In today's mature enterprise environments, adversaries must choose a stealthy means of beacon execution. The advancement of antivirus (AV) engines has forced threat actors to migrate many heavily-signatured implants from disk to memory, where they are not scanned as often if at all. Process Injection [T1055] is a common technique used to achieve this goal. In this article, we will explore the Windows logging mechanisms available for defenders to detect and prevent process injection, as well as the evasion techniques used by advanced threat actors to circumvent detection. At a high-level, the figure below demonstrates the general steps that adversaries must take in order to perform Process Injection or Reflective Code Loading [T1620], and the coverage / visibility that good endpoint detection and response (EDR) products have along the way.

TL;DR

With the myriad of publicly available shellcode loaders, broad detection mechanisms should be utilized to detect as many variations as possible. Most process injection techniques can be abstracted into memory allocation, write, and execution primitives to dynamically execute code. The more generic the abstractions that we can create, the more individual procedures that we can potentially identify.

Step 1: Load PE File From Disk

The first step that adversaries commonly employ is loading a PE file from disk to establish command and control (C2) [TA0011] communications. The implant loaded from disk can then callback to an attacker-controlled server, facilitating control over the compromised system. However, stage-less implants directly loaded like this can be easily signatured by AV. While some static indicators can be encrypted to hide their presence, excessively high file entropy can also be an indicator itself. Additionally, EDRs often perform automated dynamic analysis in a sandbox before allowing execution of suspicious binaries to take place. This naturally led to the development of "stagers", which are small programs designed to load and execute position-independent shellcode. Stagers decouple functionality and allow for retrieval of the shellcode at runtime, thereby bypassing AV scans. While impractical for some environments, application whitelisting or code signing enforcement can restrict the usage of unknown applications. This would prevent a stager from directly executing in the first place. While these defenses can potentially be bypassed via DLL Hijacking [T1574.001] and other techniques, for now, we will assume that the attacker is able to execute a stager on the machine with the goal of injecting code into a remote process.

Relevant Security Controls:

• Antivirus / Antimalware [M1049]

  • Yara Rules

• Application Isolation and Sandboxing [M1048]

  • Hybrid Analysis (CrowdStrike Falcon® Sandbox)

  • Any Run

• Code Signing [M1045]

  • Windows AppLocker

• Execution Prevention [M1038]

  • Windows Defender Application Control (WDAC)

Step 2: Identify Sacrificial Process

Next, the attacker needs to identify a process to inject code into. While code can be reflectively loaded into the stager itself (the local process), attackers often use remote process injection to better mask execution and masquerade as a legitimate process. For stability reasons, many opt to create the desired remote process and spawn it at runtime, rather than potentially crashing an existing live process. Then, attackers (usually) need to acquire a handle for the target process to perform virtual memory operations in the context of the remote address space. So, what telemetry sources do defenders have for these actions?

Since most EDRs operate using a kernel-mode driver, they can register a set of custom kernel callback routines to get notified whenever certain actions take place. For example, EDRs can utilize the PsSetCreateProcessNotifyRoutine* family of functions to register a callback that is invoked whenever a process is created1. An EDR can use this notification as an opportunity to inject a hooking library into the new process, as a source of telemetry for certain sensitive API calls. Additionally, ObRegisterCallbacks() can be used to register a callback routine for thread, process, and desktop handle operations. On its own, these behaviors are usually not enough to trigger an alert. However, when combined with other indicators, the general process injection flow becomes clearer.

Relevant Security Controls:

• Windows Kernel Callback Functions

  • PsSetCreateProcessNotifyRoutine()

  • PsSetCreateProcessNotifyRoutineEx()

  • PsSetCreateProcessNotifyRoutineEx2()

  • PsSetLoadImageNotifyRoutine()

  • PsSetLoadImageNotifyRoutineEx()

  • ObRegisterCallbacks()

Step 3: Allocate Virtual Memory

Depending on the injection method, memory usually needs to be explicitly allocated before shellcode can be written and executed. Windows provides several different memory allocation methods, each with slightly different functionality.

To allocate memory on the heap, HeapAlloc() or one of its wrappers ( GlobalAlloc() and LocalAlloc() ) can be used. Today, these wrapper functions are functionally equivalent and remain as artifacts from the old days of 16-bit Windows. The C runtime (CRT) provides malloc() and new, but they also internally call HeapAlloc(). For COM-aware allocations, CoTaskMemAlloc() or IMalloc::Alloc() with an OLE memory allocator can be used. VirtualAlloc() and VirtualAllocEx() are similar, but align allocations to page granularity (usually 64KB) and round up the length to the minimum page size (typically 4KB).

Despite the multitude of different options, most are simply wrappers and end up calling the same low-level implementations (as shown in this example call stack):

kernel32!VirtualAlloc()

↳ kernel32!VirtualAllocEx()

↳ ntdll!NtAllocateVirtualMemory()

Another important distinction for the VirtualAlloc* family of functions is that, by default, they (along with the NtAllocateVirtualMemory() NT API syscall) will treat executable pages as valid indirect call targets for Control Flow Guard (CFG). CFG, which is Microsoft's implementation of Control Flow Integrity (CFI), is an exploit mitigation feature designed to restrict arbitrary code execution by validating call targets using a bitmap. It is worth noting that CFG is only designed to limit exploitation of memory corruption vulnerabilities, as Microsoft exposes the SetProcessValidCallTargets() API for programs to manually designate call targets as valid or not.

