adapting to advanced malware: insight from the 2024 cybersecurity frontlines
Compared to other often changing courses (e.g., Windows forensics courses), reverse engineering techniques do not often change. Assembly, API calls, etc., all remain the same. But that does not mean malware does not evolve over time. Attackers are imaginative at implementing new techniques to evade classic security controls (or automated ones) and make the lives of analysts and reverse engineers very difficult.
PDF documents are a perfect example. In the past, many PDF viewers (Acrobat Reader, FoxIt Reader, etc.) suffered from weird vulnerabilities. Today, however, PDF files are more often used as a “transport mechanism” to deliver other types of payloads with embedded objects or a URL. Once the malware has been delivered to and infected the victim’s computer, it must communicate with a central authority, known as a C2 server, to receive commands and/or send interesting data. Modern C2 servers rely on layer-7 protocols. From an attacker’s point of view, they offer a great tool for implementation thanks to powerful application programming interfaces (APIs) and, even more interesting, they can’t (without great difficulty) be blocked. Could you suddenly block Discord servers for your users?
Blocking the execution of malicious code has always been a cat and mouse game between defenders and attackers. Modern pieces of software implement many controls that will try to prevent malicious activity. Microsoft Office document macros are a good example. They are very popular, but for a few months now, I have seen a large decrease in infected documents. This is likely due to Microsoft improving the decision rules to automatically execute VBA code. At the opposite end of the spectrum, they are attacks that remain classic. An example is CVE-17-11882, which targets the Equation Editor. Still today, I spot one or two examples per month. Crazy, seeing that the tools do not even exist anymore!
If attackers are always looking for new techniques to spread their malicious code, I like to say that the malware landscape is like fashion. Let me explain why. When it’s fashion week in Milan, a specific color is often used for a collection. The next year, another color will emerge, and so on. After a few years, a previous color will become trendy again, and everybody will be dressed in blue. It’s the same for malware. After a while, some tools and techniques are back on stage and reused by attackers. Why? Because newcomers aren’t aware of “vintage” techniques and some security controls, for performance reasons, will have some rules disabled. The best example I can give is the Excel 4.0 (XLM) macros.
What are the trends in malware landscape so far in 2024?
First, attackers are using other programming languages. In the Windows ecosystem, Microsoft offers a great tool called AMSI to track all scripts activities. This tool helps you log the execution of scripts like JavaScript, VBS, PowerShell, but it lacks support for one popular language (not installed by default), Python! These days, I see new malicious Python scripts targeting Windows systems daily. And they are really powerful!
If the .Net framework remains popular, there are other emerging programming languages like Go or Rust. Go has many advantages for an attacker: it’s relatively easy to learn, it’s powerful, cross-platform compatible, and Go binaries are challenging to debug and disassemble! Also, I often see compiled binaries in Python scripts. They are easier to deploy on the victim’s computer because they contain all the dependencies embedded in one file.
In recent years, there have been a lot of stories about the “supply chain.” The best example being SolarWinds. Supply chain attacks are very effective because third-party providers are trusted and their updates are allowed blindly because as security professionals always say, “patch, patch, and patch again!” Hopefully, the attack complexity makes it unavailable to all but a small group of attackers!
Ransomware remains a classic attack, but it seems less profitable since victims tend not to pay. Sometimes, malware tends to use simple scripts based on Living off the Land (LOTL) binaries. They offer simple functionalities for system administration tasks but they can be used by attackers for malicious reasons. Being part of the operating system, they are less suspicious. Even if based on simple tools, a ransomware will remain a real threat if you don’t get a decent backup mechanism
A specific malware trend is related to an information stealer or “infostealer.” the purpose of an infostealer is simple: Once the victim’s computer is infected, it searches for any sensitive information and exfiltrates it through a simple C2 protocol (usually Discord or Telegram). What type of information do they search for?
- A footprint of the victim’s computer or network.
- Credentials, (especially in browsers configurations).
- Cookies. (Another goldmine.)
Wi-Fi credentials.
- Cryptocurrency wallets.
The exfiltration of passwords from the Chrome browser is weird because, on one hand, we instruct people to use complex passwords and a password manager. So they do. Then, on the other hand, they make their passwords vulnerable by storing them in Chrome.
Pro tip: Do NOT save passwords in browsers. Instead, use a strong password manager.
Infostealers collect plenty of information that is then compiled and sold on black markets or directly reused by another attacker. Indeed, this is a common attack pattern:
- Group A infects computers with an infostealer malware and collect juicy data.
- The data is sold to Group B that uses it to implant a backdoor or otherwise compromise the victim’s infrastructure.
- The backdoor is sold to Group C that performs the real attack, often ransomware, against the victim.
Another fact is that Windows is not the only targeted operating system anymore. A few years ago, many people had the idea that Apple devices were “safe.” That’s not true! Recently, a new infostealer called Cuckoo Stealer has been discovered targeting MacOSs.
Another trend is the abuse of “new” features implemented in software. An example is the MSIX file format. MSI files are Microsoft Windows packages (like .rpm for Red Hat or .deb for Debian Linux distributions) that help developers deliver their applications with all the required dependencies. MSIX is the newest file format that implements nice features. The developer now has the opportunity to specify a script that will be automatically executed during the package installation. What could go wrong? Here is a practical example: The file “EditProAI-x64.msix” available on VirusTotal uses this technique. Let’s have a quick look at the file.
You don’t need complex tools to investigate the file. Zipdump is sufficient:
$ zipdump.py EditProAI-x64.msix
Index Filename Encrypted Timestamp
1 Registry.dat 0 2024-04-22 12:44:46
2 libsqlite3-0.dll 0 2023-07-04 14:24:14
3 gpg.exe 0 2023-07-04 14:23:30
4 libgpgme-11.dll 0 2023-07-04 14:24:04
5 libassuan-0.dll 0 2023-07-04 14:23:54
6 libgcrypt-20.dll 0 2024-04-22 12:34:44
7 libgpg-error-0.dll 0 2023-07-04 14:24:00
8 libnpth-0.dll 0 2023-07-04 14:24:10
9 zlib1.dll 0 2023-07-04 14:24:24
10 1.ps1 0 2024-03-23 12:37:22
11 StartingScriptWrapper.ps1 0 2022-09-14 13:42:04
12 config.json 0 2024-04-22 12:44:46
13 PsfRuntime64.dll 0 2024-04-22 12:44:46
14 PsfRuntime32.dll 0 2022-09-14 15:17:16
15 PsfRunDll64.exe 0 2022-09-14 15:17:32
16 PsfRunDll32.exe 0 2022-09-14 15:17:14
17 assets/rocke.zip 0 2024-03-19 11:57:18
18 assets/Store50x50Logo.scale-100.png 0 2024-03-06 08:09:28
19 assets/gpg.exeSquare44x44Logo.scale-100.png 0 2022-09-14 13:42:10
20 assets/gpg.exeSquare150x150Logo.scale-100.png 0 2022-09-14 13:42:12
21 AI_STUBS/AiStubX64.exe 0 2024-04-22 12:44:46
22 resources.pri 0 2024-04-22 12:44:46
23 AppxManifest.xml 0 2024-04-22 12:44:46
24 AppxBlockMap.xml 0 2024-04-22 12:44:48
25 [Content_Types].xml 0 2024-04-22 12:44:46
26 AppxMetadata/CodeIntegrity.cat 0 2024-04-22 12:44:46
27 AppxSignature.p7x 0 2024-04-22 08:29:34
The config.json file contains interesting information:
$ zipdump.py EditProAI-x64.msix -s 12 -d
{
"processes": [
{
"executable": ".*",
"fixups": []
}
],
"applications": [
{
"id": "gpg.exe",
"startScript": {
"scriptExecutionMode": "-ExecutionPolicy RemoteSigned",
"scriptArguments": "-windowstyle hidden",
"scriptPath": "1.ps1"
}
}
]
}
The script “1.ps1” will be executed once the package installed.
As you can see, a key element for reverse engineers is to be able to understand the environment targeted by the malware. While teaching FOR610, I like to say to my students that they must know the targeted operating system and how it works. Another good example: How can you guess that a malware implements persistence if you don’t know the purpose of the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run?
Malware developers have plenty of techniques that, at first, are not malicious at all. They are actually provided by Microsoft for legitimate purposes. Another critical point for malware reversers is that they must know common API calls used by attackers.
Let’s check another common technique used these days called process hollowing. It’s a nasty process injection technique that takes only a few steps:
- A new process (chosen by the attacker) is created in suspended mode (this is key!).
- The newly created process memory is hollowed (i.e., wiped).
- Free memory is allocated by the attacker in the remote process.
- The malicious code is copied in memory.
- The process is resumed.
To achieve this, the common API call ZwUnmapViewOfSection() is used. This function is provided by Microsoft and is not malicious. One day, a former student asked, “Why does Microsoft provide such a dangerous call? In which context could it be used for legitimate purposes?” Here is the best explanation I have found:
“NtUnmapViewOfSection (and the corresponding NtMapViewOfSection) are function calls used by Windows kernel-mode drivers to manage shared memory. These functions can be used to share memory between kernel space and user space: for example, a driver could use them to communicate with a user-space configuration tool.” [source]
What Are the Challenges for Reverse Engineers?
They are many techniques used by attackers to defeat malware analysts. Process hollowing (see above) is one. Other protections can be grouped in two main categories:
- Defeat the analyst or the automatic analysis (in a sandbox).
- Anti-debugging techniques (to detect when executed inside a debugger).
- Hide interesting information (code or data).
- Packers,
- Obfuscation,
- Encryption, and/or
- Junk code/data.
Attackers are very good at detecting environments. The goal is to detect as soon as possible where in the host machine or network the infection should be targeted and the malware executed. For example, state-sponsored groups would like to keep friendly countries (I won’t mention any example here 😉) from being affected. But they also try to defeat the automatic analysis by checking for common indicators. Recently, I found an interesting piece of PowerShell that implemented all those checks. Example:
Detection of evil GPUs:
$gpu1 = Get-WmiObject -Class win32_videocontroller | Select-Object -ExpandProperty Caption
$pcusn = $env:USERNAME
$uuid = (Get-WmiObject Win32_ComputerSystemProduct).UUID
$evilgpu = @(
'29__HERE'
'2RO_8UVU'
'5KBK41_L'
'5LXPA8ES'
'5PECN6L1'
'5RPFT3HZ'
'6BOS4O7U'
'6BZP2Y2_’
'AMD Radeon HD 8650G'
'ASPEED Graphics Family(WDDM)'
…)
if ($evilgpu -contains $gpu1) {
exit 1
}
else {
{}
}
Detection of bad hostnames:
$badpcname = $env:COMPUTERNAME
$badpcnamearr = @(
'00900BC83803'
'0CC47AC83803'
'6C4E733F-C2D9-4'
'ACEPC'
'AIDANPC'
'ALENMOOS-PC'
'ALIONE'
'APPONFLY-VPS'
'ARCHIBALDPC'
'azure'
'B30F0242-1C6A-4'
'BAROSINO-PC'
'BECKER-PC'
… )
if ($badpcnamearr -contains $badpcname) {
exit 1
}
else {
{}
}
They know the name of suspicious processes and they know the IP addresses used by most security vendors. It’s a huge amount of knowledge.
Finally, like most people working in IT, malware developers and attackers are lazy. If they can find interesting free online resources, they will use them to store payloads, collect data, and serve as C2 protocols.
What to Expect in the Future?
I don’t have a crystal ball, but malware developers will certainly continue to have crazy ideas to make our lives more difficult. Computers are everywhere and there are still domains out there that are not yet massively targeted. I’m thinking about connected cars, for example. Can you imagine a ransomware targeting cars? In the morning, you step into your car, turn the engine on, and the multimedia interface displays a ransom note. Scary!
If most malware can be detected by modern tools like endpoint detection and response (EDR), there are already researches demonstrating how easy they can be bypassed, like the Process Mockingjay.
Finally, we must strengthen our methodologies to speed up the analysis of the huge amount of malware detected daily. It’s important to make a clear distinction between the regular “noise” (like the classic AgentTesla, RedLine, etc.) and the real new interesting piece of malware that deserve to be investigated deeper.
No Comments