This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject

NetWitness Community

  • Home
  • Products
    • NetWitness Platform
      • Advisories
      • Documentation
        • Platform Documentation
        • Known Issues
        • Security Fixes
        • Hardware Documentation
        • Threat Content
        • Unified Data Model
        • Videos
      • Downloads
      • Integrations
      • Knowledge Base
    • NetWitness Cloud SIEM
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Detect AI
      • Advisories
      • Documentation
      • Knowledge Base
    • NetWitness Investigator
    • NetWitness Orchestrator
      • Advisories
      • Documentation
      • Knowledge Base
      • Legacy NetWitness Orchestrator
        • Advisories
        • Documentation
  • Community
    • Blog
    • Discussions
    • Events
    • Idea Exchange
  • Support
    • Case Portal
      • Create New Case
      • View My Cases
      • View My Team's Cases
    • Community Support
      • Getting Started
      • News & Announcements
      • Community Support Forum
      • Community Support Articles
    • Product Life Cycle
    • Support Information
    • General Security Advisories
  • Training
    • Blog
    • Certification Program
    • Course Catalog
      • Netwitness XDR
      • EC-Council Training
    • New Product Readiness
    • On-Demand Subscriptions
    • Student Resources
    • Upcoming Events
    • Role-Based Training
  • Technology Partners
  • Trust Center
Sign InRegister Now
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
NetWitness Community Blog
Subscribe to the official NetWitness Community blog for information about new product features, industry insights, best practices, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
  • NetWitness Community
  • Blog
  • DCSync Detection with NetWitness

DCSync Detection with NetWitness

HalimAbouzeid
Respected Contributor HalimAbouzeid Respected Contributor
Respected Contributor
Options
  • Subscribe to RSS Feed
  • Mark as New
  • Mark as Read
  • Bookmark
  • Subscribe
  • Printer Friendly Page
  • Report Inappropriate Content
‎2023-02-07 04:17 AM

Introduction

In this post we will look at the DCSync OS Credential Dumping technique targeting domain controllers (T1003.006), the shortcoming of logs to efficiently detect and investigate this attack, and how network data provides a better approach.

Active Directory

Active Directory is at the centre of most organizations to help centrally manage users, privileges, policies … across the network. Due to its critical role, Active Directory is often one of the 1st targets threat actors go after once they get initial access to a network, and it is therefore critical to have the required tools, visibility, and capabilities to detect and investigate attacks targeting domain controllers.

 

Domain Replication

Active Directory supports the option of having multiple domain controllers, both for backup and high availability, as well as for geographic distribution to serve sites locally. A necessary capability is therefore to ensure that all domain controllers and accounts are synchronized whenever changes are made to make sure that they all have the latest account information. This is done using MS-DRSR (Microsoft Directory Replication Service Remote Protocol), which is an RPC protocol that allows a domain controller to request the synchronization of resources using the GetNCChanges function. For example, requesting the replication for a specific user would provide the data of that user, which includes the user’s password hashes, to the domain controller requesting the information.

 

 

 

The Attack

DCSync

It is possible for a threat actor to impersonate a domain controller and generate a request to synchronize a user account. With the correct privileges, the legitimate domain controller would respond with the information, including the requested user’s password hashes. These could include password hashes of key user accounts, such as Administrator and KRBTGT accounts, which would then allow the threat actor to generate golden tickets and perform pass the hash attacks. DCSync is part of mimikatz, allowing to easily perform this attack.

 

Privilege Requirements

For the attack to be successful, the threat actor must use an account that has the following privileges:

  • Replicating Directory Changes
  • Replicating Directory Changes All

By default, members of the Domain and Enterprise Admin groups, as well as computer accounts have these privileges.

If the attacker was able to compromise one of these accounts (through phishing, bruteforcing, password re-use, data leak …), he would be able to successfully execute this attack.

In addition, some vulnerabilities such as Zerologon (CVE-2020-1472) would allow the threat actor to set an empty password for the computer account of the domain controller and use this account to successfully use DCSync.

 

Attack Process

The following are sample steps to demonstrate a successful execution of DCSync to obtain the password hashes of the “Administrator” account.

Execution of Zerologon

This is an optional step to gain access to the domain controller’s computer account that has enough privileges to launch the DCSync attack.

HalimAbouzeid_0-1675751958166.png

Execution of DCSync

In this step we execute DCSync using the computer account that was compromised in the previous step to request the details of the “Administrator” account from the legitimate domain controller.

The computer account having enough privileges, the domain controller accepts the request and sends the “Administrator” details, including password hashes.

 

HalimAbouzeid_0-1675760347763.png

 

 

 

 

 

Detection

