In this article, I aim to present technical security perspectives on identifying C2 servers based on a few APT groups. APT groups are generally state-backed, highly capable, and dangerous hacker groups.
For example, APT39 is a threat group known for conducting cyber espionage supported by the Iranian Ministry of Intelligence and Security under various aliases. These groups use specific tactics and techniques to infiltrate systems, steal data, and avoid detection. They have tactics and techniques they consistently use at each stage, forming their procedures known as TTPs (Tactics, Techniques, and Procedures). Each group has its unique TTPs. This concept is referred to as TTP.
Let's gradually move towards our topic. CSOC APT Detection.
To detect an attack, we should first identify our attack surface/vectors and pinpoint the maximum efficient log sources we can extract from these areas. What does this mean? Let's evaluate with an example.
For attacks originating from the web, we need to obtain IIS or Apache logs. Is that enough? No, of course not. For better efficiency, we also require WAF logs. While we can detect attacks from logs obtained from IIS or Apache, we cannot see any actions taken against the attack (Drop/deny/permit/allow). For this purpose, WAF logs will serve our needs.
Once the logs are acquired, there are parts such as identifying critical log sources, parsing, etc., that are not included in the topic for now. We've securely acquired the logs; now it's time to write rules. In this article, we'll focus on a compromised system. For instance, we can study the techniques used by APT39 when communicating with C2 and develop rules to identify them.
Note: I intend to proceed with detectable behaviors and writable rules. This is not specifically about APT39 but will use them in many examples.
T1071 — Application Layer Protocol
T1102 — Web Service
T1090 — Proxy
T1036 — Masquerading
APT39 communicated with its C2 server via HTTP, DNS, legitimate app/process names, and proxies (usually infected hosts). As an alternative method, they uploaded victim machine data to Dropbox and then downloaded it to the C2 server.
Different hacker groups such as APT12, APT28, and APT37 have used trusted platforms like WordPress, Google Drive, and Twitter to send data to their C2. It's genuinely challenging to detect. For a security analyst, considering these situations as risky is quite challenging. Analyzing the network traffic flow and content might provide a stronger approach in this regard.
For the following information, DLP, IPS, Firewall, and DNS logs are the necessary log sources we require at the moment. To detect the C2 server, outbound traffic should be inspected. The transmitted data and its size (Bytes IN/Out) can provide information about detection, but this might not be sufficient when dealing with APTs. Additionally, the destination address should be thoroughly analyzed using intelligence sources.
Even if the traffic is dropped, if the destination address is suspicious, the system might still be compromised.
a) The whois information of the communication domain should be examined. Is the registration date recent? If so, there might be no intelligence. Every newly registered domain is suspicious. If the domain is random, it might be attempting to bypass security devices using the DGA technique (e.g., domains like qyshzm.com).
DGA: Domain Generation Algorithms that programmatically generate a list of domain names used to communicate with C2. For example, having domains like ysyds.com, xmsja.ru, instagramhhsds.me on an IP address.
Fast fluxing: Opposite of DGA, constantly changes IP addresses while keeping the domain name constant. As these IP addresses belong to compromised hosts, they appear reliable and work as proxies.
Why are these significant? A newly generated domain using DGA won't have intelligence sources and will bypass these sources. The other benefit is, even if you block x.com through the firewall, using the DGA method, they can communicate with the C2 using xy.com. Can you escape by just blocking the IP address of the domain? No.
That's why the fast fluxing technique exists. Let's assume you've blocked the IP addresses used by x.com and xy.com. In the fast fluxing technique, IP addresses constantly change while domain names remain the same. Therefore, both domain names and IP addresses should be blocked together. This might be a maximum solution, but it might not be sufficient.
b) Rarely used record types in DNS logs should be examined (e.g., TXT, NULL, CNAME).
Threat groups have predominantly used TXT and CNAME on DNS to send data to C2. Geolocation could also be distinctive here (e.g., Yemen, Malaysia, etc.). The proliferation of TLDs has helped attackers bypass security devices. TLDs are commonly used to evade threat intelligence. Commonly used TLDs are suspicious and should be thoroughly investigated (.biz, .xyz, .me, and similar).
c) Review DNS resolution errors in DNS logs but filter out many NXDOMAIN (domain does not exist) response codes to reduce false positives. If you receive numerous DNS resolution errors, a server or host should be thoroughly examined. This response might occur because the malicious domain cannot access it for malicious purposes.
d) Multiple DNS requests from a single host to multiple sub-domains of a single domain are suspicious. (Query intelligence from the domain primarily in these cases)
e) A significant number of denied outbound traffics are crucial. This means, 'The security policy has encountered numerous intrusion attempts.' A host is attempting to communicate with an unauthorized address. Suspicious!
f) Destination ports are essential to monitor if they are not ordinary (e.g., destination 33987 port number). Because this requires extra effort. Why would a regular user do something like this? Potentially suspicious ports should be identified (e.g., njRAT uses port 5552).
g) Some may attempt to send data to the C2 server using tools like ZXproxy and ZXPortMap. For instance, APT28, after hacking NATO employees, used the Georgian military mail server as a proxy to transmit data. Therefore, the exit of data from the local environment followed the sequence below:
Compromised NATO employee hosts >> Georgian military mail server >> C2 server
When examining the traffic through SIEM, you might observe communication with a reliable L2R server. This is a very ordinary activity. It's almost impossible to distinguish, but we often need to maintain our perspective at this level. Do you have any hacking news related to Georgian military servers? You can interpret this based on the incident you encountered.
h) To communicate with the C2 server, they can use masquerading techniques to adopt a
legitimate file name or file path. APT39 mimicked a legitimate McAfee file, mfevtps.exe, and used a malicious software disguised as Mozilla Firefox, named mfevtpse.exe, via the proxy method for C2 communication. Outbound connecting files should be examined if they exhibit abnormal traffic. A file or process that normally shouldn't generate external traffic could pose a threat. Or if the connected address is suspicious...
I) Sending a ZIP file would make this situation even more suspicious. If there's DLP, it will already detect this situation.
To be continued
Comments