Category Archives: Software Releases

Detecting sniffers with HSD

Posted on by

I am aware of two command line tools available ‘on the market’ that are free and can be used to detect sniffers:

  • promiscdetect.exe by Arne Vidstrom from ntsecurity.nu
  • promqry.exe from Microsoft.

The first one i.e. promiscdetect.exe detects promiscuous mode of network cards by enumerating the entries that can be found under the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards

It does not ‘see’ all devices/interfaces.

The second tool is better – promqry.exe ‘sees’ all interfaces yet the tool requires .NET and is quite slow. It is understandable, because it is a .NET application and it ‘talks’ to WMI to retrieve the information it needs.

The very same concept that is used by promqry.exe can be implemented with a simple vbs script e.g.:


Set wmi = GetObject("winmgmts:\\.\root\WMI")
Set items = wmi.ExecQuery("SELECT * FROM MSNdis_CurrentPacketFilter", "WQL", 48)
For Each oneitem In items
if (oneitem.NdisCurrentPacketFilter And 32) then
WScript.Echo "InstanceName: " & oneitem.InstanceName
WScript.Echo "Promiscuous mode detected!"
end if
Next

You can then run such script with cscript.exe or wscript.exe.

Using wrappers is nice and easy, yet not everyone wants to run commands that may in the end trigger execution of other applications/services, and/or create extra Prefetch files, especially during volatile data acquisition.

Removing the wrappers and talking directly to devices to get their status on promiscuous mode is quite simple. As mentioned, what both .NET or VBS scripts really do is talking directly to WMI. Conceptually WMI must find the device names for each of the interfaces and send them some status requests, but well, who knows what is really going on under the hood there.

Luckily, many people have researched it before and we can assume that at some stage the enumerated devices are being sent a IOCTL_NDIS_QUERY_GLOBAL_STATS/OID_GEN_CURRENT_PACKET_FILTER request via DeviceIoControl API. If the returned value has a NDIS_PACKET_TYPE_PROMISCUOUS (0x20) bit on, it means the promiscuous mode for this particular device is enabled. Yes, it is that simple. While Microsoft says ‘This IOCTL will be deprecated in later operating system releases. You should use WMI interfaces to query miniport driver information. For more information see, NDIS Support for WMI.’, I don’t see any reason why we shouldn’t be using it until they actually do 🙂

So, how can we enumerate all interfaces?

We can certainly talk to devices listed under the NetworkCards key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards

We can also talk to network devices listed under the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}

as explained 8 years ago here.

And this is precisely what Hexacorn Sniffer Detector (HSD) does. It is written in x86 asm, so it’s pretty small. It ‘encapsulates’ the functionality of promiscdetect.exe and promqry.exe as well as the technique described on SecurityFriday page.

Yes, it is slightly overengineered solution as the same device can be requested for status twice, but at least we have a certainty nothing is missed 🙂

To avoid noise, HSD reports only these devices that are in a promiscuous mode.

Last, but not least, there are other methods to enumerate interfaces – one can use GetIfTable/GetIfTable2/GetIfTableExAPI APIs. The problem is that the first one doesn’t enumerate all devices and the other ones are available on Vista+ only, so enumerating registry entries sounds like the best deal at the moment.

When you run HSD on a clean system, you should see something like this:

And with the active sniffer, you you should see the something along these lines:

You can download HSD here

Please let me know if you encounter any issues.

DeXRAY – simple XORcarver

Posted on by

It is a well-known fact that the most common encryption algorithm used by malware authors relies on an eXclusive OR (a.k.a. XOR) operation using a static, one byte long key. It is used so often that many researchers already have their own scripts and tools that attempt to cryptanalyse encrypted files and discover hidden data. And in case you don’t – you will now have one as well :-).

DeXRAY

DeXRAY is a simple perl script that tries to discover encrypted executables and DLLs (or, more generically – Portable Executables a.k.a. PE) within a given data file e.g. it could be an encrypted PE that is embedded inside a malicious dropper (including non-PE files e.g. PDFs) or network traffic.

How it works

DeXRAY relies on a simple technique known as X-RAY. The technique is probably as old as an antivirus industry itself and relies on a simple fact that xoring two values from analyzed data will produce the same result as the result obtained from xoring these values if they have been previously encrypted with a static key.

A xor B = (A xor key) xor (B xor key) = same value

Since all Portable Executables start with letters ‘M’ and ‘Z’, xoring ‘M’ and ‘Z’ will produce the same value as xoring (‘M’ xor key) with (‘Z’ xor key)

‘M’ xor ‘Z’ = (‘M’ xor key) xor (‘Z’ xor key) = 0x17

In other words, it is a known plain-text attack.

Supported files

DeXRAY attempts to decrypt

  • Any binary file (using X-RAY)
  • Symantec Quarantine files (VBN/QBD)
  • McAfee Quarantine files (BUP)

Quarantine files are supported specifically for a very simple reason: they often rely on a XOR-based encryption algorithm and X-RAY is a very suitable technique to decrypt them. To make things easier, DeXRAY recognizes file extensions of known Quarantine files and uses (widely) known hard coded keys to decrypt these files while maintaining some flexibility in case some keys have changed.

Usage:

perl DeXRAY.pl <filename or directory>

What is the output?

If it works, you will get files saved as <original filename.XXXXXXXX.YY.out>

where:

  • XXXXXXXX is the offset (hexadecimal) where the file starts in the original file
  • YY is the encryption key (hexadecimal)

There may be more files than one. In some cases the log from the script may show two output files with the same name (one obtained from de-xoring with a hard coded value and second one from X-RAY; in such case, only one file is produced).

Examples and Notes

  • Symantec Quarantine files (.VBN) – xor 0x5A

DeXRAY won’t work with some Symantec Quarantine files. As far as I can tell, it is because not all VBN files are actualy encrypted, so it’s worth looking at a hex dump of such files first. It may also not work if the Quarantined file is not Portable Executable – X-RAY only supports Portable Executable. Adding support for other files (e.g. Flash, PDF) is trivial. Finally, note that there are often two VBN files associated with one Quarantine entry – one contains some metadata, second is the actual encrypted file and is located in a Quarantine subdirectory named similarly to the first VBN file.

The content of the decryptable VBN file is metadata at the top of the file (clear text and strings visible, but header format is unknown) that is followed by the encrypted content we want to grab. One more note here – the location of the encrypted data within the VBN file is not static as some blogs suggest. DeXRAY script is trying to ‘guess’ the offset to the encrypted by reading first 32-bit value from the file (while it is not documented, it appears to be actually pointing to the encrypted content).

  • Symantec/Norton Quarantine files (.QBD) – xor 0xB3 / xor 0x4C

DeXRAY decrypts the whole file using static key 0xB3. This allows to decrypt the metadata at the top of the file. It then uses X-RAY and finds the encrypted malware (it’s encrypted with the key 0x4C)

  • McAfee Quarantine (.BUP) – xor 0x6A

DeXRAY decrypts the whole file using static key 0x6A. This allows to decrypt the metadata at the top of the file. It then relies on X-RAY to find and extract the encrypted malware

  • only PE files are supported by X-RAY, but adding support for known malicious files is trivial and you could add it yourself, or drop me a line and I will add it.

I am not sure if all static keys are always correct as I didn’t have enough samples to test, but it seemed to work in all tests. If you come across files that you know for sure they should be containing malware and DeXRAY fails to decrypt them, feel free to send them over and I will have a look.

Download