Attack Graph Response to US-CERT AA22-083A: Historical Russia-based Actors Targeting the Energy Sector 

Last week the Department of Justice unsealed two indictments charging four Russian nationals, working on behalf of the Russian government, with conducting computer intrusions targeting the global energy sector between 2012 and 2018. Simultaneously, the U.S. Federal Bureau of Investigation (FBI), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and the U.S. Department of Energy (DOE) released a joint Cybersecurity Advisory (CSA) providing an overview of the tactics, techniques, and procedures (TTPs) used in those attacks.

While the intrusions are historical, the TTPs employed by the Russia-based threat actors are still timely and relevant to today’s threat landscape. Our new attack graph, “[US-CERT AA22-083A] – TTPs of HAVEX Malware (2014-04) Used by Russian FSB Center 16 Cyber Operators Against Energy Sector 2012-2014” emulates some of the key TTPs used in the first phase of the campaign, which began with a supply chain attack that compromised software updates for ICS/SCADA devices and controllers used by power and energy companies in 135 countries.

A majority of the techniques reported under the HAVEX campaign are focused on the Discovery techniques that occurred after the software updates, poisoned with HAVEX, landed on target/victim systems. This automated discovery leveraged native Windows tools and capabilities like WMI and PowerShell, allowing the actors to live off the land and blend in with normal system administrator activity as they sought to expand access through lateral movement.

It is important to validate your security program performance against these types of native techniques to ensure that you are prepared. To that end, AttackIQ has released a new attack graph to emulate the adversarial activity of HAVEX malware from April, 2014, at the end of Center 16’s Phase 1 campaign referenced and described in the latest US-CERT alert. By using this new attack graph in the AttackIQ Security Optimization Platform, security teams will be able to:

1. Evaluate security control performance against native Windows utilities being used to conduct malicious activity.
2. Assess security posture for the techniques that have been well documented and long in use by threat actors.
3. Continuously validate detection and prevention pipelines against actor activity that attempts to blend in with normal everyday usage

Figure 1.0: AttackIQ attack graph response to US-CERT AA22-083A, HAVEX malware targeting the energy sector. 

Detection and Mitigation Recommendations

This attack graph emulates an attack using the behaviors exhibited by the Russian threat actors during their campaign against the global energy sector. The emulation starts with the delivery of the HAVEX malware and moves on to their attempts for code injection and persistence using the registry. A series of discovery techniques are completed to conduct reconnaissance on the host and victim’s network before finishing with data collection of email artifacts and encrypted exfiltration. Specifically, the attack graph takes the following steps:

Scenario 1: Spearphishing Link (T1566.002): The first step in our attack graph simulates what happens when a user follows a link and attempts to download a malicious payload to disk. One of the original trojanized ICS software installers are downloaded from a remote site over HTTP and then attempted to be written to disk. These are the atomic tests designed to test a security control’s ability in preventing a well-known malicious file from being received or saved to disk. Additionally, the final HAVEX DLL payload is also attempted to be written to disk.

1a. Detection Process 

For EDR tools, attempt to build detections looking for Microsoft Office products such as Word, Excel, and PowerPoint invoking interpreters, as this is a sign a malicious macro may have been executed from a Microsoft document:

• Parent Process Name == (winword.exe OR excel.exe OR powerpnt.exe)
• Process Name == (cmd.exe or powershell.exe)

In addition, you may add additional command line behavior indicating downloading / execution of a fileless attack:

• Parent Process Name == (winword.exe OR excel.exe OR powerpnt.exe)
• Process Name == (cmd.exe or powershell.exe)
• Command Line CONTAINS (“DownloadString” AND (“IEX” OR “Invoke-Expression))

Lastly, check for registry modifications to the following registry keys which could indicate a change that would enable macro execution:

• HKEY_CURRENT_USER\Software\Microsoft\office\<OfficeVersion>\Word\security\VbaWarnings
• HKEY_CURRENT_USER\Software\Microsoft\office\<OfficeVersion>\Excel\security\VbaWarnings
• HKEY_CURRENT_USER\Software\Microsoft\office\<OfficeVersion>\PowerPoint\security\VbaWarnings

Public Sigma rule for detecting via SIEM: Suspicious Double Extension

1b. Mitigation Policies 

• Disable Office Macros except in the specific apps where they are required
• Utilize Anti-Phishing / Email Filtering software
• Enforce user training on email and phishing awareness

Scenario 2: Dynamic-link Library Injection (T1055.001): HAVEX injects itself into the running explorer.exe process. The actor uses this specific process to help evade detection via activity logging as all actions would appear to originate from the legitimate Explorer process. The scenario is initially configured to attempt injection of a custom AttackIQ DLL into the AttackIQ process, but advanced customers can change the configuration to attempt the same injection into explorer.exe.

