Uncovering Anunak/Carbanak APT Indicators Of Compromise (IoCs) With Continuous Endpoint Monitoring
Presented By Charles Leaver And Written By Dr Al Hartmann
Part 3 in a 3 part series
Following are excerpts of IoCs from the technical reports linked above on the Anunak/Carbanak APT, with comments on their detection by continuous endpoint monitoring in the Ziften solution. At Ziften we strive to focus our analytics on generic indicators of compromise that have held true over decades of security industry experience with hacker attacks. Anywhere from a few dozen to a few hundred generic IoC’s can be identified for any particular operating system platform, such as Windows, OS X, or Linux. There are also specific indicators of compromise, sometimes referred to as artifacts, that identify very specific instances of attack code or C2 infrastructure, but that are not typically long-lived and not typically re-used by attackers in fresh new attacks. Across the security industry there are billions of such artifacts, with many thousands added daily. Ziften security analytics embed generic IoCs for supported OS platforms, and the Ziften Knowledge Cloud employs specific IoCs by subscribing to a variety of industry threat feeds and watch lists that aggregate these artifacts. Both approaches have value (as discussed below) and can help triangulate attack activity in victim organizations.
1. Exposed vulnerabilities
Excerpt: All observed cases used spear phishing emails with Microsoft Word 97 – 2003 (.doc) files attached or CPL files. The doc files exploit both Microsoft Office (CVE-2012-0158 and CVE-2013-3906) and Microsoft Word (CVE- 2014-1761).
Comment: While not technically an IoC, a critical exposed vulnerability (notorious for hacker exploitation) is a major red flag that elevates the risk score (and thence the SIEM priority) for the endpoint, especially when other indicators are present. Exposed critical vulnerabilities are organizational indicators of lax patch management and vulnerability lifecycle management, i.e. of a weak cyber defense posture.
2. Suspect geographies
Excerpt: Command and Control (C2) servers located in China have been identified in this campaign.
Comment: Geolocation of endpoint network contacts and scoring of geographies contributes to the endpoint risk score that drives SIEM alerting priority. Certainly there are valid reasons for contacting Chinese servers, and some enterprise sites may even be located in China, but that should be borne out by both temporal and spatial anomaly checking. Both domain and IP address information should be bundled with any resulting SIEM alert, for rapid SOC triage.
3. New binaries
Excerpt: Once the remote code execution vulnerability is successfully exploited, it installs Carbanak on the victim’s system.
Comment: New binaries are always suspect, but not each new binary cannot be escalated for SOC staff attention. Image metadata can be analyzed to see if it fits a pattern, such as a new version of an existing app or a new app from an existing vendor on a likely filepath for that vendor, etc. Attackers will try to spoof whitelisted apps, so again that can be compared based upon signing data, filepath, file size, etc. to filter out the more obvious cases.
4. Sensitive or unusual filepaths
Excerpt: Carbanak copies itself into “%system32%com” with the name “svchost.exe” with the file attributes: system, hidden and read-only.
Comment: System32 is a highly sensitive system directory, so writing into a filepath through System32 is immediately subject to scrutiny by anomaly checking. In this case the anomaly would be svchost.exe, a critical system process image, in an unusual location, the com subdirectory.
5. New services or autostarts
Excerpt: To ensure that Carbanak has autorun privileges the malware creates a new service.
Comment: A new service or autostart is a common part of malware installation and must be checked by the analytics. Being low prevalence would raise suspicion here. When the image hash is checked against industry watchlists and found largely unknown to most AV engines, that would raise suspicion further.
6. Low prevalence file in high prevalence directory
Excerpt: Carbanak creates a file with a random name and a .bin extension in %COMMON_APPDATA%Mozilla where it stores commands to be executed.
Comment: This is an excellent example of “one of these things is not like the other” that is trivial for security analytics to check (in a continuous monitoring environment). And this IoC is entirely generic, has nothing to do with which directory or which filename is created. So even though the original security report lists it as a specific IoC (i.e. an artifact), it is trivially genericized beyond Carabanak to future attacks.
7. Suspect signer
Excerpt: In order to render the malware less suspicious, the latest Carbanak samples are digitally signed
Comment: A suspect signer raises suspicion. In one case the signer provides a suspicious anonymous email address to a gmail account, hardly confidence inspiring, raises the risk score for this image. In another case no email is provided. It is easy to list signers, perform a Pareto analysis, and identify the more versus less trusted code signers. Less trusted signers in more sensitive directories is especially suspicious.
8. Remote administration tools
Excerpt: There appears to be a preference for the Ammyy Admin remote administration tool for remote control. It is believed that the attackers used this remote administration tool because it is commonly whitelisted in the victims’ environments as a result of being used regularly by administrators.
Comment: RAT tools are always suspect, even when whitelisted within the enterprise. Anomaly checking would be performed to see if spatially or temporally that each new instance of a RAT tool appears consistent. They are too subject to abuse. Attackers prefer to use an enterprise’s own RAT tools to avoid detection, so it is not possible to give them a pass in every instance, just because of whitelisting.
9. Remote login pattern
Excerpt: Logs for these tools indicate that they were accessed from two different IPs, probably used by the attackers, and located in Ukraine and France.
Comment: Remote logins are always suspect, simply because the attackers are presumed remote. Remote logins are also typically employed even with insider attacks, since it is too risky for an insider to be observed at a system they do not have responsibility for. The time pattern of logins and the remote addresses would also be subject to anomaly checking, which in this case would likely disclose low prevalence usage (relative to peer systems) plus the suspect geography of Ukraine.
10. Atypical IT tools
Excerpt: We have also found traces of many different tools used by the attackers inside the victim´s network to gain control of additional systems, such as Metasploit, PsExec or Mimikatz.
Comment: IT tools are sensitive apps that should always be anomaly checked, since many attackers subvert them to malicious purposes. Maybe a vulnerability researcher or penetration tester would employ Metasploit, but that would be quite rare even in IT. This is a good example of where surfacing an unusual observation for SOC vetting would quickly triage to either absolve or convict. It is also a good example of where blanket whitelisting is not helpful in identifying suspect activity.
Part 3 in a 3 part series
Following are excerpts of IoCs from the technical reports linked above on the Anunak/Carbanak APT, with comments on their detection by continuous endpoint monitoring in the Ziften solution. At Ziften we strive to focus our analytics on generic indicators of compromise that have held true over decades of security industry experience with hacker attacks. Anywhere from a few dozen to a few hundred generic IoC’s can be identified for any particular operating system platform, such as Windows, OS X, or Linux. There are also specific indicators of compromise, sometimes referred to as artifacts, that identify very specific instances of attack code or C2 infrastructure, but that are not typically long-lived and not typically re-used by attackers in fresh new attacks. Across the security industry there are billions of such artifacts, with many thousands added daily. Ziften security analytics embed generic IoCs for supported OS platforms, and the Ziften Knowledge Cloud employs specific IoCs by subscribing to a variety of industry threat feeds and watch lists that aggregate these artifacts. Both approaches have value (as discussed below) and can help triangulate attack activity in victim organizations.
1. Exposed vulnerabilities
Excerpt: All observed cases used spear phishing emails with Microsoft Word 97 – 2003 (.doc) files attached or CPL files. The doc files exploit both Microsoft Office (CVE-2012-0158 and CVE-2013-3906) and Microsoft Word (CVE- 2014-1761).
Comment: While not technically an IoC, a critical exposed vulnerability (notorious for hacker exploitation) is a major red flag that elevates the risk score (and thence the SIEM priority) for the endpoint, especially when other indicators are present. Exposed critical vulnerabilities are organizational indicators of lax patch management and vulnerability lifecycle management, i.e. of a weak cyber defense posture.
2. Suspect geographies
Excerpt: Command and Control (C2) servers located in China have been identified in this campaign.
Comment: Geolocation of endpoint network contacts and scoring of geographies contributes to the endpoint risk score that drives SIEM alerting priority. Certainly there are valid reasons for contacting Chinese servers, and some enterprise sites may even be located in China, but that should be borne out by both temporal and spatial anomaly checking. Both domain and IP address information should be bundled with any resulting SIEM alert, for rapid SOC triage.
3. New binaries
Excerpt: Once the remote code execution vulnerability is successfully exploited, it installs Carbanak on the victim’s system.
Comment: New binaries are always suspect, but not each new binary cannot be escalated for SOC staff attention. Image metadata can be analyzed to see if it fits a pattern, such as a new version of an existing app or a new app from an existing vendor on a likely filepath for that vendor, etc. Attackers will try to spoof whitelisted apps, so again that can be compared based upon signing data, filepath, file size, etc. to filter out the more obvious cases.
4. Sensitive or unusual filepaths
Excerpt: Carbanak copies itself into “%system32%com” with the name “svchost.exe” with the file attributes: system, hidden and read-only.
Comment: System32 is a highly sensitive system directory, so writing into a filepath through System32 is immediately subject to scrutiny by anomaly checking. In this case the anomaly would be svchost.exe, a critical system process image, in an unusual location, the com subdirectory.
5. New services or autostarts
Excerpt: To ensure that Carbanak has autorun privileges the malware creates a new service.
Comment: A new service or autostart is a common part of malware installation and must be checked by the analytics. Being low prevalence would raise suspicion here. When the image hash is checked against industry watchlists and found largely unknown to most AV engines, that would raise suspicion further.
6. Low prevalence file in high prevalence directory
Excerpt: Carbanak creates a file with a random name and a .bin extension in %COMMON_APPDATA%Mozilla where it stores commands to be executed.
Comment: This is an excellent example of “one of these things is not like the other” that is trivial for security analytics to check (in a continuous monitoring environment). And this IoC is entirely generic, has nothing to do with which directory or which filename is created. So even though the original security report lists it as a specific IoC (i.e. an artifact), it is trivially genericized beyond Carabanak to future attacks.
7. Suspect signer
Excerpt: In order to render the malware less suspicious, the latest Carbanak samples are digitally signed
Comment: A suspect signer raises suspicion. In one case the signer provides a suspicious anonymous email address to a gmail account, hardly confidence inspiring, raises the risk score for this image. In another case no email is provided. It is easy to list signers, perform a Pareto analysis, and identify the more versus less trusted code signers. Less trusted signers in more sensitive directories is especially suspicious.
8. Remote administration tools
Excerpt: There appears to be a preference for the Ammyy Admin remote administration tool for remote control. It is believed that the attackers used this remote administration tool because it is commonly whitelisted in the victims’ environments as a result of being used regularly by administrators.
Comment: RAT tools are always suspect, even when whitelisted within the enterprise. Anomaly checking would be performed to see if spatially or temporally that each new instance of a RAT tool appears consistent. They are too subject to abuse. Attackers prefer to use an enterprise’s own RAT tools to avoid detection, so it is not possible to give them a pass in every instance, just because of whitelisting.
9. Remote login pattern
Excerpt: Logs for these tools indicate that they were accessed from two different IPs, probably used by the attackers, and located in Ukraine and France.
Comment: Remote logins are always suspect, simply because the attackers are presumed remote. Remote logins are also typically employed even with insider attacks, since it is too risky for an insider to be observed at a system they do not have responsibility for. The time pattern of logins and the remote addresses would also be subject to anomaly checking, which in this case would likely disclose low prevalence usage (relative to peer systems) plus the suspect geography of Ukraine.
10. Atypical IT tools
Excerpt: We have also found traces of many different tools used by the attackers inside the victim´s network to gain control of additional systems, such as Metasploit, PsExec or Mimikatz.
Comment: IT tools are sensitive apps that should always be anomaly checked, since many attackers subvert them to malicious purposes. Maybe a vulnerability researcher or penetration tester would employ Metasploit, but that would be quite rare even in IT. This is a good example of where surfacing an unusual observation for SOC vetting would quickly triage to either absolve or convict. It is also a good example of where blanket whitelisting is not helpful in identifying suspect activity.