Additionally, with the widespread adoption of Data Execution Prevention (DEP), stack and heap allocations are often automatically marked as non-executable in their corresponding page table entry (PTE) control bits.

3.1 Hooking and Syscalls

One way that EDRs can get telemetry from allocation events is via usermode (ring 3) API hooks. Once an EDR is notified of a new process creation, it can inject its hooking library and detour functions by overwriting their function body in memory. This strategy is known as an inline hook, but there are many other methods that could be employed as well, such as import address table (IAT) hooking or previously system service dispatch table (SSDT) hooking. AV and EDR vendors used to more readily patch kernel memory, but this led to system instability and insecure implementations. With the introduction of Kernel Patch Protection (KPP / PatchGuard) in Windows XP, security vendors have now been forced to migrate their hooks to usermode instead.

Using native system services routines (syscalls) instead of their corresponding WinAPI wrappers can bypass some high-level hooks, but they can ultimately be scrutinized by an EDR just as easily. If an adversary directly executes a syscall stub (from the exported function in ntdll.dll), the stub could be hooked just like any other function. Additionally, the EDR can analyze the call stack during execution of the syscall and see that it directly returns to user code (instead of through the normal wrappers), which is a high fidelity indicator of malicious activity. Some attackers may choose to embed custom syscall stubs inside an implant to bypass inline hooks. These stubs consist of a short function prologue in Assembly that sets up the required registers ( mov rax, <SSN>; mov r10, rcx ) before executing a system call. They have the added overhead of having to manually recover the system service number (SSN) of the desired syscall, in order to properly set the RAX register. If these stubs perform "direct" sycalls, by directly using the syscall instruction, then they can actually be caught by a simple static indicator. Only internal Windows libraries implement syscalls, so any other user binary with the syscall instruction ( 0x0F 0x05 ) in its .text section is likely to be malicious. Some attackers implement "indirect" syscalls, which jump to the address of a syscall instruction in ntdll.dll. While these stubs may bypass static analysis, they can still be caught using call stack analysis at runtime. Using Windows' internal instrumentation engine, EDRs can register a callback for the transition from kernel to user mode (by setting the KPROCESS!InstrumentationCallback field). Once the callback is invoked, the EDR can analyze the context for each syscall and check the RIP to determine if it is legitimate or not. Unless the call stack is artificially legitimized and spoofed (e.g. by using ROP gadgets or hardware breakpoints), then the syscall will still return directly back to user code and appear anomalous.

3.2 ETW

An alternative approach taken by some malware authors is to launch the sacrificial process in a suspended state, in an effort to beat the EDR before its hooks can be fully initialized (Process Hollowing [T1055.012]). However, using Event Tracing for Windows (ETW), EDR vendors can tap into the Threat-Intelligence (TI) log provider to receive telemetry without relying on hooking.

This provider generates several relevant events:

• THREATINT_ALLOCVM_LOCAL

• THREATINT_ALLOCVM_REMOTE

• THREATINT_FREEZE_PROCESS

• THREATINT_MAPVIEW_LOCAL

• THREATINT_MAPVIEW_REMOTE

• THREATINT_RESUME_PROCESS

• THREATINT_RESUME_THREAD

• THREATINT_SUSPEND_PROCESS

• THREATINT_SUSPEND_THREAD

• THREATINT_THAW_PROCESS

• …

While ETW largely operates at the kernel-level, some events are sent from userland via ntdll!EtwEventWrite(). As a result, implants may patch this function in memory to disable some ETW providers. However, telemetry from ETW can be used to detect this tampering (via the THREATINT_PROTECTVM* and THREATINT_WRITEVM* events), which may actually increase the chances of detection. In some cases, attempting to unhook or disable security controls unintentionally results in an increased likelihood of detection. In social psychology, this is known as the boomerang effect.

Now, back to memory allocation. Since EDRs have plenty of data surrounding explicit allocation, one alternative is to perform actions that have the side effect of allocating memory, like sending messages to a graphical window message queue (Shatter Attacks), or stuffing shellcode into the environment strings of a child process. Other techniques, such as enumerating existing PAGE_EXECUTE_READWRITE protected memory pages (Mockingjay), overwriting linker padding in a PE (Code Cave), or abusing the shared Extra Window Memory region of Explorer's tray window (Extra Window Memory Injection [T1055.011]), can even take advantage of existing memory without the need to explicitly allocate it. These techniques are much more difficult to atomically detect since they depart from the normal process injection paradigm. From a defensive perspective, allocation events by themselves present far too much noise to be a reliable indicator of process injection. But, they can help paint a full picture, especially when using temporal correlation to observe and link other injection steps.

Relevant Security Controls:

• API Hooking

  • Inline Hooks

  • IAT Hooks

• Call Stack Analysis

  • Process Instrumentation Callback

• Event Tracing for Windows (ETW)

  • Microsoft Threat Intelligence (ETW-TI)

    • THREATINT_ALLOCVM_LOCAL

    • THREATINT_ALLOCVM_REMOTE

    • THREATINT_MAPVIEW_LOCAL

    • THREATINT_MAPVIEW_REMOTE

Step 4: Write Virtual Memory

