Attack Graph Response to US CERT AA22-074A: Russia-based actors disabling multi-factor authentication (MFA)  

AttackIQ has released a new attack graph to emulate Russia-based threat actors as they exploit multi-factor authentication protocols to disable MFA. This blog describes the scenarios we have included in the new attack graph to emulate the adversary and then, to inform a purple team construct for cyberdefense operations, it provides detection and mitigation recommendations that you can use to improve your security program effectiveness. Read on for more. Read More

Russian State-Sponsored Cyber Actors Gain Network Access by Exploiting Default Multifactor Authentication Protocols and “PrintNightmare” Vulnerability 

On March 15, 2022, the U.S. Federal Bureau of Investigation (FBI) and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) published a joint Cybersecurity Advisory (CSA) detailing tactics used by Russian threat actors during the compromise of a non-governmental organization (NGO). The alert indicates that as early as May 2021, the threat actors leveraged a misconfigured account and enrolled a new device for multi-factor authentication (MFA) to gain initial access to the victim’s network. The PrintNightmare (CVE-2021-34527) vulnerability was then exploited to gain system privileges and ultimately the Windows hosts file was modified to redirect the victim’s MFA solution to localhost causing it to be unreachable and “fail open” disabling MFA for all accounts. 

After disabling MFA, the Russia-based actors collected and used legitimate credentials to access the victim’s virtual private network (VPN). Once connected to the network, the intruder obtained additional domain account credentials, and established Remote Desktop (RDP) sessions to other Windows domain controllers. With this additional access, the threat actors moved laterally to the victim’s cloud and email accounts to access and exfiltrate data. 

The CISA alert reported that the actors mostly leveraged internal Windows utilities including ping, regedit, and ntdsutil to perform the activity. Many of the steps mentioned in the alert match activity previous US-CERT reports published as AA22-011A and AA22-047A. 

AttackIQ recommends that customers review the mitigation recommendations made by US-CERT to enforce and review MFA policies, ensure inactive accounts are universally disabled, and patch all systems for vulnerabilities knowingly exploited in the wild. From there, it is important to validate your security program performance against the adversary to ensure that you are prepared.  

To that end, AttackIQ has developed a new attack graph to emulate the adversarial activity described in the latest US-CERT alert and to test their security program’s performance against key tactics employed by Russian government-affiliated threat actors. 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 your security posture to prevent changes from being made to a system’s hosts file to stop similar MFA attacks from being successful. 
  3. Continuously validate your detection and prevention pipelines against a realistic multi-stage attack emulation that triggers security control preventions. 

This attack graph emulates the attack covered in the US-CERT alert by starting with procedural implementations of the techniques to include brute force attempts to gain initial access, privilege escalation, execution, defense evasion, lateral movement, a Windows hosts file modification that disables the victim’s MFA policies, and finally a script that collects email to stage for exfiltration.  

In this blog, we walk you through the tactics, techniques, and procedures employed by the adversary in the attack, show you which scenarios we have included in the attack graph to emulate the adversary’s techniques and procedures and then, to inform a purple team construct, we provide detection and mitigation recommendations that you can employ to improve your security posture. Our goal is for these detection and mitigation recommendations to help you get ahead of the techniques and procedures we know the adversary is likely to employ. Once you run the attack graph to assess your security posture, you can take these steps to improve your security effectiveness.  

 Let’s begin. The attack graph emulates the attacker through the following logical steps: 

Scenario 1: Brute Force Password Guessing (T1110.001): The first step utilized by the Russia-based threat actors was to conduct a brute force password guessing attack that was successful due to a victim account with a simple, predictable password. The AIQ scenario uses the top 25 RDP usernames and passwords identified in a leak of 1.3 million Windows RDP credentials published to an underground marketplace. The scenario needs to be configured with a host to target with the brute force attempts. 

1a. Detection Processes: 

  • If possible, use a SIEM product to correlate centralized logs and detect unusual login activity on your network. In the case of this US-CERT report, remote login attempts are of interest. Some parameters for your SIEM detections are as follows:  
  • Source Type: WinEventLog:Security 
  • Logon Type: 10 
  • Event Codes: 4624, 4625 

An example of a basic Splunk Brute Force Detection: 

index=*  sourcetype=“win*security” Logon_type=10 user=* user!=“” 

| stats count(eval(action=“success”)) as successes count(eval(action=“failure”)) as failures by user, ComputerName, src 

| where successes>0 AND failures>50 

