OSfuscate: Change your Windows OS TCP/IP Fingerprint to confuse P0f, NetworkMiner, Ettercap, Nmap and other OS detection tools

OSfuscate: Change your Windows OS TCP/IP Fingerprint to confuse P0f, NetworkMiner, Ettercap, Nmap and other OS detection tools 

        I was wondering awhile back how one could go about changing the OS fingerprint of a Windows box to confuse tools like Nmap, P0f, Ettercap and NetworkMiner. I knew there were registry setting you could change in Windows XP/Vista that would let you reconfigure how the TCP/IP stack works, thus changing how the above tools would detect the OS.  I wasn't sure what all registry changes to make, but luckily I found Craig Heffner's tool Security Cloak ( sec_cloak.exe ) and by looking at it's source I was able to figure out what to do.  The needed IP stack changes were hardcoded into Security Cloak, but for my tool I decided to make it easier to update by allowing the user to add new OS fingerprint profiles as ini files. Yes, I know this is security through obscurity and the attacker can still probably figure out the OS on a box by other means, but I still think it's kind of cool to play with. If you want to try out the beta use the link below and let me know how well it works against Nmap, P0f, Ettercap and NetworkMiner:

Download OSfuscate 0.3

        Curret profiles include: BeOS, Checkpoint Firewall, DOS, FreeBSD, HP Unix, IBM OS400, IRIX, Linux, Novell, Palm OS 3.5, PalmOS 5.2, Playstation, Sega Dreamcast, Sun OS, Tru64, Windows 2000, Windows 98, Windows CE, Windows NT and Windows SP SP1. Some may work better than others. Also, if you create any new OS profiles, please send them to me so I can add them to the distribution (I'll be glad to give you credit and link to your site). I make no guarantees that it won't screw up your box, so use it with caution. OSfuscate modifies the following registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultTTL
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpUseRFC1122UrgentPointer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SackOpts
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*\MTU

        I think the layout of a .os file is fairly self explanatory, and the Autoit3 source code is included in the download.

        After doing some testing I found that NetworkMiner and Satori could still guess the OS by sniffing the DHCP queries from the client. It seems Windows XP and Vista embed "MSFT 5.0" in the queries as the Vendor ID, and the only way I've found to change this is to use a HEX editor on dhcpcsvc.dll. I wrote the tool "dhcpcsvc patcher.exe" to make this easier, but you should use this tool only at your own risk (it's in the zip file along with OSfuscate). The patcher looks for the HEX equivalent of "MSFT 5.0"  (4d53465420352e30) in dhcpcsvc.dll, it then replaces the string with the 8 byte string of your choosing and writes it out to "patched-dhcpcsvc.dll" created in same folder as dhcpcsvc.dll. Reboot using a LiveCD with NTFS support (Linux or BartPE), backup dhcpcsvc.dll and rename patched-dhcpcsvc.dll to dhcpcsvc.dll. DO THIS AT YOUR OWN RISK!!! It could screw up your system, and while it seems to work in XP and Vista I've not tested it as much as I would like. You will most likely have to turn off System Restore to make it work.

        Even after changing the DHCP Vendor ID, NetworkMiner and Satori still seem to be able to detect the OS by the DHCP query. Please let me know if you can figure out a way to fix this.  Windows CE has the registry value:

        HKEY_LOCAL_MACHINE\Comm\Adapter Name\Parms\Tcpip\DhcpOptions

and NT 4 had:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters\Options

but the the above key still exits in Windows XP/Vista, it doesn't seem to work (I deleted them all and the fingerprint was the same). Eric Kollmann was kind enough to point me to some Windows API calls that could help:

        DhcpRequestOptions
        DhcpRegisterOptions
        DhcpSetMSFTVendorSpecificOptions

But the only way I can think of that they would be useful is if I implemented my own DHCP daemon. As of right now, if you don't want DHCP to give you away your best bet it to disable it, sniff the network for valid IP information and assign your IP manually.


Experiment, do tests before and after you run OSfuscate, have fun and let me know how to improve it.

Screen shots (click to enlarge) and output results:

 

Vista box results from NetworkMiner before any changes:

 

After changes using OSfuscate and Linux.os profile, notice the OS is no longer detected by P0f or Ettercap fingerprints, Satori still gets it via DHCP fingerprinting however:

 

After and Nmap scan, why it shows up as BSDI I have no idea, I need to work on the profiles:

 

After using my dhcpcsvc patcher, notice the Vendor ID changes, but the finger print found by Satori is the same:

 

Results of "nmap -T Aggressive -O 192.168.1.123" before OSfuscate:

 

After OSfuscate, looks like I have lots of work to do on the Linux.os profile:

PORT STATE SERVICE
3389/tcp open ms-term-serv
5357/tcp open unknown
MAC Address: 00:1A:70:3C:A6:3D (Cisco-Linksys)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING) : FreeBSD 6.X (92%), OpenBSD 4.X (92%), Microsoft Windows Vista (86%)
Aggressive OS guesses: FreeBSD 6.2-RELEASE (92%), OpenBSD 4.3 (92%), Microsoft Windows Vista (86%), Microsoft Windows Vista Home Basic (86%)
No exact OS matches for host (test conditions non-ideal).

Network Distance: 1 hop

PORT STATE SERVICE
3389/tcp open ms-term-serv
5357/tcp open unknown
MAC Address: 00:1A:70:3C:A6:3D (Cisco-Linksys)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING) : FreeBSD 6.X (96%), OpenBSD 4.X (96%)
Aggressive OS guesses: FreeBSD 6.2-RELEASE (96%), OpenBSD 4.3 (96%)
No exact OS matches for host (test conditions non-ideal).

Network Distance: 1 hop

 

Helpful Links:

Nmap
http://nmap.org/

NetworkMiner
http://networkminer.wiki.sourceforge.net/NetworkMiner

Satori DHCP Fingerprint Tool
http://chatteronthewire.org

P0f
http://lcamtuf.coredump.cx/p0f.shtml

DHCP Fingerprint Database
http://www.fingerbank.org/search.php

Network Forensics Evasion: How to Exit the Matrix
http://exitthematrix.dod.net/matrixmirror/ar01s03.html

Craig Heffner's Site (dead last I checked)
http://www.craigheffner.com/security

DHCP Options Info
http://www.networksorcery.com/enp/protocol/bootp/options.htm

Honorary mention goes to Will from whatsmypass.com for sending me an assembly port in less than 24hrs after I released my first beta. He codes in assembly  faster than I do in Autoit, so his glasses are thicker than mine. :)
http://www.whatsmypass.com

Changelog:

10/03/2008: Released to public.
10/03/2008: Added more details about DHCP problem.
10/01/2008: Released version 0.3, fixed bug with deleting MTU registry key.
10/01/2008: Released version 0.2, added links on this page, added Dhcpcsvc.dll patcher to the zip file.
09/30/2008: First beta released to BinRev/