The SolarWinds attack, which succeeded by utilizing the sunburst malware, shocked the cyber-security industry. This attack achieved persistence and was able to evade internal systems long enough to gain access to the source code of the victim.
Because of the far-reaching SolarWinds deployments, the perpetrators were also able to infiltrate many other organizations, looking for intellectual property and other assets.
Among the co-victims: US government, government contractors, Information Technology companies, and NGOs. An incredible amount of sensitive data was stolen from several customers after a trojanized version of SolarWinds’ application was installed on their internal structures.
Looking at the technical capabilities of the malware, as you will see, this particular attack was quite impressive. A particular file, named SolarWinds.Orion.Core.BusinessLayer.dll is a SolarWinds digitally signed component of the Orion software framework.
The threat actors installed a backdoor that communicates via HTTP to third-party servers. After an initial dormant period of up to two weeks, it retrieves and executes commands, called “Jobs,” which includes the ability to transfer files, execute files, profile the system, reboot the machine, and disable system services.
So how could one protect the organization from Sunburst or a similar attack? Supply chain attacks have the advantage of establishing an initial foothold under the guise of a trusted 3rd party. But that’s where the distinction ends; from there on, they progress like any other attack, and they can be detected if we know where to look.
Developing SIEM rules, using the SolarWinds attack as an example
Let’s start with Sigma rules; these create a sort of a common language to create and share quality queries regardless of the SIEM your organization uses. The Cymulate platform will produce Sigma Rules for you to download these queries to your SIEM. This will enable Security Operations teams to build out the elements needed to detect future attacks. As you can see below in the 3 examples, the Sigma Rule is the same, yet the custom query is specifically for that SIEM’s language. At the click of a button, you can switch to your preferred SIEM.
Example 1: Splunk:
Example 2: Qradar:
Example 3: Azure Sentinel:
Although Sigma rules are designed mostly for queries, one can use them to build a full anti-attack-chain SIEM or EDR rule. In the case of the SolarWinds Sunburst attack and many other attacks, Cymulate Sigma Rules are queries that search for the IOBs of the attack. Each sigma rule will query the SIEM for an IOB of one stage of the attack.
When the IOBs from the sigma rules are combined, they can result in a specific rule for the target system – something that can, with a high degree of confidence, point out the attack without “inventing the wheel” all over again. All the required IOB’s are in place – in the Sigma rules – you just need to reach out your hand and take them.
Let’s look at the specific case of a recreated SolarWinds attack on the Windows platform and hunt it together.
Hunting SolarWinds on Microsoft Windows
The Cymulate Platform provides us the capability to replicate the supply chain attack, which starts with an Exchange server mailbox export. The subsequent stages of the attack, available in the Cymulate platform to simulate the attack, can be seen in the screenshot.
The first event will not get any trigger by Windows, but it will be written in various network logs. Since the event itself cannot be very specific, we will leave it as optional for placement in a general rule. Let’s continue.
The next event in the attack is downloading content with PowerShell. Such an event can be monitored with Windows Event IDs 4103 and 4104, which can also show the actual code being run, but we don’t want to limit ourselves to a specific method because, let’s face it: PowerShell is not the only tool an attacker can use.
What is common to all tools is that while downloading content, an object is created in the system, and for that, there is a Windows Event ID 4663 with an indicator of Access mask 0x1 or, if you use Sysmon, Event ID 11.
Below is a general screenshot of a 4663 Event ID with the relevant fields highlighted. This is the event that the Cymulate Sigma rule detects, and it is also the first IOB in the rule that we will create. You can find more on this Event ID here.
Next in line is the next stage in the attack: Task Scheduler: Masquerading Tasks triggered on the windows lock screen for lateral movement. Once again, it is irrelevant exactly which Tasks are being masqueraded; what is important is that there are Windows Event ID’s that can help us identify this chain of events.
The Event ID’s are:
4698 – task created
4700 – Scheduled task enabled.
4702 – Scheduled task updated.
4699 – Scheduled task removed.
What is relevant for us is, of course, is 4698 as this will pop up when a new task is created. Events of updating, enabling and/or removing a task are a good enhancement but optional. Personally, I would recommend adding an option of 4699, since there is always a possibility that the attacker would like to remove the task after completion to cover his tracks.
So, what we will want for minimal requirements is 4698 with a set of specific regexes in the “Command” field in the event, that match known executable types for example:
– ‘.exe’ – ‘.py – ‘.ps1’ – ‘.msi – ‘.msp’ – ‘.mst’ – ‘.ws’ – ‘.wsf’ – ‘.vb’ – ‘.vbs’ – ‘.jst’ – ‘.cmd’ – ‘.cpl’
For complex cases, regular expressions, such as those below, can be used:
- – ‘^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)?$’
- -‘^([A-Za-z0-9 \/]{4})*([A-Za-z0-9 \/]{3}=|[A-Za-z0-9 \/]{2}==)?$’
Pay special attention to the last two IOBs (regexes): these match a base64 pattern. Although “Scheduled Task” receives a string as an input, it is possible to write in it an obfuscated/encrypted form of a command. For example, “python” as command and “base64.b64decode(some base64 payload)” as an argument, thus effectively making your task into “decoding base64 payload” tool.
Once again, all the indicators can be found in the Sigma Rules supplied by Cymulate. We will call this list and other upcoming lists of IOB’s just “relevant IOB list” for the purpose of convenience. Below is the general view of the 4698 Event ID of creating a new task.
So, by now, we have covered two events in the chain. These should occur on the same machine and with the same username. After that, the process in your task will be executed, resulting in 4688 Event ID with Creator Process name: TaskScheduler or TaskScheduler.dll or taskeng.exe (depending on the version of build you use), and New Process Name will have one of those IOB’s in the executables list. So, at this stage, our Rule looks like this:
(4663 + Access mask 0x1)🡪 (4698 and relevant IOB list)🡪 (4688+list of relevant Creator Process name + list of relevant IOBs as part of New process Name)
OR
4663 + Access mask 0x1 or Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe))]
The 🡪 sign represents “followed by” operation
The next stage in the attack is running DLL file with rundll32. This is a simple IOB, which, by the way, can be run in a previous step as well. In this specific case it is 4688+rundll.32
Next is ADFind : Enumerating an AD Group using ADFind Masqueraded as csrss.exe. This step is a bit tricky. During this step an attacker masquerades his enumerating tool as some legitimate file. However, before this can happen, the illegitimate file has to be written somewhere on one of your drives (preferably in the system folder) with the legitimate name.
In this specific case it is csrss.exe, but there is quite a large number of file names that could be used for the same purpose for example:
– ‘svchost.exe’. – rundll32.exe. – services.exe. – powershell.exe. – regsvr32.exe. – spoolsv.exe
– lsass.exe. – smss.exe. – csrss.exe. – conhost.exe. – wininit.exe. – winlogon.exe. – explorer.exe
– taskhost.exe. – Taskmgr.exe. – sihost.exe – RuntimeBroker.exe – smartscreen.exe.
Again, no need to search for all of them, they are already supplied in the relevant Sigma rule.
Below is an example of one possible Sigma rule for this specific step, which detects creating a file with one of the specified above names. But with a hash that is different from the original. Whether overriding a system file or creating a new path, it will still result in a 4663 Event ID (or Sysmon Event ID 11), and one of the names below will be found in the payload.
Working with System files also requires privileged access, so there inevitably will be privilege escalation, which is also documented as 4688 Event ID (file access) and Token Elevation Type of %%1936 or %%1937, which are types for system and administrator access respectively.
Below is a screenshot of the 4688 Event ID with relevant fields highlighted.
Optionally you could search for 4672 Event ID with any of the privilege escalation strings, but the event of privilege escalation can happen at any step in the attack. We recommend a separate rule for this, which should be correlated with the rule we are building.
Let’s take a look at our rule at this stage:
(4663 + Access mask 0x1 or Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe)) 🡪 (4688 and rundll32) 🡪 (4663 or Sysmon 11 + generic list of system files) 🡪 (4688 and 1 of files in list and Token Elevation Type (%%1936 OR %%1937))]
The next step is “Execute base64-encoded PowerShell from Windows Registry“. What happens here is an attacker executes an obfuscated code previously written into a registry value. As you could understand, before he can do this, he needs to create a new registry value or modify an existing one.
A Windows event ID 4657 and a value matching base64 pattern (which can be identified with regexes that we have already seen in a preceding step) can help identify this step. The event can include “Existing registry value modified” or “Creating new registry value” as the Operation Type. All the IOB’s, as mentioned before, can be obtained from the supplied Sigma Rules.
This event can show you other valuable information, such as:
1) What key was involved.
The format is: \REGISTRY\HIVE\PATH where:
HIVE:
- HKEY_LOCAL_MACHINE = \REGISTRY\MACHINE
- HKEY_CURRENT_USER = \REGISTRY\USER\[USER_SID], where [USER_SID] is the SID of current user.
- HKEY_CLASSES_ROOT = \REGISTRY\MACHINE\SOFTWARE\Classes
- HKEY_USERS = \REGISTRY\USER
- HKEY_CURRENT_CONFIG = \REGISTRY\MACHINE\SYSTEM\ControlSet001\Hardware Profiles\Current
2) What is the originating process.
3) What is the old value and the new value.
Below you can view a general representation of 4657 Event ID.
Taking into account possible timeframes, since the entire operation will probably be scripted, we can safely say that if successful, steps 2-6 will take no more than 5 seconds. The entire chain until execution of code stored in the registry could be no more than 10 minutes.
After adding those variables, what we have is a chain of events that can be correlated:
- It will all originate on one machine.
- It will be started as the same user.
- The operational rule will look like the below:
{
(4663 + Access mask 0x1 or Sysmon 11)🡪
[ (4698 + relevant IOB list) 🡪
(4688+(TaskScheduler.dll or taskeng.exe)) 🡪
(4688 and rundll32) 🡪
(4663 or Sysmon 11 + generic list of system files) 🡪
(4688 and 1 of files in list and Token Elevation Type(%%1936 OR %%1937))🡪 (4657 +New value created OR existing value modified+ base64 matching pattern in value in time frame up to 5s)]
in time frame of 10 mins
}
So now, if you have built this SIEM or EDR rule, using Cymulate-provided Sigma rules, and you see an alert from it – there is a good chance you are experiencing the SolarWinds attack right now.
If you still have your doubt, you can always add some optional stages and enhance them even further by adding two next stages to the rule. These are Exchange Server Mailbox Export Cleanup and Exchange Exfiltration using basic HTTP Request, respectively.
Even though Windows doesn’t have a built-in Event ID for HTTP/S requests, there will always be {4660 on mailbox🡪 (HTTP request + 4663 of filename.zip/rar/tar/other)}. In order to get an event of HTTP/S requests, additional systems, for example, a network traffic analysis system, can assist here.
Optimize your Security Operations with Cymulate and Sigma Rules
As you have seen in the breakdown of this particular attack, you can use IOB’s in Sigma Rules. This will help your security operations to challenge, assess, measure, and optimize. This can easily be accomplished by the Cymulate platform in all areas. The steps as shown in this article are meant to help with the optimization and guide through how to prevent a SolarWinds type attack. As you have seen from the Cymulate platform, a scenario, whether it be simple, or complex can assist with optimizing your SIEM or EDR rules. This will enhance your organization’s security against the most sophisticated threats with low effort.
Good Hunting to you!
And as they say in the Hunger Games, “may the odds be ever in your favor.”
This article was written by Michael Ioffe, Senior Security Researcher at Cymulate.
From: thehackernews.com