After suitable memory has been identified and/or allocated, the payload can be written. This is usually performed using WriteProcessMemory() or its NT API equivalent, NtWriteVirtualMemory(). While most loaders simply use PAGE_EXECUTE_READWRITE protected memory pages, PAGE_READWRITE can also be used if the protection is changed after the data is written (using either VirtualProtect() or NtProtectVirtualMemory() ).

Most of the same telemetry sources are applicable from the previous section. Using the ETW-TI provider, EDRs have visibility into memory writes as well as protection modifications via THREATINT_WRITEVM* and THREATINT_PROTECTVM* events. But, before discussing specific detection mechanisms, it’s important to understand the different types of memory first.

On Windows systems, memory can be marked as any of the following:

• MEM_FREE

  • Unused physical memory

• MEM_RESERVE

  • Virtual memory that has been reserved for future use

• MEM_COMMIT

  • Virtual memory that has been committed and assigned physical storage

• MEM_PRIVATE

  • Private memory that is not shared between processes

• MEM_MAPPED

  • Shared memory that is mapped into the view of a section object

• MEM_IMAGE

  • Shared memory that is mapped into the view of an image section object

For now, we will ignore the first 3 since we're more interested in the type of memory rather than it's current state. Most dynamically allocated memory, like those resulting from the previously mentioned allocation functions, typically falls under the category of private memory. Consequently, it is almost always protected as PAGE_READWRITE, which aligns with its usage as stack and heap storage. Private memory is rarely ever marked as executable, with the exception of JIT compilers in a web browser or .NET Framework Common Language Runtime (CLR) allocations. Mapped memory, on the other hand, often originates from a file on disk via CreateFileMappingA() or NtCreateSection(). After using these functions to create a shared mapping/section object, a process can map a view of the section using MapViewOfFile() or NtMapViewOfSection() to interact with its contents. If the mapping object is backed specifically by an executable file and was created using the SEC_IMAGE flag, then subsequent views are marked as MEM_IMAGE regions instead of MEM_MAPPED. Since MEM_IMAGE regions originate from an executable file on disk, page protections for these views are determined by the PE itself from the permissions listed in the section table. Naturally, MEM_IMAGE blocks receive the least amount of scrutiny, since their contents were likely already scanned by AV on disk.

Since image section views are usually where executable code resides, what's stopping an attacker from overwriting it with shellcode? The answer lies in a mechanism called "copy-on-write". When a DLL is mapped into memory, Windows employs a resource sharing technique called "copy-on-write" to optimize memory management. Subsequent loads of the same file will be backed by the same shared memory pages, with a transparent "copy" made if a process tries to modify the shared region. The original page remains unmodified, while Windows creates a private copy of the page for the process to write to. This reduces overhead and avoids unnecessary duplication of unmodified pages across multiple processes. Since executable code segments are marked as PAGE_EXECUTE_WRITECOPY, once an attacker modifies the page, the Shared bit in that page's extended working set information will be cleared2. This detection methodology (unshared MEM_MAPPED or MEM_IMAGE pages) can also be used to detect hooks and other memory patching, like disabling ETW.

One injection technique that works around these limitations is Process Doppelgänging [T1055.013] / Phantom DLL Hollowing. This technique abuses transactional NTFS (TxF) by opening an isolated file handle to alter the .text section of a DLL. This is done without ever flushing the changes back to disk, and occurs before the view is mapped into memory, making detection much more difficult. However, due to the isolation provided by the TxF transaction, this technique has the unique side effect causing calls to GetMappedFileNameW() to fail when attempting to query the name of the file associated with the image region. Additionally, the MmDoesFileHaveUserWritableReferences() function can be used by an EDR to determine if there are any writable references to the file object of a section (broken section coherency).

Other detection logic is largely focused on private memory. Using the data sources described earlier, EDRs have visibility into the parameters passed to memory management functions. This is sufficient to cover certain anomalous behaviors, like private RWX allocation or fluctuating memory protections (RW ⇄ RX). Contextual behaviors like these can elevate a process' risk score, and trigger further investigation. One such investigative tool is memory scanning. Since full memory scanning is far too resource intensive, EDRs often rely on event-triggered scans. For example, an EDR could choose to scan the buffer being written to memory if the pages being written to are executable. These scans can be used to detect PE Injection [T1055.002] by searching for a PE header ( MZ ) found in private memory, which indicates that an executable file was loaded in an abnormal way (and not via LoadLibrary()). Another potential indicator is buffer size. As noted in the previous section, VirtualAlloc() rounds the allocation up to the minimum page size. Since most programs don't need to write large chunks of memory to a remote process, the vast majority of legitimate remote memory operations are performed on a single page. Shellcode, on the other hand, can be much larger — especially when using an off-the-shelf framework like Metasploit or Cobalt Strike.

Relevant Security Controls:

• API Hooking

  • Inline Hooks

  • IAT Hooks

• Call Stack Analysis

  • Process Instrumentation Callback

• Event Tracing for Windows (ETW)

  • Microsoft Threat Intelligence (ETW-TI)

    • THREATINT_PROTECTVM_LOCAL

    • THREATINT_PROTECTVM_REMOTE

    • THREATINT_WRITEVM_LOCAL

    • THREATINT_WRITEVM_REMOTE

Step 5: Execute Payload

