Finding Beacons in the Dark Free Download

Finding Beacons in the Dark
English | Size: 13.86 MB
Genre: eLearning

There are probably hundreds of thousands of unique malware types. Analysts around the world have different vernacular and may call malware different things depending on its role, type, or variety. Viewed abstractly, many pro’s like to refer to each unique strain of malware as an ecosystem, framework, or family of related code. Every type of malware ecosystem, malware framework, or malware code family could have many interdependent parts. But each family is really its own genetic species, with its own DNA that tells it how to act, how to communicate, and how to do malicious things at the behest of an adversary. Each malware species has a population ranging from the single digits to the millions. Some species or families of malware are designed to co-exist and cooperate in symbiosis with others. The genetic analogy of malware falls apart when you consider that they do not form on their own in the wild, but are designed, written, programmed and (mostly) operated by humans. But we are still left to wonder, what causes turnover in malware? What is the average lifespan of a malware species? What causes malware to rise and fall in popularity or efficacy? Why do some malware ecosystems fail in months, and why do others live long, healthy lives? And more interestingly, what selective pressures force a malware family to evolve, or to go extinct? When I joined Mandiant in 2013, the threats that we faced at the time were no different from today, except for the names. We worked interactive intrusion activity all night, every night, and the intelligence team – like biologists, classifying and identifying new species in the field – could not give names to new malware families fast enough. Early in an intrusion operation, attacks often employ simple droppers, downloaders and reverse shells. These early-stage malware families are light and fast, often with trivial persistence and simple communications methods, and they require minimal development time from a malware author. Early-stage malware typically has a half-life of less than six months and is easy to abandon and replace if it gets “burned” or detected. Simply put, these were cheap, throwaway code families that did not survive long in the wild. They came and went quickly and many did not even last long enough to merit a name. But after initial access, our adversaries often deployed late-stage malware frameworks. Once the adversary had a seemingly undetected foothold, they would switch out early malware for deeper malware frameworks referred to interchangeably as “post-exploitation tooling,” “command-and-control (C2) frameworks,” or simply “late-stage” malware “backdoors.” Late-stage malware frameworks often use stealthy C2 schemas and network protocols. They often have a “core implant” with a modular plugin architecture and novel persistence mechanisms, and they are designed to provide comprehensive command-line access to remote operators. Late-stage malware ecosystems require huge development investments and are expected to provide years of utility. An example of an early-stage malware family may be a simple HTTP downloader that uses a common Windows\CurrentVersion\Run registry key for persistence. An example of a late-stage malware could be something like Cobalt Strike’s immensely versatile Beacon payload. Early-stage malware gets replaced wholesale when it gets burned, whereas late-stage malware can last for decades with tweaks, forks, improvements, and plugins. Late-stage malware has a longer lifespan 8 because attackers want to protect their development investments. To get extra life out of core implants (such as TrickBot or SHADOWPAD/POISONPLUG), malware developers must introduce new plugins, new functionality, and new obfuscations. And they must create increasingly elaborate packaging and multi-layered delivery schemes to evade detection and subvert meaningful analysis. You are likely familiar with some of the titans of late-stage malware, from the days of yore. For example, Poison Ivy and PlugX, which may have been in use as far back as 2005. Or Gh0st RAT, which goes as far back as 2008. And HiKit, which goes back to at least 2011, maybe earlier. Poison Ivy and Gh0st dominated nearly a decade of intrusion operations, and they were for the most part stomped out by public research and tooling to help improve global detection. These families survive in a miniscule footprint today, but evolutionary pressure pushed these species close to extinction. HiKit and PlugX were detected, and while they were not snuffed out, they were both forced to evolve. Over the years we have seen several modernizations, tweaks, forks, and derivatives. In the face of evolutionary pressure, malware developers are working to get extra mileage out of their investments. Source code from both of these families have been used to create new malware frameworks altogether. These families aren’t dead yet, but I think the continued development effort shows that we have levied some cost on the adversaries who wish to continue using these toolkits. While watching the ascent and decline of Pirpi, CozyCar, Xagent, Zxshell, Derusbi, and countless other beloved malware families, I’ve learned that it takes years of community effort, intelligence sharing, open-source tooling, and public detection research to apply pressure on the dominant late-stage malware frameworks. Versatile late-stage, post-exploitation malware ecosystems become even more complicated because we need to study not only the malware itself, but also how the malware is configured, deployed and operated by a variety of threat actors in a multitude of campaigns over a long period of time. Rather than just deep analysis of single samples, we must approach doing bulk analysis of tens of thousands of files at a time, all within the context of thousands of intrusion operations. That’s no small feat, especially when it comes to the topic du jour, Cobalt Strike. Cobalt Strike is a post-exploitation framework that was developed to emulate the greatest features of late-stage malware ecosystems and allow its users to simulate adversary actions. The adoption of Cobalt Strike by global threat actors, and the framework’s use in hundreds of genuine intrusions, ransoms, and data breaches, shows that Beacon has fought its way to the top. It currently sits on the throne as the reigning champ of all malware toolkits. If it works, it wins. While Poison Ivy and Gh0st have gone out to pasture, Cobalt Strike and its core implant Beacon have stepped into the limelight. This forces analysts and researchers around the world to renew their approaches to collecting, processing and sharing information about Cobalt Strike and its use in bulk. Can you detect Cobalt Strike payloads before they execute? Or only after they execute? Can you detect the network C2 traffic? And when you see Cobalt Strike detections, can you differentiate between a red team engagement and a bona fide intrusion? More proactively, can you develop intelligence on a Cobalt Strike wave before the first phishing email is sent your way? Can you identify a C2 server before the adversary builds their first payload? Can you extract additional intelligence directly from adversary-controlled infrastructure? These are questions that each organization must ask itself, and the team at BlackBerry are offering different ways to say yes. “Finding Beacons in the Dark” is a labor of love by practitioners for practitioners. What began as a project to detect Cobalt Strike exploded into a full-blown automation platform for broad collection, processing, and data harvesting from Cobalt Strike team servers with corresponding Beacon payloads and their configuration details. 9 Through creating this system and analyzing the data en masse, the BlackBerry Research & Intelligence Team observed trends and developed a holistic picture of Cobalt Strike across many phases of the threat intelligence lifecycle. From static payload analysis to configs to server fingerprints to unique toolmarks, the authors of this book provide a practical and detailed look at the Cobalt Strike framework itself and then dive into examples that will help you understand how it gets used in the wild. There are some handy detection rules and scripts, as well. There’s more than meets the eye in these pages, and through the lens of Cobalt Strike you may gain a better understanding of how threat actors tend to design, configure and operate malware of all types. (Spoiler alert: ports 80, 443 and 8080 are malware config favorites for good reason — they are almost always “open” on network gear!) If you’re like me, you’ll probably have fun spelunking through the details and operationalizing what you learn. I hope that this inspires you to become a part of the evolutionary pressure, and more broadly, I hope that this work serves as a model for how to build and share bulk intelligence analysis about prolific malware families.