Research

Detecting WiFi dumping via direct WinAPI calls and introduction to “Immutable Artifacts”

Lately I’ve been reading a LOT of materials on how to write better detection rules. The main reason this whole thing started is that I’ve had a very interesting thought. Most detection rules I see on public databases such as SIGMA, SnapAttack and SOCPrime, rely on artifacts that are mutable by attackers. For example, the first thing that comes to mind when I want to detect WiFi dumping on Windows is to monitor process creating logs and look for events where the commandline contains Netsh.exe and key=clear.

This is all fine and well for a lot of the scenarios out there, but that wasn’t enough for me. The threshold required to bypass such a detection is embarrassingly low. What I want to do is to attempt to find, to the best of my ability, artifacts that are immutable. Meaning — no matter what specific technique the attacker is using to dump WiFi — the assumption is that there is an artifact(s) that must be generated every single time, regardless of the tooling/tradecraft in use.

As you can probably guess, this led me to quite the rabbit hole. The tools I’ve been using for my hunt are:

  • Windows Event Viewer
  • Sysmon
  • Procmon
  • Custom C program to dump WiFi information using direct API calls to wlanapi

The C code I have been using in this scenario can be found HERE, and it really is quite simple. When I run it, it provides the list of SSIDs stored on the machine.

The “problem” here, is that unlike using “netsh”, this code will not generate any of the more common event IDs that are usually used for detection. I used various tools such as procmon, process hacker and API monitor:

  • No obvious registry calls that I could find, even after enabling “read” auditing on any registry keys that store WiFi profile information.
  • No obvious “read” file operations on C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces, where WiFi information, including the encrypted passwords, is stored.
  • No process creation log for netsh (quite obvious, since using direct API calls).

So, what are we to do? luckily for us, the solution is both very simple, but also comes with its own price (the price being vastly increased telemetry generation).

We can leverage Sysmon’s Event ID 7 (WHICH IS DISABLED BY DEFAULT!), in order to alert on any unknown EXEs that are calling “wlanapi.dll”.

First, download and install Sysmon. For my testing purposes I have used the excellent configuration from SwiftOnSecurity. Before installing that config, we need to enable auditing for Event ID 7, which can be found in line 419:

Change the word “include” to “exclude”, which will log everything. It is HIGHLY recommended to heavily tune this before enabling on a production environment as this will generate a LOT of noise. After saving the file, run the command: sysmon.exe -accepteula -i sysmonconfig-export.xml

After that’s done, we can start working. I have run my C code EXE file, which gave me the expected output of all my stored SSIDs.

I can now use Windows Event Viewer to navigate to Application and Service Logs > Microsoft > Windows > Sysmon > Operational and filter on Event ID 7:

If I search for my EXE name, one of the events will show the following:

Which is exactly what I was looking for. To stress this again, assuming an attacker will perform this activity, in this manner (API calls), I am NOT aware of any method to capture it EXCEPT using Event ID 7 or relying on your EDR. This is quite big!

To detect this, a detection rule can be created that looks for Sysmon Event ID 7, where the ImageLoaded is wlanapi.dll and the Image contains “.exe” that is not known or expected. Of course, proper baselining is required beforehand to define whether this activity is legitimate in your organizational context, but this is a great place to start detecting more advanced techniques.

What about passwords?

I’m sure there are quite a lot of methods to dump passwords as well, but in my test case I did this using Powershell’s “[System.Security.Cryptography.ProtectedData]::Unprotect” functionality, that is also utilized in “Wifi-squid”. Any call to DPAPI’s “CryptUnprotect” will get logged under “Crypto-DPAPI” event log (also disabled by default), under event id 16385. This event ID can be correlated with the caller process ID (in my case, it was Powershell.)

To summarize, the point of this article is to challenge existing notions of many security professionals (myself included) where we rely that an attacker will utilize “known” tools and rely on various LOLBins. I wanted to see what would happen if an attacker will use direct API calls, which is very easy to implement, and which will also evade the vast majority of detections that rely on that telemetry. We should aspire to write detections that find immutable artifacts — the ones that the attacker is going to leave behind 100% of the times, and that are not subject to obfuscation, source code modifications, or anything that the attacker controls, ideally.

If you enjoyed the article, feel free to connect with me!
https://www.linkedin.com/in/daniel-koifman-61072218b/
https://x.com/KoifSec
https://koifsec.medium.com/