After staging the payload in memory, the final step is to trigger execution. There's a wide variety of execution primitives, with the most common being CreateRemoteThread() / RtlCreateUserThread() / NtCreateThreadEx(). These functions simply create and insert a new thread into the target process, with the specified starting address. In a "classic" DLL Injection [T1055.001], LoadLibraryA() is used as the starting address. Using the PsSetCreateThreadNotifyRoutine kernel callback, these techniques can be detected by determining if the starting address points to private memory or a suspicious trampoline function.

Another method is to hijack the state of an existing thread using the SetThreadContext() API (Thread Execution Hijacking [T1055.003]). This function modifies the register state (context) of a suspended thread, and can be used to redirect execution flow by directly setting the RIP register. However, it is primarily only used by debuggers and can be caught using API hooks or THREATINT_SETTHREADCONTEXT_REMOTE ETW-TI events.

Existing threads can also be used to execute an asynchronous procedure call (APC) by using QueueUserAPC() or NtQueueApcThread() to insert a user-mode APC object into the thread’s APC queue (Asynchronous Procedure Call [T1055.004]). This will cause the thread to execute the specified APC the next time it enters an alertable state. ETW-TI also provides visibility into these events via THREATINT_QUEUEUSERAPC_REMOTE logs.

Message hook functions, like SetWindowsHookEx() or NtUserSetWindowsHookEx(), are yet another option. These functions install a custom hook procedure into the hook chain, which triggers execution whenever the specified WH_* event occurs3. Due to their widespread abuse by keyloggers, defensive tooling often has the capability to detect suspicious message hooks by enumerating gSharedInfo members, performing API hooking, or even keeping a stateful list to determine anomalies4.

Lastly, a large class of injection methods involve overwriting a pointer to code (often a callback). These methods take advantage of the fact that many pointers to code are stored in writable memory, and overwriting these pointers can redirect the execution flow to arbitrary locations when the callback is triggered. This includes attacks that abuse Window subclassing (PROPagate), window message handlers (ConsoleWindowClass), PE entry points (AddressOfEntryPoint), thread local storage (TLS) callbacks (Thread Local Storage [T1055.005]), control signal handler callbacks (Ctrl-Inject), the KernelCallbackTable PEB member, and many many more. While there's an almost innumerable amount of execution primitives, most can be detected using a combination of API hooking, validating the target address of a remote memory writes, as well as monitoring new threads that originate from unbacked memory.

Relevant Security Controls:

• API Hooking

  • Inline Hooks

  • IAT Hooks

• Call Stack Analysis

  • Process Instrumentation Callback

• Event Tracing for Windows (ETW)

  • Microsoft Threat Intelligence (ETW-TI)

    • THREATINT_PROTECTVM_LOCAL

    • THREATINT_PROTECTVM_REMOTE

    • THREATINT_QUEUEUSERAPC_REMOTE

    • THREATINT_READVM_REMOTE

    • THREATINT_SETTHREADCONTEXT_REMOTE

    • THREATINT_WRITEVM_LOCAL

    • THREATINT_WRITEVM_REMOTE

• Exploit Protection [M1050]

  • Control Flow Integrity (CFI)

    • Control Flow Guard (CFG)

  • Data Execution Prevention (DEP)

• Windows Kernel Callback Functions

  • PsSetCreateThreadNotifyRoutine

  • PsSetCreateThreadNotifyRoutineEx

1. https://attack.mitre.org/

2. https://github.com/rabobank-cdc/DeTTECT

3. https://github.com/rabobank-cdc/DeTTECT/wiki/Data-quality

4. https://github.com/rabobank-cdc/DeTTECT/wiki/Visibility-scoring

5. https://github.com/rabobank-cdc/DeTTECT/wiki/Detection-scoring

6. https://mitre-attack.github.io/attack-navigator/

7. https://rabobank-cdc.github.io/dettect-editor

8. https://github.com/blacklanternsecurity/blue-resources/blob/main/Windows_MITRE_Data_Source_Mapping.xlsx

One of the objectives for the initial phase of a risk assessment is to identify and analyze critical business workflows, as well as the IT assets and personnel that support them. Keep in mind that these workflows may not even be IT-specific. For example, consider the workflows associated with accounts payable, accounts receivable, vendor management, and treasury operations. What's important to understand is that critical workflows have the greatest potential risk. A successful attack on the IT assets, personnel, or data that support these workflows would result in significant negative impacts to the organization. The impact to an organization can be reduced by ensuring that critical IT assets and personnel are adequately defended. Administrative-, network-, host-, and email-based security controls can be strategically deployed to defend critical assets, personnel, and the workflows that they support.

In the event of an incident or breach, it is equally important to ensure that the data sources these security controls rely on are available, accurate, and provide the required fidelity. For example, if the aim is to detect and alert on brute force login attempts and the target server is not configured to log failed login attempts, then it will be incredibly difficult to detect the attack and isolate the attacker. An easy mental checklist might be:

1. Is the activity visible in your environment and does it generate any logging artifacts?

2. If so, where is the event being logged? What is the data source for that event?

3. Are the logs for that data source being shipped to a SIEM or centralized log management solution?

4. If so, is there an alert being generated when executing the attack?

5. Finally, are SOC analysts triaging the alert based on criticality?

This approach quickly becomes more complicated and resource-intensive as more and more attacks are considered. The MITRE Enterprise ATT&CK matrix currently includes 14 tactics, 191 techniques, and 385 sub-techniques. "MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community." [1]

