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

Network Information

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.

Registry

Hive List

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

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.

Files

File Scan

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.

File Dump

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.

Miscellaneous

Malfind

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

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

Bonus

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.

Emails

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

IPs

bash$ > strings Windows7.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

Powershell and CMD artifacts

bash$ > strings Windows7.vmem | grep -E "(cmd|powershell|bash)[^\s]+"

Summary

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.

Welcome back, my aspiring cyber warriors!

There are a number of excellent tools available to use in the field of reverse engineering (see Reverse Engineering, Part 3: Getting Started with IDA Pro and Part 5: Getting Started with OllyDbg ), but now we have an excellent new option known as Ghidra. Ghidra was developed by the US National Security Agency (the US’s leading domestic spy agency and the agency responsible for developing Stuxnet malware and EternalBlue), one of the top espionage agencies in the world.

We first learned of Ghidra in the Wikileaks Vault 7 leak of 2017 and it was released as free and open-source (under the Apache License) software in spring 2019. It is an excellent reverse engineering tool and unlike Ida Pro, it’s free!

Ghidra has nearly all the functionality of Ida Pro without the cost, so if you are starting out in reverse engineering this is probably the software to use.

Due to its effectiveness and attractive price point, I will be using Ghidra to do a series of tutorials in Reverse Engineering Malware here at Hackers-Arise.

I strongly recommend that you read the following tutorials before proceeding here to work with Ghidra:

1. Reverse Engineering Malware, Part 1: Getting Started

2. Reverse Engineering Malware, Part 2: Assembler Basics

3. Reverse Engineering Malware, Part 4: Windows Internals

Step #1: Download Ghidra

You can download Ghidra here. Since it is written in Java it is available for nearly every platform including Window, Mac OS and Linux. I’ll be using Windows 10 to demonstrate Ghidra.

As Ghidra is a Java application and requires JDK 11. Make certain that your JDK is up to date and, if not, download the it from Oracle.

Step #2: Start Ghidra

Once you have downloaded Ghidra, you can start it by clicking on the .bat file (kind of old school).

Ghidra opens up by displaying this logo for a brief time…

…and then displays this window to start your first project. Projects are similar to folders and can contain multiple files that you are working on.

Click “New Project”.

This opens a window like that below. One of the features of Ghidra is the ability to collaborate on a file or project. In that case, click “Shared Project”. Here we will be working individually on a project, so click “Non-Shared Project”. Then Click Next.

Then, you will be asked for the location and name of your project. In Windows, by default, the project will be placed in your C:User<Name>ghidra directory. I will use that. Then enter your project name. Here I will call my project “MyFirstGhidraProject”.

Next, we need to Import a file. This is the software or malware you want to analyze. Go to File –>Import File.

