Investigating an Infected Windows Active Directory | TryHackMe Recovering Active Directory

We covered the process of incident response and the steps taken to investigate and recover an infected Windows active directory system. We used Powerview and Eventviewer to investigate the actions taken by the attacker such as users created/modified, group policy changes and other events such as date and time. . This was part of TryHackMe recovering active directory.

Initial Incident Response Steps

When faced with an infected Windows Active Directory machine, my first priority is to preserve evidence. This means avoiding any changes to the machine that could alter hashes, checksums, or volatile memory.

Instead of performing live analysis on the infected machine, I immediately take a backup of the machine. All subsequent analysis is then performed on a cloned copy of this backup. For a Windows Server machine, I use the Windows Server Local Backup service. I navigate through the backup wizard, choosing options like “full server backup” or “custom” for bare metal recovery if external storage is available.

After backing up, it’s crucial to isolate the machine. I disconnect the infected machine from the network and internet to prevent any communication with command and control (C2) servers.

Analysis on the Cloned Machine

I then proceed with the analysis on the cloned copy, often mounted on another machine using VMware.

Using PowerView (PowerShell script)

I use PowerView for enumeration to identify attacker actions and changes made to users, permissions, and Group Policy Objects (GPOs). Here are some of the commands I execute:

• Import-Module .\powerview.ps1 (after navigating to the script’s directory)
• Get-NetDomainController: To get information about the domain controller.
• Commands to list logged-on users (to find potential attacker-created persistence accounts) and to get active sessions on the domain controller.
• Get-NetComputer | Select-Object -ExpandProperty Name: To list computers in the domain. I noted there were 11 machines.
• Get-ADUser -Filter {Enabled -eq $true -and Created -gt "10 April 2022"} -Properties lastLogon, sAMAccountName, Created: To list users created after a specific date. This helped me find an “evil_guy” account.
• Get-DomainUser | ? {$_.sAMAccountName -eq "evil_guy"} | Select-Object mail: To filter domain users for “evil_guy” and display their email.
• Get-ADUser -Filter {Enabled -eq $true -and lastLogon -gt "01 December 2022"} -Properties lastLogon, sAMAccountName: To list users who logged on after a specific date.

Using Windows Event Viewer

Next, I turn to the Event Viewer to track security events, GPO modifications, user creation/addition, and user authentication. Some key Event IDs I look for include:

• 4720: User account created. This helped me confirm the “evil_guy” account creation.
• 4756: A member was removed from a security-enabled universal group.
• 4757: A member was added to a security-enabled universal group. (I had to be careful not to mix this up with 4756).
• Event IDs related to Group Policy changes, such as audit policy changes, authentication policy changes, and domain policy changes related to password policy.

I always remember that even if changes are logged under a legitimate administrator account, it doesn’t mean they weren’t performed by an attacker who compromised that account.

Cleanup and Recovery

The final phase involves cleanup and recovery:

• Restore from a Trusted Backup: I restore the system from a backup taken before the compromise was detected.
• Reset Passwords: I reset passwords for critical users, especially administrators and service accounts (like the Kerberos krbtgt account to prevent Silver Ticket attacks). I also identify members of privileged groups (e.g., Domain Admins) and reset their passwords. A command to force a computer to change its password is Reset-ComputerMachinePassword.
• Remove Unauthorized Users: I delete any users created by the attacker.
• Malware Scan: I perform a thorough scan of the machine.
• Log Forwarding: I forward all logs to a SIEM solution (e.g., Splunk) for further analysis and monitoring.
• Address Specific Vulnerabilities: I consider vulnerabilities like Silver Ticket Abuse (abusing Kerberos service tickets) and DC Sync Attack (where attackers impersonate a domain controller, often possible if an attacker compromises an account with “Replicating Directory Changes” or “Replicating Directory Changes All” permissions, or the SeImpersonatePrivilege).
• Synchronize Time: I ensure time is synchronized across all network devices for accurate log correlation.
• Lessons Learned & Policy: The final step in any incident response plan is “Lessons Learned.” If a cybersecurity policy and disaster recovery plan don’t exist, I make sure to prepare them.

Q&A Section (from the TryHackMe room)

I also reviewed some of the questions and answers from the TryHackMe room:

• Types of backups from Windows Server Backup: One-time and Incremental.
• Launching Windows Server Backup utility via Run dialog: wbadmin.msc.
• Isolating infected infrastructure: Yes, it’s good practice.
• Number of machines found with PowerView: 11.
• Windows utility for tracking events: Windows Event Viewer.
• Email for “evil_guy”: hack@crypto.
• Total users logged on after a specific date (in the example): 1 (“evil_guy”).

Room Answers

Video Walkthrough