As a defender, a primary concern might be how much "coverage" an organization has for the tactics, techniques, and procedures (TTPs) detailed in the MITRE ATT&CK matrix. That is, based on existing security controls and data sources, what percentage of TTPs can I potentially detect? To make it easier for defenders to determine their current "coverage" for MITRE ATT&CK TTPs, the DeTT&CT [2] project has mapped attacker (sub)techniques to the data sources that should capture specific attacker activities. Therefore, as a first approximation, if a defender has one or more data sources configured and available, then they have the "potential" to detect the (sub)techniques that map to those data sources. Going from a potential detection to an actual detection depends on the completeness and quality of the data contained in each data source, as well as the number of data sources that could potentially capture activity surrounding a TTP.

The DeTT&CT framework provides defenders with a means to specify and score: - Data Sources - Data Quality - Visibility - Detection

Data quality is scored based on "device completeness, data field completeness, timeliness, consistency and retention" [3]. Visibility scores will depend on how many aspects of the attacker (sub)technique can be captured [4]. Theoretically, multiple high quality data sources should be configured for each (sub)technique. A Detection will be scored based on multiple factors including, timing, (sub)technique coverage, opportunities to bypass, false negatives, and false positives [5]. Data Source, Data Quality, Visibility, and Detection metrics can be visualized as ATT&CK Navigator layer files [6] that serve to illustrate an organization’s defensive posture. Establishing and increasing an organization's coverage is a continuous and resource-intensive process.

For the purposes of this post, the objective will be to generate a simple ATT&CK Navigator layer file that a defender can use to illustrate MITRE ATT&CK coverage for Windows systems based on data sources alone; data quality, visibility, and detections will not be considered for now. This basic coverage data can then be used as an input for assessing organizational risk.

The primary inputs for the MITRE Navigator file are the data sources that are available within the organization. However, the Rabobank-CDC DeTT&CT framework doesn't map the data sources to well known Windows Event Logs. In this case, it's left to the analyst to perform that mapping by hand. To that end, Adeem Mawani and Brian O'Hara have created a helpful worksheet published in the BLS Blue Team Resources Github repository [8]. The worksheet details each Windows Advanced Audit Log Setting and then maps that setting and its corresponding Windows Event IDs to its MITRE data source. Each entry includes:

• Category

• Subcategory

• Default configuration

• Baseline configuration recommendations

• Conditions (success/failure)

• MITRE data source name

• MITRE data source ID

• Windows event ID

• Windows event description

The intention is to provide the analyst with a rubric for mapping the output of the auditpol command to actual MITRE data sources. Armed with a list of MITRE data sources, the MITRE Navigator layer file can be created. The end result is a map of "potential" coverage for MITRE ATT&CK TTP's based on available data sources.

1. The DeTT&CT Editor [7] is publicly hosted or can be run locally using:

python dettect.py editor

2. In the editor, create a new YAML file to store your available data sources:

   

2. Determine available data sources in your environment. For example, by using the published worksheet to map data sources to Windows audit log configurations:

   

3. Add applicable data sources using the interface at the bottom of the page:

   

4. Click "Save YAML file" to export your data sources

5. Run the following command to generate a navigator layer file using the exported YAML:

python dettect.py ds -fd data-sources.yaml -l

6. View the ATT&CK Navigator using the following link to disable yellow underlines: https://mitre-attack.github.io/attack-navigator/#comment_underline=false

7. In Navigator, click "Open Existing Layer" and open the exported JSON layer file created from earlier.

After gaining a foothold within an organization, threat actors often need to perform internal reconnaissance to discover users, permissions, and other potentially useful resources available. One of the most commonly used methods to achieve this is by gathering data from Active Directory in Windows enterprise environments. However, these activities often fly under the radar because attackers are simply (ab)using a legitimate feature.

Lightweight Directory Access Protocol (LDAP) queries are how clients obtain information from Active Directory. Clients specify a search filter to search for objects, such as users or computers, that match specific criteria. LDAP is used in the background by Windows to lookup and authenticate members of the domain, and has a variety of different use cases. But, since most objects in the directory can be read by any authenticated user, it can be easily abused to collect broad information about every user, group, and system on the domain.

MITRE ATT&CK TTPs

• Permission Groups Discovery - Domain Groups (T1069.002)

• Account Discovery - Domain Account (T0187.002)

• Domain Trust Discovery (T1482)

Detection Mechanisms

Network Indicators

In many environments today, LDAP queries are encrypted in-transit. While encrypting traffic is a great way to prevent eavesdropping, it also makes purely network-based detection difficult. Many current detection techniques look for an anomalous spike in traffic on ports 389 and 636 (LDAP & LDAPS), but determined threat actors can simply slow their collection over a longer time period to avoid this methodology.

Canary / Honey Accounts

Canary accounts are decoys designed to mimic legitimate accounts and bait attackers into utilizing them. They are never supposed to be used legitimately, so any activity around them can be used as an early warning sign of possible reconnaissance or enumeration activity. Canary accounts also have a very low false positive rate, since they are not normally accessed. However, baselining and whitelisting may still be necessary to rule out legitimate applications that inadvertently interact with the canaries. When deploying canary accounts, it is important to keep in mind that attributes such as a very old last logon time could tip off its existence to threat actors. It is critical to make these accounts “blend in”.

