FireEye recently released a large number of indicators to help security teams identify their set of stolen Red Team tools. The RSA IR team commends FireEye for releasing this information to the security community, to allow all of us to help better defend against attackers who might seek to abuse these tools.
While most security teams will be incorporating these indicators into their existing security detection infrastructure (https://community.rsa.com/community/products/netwitness/blog/2020/12/09/fireeye-breach-implementing-countermeasures-in-rsa-netwitness), the RSA IR team normally takes a different approach to identify threats, which is primarily focused on tool/attack behaviors instead of signatures.
The RSA IR team has long been a proponent of behavioral analysis, which in our experience help us continuously identify both known and unknown attackers. This analysis philosophy, coupled with an “Assume Breach” mindset, is at the core of Threat Hunting and Incident Response within our team. Therefore, in this blog we will look at the behavioral aspects of the tools related to the FireEye release of indicators, and provide some examples of how identifying suspicious behaviors can help identify attacker activity, without the need for specific signatures.
Adversaries attempt to dump credentials to obtain account login and credentials, normally in the form of a hash or a clear text password, from the operating system and software.
SafetyKatz is an open source tool, which is available on GitHub (https://github.com/GhostPack/SafetyKatz). It is an all inclusive LSASS password dumper. This tool will dump the memory of the LSASS process using the Windows API call, MiniDumpWriteDump, and then load a custom C# implementation of Mimikatz to pull information from the dump, subsequently deleting the LSASS dump file when it is finished.
Executing SafetyKatz on a host with NetWitness Endpoint, we can easily detect its usage via a number of indicators. From the screenshot below, we can see that NetWitness flags the file as malicious, based of RSA's file reputation lookup service. Furthermore, the agent generates metadata based of the behavior of the tool itself under the Behaviors of Compromise meta key, which is an unsigned application opening LSASS. Depending on how an attacker may use this tool, other generic behaviors, such as the location and name of the binary itself, can be part of the overall characteristics of this behavior. These behaviors should immediately stand out as suspicious and warrant further triage:
To configure file reputation lookup, please refer to the following article: Context Hub: Configure Live Connect as a Data Source.
Executing the YARA rule from FireEye against the SafetyKatz binary, we can see that we indeed get a hit:
This tool is similar to SafetyKatz in that it is open source (https://github.com/hoangprod/AndrewSpecial), and will create a dump file of the LSASS.exe process using the MiniDumpWriteDump Windows API call. It will not however, extract credentials from the dump created. From the screenshot below, you can see that the tool exhibits the same behaviour as SafetyKatz, in that it is an unsigned tool opening LSASS. This tool again, running from a unexpected directory should stand out to defenders and warrant further triage:
Executing the YARA rule from FireEye against the AndrewSpecial binary, we can see that we indeed get a hit:
The important takeaway from these two tools, is that simply relying on atomic indicators of compromise, such as signatures, which the attacker can easily avert, is not a scalable easily maintained solution to detection. Instead, relying on the behaviours of these tools and how they have to operate in order to achieve their goal, such as opening a handle to LSASS in order to dump the memory, we can easily detect the seldom used and unknown tools.
Discovery consists of techniques an adversary may use to gain knowledge about the system and internal network. These techniques help adversaries observe the environment and orient themselves before deciding how to act.
In addition to NetWitness Endpoint flagging the tool's presence as malicious, we can still detect unwarranted tools being introduced into an environment through daily hunting. NetWitness Endpoint has two meta keys called dir.path.src and dir.path.dst that will group files running out of certain directories. We can then as defenders pivot into interesting locations and look for suspicious executables running from suspicious locations with ease:
For example, pivoting on dir.path.dst = 'uncommon' - we can look at all the files being executed out of uncommon directories. From the below we can see that cmd.exe was used to launch a suspect binary from C:\PerfLogs\ named, shp.exe:
This is a useful tactic to find malicious tools, as typically (but not always), attackers do not run their tools from the users Desktop.
Sometimes it is not about having a signature to detect the tool and how it works, but rather to find the tool based on anomalous characteristics of its execution, such as it running from a suspect location. Discovery tools are constantly evolving and adapting to evade detection, meaning signatures for them can easily become obsolete.
Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it.
Part of the FireEye indicators included references to Impacket tools (https://github.com/SecureAuthCorp/impacket) such as smbexec. As part of our Profiling Attackers Series, two of these tools that aid in lateral movement have already been covered in previous RSA blogs, which we recommend you read:
|smbexec||Detecting Lateral Movement in RSA NetWitness: Smbexec|
|wmiexec||Detecting Lateral Movement in RSA NetWitness: WMI|
However, it is worth mentioning a new feature in NetWitness that has been added since the release of those blogs. Namely, NetWitness has now introduced host-based information matched to the Packet data. If you have both NetWitness Packets and NetWitness Endpoint, as of 11.5.1, packet sessions will be enriched with the associated host based data, giving defenders the full picture from both the endpoint perspective as well as the network perspective:
To configure and learn more see the following article: https://community.rsa.com/docs/DOC-86987#Host
In order for an attacker to achieve their end goal, they are going to have to laterally move to other endpoints. While custom tools such as Impacket have been developed to make this task easier, as shown by the FireEye breach, the tools can be obfuscated to easily evade signatures. Whereas, as shown in the blog posts, relying on the behaviors of the tools we can ensure that we will always identify their usage.
Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.
This is an exploit for CVE-2020-1472, a.k.a. Zerologon. This tool exploits a cryptographic vulnerability in Netlogon to achieve authentication bypass. Ultimately, this allows for an attacker to reset the machine account of a target Domain Controller, leading to Domain Admin compromise.
One of our content developers William Motley, updated the DCERPC Lua parser when this vulnerability was initially announced to detect this behavior on the network. This parser will generate the meta value, zerologon attempt, under the ioc meta key when the behavior is observed. Prior to the update of the DCERPC parser, the ZeroLogon CVE has previously been covered by Halim Abouzeid, and is a recommended read to show how these exploits can still be detected without signatures:
|ZeroLogon||Domain Controller Takeover with Zerologon, from Compromise to Detection|
This is a custom tool developed by FireEye, and is freely available on GitHub (https://github.com/fireeye/SharPersist). This tool makes it incredibly quick and easy to setup persistence on an endpoint. We ran some of the mechanisms it offers on one of our victim hosts to see what meta values NetWitness creates.
One of the switches for the tool adds persistence via the registry using the \CurrentVersion\Run key. The following query can be used to identify any application persisting itself in this manner:
action = 'createregistryvalue' && ec.subject = 'runkey'
Autoruns (i.e. persistent files) also have their own section for each endpoint. These can be reviewed in order to identify potentially malicious autoruns based on various characteristics of the file, such as signed/not signed, frequency in the network, location, etc. The screenshot below shows a malicious registry autorun:
The screenshot below shows a malicious service:
The screenshot below shows a malicious task:
You should also be collecting the Windows logs from your endpoints as well, as these can be used to help identify malicious autoruns. Querying events where reference.id = '7045' will show newly created services, these should be analysed to find potentially malicious services, from the below screenshot we can see that a suspect service was created referencing a binary in a suspect location:
Executing the YARA rules from FireEye against the SharPersist binary, we can see that we indeed get a hit:
Again we have shown that regardless of the tools being used, the persistence mechanisms can all be detected based on the behavior of the service/task/autorun as well as the characteristics of the file behind the persistence mechanism.
Command and Control
Command and Control consists of techniques that adversaries may use to communicate with systems under their control within a victim network. Adversaries commonly attempt to mimic normal, expected traffic to avoid detection. There are many ways an adversary can establish command and control with various levels of stealth depending on the victim’s network structure and defenses.
We executed one of the tools identified by FireEye as, DShell (backdoor), to see what what indicators we could use to identify its usage within an environment. What we noticed was that the tool adds itself and its C2's as an exception in the firewall using netsh.exe; this gets identified by NetWitness Endpoint with the two meta values shown below:
It should be noted that in general, any C2 type file will exhibit additional behaviors once it is used to do something useful, such as upload/download files, enumerate processes/services/file system, etc. Here, we are simply executing it to observe its initial behavioral footprint.
Navigating to the events view we can see that the binary was located in C:\PerfLogs\ and named Program.exe. It spawned cmd.exe and passed the netsh argument to it:
This is one tactic for many C2's, njRAT for example will do the same, albeit with a slightly different command. For example, the njRAT execution on ANY.RUN exhibiting the same behavior can be found at the following link: https://app.any.run/tasks/7d09956b-6843-45f6-8bbf-5a5880999961/. This again shows that utilising the behaviour of the tool would allow defenders to identify its usage and others without having to rely on signatures.
Executing the YARA rule from FireEye against the DShell binary, we can see that we indeed get a hit:
Cobalt Strike / Meterpreter / DNS Tunnelling
A number of the signatures released by FireEye reference Cobalt Strike, Meterpreter and DNS tunnelling. While we have covered these tools in prior posts, some of the network detection discussed in them cannot be directly applied to the tools released by FireEye. This is because tools such as Cobalt Strike allow for malleable profiles that can easily be altered. With that being said, the hunting principles outlined in our Profiling Attackers Series whereby we hunt for these tools based on behaviours, shows that they can still be detected via proactive hunting:
We have discussed hunting for C2's a number of times in other blog posts. Due to their flexibility and ability to dynamically change, it is seldom useful to employ signatures for their detection. Instead, identifying suspect characteristics associated with the communication can make them stand out even when they attempt to blend in:
The key takeaway from this post is while signatures are an easy way to detect known malicious tools/files, they are not ideal for today's network defense from the more sophisticated attacks. The intrusion into FireEye's network itself demonstrates this fact. The RSA IR team's philosophy is to assume a breach, and use daily hunting to identify abnormal behaviors in your network. We also always encourage our clients to invest in hunters who use our toolset to "patrol" the network both from the packet and endpoint perspectives. The sole reliance on signatures and alerts generated by them will only protect you from the known attacks. Signatures can be typically easily averted and become stale rather quickly. On the other hand, behaviors are more generic and fairly static, and will always allow you to detect what the signatures would have detected as well as malware not covered by signatures.