2a. Detection Process 

Using an EDR or SIEM product ingesting windows logs, attempt to identify instances where explorer.exe is loading in unsigned DLLs. Although this may be false positive prone, it will alert when explorer.exe is seen loading an abnormal DLL which could be an indicator of HAVEX.

Public Sigma rule for detecting via SIEM:

title: Unsigned Image Loaded Into explorer Process
id: 3BCDE80B-D74F-4E53-B35B-D24BDB790B75
status: Experimental
description: Loading unsigned image (DLL, EXE) into Explorer process
author: Jackson Wells
references:
- https://www.slideshare.net/heirhabarov/hunting-for-credentials-dumping-in-windows-environment
date: 2022/03/28
modified: 2022/03/28
logsource:
category: image_load
product: windows
detection:
selection:
Image|endswith: '\explorer.exe'
Signed: 'false'
condition: selection
level: medium
tags:
- attack.credential_access
- attack.t1003.001

2b. Mitigation Policies

If possible, utilize EDR/EPP Products to block types of process injections based on sequences of behavior that occur during the injection process. https://attack.mitre.org/techniques/T1055/001/

Additional documentation on proper mitigations to prevent DLL preloading attacks seen here: https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1

Scenario 3: Registry Run Keys (T1547.001): The threat actors used common ‘CurrentVersion\Run’ registry keys to ensure HAVEX would continue to start up after every restart. Windows leverages many different registry keys for this purpose and the scenario tests two of the most commonly used keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

3a. Detection Process 

Using a SIEM or EDR Platform to see modifications to the Run and RunOnce keys will alert when unauthorized users or software makes modifications to “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run”

Process name: reg.exe
Command Line Contains (“ADD” AND “Microsoft\Windows\CurrentVersion\Run” AND “/V”)
Optionally you can include a search for users NOT IN to lower the chance of false positives.

3b. Mitigation Policies 

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features. For best protection, ensure group policy is set to only allow specific users with need to utilize reg.exe as well as have anti-virus enabled to statically and dynamically scan files for possible malicious use of the registry

Scenario 4: System Owner / User Discovery (T1033): The first local discovery step executed by the actors in this attack graph is to get details on the running users. This behavior is emulated using a command shell to run the “query user” command, which retrieves a list of Remote Desktop Sessions running on the host, and the “whoami” command to get the running user of the malicious process.

4a. Detection Process 

Although commands such as “query user” and “whoami” are utilized as administrators frequently, there should still be alerts in place when unexpected users are running these commands as they could be a sign of possible user enumeration and system discovery.

With an EDR, if possible, look for the following details:

Process Name == (cmd.exe OR powershell.exe)
Command Line CONTAINS (“Query User” OR “whoami”)
User != [<list of expected administrators to be issuing these commands>]

Additionally, “whoami” and “priv” is a command that should be monitored closely for typical end users. This command will show any permissions for token usage available and may give indicators if the user is exploitable to a Token Impersonation Attack.

4b. Mitigation Policies 

Ensure that Group Policy enforces only authorized users / administrators to be able to run cmd.exe or powershell.exe. These interpreters can be limited to lower privileged or unneeded users to prevent enumeration or abuse.

Scenario 5: System Information Discovery (T1082): Threat actors commonly want to understand more about the host they have compromised. Understanding what version of the operating system is running, how much memory is installed, or how much disk space is available, will indicate if the actors have managed to access a server or client host. This scenario executes the native Windows command “systeminfo” through the command shell to receive detailed information about the computer.

5a. Detection Process 

Process Name == (cmd.exe OR powershell.exe)
Command Line CONTAINS “systeminfo”
User NOT IN User != [<list of expected administrators to be issuing these commands>]


5b. Mitigation Policies

Ensure that Group Policy enforces only authorized users / administrators to be able to run cmd.exe or powershell.exe. These interpreters can be limited to lower privileged or unneeded users to prevent enumeration or abuse.

Scenario 6: Process Discovery (T1057): A threat actor would want to understand what software is running on a specific host to either identify security software that may inhibit their actions or to illuminate targets of interest running ICS/SCADA applications. This is another scenario that uses a native Windows tool to achieve that end. Tasklist is executed as a command process and the results are saved to a temporary location.

6a. Detection Process 

Using an EDR or SIEM product, use the following parameters for identifying possible enumeration of system processes:

Process Name == (“cmd.exe” OR “powershell.exe”)
Command Line CONTAINS (“Tasklist” AND “/FO”)
User = [<list of expected administrators to be issuing these commands>]

