Malware Analysis Skills = More Valuable Analyst

I've become more interested in learning about malware analysis and DFIR (these two topics shouldn't be conflated with one another, but having skills in one of these areas can help you in the other and vice versa), because I find the topics fascinating, but I also know that having this knowledge makes me more valuable as a security analyst.

Being a combat veteran, we're trained to always know how to do the job of someone 2 ranks above us. In case one of our leaders went down there was always someone able to step in and effectively run the team and complete the mission. I carry this ethos with me today in my work as a cybersecurity professional. I'm constantly learning how I can become a more capable team member and provide value to my clients, and I can see the benefits that some malware analysis knowledge and training can have for me as a security practitioner.

Malware analysis is a complementary skill you can add to your Blue Teamer tool belt to help increase your confidence at work, knowing that you're able to understand what artifacts are on your network and provide a description of what you may be dealing with and having an idea of next steps, instead of freezing up when encountering malware signatures or worrying that you won't be able to recognize the signs of malware existing in your environment.

What follows is a rundown of some of the key points that stood out to me during a conversation, which you can find here, between Dr. Gerald Auger and Matt Kiely, a Red Team Operator & Exploit Developer at a large financial institution and Principal Cybersecurity Content Architect & Instructor at SimSpace.

Kiely begins by relaying an immediate benefit for analysts who encounter malware and who have a cursory awareness of what it is and how to deal with it when you see it: "When you’ve understood how malware works and you’ve analyzed it, and you’ve understood how to operate with it safely, then when you find malware on a network you don’t treat it like it’s radioactive.” Kiely regales us with one of his Marine Corps combat training anecdotes to drive this point home:

In boot camp, his Drill Instructor was conducting grenade safety training and then, in front of the entire class, pulled the pin out of the grenade. Now, if you've never handled a grenade, seeing this happen right before your eyes would probably produce an instant terror response and have you charging in the opposite direction quicker than Usain Bolt. (They found out later it was a dummy grenade, but the rules are the same, nevertheless). A grenade's charge will not arm if you don’t release the latch of the handle. As long as the drill instructor didn't release his grip on the grenade there was no danger of anyone being hurt. Kiely says, “From grenades to malware, if you handle them safely there is no reason to ever be afraid of them.” That being said, do NOT mess around with malware if you don't know what you’re doing.

Kiely offers a few basic procedures for handling malware: 1) defang, dearm, password protect, and zip up samples while you move them around, 2) make sure that the person giving you malware knows to do the same thing, and 3) when you’re just starting out, make sure you are detonating the malware in a lab environment. Having a healthy respect for the power of what these malware samples can do cannot be understated.

Defanging refers to the process of neutralizing or making harmless certain elements of the malware sample to prevent accidental execution or spreading. This typically involves modifying the code or content of the malware in a way that renders it inert or safe to handle. Common defanging techniques include:

1) removing or altering malicious code snippets--this involves editing the malware code to remove or modify the parts responsible for harmful actions, such as deleting or disabling payload execution routines.

2) replacing malicious URLs or domain names with placeholders--if the malware contains URLs or domain names used for command and control (C&C) communication or downloading additional payloads, these can be replaced with dummy or non-existent addresses to prevent unintentional network activity.

3) renaming file extensions--changing the file extension of the malware sample to a non-executable format can help prevent accidental execution if the file is opened or accessed.

and 4) stripping executable permissions--if the malware sample is stored as an executable file, removing its execute permissions can prevent it from running accidentally when accessed.

Dearming involves removing potentially harmful or active components from the malware sample, such as payloads, exploits, or scripts, to make it safer to handle. This process typically involves dissecting the malware to identify and extract its malicious components while leaving benign or non-executable parts intact. Dearming helps reduce the risk of accidental activation or unintended consequences when analyzing or sharing malware samples.

Password protecting the malware samples adds an additional layer of security to prevent unauthorized access or accidental execution. This involves encrypting the malware sample with a strong password or passphrase using encryption tools or archive formats that support password protection, such as ZIP files with AES encryption. The password should be complex and securely shared with authorized personnel only to ensure that the malware remains contained and inaccessible to unauthorized individuals.