1b. Mitigation Policies:  

  • Ensure Account Lockouts are set and not waived 
  • As you operationalize CTI, incorporate known password leaks if possible 
  • Conduct Regular Active Directory security assessments 
  • Ensure MFA policies and configurations are set to remain enabled for inactive accounts that have not yet been disabled 
  • Regularly audit for inactive accounts and ensure inactive accounts are disabled; consider adding this to an offboarding process 

Scenario 2: Remote System Discovery (T1018): Once an initial foothold has been established, a threat actor is going to look for additional hosts they can access. This scenario uses a combination of Windows tools to find connected hosts using net view and then ping to validate they can be reached by the asset. 

2a. Detection Processes: 

  • If possible, use SIEM, EDR or ProcMon tools to consume logs to monitor usage of interpreters using net.exe and ping commands in unusual ways indicating host discovery enumeration.  
  • Cmd.exe or Powershell.exe running commands such as “net view /all” from any unexpected user accounts 
  • Nmap usage in the environment with the –sP flag indicating a ping sweep 
  • Cmd.exe or Powershell.exe with commands containing (“for /L” AND “do ping”) indicating a possible ping sweep script 
  • Check Microsoft-Windows-DNS-Server-Service for Event ID: 6001 from any unusual servers or IPs for unauthorized DNS Zone Transfers. 

2b. Mitigation Policies:  

  • Ensure DNS Zone Transfers are restricted to a whitelist of known hosts 
  • Restrict the availability of cmd.exe and powershell.exe to necessary users (admin groups) 
  • Restrict usage of network diagnostic tools such as nmap.exe to necessary users (admin groups) using Application Control tools while considering adding detections for these types of tools in your SIEM. 

Scenario 3: Exploitation for Privilege Escalation (T1068): PrintNightmare is a critical Windows vulnerability discovered in June 2021 that allows for remote code execution and privilege escalation by exploiting a flaw in the Print Spooler service running on Windows systems, including high value targets like domain controllers. The victim had not patched their host and the actors were able to exploit this vulnerability to gain system privileges. AttackIQ emulates this behavior by testing if the asset is vulnerable by executing a PowerShell script capable of exploiting the vulnerability.
 

3a. Detection Processes  

  • If possible, utilize a SIEM product to monitor which servers currently have the PrintSpooler enabled, and if not needed on the server, disable.  

An example query to search for this is as follows:  

index=<your index> sourcetype=WinHostMon source=service  

DisplayName=”Print Spooler”  

| stats values(DisplayName) as  

Disp_Name,values(StartMode) as Start_mode,values(Started) as Started,values(State) as State by host
 

To be alerted on a possible exploitation of PrintNightmare, search your SIEM for: 

  • Sourcetype: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational 
  • Event ID: 7 
  • ImageLoaded = *\\Windows\\System32\\spool\\drivers\\64\\* 
  • ImageLoaded = *.dll
     

An example of a Splunk query for this behavior is as follows 

sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational OR  

source=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=7 Image =”*\\spoolsv.exe” ImageLoaded=”*\\Windows\\System32\\spool\\drivers\\x64\\*” 

 ImageLoaded = “*.dll” | stats dc(ImageLoaded) as countImgloaded values(ImageLoaded) 

 as ImgLoaded count min(_time) as firstTime max(_time) as lastTime by Image Computer 

 EventCode | where countImgloaded >= 3 

(Please note: a count of images loaded is 3 or more as two .dlls are loaded into by default: unidrv.dll and kernelbase.dll. The third being the malicious .dll)
 

3b. Mitigation Policies: 

  • Make sure you have the PrintNightmare Patch here 
  • If you are unsure of current PrintSpooler patch status, disable PrintSpooler on all devices where it is not necessary  
  • Verify the following registry key does not exist, or set to 0: 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsNT\Printers\PointAndPrint 

Value: NoWarningNoElevationOnInstall 

Data Type: REG_DWORD 

Data: 0 or not defined  

(Note: Having NoWarningNoElevationOnInstall set to 1 makes your system vulnerable by design.) 

Scenario 4: Disable or Modify System Firewall (T1562.004): The US-CERT alert makes references to the threat actor leveraging remote desktop to access the domain controllers and their usage of regedit to modify the system registry. Previous reporting from the US-CERT identified registry commands used by Russian threat actors targeting the energy and critical infrastructure sectors. This step is emulated in the attack graph by running reg.exe from the command line to open port 3389 used for Remote Desktop connections on the asset.

4a. Detection Processes
If possible, utilize an EDR product to create a preventative detection any time reg.exe is utilized by a non-authorized user. A detection should have the following attributes: 

  • Process Name == cmd.exe OR powershell.exe  
  • Command Line Contains (reg add AND FirewallPolicy AND Enabled: Remote Desktop) 
  • User NOT IN <list of authorized cmd.exe, powershell.exe, and reg.exe users>

