Lateral movement refers to the techniques that a cyber attacker uses, after gaining initial access, to move deeper into a network in search of sensitive data and other high-value assets. After entering the network, the attacker maintains ongoing access by moving through the environment and using multiple accounts. In this blog the explanation/ simulation of detection lateral Movement with Defender for Identity and monitoring with Azure Sentinel. 

what is Lateral Movement?

Typically, cyberattacks are launched against any accessible entity, such as a low-privileged user, and then quickly move laterally until the attacker gains access to valuable assets. Valuable assets can be related to domain administrators, sensitive accounts with high rights, sensitive data, or sensitive servers ( domain controllers). For the on-prem environment based on Domain Controllers – Defender for Identity is useful for getting more insights into the on-prem events and detect Lateral Movement.

In the simulation below the explanation of the kill chain and the protection features based on Microsoft components. In the below screenshots it is easy to simulate some of the attacks:

  1. Non-sensitive account opens e-mail or opens the attachment
  2. The user’s computer is compromised, the attacker has access to the computer.
  3. From the first compromised computer lateral movements takes time
  4. Privileged account compromised
  5. Domain compromise and attacks gained admin permissions

Sound difficult for an attacker, in the practice quite easy to run without any monitoring or credential protection. For example, when the Helpdesk employee sign-ins on the compromised device with management credentials for the management servers without any credential protection it is not too hard to get domain admin permissions.

Defender for Identity

Microsoft Defender for Identity is the security product from Microsoft for getting insights from the on-premises environment. Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

With Defender for Identity critical data will be visible from the complete cyber-attack kill-chain. For example the image above. Reconnaissance, Compromised credentials, Lateral movements, Domain dominance is all visible. Key components in case of a real attack. (example ransomware)

Configuration Defender for Identity

Microsoft integrated Defender for Identity some weeks ago with the security.microsoft.com portal for configuration. Note: this blog won’t contain all the details and describes the only Defender for Identity in some high-overview steps.

Requirements

Some requirements are needed for configuring Defender for Identity.

  •  Licensing Defender for Identity
    • License (E5/A5)
    • Microsoft E5/A5
    • Standalone Defender for Identity license
  • Allowed internet connectivity or use proxy
  • Directory service accounts
    • Standard AD User account or gMSA account (gMSA recommended for 2012 or above)
  • Honeytoken account with no network activity
  • Specific sizing and CPU/ Memory specs

For all requirements check Microsoft.com

Create the Defender for Identity instance

For new tenants, it is required to create the Defender for Identity instance first.  The MDI instance is created automatically in the data center that is geographically closest to your Azure Active Directory (Azure AD). Once created, Defender for Identity instances aren’t movable.

  1. Go to Security.microsoft.com
  2. Open Settings
  3. Click on Identities
  4. Wait a couple of minutes before the instance is created

Now the following portal is visible:

For installing the first sensor on the domain controller. Click on Sensors and press the button Add Sensors. From the add sensor page the installer can be downloaded and the Access Key is visible for the registration during the installation.

Important is to configure the Directory service account to connect sensors with the on-premise Active Directory domains. For configuring the directory services accounts click on directory service accounts. More information about service accounts and gMSA accounts. Source

Note: GMSA account recommended.

Collect events

Microsoft Defender for Identity detection relies on specific Windows Event log entries to enhance some detections and provide additional information on who performed specific actions such as NTLM logons, security group modifications, and similar events. Important to change if needed the Event collection for the domain controllers.

For lateral movement important to configure the SAM-R capabilities with the Defender for Identity service account.

For the complete event overview. See the instruction from Microsoft. source

After the configuration the sensor is visible from the portal. From the portal you can detect any sensor issues and validate the version, service state, updated state, health state and view related health issues.

 

Azure Sentinel connector

Connecting Defender for Identity with Azure Sentinel is possible with the existing connector.  For enabling the connector use the following steps:

  • Go to Azure Sentinel
  • Click on Data connectors
  • Search for Defender for Identity

 

  • Now open the connector page and connect the Defender for Identity instance into Azure Sentinel with the button Connect.

Validate events in Security console

From the advanced hunting tool data is available from the Defender for Identity product. Advanced hunting is a query-based threat-hunting tool that lets you explore up to 30 days of raw data.

To be able to use Advanced Hunting:

The tables ‘IdentityLogonEvents‘ contain the raw data from Defender for Identity. If needed it is possible to export all the raw log data into the Sentinel Log Analytics workspace. For now only the alert information is redirected into Sentinel.

From Sentinel view, the alerts are visible into the security alert table with the ProviderName: Azure Advanced Threat Protection.

Lateral Movement simulation

For simulation of the lateral movement, we will use the following. In this simulation, there are three main users. There’s a “Helpdesk” Security Group (SG) of which Ron HelpDesk is a member. This SG mimics the Helpdesk. The SG is paired with a Group Policy Object that gives our Helpdesk members Local Admin rights on the respective computers.

The following users will be used:

  • Jeff Leatherman: Victim of effective phishing attack
  • Ron HelpDesk: Helpdesk guy in the organization and part of the helpdesk group.
  • Samira Abbasi: Domain admin of the local domain

