Auxiliary Sources
Appendix
Modern EDRs sometimes make use of less popular components known as auxiliary sources to get immensely valuable data that would otherwise be unavailable from other sensors.
Alternate Hooking Methods
Other, more robust methods of intercepting function calls exist, such as using the Microsoft-Windows-Threat-Intelligence ETW provider to indirectly intercept certain syscalls in the kernel, but these have their own limitations.
There also exists Nirvana hooks. This technique intercepts the point at which the syscall returns to user mode from the kernel. This allows the agent to identify syscalls that didn’t originate from a known location, such as the copy of ntdll.dll mapped into a process’s address space.
There are a few notable downsides to this hooking method, though. First, it relies on an undocumented PROCESS_INFORMATION_CLASS and associated structure being passed to NtSetInformationProcess() for each process the product wishes to monitor.
Because it isn’t formally supported, Microsoft may modify its behavior or disable it entirely at any time. Additionally, the developer must identify the source of the call by capturing the return context and correlating it to a known good image in order to detect manual syscall invocation.
Lastly, this hooking method is simple to evade, as adversaries can remove the hook from their process by nulling out the callback via a call to NtSetInformationProcess(), similarly to how the security process initially placed it.
Having multiple techniques for achieving the same effect provides advantages for defenders, as one method may work better in some contexts than others. For this reason, some vendors have leveraged alternative hooking methods in their products to augment their ability to monitor calls to suspicious functions.
RPC Filters
RPC traffic is notoriously difficult to work with at scale. One way EDRs can monitor it is by using RPC filters. These are essentially firewall rules based on RPC interface identifiers, and they’re simple to create and deploy using built-in system utilities. An example is shown below:
netsh> rpc filter
netsh rpc filter> add rule layer=um actiontype=block
Ok.
netsh rpc filter> add condition field=if_uuid matchtype=equal \
data=e3514235-4b06-11d1-ab04-00c04fc2dcd2
Ok.
netsh rpc filter> add filter
FilterKey: 6a377823-cff4-11ec-967c-000c29760114
Ok.
These commands add a new RPC filter that specifically blocks any communications using the Directory Replication Service RPC interface (which has the GUID E3514235-4B06-11D1-AB04-00C04FC2DCD2). Once the filter is installed via the add filter command, it is live on the system, prohibiting DCSync. Whenever the filter blocks a connection, the Microsoft-WindowsRPC provider will emit an ETW.
A better option may be to consume a similar event from the MicrosoftWindows-Security-Auditing Secure ETW provider. Since this provider is protected, standard applications can’t consume from it. It populates Event ID 5157 whenever the base filtering engine blocks a request.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994
-A5BA-3E3B0328C30D}" />
<EventID>5157</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12810</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2022-05-10T12:19:09.692752600Z" />
<EventRecordID>11289563</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="3444" />
<Channel>Security</Channel>
<Computer>sun.milkyway.lab</Computer>
<Security />
</System>
<EventData>
<Data Name="ProcessID">644</Data>
<Data Name="Application">\device\harddiskvolume2\windows\system32\lsass.exe</Data>
<Data Name="Direction">%%14592</Data>
<Data Name="SourceAddress">192.168.1.20</Data>
<Data Name="SourcePort">62749</Data>
<Data Name="DestAddress">192.168.1.5</Data>
<Data Name="DestPort">49667</Data>
<Data Name="Protocol">6</Data>
<Data Name="FilterRTID">75664</Data>
<Data Name="LayerName">%%14610</Data>
<Data Name="LayerRTID">46</Data>
<Data Name="RemoteUserID">S-1-0-0</Data>
<Data Name="RemoteMachineID">S-1-0-0</Data>
</EventData>
</Event>But this has limitations, the interface ID is missing, making it difficult to determine whether the event is related to the filter that blocks DCSync attempts or another filter entirely. It is also inconsistent across various versions.
Hypervisors (Intel VT-x)
When a virtualized guest system attempts to execute an instruction or perform some action that the hypervisor must handle, a VMEXIT instruction occurs. When this happens, control transitions from the guest to the hypervisor.
The Virtual Machine Control Structure (VMCS) preserves the state of the processor for both the guest and the hypervisor so that it can be restored later. It also keeps track of the reason for the VMEXIT. One VMCS exists for each logical processor of the system.
When the hypervisor enters root-mode operation, it may emulate, modify, and log the activity based on the reason for the VMEXIT. These exits may occur for many common reasons, including instructions such as RDMSR, for reading model-specific registers, and CPUID, which returns information about the processor.
After the completion of the root-mode operation, execution is transferred back to non-root-mode operation via a VMRESUME instruction, allowing the guest to continue.
Most EDRs that implement a hypervisor take the Type 2 approach. Even so, they must follow a complicated series of steps to virtualize an existing system. A hypervisor can provide visibility into system operations at a layer deeper than nearly any other sensor.
Some use cases of these hypervisors are -
Virtual Machine Detection - Some malware attempts to detect that it is running in a virtual machine by issuing a CPUID instruction. Since this instruction causes a VMEXIT, the hypervisor has the ability to choose what to return to the caller, allowing it to trick the malware into thinking it isn’t running in a VM.
Syscall Interception - A hypervisor can potentially leverage the Extended Feature Enable Register (EFER) function to exit on each syscall and emulate its operation.
Control Register Modification - A hypervisor can detect the modification of bits in a control register, which is behavior that could be part of an exploit. Additionally, the hypervisor can exit when a control register is changed, allowing it to inspect the guest execution context to identify things such as token-stealing attacks.
Memory Change Tracing - A hypervisor can use the page-modification log in conjunction with Extended Page Tables (EPT) to track changes to certain regions of memory.
Branch Tracing - A hypervisor can leverage the last branch record, a set of registers used to trace branches, interrupts, and exceptions, along with EPT to trace the execution of the program beyond monitoring its syscalls.
Last updated