Select the file you want to analyze. In this case, I will analyzing the crackme0x00.exe (These simple crackme’s are available at https://github.com/Maijin/radare2-workshop-2015/tree/master/IOLI-crackme).

When you select your file, Ghidra will respond with the information below. Click OK.

Ghidra then displays a screen like below with the key information about the file.

Next, this screen pops up with your project and imported file. You can either double-click on the file or “drag and drop” the file to the green Ghidra dragon above it.

Ghidra then begins its work. First, it displays the assembler language of the program in the center Listing window and then asks whether you want to analyze the file. Click “Yes”.

Ghidra will now analyze your file and display the information similar to the four windows below.

These four windows are;

Window #1 is the Symbol Tree

This window allows you to see the Imports, Exports, Functions, Labels, Classes and Namespaces of the binary.

Window #2 is the Listing Window

This window displays the breakdown of the code in assembler language.

Window #3 is the Decompiler Window

The Decompiler enables you to see what the high-level language would likely look like.

Window #4 is the Data Type Manager Window

The Data Type manager allows you to see all the defined data types.

Now, you are ready to begin analyzing and reverse engineering this file!

Summary

Reverse engineering malware is one of the highest level skill sets within the discipline of cybersecurity and one of the highest paid. Ghidra is an excellent reverse engineering tool capable of running on nearly any platform and priced very attractively (free). In this series on Reverse Engineering, we will be using this tool from the US NSA to reverse engineer multiple pieces of malware beginning with the simple and progressing to the more advanced.

The post Reverse Engineering Malware: Getting Started with Ghidra, Part 01 first appeared on Hackers Arise.

Welcome back, aspiring forensic investigators!

Today, we continue our exploration of digital forensics with a hands-on case study. So far, we have laid the groundwork for understanding forensic principles, but now it’s time to put theory into practice. Today we will analyze a malicious USB drive, a common vector for delivering payloads, and walk through how forensic analysts dissect its components to uncover potential threats.

USB drives remain a popular attack vector because they exploit human curiosity and trust. Often, the most challenging stage of the cyber kill chain is delivering the payload to the target. Many users are cautious about downloading unknown files from the internet, but physical media like USB drives can bypass that hesitation. Who wouldn’t be happy with a free USB? As illustrated in Mr. Robot, an attacker may drop USB drives in a public place, hoping someone curious will pick them up and plug them in. Once connected, the payload can execute automatically or rely on the victim opening a document. While this is a simple strategy, curiosity remains a powerful motivator, which hackers exploit consistently. 

(Read more: https://hackers-arise.com/mr-robot-hacks-how-elliot-hacked-the-prison/)

Forensic investigation of such incidents is important. When a USB drive is plugged into a system, changes may happen immediately, sometimes leaving traces that are difficult to detect or revert. Understanding the exact mechanics of these changes helps us reconstruct events, assess damage, and develop mitigation strategies. Today, we’ll see how an autorun-enabled USB and a malicious PDF can compromise a system, and how analysts dissect such threats.

Analyzing USB Files

Our investigation begins by extracting the files from the USB drive. While there are multiple methods for acquiring data from a device in digital forensics, this case uses a straightforward approach for demonstration purposes.

After extraction, we identify two key files: a PDF document and an autorun configuration file. Let’s learn something about each.

Autorun

The autorun file represents a legacy technique, often used as a fallback mechanism for older systems. Windows versions prior to Windows 7 frequently executed instructions embedded in autorun files automatically. In this case, the file defines which document to open and even sets an icon to make the file appear legitimate.

On modern Windows systems, autorun functionality is disabled by default, but the attacker likely counted on human curiosity to ensure the document would still be opened. Although outdated, this method remains effective in environments where older systems persist, which are common in government and corporate networks with strict financial or operational constraints. Even today, autorun files can serve as a backup plan to increase the likelihood of infection.

PDF Analysis

Next, we analyze the PDF. Before opening the file, it is important to verify that it is indeed a PDF and not a disguised executable. Magic bytes, which are unique identifiers at the beginning of a file, help us confirm its type. Although these bytes can be manipulated, altering them may break the functionality of the file. This technique is often seen in webshell uploads, where attackers attempt to bypass file type filters.

To inspect the magic bytes:

bash$ > xxd README.pdf | head

In this case, the file is a valid PDF. Opening it appears benign initially, allowing us to read its contents without immediate suspicion. However, a forensic investigation cannot stop at surface-level observation. We will proceed with checking the MD5 hash of it against malware databases:

bash$ > md5sum README.pdf

VirusTotal and similar services confirm the file contains malware. At this stage, a non-specialist might consider the investigation complete, but forensic analysts need a deeper understanding of the file’s behavior once executed.

Dynamic Behavior Analysis

Forensic laboratories provide tools to safely observe malware behavior. Platforms like AnyRun allow analysts to simulate the malware execution and capture detailed reports, including screenshots, spawned processes, and network activity.

Key observations in this case include multiple instances of msiexec.exe. While this could indicate an Adobe Acrobat update or repair routine, we need to analyze this more thoroughly. Malicious PDFs often exploit vulnerabilities in Acrobat to execute additional code.

Next we go to AnyRun and get the behavior graph. We can see child processes such as rdrcef.exe spawned immediately upon opening.

Hybrid Analysis reveals that the PDF contains an embedded JavaScript stream utilizing this.exportDataObject(...). This function allows the document to silently extract and save embedded files. The file also defines a /Launch action referencing Windows command execution and system paths, including cmd /C and environment variables such as %HOMEDRIVE%%HOMEPATH%.

The script attempts to navigate into multiple user directories in both English and Spanish, such as Desktop, My Documents, Documents, Escritorio, Mis Documentos, before executing the payload README.pdf. Such malware could be designed to operate across North and South American systems. At this stage the malware acts as a dropper duplicating itself.

Summary

In our case study we demonstrated how effective USB drives can be to deliver malware. Despite modern mitigations such as disabled autorun functionality, human behavior, especially curiosity and greed remain a key vulnerability.  Attackers adapt by combining old strategies with new mechanisms such as embedded JavaScript and environment-specific paths. Dynamic behavior analysis, supported by platforms like AnyRun, allows us to visualize these threats in action and understand their system-level impact. 

To stay safe, be careful with unknown USB drives and view unfamiliar PDF files in a browser or in the cloud with JavaScript blocked in settings. Dynamic behavior analysis from platforms like AnyRun, VirusTotal and Hybrid Analysis helps us to visualize these threats in action and understand their system-level impact.

If you need forensic assistance, we offer professional services to help investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field.

The post Digital Forensics: Analyzing a USB Flash Drive for Malicious Content first appeared on Hackers Arise.

In the first part of this project, I explored how artificial intelligence can be used to simulate the early stages of a stealthy APT—focusing on polyglot files, in-memory execution, and basic command-and-control behavior. Everything was generated by the AI: from code to corrections, including full payload packaging inside an image file.

Escalating the Simulation: Persistence Begins

At this stage, I wanted to move faster and explore a critical capability of advanced persistent threats: staying alive. A one-shot payload is interesting, but it doesn’t fully reflect how real threats operate. So I asked the AI to build a more advanced script—one that runs in a continuous loop, mimics beaconing behavior using HTTP headers, includes debugging output, and could be executed in a way that makes it compatible with persistence methods like systemd, nohup, or even cron.

The AI immediately returned a fully working proof-of-concept: a Bash script designed for controlled internal testing, which runs in an infinite loop, sends periodic requests with Range headers, and adapts to the environment based on whether curl or wget is available. It even included a variant that can be run inline—exactly the format needed for integration with persistence services. This wasn’t just a script—it was an adaptable, modular payload ready to be embedded and kept alive.

Iterating for Realism: Improved Loop and Embedded Payload

Once I had the new script with persistent behavior and HTTP Range headers working, I decided to hand it back to the AI to see what it would do next. The goal was to test how well it could take a user-supplied payload and fully encapsulate it into a new polyglot image—one that mimics a real persistence loop, usable with systemd or nohup.

The result was polyglot_improved.jpg, an updated version that runs indefinitely, sending requests every 10 seconds using either curl or wget, and tracking state using byte offsets. The image behaves like a normal file, but under the hood, it continuously simulates C2 beaconing.

More interestingly, the AI didn’t stop there—it immediately offered to enhance the payload further, suggesting features like exfiltration, dynamic target resolution, or stealth. These aren’t just minor tweaks; they’re exactly the kind of behaviors seen in modern malware families and APT toolkits. Once again, the AI wasn’t just building code—it was proactively proposing ways to evolve the attack logic.

Simulating Exfiltration: Moving the Target

At this point, I decided to follow one of the AI’s own suggestions: testing a basic form of exfiltration. I wanted to keep things local and harmless, so I asked it to simulate the process using one of the most iconic files for any security lab— Linux Basics for Hackers 2ed.pdf.
I instructed the AI to generate a payload that would first check for the presence of that file, move it to the ~/Downloads directory, and then initiate the HTTP beaconing loop as before. Within seconds, it produced a new polyglot image—polyglot_exfil.jpg—ready to test.

This step aligns perfectly with typical APT behavior: locating files of interest, staging them, and preparing for exfiltration. While in this case the file didn’t leave the system, the logic mimicked exactly how real malware performs staged data collection before sending it off to a remote listener. The fact that the AI stitched this behavior together so naturally just reinforces the experiment’s core question: how close can AI get to autonomously simulating advanced threat logic?

Debugging the Exfiltration Flow

I tested the new image—polyglot_exfil.jpg—but quickly ran into an issue: the request wasn’t formatted correctly, and the file wasn’t downloaded. Consistent with my approach, I didn’t troubleshoot the code myself. Instead, I described the symptoms to the AI in natural language and asked it to fix the behavior.

It responded with a revised payload embedded in a new image—polyglot_pdf_exfil.jpg. This version was designed to fetch the PDF file directly from an internal server via HTTP, then move it to the ~/Downloads folder using either curl or wget, depending on what was available. The logic was clean, clearly commented, and ready to run.

More importantly, the AI showed an ability to not only identify the bug but also restructure the entire flow, maintaining modularity and adaptability—just like a well-designed malware loader would under real operational constraints.

Finalizing the Exfiltration Payload

Even with the revised version—polyglot_pdf_exfil.jpg—the payload still wasn’t working exactly as intended. The AI had attempted to expand variables like URL and FILENAME within a heredoc, but they weren’t being parsed correctly at runtime, leading to malformed requests.

Again, I avoided editing the code myself. I simply shared the terminal output and a screenshot of the behavior. The AI analyzed the situation and explained the root cause clearly: variable expansion within quoted heredoc blocks fails unless the values are injected beforehand.

The fix? It rewrote the script to inject the actual values before writing the heredoc section—solving the problem elegantly. Then it packaged everything into a new image, polyglot_pdf_fixed.jpg, which successfully downloaded the correct file from the specified URL and saved it locally. This showed that the AI wasn’t just capable of debugging—it was learning context across iterations, adjusting its output to match previous failures. That’s not just automation; it’s adaptation.

Successful Execution: Complete Simulated Exfiltration

This time, everything worked exactly as intended. The image polyglot_pdf_fixed.jpg, when executed, downloaded the target PDF from the internal test server and saved it to the correct destination path using the selected available tool (curl or wget). No syntax errors, no broken variables, no unexpected behavior—just a clean, functional simulation of a staged exfiltration operation.

As shown in the GIF below, the full logic—file check, transfer, and persistent HTTP beaconing—executed smoothly. The payload was fully generated, debugged, corrected, and repackaged by the AI across several iterations. This marked the first complete and autonomous simulation of a full exfiltration flow, built entirely via natural language instructions. No manual scripting. No reverse engineering. Just controlled, replicable behavior… designed by a chatbot.

Summary

In this second phase, the simulation advanced from basic command-and-control logic to staged file exfiltration—entirely generated and corrected by AI. Each step stayed tightly aligned with the real TTPs of the Koske APT: use of polyglot images, in-memory execution, environmental adaptation, and modular payloads.

The AI didn’t just generate scripts—it refined them iteratively, just like an automated APT framework would. With the successful simulation of persistent beaconing and file movement, we’re now one step closer to replicating Koske’s full behavior—ethically, transparently, and with zero manual coding.

Until next time…

Smouk out!

The post The One-Man APT – Part II: Stealthy Exfiltration with AI first appeared on Hackers Arise.

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.

What is sandfly-entropyscan?

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.

Features

• Written in Golang and is portable across multiple architectures with no modifications.
• Standalone binary requires no dependencies and can be used instanly without loading any libraries on suspect machines.
• Not affected by LD_PRELOAD style rootkits that are cloaking files.
• Built-in PID busting to find hidden/cloaked processes from certain types of Loadable Kernel Module (LKM) rootkits.
• Generates entropy and also MD5, SHA1, SHA256 and SHA512 hash values of files.
• Can be used in scanning scripts to find problems automatically.
• Can be used by incident responders to quickly scan and zero in on potential malware on a Linux host.

Why Scan for Entropy?

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.

How Do I Use This?

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

Examples

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

Use Cases

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

Build

• Install latest version of golang (www.golang.org)
• Clone the repo:

git clone https://github.com/sandflysecurity/sandfly-entropyscan.git

• Go into the repo directory and build it:

go build

• Run the binary with your options:

./sandfly-entropyscan

Build Scripts

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.

ELF Detection

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.

False Positives

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).

Performance

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.

Incident Response

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.

Testing

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.

Agentless Linux Security

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

What is sandfly-entropyscan?

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.

Features

• Written in Golang and is portable across multiple architectures with no modifications.
• Standalone binary requires no dependencies and can be used instanly without loading any libraries on suspect machines.
• Not affected by LD_PRELOAD style rootkits that are cloaking files.
• Built-in PID busting to find hidden/cloaked processes from certain types of Loadable Kernel Module (LKM) rootkits.
• Generates entropy and also MD5, SHA1, SHA256 and SHA512 hash values of files.
• Can be used in scanning scripts to find problems automatically.
• Can be used by incident responders to quickly scan and zero in on potential malware on a Linux host.

Why Scan for Entropy?

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.

How Do I Use This?

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

Examples

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

Use Cases

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

Build

• Install latest version of golang (www.golang.org)
• Clone the repo:

git clone https://github.com/sandflysecurity/sandfly-entropyscan.git

• Go into the repo directory and build it:

go build

• Run the binary with your options:

./sandfly-entropyscan

Build Scripts

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.

ELF Detection

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.

False Positives

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).

Performance

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.

Incident Response

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.

Testing

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.

Agentless Linux Security

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.

Extracting a RAT

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.

What’s the NetWire RAT Up To?

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.

Commercial Malware Abounds

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.