A live malware infection - a real life study (Part 1)

We recently assisted a client that was aggressively hit with a phishing campaign. Following a couple of successful compromises they found themselves faced with an escalation with the malware attempting to impersonate staff, both emailing their customers and pivoting to attack the admin users in a secondary phishing attack. What made things a little more interesting than the usual kiddy attack was that the initial malware was not carrying a particularly nefarious payload, which meant that it escaped the usual malware detection that the client had deployed.

The end result - the company was struggling to cope with identifying valid and invalid emails, both of which seemed to originate from internal staff. At the time they had two routes open to them - they either actioned everything that came in, both valid and nefarious, or they actioned nothing - but in both cases the end result would be a success for the attacker.

How to identify the attack?

The first step was to assess the capability of the attacker, and reverse engineer the initial malware to understand what it was attempting to do. This showed that it was calling back to a Command and Control server on a fixed IP address, hence the first objective: block access to the C&C host. This had two benefits, firstly it stopped the attack from escalating, but also by watching the logs we could see local machines attempting to reach the C&C host and therefore identify which machines had been compromised - it turns out not every member of staff is completely transparent when asked “Did you click on this link?”!

A great start, we’ve now stopped things getting away from us. However we then had an additional complication - many staff had laptops and therefore they were able to reach the C&C host whilst out of the office and unprotected from the corporate firewall. Therefore any machine that has left the protection of the corporate network is treated as hostile. This meant that the corporate wifi needed to be disabled to avoid any machines connecting automatically, and every single machine that had left the site was quarantined from the corporate network until it was proven to be free of infection.

Understand the infection method

So now we’ve stopped the infection growing, and we’ve taken steps to avoid machines outside of our protection entering our network and reinfecting others. Next we needed to understand what the next phase of the infection would do, so we can protect ourselves accordingly. So we created a clean machine, running in isolation from the corporate network, with a monitoring device alongside it so that we could see any change to the machine, no matter how small and most importantly - we’re monitoring it independently of the Operating System so the malware shouldn’t be able to tell that it’s being watched unless it’s particularly sophisticated.

(This helps us see what’s happening, but we also need to see how the infection will run around the network. So we also created a honeypot, simulating the corporate network, but that’s outside the scope of this post - maybe we’ll revisit in a new post soon.)

Now we have the means to actively infect our machine, and watch the infection take place…and finally see what the attackers’ actual intent was.

So, now the fun part, let’s move from being reactive to actively going on the hunt

Keeping an eye on our machine we connect it to the internet, running through a firewall that is set to monitor rather than restrict, and we now watch the infected machine connect out to the C&C machine. Throughout we capture the traffic off the network port using port mirroring, so the malware cannot detect it’s being monitored, which will allow us to examine and replay events at our leisure and if necessary provide a full analysis to a court of law.

Once the malware connects to the C&C host, we watch the handshake as it identifies itself, before downloading the real malware to the host machine. This was effected by the malware triggering the request as a user driven event from the client machine, so a normal corporate firewall set to stop inbound events but permit users to get out without too many restrictions would have permitted the action through. Masquerading as a text file to circumvent primitive extension checks, the malware is now inside our host machine where it is renamed as an executable file and ostensibly executed by the user. We’re on….

….so that’s how an infection is seen, identified and stopped. Next in Part 2 we’ll explore how we find out what the malware itself was doing, and what we can do to protect ourselves against it.

Fancy reading something else - what takes your fancy?