I recently attended the SecTor security education conference in Toronto. It’s a great annual event that brings together security professionals from across North America and beyond. Top of the agenda is learning from the super-talented people you bump into at these events!
One of the areas frequently getting discussed was incident response and some of the techniques we, as security professionals, should employ to understand and learn from incidents. A side-project of mine for some time has been a tool I’ve affectionately referred to as ‘FRuiT’. It was conceived as a tool for the non-security-savvy first responder to collect valuable information that can be analyzed by a security incident handler to determine if a security incident had occurred and to plot a remedial course of action. If you were wondering about the name ‘FRuiT’, it started off as the First Responder Toolkit (FRT) and then gained a User-Interface (UI), so became FRuiT, the First Responder Toolkit with a UI 🙂
Back to the story. Using FRuiT, I captured a physical memory image of a corporate laptop system I had access to; this dumps the entire contents of physical memory to a file, for later analysis. Using the tools provided by the Volatility Framework, it’s possible to analyze this memory image to determine (amongst other things) what processes were running on the system, open network connections, files and registry keys, etc. It also allows you to extract an executable from the memory image.
I selected a random executable that was running on the system and extracted it from the memory image, saving it back to an executable file on disk. Out of curiosity, I decided to run ‘strings’ against the binary file and see if there was anything exciting inside. By sheer chance, there was.
It turns out that inside the extracted executable, there was an IP address that stood out. It stood out because it was not part of the corporate address space where the subject laptop system was running. So the obvious questions arise: where is this IP address pointing to, and what purpose is it serving in the process? A quick trip along to DomainTools indicated that the IP address belonged to an ISP in the UK that provides residential Internet access. Curious… now why would a residential ISP IP address be in a binary running on a corporate system?
The next step was to discover what the code was doing with this IP address. For that, I turned to OllyDbg — a Windows debugger that disassembles code back to assembly language and allows us to peer inside the binary to uncover what it’s doing. Here’s a snapshot of OllyDbg looking at the code section that uses this IP address:
(as you can see, I’ve redacted the actual IP address)
I’m no Windows assembly language guru, but the code is essentially trying to connect to the IP address we have found (the function call being addresses at 00411C22 is to the connect() function in WinSock32).
Going back to the corporate laptop where we found this executable in the first place, we use Wireshark to capture traffic between the laptop system and the IP address we discovered. Sure enough, after some time, the processes attempted an outbound TCP connection, on port 80, to the IP address we identified. It turns out that there isn’t anything listening on that IP address at port 80, so the traffic capture consisted only of the laptop attempting to set-up the TCP connection… and ultimately failing.
So the question remains, what is the code trying to do. Like I said, I’m no assembly language guru so I’ll rely on some empirical evidence to try and formulate an idea. Since I don’t control the network within which the corporate laptop is running, I’m unable to play routing tricks to direct traffic for the suspect IP address to a system under my control. So, next up, we try to patch the running binary and change the IP address to point to a system we do control. In this case, it’s a server system I maintain on the Internet. Again, OllyDbg allows us to connect to the running process on the laptop and manually patch the binary to change the IP address.
On the Internet-connected system we control, I’ve placed a simple netcat listener on TCP port 80, so that when the executable attempts the TCP connection, it should succeed and we can perhaps divine a little more about what the process is trying to do and the information it’s sharing. We’re also running a tcpdump packet capture to collect the packets being received by the outbound connection from our process. Back on the laptop system, a Wireshark packet capture is running to detect any activity from the process to the (newly patched) IP address we control. This enables us to get as much information about the connection as possible, in case any HTTP filtering is tampering with the outbound connection on TCP port 80.
So what do we find? Well… at the moment, nothing!
It seems that the executable only attempts the connection infrequently and as I write this, it hasn’t tried to ‘reach out’. However, when it does, we should be prepared to capture some useful data for analysis.
I know what you’re thinking: what executable is this? Since it’s an ongoing investigation, I’m not going to share the name of the executable, or it’s publisher. Safe to say that it’s from a trusted large software vendor and one could expect to find it in many large corporate settings. The vendor has been notified and we’re working together to try and shed some light on things.
What are my thoughts on what’s going on? Honestly, I believe that this just might be some debugging code left behind by the developer. I’m not assuming anything nefarious… but staying open-minded. It raises the question though: what is YOUR software doing?
