Incident Response in Trinidad

Sometimes when you fill the role of a consultant you never know what type of engagements will be thrown your way.  How can you train someone to expect the unexpected with computer security. The topic is so huge, and there is so much to learn in this gigantic sea of knowledge.

Recently I was sent on an engagement in Trinidad while it’s country was in a state of emergency.  I had never traveled international before so I was required to get a passport.  I had to expedite my passport since I was supposed to be in Trinidad in less than a week.  Once the passport arrived, I was smooth sailing; so I thought.

I missed my flight to Trinidad which was supposed to leave Minnesota around 9am CST.  I panicked and thought I would never find a flight to Trinidad in time.  I called my travel agent and was very surprised to find  there was an afternoon flight heading to Trinidad.  The only catch was that it had a six hour layover in Newark, New Jersey and the connecting flight to Trinidad was between 12am – 6am EST.  I didn’t have any other options at this point, so I took it.

The highlight in Newark had to have been the Symantec crash on the airport screens.  The system was running out of virtual memory, most likely because it didn’t have enough physical memory in the first place.  What geek doesn’t love to see computers crash in public?

After a rough flight I finally arrived in Trinidad where my bright yellow pelican case full of forensics gear seemed to be the center of attention as I attempted to pass through customs.  The guards made me open the case and asked me multiple times what the gear was for.  After both guards were completely confused they finally let me into Trinidad!

Heading into this engagement the only information that we knew was that the client had nearly lost half a million dollars after a fraudulent ACH wire transfer was attempted. It was my job to figure out how the money was wired out.  When we arrived at the clients location they had already pulled the internet connection, and since I was international I did not want to use my iPhone to pull down Internet because of the additional costs.  Needless to say, I was performing this incident response without my best friend “Google”.

One of my first suspicions was that a piece of malware had infected one of the machines and key-logged its way into the bank’s website since it did not require two-factor authentication.  But a suspicion is no good without some actual proof, we needed to get hands on and determine how these systems were infected and which ones.

While two of the suspected systems were being imaged for future forensic analysis I spent my time analyzing network traffic.  In order to properly analyze all of the traffic on this network I would need to redirect the flow of traffic into my laptop running Ubuntu.  I use the tool arpspoof from the dsniff utilities to achieve this task.

The first item we need to change is to enable forwarding.  If I was going to redirect the entire network to my laptop, I would need to forward any traffic received or it would be dropped.  This task can be accomplished by editing the ip_forward file on linux based systems.

#echo 1 > /proc/sys/net/ipv4/ip_forward

Now that we have enabled the proper forwarding, lets redirect all of the network traffic that was destined for it’s gateway to our laptop.  We do this with arpspoof:

#arpspoof 192.168.1.1

Great, now that all of the traffic is flowing through my laptop, lets get dirty and start analyzing the traffic at the packet level.  There are many different tools that could be used for this task, but I prefer wireshark because of the flexibility of filtering on the fly.

Luckily the network that I was on was fairly small and the network traffic was fairly minimal.  Had this been a larger corporate network I would have had a difficult time finding any malicious packets.

We can fire up wireshark with the following command below.  We need to run wireshark with root privileges so that it can properly bind to a network interface.

#wireshark &

As you can see from the image above it is very difficult to detect any malicious traffic with all of the network traffic quickly flowing through my laptop.  I need to filter my results because there is way too much flying by my screen with a raw dump.  My first thought was that if a system was infected and it was trying to call back home for a set of instructions or to relay key-logging information it would most likely use DNS if has not edited the infected machines hosts file.

Using wireshark’s quick and dirty filter I just type DNS into the bar and hit apply.

This is nice, but let’s see what DNS queries are coming from 192.168.1.10 only.  We can do this with the filtering functionality with wireshark entering the following:

dns and ip.addr == 192.168.1.10

The first thing I noticed when I looked at the different types of DNS queries was “what is serioslyfucked.ru and loshatemikontara551.ru?”  I knew it was a Russian domain, but would someone really use the name serioslyfucked.ru as a domain name to run a botnet?  That is pretty cocky of an attacker if this is the case.

I then asked a colleague if they could “Google” serioslyfucked.ru since their phone had an international phone plan. Instantly Google yielded hits related to Trojans, Worms, and other types of malware. One of the articles mentioned that the malware sends it’s payload through email with a subject line of “Subject: ACH Payment xxxxxxx cancelled“.  It also mentioned:

Communicates with a remote server
Worm:Win32/Gamarue.B tries to connect to the following remove servers to report its infection and to download additional arbitrary files:

• randomcrappy.com
• karabasdobryak.eu
• loshatemikontara551.ru
• serioslyfucked.ru

This describes exactly what we saw with the DNS queries in wireshark.

At this point I felt like I was onto something.  I had found a machine that I believed to be infected by a piece of malware, but now I had to find the entry point into the network.  I knew that this malware is typically spread through email, and I knew the subject that it typically uses.  In an ideal case the client would be running an internal exchange server where I could just query the transaction logs for a specific subject line.  This would be my first option since it would detect email messages that have been deleted as well.

The client did not run an exchange server, but rather they had a 3rd party hosted provider that handled all of their email needs.  We put in a request to query all of their transaction logs for the specific subject line.  We were told that our request would not be completed for a couple of days, so we had to continue to find these emails on our own in the meantime.

The next steps that we took were not the most efficient, but they yielded the best results thus far.  We went to each of the workstations on the network to use the search functionality built-in to the outlook email client searching for the term “ACH Payment”.  After visiting all of the workstations on the network we were able to find three emails that were exactly like the malware article had suggested.  All of the emails looked very similar with either a masked link attempting to lure the user into a malicious website, or the email had an attachment with the payload embedded in it.

At this point the case was cracked wide open.  The entry point of the attack had been identified, and the systems infected had been identified.  This was all possible without inspecting any workstations, without running antivirus, and without my friend “Google”.

Share this article