4b. Mitigation Policies 

  • Ensure that cmd.exe, powershell.exe, and reg.exe are only able to be run by authorized users with a need to access it, e.g., admin groups. 

Scenario 5: Remote Desktop Protocol (T1021.001): The actor utilizes Remote Desktop (RDP) to gain full hands-on keyboard and mouse control over their target. RDP is commonly used by system administrators, and the actor’s use of legitimate credentials helps them blend into normal everyday activity. The scenario needs to be configured with a remote target and can be configured to use a separate account for authentication.

5a. Detection Processes 

  • Use a SIEM product or monitor windows logs to view RDP logins (logon type 10) from IPs/Devices that are not expected to be utilizing RDP. 
  • Microsoft Azure Rare RDP Connections Detection 

5b. Mitigation Policies 

  • Ensure Group Policy enforces only authorized users to initiate RDP connections to specified machines.  

Scenario 6: Disable or Modify Tools (T1562.001): The actors were able to make a simple modification to the Windows hosts file that redirected the victim’s multifactor authentication system to localhost causing it be unreachable and fail open. The attack graph emulates this behavior by attempting to make a similar modification to the hosts file but using a non-existent domain to prevent serious disruption. Any modification to the hosts file would be indicative that an attack could redirect any internal asset to itself.

6a. Detection Processes 

  • If possible, utilize an EDR or Application Control product to monitor the integrity of /etc/hosts files. Often, attackers will echo data over to the /etc/hosts file on windows devices to reroute traffic. In this case, the threat actor is interested in re-routing MFA traffic to the local host, in hopes of causing the MFA product to “fail open.” An EDR Detection should have the following attributes:
    Process Name == Cmd.exe OR Powershell.exe
    Command Line Contains (echo AND 127.0.0.1 AND /etc/hosts) OR (echo AND 127.0.0.1 AND /etc/hosts AND duosecurity.com)  
    Username != <expected users to modify /etc/hosts file> 

6b. Mitigation Policies 

  • Ensure that the /etc/hosts file is only writeable by system/administrative users  

Scenario 7: Local Email Collection (T1114.001): Once access is fully established, the actor will move to accomplish their final objectives. The alert identifies email data as one of the targets for this attack and our final step in our attack graph performs a similar activity. The asset is searched for any local Outlook email files using a PowerShell script.

7a. Detection Processes 

  • If possible, utilize an EDR product to monitor Powershell usage collecting .pst or .ost files in the \users directory. Attributes for these detections are as follows:
    Process Name: Powershell.exe
    Command Line Contains (Get-ChildItem AND (.pst OR .ost) ) 

7b. Mitigation Policies 

  • Ensure only authorized users can run interpreters such as powershell.exe or cmd.exe
    If possible, enable the detection above to prevent execution once observed. There should be no legitimate reason an end user would need to query .pst and .ost files.  

In addition to what is covered by the attack graph, there is an additional technique the Russia-based threat actors are leveraging that allows them to retrieve a copy of the entire Active Directory database. Security teams can easily extend this attack graph with a simple clone operation and the insertion of a final step that requires it to be executed on a domain controller asset. 

Scenario 8 (additional step): Dump Active Directory Databases (T1003.003): One of the many end goals of the threat actor is to obtain a copy of the Active Directory database so that it may be attacked offline. Russia-based actors have been observed dumping the NTDS.dit database from a domain controller once administrative access has been achieved. This scenario needs to be executed on a Domain Controller asset. 

8a. Detection Processes: 

  • Implement detection analytics against: 

Ntds.dit file creation  

Sigma Rule for Suspicious Process Patterns (NTDS.Dit Exfiltration)   

Suspicious Process Patterns NTDS.DIT Exfil  

EDR Keys to search:  

  • Process Name == (NTDSDump.exe OR NTDSDumpEx.exe)  
  • Command Line Contains (ntds.dll AND system.hiv) Or (NTDSgrab.ps1 OR *ac\ I\ ntds*) AND *create\)  

NTDS Dump with NTDSUtil (LOLBAS): 

EDR Keys to search: 

  • Process Name == cmd.exe OR Powershell.exe  
  • Command line Contains (“ntdsutil” AND “ifm” AND “create full” AND “NTDS”) 

8b. Mitigation Policies:  

  • Ensure permissions are placed for only authorized users to utilize the Active Directory diagnostic tool NTDSUtil.exe to prevent chance of unauthorized copying of ntds.dit.  

 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 Russia-based threat actors. 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.