Thread by @IISResetMe

No DNS logs?

Next best activity indicator seems to be file-write events to `SolarWindows.Orion.Core.BusinessLayer.dll.config` (used to track detection and modification of forensic/anti-tamper services)

... but you probably don't track those either 😉 #SolarWinds #SUNBURST

https://twitter.com/cyb3rops/status/1339505185178218496

Couple of colleagues also reported seeing reports that the config file should contain a setting key'd `ReportStatus`.

Looking at the March sample (32519b85..107d6c77) This is NOT true, the key names in the file on disk starts with `ReportWatcher`, not `ReportStatus`

Something haven't seen elsewhere:
When the main loop enters a state of `Truncate` (ReportWatcherRetry=3 on disk), it breaks the current run. FireEye previously reported that subsequent frequency of reactivation was unclear.

The default update interval is 24h

How do I know?

Backdoor piggybacks off a background refresh timer used by a (legitimate) inventory management component in Orion.

Default setting for this interval is 24h, but configurable (check `Settings` table in Orion db for settings matching SolarW*BackgroundInventory*)

The reports on Service detection and modification I've seen so far fails to make clear that the backdoor distinguishes between "maleable detectors" (the services modified and tracked in the config file) and "dealbreakers" - running processes that'll make it abort immediately

The few "maleable detectors" I've been able to decode so far have been AV/EDR agents.

The "dealbreaker" list on the other hand contains a long list of both generic and specialized forensic tools. Using hashes published by FE, we can identify most: gist.github.com/IISResetMe/d61…

And here's the "maleable detector" list, I've included the value you should expect to see as the `ReportWatcherPostpone` value in the config file if detected (presuming only one is running): gist.github.com/IISResetMe/d61…

So if you see in the config file:
ReportWatcherRetry=3
ReportWatcherPostpone=255

It means the backdoor is dormant due to detection of Windows Defender

Finally, it has an optional 3rd-level component for detecting system drivers, all of which FE already cracked (these are also all "dealbreakers", but not checked in between job executions when it's in Append state)

gist.github.com/IISResetMe/d61…

This distinction between 3 different "buckets" of target systems processes/drivers for evasion purposes is pretty important.

Initial reports from FE and subsequently CrowdStrike stated or implied these were all equally "dealbreaking" for the backdoor, but that's not true.

On encountering one of the 8 maleable detection product families, it:
- Takes a backup of SCM ACL for the service
- Modifies the ACL to take ownership
- Disables the service

Before going dormant again (ReportStatus=`Truncate`), it restores the original ACL and settings

This means that:
- Dealbreaker drivers installed prevents execution completely
- Dealbreaker processes AT RUNTIME prevents job execution AT THAT TIME
- The 8 AV products don't prevent shit unless you've cranked up anti-tampering settings😁

Clarification: it disables the service by overwriting the scm config in the registry - but it never actually interacts with scm - it just goes dormant again, waiting for the service to crash or a reboot to occur.

https://twitter.com/IISResetMe/status/1339578221365325835

This means that if you
1. Monitor changes to services in registry, AND
2. Had the (un)fortune to use one of the 8 AV families

then here's now a 3rd opportunity for inferring usage patterns...

... but you probably don't collect that either, do you? ;-)