Skip links

Want to detect Cobalt Strike on the network? Look to process memory

Enterprise security pros can detect malware samples in environments that incorporate the highly evasive Cobalt Strike attack code by analyzing artifacts in process memory, according to researchers with Palo Alto Networks’ Unit 42 threat intelligence unit.

Cobalt Strike is possibly the best-known example of legitimate commercial security software – it was designed to help red teams test their organizations’ cyber defenses – that has been co-opted by threat groups that use it to get around those defenses. The Nighthawk command-and-control framework could become another example of abused legit infosec software.

The commercial Cobalt Strike toolkit is only sold to vetted customers who use it to run security tests, but source code leaks led to threat groups – from ransomware gangs to nation-state attackers – using it to gain initial entrance into targeted networks. Unit 42’s researchers note it was used in the high-profile attack on SolarWinds in 2020.

“One of the main advantages of Cobalt Strike is that it mainly operates in memory once the initial loader is executed,” Unit 42 malware researchers Dominik Reichel, Esmid Idrizovic, and Bob Jung write in a report. “This situation poses a problem for detection when the payload is statically armored, exists only in memory and refuses to execute. This is a challenge to many security software products, as scanning memory is anything but easy.”

Cobalt Strike is included in a payload delivered with file loader malware, they write. When the loader is executed by the victim, it decrypts or decodes the payload into memory and runs it. Because the payload is present in memory in its original form, it can be more easily detected.

The researchers attest that Cobalt Strike can be detected in the memory. Palo Alto designed a hypervisor-based sandbox for analyzing artifacts in memory and Unit 42 analyzed samples of three Cobalt Strike loaders detected by the sandbox.

One of the loaders – dubbed KoboldLoader – uses various techniques to evade detection. KoboldLoader runs the payload using mapping injection and launches a decrypted Cobalt Strike SMB beacon that can be detected in memory, despite some in-memory evasion features.

It would have been impossible to detect the SMB beacon without being able to look inside memory while the malicious code was being executed, according to the researchers.

MagnetLoader is a DLL that imitates a legitimate Windows library and decrypts the Cobalt Strike beacon into a memory buffer, using a Windows API function to run the beacon loader rather than calling it directly.

LithiumLoader is a DLL that uses a side-loading attack technique that hijacks legitimate software to run another malicious DLL. The sample was part of a Fortinet installation package created by the attackers and submitted to VirusTotal. One of the loader’s functions indirectly runs the Cobalt Strike stager shelled code through the EnumSystemGeoID function rather than directly. The stager shellcode is a reverse HTTP shell payload.

“These samples do not execute in normal sandbox environments,” the researchers write. “But … there is a wealth of information that we can use for detection if we look inside memory during execution, like function pointers, decoded stages of the loader, and other artifacts.”

Palo Alto put tactics for analyzing memory into its Advanced WildFire cloud malware protection tool to complement other techniques like instrumenting and logging API calls. One is automatic payload extraction, which helps when malware makers obfuscate the payloads and run evasion practices.

Building signatures for the payloads can enable detection of different malware components like Cobalt Strike and “if we can catch them in memory, it ultimately doesn’t matter if the malware decides not to execute,” the researchers write.

Another tactic is using Windows API function pointers. Malware designers typically hide the Windows API functions they use to evade detection. Advanced WildFire can selectively search for and use data about the function pointers to detect Cobalt Strike.

Security pros can also look at memory to find changes to Windows bookkeeping structures, which the operating system uses to track process characteristics libraries that have been loaded. Executable images are also loaded to the bookkeeping structures.

“Given that many of these fields should never be modified, it’s often useful to keep track of when and how malware samples are manipulating them,” the researchers argue.

In addition, malware writers often must change memory permissions to properly load and execute further stages. Security analysts who know which memory pages had their permissions changed can see where malicious code was loaded and executed. ®