New malware abuses Microsoft IIS feature to establish backdoor

New malware abuses Microsoft IIS feature to establish backdoor(symantec-enterprise-blogs.security.com)

72 points by xook 3 years ago | 59 comments

jimbobimbo 3 years ago |

FTA: "In order to use this technique, an attacker needs to gain access to the Windows system running the IIS server by some other means. In this particular case, it is unclear how this access was achieved."

See also "It rather involved being on the other side of this airtight hatchway" series by Raymond Chen:

https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=10...

https://devblogs.microsoft.com/oldnewthing/20211207-00/?p=10...

gerdesj 3 years ago | |

"it is unclear how this access was achieved"

Not a good line in a write up like this. Windows does write n store an awful lot of logs by default. However thanks to circular logging with log sizes from the 1990s on critical logs, you can easily lose information.

I can't remember what the defaults are (connects to 2016 AD DC) ... 20Mb for %SystemRoot%\System32\Winevt\Logs\Security.evtx . On a tiddly setup like mine (20 odd users), that will last ... less than a day.

I ship the logs elsewhere for proper evaluation etc but 20Mb? Yes, you can fiddle with the default sizes via group policy and you probably should but 20Mb really is off of the 1990s. OK so all the "core" logs seem to be 20Mb each and there are the rest under /Microsoft/Windows with varying sizes. I probably ought to look at what a PC logs these days - probably the same silly sizes.

Dylan16807 3 years ago | | |

My desktop has a 20MB security log that goes back 16 days, which seems like enough. If anything, stop spamming tens to hundreds of duplicate messages when credentials are read or group membership is enumerated.

System has 8 months, application has 10 months, and setup has 26 months.

msm_ 3 years ago | | |

Analyses like this are not usually performed by insiders. People that write them are external researchers (in this case, Symantec's) that have limited (or zero) insight into actual logs on the target system. There is some coordination with the attacked organisation, but requesting "please find the attack vector for us" or "just send us all your logs" is out of the question. So, unless the attack is really high profile, sometimes it's easier to just accept that you don't know something.

tbrownaw 3 years ago | |

But I don't see this being presented as a way to break in. I'd presented as a way to be sneaky about listening for commands once you're already in.

The "airtight hatchway" series is about things being presented as ways to break in, when they actually require you to already be in.

bilekas 3 years ago | |

This.. As far as I see it, if there is already access to the machine, all bets are off.

However in fairness they didn't say it was an exploit more that it's just a stealthy 'clever' malware.

dhx 3 years ago | |

I don't think "airtight hatchway" applies here because what is to say the entry point isn't exploiting w3wp.exe remotely and executing code from the stack. Then let's say a memory page containing FREB code has permission PAGE_EXECUTE_READWRITE set (a plausible possibility for JIT compiling akin to eBPF), providing a convenient (and plausibly deniable) location for an extended amount of malicious code to be stored and executed from. Or w3wp.exe has permission to create a new memory page with PAGE_EXECUTE_READWRITE set and again this is plausibly deniable because FREB may need to do similar for JIT compiling. It it were almost any other process, a memory page set to PAGE_EXECUTE_READWRITE would sound alarm bells (or at least it should).

The second aspect is how well is w3wp.exe isolated? Can and does it use "AppContainer" (or equivalent) isolation and is it strict? For example, could code executed by w3wp.exe create a new network socket, execute another process, write to a file in any path even though it shouldn't have a need to do so? Perhaps a different process sample123.exe is compromised, which by itself isn't too much of a problem due to its high degree of isolation. However, sample123.exe has permission to write to a pipe shared with w3wp.exe and can use this permission to exploit a bug in w3wp.exe (not exposed remotely) to allow code to execute with different/higher permissions of w3wp.exe, or using a plausibly deniable PAGE_EXECUTE_READWRITE memory page of w3wp.exe to store and execute code from without immediately sounding alarm bells.

_If_ strong process isolation was in place and working for w3wp.exe and/or sample123.exe, the "airtight hatchway" may not have been breached because whilst malicious code may have been executable from a stack, the malicious code wouldn't have been able to achieve much or anything of concern (can't read files from disk, can't access memory of other processes, can't login to a SQL database and start pulling data of other users, etc, etc).

I'm not sure what the equivalent of "systemd-analyze security" is for Windows, but it'd be well worthwhile for Windows system owners to demand similar easy-to-use tools for auditing the level of isolation of and required interfaces between applications (spoiler: just like a typical Linux system, the results will not be comforting, but seemingly with Windows you wouldn't know). Windows process isolation features introduced over the years are poorly documented, hard to use due to lack of tooling and often not used except for a few high profile applications such as Chromium and Adobe Acrobat. Chromium possibly has one of the best overviews of how sandboxing/process isolation can be achieved in Windows because they would have gone through a lot of pain in being amongst the first to figure it out[1].

[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...

Dwedit 3 years ago |

So in other words, this is something that someone has to run on the computer, then it injects itself into IIS. Not a remote vulnerability, just an entry point for monitoring HTTP requests once you have code execution in there.

sublinear 3 years ago |

People use IIS?

danielodievich 3 years ago |

Nobody sane runs FREB at full prod load on public sites. It's not installed by default. It is highly useful for troubleshooting but not at production traffic. Seems like if you're inside IIS already by some mystic hack you already own the space.

Someone1234 3 years ago | |

This malware is enabling FREB then injecting malware into it. The point is to hide the exploitation better than simply injecting a custom module. You don't need to be running FREB previously.

Plus I don't find the "nobody does [XYZ]" when talking about a supported feature of a popular product reassuring, there's always a somebody or the feature would have been removed since it costs money to support and maintain it.

greatgib 3 years ago |

It's 2023, if you are still using IIS you are highly incompetent and you deserved to be rooted...