To create a canary object (e.g. user, computer, etc.), use the Active Directory Users and Computers (ADUC) console. Depending upon your use case, apply some of the following properties to the canary:

• Set user logon hours to 24/7 deny

• Periodically update the “last logged into” property to make the honey account less obvious

• Set a service principal name (like “MSSQLSvc/fqdn”) to catch potential Kerberoasting activity

• Toggle “Do not require Kerberos pre-authentication” to catch potential AS-REP Roasting

Then, configure auditing for any of the following scenarios by modifying the group policy via:

Group Policy Management -> Default Domain Policy -> Edit

Detect enumeration

Event ID 4662

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> DS Access -> Audit Directory Service Access

To detect enumeration, enable Directory Service access logging, and configure auditing for each canary object:

1. Toggle: “Active Directory Users and Computers -> View -> Advanced Features”

2. In the security tab of the canary object’s properties, click the “Advanced” button

3. Under the auditing tab, click the “Add” button

4. Set the following properties:

   • Principal: Everyone

   • Applies to: This object only

   • Permissions: Read all properties

Note: in the resulting events, the Object Name is not translated from its GUID

Detect Canary Account Login Attempts

Event ID 4768 (or 4625)

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon -> Audit Kerberos Authentication Services

This will record all failed Kerberos authentication attempts, so filter events accordingly based on the canary name in the “TargetUserName” field.

Audit Kerberos TGS Requests

Event ID 4769

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon -> Audit Kerberos Service Ticket Operations

To detect potential Kerberoasting attempts on your canary object, configure logging for service ticket requests.

Note: this generates a huge amount of noise, so before forwarding to a SIEM, filter logs based on:

• RC4 or DES Encryption (Ticket Encryption: 0x17) OR (Ticket Encryption: 0x1 OR 0x2 OR 0x3)

• Canary name in the “Service Name” field

Host-Based Detection

The highest-fidelity detection can be achieved by logging sent LDAP queries at the host level. All LDAP queries could be logged on the Domain Controller (DC) itself, but this often leads to performance issues. A typical DC generates huge amounts of data as LDAP queries are part of its primary functionality, thus, it becomes infeasible to collect and store this data directly on the DC in any large enterprise environment. However, by logging queries directly on domain-joined endpoints, the data becomes much more manageable. Host-based logging gives visibility into the searches performed from each endpoint (which is often the pivot point of an attacker), and also provides important context around the data. For example, the PID of the process that sent the query can be captured in this manner. Luckily, this functionality is already built-in to Windows via an Event Tracing for Windows (ETW) log provider. For more information about ETW, check out Event Tracing For Windows 101.

Enabling this log provider is very simple:

wevtutil set-log "Microsoft-Windows-LDAP-Client/Debug" /enabled:true /quiet:true /retention:false /maxsize:100032

Or by using the Event Viewer GUI:

1. Event Viewer -> View -> Show analytic and debug logs

   

2. Enable “Applications and Services Logs -> Microsoft -> Windows -> LDAP-Client -> Debug”

1. . Increase the default log size and/or change the event overwrite settings. Note: if overwriting is enabled, the Event Viewer will not be able to display entries, but they are still recorded. Source

The “Microsoft-Windows-LDAP-Client” logs are stored on disk as binary event trace logs (.etl) This means that they must be converted into human-readable format before being forwarded to a SIEM. To automate the collection process, you can use SilkETW or Splunk-ETW. In this example, I will use the Splunk-ETW Technology Add-on. Installation instructions are pretty straightforward and well-documented on the project’s GitHub page.

After installing the add-on on the forwarder(s), create a new “profile” named ldap.ini in

$SPLUNK_HOME\etc\apps\Splunk-ETW\profile 

with the contents

[Microsoft-Windows-LDAP-Client].

Next, to enable the profile we just created, add the following to inputs.conf at $SPLUNK_HOME\etc\system\local\inputs.conf:

