Staying ahead of hackers and the latest malware requires a knowledgeable security team. Malware, especially ransomware, is constantly in the news, as hacker groups use it to attack companies and government agencies. More than 13 million attempted malware attacks on just Linux systems were detected during the first half of 2021.

The cybersecurity industry is struggling to find qualified infosec professionals to fill all the open positions. About 95% of security professionals say the security skills shortage hasn’t changed over the past few years. Now is a perfect time to get into the cybersecurity industry. So, how to get started?

Dylan Barker, a senior analyst at CrowdStrike, wrote Malware Analysis: Techniques: Tricks for the triage of adversarial software as an introduction to one part of the industry. “I thought it would be great if there was a quick reference out there,” Barker says. “I also wanted to inspire people just getting into the infosec industry. When people enter the infosec industry, they often think the only path for them is either sitting in a SOC [security operations center] and staring at Splunk all day or being a pen tester. There really are more exciting paths out there for blue teams [security analysts within a company] that maybe aren’t quite as popular.”

Barker calls malware analysis exciting and interesting. “We can gather all these IOCs [indicators of compromise] together and weaponize them. This will make life difficult for the adversary — or more difficult than we’ve historically made it. We can also assist coworkers, sys admins and other stakeholders defending a company’s systems.”

To help beginners entering the field of malware analysis, Barker’s book introduces key techniques and software. Readers learn how to set up a malware analysis lab. Barker also covers static and dynamic analysis methods and de-obfuscation techniques.

In this interview, Barker explains malware analysis for beginners looking to enter the field. He breaks down what to know and offers advice on how smaller security teams can succeed against malware attacks.

Editor’s note: The following interview was edited for length and clarity.

How would you recommend someone enter the infosec industry and the malware analysis field?

Dylan Barker: For infosec, you need to approach it understanding what ‘normal’ looks like. The best way to do that is to spend time either working with or being a systems administrator, network engineer or something like that. If you know what normal looks like, then you know what abnormal looks like, right?

Gain experience in programming and research vulnerabilities and what they look like. You’re going to spend a lot of time looking at code and understanding how it operates. The more you understand the way that legitimate applications work, the better you’re going to understand how malicious applications function. I think the idea that you’ve got to spend 10 years being a programmer and 10 years being a sys admin before switching to infosec or malware analysis is patently absurd. Along with finding a good mentor in the field who can show you the ropes. I think, that, coupled with some job experience, will really go a long way for you.

While potential malware analysts should be technical-minded, the only thing that’s really required of you is a passionate desire to learn. As far as code goes, it’s a big concern of people that when they want to get into infosec, they’re like, ‘I’m not a software engineer; I can’t do that.’ I don’t think that’s true. The best way to learn code is to find something you’re passionate about. Maybe you design a Raspberry Pi that collects the most recent baseball scores and shows them on an LED matrix on your wall. You can start in infosec without those skills, as you’ll pick it up as you go. The skill set that’s necessary there is having that fire, the desire to get better and the desire to learn.

What is your methodology when analyzing malware samples that someone just starting out could follow?

Barker: While analysis can vary wildly, it’s best to determine the basic baseline static stuff. There are leading indicators of whether the binary is bad or not. You’ll answer questions such as, ‘Is it packed?’ and, ‘Have we seen this hash before?’ Then, you can leverage open source intelligence [OSINT] for hashes and fuzzy hashes and check to see if someone on the internet has already done this baseline work before.

Once we’ve covered the basic static stuff and correlated that with our OSINT sources, I like to do a little dynamic analysis. I’ll upload it to a sandbox and run the malicious sample and see what behaviors I get — like, does it call out to a C2 [command and control] domain? Then I’ll follow that up with some more advanced static analysis to see if I can validate what else it’s doing. Because, oftentimes, a binary will do things that aren’t necessarily immediately obvious during its execution.

Hackers work to trick information security analysts by iterating malicious software and tweaking how it executes. How common is it to find malware with anti-analysis capabilities?

Barker: Pretty much everything has anti-analysis mechanisms built in, whether it’s just simple obfuscation or searching for debugger processes. The latter is probably the most common thing to look for: whether a debugger is running. More advanced malware will check to see how many [system] ticks have occurred since the malware started executing. A short period could indicate the malware is being debugged and single-stepped as opposed to executing normally.

Before you can develop a strategy to get around any anti-analyzing techniques, you need to understand what the malware is doing. This is something we cover in Chapter 7 [of Malware Analysis Techniques]. But there are broad steps you can do, [like] rename a debugger’s binary. Maybe it’s looking for ProcessMonitor.exe. In the book, we renamed that binary angrypinchycrab.exe so that it doesn’t match what the malicious program is looking for.

How could a smaller security team get started examining potentially malicious files?

Barker: I would suggest a beginning SOC leverage a combination of tactics and tools to get into malware analysis. In Chapter 4, I explain how to set up a Cuckoo Sandbox. This on-premises, private sandbox will automate a lot of the steps for malware analysis and provide a lot of good information on files. From there, I’d complement Cuckoo with OSINT tools like VirusTotal Enterprise and ANY.RUN. These three things would be the most valuable for a SOC just starting out and trying to build a foundation in malware analysis.

How would you say that most security teams handle analysis right now? Is it reactive, proactive or a combination of both?

Barker: That’s an interesting question. The answer depends on the maturity of the organization. A lot of teams have been historically reactive. We sit back and wait in our SOC for alerts. Once we get those alerts, then we analyze the malware and take action.

Nowadays, we’re seeing with the advent of MDR — managed detection and response — services, a little bit of that work being outsourced, which is a good thing. You’ve got specialized teams, so they could be full-time threat hunting, understanding what’s coming down the pipe with dedicated intelligence teams and generating and building these detections long before we ever see it in [the] environment. I do think we’re moving more toward a proactive stance as we see more and more people go to MDR products. Full disclosure, I work for CrowdStrike, which delivers an MDR product. But, be it CrowdStrike, Cylance, SentinelOne or whichever, we’re seeing more of that these days than in the past.

How confident do you feel that security teams can defend effectively against malware, as a whole industry has sprung up to offer malware-as-a-service products?

Barker: At DEFCON this year, there was one session where some panelists were saying, ‘You know, we’re not as good as these adversaries. We can’t defend against them.’ I do not subscribe to that belief in the least. I think we are winning and that we can kick their butts. It’s just a matter of doing the right things and getting the right products and policies in place. We can win this battle.

Over 90% of the ransomware incidents I see — and I see at least three a week — are caused by one of three things:

  • First, exposing something to the WAN that should not be exposed to it.
  • Second, companies not keeping up with patch management.
  • Last is credential reuse.

All three are simple things that are generally exploited. Sometimes an attack originates from successful phishing. But even that is an easy thing to prevent through proper security controls and with zero trust by having a robust patching strategy.

[Us] just doing the bare minimum makes things so much harder for adversaries. By and large, these ransomware actors are not out here burning zero-days to get into your network. They’re not doing it. They’re getting in with ‘spring2020’ being your password on your VPN, and they’re walking in the front door with the key. We’re not doing everything that we can.

About the author
Dylan Barker is a technology professional with 10 years’ experience in the information security space, in industries ranging from K-12 and telecom to financial services. He has held roles from security infrastructure engineering to vulnerability management. He has spoken at BSides events and written articles for CrowdStrike, where he is a senior analyst.