6b. Mitigation Policies 

Ensure application whitelisting is in place to allow only permitted users/administrators the right to run utility binaries such as cmd.exe, powershell.exe, tasklist.exe, and WMIC.exe.

Scenario 7: File and Directory Discovery (T1083): HAVEX performs many initial discovery and profiling activities on the host. The threat actors were interested in collecting information about available drives and files located in the Desktop, My Documents, and Program Files directories. This behavior is emulated by using the native Windows ‘dir’ command to list all files in those directories and record the results in a temporary text file.

7a. Detection Process 

File and Directory discovery typically utilizes living off the land binaries such as dir or ls to discover interesting directories of files that could be of use for the attacker. There is no excellent continuous way of monitoring this activity, but many actors use automated scripts to perform this activity to expedite the process. Look for excessive “dir” and “type” commands on a windows machine invoked possibly from a batch or VBS file which could indicate possible mass enumeration of file system.

7b. Mitigation Policies 

Ensure sensitive files and directories have proper permissions assigned. Preventing non-need to know users access to configuration files or other sensitive user/system information could greatly reduce risk of malicious enumeration.

Scenario 8: System Network Configuration Discovery (T1016): The HAVEX actors would want to understand how the existing host’s network is configured to assist with future lateral movement. These details help the actor plan their future network scanning activity or identify which network shares and domain controllers could be targeted next. Continuing to live off the land, this scenario executes the following commands and collects the following data:

• Routing information: route print
• IP information: ipconfig /all
• Connected Domain Controller: nltest /DSGETDC:
• Network Shares: net use
• ARP information: arp -a

8a. Detection Process 

Using an EDR or SIEM tool, you can monitor usage of windows network discovery tools. Keep in mind, these are binaries used rather frequently. we strongly recommend querying these commands with an “exclude user” option to limit false positives if that option is available in your EDR/SIEM product.

Process Name == (“cmd.exe” OR “powershell.exe”)
Command Line CONTAINS (“route print” OR “ipconfig /all” OR “nltest /DSGETDC” OR “net use” OR “arp -a”)
User NOT IN [<list of expected administrators to be issuing these commands>]

8b. Mitigation Policies 

Ensure application whitelisting is in place to allow only permitted users/administrators the right to run utility binaries such as cmd.exe, powershell.exe, route.exe, ipconfig.exe, nltest.exe, net.exe, and arp.exe. Although some of these may be used on a day-to-day basis, only authorized users should have the right to run these executables to prevent misuse.

Scenario 9: Remote System Discovery (T1018): Once the actor has collected what it needs from its initial entry point, they would shift their sights to identifying what other systems could be contacted for lateral movement. In this scenario, the “net view” command is executed and if a remote host is identified, a connection attempt is made.

9a. Detection Process 

Using an EDR or SIEM tool, you can monitor usage of windows network discovery tools. Keep in mind, these are binaries used rather frequently. we strongly recommend querying these commands with an “exclude user” option to limit false positives if that option is available in your EDR/SIEM product.

Process Name == (“cmd.exe” OR “powershell.exe”)
Command Line CONTAINS (“net view”)
User NOT IN [<list of expected administrators to be issuing these commands>]

9b. Mitigation Policies 

Ensure application whitelisting is in place to allow only permitted users/administrators the right to run utility binaries such as cmd.exe, powershell.exe, route.exe, ipconfig.exe, nltest.exe, net.exe, and arp.exe. Although some of these may be used on a day-to-day basis, only authorized users should have the right to run these executables to prevent misuse.

Scenario 10: Credentials from Web Browsers (T1555.003): The HAVEX actors used a 3rd party tool to extract passwords from the infected browser. These credentials could include the username and passwords used to access internal resources or control ICS systems through web interfaces. This AttackIQ scenario uses a more modern tool, LaZagne, to perform credential harvesting from a selection of common Windows web browsers.

10a. Detection Process 

Tools such as Lazangne.exe and other password harvesting software look for browser directories for stored passwords. Looking for modifications (file copies) of locations such as “%APPDATA%\Local\Google\Chrome\User Data\Default\Login Data” would indicate that some process has taken action to copy or otherwise touch the location where browsers store encrypted passwords.

Other than monitoring sensitive directories such as the one listed above, tools such as Lazangne.exe will have the following attributes when ran:

Process Name = (“cmd.exe” or “powershell.exe”)
Command Line CONTAINS (“browsers” AND “–oJ” AND “–output”)

10b. Mitigation Policies 

Ensure you configure browser settings to NOT store passwords on your behalf as the method is not secure. We recommend utilizing a password vault service to store and handle passwords.

