Threat Thursday - NetWire RAT

Happy Fall everyone! I’m Christopher Peacock, the newest unicorn to join the herd as an Adversary Emulation - Detection Engineer. For my first #ThreatThursday, I will cover the recent NetWire RAT report from BlackBerry’s ThreatVector Blog. The focus is on the emulation and detection opportunities of the threat to help organizations measure and defend against the threat’s behaviors. As always, our emulation plan is shared in our Community Threats Github. New this round are SIGMA rules for the NetWire RAT emulation.

Cyber Threat Intelligence

NetWire is malicious software that has been used  for nearly a decade by various nation states and criminal organizations. With various adversaries leveraging the tool, different Tactics, Techniques, and Procedures (TTPs) are found across intrusions. For a complete list of techniques, the MITRE ATT&CK® team compiled multiple threat groups into one listing of known techniques observed with NetWire. Today we will focus on the specific Cyber Threat Intelligence (CTI) from BlackBerry’s Blog.

Adversary Emulation Plan

This plan facilitates emulation of early Kill Chain phases up to Command & Control (C2), allowing defenders to focus on a few key detection opportunities before Actions on Objectives.

The first step of the emulation process drops  Host.exe, the malicious application used in persistence, to the %AppData%\Install\ directory. To ensure no interference with potential existing folders, we append “_NetWire_” to the folder name in our emulation. The directory structure and labeling is easily changed by the attacker(s), but the naming convention has been seen in multiple samples and could be part of a default configuration. Therefore, one may decide it is helpful to hunt for Host.exe in the %AppData%\Install\ directory. 

The following section in the emulation plan creates registry keys used for persistence. Registry persistence is a detection opportunity, and it is critical to emulate the technique to validate detection. 

Keys are set in

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKCU\Software\Netwire
  

The attacker(s) can change the naming convention to subvert monitoring, making it crucial to detect the persistent technique of leveraging registry run keys. This technique is further identified  in the detection section below.

After persistence, we emulate keylogging and data staging. The reported adversary stages RC4 encrypted log files that include stolen data, such as credentials or keystrokes, in a directory labeled %AppData%\Logs\ with the log files following a DD-MM-YYYY naming convention. This supplies organizations an opportunity to hunt for files that match the DD-MM-YYYY format located in the %AppData%\Logs\ directory.

Finally, Dynamic DNS (DDNS) Command & Control will be replicated before cleanup. . Organizations can set the Command & Control up to leverage a Dynamic DNS provider, but we replicate this with a nslookup command to save resources. Detecting DDNS C2 proves crucial in identifying threats as malware commonly uses Dynamic DNS.

Detect

Key Detection Opportunities

• Detect NetWire Registry Autorun Keys
• Detect NetWire’s commonly used path HKCU:\Software\Netwire
• Detect (Block) Dynamic DNS (DDNS)
  

Due to this Cyber Threat Intelligence (CTI) ending at the Command & Control (C2) phase of the Kill Chain, we are focusing on detection opportunities at the Installation and Command & Control phases and disrupting the adversary before Actions on Objectives. The Installation phase is covered by two SCYTHE developed SIGMA rules. Should the Installation phase be successful and Command & Control attempted, the attack should be thwarted by blocking and alerting on Dynamic DNS (DDNS). The following three subsections outline these detection opportunities.

Detect NetWire Registry Autorun Keys

One of the first detection opportunities is the registry run key used for persistence. The trojan sets a key labeled NetWire in ‘\software\Microsoft\Windows\CurrentVersion\Run’ with a value of C:\Users\<UserName>\AppData\Roaming\Install\Host.exe. To detect this activity, we recommend the SCYTHE developed SIGMA rule that looks for registry autorun keys set to \AppData\Roaming. The SIGMA rule may generate too many results to alert on, but organizations can tune the rule to alert on anomalous instances or utilize aggregated data from the rule for hunting. The “details|contains” parameter may be removed to conduct a broad hunt for suspicious autorun keys.  To leverage SIGMA rules you will need  to convert the generic rules to your security stack with a converter. We recommend leveraging unicode.io or the Sigmac Tool. Note that depending on how your data is tagged, you may have to implement data field mappings. We leveraged uncoder.io to convert the rule from SIGMA to Splunk and received the following true positive result in our detection lab. 

