This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
  • NetWitness Community
  • Blog
  • FireEye Breach

FireEye Breach

RSAIncidentResp
Employee RSAIncidentResp
Employee
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Email to a Friend
  • Printer Friendly Page
  • Report Inappropriate Content
‎2020-12-12 11:47 AM

  • Introduction
  • Credential Dumping
  • SafetyKatz
  • AndrewSpecial
  • Closing Notes
  • Discovery
  • SharpHound
  • Closing Notes
  • Lateral Movement
  • Impacket
  • Closing Notes
  • Persistence
  • ZeroLogon
  • SharPersist
  • Closing Notes
  • Command and Control
  • DShell
  • Cobalt Strike / Meterpreter / DNS Tunnelling
  • Closing Notes
  • Conclusion

Introduction

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.

 

Credential Dumping

 
OS Credential Dumping, Technique T1003 - Enterprise | MITRE ATT&CK®  

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

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:

pastedImage_4.png

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:

pastedImage_1.png

 

 

AndrewSpecial

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:   

pastedImage_18.png

 

Executing the YARA rule from FireEye against the AndrewSpecial binary, we can see that we indeed get a hit:

pastedImage_3.png

 

 

Closing Notes

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

 
Discovery, Tactic TA0007 - Enterprise | MITRE ATT&CK® 

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.

 

SharpHound

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:

 

pastedImage_5.png

 

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:

pastedImage_6.png

 

This is a useful tactic to find malicious tools, as typically (but not always), attackers do not run their tools from the users Desktop.

 

Closing Notes

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

 
Lateral Movement, Tactic TA0008 - Enterprise | MITRE ATT&CK® 

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.

 

Impacket

Part of the FireEye indicators included references to Impacket tools (https://github.com/SecureAuthCorp/impacket) such as smbexec. As part of our https://community.rsa.com/community/products/netwitness/blog/2020/04/01/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:

 

Tool Article
smbexec https://community.rsa.com/community/products/netwitness/blog/2019/04/17/detecting-lateral-movement-in-rsa-netwitness-smbexec 
wmiexec https://community.rsa.com/community/products/netwitness/blog/2019/04/09/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:

 

pastedImage_1.png

To configure and learn more see the following article: https://community.rsa.com/docs/DOC-86987#Host

                                                                 

 

Closing Notes

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

 
Persistence, Tactic TA0003 - Enterprise | MITRE ATT&CK® 

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.

 

ZeroLogon

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:

Tool Article
ZeroLogon https://community.rsa.com/community/products/netwitness/blog/2020/09/30/domain-controller-takeover-with-zerologon-from-compromise-to-detection 

 

 

SharPersist

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'

                         

 

pastedImage_2.png

 

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:

 

pastedImage_1.png

 

The screenshot below shows a malicious service:

 

pastedImage_3.png

 

The screenshot below shows a malicious task:

 

pastedImage_2.png

 

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:

pastedImage_4.png

 

Executing the YARA rules from FireEye against the SharPersist binary, we can see that we indeed get a hit:

pastedImage_1.png

 

Closing Notes

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, Tactic TA0011 - Enterprise | MITRE ATT&CK® 

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.

 

DShell

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:

 

pastedImage_2.png

 

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:

 

pastedImage_5.png

 

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:

pastedImage_2.png

 

 

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 https://community.rsa.com/community/products/netwitness/blog/2020/04/01/profiling-attackers-series whereby we hunt for these tools based on behaviours, shows that they can still be detected via proactive hunting:

 

Tool Article
Cobalt Strike Detecting Command and Control in RSA NetWitness: Cobalt Strike
Metasploit Detecting Command and Control in RSA NetWitness: Metasploit
DNS2TCP Detecting DNS tunneling in RSA NetWitness: DNS2TCP
Weasel Using RSA NetWitness to Detect C&C: WEASEL

 

 

Closing Notes

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:

 

pastedImage_5.png

 

 

Conclusion

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. 

  • Behavioral Analytics
  • fireeye
  • NetWitness
  • NW
  • NWP
  • RSA NetWitness
  • RSA NetWitness Platform
  • threat hunting
4 Likes
Share

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Related Articles

FireEye Breach - Beyond the signatures

DustinLee
DustinLee Employee
1 Likes
0 Comments

FireEye Breach - Implementing Countermeasures in RSA NetWitness

SeanEnnis1
SeanEnnis1 New Contributor
1 Likes
0 Comments
Latest Articles
  • Agent Tesla: The Information Stealer
  • Threat Analysis: Detecting “Follina” (CVE-2022-30190) RCE Vulnerability with Netwitness Endpoint
  • Introducing NetWitness Vision XDR
  • Introducing NetWitness Platform XDR v12.0
  • Atlassian Confluence Zero-day Vulnerability (0-Zero) CVE-2022-26134: What You Need To Know
  • ‘Follina’ CVE-2022-30190 0-Day: What You Need To Know
  • CVE-2022-1388: BIG-IP iControl REST RCE Vulnerability
  • Ragnar Locker Ransomware: The Rampage Continues…
  • Ransomware Email Attacks: Beware of BazarLoader
  • Detecting Impacket with Netwitness Endpoint
Labels
  • Announcements 54
  • Events 2
  • Features 9
  • Integrations 6
  • Resources 57
  • Tutorials 21
  • Use Cases 21
  • Videos 116
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.