farmpoet Profile picture
Jan 7, 2022 11 tweets 5 min read Read on X
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) Image
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) Image
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) Image
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) Image
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) Image
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)

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with farmpoet

farmpoet Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @f4rmpoet

Aug 22
Let's explore China’s 0-day vulnerability research capabilities.
I’ve long been intrigued by the prolific nature of Chinese teams in discovering vulnerabilities. Over the past months, I’ve gathered some data and analyzed reported vulnerabilities to gain a deeper understanding.🧵 Image
Since September 2021, the Chinese government has mandated that any Chinese researchers, businesses, or even foreign companies operating in China who discover 0-day vulnerabilities must report the details to the Chinese Ministry of Industry and Information Technology (MIIT)
The policy in question was formalized through the "Provisions on the Management of Network Product Security Vulnerabilities" issued by MIIT, which obliges entities to report vulnerabilities within within two days (48 hours) of their discovery. chinalawtranslate.com/en/product-sec…
Read 25 tweets
Aug 19
It's time to take a closer look at CVE-2024-38063 (Windows TCPIP RCE).
I usually don't post partial analysis but since most available info is unreliable I'll do my best to try and shed some light.
This time I'll focus on my workflow and thought process as we go. 🧵
MSFT advisory pretty much tells us where to look.
Our target is the tcpip.sys kernel driver which got an update during last patch tuesday.
For the analysis I picked binaries for Windows 11 23H2, builds 3958 (pre-fix) and 4036 (post).
Diffing shows a single function has changed. Image
In fact, this is the best you could hope for on binary diffing.
Further inspecting the differences on Ipv6pProcessOptions() it comes down to a single change at the end.
A call to IppSendErrorList() has been replaced by IppSendError(). Couldn't get simpler than this right? 😅 Image
Read 24 tweets
Jun 29
Some final notes on CVE-2024-30078 (wifi RCE) exploitability.
If you haven't already done so, I recommend you first take a look at my previous thread on the subject.
🧵

As previously noted, the native driver does not account for 4 extra bytes when the ether type is 0x8100 (Vlan tagged net).
Since the packet is rewritten on the original buffer, it will do so 4 bytes ahead of what is was supposed to because of the dot1q header that should exist.
This will not only corrupt the translated packet (which will be later discarded as invalid) but also overwrite up to 2 bytes outside the MDL buffer that holds the packet. [overflowed bytes marked in red]
But is the exploitability feasible? Image
Read 10 tweets
Jun 23
MSFT released a patch for CVE-2024-30078 (Wi-Fi Driver RCE) on June cumulative update, however details on the advisory have been very limited.
I'm leaving some quick notes from a quick reverse engineering of the patch that hopefully will shed a little more light on the issue. 🧵
I am not an expert on wireless network protocols so feel free to correct me or add up on the provided info in the comments or through a DM.
The patch targets Dot11Translate80211ToEthernetNdisPacket() of the native wifi driver (nwifi.sys).
The patch expands on a previous check at the beginning of the function which is described in the pseudocode below:

MDL_packetSize = MDL->ByteCount;
if (MDL->ByteCount < (MAC_frame_size + 8))
return NDIS_STATUS_INVALID_PACKET;
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(