NCC Group’s Cyber Defence Operations team has released a technical note about the Derusbi Server variant, which we encountered on an engagement at the end of last year.
The Derusbi Server variant is typically associated with advanced attackers (APT groups) and was the most sophisticated attempt to retain persistence on our client’s network. Other activity included installation of ASPXSpy web backdoors and usage of a modified Gh0st RAT.
During the engagement we faced a number of challenges that required us to conduct detailed research and write custom tools. This blog post accompanies the full technical note and briefly discusses some of the challenges faced during a typical incident response engagement.
Challenges
Undocumented Windows internals
The Windows API is typically well documented with information readily available to both developers and malware analysts. However, during reverse engineering it is not uncommon to find malware authors using internal functions, either to access additional operating system features or to hide activity from security products.
When running on older Windows platforms (XP, 2003 and older) the Derusbi server variant uses Windows Firewall Hook drivers. However there appeared to be no way to enumerate the current hooks on a running machine which caused problems for the incident responders.
To address this Zsolt Imre, one of our consultants, conducted some research to understand the hooks in more details, information is available in his blog post released earlier this year. He subsequently wrote a tool to display current legacy firewall hooks, which can be downloaded from NCC Group’s Github repository.
Analysing memory images
Having a custom tool to enumerate firewall hooks is useful but often during incident response we are working with preserved evidence such as forensic disk copies or memory images. Fortunately our client was able to provide memory images from their virtualised hosting platform, allowing us to conduct analysis using the Volatility framework.
Building on analysis of the Windows Firewall Hook mechanism our technical director Ollie Whitehouse developed a Volatility plugin, also available from Github. When run on an infected machine there are two malicious hooks present in addition to legitimate Windows functionality provided by ipnat.sys.
[FWHook] Total hooks registered 3 [FWHook] --------------------------------------------------------------------------- [FWHook] Call Out Address: 0xf0582246 [FWHook] Module Base Address: 0xf0580000 [FWHook] Module DLL Name dump_dumpfve.sys [FWHook] Module Binary Path ??C:WINDOWSsystem32driversdump_dumpfve.sys [FWHook] --------------------------------------------------------------------------- [FWHook] Call Out Address: 0xf103c6dc [FWHook] Module Base Address: 0xf1027000 [FWHook] Module DLL Name ipnat.sys [FWHook] Module Binary Path SystemRootsystem32DRIVERSipnat.sys [FWHook] --------------------------------------------------------------------------- [FWHook] Call Out Address: 0xf0582270 [FWHook] Module Base Address: 0xf0580000 [FWHook] Module DLL Name dump_dumpfve.sys [FWHook] Module Binary Path ??C:WINDOWSsystem32driversdump_dumpfve.sys
Attributing the different parts of an attack
It is often beneficial to identify how the various files and techniques used during an attack are related. Were components custom written by a skilled attacker, or reused code from public sources?
Reverse engineering can often provide answers to these questions, so Pete Beck from NCC Group’s Exploit Development Group took apart the various components to understand their functionality and how they interact (his work is outlined in the technical note).
One piece of code is the MiniLZO decompression routine, reused in four of the six executable modules. This strongly suggests that the same programmer(s) were responsible for all parts from the DLL load order hijacking shim to the backdoor kernel driver.
Identifying other infected hosts
There are various ways to identify suspicious behaviour, from host based indicators of compromise to network signatures. Sample Yara rules and ssdeep hashes are provided in our technical note, however it is not always possible to quickly run custom tools on all machines in a complex organisation.
Another option is to generate IDS signatures for malicious traffic, but this is not reliable as the Derusbi Server variant is “woken up” by packets with a special combination of values. Because these values are not fixed it becomes very difficult to generate static signatures or deploy monitoring at scale.
Instead we used the output of our reverse engineering activity to generate a proof-of-concept script that sends the correct magic values to all machines in a subnet. Responses are monitored by the script and any data returned is checked to verify whether it is expected (e.g. an HTTP error) or if it matches Derusbi Server variant behaviour. The output of this script when run against an infected virtual machine is shown below.
-> % python derusbi-server-trigger.py 192.168.99.50 [+] Sending 64 byte handshake to 192.168.99.50:80 [E] Port not open or timed out reading from socket! [+] Sending 64 byte handshake to 192.168.99.50:139 [D] Received: 3b12751cc4ed8ae324ea38767854736d4d08d067be548258be66db43c257461241582b5d8c63fa03306f7f52705af00aa7465479860732239512aa7d5b4f6825 [D] Values: 1c75123b e38aedc4 7638ea24 [!] Got a valid reply from 192.168.99.50, this machine is potentially infected! [+] Sending 64 byte handshake to 192.168.99.50:445 [D] Received: e658fc1b19a703e4b1f837cc9f0d89738a38410a1b64fd15b87c4f63686ff61a723a7b001460990ecd33d3270d7ff00444203a18b41fa613664f537133780b19 [D] Values: 1bfc58e6 e403a719 cc37f8b1 [!] Got a valid reply from 192.168.99.50, this machine is potentially infected!
Conclusion
Conducting a large, complicated incident response engagement proved to be a great way for NCC Group to bring together expertise from Cyber Defence Operations, the and Research team and our Exploit Development Group. We firmly believe that combining these skillsets allows us to deliver the highest quality results to clients in a timely manner.
Thanks go to Pete Beck, Zsolt Imre, and the CDO team for working on this together.
Further Details
Our detailed analysis was provided to industry partners and CERT UK in January 2015 prior to public release. Further queries from verified security industry contacts can be answered where required. Please email cirt@nccgroup.com from a recognised corporate address to start this process.
Published date: 09 March 2015
Written by: David Cannings
