Because a single byte XOR is one of the oldest tricks in the book, yara actually supports native detection with the xor modifier:ĭescription = "Identifies XOR'd strings used in Cobalt Strike Beacon DLL." To confirm, we can use CyberChef:Īs you can see, the “This program cannot be run in DOS mode” string appears after decoding, confirming our theory. This can be an indication that Beacon is using a simple one-byte XOR obfuscation. Quickly looking at this, we can see a lot of repeated bytes (0x80 in this case) where we would actually expect null bytes. If we look in memory where the MZ/PE header would normally be found, we now see it is obfuscated: This would give us a good base of coverage, but we can do better by looking at the samples with sleep_mask enabled. To demonstrate, will will be writing signatures with yara, an industry standard tool for this purpose:ĭescription = "Identifies strings used in Cobalt Strike Beacon DLL." The easiest win would be to pick a few unique strings from this region and use those as our signature. Starting with a sample with sleep_mask disabled, after detonation we can locate Beacon in memory with Process Hacker by looking for a thread which calls SleepEx from an unbacked region:įrom there, we can save the associated memory region to disk for analysis: We will start by obtaining a handful of Beacon payloads with the sleep_mask option enabled and disabled with the most recent releases (hashes in reference section). We will need to consider this option when developing signatures, but it is still easy to signature Beacon even with these advanced stealth features. For example, the obfuscate-and-sleep option attempts to mask portions of the Beacon payload between callbacks to specifically evade signature-based memory scans. Further, Beacon can be configured with a variety of in-memory obfuscation options to hide its payload. Here we will attempt to use memory signatures as an alternative detection strategy.īeacon is typically reflectively loaded into memory and never touches disk in a directly signaturable form.
However, due to the level of configurability in Beacon, there are usually ways to evade public detection strategies. This includes looking for unbacked threads, and, more recently, built-in named pipes. There have been various techniques for detecting Beacon, Cobalt Strike’s endpoint payload. Presumably due to its ease of use, stability, and stealth features, it is also a favorite tool for bad actors with even more nefarious intentions. In this post, we will use Cobalt Strike as an example for leveraging in-memory signatures.Ĭobalt Strike is a popular framework for conducting red team operations and adversary simulation. This effectively extends the shelf life of the signature from days to months. To step around the issue of packers and loaders, we can focus signature detection strategies on in-memory content. These components rapidly evolve to evade signature detection however, the final malware payload is eventually decrypted and executed in memory. One roadblock to creating signatures that provide long-term value is the widespread use of packers and throw-away malware loaders. Even if we could hypothetically catch only half of known malware with signatures, that is still a huge win when layered with other protections, considering the other benefits. For example, an alert for TrickBot or REvil Ransomware requires more immediate action than a potentially unwanted adware variant. Signatures, while unable to detect unknown malware, have false positive rates that approach zero and have associated labels that help prioritize alerts. Performance and false positive rates are also critical in measuring a detection technique's effectiveness. Historically, we’ve felt that signatures are too easily evaded, but we also recognize that ease of evasion is only one of many factors to consider. These two methods are powerful because they can detect never-before-seen malware. Traditionally, we have focused on machine learning models and behaviors. At Elastic Security, we approach the challenge of threat detection with various methods.
0 kommentar(er)
