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:
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.
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.
Yes (20Mb), but so do AD DCs which is frankly lazy on MS dev's part. If a DC is such a big deal that it requires rather more cash to buy than a "workstation" edition of Windows, then I'd like to see more attention to detail.
By contrast a Linux box running systemd/journald by default will leave 10% disc space free when logging. That's enough to keep a filesystem honest!
20Mb on a DC - even one for a small site like mine will cycle quite often.
I really recommend that you extend your logs to cover six months or more. It will cost you maybe a gigabyte or 10. Very little these days (my first HD was 20MB, yes: megabytes). However if you need to get some details from the past - very handy.
It's absolutely not enough for APT investigation. Average attacks lengths are in months, infections sometimes span multiple years. Especially since we're talking about a backdoor (ransomware operators tend to move more quickly)
It's not enough for that, but that bar is too high. Unless the logs are very small, you should not be keeping years of them. I still say 20MB is enough for a desktop.
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.
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].
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.