I’ve been getting many duplicate questions about FakeNet, so I’ve decided to post this FAQ to address them.
The other day I was looking at some malware that was interesting because it employed a strategy that allowed it to avoid a hard-coded IP address for the callback domain without being susceptible to DNS filtering. The program would first attempt to resolve the malicious domain name using the host’s built in DNS resolution, but if that failed the host would then open a UDP connection on port 53 to a public DNS server and resolve the host directly. Read on for more details.
We’re releasing an update to the FakeNet tool to version 0.91 which can be downloaded here. The following improvements have been made:
- The dummy listener that listens on all ports now automatically detects SSL and if the connection is SSL it will decrypt the content and display it to the user. This is very useful for when malware uses SSL to encrypt traffic to an unusual port.
- Python is loaded dynamically so that if Python fails to load because the user does not have the Visual Studio redistributables the program will continue to execute without Python support.
- The NXDomain feature has been added to the DNS server to return a domain not found message for the first n times that a domain is requested. This is very useful is determining if a malware sample calls out to more than one domain if the first domain is blocked.
- An option to output the text that is sent to the console to a text file as well. Several users have asked for this feature.
- Improvement in the generated .pcap file. Some other programs were having trouble parsing the pcap data because the source and destination address were the same. To resolve this one end of the connection is recorded as 127.0.0.1 and the other end is recorded as 127.0.0.2. Additional TCP handshakes have been added to the packet recpature.
As usual we welcome feedback that could be used to improve the quality of this tool.
EBP was designed to provide a “Base Pointer” for the current function so that all parameters and local variables would be at a fixed offset from the base pointer even as the stack pointer moved with push and pop instructions. This made it easier to generate assembly and was very beneficial for debugging because it made it easier to trace backwards up the stack and see what path of function calls led to the current instruction. However, due to compiler improvements EBP is used less often so back tracing up the stack is more difficult.
When reviewing disassembly, some instructions are more important than others. You can use a simple script to color instructions that you’re interested in and make them stick out. You can use either IDAPython or IDC scripts to make color the interesting instructions. Most professionals use IDAPython for their scripting, but I’ll talk about IDC because it’s available in the free version of IDAPro and I suspect some of our readers are just flirting with malware analysis and haven’t purchased the full version (also because I have an irrational bias against python). The most important instruction that I like to highlight is the call instructions, but I also highlight instructions commonly used for data encoding (non-zeroing XORs), anti-VM (sidt, sgdt, str, etc), and anti-debugging (int 3, rdtsc, etc). This makes it easier to locate more interesting code during disassembly.
I’ll be at CanSecWest in Vancouver. On Thursday from noon-2pm I’ll be signing copies of the book. Pick up a signed copy of the book or bring your copy by for a signature.
A few weeks ago a friend sent me some packed malware that he was having trouble with. The malware had a number of anti-debugging techniques employed that made it difficult to unpack and my friend was in a desperate rush to create solid host-based indicators for the malware. After spending about 30 minutes trying to find all the anti-debugging techniques, I decided to try opening it in WinDbg, because most of the anti-debugging techniques were specifically targeting OllyDbg. OllyDbg is the most popular debugger for unpacking and in our book we devote an entire chapter to unpacking using OllyDbg. However, in cases like this you can use WinDbg to unpack malware and all the same strategies apply.
In Chapter 3 of our book, we discuss strategies for how to use dynamic analysis tools and techniques. The best way to get started is set up tools to fake the network, which usually includes changing the local DNS server, running a local DNS server such as ApateDNS/FakeDNS, and setting up a second virtual machine with INetSim in order to simulate network services. I’ve been working on a new tool called FakeNet which will combine all those steps into a single tool with additional features to handle hard coded IP addresses, new protocols, SSL support, and more. We’ll be releasing the tool on 2/29 during a Mandiant webinar where we’ll be talking about our book and the tool.
Chapter 2 in our book teaches readers how to set up a safe environment for performing malware analysis in VMs using VMware. The first step in setting up a VM is installing the OS (we recommend Windows XP). For readers that don’t have access to a Windows XP installation CD you may be able to obtain the Windows XP virtual machine that comes free from Microsoft.