Bypassing ETW, Sysmon, EventLog and Command-Line-Argument Spoofing


m3rcer

Bypassing ETW

User-Mode Attacks

Block Logging Events using EtwEventWrite ret patch

ETW providers are loaded in process memory as dlls which log events using the EtwEventWrite API function call.

The EtwEventWrite function defintion is as follows for 32bit and 64bit applications:

  • 32bit:

  • 64bit:

This technique originally researched by [Adam Chester](https://twitter.com/xpn) from MDSec is one of the most popular techniques for ETW bypasses. It can be used for the current process or also a target remote process accessible by our current user context. In short this works by using the ret opcode seen at the EtwEventWrite function end to patch the beginning of the subroutine to avoid its intended execution flow executing the ret opcode initially to return without writing any events. This way all ETW events can be stopped from being logged for the current process.

Adam Chester originally showcased the technique for 32bit using the following patch:

  • 32bit: 
    \xc2\x14\x00\x00 --> ret 14h

Minor variations of this patch are publically available. For example Sektor7 showcases this technique with the following patch to zero out the registers before returning using the ret opcode:

  • 32bit: 
    \x33\xc0\xc2\x14\x00 --> xor eax, eax; ret 14
  • 64bit: 
    \x48\x33\xc0\xc3 --> xor rax, rax; ret

The control flow of EtwEventWrite can be modified using: • Function patching with RET • Import Address Table (IAT) Hooking • Inline hooking

For instance, TamperETW by Outflank is a slight modification of this technique which allows using native system calls to hook the EtwEventWrite to redirect flow to a custom MyEtwEventWrite function and selectively forward .NET ETW events.

Another reimplementation called BypassETW_CSharp uses RtlInitializeResource API to patch the target EtwEventWrite function the same way to stop ETW events being logged for the current process.

To use this technique in a remote process we can use injectEtwBypass by boku7 which patches the EtwEventWrite function using a ret opcode in a target remote process accessible by our current user context.

Demo within current process

We can detect Seatbelt’s execution in memory using the Microsoft CLR Runtime ETW Provider with a GUID {e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}. Using SilkETW and a simple yara rule we can detect SeatBelt’s MethodNameSpace: (Seatbelt.Seatbelt) to view the ETW .NET trace events. Process hacker can also used to analyze events from the .Net Runtime ETW Provider.

Yara rule:

rule Seatbelt_MethodNameSpace
{
    strings:
        $s1 = "MethodNamespace=Seatbelt.Seatbelt" ascii wide nocase

    condition:
        all of ($s*)
}

Cobalt Strike and the inlineExecute-Assembly aggressor are used to execute Seatbelt within the current beacon process context.

Viewing events generated by SilkETW:

Viewing the loaded .NET assemblies using Process Hacker:

Now using the –etw flag within inlineExecute-Assembly it is possible to bypass ETW using the the EtwEventWrite patch to find no ETW .NET runtime events generated by SilkETW for the beacon process.

No ETW events are forwarded. Viewing for .NET assemblies in the beacon process using Process Hacker:

To specifically bypass yara rules such as for method/namespace names as above and blend into the ETW .NET trace events we can implement custom AppDomain Names using the –appdomain argument and unique named pipe names using the –pipe argument within inlineExecute-Assembly.

Demo with a remote process

We target a powershell process spawned by our current user with a PID:3472 to inject our ETW bypass into.

We use the injectEtwBypass aggressor which implements **Sycalls via Halos HellsGate** for lesser visibility avoiding commonly abused Win32 APIs to inject the same EtwEventWrite patch as follows.

Disable .NET ETW providers using COMPlus_ETWEnabled envar

A quick way to only disable the Microsoft CLR Runtime Provider referencing the GUID {e13c0d23-ccbc-4e12-931b-d9cc2eee27e4} yet again researched by Adam Chester is by setting the environment variable  COMPlus_ETWEnabled to 0.

From Adam Chester’s Blog it is stated that COMPlus_* settings provide developers via environment variables or registry value a number of configuration options which can be set at runtime with various levels of impact on the CLR, from loading alternative JITters, to tweaking performance and even dumping the IL of a method.

If COMPlus_ETWEnabled=0 is enabled, the CLR will jump past the block of ETW registrations to the .NET ETW providers, this way avoid logging any .NET assemblies within the current process context.

Demo within current process

Adam Chester has developed a POC to showcase this along with his developed argument spoofing technique to hide the COMPlus_ETWEnabled=0 variable from CreateProcess. We will be using this POC to disable .NET assembly ETW trace events.

Compiling the source using x86_64-w64-mingw32-g++ and executing the POC spawns a powershell prompt with added Command line Argument spoofing over the COMPlus_ETWEnabled=0 bypass hence disabling all .NET assembly ETW trace events for the spawned powershell process.

Other variations

Since the discovery of the attack on the envar COMPlus_ETWEnabled, variations have emerged as showcased in this blog

  • Disable tracing for services.exe by disabling the registry key: TracingDisabled located at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Tracing\SCM\Regular. (Requires admin privileges)

  •  Similarly rpcrt4.dll can be disabled to avoid RPC generated events using the registry key ExtErrorInformation at: HKLM\Software\Policies\Microsoft\Windows NT\Rpc. Here’s a POC to find ETW handles in rpcrt4.dll.

Unregister and disable ETW providers

This method was researched by modexp and details how to register and disable a specific ETW provider for a target process. Here’s the blog detailing how modexp managed to do this. Also he has released a POC which can be found here

In short, ETW providers register using the advapi32!EventRegister API, this is forwarded to ntdll!EtwEventRegister. This API validates arguments and forwards them to ntdll!EtwNotificationRegister. The caller provides a unique GUID that represents a provider on the system, an optional callback function and an optional callback context. This Callback function for a provider is invoked in request by the kernel to enable or disable tracing. This way Registration handles can later be used with EventUnregister to disable tracing.

ETW Dump is the POC released showcasing this and can also display information about each ETW providers in the registration table of one or more processes as follows.

Demo with Remote Process

In this case we target powershell.exe. The Callback function as stated earlier for a provider is invoked in request by the kernel to enable or disable tracing. For the CLR, the relevant function is clr!McGenControlCallbackV2. Code redirection is achieved by replacing the callback address with the address of a new callback (shellcode) which must use the same prototype which can be done via NtTraceControl.

modexp unregisters a specifc provider in his POC by passing the registration handle to ntdll!EtwEventUnregister. In this instance he disables the .NET Runtime provider for a target powershell process running under our current user privileges. Examining with SilkETW after disabling the provider we dont find any new .NET ETW events for the spawned powershell process.

Obfuscating .NET assemblies

It is possible to obfuscate .NET assemblies using tools like ConfuserEx or an LLVM-Obfuscator to break yara .NET ETW signatures and bypass ETW selective .NET events whose detection rely on specific yara signatures.

Kernel-Mode Attacks

ETW Session Hijacking

This attack vector was originally researched by Binarly.io and details the research in this blog. An ETW session is a global object identified by a unique name that allows multiple ETW consumers to subscribe and receive events from different ETW providers. The default number of simultaneously running sessions is 64. The NT kernel supports a maximum of 8 System Logger Sessions with hardcoded unique names.

Process Monitor is a tool for malware analysis which uses the same technology as many EDRs. Process Monitor version 3.85 uses a session called PROCMON TRACE to record network events. An attacker can stop a target ETW session using Session names like the PROCMON TRACE session and start fake ones instead to stop the consumer, in this case Process Monitor 3.85 from recieving any events. Relaunching Process Monitor too does not fix this attack.

To hijack a Secure ETW session like Windows Defender ETW Sessions different principles apply since we cannot stop the Defender ETW sessions and hijack it as for Process Monitor. Defender uses the two ETW sessions: DefenderApiLogger and DefenderAuditLogger. They are run on startup as Autologger Sessions and hence can be disabled by:

  1. Modifying the Startup registry setting: reg add “HKLM\System\CurrentControlSet\Control\WMI\Autologger\DefenderApiLogger” /v “Start” /t REG_DWORD /d “0” /f
  2. Each Defender ETW session has a security descriptor in registry. By patching the values in registry it is possible to modify the Defender ETW session security descriptors.
  3. It is possible to load a malware driver to patch the WMI_LOGGER_CONTEXT structure while using the QueryAllTracesW() / StopTraceW() APIs to stop or query a Secure ETW Defender session (not stoppable and running with high privs by default).

Demo hijacking PROCMON TRACE ETW Session

ORCx41 has released a POC demonstrating this attack. This works by stopping the target ETW session and starting one under the same name. It then checks for the status of the newly started malware session and if terminated it can repeat the process from the beginning. As long as this malware created session is active network events aren’t detected.

We start up ProcMon and analyze all network events after visiting a site on chrome as follows:

After running the ETW Procmon Session Hijacker and revisiting a site on chrome no Network events are further generated.

Using Custom Sycalls

Attacker can call custom Syscalls which dosen’t include ETW instrumentation and information about the call to avoid logging.

ETW utilizes built-in Syscalls to generate telemetry. Since ETW is a native feature built into Windows, security products do not need to “hook” the ETW syscalls to gain this information. As a result, to prevent ETW, ScareCrow patches numerous ETW syscalls, flushing out the registers and returning the execution flow to the next instruction. This is enabled by default and to disable this feature use the -noetw argument.

Demo With ScareCrow

Compile Cobalt strike Shellcode using ScareCrow into an executable with ETW patched as follows:

Examining the ScareCrow beacon process after .NET execution within the process using Process Hacker we find no .NET assemblies tab loaded.

Examining with SilkETW and a basic yara rule to detect Outlook.exe process name via .NET generated events, we find no .NET logs generated from the loader Outlook.exe process.

  • Yara rule:
rule Outlook_ScareCrowProcessNameDetection
{
    strings:
        $s1 = "ProcessName=Outlook" ascii wide nocase

    condition:
        all of ($s*)
}

Bypassing Sysmon

User-Mode Attacks

Bypassing Sysmon Configs

Sysmon Configuration files are detection rules written as XML templates and it is easy to find blindspots in these configuration files for unaccounted execution beyond its scope.

It is possible to retrieve Sysmon Configuration files in a number of ways, via registry / Get-SysmonConfiguration.ps1 (admin privileges needed). If lucky it is possible to find the sysmon configuration file with misconfigured ACLs accessible with user privileges. It is possible to use a tool such as sysmon-config-bypass-finder / SysmonRuleParser.ps1 to find loopholes within the configuration file to perform malicious execution without leaving any Sysmon Logs.

There are 2 more methods to tamper with Sysmon Configs which is mentioned in the next section.

Bypass Sysmon ETW DNS Tracing

Adam Chester researched and detailed how DNS ETW events can be patched similar to his first bypass and showcased this in his blog.

In short, DNS events generated are sent to the Microsoft-Windows-DNS-Client from within DnsApi.dll. Since this dll is loaded within the current process we can control its execution flow. It is possible to patch the DNSAPI!McTemplateU0zqxqz routine using a simple ret opcode during runtime to return execution without sending an event via EtwEventWriteTransfer.

Here is the POC released by Adam Chester. This POC can be coupled with other Sysmon ETW bypass techniques like driver unloading/Altitude number collision where DNS entries persist because of the unloading of Microsoft DNS ETW providers/kernel minidrivers.

Demo to patch the DNS ETW provider.

We use the above POC to patch the DNS ETW provider to disable forwarding any DNS ETW events and once done ping google.com using the DnsQuery_A WINAPI to test this as follows. As a result we see only a PROCESSS_CREATION Event with the latest SwiftOnSecurity sysmon-config.

Kernel-Mode Attacks

Unloading the Sysmon Driver

It is possible to unload the Sysmon Kernel minidriver from memory which effectively kills only the kernel portion of sysmon using fltmc: fltmc unload <driver name>. This requires SE_LOAD_DRIVER privileges.

Implications:

  • Once the driver is unloaded, an error event with an ID of DriverCommunication will be generated.

  • Error log stating couldn’t recieve events and some logging functionality persists like DNS queries because of the use of seperate ETW providers (Sysmon uses other Microsoft ETW providers too for logging)

  • Command line logging would be captured by Sysmon before the driver is unloaded.

  • Since this technique requires the SeLoadDriverPrivileges an audit is logged for its usecase.

  • FilterManager reports that a File System Driver was unloaded succesfully:

A reboot would fix and load back the Sysmon Driver.

Demo using Shhmon

Another way to perform this attack is by using Shhmon explained in this Blog which uses WIN APIs to perform the same unloading process. One implication it helps evade is the initial command line logging which would be captured by Sysmon before the driver is unloaded.

Disabling Sysmon functionality with Co-Existing Altitude Numbers

Sektor7 showcased that by changing the altitude number of the Sysmon Kernel Minidriver to that of an already existing minidriver it is possible to break Sysmons functionality and disrupt the Sysmon Minidriver from processing Sysmon events.

Query Sysmon Minidriver Altitude using fltmc or registry: reg query “HKLM\SYSTEM\CurrentControlSet\Services\Sysmondrv\Instances\Sysmon Instance”

Most of the times the Symon Altitude Number would remain constant but it is possible to change this.

2 minor drawbacks of this method is that it leaves and error log for loading the kernel driver and the second that it requires a reboot to make it effective.

Demo showcasing Sysmon Altitude Collision Attack

Let us target the WDFilter - \Device\Mup Minidriver and change Sysmon’s Altitude to its Altitude Number.

Change Sysmon Altitude using registry: reg add “HKLM\SYSTEM\CurrentControlSet\Services\Sysmondrv\Instances\Sysmon Instance” /v Altitude /t REG_SZ /d 328010 /f

To make this effective reboot the machine. Verify Sysmons existence using fltmc instances to find no Sysmon Minidriver:

Checking EventViewer after simulating a Sysmon Event using SysmonSimulator we find an error log loading the Kernel Minidriver hence effectively killing the kernel portion of Sysmon. However DNS queries could still be logged since it depends on a seperate DNS ETW provider.

Patching Sysmon EtwEventWrite events: Sysmon-Gag

As before, it is possible to get a handle to the SysmonDrv process and patch (ret) EtwEventWrite to disable writing Sysmon ETW events as a whole. This was showcased by Sektor7 and termed it Sysmon-Gag.

Performing this technique avoids all Sysmon events, including DNS log entries and Error Log messages.

Sysmon functionality can be restored with a simple system or service restart.

An RDLL POC implementation of this technique can be found on github: SysmonQuiet

Demo with Sysmon-Gag

Executing Sysmon-Gag and note to see that the Sysmon Kernel minidriver portion is untouched:

Testing Process Creating and DNS events using Sysmon Simulator we find no events generated:

Injecting code into Sysmon to redirect execution flow: SymonEnte

This technique researched by codewhitesec involves injecting code into Sysmon which redirects the execution flow in such a way that events can be manipulated before being forwarded to the SIEM. Here is the POC detailing the research.

In short as per the blog it works as follows:

  • Suspend all threads of Sysmon.
  • Create a limited handle to Sysmon and elevate it by duplication.
  • Clone the pseudo handle of Sysmon to itself in order to bypass SACL as proposed by James Forshaw.
  • Inject a hook manipulating all events (in particular ProcessAccess events on Sysmon).
  • Resume all threads.

Additionally, SysmonEnte uses indirect syscalls to bypass possible userland hooks.

The Repo provides two ways to use SysmonEnte, one via inject shellcode - SysmonEnte.bin and the second via using a loader - EntenLoader.exe <PID Sysmon>

Bypassing Sysmon Configs

The second way to circumvent and operate in the configuration blindspots is to delete the Sysmon Configuration file. We can clear these configs in the registry. Sysmon will see the registry being changed and it will automatically reload the configuration and since no rules are present it will be blinded temporarily allowing to operate in a small time frame without detection depending on how the configuration is maintained. One major giveaway of this technique is that process creation and process termination events will have a blank rule name in them.

Lastly, it is possible to mess with Sysmon Configs by replacing the original with one of the attackers chosing. There is a technique showcased by Sinaei on twitter. Basically, whenever Sysmon detects a configuration change, it calls DeviceIoControl with the 0x83400008 IOCTL in order to tell SysmonDrv.sys to update its rules and then Sysmon sends a Event ID:16: Sysmon config state change to Event Logs. It is possible to create and configure a very permissable Sysmon Config by modifying the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SysmonDrv\Parameters and send a 0x83400008 IOCTL directly after without sending an update changed notification to Event logs. This POC was tested for Sysmon version 9.21 and prior.

Universally Bypassing ETW and Sysmon

Kernel-Mode Attacks

Leveraging InfinityHook to hook NtTraceEvent

This technique was researched by batsec. Here is the blog and POC detailing the research.

As per the blog, Sysmon64.exe uses the ReportEventW Windows API call to report events. Going deeper down the call chain it is found that ReportEventW in ADVAPI32.dll is essentially a wrapper around EtwEventWriteTransfer which is defined in NTDLL.dll. By examining EtwEventWriteTransfer it is found that it calls the kernel function NtTraceEvent which is defined inside ntoskrnl.exe.

It is possible to patch the nt!NtTraceEvent function with a ret instruction to avoid returning any events. Since this is a kernel function we need to have our hooking code running inside the kernel space as well and bypass protections like Kernel driver signing enforcement and PatchGuard. The author leverages InfinityHook to bypass these protections and hook the nt!NtTraceEvent to our DetourNtTraceEvent which if returns any non zero value return STATUS_SUCCESS signifying that the event was reported successfully, which in reality wasn’t.

Since this is a universal bypass, it should stop ETW and Sysmon events for all processes.

Demo to perform a ETW/Sysmon universal bypass

We can begin testing if Sysmon is universally disabled for all processes. A simple test would be to spawn a powershell process after using the universal bypass to check if Sysmon reports the PROCESS_CREATE event.

Load the driver and set the hook:

Enable the hook:

Spawning a new powershell prompt we find there are no logs logged by Symon.

It is also possible to check this using SysmonSimulator to test Process Creation to find no new events:

Starting SilkETW and noting for .NET ETW events after spawning a Powershell Prompt we find no events reported:

Analysing the spawned PowerShell Prompt using ProcessHacker we find no .NET assemblies loaded:

Disable the hook, enabling all logging:

Bypassing EventLog

Kernel-Mode Attacks

Killing Event Log Threads using Phant0m

It is possible to target the Event Log detect and kill the threads responsible for the Event Log service. Doing so would result in the Event Log service appear to be running but intrun the system does not collect logs since the threads required for log collection were terminated.

This concept was originally introduced by the Shadow Brokers leak of NSA’s eventlogedit.

Phant0m is a good POC for this technique of disabling Event Logs from being logged via Event Log Thread termination. It leverages two techniques to perform this.

The first technique leverages the TEB block (thread environment block) to find the numeric tag of the target Event Log Service and kill its corresponding threads responsible for the Event Logging functionality. The second method leverages dlls associated with the Event Log threads to validate if these threads are using the specific dll and if the thread is using that DLL, it is the Windows Event Log Service’s thread and then Phant0m kills the thread.

Demo universally disabling all Event Log Events

A custom view is created to log all events in the Event Log Service for demo purposes.

Analysing threads of the EventLog Service process using Process Hacker:

Execute phant0m to terminate EventLog threads:

Analysis of EventLog Service threads after phant0m execution:

Making a small change to Local Security Policy we find no new logs generated in our Custom View

Block Specifc Yara Events via hooking EtwEventCallback

This technique was researched by Jumpsec Labs. Here is the blog detailing the research.

Basically wevtsvc.dll which is the Event Log service uses OpenTraceW to open a tracing session. OpenTraceW takes the EVENT_TRACE_LOGFILEW structure as an argument. This structure has the value EventRecordCallback which points to the callback function that will be given the event. The callback function is just a bit of assembly that will call EventCallback. This callback receives the event in the EVENT_RECORD structure which contains info about the event including the ETW provider. It is possible to hook this callback to our own yara callback and patch it to return no events and also restore it dynamically so that events that aren’t targetted can be delivered.

EvtMuteHook.dll contains the core functionality, (via hooking EtwEventCallback) once it is injected it will apply a temporary filter which will allow all/selective events to be reported, this filter can be dynamically updated without having to reinject the dll. SharpEvtMute.exe is its C# .NET assembly implementation compatible with execute-assembly/inlineExecuteAssembly.

Demo with SharpEvtMute

We use the same Yara rule along with SilkETW and execute Seatbelt using inlineExecute-assembly from Cobalt Strike to detect Seatbelt execution based on Methodspace Names.

Start by injecting the hook into the event service. Next, once the hook is placed add the following filter to drop all yara events by EventViewer.

Note: It is possible to use other complex yara filters to filter specific criteria.

As noted from the output, after executing Seatbelt using inlineExecute-Assembly from Cobalt Strike, SilkETW crashes after the first rule detection and fails to write to the EventLog.

Event Log Manipulation using EventCleaner and Eventlogedit-evtx–Evolution

EventCleaner and Eventlogedit-evtx–Evolution combines the method of Event Viewer Thread Tampering (showcased in previous section), Duplicating Handles and Event Record Manipulation to disrupt the Event Log Service and manipulate/delete induvidual logs. The only difference between the two is that EventCleaner disrupts the Event Log service and deletes the target malicious log leaving out a gap between sequential record id’s, while Eventlogedit-evtx–Evolution does the same but after deleting the target malicious log restores it in a way with sequential record ids.

Demo universally disabling Event Log and tampering a specific event using EventCleaner

As an example we modify the Password Policy in Local System Policy which generates the following event with a Event Record ID:244.

We will be targetting to clear this specific event using EventCleaner. Begin by suspending the Event Log threads:

Duplicate the handle on the security.evtx file and close the current handle:

It is noted that the Event Log service no longer has a file handle for security.evtx:

Delete the EventRecordID:244, fix the checksums, and restore the file handle.

Resume the threads of the service:

Inspecitng security.evtx it is observed that the EventRecordID skips from 243 to 245, hence the target EventRecordID:244 was succesfully deleted. However this attack can be detected due to non-sequential EventRecordIDs.

Demo universally disabling Event Log and tampering a specific event using Eventlogedit-evtx-Evolution

We can improve on the previous demo to avoid non-sequential EventRecordIDs using Eventlogedit-evtx-Evolution. We use the same example as before changing the Password Policy using Local System Policy to generate a Security Event with a EventRecordID: 4739

As with the previous attempt, our first step is to suspend the threads of the EventLog service as follows:

We next use the EvtExportLog WinAPI to copy the current Security.evtx log, excluding a specific EventRecordID as follows:

Use DeleteRecordbyGetHandleEx.exe, to move temp.evtxto replace Security.evtx by duplicating the file handle on the file as follows:

Finally resume the threads with SuspendorResumeTid.exe as follows:

We’ve now successfully replaced the log without evidence of EventRecordID inconsistencies.

Command-line Argument Spoofing

Cobalt Strike 3.13 introduced the argue aggressor command showcasing argument spoofing intially. Adam Chester improved on this and wrote a good blog describing his add reimplementations with a good POC.

In short tools like Process Hacker use APIs such as NtQueryInformationProcess to retrieve the PEB (Process Environment Block) structure from a target process and then enumerate process arguments from ProcessParameters located within the PEB structure. It is possible to update ProcessParameters structure to hide arguments passed to the process.

It is possible to perform this by first spawning our target process in a suspended state using the CREATE_SUSPENDED flag within the CreateProcessA API. Next parsing and grabbing the PEB structure address using the ReadProcessMemory API. We then parse the ProcessParameters structure field within the read PEB Structure to read the process arguments which is of type struct UNICODE_STRING. It is possible now to update the arguments by writing to the UNICODE_STRING.Buffer address within struct UNICODE_STRING using WriteProcessMemory after which resume execution with ResumeExecution API.

This is how basically the argue aggressor worked but tools like Process Hacker actually retrieve a copy of the PEB each time the process is inspected, meaning that spoofed arguments will be revealed. Adam Chester improved on this technique with a slight modifications by creating a corrupted UNICODE_STRING which did hide arguments from tools like Process Hacker and next tried setting the Length parameter to be less than the size of the string set within the Buffer to make the remainder of the command line hidden (Unicode length of process name). This worked efficiently for spoofing arguments with Sysmon detection and tools like Process Hacker could no longer read command line arguments.

NOTE: Make sure to keep the length of the spoofed arguments longer than the actual arguments.

There are many reimplementations of this POC such as: CmdLineSpoofer and PEB-PPIDspoofing_Csharp

Demo with DNS-ETW Bypass POC

Executing Adam Chesters POC we note that Process Hacker dosen’t include any command line arguments:

Examining with Sysmon we find the spoofed command line arguments:

Actual command line arguments executed from POC source are:

Conclusion

As defensive teams strive to various defense mechanisms, understanding and anticipating these evasion techniques is critical. Leveraging both traditional and novel attack vectors ensures that attackers can bypass traditional monitoring and maintain operational security.

Credits

  • Adam Chester (@xpn)
  • Outflank
  • boku7
  • modexp (@modexpblog)
  • Sektor7
  • Microsoft