Thread by @farmpoet_eth

Inspired by @osxreverser analysis of NSA BPF port-knocking implant, I decided to take a 2nd look at #ShadowBrokers leak of windows implants. Lo and behold, a couple of hardly mentioned kernel drivers (#DoormanGauze and #FlewAvenue) caught my attention. (1/11)

Information publicly available on these drivers is scarce and for the most part flat out wrong. Instead of going for the usual deep-dive blog post, lets try a light-speed tweeter thread analysis. In this thread we'll take a brief look at #DoormanGauze. (2/11)

So, what is #DoormanGauze... In a nutshell, its a plugin for #DanderSpritz / #ExpandingPulley implants implementing an in-kernel mailslot server, allowing for stealthy inter-process communication. This can replace the usual named pipes/windows sockets IPC. (3/11)

The module follows a typical NDIS filter driver, implementing 11 IOCTLs that can be called by other drivers or from userland code. These range from getting version, registering mailslots, fetching status for single/all slots, send messages and clearing triggers. (4/11)

The driver implements 25 slots, which can be individually registered and messages delivered to. Internally a structure is kept which keeps track of slot index, bound process, comms path, last trigger time and status. (5/11)

Strings are obfuscated with a single byte XOR (0x77), and are decoded in memory strictly for the time needed before getting wiped from memory. Other than this, no other attempts are made to obfuscate or otherwise hinder reversing the code. (6/11)

The leak contains both i386 and x64 versions, as well as the respective userland DLLs for interaction with the driver. On load, the driver registers a device and symlink, enumerates ethernet network adapters through registry and bounds to them in order to filter traffic. (7/11)

After the filter is active, all packets on bound interfaces are parsed, checking for IPv4 or IPv6 headers, and delegating execution to the respective parsing routine. These functions sieve the traffic for packets containing specifically crafted data payloads. (8/11)

Parsing roughly checks for a 6 byte tail with data length and MAGIC words XORed respectfully with 0x55aa and 0xaa55. These must further match a 2 byte header to be accepted and the data delivered to the mailslot. Some further checks are made for ICMP and TCP packets (9/11)

If the packet matches the expected payload, the data is dispatched to the registered mailslots, updating the trigger time. If an error is detected while dispatching the message, that mailslot is unregistered to prevent receiving further messages (10/11)

This light-speed/ultra-condensate type of analysis deceitfully hide several hours of reversing. If you find this format useful and would like to see more of these, leave a like or retweet. If a more in-depth blog post is preferred do let me know. (11/11)