Detect NetWire’s Commonly Used Path HKCU:\Software\Netwire

SCYTHE has  developed a NetWire Registry SIGMA rule to detect a common registry location leveraged by the NetWire RAT. The organization should ensure its collection of  the appropriate registry events for this rule. If leveraging sysmon, the configuration may have to be updated with a target objecting to contain NetWire. It’s worth noting that the name-matching of this rule could be subverted by an attacker changing the name, but it appears to be a default or a commonly used setting. 

Detect Dynamic DNS (DDNS)

The third detection point we’d like to touch on is the use of Dynamic DNS (DDNS). Our emulation does not use dynamic DNS for Command & Control by default as it requires additional infrastructure outside of SCYTHE to set up. Instead we run a nslookup command to generate the necessary traffic for logging, detection, and controls validation. Best practice is to leverage your proxy, DNS solution, or firewall to block Dynamic DNS, such as the Dynamic DNS guidance mentioned in Palo Alto’s URL Filtering Category Recommendations or Cisco Umbrella’s Manage Security Settings guidance. Dynamic DNS should generate a network alert and host analysis should be conducted to determine causation.

Respond

If NetWire RAT is detected in the environment, the response team should determine the depth of the Kill Chain, collect artifacts, and answer the following questions:

Was the installation successful?

• What are the persistent mechanisms?

Is Command & Control (C2) successful?

Are there observations of Actions on Objectives (AOO)?

• If so, what are they?

What was the infection vector?

• How was it delivered?
• What exploitation led to installation?

Once it has been determined how deep the intrusion goes, containment, eradication, and recovery should begin.  After recovery, lessons learned should drive additional courses of action (COAs) to thwart the threat should it return, such as implementing additional security controls. As always, please follow your organization's response plan and evidence retention policies. We also recommend leveraging NIST SP 800-61 Rev. 2.

Considerations

First, we recommend organizations leverage application control. Antivirus (AV) solutions allow you to block applications based on risk score, and we recommend using a risk score threshold with an action of auto quarantine or block, if organizations cannot leverage a permit list for application control.

Other considerations include deploying the NetWire_RAT YARA Rule given in the Blackberry blog. Organizations should aim to keep antivirus up-to-date and audit the deployment to ensure it is appropriately checking in. Finally, if an organization can not detect Dynamic DNS, ProofPoint has a Duck DNS Emerging Threat Rule that may be deployed. It is worth noting that several different Dynamic DNS providers have been observed.

Conclusion

NetWire is a commodity malware commonly seen across different organizations and leveraged by various adversaries. It’s tough to say how each adversary will configure and use NetWire, but organizations should ensure they can detect some common techniques, including Registry Run Keys and Dynamic DNS as outlined in this post. The goal should be to detect, disrupt, and respond at the Installation and Command & Control (C2) phases. In that case, you can limit impact before the NetWire Trojan takes further Actions on Objectives, such as a human operator moving through a Windows Domain.

This Threat Thursday post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.

About the Author

Chris is an Adversary Emulation - Detection Engineer at SCYTHE, specializing in Purple Team Exercises and Detection Engineering. His previous experience includes multiple roles such as Cyber Threat Intelligence Analyst, Cyber Threat Hunter, Tier 3 SOC Analyst, Incident Responder, Cyber Security Consultant, and Purple Team Lead. He previously worked at Raytheon Intelligence & Space as well as General Dynamics Ordnance and Tactical Systems. Additionally, he has experience in multiple industries, including Energy, Finance, Healthcare, Technology, and Defense. Current certifications include GCTI, GCFA, GCED, eJPT, and CSIS.

About SCYTHE

SCYTHE provides an advanced attack emulation platform for the enterprise and cybersecurity consulting market. The SCYTHE platform enables Red, Blue, and Purple teams to build and emulate real-world adversarial campaigns in a matter of minutes. Customers are in turn enabled to validate the risk posture and exposure of their business and employees and the performance of enterprise security teams and existing security solutions. Based in Arlington, VA, the company is privately held and is funded by Gula Tech Adventures, Paladin Capital, Evolution Equity, and private industry investors.