Security teams are faced with a reality: sometimes, adversaries are going to compromise an environment. A user may click on a link in a phishing email that leads to the download of malware that’s not caught by antivirus software. A threat actor may exploit an unpatched vulnerability in an internet-facing appliance that was not on an organization’s asset register. Compromised credentials could lead to an attacker taking over a highly privileged account, lending access to a domain controller. However, not all is immediately lost. Once an adversary gains access, there may be some time before the attackers begin to laterally move and the threat can be detected and removed. This dwell time can vary in length, but this gap offers an opportunity for threat hunting.
The premise of threat hunting is looking for clues of compromise and finding anomalous behaviors that could be signs. Security tools have long employed indicators of compromise (IoCs) as a means of detecting infections. IoCs can include hashes of malware samples, malicious domains associated with malware downloads and IP addresses. These types of indicators, however, are usually short lived. Adversaries know these types of files and infrastructure will be quickly flagged and blocked, so they change them frequently. It’s trivial for malware developers to change a few bytes of the code to create a piece of malware with a different hash that has not yet been flagged as malicious. Malware distributors routinely change domains and hosting URLs to new ones that have not been linked to malicious behavior. It’s much more difficult, however, for threat actors to change the behaviors linked to intrusions. These tactics, techniques and procedures (TTPs) are at the top of the Pyramid of Pain, which is the model of indicators that illustrates the relative difficulty threat actors have in changing them.
In this post, we’ll explain how to use Intel 471’s HUNTER threat hunting platform to detect behaviors linked to a pernicious Russian cybercriminal group with a long history of distributing banking malware and ransomware. HUNTER contains pre-written threat hunting queries for a variety of security information and event management (SIEM), logging and endpoint security platforms. These queries are intended to let security teams jump immediately into threat hunting and spend less time on writing queries and more on investigations and remediation.
The Adversary: Evil Corp
One of the most well-known financially motivated Russian cybercriminal groups is Evil Corp aka Indrik Spider, Manatee Tempest. In the early 2010s, the group was intricately involved in developing and distributing the Bugat and Cridex banking trojans (also known as Geodo and Feodo), which later evolved into Dridex. These malware applications were the front-line soldiers for several years in intense waves of banking malware. The malware applications captured login credentials and had sophisticated capabilities to trick users into divulging information by injecting new fields into legitimate web pages that asked for additional personal information. On Dec. 5, 2019, the U.S. Justice Department announced charges against members of Evil Corp, which it accused of stealing more than US $100 million. Two leading members, Russian nationals Maksim Yakubets and Igor Turashev, were indicted by U.S. prosecutors for bank fraud, conspiracy, computer hacking and wire fraud. Yakubets and Turashev, along with 15 other individuals associated with the group and the group itself, were sanctioned. Before the indictments and sanctions, Evil Corp had moved on from banking malware schemes as improving security defenses made it less profitable than in the early days. Along with other financially motivated threat actor groups, Evil Corp moved into ransomware around 2017 and began using Dridex as a “loader,” or a piece of malware used to install other malware. The advantage of using Dridex as a loader is that it was already an established, large botnet. Security researchers began to see Evil Corp install the BitPaymer (also known as FriedEx and DoppelPaymer) ransomware, which had code similarities to Dridex. Other ransomware that has been linked to the group include WastedLocker, Hades and Phoenixlocker. The security vendor CrowdStrike writes that Evil Corp went quiet after the sanctions but then emerged with new TTPs in an attempt to evade them. Hades and Phoenixlocker appeared after the sanctions, and both of those ransomware strains appeared to take steps to mask links to Evil Corp to make victims more likely to pay ransoms.
Dridex IoCs
Samples of Dridex have been collected for at least a decade since the malware first appeared. Below is a table of hashes for samples of Dridex going back to 2022:
Hash-based detection is still used by many endpoint security products, but its limitations are well known. A piece of malware may only have a particular hash for a short period of time. Malware authors often use crypters to encrypt or manipulate malware to evade detection. Crypter services are often sold on underground markets. The use of crypters means that a detection of a particular piece of malware using its hash value is only as good as a point in time. A version of Dridex with a different hash could be installed on a machine the next day and go undetected. A scan using hashes is a binary outcome: either the malware is there, or it isn’t.
Threat hunting looks at behaviors associated with the malicious activity. Threat actor groups often undertake the same behaviors once they’ve compromised a system, so if the malware is missed — which it often is — the behaviors may be a clue. Over the last decade, MITRE Corp. has developed the ATT&CK framework, which is a knowledge base of adversary behaviors that can be used to classify how individual threat groups work.
As seen above, ATT&CK displays that Evil Corp has used the PowerShell scripting language, the Windows command shell and JavaScript in its activities. What is captured in the MITRE framework is not just the tools but the actual commands and the intent of those commands. While adversaries have control over the hash value of a sample of malware and can change it over and over, they don’t have control over the parameters of the commands they need to issue to execute these techniques and eventually achieve their goals. Those are facets of infrastructure that an adversary can leverage but does not create. This is where threat hunting for behaviors and TTPs outshines methods focused on the lower part of the Pyramid of Pain.
To illustrate, we will use attack technique T1070.011 — indicator removal — and a sub-technique that clears Windows event logs. This technique is used to hide evidence of an intrusion.
MITRE’s documentation shows that these commands can be used to clear event logs if a person has administrator privileges:
If one of these commands turns up in logging and it’s not associated with a legitimate, authorized system change, it could mean that attackers are trying to hide their tracks. Given this is great intelligence about a known adversary’s behaviors, how do we operationalize this in HUNTER?
Our threat hunting content developers have created hunt packages that enable investigators to search for this activity in their SIEMs, EDR/XDRs or other logging systems. This hunt package is titled Wevtutil Cleared Log. This particular threat hunt supports Carbon Black Investigate, Carbon Black Response, CrowdStrike LogScale, Elastic, Microsoft Defender, Microsoft Sentinel, Palo Alto XDR, QRadar Query, SentinelOne, Splunk and Trend Micro Vision One. After the supported tools, there is the query logic:
This represents the bare bones of the query and captures the field-value relationship and represents the conditions that must be present for the hunt to be successful. In the process path field, we can see it is focused on Windows Event Utility in either the System32 or the SysWOW64 directories. The hunt also looks for command-line arguments related to deleting logs.
If the hunt is successful, does this mean the system has been compromised? Not necessarily. Since these behaviors could be undertaken by authorized users, it is up to the security team’s threat hunters and incident responders to figure out if this activity is truly malicious. As an example, here’s this threat hunt run in Splunk using the Windows System Monitor (Sysmon) service as the logging source.
In the above screenshot, the query for Sysmon is the second one down. We copy the query and then run a search in Splunk:
As seen in the screenshot above, this query has surfaced activity. We see that both the clear-log and set-log commands have been invoked. At this point, it is recommended to double check that the query logic is sound and that the values are in the correct fields.
Looking at the process path, it appears that the query logic appears correct since the results match the query.
To emphasize again, this doesn’t mean that this activity is malicious. The ball is in your court to take the next investigative steps. There are many ways to start, including investigating the process path that spawned this activity, looking at different process IDs and more. For more information on HUNTER and threat hunting, please contact Intel 471. Happy hunting.
