With over 400 million endpoints, Avast uses its AI and machine learning to protect customers worldwide. And, the numbers are big. We prevent over 3.5 billion malware attacks each month. Our security cloud checks over 200 billion URLs and 300 million new files every month. As malware evolves, our Threat Labs team continuously adds more protection by continuously detecting threats and updating our customers to keep ahead of cybercriminals. But it is not all about big data and automation. A highly skilled team works behind the scenes to add the human element to fighting cyber crime. Take a peek behind the scenes in the day of the life of a threat labs analyst.
Everyone’s in the office. The morning light is punctuated by the twitching of multicoloured figures and lines on our screen wall. Global statistics of trends, threats and other activity remind us the threat landscape is constantly evolving.
I have coffee, I am ready.
I am called off routine checks and analysis early as one of our automated systems has found a potential threat in an anomalous trend that started two days ago. Our analysts are alerted to the find and look for a specific case in CyberCapture, Behaviour Shield and heuristic databases on the trend to see what’s behind it, whether it’s malicious and, if so, make sure our customers are protected.
Our method is simple but challenging: spot it, analyse it, work out how to protect against it, and then build it into our product. And new discoveries like this are the most important part of the process.
Many minor threats are dealt with by our AI and big data systems, but this trend is pronounced and so the team begins manual investigation. We pull some code from the activity and begin looking for potentially malicious URLs or signatures in the binary.
It might be a false alarm, or at least one that we can use automated systems to deal with.
Some threats (malware, viruses etc.) repeat in the consumer space so I want to check if this is something we’ve seen before. We can see malicious code again and again but it can come back in other forms. To find the original form we have to go through several layers. So that’s what I start to do.
There is some routine to my days, but no two days are ever the same. I am always analysing different things and the course of action is different.
From looking at the binary and running detection software, we find something familiar in this code. It’s an old favourite with a new twist.
Getting people to click on a malicious link is a tactic that goes back more than a decade. And even though we, as humans, are suspicious if not cautious, some people simply do what they’re asked when an email arrives: ‘click the link’, ‘unpack this zip file’ and so on.
It seems that the scam is to pose as a legitimate business with whom a company does work, and send them an invoice… only it’s not an invoice, it’s malware.
It initially looked like simple phishing – trying to get you to put your details into a malicious web form – but it is in fact linking to malware that will infect yours and any linked machines.
The problem with so many malicious threats is that they come from common code. They’re like zombies… they just keep mutating and coming back. Our customers are protected if the threat looks the same, it’s when they come back in a slightly different way that we have to act quickly to protect them – make sure their antivirus is up-to-date.
I work on the Windows platform, focusing on the Windows binaries. We also have teams in the Threat Lab who focus on malicious java scripts and Android – but this doesn’t seem to need their input. I analyse the script to see how it deploys the malicious code into machines.
I am close to finding out which particular piece of code this threat is based on – then I can write a signature/detection mechanism to combat it and roll it out to our customers’ software directly.
I catch up with a colleague on a scam that was discovered yesterday and what happened. She tells me that we were able to stop a phishing attack that targeted customers of one of the big banks. They use two-factor-authentication on all their machines in and out of the office – which is pretty standard these days.
But attackers created an app to capture login information. They tricked users to download the app to their Android phone. The app then reads their texts which included confirmation codes for logging in.
We managed to catch the threat just in time – recommending all those with the malicious app remove it immediately via their Avast Antivirus software. The attack could have cost the company millions – maybe even billions.
We felt proud.
Today’s threat is proving tricky. We already know it is malicious, but we can go deeper and get the hidden configuration file, which is present in encrypted form somewhere in the binary. The configuration file often contains other information such as the URLs of other malicious servers or scripts.
I am debugging the assembly code, however, I haven't found the spot yet. I write a script and run a diagnostic.
I’m waiting for a diagnostic to deliver its findings, so I work on another project.
I’ve been working out how to detect some of the threats even sooner so we’re designing a new system to do it. I’m currently working on a rule (code) that will help. We all love the challenge of making our systems faster and creating ways of working better.
Lunch! I stand in the kitchen and wait for the toaster to cook my panini. I talk to the guy next to me about the infamous WannaCry attack of May 2017.
We could see from certain indicators that something was happening before the news broke. We saw the threat spread and grow so we started analysing it. Behaviour Shield (technology that observes the behaviour in the computer) means we were able to stop WannaCry affecting our customers before it was even publicly announced.
Another victory for antivirus!
The new guy, Honza, is eating his lunch as I wash up. He asks me how I got into this line of work.
“You have to be in the right place at the right time,” I smile.
Actually, I started coding in high school. I loved ‘reversing’ in ‘crackme’ programs – programmes designed to test a programmer’s reverse engineering skills.
“A few years after I’d left school, a friend of mine started working at Avast when a job came up. He knew that I’d solved some crackme programmes in past - so I knew how software protection works - and I decided to apply for the job.”
Enough chat. Back to work!
Finally, the diagnostic showed some output. I feel that I am close. This is the really hard part. I’m analysing a sample of the code – trying to reverse-engineer the algorithm to see what the specific configuration of the file is. I want to see if I can even find a URL inside the code that we should be blocking to protect customers who do open the attachment.
While I’m searching manually we have some internal software running as well. I’m analysing the code, trying to reverse engineer it, using a debugger called OllyDbg [Olly Debugger software). Depending on how this goes, I might use IDA Pro (an interactive disassembler).
I know what I’m looking for. I’m circling it, but I still don’t have it. When doing this, it’s always a challenge to not make mistakes which might ruin the work you’ve have already done.
It can’t hide forever, I just have to find the right place.
This is going to take some time. The code is very complex - and that’s where the difficulty comes in: the sheer time it can take to understand the source code of the theat.
A lot of people can code in language like C# which is compiled into byte code. This code can easily be reverse-engineered by tools you can download from the web and you can see the whole code at a high-level - almost the same as was written by the author.
There is usually some obfuscation – hiding the code within code - but after renaming the classes, variables and a few other checks you can usually get back to the plain text code.
But this one isn’t written in C# it’s written in C++ using a lot of classes which make it harder to reverse engineer. I have to be slow and careful - almost debugging it instruction by instruction.
There it is! Working with my colleague, we find the decryption routine deep in the binary code. I had a hunch that we wouldn’t find it today. However, we focus on tracking the memory and, sure enough, we finally find it!
The threat was similar to one we caught earlier in the year. Someone was clearly using that as the basis for this malware deployment, but they had buried its source and identity in lots of code – including something that disguised it to look more legitimate.
The next step is to quickly get alerts and protection in place for our customers. We always choose the proper detection methods to suit the case, then they can be delivered to customers. Some code can be created and rolled out automatically but this one will need me and the team to write a bespoke definition (code and data).
We pushed new definitions into our back end, the software performs several tests to avoid False Positives, before sending them to all of our users’ machines.
The definitions can now be rolled out by streaming updates which are delivered very quickly - taking only minutes, after that we are able to flag malicious binaries. We also changed some code, however, these changes need to be properly tested and are delivered by updating the whole VPS (virtual private server) and this takes more time.
We still haven’t had any flags of customers actually opening the file and it being deployed, so we might be able to solve this case with no ‘infections’. It’s always sad to hear about someone who has been cheated out of their life savings, just because they clicked on a link.
I love it when I can see that my work is successful. I get satisfaction from stopping malicious code. Some people may think that my job is boring – sitting staring at a screen all day – but when I find a threat and no one else gets it, it’s the best feeling in the world!
Home time! Today was a good day, it’s rare that we deal with something in a single day. Who knows what tomorrow will bring…?