Does the command and control (C2) traffic of an attack transmitted via IMAP remain “invisible”? Or can a C2 agent specially designed for IMAP be detected? We have tested it.
Attack detection in practice
The eternal game of cat and mouse between attack and defense in the networked world never ends. This is why Trovent and carmasec work closely together to regularly test new attack methods of the carmasec Offensive Security Squad against Trovent’s attack detection.
We pursue these goals together:
- We want to refine the attack methodologies to increase the effectiveness of red-teaming maneuvers.
- We are constantly exposing the detection capabilities to maximum challenges in order to gradually improve them.
How can you recognize an IMAP C2 agent?
Timo Sablowski, Senior Security Consultant at carmasec, implemented a command and control (C2) agent based purely on IMAP. Together we decided to take a closer look at it in an attack/detection scenario.
Timo demonstrates how C2 communication works in a LinkedIn post. Here, the infrastructure of free email providers is used to enable communication between the compromised system and the attacker.
First of all, it can be clearly stated: Detection is not possible with conventional approaches. For example, when using public IMAP servers, the known IP blacklisting approaches definitely do not work. Other detection methods must therefore obviously be used!
So we started with our work. In the first step, we ran the code of the C2 agent in the Trovent lab in order to have the generated traffic monitored by the Trovent MDR system. We then investigated the following possibilities for a potentially successful detection of C2 traffic in detail.
Monitor session duration – is that too trivial?
As has already been observed with other C2 implementations, a session could also be used by the C2 agent in this case that remains open for a very long period of time (i.e. several days). And indeed: After one day, the Trovent MDR system reported that the IMAP session in the lab had been open for more than 24 hours.
But that alone does not constitute a security-relevant event. And the potential for a large volume of false positives is correspondingly high in this context. Why? Even regular, non-malicious IMAP clients can keep connections open for a long time.
Even if the long duration were a reliable detection criterion, it is child’s play for a technically competent attacker to adapt the C2 agent so that the session is regularly disconnected and reconnected. As the remote peer is a public IMAP server, the attacker does not run the risk of being unintentionally detected based on the entries in the collected log data.
Frequency of communication – a reliable indicator?
After we quickly realized that the duration of the session alone is not a reliable indicator for the detection of C2 traffic, we took a closer look at the IMAP communication in its specific behavior and frequency. To do this, we wrote some Python code. This extracts the time stamps and transmission volumes from the output of tcpdump, creates a time series and calculates the spectrum of the communication with the help of Fourier transformation.
For a recording of IMAP communication in the Lab, this analysis provides a clear peak every five minutes. This peak actually corresponds to the frequency with which the C2 agent polls the IMAP server for new commands.
Deterministic behavior – the key to detection?
This clearly recognizable, deterministic behaviour could clearly detect C2 traffic packaged in IMAP traffic – right? No. A comparison with a recording of regular IMAP traffic quickly brought disillusionment. There is a clearly recognizable peak there too. The fact that this is ten minutes and not five minutes was of little consolation.
This is because both a regular IMAP client and the C2 implementation could easily work with other frequencies. Furthermore, it would not be difficult to eliminate any periodicity from a C2 client by randomizing the time intervals. In short, developing a workaround for corresponding detection mechanisms would not be a major challenge for attackers.
The solution: incorporating contextual knowledge into attack detection
What conclusions can we draw from the tests carried out? We found no single, unambiguous criterion that could reliably identify C2 communication in IMAP traffic. Does Timo Sablowski really have an easy time with his C2 traffic via IMAP? Are there no reasonable detection approaches without drowning in a flood of false positives?
Let’s summarize the situation:
- What do we have?
We have certain indicators (session duration and frequency), but these are not reliable detection criteria in themselves.
- What can we do?
Combining detected indicators with contextual knowledge about the IT infrastructure can significantly increase the effectiveness of detection.
This contextual knowledge can include, for example, information about which host has communicated with which IMAP servers in the past and which mail client is installed. The observed frequency spectra of IMAP communication are also important.
A connection to a previously unused IMAP server, IMAP communication from a system with an unknown mail client, a change in the communication frequency … these would all be clear indications of potentially malicious C2 communication that a SOC analyst could and should investigate.
Conclusion of the test
Ultimately, the tests carried out jointly by Trovent and carmasec in this particular scenario confirm the experience gained to date: Successful detection is less a question of individual, technically innovative methods. Rather, it depends on being able to assess the observed events and indicators in the right context.
Sophisticated attack techniques such as Timo Sablowski’s IMAP-based C2 implementation can be detected! The prerequisite for this, however, is having a solution at hand with which the necessary contextual knowledge about the IT infrastructure can be built up automatically.
Background: How can contextual knowledge be generated automatically?
Contextual knowledge is extremely important in order to objectively assess the significance of detected anomalies and the potential threat they pose to the organization. But how can the need to collect this knowledge and keep it up to date be mastered? The documentation of current asset information alone (for example in a CMDB) often fails in day-to-day IT work, as there is usually a lack of personnel capacity.
The Context Engine, which is an integral part of the Trovent (Cloud) MDR solution, makes it possible to build up precisely this required contextual knowledge in the background – without the manual intervention of a SOC analyst or IT administrator. Information about the organization’s IT infrastructure assets is extracted from collected log data and network flows and linked to each other in a graph database.
This information includes, for example:
- Systems with their host names and IP addresses
- Users with their accounts
- Operating systems and their different versions
- Software packages with characteristic registry keys and files
- Servers (e.g. IMAP) that are contacted by a host
By automatically processing the context information, the Context Engine generates a picture of the normal behavioral state of the IT infrastructure, including its users and applications. This makes it possible to recognize when something changes – for example, IMAP traffic that has never occurred in an observed combination of IMAP client, host and IMAP server.
Are you looking for an attack detection system or a managed detection & response solution? Or would you like to know how Trovent’s Context Engine works? Get in touch with us! We will be happy to talk to you and demonstrate our solutions.