Maelstrom #1: An Introduction
Throughout this series, we will be slowly building out a Command & Control Framework and discussing common implementation, IOCs, and TTPs.
Last updated
Throughout this series, we will be slowly building out a Command & Control Framework and discussing common implementation, IOCs, and TTPs.
Last updated
Command & Control (C2) Frameworks are becoming increasingly more common and necessary for penetration tests, "red teaming", and Advanced Persistent Threat (APT)s. By combining av / edr avoidance, the utility of implant control, and file CRUD (Create, Read, Update, and Delete), A C2 massively improves an operators quality of life on an engagement. This has resulted in more and more offensive tooling making its way online over the past 5 years, far more advanced and capable than its predecessors.
The typical consultancy will find that they have filled the technical gap of a C2 by either buying an off-the-shelf solution or a cobbled homebrew solutions such as running metasploit with custom meterpreter droppers encoded with msfvenom or re-implementing crackmapexec and impacket functions. But what was once a point of convenience is now a point of necessity as endpoint protection has turned older methodologies into a list of blockers. As the industry balances around the convenience of delivering code and retrieving content using C2s, bad guys have been increasingly also using custom or cracked tooling for their own operations.
The C2 Matrix tries to track as much of the burgeoning marketplace of C2s as possible. At the time of writing 96 102 C2s are tracked. C2 Matrix's Google Sheet shows the ambitions of the community with its varying implant languages, target Operating Systems, and UI/UX.
In looking at these C2s, we found that a lot of the heavy hitters1 had proprietary code, as they were the research projects or products of consultancies. To preserve the viability of these commercial business assets, their source code is protected. This limits the ability of defenders to identify and respond to attacks using these C2s, or C2s developed using their research, as defenders must obtain and reverse samples of the C2s implants before static detections can be written based on captured samples. Furthermore, it is only when these detections are released to the wider community (such as on VirusTotal) that everyone is protected from these cutting-edge implementations.
A number of vendors do responsibly explain their techniques, which allows defenders to infer runtime detections. Rarely, vendors share sample submissions, which allows defenders to write static detections such as YARA rules or more general AV signatures. These products are ultimately intended to improve the security of clients commissioning assessments - it doesn't help defenders when these same tools are stolen, cracked, or purchased legitimately. In return for empowering attackers, defenders are not freely provided with a countermeasure.
Open-source and cracked closed-source C2s are widely disseminated, so are their detections. But at the cutting edge, a fog remains.
Early C2s (see Metasploit, Armitage, Empire) acted as a simple point of convenience within a test, co-ordinating exploit delivery, and beacon management. They would vary in complexity, and operators were generally in a position to understand their operation. Prevalent exams such as OSCP focused on the basic knowledge of directly interacting with exploits and reverse shells. The required knowledge to obtain a shell using these C2s was not far beyond the required knowledge to write a custom C2. A basic working knowledge of Python or C# and some time to re-write a reverse shell would grant a beacon which would return a shell and not be detected by anti-virus.
However, the state-of-the-art has moved beyond this as C2s are now required tooling on engagements.
As endpoint detection improves, so must the implant. As the implants improve, they must reach further into the recesses of Windows. This requires more development time, incentivising closed-source development of C2s and C2 modules to provide a return on investment. A modern C2's internal behaviours are almost a closed box as the required knowledge to develop outstrips the required knowledge to operate them.
The industry entered the 2010s with workflows centring around implants as executable files dropped on disk or PowerShell scripts. Now, modern stagers include far more complex and bespoke approaches to their implants, such as environmental keying, indirect callbacks via system and web proxying, and deep packet inspection proof channels. Defenders now have to detect and respond using advanced indicators of compromise (IOC) rather than simply using signatures targeting known C2 implants.
So with this as our background, we wanted to explore how C2s function in 2022, what evasive behavior's are required, and what a minimum viable C2 looks like in a world of sophisticated endpoint protection.
Which gave us our goals for this blog series:
Document the internals of a minimum viable C2:
What are the ideas behind popular C2 implementations?
What are their goals and objectives?
Analyse and implement evasive behaviors:
What is required to run on a contemporary Windows system?
What is required to bypass up-to-date, modern endpoint protection?
Produce a proof-of-concept C2:
What is the minimum viable C2 for an operator in 2022?
What is required to detect this minimum viable C2?
With that said, we don't want to produce a C2 that is usable from the get-go - it's solely useful to demonstrate behaviour. Our goal in writing is to simply discuss the concepts and review how the behaviour could be tracked; to use this example C2 offensively, you still have to learn how to code and how to act securely.
Content provided within this series will require enough background knowledge to weaponise that potential users will already be able to write their own version anyway, but defenders and operators alike should hopefully find the exploration informative.
With that in mind, we've:
Not implemented all evasive techniques discussed.
Provided Yara rules and uploaded samples to VirusTotal.
Left (deliberately!) really awkward code.
What we are going to publish in this series is a discussion on the broad aspects of a C2:
The architectural decisions regarding the Server and the Implant
The user experience, with examples and our thoughts
Endpoint protection (as an exercise for the reader), exploring how operations can still be stymied.
A Static OpSec Review to look at common pitfalls implants can face.
A Runtime OpSec Review to look at the same... but at runtime.
Communications to and from the server and how both stealth and detections work beyond the target device.
By doing this, we hope to shed light on the internals of a C2 and aid vendors in identifying gaps in their detections, as well as improving the efficacy of operators in identifying legitimate gaps in security that could be exploited by a contemporary attacker.