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.