As open source software continues to fortify modern applications, attackers are finding new and increasingly efficient ways to exploit the trust developers place in public ecosystems.
The post Open Source Malware Index Q4 2025: Automation Overwhelms Ecosystems appeared first on Security Boulevard.
Welcome back, my aspiring digital investigators!
Many of you enjoyed our earlier lessons on Volatility, so today we will continue that journey with another practical case. It is always great to see your curiosity growing stronger. This time we will walk through the memory analysis of a Windows machine that was infected with a stealer, which posed as a VPN app. The system communicated quietly with a Command and Control server operated by a hacker, and it managed to bypass the network intrusion detection system by sending its traffic through a SOCKS proxy. This trick allowed it to speak to a malicious server without raising alarms. You are about to learn exactly how we uncovered it.
Before we jump into memory analysis, let’s briefly talk about NIDS, which stands for Network Intrusion Detection System. A NIDS watches the network traffic that flows through your environment and looks for patterns that match known attacks or suspicious behavior. If a user suddenly connects to a dangerous IP address or sends strange data, the NIDS can raise an alert. However, attackers often try to hide their communication. One common method is to use a SOCKS proxy, which allows the malware to make its malicious connection indirectly. Because the traffic appears to come from a trusted or unknown third party instead of the real attacker’s server, the NIDS may fail to flag it.
Now that we understand the background, we can begin our memory investigation.
In this case we received a memory dump that was captured with FTK Imager. This is the only piece of evidence available to us, so everything we discover must come from this single snapshot of system memory.
If you followed the first part of our Volatility guide, you already know how to install Volatility in its own Python 3 environment. Whenever you need it, simply activate it:
bash$ > source ~/venvs/vol3/bin/activate
Volatility includes a helpful plugin called malfind. In Volatility 3, malfind examines memory regions inside processes and highlights areas that look suspicious. Attackers often inject malicious code into legitimate processes, and malfind is designed to catch these injected sections. Volatility has already announced that this module will be replaced in 2026 by a new version called windows.malware.malfind, but for now it still works the same way.
To begin looking for suspicious activity, we run:
bash$ > vol -f MemoryDump.mem windows.malware.malfind
The output shows references to a VPN, and several processes stand out as malicious. One in particular catches our attention: oneetx.exe. To understand its role, we need to explore the related processes. We can do that with pslist:
bash$ > vol -f MemoryDump.mem windows.pslist | grep -E "5896|7540|5704"
We see that oneetx.exe launched rundll32.exe. This is a classic behavior in malware. Rundll32.exe is a legitimate Windows utility that loads and executes DLL files. Hackers love using it because it allows their malicious code to blend in with normal system behavior. If the malware hides inside a DLL, rundll32.exe can be used to run it without attracting much attention.
We have confirmed the malicious process, so now we will extract it from memory.
To analyze the malware more deeply, we need the actual executable. We use dumpfile and provide the process ID:
bash$ > vol -f MemoryDump.mem windows.dumpfile --pid 5896
Volatility will extract all files tied to the process. To quickly locate the executable, we search for files ending in .exe:
bash$ > ls *exe*
Once we find the file, we calculate its hash so that we can look it up on VirusTotal:
bash$ > md5sum file.0x….oneetx.exe.img
The malware is small, only 865 KB. This tells us it is a lightweight implant with limited features. A full-featured, multi-purpose implant such as a Sliver payload is usually much larger, sometimes around sixteen megabytes. Our sample steals information and sends it back to the hacker.
Viewing its behavior reveals several MITRE ATT&CK techniques, and from that we understand it is a stealer focused on capturing user input and collecting stolen browser cookies.
Next, we want to know which user launched this malware. We can use filescan for that:
bash$ > vol -f MemoryDump.mem windows.filescan | grep "oneetx.exe"
It turns out the user was Tammam, who accidentally downloaded and executed the malware.
Before we continue, it is worth discussing memory protection. Operating systems apply different permissions to memory regions, such as read, write, or execute. Malware often marks its injected code regions as PAGE_EXECUTE_READWRITE, meaning the memory is readable, writable, and executable at the same time. This combination is suspicious because normal applications usually do not need this level of freedom. In our malfind results, we saw that the malicious code was stored in memory regions with these unsafe permissions.
Next, we review the complete process tree to understand what else was happening when the malware ran:
bash$ > vol -f MemoryDump.mem windows.pstree
Two processes draw our attention: Outline.exe and tun2socks.exe. From their PIDs and PPIDs, we see that Outline.exe is the parent process.
Tun2socks.exe is commonly used to forward traffic from a VPN or proxy through a SOCKS interface. In normal security tools it is used to route traffic securely. However, attackers sometimes take advantage of it because it allows them to hide communication inside what looks like normal proxy traffic.
To understand how Outline.exe started, we trace its PID and PPID back to the original parent. In this case, explorer.exe launched multiple applications, including this one.
Normally we would extract these executables and check their hashes as well, but since we have already demonstrated this process earlier, we can skip repeating it here.
Malware usually communicates with a Command and Control server so the hacker can control the infected system, steal data, or run remote commands. Some malware families, such as ransomware, do not rely heavily on network communication, but stealers typically do.
We check the network connections from our suspicious processes:
bash$ > vol -f MemoryDump.mem windows.netscan | grep -iE "outline|tun2socks|oneetx"
Tun2socks connected to 38.121.43.65, while oneetx.exe communicated with 77.91.124.20. After checking their reputations, we see that one of the IPs is malicious and the other is clean. This strongly suggests that the attacker used a proxy chain to hide their real C2 address behind an innocent-looking server.
The malicious IP is listed on tracker.viriback.com, which identifies the malware family as Amadey. Amadey is known for stealing data and providing remote access to infected machines. It usually spreads through phishing and fake downloads, and it often hides behind ordinary-looking websites to avoid suspicion.
The tracker even captured an HTTP login page for the C2 panel. The interface is entirely in Russian, so it is reasonable to assume a Russian-speaking origin.
Now that we understand the basic nature of the infection, we search for strings in the memory dump that mention the word “stealer”:
bash$ > strings MemoryDump.mem | grep -ai stealer
We find references to RedLine Stealer, a well-known and widely sold malware. RedLine is commonly bought on underground markets. It comes either as a one-time purchase or as a monthly subscription. This malware collects browser passwords, auto-fill data, credit card information, and sometimes even cryptocurrency wallets. It also takes an inventory of the system, gathering information about hardware, software, security tools, and user details. More advanced versions can upload or download files, run commands, and report regularly to the attacker.
We can also use strings to search for URLs where the malware may have uploaded stolen data.
Several directories appear, and these could be the locations where the stolen credentials were being stored.
Tammam wanted to download a VPN tool and came across what looked like an installer. When he launched it, the application behaved strangely, but by then the infection had already begun. The malware injected malicious code, and used rundll32.exe to run parts of its payload. Tun2socks.exe and Outline.exe helped the malware hide its communication by routing traffic through a SOCKS proxy, which allowed it to connect safely to the attacker’s C2 server at 77.91.124.20. From there, the stealer collected browser data, captured user inputs, and prepared to upload stolen credentials to remote directories. The entire activity was visible inside the memory dump we analyzed.
Stealers are small but very dangerous pieces of malware designed to quietly collect passwords, cookies, autofill data, and other personal information. Instead of causing loud damage, they focus on moving fast and staying hidden. Many rely on trusted Windows processes or proxy tools to disguise their activity, and they often store most of their traces only in memory, which is why memory forensics is so important when investigating them. Most popular stealers, like RedLine or Amadey, are sold on underground markets as ready-made kits, complete with simple dashboards and subscription models. Their goal is always the same.
Hello, aspiring digital forensics investigators!
Welcome back to our guide on memory analysis!
In the first part, we covered the fundamentals, including processes, dumps, DLLs, handles, and services, using Volatility as our primary tool. We created this series to give you more clarity and help you build confidence in handling memory analysis cases. Digital forensics is a fascinating area of cybersecurity and earning a certification in it can open many doors for you. Once you grasp the key concepts, you’ll find it easier to navigate the field. Ultimately, it all comes down to mastering a core set of commands, along with persistence and curiosity. Governments, companies, law enforcement and federal agencies are all in need of skilled professionals As cyberattacks become more frequent and sophisticated, often with the help of AI, opportunities for digital forensics analysts will only continue to grow.
Now, in part two, we’re building on that to explore more areas that help uncover hidden threats. We’ll look at network info to see connections, registry keys for system changes, files in memory, and some scans like malfind and Yara rules to find malware. Plus, as promised, there are bonuses at the end for quick ways to pull out extra details
As a beginner analyst, you’d run network commands to check for sneaky connections, like if malware is phoning home to hackers. For example, imagine investigating a company’s network after a data breach, these tools could reveal a hidden link to a foreign server stealing customer info, helping you trace the attacker.
‘Netscan‘ scans for all network artifacts, including TCP/UDP. ‘Netstat‘ lists active connections and sockets. In Vol 2, XP/2003-specific ones like ‘connscan‘ and ‘connections‘ focus on TCP, ‘sockscan‘ and ‘sockets‘ on sockets, but they’re old and not present in Vol 3.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> netscan
vol.py -f “/path/to/file” ‑‑profile <profile> netstat
XP/2003 SPECIFIC:
vol.py -f “/path/to/file” ‑‑profile <profile> connscan
vol.py -f “/path/to/file” ‑‑profile <profile> connections
vol.py -f “/path/to/file” ‑‑profile <profile> sockscan
vol.py -f “/path/to/file” ‑‑profile <profile> sockets
Volatility 3:
vol.py -f “/path/to/file” windows.netscan
vol.py -f “/path/to/file” windows.netstat
bash$ > vol -f Windows7.vmem windows.netscan
This output shows network connections with protocols, addresses, and PIDs. Perfect for spotting unusual traffic.
bash$ > vol -f Windows7.vmem windows.netstat
Here, you’ll get a list of active sockets and states, like listening or established links.
Note, the XP/2003 specific plugins are deprecated and therefore not available in Volatility 3, although are still common in the poorly financed government sector.
You’d use hive list commands to find registry hives in memory, which store system settings malware often tweaks these for persistence. Say you’re checking a home computer after suspicious pop-ups. This could show changes to startup keys that launch bad software every boot.
‘hivescan‘ scans for hive structures. ‘hivelist‘ lists them with virtual and physical addresses.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> hivescan
vol.py -f “/path/to/file” ‑‑profile <profile> hivelist
Volatility 3:
vol.py -f “/path/to/file” windows.registry.hivescan
vol.py -f “/path/to/file” windows.registry.hivelist
bash$ > vol -f Windows7.vmem windows.registry.hivelist
This lists the registry hives with their paths and offsets for further digging.
bash$ > vol -f Windows7.vmem windows.registry.hivescan
The scan output highlights hive locations in memory.
Printkey is handy for viewing specific registry keys and values, like checking for malware-added entries. For instance, in a ransomware case, you might look at keys that control file associations to see if they’ve been hijacked.
Without a key, it shows defaults, while -K or –key targets a certain path.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> printkey
vol.py -f “/path/to/file” ‑‑profile <profile> printkey -K “Software\Microsoft\Windows\CurrentVersion”
Volatility 3:
vol.py -f “/path/to/file” windows.registry.printkey
vol.py -f “/path/to/file” windows.registry.printkey ‑‑key “Software\Microsoft\Windows\CurrentVersion”
bash$ > vol -f Windows7.vmem windows.registry.printkey
This gives a broad view of registry keys.
bash$ > vol -f Windows7.vmem windows.registry.printkey –key “Software\Microsoft\Windows\CurrentVersion”
Here, it focuses on the specified key, showing subkeys and values.
Filescan helps list files cached in memory, even deleted ones, great for finding malware files that were run but erased from disk. This can uncover temporary files from the infection.
Both versions scan for file objects in memory pools.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> filescan
Volatility 3:
vol.py -f “/path/to/file” windows.filescan
bash$ > vol -f Windows7.vmem windows.filescan
This output lists file paths, offsets, and access types.
You’d dump files to extract them from memory for closer checks, like pulling a suspicious script. In a corporate espionage probe, dumping a hidden document could reveal leaked secrets.
Without options, it dumps all. With offsets or PID, it targets specific ones. Vol 3 uses virtual or physical addresses.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir”
vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -Q <offset>
vol.py -f “/path/to/file” ‑‑profile <profile> dumpfiles ‑‑dump-dir=“/path/to/dir” -p <PID>
Volatility 3:
vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles
vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑virtaddr <offset>
vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles ‑‑physaddr <offset>
bash$ > vol -f Windows7.vmem windows.dumpfiles
This pulls all cached files Windows has in RAM.
Malfind scans for injected code in processes, flagging potential malware.
Vol 2 shows basics like hexdump. Vol 3 adds more details like protection and disassembly.
Volatility 2:
vol.py -f “/path/to/file” ‑‑profile <profile> malfind
Volatility 3:
vol.py -f “/path/to/file” windows.malfind
bash$ > vol -f Windows7.vmem windows.malfind
This highlights suspicious memory regions with details.
Yara scan uses rules to hunt for malware patterns across memory. It’s like a custom detector. For example, during a widespread attack like WannaCry, a Yara rule could quickly find infected processes.
Vol 2 uses file path. Vol 3 allows inline rules, file, or kernel-wide scan.
Volatility 2:
vol.py -f “/path/to/file” yarascan -y “/path/to/file.yar”
Volatility 3:
vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-rules <string>
vol.py -f “/path/to/file” windows.vadyarascan ‑‑yara-file “/path/to/file.yar”
vol.py -f “/path/to/file” yarascan.yarascan ‑‑yara-file “/path/to/file.yar”
bash$ > vol -f Windows7.vmem windows.vadyarascan –yara-file yara_fules/Wannacrypt.yar
As you can see we found the malware and all related processes to it with the help of the rule
Using the strings command, you can quickly uncover additional useful details, such as IP addresses, email addresses, and remnants from PowerShell or command prompt activities.
bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"
bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"
bash$ > strings Windows7.vmem | grep -E "(cmd|powershell|bash)[^\s]+"
By now you should feel comfortable with all the network analysis, file dumps, hives and registries we had to go through. As you practice, your confidence will grow fast. The commands covered here will help you solve most of the cases as they are fundamental. Also, don’t forget that Volatility has a lot more different plugins that you may want to explore. Feel free to come back to this guide anytime you want. Part 1 will remind you how to approach a memory dump, while Part 2 has the commands you need. In this part, we’ve expanded your Volatility toolkit with network scans to track connections, registry tools to check settings, file commands to extract cached items, and miscellaneous scans like malfind for injections and Yara for pattern matching. Together they give you a solid set of steps.
If you want to turn this into a career, our digital forensics courses are built to get you there. Many students use this training to prepare for industry certifications and job interviews. Our focus is on the practical skills that hiring teams look for.
Microsoft recently announced the launch of Project Ire – a dedicated AI agent for malware…
Project Ire – Microsoft Launches AI Agent For Automated Malware Classification on Latest Hacking News | Cyber Security News, Hacking Tools and Penetration Testing Courses.
Black Hat USA 2025 was nothing short of groundbreaking. The show floor and conference tracks were buzzing with innovation, but one theme stood above all others – the rapid advancement...
The post AI Takes Center Stage at Black Hat USA 2025 – Booz Allen Leads the Conversation appeared first on Cyber Defense Magazine.
sandfly-entropyscan is a utility to quickly scan files or running processes and report on their entropy (measure of randomness) and if they are a Linux/Unix ELF type executable. Some malware for Linux is packed or encrypted and shows very high entropy. This tool can quickly find high entropy executable files and processes which often are malicious.
Entropy is a measure of randomness. For binary data 0.0 is not-random and 8.0 is perfectly random. Good crypto looks like random white noise and will be near 8.0. Good compression removes redundant data making it appear more random than if it was uncompressed and usually will be 7.7 or above.
A lot of malware executables are packed to avoid detection and make reverse engineering harder. Most standard Linux binaries are not packed because they aren't trying to hide what they are. Searching for high entropy files is a good way to find programs that could be malicious just by having these two attributes of high entropy and executable.
Usage of sandfly-entropyscan:
-csv output results in CSV format (filename, path, entropy, elf_file [true|false], MD5, SHA1, SHA256, SHA512)
-delim change the default delimiter for CSV files of "," to one of your choosing ("|", etc.)
-dir string directory name to analyze
-file string full path to a single file to analyze
-proc check running processes (defaults to ELF only check)
-elf only check ELF executables
-entropy float show any file/process with entropy greater than or equal to this value (0.0 min - 8.0 max, defaults 0 to show all files)
-version show version and exit
Search for any file that is executable under /tmp:
sandfly-entropyscan -dir /tmp -elf
Search for high entropy (7.7 and higher) executables (often packed or encrypted) under /var/www:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Generates entropy and cryptographic hashes of all running processes in CSV format:
sandfly-entropyscan -proc -csv
Search for any process with an entropy higher than 7.7 indicating it is likely packed or encrypted:
sandfly-entropyscan -proc -entropy 7.7
Generate entropy and cryptographic hash values of all files under /bin and output to CSV format (for instance to save and compare hashes):
sandfly-entropyscan -dir /bin -csv
Scan a directory for all files (ELF or not) with entropy greater than 7.7: (potentially large list of files that are compressed, png, jpg, object files, etc.)
sandfly-entropyscan -dir /path/to/dir -entropy 7.7
Quickly check a file and generate entropy, cryptographic hashes and show if it is executable:
sandfly-entropyscan -file /dev/shm/suspicious_file
Do spot checks on systems you think have a malware issue. Or you can automate the scan so you will get an output if we find something show up that is high entropy in a place you didn't expect. Or simply flag any executable ELF type file that is somewhere strange (e.g. hanging out in /tmp or under a user's HTML directory). For instance:
Did a high entropy binary show up under the system /var/www directory? Could be someone put a malware dropper on your website:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Setup a cron task to scan your /tmp, /var/tmp, and /dev/shm directories for any kind of executable file whether it's high entropy or not. Executable files under tmp directories can frequently be a malware dropper.
sandfly-entropyscan -dir /tmp -elf
sandfly-entropyscan -dir /var/tmp -elf
sandfly-entropyscan -dir /dev/shm -elf
Setup another cron or automated security sweep to spot check your systems for highly compressed or encrypted binaries that are running:
sandfly-entropyscan -proc -entropy 7.7
git clone https://github.com/sandflysecurity/sandfly-entropyscan.git
go build
./sandfly-entropyscan
There are a some basic build scripts that build for various platforms. You can use these to build or modify to suit. For Incident Responders, it might be useful to keep pre-compiled binaries ready to go on your investigation box.
build.sh - Build for current OS you're running on when you execute it.
We use a simple method for seeing if a file may be an executable ELF type. We can spot ELF format files for multiple platforms. Even if malware has Intel/AMD, MIPS and Arm dropper binaries we will still be able to spot all of them.
It's possible to flag a legitimate binary that has a high entropy because of how it was compiled, or because it was packed for legitimate reasons. Other files like .zip, .gz, .png, .jpg and such also have very high entropy because they are compressed formats. Compression removes redundancy in a file which makes it appear to be more random and has higher entropy.
On Linux, you may find some kinds of libraries (.so files) get flagged if you scan library directories.
However, it is our experience that executable binaries that also have high entropy are often malicious. This is especially true if you find them in areas where executables normally shouldn't be (such as again tmp or html directories).
The entropy calculation requires reading in all the bytes of the file and tallying them up to get a final number. It can use a lot of CPU and disk I/O, especially on very large file systems or very large files. The program has an internal limit where it won't calculate entropy on any file over 2GB, nor will it try to calculate entropy on any file that is not a regular file type (e.g. won't try to calculate entropy on devices like /dev/zero).
Then we calculate MD5, SHA1, SHA256 and SHA512 hashes. Each of these requires going over the file as well. It's reasonable speed on modern systems, but if you are crawling a very large file system it can take some time to complete.
If you tell the program to only look at ELF files, then the entropy/hash calculations won't happen unless it is an ELF type and this will save a lot of time (e.g. it will ignore massive database files that aren't executable).
If you want to automate this program, it's best to not have it crawl the entire root file system unless you want that specifically. A targeted approach will be faster and more useful for spot checks. Also, use the ELF flag as that will drastically reduce search times by only processing executable file types.
For incident responders, running sandfly-entropyscan against the entire top-level "/" directory may be a good idea just to quickly get a list of likely packed candidates to investigate. This will spike CPU and disk I/O. However, you probably don't care at that point since the box has been mining cryptocurrency for 598 hours anyway by the time the admins noticed.
Again, use the ELF flag to get to the likely problem candidate executables and ignore the noise.
There is a script called scripts/testfiles.sh that will make two files. One will be full of random data and one will not be random at all. When you run the script it will make the files and run sandfly-entropyscan in executable detection mode. You should see two files. One with very high entropy (at or near 8.0) and one full of non-random data that should be at 0.00 for low entropy. Example:
./testfiles.sh
Creating high entropy random executable-like file in current directory.
Creating low entropy executable-like file in current directory.
high.entropy.test, entropy: 8.00, elf: true
low.entropy.test, entropy: 0.00, elf: true
You can also load up the upx utility and compress an executable and see what values it returns.
Sandfly Security produces an agentless endpoint detection and incident response platform (EDR) for Linux. Automated entropy checks are just one of thousands of things we search for to find intruders without loading any software on your Linux endpoints.
Get a free license and learn more below:
https://www.sandflysecurity.com @SandflySecurity
sandfly-entropyscan is a utility to quickly scan files or running processes and report on their entropy (measure of randomness) and if they are a Linux/Unix ELF type executable. Some malware for Linux is packed or encrypted and shows very high entropy. This tool can quickly find high entropy executable files and processes which often are malicious.
Entropy is a measure of randomness. For binary data 0.0 is not-random and 8.0 is perfectly random. Good crypto looks like random white noise and will be near 8.0. Good compression removes redundant data making it appear more random than if it was uncompressed and usually will be 7.7 or above.
A lot of malware executables are packed to avoid detection and make reverse engineering harder. Most standard Linux binaries are not packed because they aren't trying to hide what they are. Searching for high entropy files is a good way to find programs that could be malicious just by having these two attributes of high entropy and executable.
Usage of sandfly-entropyscan:
-csv output results in CSV format (filename, path, entropy, elf_file [true|false], MD5, SHA1, SHA256, SHA512)
-delim change the default delimiter for CSV files of "," to one of your choosing ("|", etc.)
-dir string directory name to analyze
-file string full path to a single file to analyze
-proc check running processes (defaults to ELF only check)
-elf only check ELF executables
-entropy float show any file/process with entropy greater than or equal to this value (0.0 min - 8.0 max, defaults 0 to show all files)
-version show version and exit
Search for any file that is executable under /tmp:
sandfly-entropyscan -dir /tmp -elf
Search for high entropy (7.7 and higher) executables (often packed or encrypted) under /var/www:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Generates entropy and cryptographic hashes of all running processes in CSV format:
sandfly-entropyscan -proc -csv
Search for any process with an entropy higher than 7.7 indicating it is likely packed or encrypted:
sandfly-entropyscan -proc -entropy 7.7
Generate entropy and cryptographic hash values of all files under /bin and output to CSV format (for instance to save and compare hashes):
sandfly-entropyscan -dir /bin -csv
Scan a directory for all files (ELF or not) with entropy greater than 7.7: (potentially large list of files that are compressed, png, jpg, object files, etc.)
sandfly-entropyscan -dir /path/to/dir -entropy 7.7
Quickly check a file and generate entropy, cryptographic hashes and show if it is executable:
sandfly-entropyscan -file /dev/shm/suspicious_file
Do spot checks on systems you think have a malware issue. Or you can automate the scan so you will get an output if we find something show up that is high entropy in a place you didn't expect. Or simply flag any executable ELF type file that is somewhere strange (e.g. hanging out in /tmp or under a user's HTML directory). For instance:
Did a high entropy binary show up under the system /var/www directory? Could be someone put a malware dropper on your website:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Setup a cron task to scan your /tmp, /var/tmp, and /dev/shm directories for any kind of executable file whether it's high entropy or not. Executable files under tmp directories can frequently be a malware dropper.
sandfly-entropyscan -dir /tmp -elf
sandfly-entropyscan -dir /var/tmp -elf
sandfly-entropyscan -dir /dev/shm -elf
Setup another cron or automated security sweep to spot check your systems for highly compressed or encrypted binaries that are running:
sandfly-entropyscan -proc -entropy 7.7
git clone https://github.com/sandflysecurity/sandfly-entropyscan.git
go build
./sandfly-entropyscan
There are a some basic build scripts that build for various platforms. You can use these to build or modify to suit. For Incident Responders, it might be useful to keep pre-compiled binaries ready to go on your investigation box.
build.sh - Build for current OS you're running on when you execute it.
We use a simple method for seeing if a file may be an executable ELF type. We can spot ELF format files for multiple platforms. Even if malware has Intel/AMD, MIPS and Arm dropper binaries we will still be able to spot all of them.
It's possible to flag a legitimate binary that has a high entropy because of how it was compiled, or because it was packed for legitimate reasons. Other files like .zip, .gz, .png, .jpg and such also have very high entropy because they are compressed formats. Compression removes redundancy in a file which makes it appear to be more random and has higher entropy.
On Linux, you may find some kinds of libraries (.so files) get flagged if you scan library directories.
However, it is our experience that executable binaries that also have high entropy are often malicious. This is especially true if you find them in areas where executables normally shouldn't be (such as again tmp or html directories).
The entropy calculation requires reading in all the bytes of the file and tallying them up to get a final number. It can use a lot of CPU and disk I/O, especially on very large file systems or very large files. The program has an internal limit where it won't calculate entropy on any file over 2GB, nor will it try to calculate entropy on any file that is not a regular file type (e.g. won't try to calculate entropy on devices like /dev/zero).
Then we calculate MD5, SHA1, SHA256 and SHA512 hashes. Each of these requires going over the file as well. It's reasonable speed on modern systems, but if you are crawling a very large file system it can take some time to complete.
If you tell the program to only look at ELF files, then the entropy/hash calculations won't happen unless it is an ELF type and this will save a lot of time (e.g. it will ignore massive database files that aren't executable).
If you want to automate this program, it's best to not have it crawl the entire root file system unless you want that specifically. A targeted approach will be faster and more useful for spot checks. Also, use the ELF flag as that will drastically reduce search times by only processing executable file types.
For incident responders, running sandfly-entropyscan against the entire top-level "/" directory may be a good idea just to quickly get a list of likely packed candidates to investigate. This will spike CPU and disk I/O. However, you probably don't care at that point since the box has been mining cryptocurrency for 598 hours anyway by the time the admins noticed.
Again, use the ELF flag to get to the likely problem candidate executables and ignore the noise.
There is a script called scripts/testfiles.sh that will make two files. One will be full of random data and one will not be random at all. When you run the script it will make the files and run sandfly-entropyscan in executable detection mode. You should see two files. One with very high entropy (at or near 8.0) and one full of non-random data that should be at 0.00 for low entropy. Example:
./testfiles.sh
Creating high entropy random executable-like file in current directory.
Creating low entropy executable-like file in current directory.
high.entropy.test, entropy: 8.00, elf: true
low.entropy.test, entropy: 0.00, elf: true
You can also load up the upx utility and compress an executable and see what values it returns.
Sandfly Security produces an agentless endpoint detection and incident response platform (EDR) for Linux. Automated entropy checks are just one of thousands of things we search for to find intruders without loading any software on your Linux endpoints.
Get a free license and learn more below:
https://www.sandflysecurity.com @SandflySecurity
IBM X-Force researchers have discovered a new campaign targeting organizations with fake business emails that deliver NetWire remote-access Trojan (RAT) variants.
The RAT is hidden inside an IMG file, which is a file extension used by disk imaging software. Since many attachments can be automatically blocked by email security controls, spammers often carefully choose the type of file extensions they use in malspam messages, and shuffle the types of files they conceal malware in. X-Force’s analysis shows that emails delivered by the NetWire RAT in this campaign are being sent from a small number of unique senders supposedly located in Germany.
The NetWire RAT is a malicious tool that emerged in the wild in 2012. This multi-platform malware has since undergone various upgrade cycles and was detected in different types of attacks that range from cybercrime endeavors by Nigerian scammers to advanced persistent threat (APT) attacks. The NetWire RAT is a commercial offering that can be easily purchased on Dark Web markets, which means that it can be used by just about any threat actor.
This isn’t the first time NetWire is being delivered in fake business communications. In a previous campaign launched in September 2019, its operators sent booby-trapped fake PDF files to potential victims, indicating it was a commercial invoice. The actual file was an executable that installed the NetWire RAT as soon as the file was clicked.
In one of the samples we looked into, an IMG file named “Sales_Quotation_SQUO00001760.img.” was a way for the attackers to archive the malware until the file was clicked open. Once opened, it extracted an executable: the NetWire RAT.
Immediately after this initial execution, the malware established persistence via a scheduled task, a common tactic to many malware developers. Scheduled tasks enable the malware to keep checking that it’s active or relaunch itself in a recurring fashion.
Additionally, registry keys are created to store the command-and-control (C&C) server’s IP address and save data used by the malware to operate on the infected device. Communication with the C&C server is performed over TCP port 3012.
Since this malware can be used by any group with any motivation, attribution is rather futile. What we did want to figure out was what the NetWire RAT campaign we detected was after this time.
Looking at some unencrypted strings found in memory, we identified a series of strings written in a foreign language, which appears to be Indonesian. Below is a screenshot from Google Translate showing a rough translation of the various identified strings. Many of these terms either relate to a login prompt, payment options, donations or the term “afterlife savings”:
Figure 1: Translated malware strings from recent NetWire RAT campaign
This term may relate to permanent life insurance for retirement purposes offered in some parts of the world.
From the overall look of it, this campaign is financially motivated and most likely being carried out by local fraudsters looking to rob account owners in various ways. Although we have not seen the complete post-infection flow, it may be followed up by a 419-type scam, or might also include social engineering or phishing pages to lure the victim to enter their banking credentials and enable the attackers to take over their accounts.
Recent campaigns in the wild show that the NetWire RAT is not the only malware being delivered via disk imaging file extensions. This was somewhat of a trend in late 2019, likely because the same spamming operators were distributing RATs for different threat actors.
Oftentimes, as security professionals, we hear about the larger and more impactful data breaches, ransomware attacks, and destructive campaigns, which are often carried out by sophisticated cybercrime gangs. But while most financially motivated cybercrime is the work of larger, organized crime groups, smaller factions are still very much in business, and they too target businesses to compromise bank accounts and steal money by using commercially available malware year-round.
Indicators of compromise (IoCs) and other information on how to protect networks from the NetWire RAT can be found on IBM X-Force Exchange.
The post New NetWire RAT Campaigns Use IMG Attachments to Deliver Malware Targeting Enterprise Users appeared first on Security Intelligence.
Login