My last blog post was about miscreant hiding techniques . . . unfortunately one can probably write a book devoted to some of the more popular techniques . . . I'm just going to blog from time to time about the ones my team is encountering (call it miscreant trends if you will).
Background:When miscreants take over a machine it's very common to see them install a new service on the machine and configure it to run as the NT AUTHORITY\SYSTEM account. If this service listens on a port it gives them backdoor access to the server and as a bonus they have access as the SYSTEM account. In the vast majority of the cases we see the miscreants are lame and create a new service that's not hidden and it's usually rather easy for a Windos IR specialist to spot. We've seen such cleverly named services as:"IP / TCP Service""RCP Service""Socks Puppet" (<-- my all time personal favorite name for a backdoor service)etc. etc.
But every now and then we see a miscreant who's a bit more clever than your average lamer - what these miscreants do is hijack a legitimate service and repurpose it for their malware. Confused? Here's an example of what I'm talking about (take a close look):[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Messenger]"Description"=(REG_SZ)"Sends and receives messages transmitted by administrators or by the Alerter service.""DisplayName"=(REG_SZ)"Messenger""ErrorControl"=(REG_DWORD)"0x0""ImagePath"=(REG_EXPAND_SZ)"C:\\WINDOWS\\services.exe""ObjectName"=(REG_SZ)"LocalSystem""Start"=(REG_DWORD)"0x2""Type"=(REG_DWORD)"0x10"
What's wrong with this registry entry? The 'Messenger' service is legitimate. 'Services.exe' is in fact, legitimate. Observe the location where 'services.exe' is running from. The REAL services.exe runs from the SYSTEM32 folder by default. Due to System File Protection - the miscreants don't usually place malware named after legitimate system binaries in the same directory. We see them place it in the %Windir% quite a bit.
Want more? Check this out . . .
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Alerter]"Description"=(REG_SZ)"Notifies selected users and computers of administrative alerts.""DisplayName"=(REG_SZ)"Alerter""ErrorControl"=(REG_DWORD)"0x0""ImagePath"=(REG_EXPAND_SZ)"C:\\WINDOWS\\system32\\winsock.exe""ObjectName"=(REG_SZ)"LocalSystem""Start"=(REG_DWORD)"0x2""Type"=(REG_DWORD)"0x10"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSvr]"DisplayName"=(REG_SZ)"Remote Procedure Call RPC""ErrorControl"=(REG_DWORD)"0x0""ImagePath"=(REG_EXPAND_SZ)"\"C:\\WINDOWS\\system32\\vidres.exe\" \"C:\\WINDOWS\\system32\\vidres.inf\"""ObjectName"=(REG_SZ)"LocalSystem""Start"=(REG_DWORD)"0x2""Type"=(REG_DWORD)"0x10"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Explorer]"Description"=(REG_SZ)"Microsoft Internet Explorer 6.0.2700 (SP1)""DisplayName"=(REG_SZ)"Internet Explorer""ErrorControl"=(REG_DWORD)"0x1""ImagePath"=(REG_EXPAND_SZ)"C:\\WINDOWS\\system32\\iexplorer.exe""ObjectName"=(REG_SZ)"LocalSystem""Start"=(REG_DWORD)"0x2""Type"=(REG_DWORD)"0x10"
Again notice the miscreants have hijacked the real 'Alerter' service and have made this legitimate service start 'winsock.exe' and in the latter case they have hijacked the RPC service and made it run a file called 'vidres.exe' which is taking an INF file as input (hmmm, smells like Hacker Defender) . . . which is a great segue into my next topic. Hacker Defender.
Hacker Defender has been for many *years* the miscreant rootkit of choice. If you are not familair with Windows rootkits and you do incident response for a living - I suggest you visit www.rootkit.com (or take Greg Hoglunds 'Aspects of Offensive Rootkit technology' class at the next Blackhat) and bone up on the topic of Windows rootkits. Windows rootkits have been around, in the wild, depending on who you ask, since circa 1999. In the last few years the PSS Security team has seen them steadily increase in intrusion cases we've worked on and they come in many different sizes and colors. :)
What are rootkits? In a nutshell, on the Windows platform - a rootkit is a piece of malware designed to hide itself and/or other software from the administrator. Generally speaking they accomplish this feat in either usermode or kernel mode by altering the operating system. They can modify the running process list to remove a process from the list, they can modify the list of loaded drivers, they can alter a users token, they can modify the file system and registry API's to ensure they never return information about the files the attacker doesn't want you to see. This may sound bad, but rootkits are usually always installed by either an administrative account (via a weak or easily guessed password) or the SYSTEM account (in the case of a remote command shell spawned via an un-patched vulnerability in a remotely exploitable privileged service). The administrator (and higher) privilige levels can pretty much do anything they want to the operating system (including altering it).
The defacto rootkit standard among most of the miscreant underground, without a doubt, has to be Hacker Defender. You can read more about it here.This rootkit is very popular because of it's broad feature set and ease of use and configuration. Hacker Defender is a self-contained EXE that accepts an INI file as input. The rootkit can not only hide other processes and services but it also provides a built-in backdoor that can be configured to listen on any available port (and on the latest versions can listen on ANY usermode port - even if it's in use!). In addition it can be configured to start other processes when it starts. It also allows the miscreant to specify file names and folder names to hide and a 'safe list' of processes that the stealthing of file names / folder names / process names do not apply to. There are numerous versions of Hacker Defender floating around with the 'latest' according to the download site being version 1.0 - but that was released over a year ago - do you really think that's the 'latest' version? The features and power of the rootkit have changed from version to version.
Here's an example INI file fished off a recently hacked machine . . . this was for Hxdef version .084 which is rather old - but as you can see is still being used.
The rootkit supports the obfuscation of information in the INI file through the use of special characters which is why the header names for the various sections in the INI file look all messed up - don't worry - the rootkit knows how to ignore the extra characters and take the appropriate action:[H<<id<<den <<Ta<<::ble]ftp.exetftp.exeftp.ex_tftp.ex_dllhost.exedllhost.iniviapcidrv.sysnet.exenet1.exenet.ex_net1.ex_ten.exeten1.exe_data__restorefaxsrvmsvagina.*mspslist.dllspoolsv.exenetmngr.exectfmon.exedxdlg.exesmss.exewget.exehxdef*ioftpd.exewget*senvices.exesenvices.inimssvchost32.dlldebug.exesmss.exentmngr.exemsvint.syslocator.ocxlocator.dllautoconvert.dllservices.exeservices.ini
[Hid<<den Services]AlerterFax serverFax*SysadmVIA-PCImsvagina.*NtmngrCtfmonRemoteRegistryHa<c:ke<rDe:fe:nd:er*VIAPCILEGACY_VIAPCIVIA-PCIVIA PCI DriverVIA* [Hidden RegKeys]msvagina.*ioftpd.exeAlerterVIAPCILEGACY_VIAPCIVIA-PCIVIA PCI DriverVIA*MSVINTLEGACY_MSVINTVIAPCIDRVSYSADMR_SERVERmsvagina.* [Hidden RegValues]ioftpd.exe [St<ar<t<up Run]c:\system~1\_restore\system\win\smss.exe
[Hid::den Po<<>>rts]TCP: 41414,4899,4128,1111,1090,3200,999,63636,30336,48792,2112,2109,64896,65235,65234,65233,65232,65231UDP: 41414,4899,4128,1111,1090,3200,999,63636,30336,48792,2112,2109,64896,65235,65234,65233,65232,65231
[Settings] Password=1515-MaRiGnAnBackdoorShell=xcmd.exeFileMappingName=-Messenger-ServiceName=MessengerServiceDisplayName=MessengerServiceDescription=Sends and receives messages transmitted by administrators or by the Alerter service.DriverName=MSVINTDriverFileName=msvint.sys
The heading names may be rather self explanatory - but I'll explain their purpose anyways:[H<<id<<den <<Ta<<::ble] <-- List of processes / files / folders to hide from administrators or non-root processes[R<<::o::o<t Pro<<ce<s<s<es] <-- List of 'root' processes - these are the processes that are allowed to 'see' what's hidden[Hid<<den Services] <-- List of services to hide[Hidden RegKeys] <-- List of registry keys to hide[Hidden RegValues] <-- List of registry values to hide[St<ar<t<up Run] <-- List of things to launch / start when the rootkit starts (which is itself configured usually to start as a service)[Free Space] <-- Used to lie about the free space - useful for miscreants who fill up your hard drive with stolen movies, music and software[Hid::den Po<<>>rts] <-- List of ports to hide from netstat and other utilities[Settings] <-- Other misc. settings like the password for the backdoor that gets spawned, what to call the device driver used by the rootkit etc.Something we've discovered recently that is specific to the Hacker Defender (tested with versions .084 and 1.00) rootkit is that it doesn't seem to hide its files / folders from the SYSTEM account on the disk.
What I mean by that is that if you are able to spawn a command shell as SYSTEM you can enumerate the file system using DIR /S and it will show any files / folders hidden by this version of Hacker Defender.
Other techniques we've seen discussed publicly for detecting the presence of this rootkit involve enumerating all of the listening ports on a box locally and then port-scanning the box remotely and comparing the list of ports that show up as listening. Any ports that show up remotely that don't show up locally are obviously hidden. I want to urge caution on this approach. The latest version of hacker defender 1.0.0 can actually hijack usermode ports (i.e. TCP 135, 80, 443) and allow them to be used for backdoor control (i.e. the backdoor server built-in to the rootkit does not need to bind to a NEW port, it shares an existing port being used by some other process like IIS). It doesn't currently seem to be able to bind to ports being listened on in the kernel (i.e. TCP 139/445 for example). It does this by hooking winsock and inspecting all in-coming packets and if the packet was emitted by a special backdoor client it will have certain properties; if it sees these packets the packet gets forwarded to the backdoor server and not the other application sharing the port (like IIS).
As always - I don't take credit for these findings. The PSS Security team is large (over 30+ people now and growing) and we truly are a team - finding and sharing this kind of information. I'd like to thank Matt and Paul for sharing this information.