[Splunk-ETW://ldap]
disabled = 0

Then, you should begin to see events populate Splunk with the sourcetype: Splunk-ETW (a restart of Splunk may be required).

Now that we have visibility into the actual LDAP queries that are being sent, we can begin to differentiate “signal” from “noise”. But first, let’s take a look at the syntax of LDAP search filters. Filters are boolean expressions, more simply known as “true” or “false” statements, that specify what objects should be returned in the search. For example, the following search filter will return all objects in the “user” class:

(objectClass=user)

Parenthesis serve as a grouping around the different “clauses”, and allow for multiple attributes to be specified in a single search query. These groupings can also be chained together with logical comparative operators, AND (&) or OR (|). For example, another way to enumerate user accounts could be to search for all objects that have the “homedirectory”, “scriptpath”, or “profilepath” attributes set. Since we want to find all objects with any value for each of these 3 attributes, we can use the wildcard (*) character in place of the value. So, to return objects with any value for “homedirectory” OR “scriptpath” OR “profilepath” we could use the following:

(|(homedirectory=*)(scriptpath=*)(profilepath=*))

Most legitimate LDAP queries will be searching for a very specific object, instead of trying to find all objects that match generic criteria. After running some popular enumeration tools in the BLS lab environment, we observed the following elements of suspicious queries begin to standout:

• Generic search looking for all objects of a general type

• Large number of generic filters in single query (e.g. return all computers AND users AND groups)

• Multiple queries from the same PID in a short time-frame

• Wildcards present in search filter

Utilizing these observations as a basis for generating a detection method, we have created a series of LDAP query filters that can be used with the logging configuration outlined above to generate alerts for suspicious LDAP activity. These queries have been consolidated and published as Sigma rules in the BLS and SigmaHQ repositories.

Below is a list of additional LDAP search filters that could potentially be used for reconnaissance by an attacker. These filters may be useful for threat hunting efforts within your environment to identify suspicious / unwanted LDAP activity.

Domain Enumeration

Account Enumeration

Computer Enumeration

Group Enumeration

Kerberos Enumeration

Related Works

The Remote Security Account Manager (SAMR) protocol has very similar functionality to LDAP, as it also enables enumeration of domain accounts and groups. It is used by the built-in net.exe command, and its impact should also be considered. For mitigation strategies, visit the following page:

• https://stealthbits.com/blog/making-internal-reconnaissance-harder-using-netcease-and-samri1o/

Share

Subscribe now

References

1. https://github.com/blacklanternsecurity/sigma-rules

2. https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/ldap/win_ldap_recon.yml

3. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties

4. https://docs.microsoft.com/en-us/windows/win32/adschema/a-grouptype#remarks

5. https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccounttype

6. https://github.com/fireeye/SilkETW

7. https://github.com/airbus-cert/Splunk-ETW

A common favorite “domain domination” technique for Black Lantern Security (BLS) operators during engagements is to perform a DCSync attack to obtain all the juicy credentials they can acquire. Because this technique generally flies under the radar of detection and logging capabilities at most organizations, the first question from the client during outbrief always seems to be, “How did you do it?” In an effort to aggregate many of the community resources, research, and shared experience and to demystify some of this technique’s nitty gritty technical details in a digestible manner for our clients, we have put together a brief write up.

Overview

The DCSync attack methodology takes advantage of the Directory Replication Service Remote (DRSR) protocol to obtain sensitive information from a domain controller.1 This technique involves an adversary masquerading their host as a domain controller (DC) and convincing the authentic DC to synchronize its database to the new rogue DC by issuing a replication request. This functionality is not a bug, but rather is intended activity to provide user friendly redundancy in a multi-DC network. The attack does require elevated privileges to complete. The user account used to perform the data replication request must have the ”replicating directory changes” privilege, which is commonly found associated with administrator and domain administrator credentials. The results of a successful DCSync attack will provide the adversary with password hashes of the targeted users. In most cases, this will include all users.

Detection on the Wire

The security community’s current recommendation for detecting a DCSync attack is to implement a detection signature at the network layer (typically through an IDS/IPS application) to identify RPC/DCE traffic, which includes calls to the DRSUAPI RPC interface.2 Network layer detection has proven to be the most consistent and easiest way to detect this type of attack. The detection criteria can be further customized to have more granularity by specifically targeting traffic which includes the bit map that indicates calls to “IDL_DRSGetNCChanges”.

For this detection technique to be effective, it requires the network to be logically segmented so that the domain controllers are grouped on a common VLAN and separated from the rest of the network. It is important to note that replication activity, as mentioned above, is normal behavior in a Windows Active Directory environment. The recommended deployment configuration from Microsoft suggests including more than one DC for redundancy and load balancing purposes.3 As this is the advice given directly from the vendor, it is likely to be encountered in many corporate networks and all but guarantees ongoing replication activity. The fact that replication behavior is expected makes detection of “malicious” activity very challenging on a flat network. The sheer volume of alerts from a flat network will eventually cause alert fatigue and many times the results of an investigation will end up being legitimate activity. By implementing proper network segmentation, DRSR protocol activity is limited to the DC VLAN and detective measures can be put in place so that the IDS/IPS signatures only alert on attempts to replicate the DC database outside of the controlled DC segment. In this configuration, preventative controls may also be put in place as well to block DRSR traffic that is routed outside of the DC network segment.

Example Suricata signatures created by Didier Stevens research can be seen below.4

alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg:"Mimikatz DRSUAPI"; flow:established,to_server; content:"|05 00 0b|"; depth:3; content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|"; depth:100; flowbits:set,drsuapi; flowbits:noalert; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000001; rev:1;)

alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg:"Mimikatz DRSUAPI DsGetNCChanges Request"; flow:established,to_server; flowbits:isset,drsuapi; content:"|05 00 00|"; depth:3; content:"|00 03|"; offset:22 depth:2; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000002; rev:1;)

Note that both signatures are inspecting for traffic originating from any network segment that is NOT the DC segment and that includes calls to drsuapi through RPC/DCE traffic. The first signature is looking for a bind event, which is a required prerequisite to call individual functions from the DRSUAPI. The second alert is specifically targeting the flag associated with DsGetNCChanges requests. Both signatures have been tested and validated in a lab environment. Each will fire and alert when a DCSync attack is executed.

Detection Through Event Logs