Additionally, utilize Anti-Virus product policies to look for browser-based attacks as well as any behavioral indicator engines to alert on possible browser password enumeration.

Scenario 11: Local Email Collection (T1114.001): The Russian-based threat actors were interested in collecting local Outlook Address Book files. They could leverage this information for future phishing attacks to target other employees at the same company or their external connections. Having access to address book content would allow the actor to tailor their targeting based on job titles and locations provided by  the contact records. The scenario in this attack graph takes it a little further by collecting all offline mail content on the host. A PowerShell script is used to search for PST and OST files located in the User or Program Files directories.

11a. Detection Process 

Malicious actors will attempt to pull email files (.PST and .OST) under Program Files, Users, and/or UsersProfile directories. Powershell scripts are the most common way these searches are performed, output to look for is as follows:

Process Name == (“powershell.exe” OR “cmd.exe”)
Command Line CONTAINS (“Get-ChildItem –Path” AND (“Users” OR “Programfiles” OR UserProfile”) AND (“.PST” OR “.OST”))

11b. Mitigation Policies 

If possible, enforce encryption on these file locations. Use of encryption provides an added layer of security to sensitive information sent over email. Encryption using public key cryptography requires the adversary to obtain the private certificate along with an encryption key to decrypt messages. (https://attack.mitre.org/techniques/T1114/001/)

Ensure application whitelisting is in place to allow only permitted users/administrators the right to run utility binaries such as cmd.exe and powershell.exe.

Scenario 12: Automated Collection (T1119): Threat actors will commonly leverage file extension filters to automate data collection. By collecting everything that matches their rules instead of manually reviewing content during the intrusion, they are reducing the amount of time needed to find files of interest. There is a tradeoff though, as the actor will need to balance between speed and noise from mass collection activity. This scenario searches for all document file types and then collects them into a zip file stored in a temporary directory.

12a. Detection Process 

With automated collection, you should expect a wide array of files to be collected and zipped into a convenient folder for the attacker to utilize. Attempting to look for 100 or more of the files below being modified within 1 minute is a sign of some bulk automation that may need investigation if it was performed by an unexcepted user or time.

“.doc, .xps, .xls, .ppt, .pps, .wps, .wpd, .ods, .odt, .lwp, .jtd, .pdf, .zip, .rar, .docx, .url, .xlsx, .pptx, .ppsx, .pst, .ost, psw, pass, login, admin, sifr, sifer, vpn, .jpg, .txt, *.lnk”

12b. Mitigation Policies 

Encryption and off-system storage of sensitive information may be one way to mitigate collection of files but may not stop an adversary from acquiring the information if an intrusion persists over an extended period of time and the adversary is able to discover and access the data through other means. Strong passwords should be used on certain encrypted documents that use them to prevent offline cracking through Brute Force techniques. (https://attack.mitre.org/techniques/T1114/001/)

Additionally, utilizing a File Integrity Monitoring (FIM), Data Loss Prevention (DLP), or Endpoint Detection and Response (EDR) product with FIM or DLP may have policy settings to alert when these actions occur.

Scenario 13: Exfiltration Over Symmetric Encrypted Non-C2 Protocol (T1048.001): HAVEX used a combination of compression and encryption algorithms to encrypt and decrypt data sent to and from their command-and-control servers. The additional layers of obfuscation make it more difficult for detection as the commands and stolen data will not be visible as plain text even if advanced defensive techniques were utilized like SSL decryption. This scenario will exfiltrate an encrypted file containing personal data over HTTP, simulating the transfer of confidential data using layered encryption.

13b. Mitigation Policies

Enforce proxies and use dedicated servers for services such as DNS and only allow those systems to communicate over respective ports/protocols, instead of all systems within a network. (https://attack.mitre.org/techniques/T1048/001/)

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary command and control infrastructure and malware can be used to mitigate activity at the network level. (https://attack.mitre.org/techniques/T1048/001/)

Follow best practices for network firewall configurations to allow only necessary ports and traffic to enter and exit the network (https://attack.mitre.org/techniques/T1048/001/)

Conclusion

In summary, this attack graph will evaluate security and incident response processes and support the improvement of your security control posture against a range of threat actors who leverage native Windows tools to conduct their operations. With data generated from continuous testing and use of this attack graph, you can focus your teams on achieving key security outcomes, adjust your security controls, and work to elevate your total security program effectiveness against a known and dangerous threat.

AttackIQ stands at the ready to help security teams implement this attack graph and other aspects of the AttackIQ Security Optimization Platform, including through our co-managed security service, AttackIQ Vanguard.