The followings PC’s will be used:

  • Workstation5: Victim’s PC
    • JeffL part of the local administrator group
    • Helpdesk added to local administrator groups
  • Workstation6: Domain Admin PC
    • Helpdesk part of the local administrator group
    • Domain admin signed in before.
  • Final target DC01 (domain controller) and Samira Abbasi ( domain admin)

The first step for an attacker is the attempt to get all the DNS information. This is possible with some basic commands. nslookup, server and ls -d.

The next step is to get all the users and groups in the domain forest. Possible with some basic commands:

  • Net user /domain
  • Net group /domain
  • net group “Domain Admins” /domain
  • net group “Enterprise Admins” /domain

With the above commands, you get valuable data points for an attacker. Net user /domain shows all the users. Net group/ domain shows all the users. In the below screenshot the group name Helpdesk is visible.

With the command net group “Domain Admins” /domain all members of the Domain Admins group are visible. SamiraA is the domain admin and the final target.

We know SamiraA is part of the domain admin group.

With JoeWare Netsess.exe the active session against the SMB share is visible.  We known now; SamiraA is active on device 192.168.2.6. 

Now it is time for more specific lateral movements. In the above part, we gained network information and we have the target IP information 192.168.2.6.

Workstation5 is a hacked PC. On this device we run Mimikatz with the following command:

mimikatz.exe “privilege::debug” “sekurlsa::logonpasswords” “exit” >> c:\temp\victimcpc.txt

With the end result victimpc.txt with all the harvested credentials found by Mimikatz. Now we seeing the Helpdesk account from RonHD with the NTLM hash.

From the hacked workstation5 we running the following command for getting information from the RonHD user. With the command net user Ronhd /domain we seeing the group membership Helpdesk and the full name Ron Helpdesk. Now we know Ronhd is part of the helpdesk group and comes with more permissions.

Now it is time for the Overpass-the-Hash technique. The NTLM hash will be used to obtain a Ticker Granting  Ticket. An attacker with a user’s TGT, can masquerade as a compromised user and execute more commands.

From the hacked workstation5 run again Mimikatz and run the sekurlsa::pth command with the NTLM hash.

Now a new command prompts opens based on the RonHD credentials. Now, with the elevated prompt with more permission we can try of we can get more permission for the 192.168.2.6 device. From the command prompt we will launch now PowerSploit and run the following command’s:

  • Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
  • Import-Module C:\tools\PowerSploit\PowerSploit.psm1 -Force
  • Get-NetLocalGroupMember 192.168.2.6

Based on local SAM we can find some useful details. We searching for the group member Administrator and get all the group members. Now we found the Administrators group name contains the member name Helpdesk. With this information, we know the group Helpdesk and the user RonHD is part of the administrator’s group and the devicename contains Workstation6.

Now from the command prompt, running with the RonHD permissions, we can check access to the C: directory. With dir \\workstation6\C$ the temp folder is visible.

Now view the local tickets. We can confirm that the RonHD account ticket is in the memory of the current system.

With the rights available the next phase is to harvest more credentials. From the command prompt running in the content of the helpdesk users, we copy mimikatz.exe to the PC. We using the earlier visible temp directory. 

Now we running remotely with psexec.exe Mimikatz for getting more local tickets and information. After the export into the temp directly we need to copy all the export files with the name *samiraA*.

With the result; the harvested tickets available from the hacked pc.

Now we have the local tickets from the 192.168.2.6 PC where the domain admin user (SamiraA) is found. Now it is time to Passing the Ticket and getting access. First import the ticket file.

Validate of the right tickets are in the current session. And finally, we have the cashed tickets available, and we know SamiraA is a domain admin.

With the result access to the domain controller.

Next, visibility in the portals and Sentinel.

Alert Visibility in Defender for Identity & Sentinel

In the lab environment Defender for Identity is configured and Sentinel is active with the Defender for Identity source.

Note: From the small MDI lab setup without learning time and limited resources, not all alert details are visible in Defender for Identity.

Incident view (pass-the-ticket) Defender for Identity: 

Ticket taken from Workstation6 (Domain admin PC) and used on Workstation5 (hacked PC) to access DC01 (Domain Controller).

Incident view (pass-the-hash) Defender for Identity:

incident view from Sentinel:

Defender for Identity incidents visible from Azure Sentinel.

Incident details view: 

Investigation view: (Identity theft ( pass-the-ticket)

Protecting

Protecting is important. With Defender for Identity some critical insights are visible. Below are some protection parts for protecting against credential stealing. Of course way more protecting features are available.

Attack Surface Reduction

Credential guard

Monitoring

  • Deploy Defender for Identity
  • Deploy Sentinel and collect Defender for Identity
  • Enable Defender for Endpoint

Defender AV

  • Enable PUA protection; block mimikatz/ hack tools
  • Enable real-time protection/ sample submission/ behavior monitoring
  • Enable EDR in blockmode

User rights

  • Admin/ user rights strategy
  • MFA enabled

Oh and finally,  no on-prem environment. AzureAD + Passwordless + E5 Security. If you have on-prem AD, configure Defender for Identity or other toolings for the insights/ anomalies.

Sources:

Microsoft:  Defender for Identity Lateral movement alerts

Microsoft: Defender for Identity

Microsoft: Connect Defender for Identity with Sentinel