How Ziften Continuous Endpoint Monitoring Deals With Indicators Of Compromise Carbanak 3 – Chuck Leaver

Presented By Chuck Leaver And Written By Dr Al Hartmann


Part 3 in a 3 part series


Below are excerpts of Indicators of Compromise (IoC) from the technical reports on the Anunak/Carbanak APT attacks, with talk about their discovery by the Ziften continuous endpoint monitoring system. The Ziften system has a focus on generic indicators of compromise that have corresponded for decades of hacker attacks and cyber security experience. IoC’s can be identified for any operating system such as Linux, OS X and Windows. Particular indicators of compromise also exist that show C2 infrastructure or specific attack code instances, however these are not used long term and not typically used once again in fresh attacks. There are billions of these artifacts in the security world with thousands being added every day. Generic IoC’s are embedded for the supported os by the Ziften security analytics, and the particular IoC’s are utilized by the Ziften Knowledge Cloud from memberships to a number of market risk feeds and watch lists that aggregate these. These both have value and will help in the triangulation of attack activity.

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).

Remark: Not actually a IoC, critical exposed vulnerabilities are a major hacker manipulation and is a big warning that increases the threat rating (and the SIEM priority) for the end point, particularly if other indicators are also present. These vulnerabilities are signs of lazy patch management and vulnerability lifecycle management which results in a weakened cyber defense position.

2. Geographies That Are Suspect

Excerpt: Command and Control (C2) servers situated in China have been identified in this project.

Remark: The geolocation of endpoint network touches and scoring by geography both contribute to the danger score that drives up the SIEM priority. There are valid situations for having contact with Chinese servers, and some companies might have sites situated in China, but this ought to be verified with spatial and temporal checking of anomalies. IP address and domain information must be included with a resulting SIEM alarm so that SOC triage can be carried out quickly.

3. Binaries That Are New

Excerpt: Once the remote code execution vulnerability is successfully manipulated, it installs Carbanak on the victim’s system.

Remark: Any new binaries are constantly suspicious, however not all of them must raise alarms. The metadata of images should be examined to see if there is a pattern, for example a brand-new app or a new version of an existing app from an existing supplier on a most likely file path for that vendor etc. Hackers will try to spoof apps that are whitelisted, so signing data can be compared in addition to size, size of the file and filepath etc to filter out obvious instances.

4. Unusual Or Sensitive Filepaths

Excerpt: Carbanak copies itself into “% system32% com” with the name “svchost.exe” with the file attributes: system, hidden and read-only.

Comment: Any writing into the System32 filepath is suspicious as it is a delicate system folder, so it undergoes analysis by checking abnormalities right away. A traditional anomaly would be svchost.exe, which is an essential system process image, in the uncommon area the com subdirectory.

5. New Autostarts Or Services

Excerpt: To ensure that Carbanak has autorun privileges the malware creates a brand-new service.

Comment: Any autostart or brand-new service is common with malware and is always examined by the analytics. Anything low prevalence would be suspicious. If examining the image hash against market watchlists leads to an unknown quantity to most of the anti-virus engines this will raise suspicions.

6. Low Prevalence File In High Prevalence Directory

Excerpt: Carbanak develops a file with a random name and a.bin extension in %COMMON_APPDATA% Mozilla where it stores commands to be carried out.

Remark: This is a traditional example of “one of these things is not like the other” that is easy for the security analytics to inspect (continuous monitoring environment). And this IoC is completely generic, has absolutely nothing to do with which filename or which directory is produced. Even though the technical security report notes it as a particular IoC, 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

Remark: Any suspect signer will be treated as suspicious. One case was where a signer supplies a suspect anonymous gmail email address, which does not inspire confidence, and the risk rating will be elevated for this image. In other cases no email address is supplied. Signers can be quickly listed and a Pareto analysis performed, to recognize the more versus less trusted signers. If a less trusted signer is found in a more sensitive folder then this is really suspicious.

8. Remote Administration Tools

Excerpt: There appears to be a choice for the Ammyy Admin remote administration tool for remote control believed that the hackers used this remote administration tool because it is commonly whitelisted in the victims’ environments as a result of being used regularly by administrators.

Remark: Remote admin tools (RAT) always raise suspicions, even if they are whitelisted by the company. Checking of anomalies would occur to recognize whether temporally or spatially each new remote admin tool is consistent. RAT’s undergo abuse. Hackers will always prefer to use the RAT’s of an organization so that they can prevent detection, so they need to not be provided access each time just because they are whitelisted.

9. Patterns Of Remote Login

Excerpt: Logs for these tools show that they were accessed from two different IPs, most likely utilized by the attackers, and located in Ukraine and France.

Comment: Always suspect remote logins, because all hackers are presumed to be remote. They are also used a lot with insider attacks, as the insider does not wish to be recognized by the system. Remote addresses and time pattern anomalies would be checked, and this ought to expose low prevalence use (relative to peer systems) plus any suspect geography.

10. Atypical IT Tools

Excerpt: We have actually also found traces of many different tools used by the attackers inside the victim ´ s network to gain control of extra systems, such as Metasploit, PsExec or Mimikatz.

Comment: Being sensitive apps, IT tools should always be examined for abnormalities, since lots of hackers subvert them for malicious purposes. It is possible that Metasploit could be utilized by a penetration tester or vulnerability scientist, but circumstances of this would be uncommon. This is a prime example where an uncommon observation report for the vetting of security staff would result in restorative action. It also highlights the problem where blanket whitelisting does not help in the identification of suspicious activity.