Even though network detection is preferred, there will be environments that may not have the capability to detect this attack at the network layer. Fortunately, there is a means to detect this attack technique using standard Windows Event logs, which should accommodate those organizations that may have this technical limitation. The event log ID required to detect this attack is Event ID 4662, which is activated by enabling “Audit Directory Services Access” through Group Policy (Computer configurations > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Directory Service Access > Enable Success).5 By configuring this setting, two new event IDs will be generated in the logs: 4661 and 4662. Each of these event IDs can be viewed in the Security log using the standard Event Viewer application. Both of these events are extremely generic and track access attempts to directory service objects. The 4662 event ID generated by DCSync activity is specifically targeting actions where, “An operation was performed on an object”. It is important to note that this event ID is not enabled by default and must be explicitly configured. Based on the Microsoft documentation, the decision to omit these events from default logging was based on the high volume of logs that can be generated. For example, event ID 4662 will be created for any access attempts to a directory service object in which a security access control list (SACL) has been assigned. 4662 events are also generated when access to the WMI namespace, MicrosoftVolumeEncryption, is referenced.6 When Bitlocker is enabled in the environment, this generates substantial log volumes and has been cause for many organizations to eventually disable the event after initial configuration. One final recommendation is to NOT enable failure auditing as these event logs are infamous for flooding log collectors in the 10+ million range when a single error occurs.

This event log correlation method, like the network detection method, also requires some prerequisite planning steps. For this method of detection to be efficient and to facilitate effective rule tuning, a strong baseline of legitimate replication activity should be identified.

Investigating Using a SIEM

From a SIEM alerting perspective, if the host names of the DCs are known and documented, their machine account names can be explicitly omitted from security event generation as that is expected behavior. Another way to limit the volume of logs from these events (at least from the SIEM perspective) is to implement a blocklist on the event forwarder so that only 4662 events of interest are captured and transferred to the centralized logging platform. This process and implementation will vary depending on both the log forwarder and the SIEM, and will require tailored research.

An example where the forwarder was tuned within the BLS Detection Lab is detailed below (Note: this is not specific to DCSync detection):7

The blacklist feature of the Splunk Universal Forwarder v6.1+ can be utilized to filter events. An additional line would need to be placed in Splunk_TA_windows\local\inputs.conf and pushed to the DCs.

[WinEventLog://Security] blacklist1=EventCode="4662" Message="Properties: [regex]”

There are three data fields of interest that should be correlated from the 4662 logs to identify possible DCSync activity.

1. SubjectUserName

2. AccessMask

3. Properties

For authentic replication activity the “SubjectUserName” should contain the name of the machine account of a domain controller or a variation of NT AUTHORITY/SYSTEM. This data field will need to be evaluated within the target environment that is being monitored. What is shown here is only an example. For this detection method, any logs that match the additional criteria listed below and include a regular user account in the “SubjectUserName” field, should be investigated further.

The “AccessMask” captured in the event log should be 0x100.8 This value represents “control access” and is specifically registered when access is allowed following extended rights verification (typically associated with the use of high level and explicit permissions that are required to initiate the DCSync attack).

The “Properties” field will include 2 pieces of relevant information to search for. The first is the starting string in the log example above, “%%7688”.9 This is another flag that is assigned and is associated with “Control access”. The second is the long string of characters at the end of that field, which are registered GUIDs that represent each of the RPC functions associated with the replication attempt. Through testing, the GUIDs of interest have been identified as one of three options when tracking DCSync activity.10 The 4th one listed below may also be associated, however, this has not yet been validated*.

1. {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} - DS-Replication-Get-Changes

2. {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} - DS-Replication-Get-Changes-All

3. {9923a32a-3607-11d2-b9be-0000f87a36b2} - DS-Install-Replica 4.*{89e95b76-444d-4c62-991a-0facbeda640c} - DS-Replication-Get-Changes-In-Filtered-Set

It is important to note that within the community there is some disagreement with regard to the presence of the GUID versus the more generalized statement (“Replicating Directory Changes all”) that’s captured in these logs. At this time, it is recommended to enrich the detection criteria to search for either the GUIDs or the replication statement to capture all possible scenarios. While hunting client environments for this type of activity, BLS has found this string instead of the GUIDs above.

Benjamin Delpy (@gentilkiwi), the researcher who discovered and pioneered the DCSync attack technique, has also provided a few recommended Splunk queries to hunt for this activity.11 Some of his searches have been found to be a bit generic when utilized in larger corporate environments and may produce overwhelming results. However, one of the suggestions he makes that could prove useful in tuning efforts is to exclude events where the SubjectUserSID includes “AUTHORITE NT”. This may be something to consider should the other criteria above overwhelm the Logs/SIEM with large numbers of events.

Note: For those curious about the other GUID seen in the log example above, “{19195a5b-6da0-11d0-afd3-00c04fd930c9}”, this is associated with the RPC function: WRITE_DAC. Though this will be present in each of these event logs, it is not very helpful in detecting DCSync activity specifically. This is a standard access permission to modify discretionary access control lists in an object’s security descriptor.

After testing using the BLSOPS lab environment, we were able to efficiently detect this activity successfully using the explained log criteria.

Lab Sample Splunk Query:

index=main EventCode=4662 Access_Mask=0x100 AND (“Replicating Directory Changes all” OR “1131f6ad-9c07-11d1-f79f-00c04fc2dcd2” OR “1131f6aa-9c07-11d1-f79f-00c04fc2dcd2” OR “9923a32a-3607-11d2-b9be-0000f87a36b2”) | regex Account_Name!=”\w+$”

Note: The Splunk instance used during test, the “SubjectUserName” data from the log was parsed and indexed into “Account_Name.”.

Share

Subscribe now