Lastly, you want to zip up samples when you're moving them around. This step involves compressing the defanged, dearmed, and password-protected malware samples into archive files (e.g., ZIP files) for easier and safer transportation or sharing. Archiving the samples helps reduce the risk of accidental execution, corruption, or unintended modification during transit. When moving malware samples between systems or sharing them with colleagues or security researchers, using archive files ensures that the samples remain contained and isolated from the rest of the system.

“You could fill an ocean with the amount of malware that’s out there,” says Kiely. The majority of the malware you’ll encounter is what he refers to as commodity malware. Most of the time commodity malware hasn’t evolved much over time, and what it does is scrape data from your file system and send it to a C2 server. While the malware is running it's looking for keywords like “passwords,” “wallet,” or any other word of a file name that an attacker could reasonably assume might contain valuable information to steal.

Sometimes, commodity malware installs persistence on your machine and the mechanisms for how most commodity malware does that hasn’t changed much over time. It might install it in the registry instead of installing it in the startup folder, for example. That’s an example of a specific TTP that has shifted a bit over time. The other half of the threat actor's malware operation is C2, agents, and things that run and gain access to your system over time (think Remote Access Trojans). These have evolved and the sophistication of these has gone up over time.

Next, Dr. Auger drew our attention to "the seminal work in malware analysis methodology," Practical Malware Analysis by Matthew Sikorski. “I’d be nothing without that book,” said Kiely. Kiely recommends reading the book after taking his Practical Malware Analysis & Triage on the TCM Academy platform. Kiely says he references the book on a weekly basis and says that its 10-year old methodologies still hold up to this day. The tools have evolved, but the methodology has stayed pretty much the same, saying “Tools come and go, but if you can understand the philosophy of how to approach a piece of malware and how you will coax it to tell you what it is doing... that kind of methodology looks very very similar.”

An extremely basic, general malware analysis process might look something like this: immediately triage and identify whether this malware sample has been seen in the wild. If it has, go track down and research that info first. If it hasn’t, then start conducting basic static/dynamic analysis of the sample, moving to a more advanced static/dynamic analysis. Depending on the type or class of malware, your methodology will vary a bit. There is so much more to analysis than this brief description, so begin learning and researching more to clarify the details for yourself about this art and how it's done.

Kiely gave us a hypothetical example of a defender who educates herself on malware analysis and how this provides value to a company: if you're trying to defend against malware and you can begin to recognize the signatures of malware, then you can start to think about developing the appropriate Sigma and YARA rules to write against it.

Next, if you want to emulate an attack, you can think of how you can use Python, Nim, C++, etc. to make a low fidelity emulation of this malware so that you can go to a client and say, "we’re going to test how resilient your systems are against this particular type of malware." In some cases, the malware is ransonware, and a client may want to know how resilient they are to ransomware, and in particular pieces of malware, when reverse engineering them until you can know what the program is doing, you can inform a client of their security posture against this particular kind of ransomware.

Kiely says, “when you think about malware reverse engineering and analysis you are studying the art of threat emulation and the art of threat presence at the code level.” Pretty cool. Keep in mind that threat actors will often incorporate anti-malware analysis. A lot of malware is written to evade sandboxes so blue teams can’t capture and analyze it.

If this sparked your interest in malware analysis and want to learn more, check out some of the information and resources below that Kiely mentioned at the end of the interview. I've also included a link to his malware analysis course.

Matt Kiely's Practical Malware Analysis & Triage course over at TCM Academy.

Start Googling and researching IOCs and TTPs to look for when doing threat hunting for malware.

Look into analyzing malware samples with ProcMon, a powerful tool to set up filters for registry creations, registry queries, DLLs that are loaded, and more.

Ghidra is an open source software reverse engineering (SRE) suite of tools developed by the NSA. https://ghidra-sre.org/

Cutter is a free and open source reverse engineering platform that uses Rizin as its core engine and the Ghidra decompiler. https://cutter.re/

Job titles that may have malware analysis as part of their job description include Cybersecurity Engineer, Research Engineer, Malware Analyst, Reverse Engineer, and Threat Intelligence Analyst.

"When you’ve understood how malware works and you’ve analyzed it, and you’ve understood how to operate with it safely, then when you find malware on a network you don’t treat it like it’s radioactive.”

“Tools come and go, but if you can understand the philosophy of how to approach a piece of malware and how you will coax it to tell you what it is doing... that kind of methodology looks very very similar (to how it's been done for the past 10 years).”