The Problem with Logs

Most recommendations to detect domain replication using logs revolve around the Windows Event ID 4662 from the domain controller, which Active Directory logs when a user accesses an AD object. Since normal and legitimate operations would generate this event, it is then recommended to specifically filter on Event ID 4662 where the properties contain "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" (when a user uses his “Replication Directory Changes All” privilegs mentioned in the previous section) and look for requests that originated from an unexpected source (such as not from another domain controller).

But the problem is that this event ID doesn’t get generated when the action is done by a computer account (such as accounts that end with “$”). Enabling logging for these accounts requires additional configuration on the domain controller, and some sources actually recommend keeping it disabled to reduce noise, because it is expected that domain controllers use computer accounts when doing replications, and this is considered as normal behaviour.

The problem with this is that, as seen in the above attack example, DCSync can be chained with Zerologon, which gives us access to the computer account of the domain controller. This means that in this or any similar case where the computer account is used by a threat actor, Event ID 4662 wouldn’t be logged, and therefore the DCSync attack would remain undetected with no trace of it.

This is just 1 example of the challenges with logs, where we rely on what is configured and enabled, and rely on the expected default behaviour of which logs are generated and under which conditions.

 

 

Detection with Network Data

A better and more consistent approach would be to leverage network data from/to the domain controller. This is typically more fool proof since it doesn’t rely on how things are configured and when things are logged or not logged: all traffic, independently of good, bad, or unknown, is continuously captured, analysed and stored.

 

As shown in the below screenshot, NetWitness can capture and extract all the information needed to detect and investigate the DCSync attack, without relying on any required custom configurations on the domain controllers:

 

  1. The service is identified as RPC (as described in the “Introduction” section)
  2. The traffic is flowing from the users’ subnet to the domain controllers’ subnet (business context can be used to enrich data at capture time by using custom feeds or by configuring the “traffic_flow_options.lua” file under the decoder’s configuration)
  3. The involved source and destination hostnames are identified
  4. The use of the “GetNCChanges” function is identified (as described in the “Introduction” section)

 

HalimAbouzeid_2-1675751958197.png

 

 

Further Investigation using Endpoint Data

If we go one step further by having the NetWitness EDR agent installed on the user workstation and domain controller, we can identify which user account and process caused the captured network session to be generated.

In the below screenshot, we can see that this RPC session has been generated by a process named “svchost.exe”, which appears to be a valid Microsoft process.

 

HalimAbouzeid_2-1675760472507.png

 

 

By drilling into the details of this “svchost.exe” process we can easily confirm that:

  • The file hash is known to be malicious
  • Independently of the filename, it is identified as “Win64.Hacktool.Mimikatz”
  • It is not actually signed by Microsoft

HalimAbouzeid_3-1675760546272.png

 

Based on the above, we can quickly and easily reach the conclusion that this specific file is actually Mimikatz renamed to a familiar process name, is not actually a valid Micorosft process, and the network traffic generated by this process is therefore also confirmed to be malicious.

 

 

IOCs

Sample IOCs for techniques and behaviours mentioned in this article.

Zerologon: ioc = 'zerologon attempt'

DCSync: action = ‘drsgetncchanges’ && ip.src != <include list of approved IP addresses>

 

  • credential dumping
  • dcsync
  • EDR
  • Endpoint
  • mimikatz
  • ndr
  • Network
  • t1003
  • t1003.006
4 Likes

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

  • Comment
Latest Articles
  • Advanced HTTP and TLS Concepts (Video)
  • Using NetWitness to Detect Command and Control: SILENTTRINITY C2
  • FirstWatch Threat Spotlight – Remcos RAT
  • FirstWatch Threat Spotlight: The LockBit Conundrum - A Glimpse into Ransomware Warfare
  • Content Hygiene – Application Rule Alert Mapping Updates
  • Microsoft Azure Log Analytics workspace integration with Netwitness
  • FirstWatch Threat Spotlight: Cryptonite Ransomware
  • Deployment Inventory (Serial Numbers)
  • The History of APT10
  • Integration of Symantec Endpoint Security with Netwitness Platform
Labels
  • Announcements 63
  • Events 8
  • Features 11
  • Integrations 12
  • Resources 66
  • Tutorials 31
  • Use Cases 27
  • Videos 118
Powered by Khoros
  • Blog
  • Events
  • Discussions
  • Idea Exchange
  • Knowledge Base
  • Case Portal
  • Community Support
  • Product Life Cycle
  • Support Information
  • About the Community
  • Terms & Conditions
  • Privacy Statement
  • Acceptable Use Policy
  • Employee Login
© 2022 RSA Security LLC or its affiliates. All rights reserved.