Traps, sandboxes and fake cops

Scanning malware on websites and in emails, evaluating its potential, thinking like a hacker and uncovering their strategy, thinking ahead, making connections, warning those affected, solving cases. A day in the life of a malware analyst.

Pubblicato il 06.10.2020

It’s Monday morning. I’m looking forward to another week as a Malware Monitoring and Analysis Duty Officer, or as we also call it, Montagsmaler [after the popular drawing game]. My work includes, among other things, making sure our systems for processing various malware-related telemetry sources are running and working properly. For instance, we collect potentially malicious emails in what are known as spam traps or extract malware from infected websites and have it automatically scanned in our sandbox, an isolated testing environment.

Recognising abnormalities

After my first cup of coffee, two inconsistencies catch my attention straight away.

First, an email in our spam trap contains a Word document that downloads Emotet malware from a Swiss domain. But the extractor, which was supposed to extract almost 100 command-and-control servers (C2 for short) from the sample, failed. I’ll definitely have to modify that. It seems like the hackers have been tampering with the code again. I can see the download URL and one C2, but the other 99 are missing. Fortunately, the URL is marked correctly in our database and is thus recognised by the SWITCH DNS Firewall; this is a key protective measure for our universities, and contains domains we know of that are related to malicious software.

Second, some Android software wasn’t really running in the sandbox – a problem I’d better hand over to our mobile malware expert. A short time later, they come out with the C2 and inform me that we’ve got FakeCop malware on our hands. Now things are starting to make sense. The group known as Roaming Mantis relentlessly spreads this malware in Switzerland and fraudulently uses the Swiss Post name for phishing.

Friendly malware

After a scan detected a vulnerability – which had probably been exploited – at one of our industry and logistics customers, we informed them without delay. Bingo: the customer has reported to our ticketing system and confirmed the incident today, and they’ve even handed over some Linux malware. Straight into the sandbox it goes, and into the disassembler for the binary code to be analysed. The malware is large, containing more than 5,000 functions. Oddly enough, it seems to neutralise the vulnerability through a ‘hack’ – could it be friendly malware? Think again. It opens a channel and is ready to receive commands. I extract the easily encrypted IP address and create a retrospective NetFlow profile. It seems several universities could also be affected, so I inform them immediately.

It looks like this is going to be an interesting day. If we’re lucky, we might see an infected machine being misused as a C2 in our university network. In that case, we would work with our security contacts to try and trace the real backend servers. It’s time for another coffee. Come to think of it, I wouldn’t mind having a bite to eat either.

The bottom line

Malware analysis is a central element of a threat intelligence programme. The better our telemetry data is, the faster we can detect potential incidents and, as CERT, take proactive action. The diverse systems are just a means to an end that we use to offer the best possible protection to the universities and other customer groups with our partners.

Altri contributi