Eset Endpoint Security Personal Firewall

Presented By Charles Leaver And Written By Dr Al Hartmann

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

endpoint security download mac     endpoint security comparison