Welcome back, aspiring forensic investigators!

We continue our practical series on digital forensics and will look at the memory dump of a Windows machine after a ransomware attack. Ransomware incidents are common, although they may not always be the most profitable attacks because they require a lot of effort and stealth. Some operations take months of hard work and sleepless nights and still never pay off. Many attackers prefer to steal data and sell it on the dark web. Such data sells well and quickly. State sponsored APTs act similarly. Their goal is to stay silent and extract as much intelligence as possible.

Today, a thousand unique entries of private information of Russian citizens cost about $100. That’s cheap. But it also shows how effective Ukrainian and foreign hackers are against Russia. All this raises demand for digital forensics and incident response, since fines for data leaks can be enormous. It’s not only fines that are a threat. Reputation damage is critical. If your competitor has never, at least yet, experienced a data breach and you did and it went public, trust in your company will start crumbling and customers will be inclined to use your competitors’ services. An even worse scenario is a ransomware attack that locks down much of your organization and wipes out your backups. Paying the attackers gives no guarantee of recovering your data, and some companies never manage to recover at all.

So let’s investigate one of those attacks and learn something new to stay sharp.

Memory Analysis

It all begins with a memory dump. Here we already have a memory dump file of an infected machine that we are going to inspect.

Installing Volatility

On our Kali machine we created a new Python virtual environment for Volatility. Keeping separate environments is good practice because it prevents tools from interfering with other dependencies. Sometimes installing one tool can break another. Here is how you do it:

bash$ > python3 -m venv env_name

bash$ > source env_name/bin/activate

Now we are ready to install Volatility in this environment:

bash$ > pip3 install volatility3

It is also good practice to record the exact versions of Volatility and Python you used (for example, pip3 show volatility3 and python3 --version). Memory forensics tools change over time and some plugins behave slightly differently between releases. Recording versions makes your work reproducible later.

Image Information

One of the first things we look at after receiving a memory dump is the captured metadata. The Volatility 3 command is simple:

bash$ vol -f infected.vmem windows.info

When you run windows.info, inspect the OS build, memory size, and timestamps shown by the capture tool. That OS build value helps Volatility pick the correct symbol tables. Incorrect symbols can cause missing or malformed output. This is especially important if you are working with Volatility 2. Also confirm the capture method and metadata such as who made the capture, when, and whether the capture was acquired after isolating the machine. Recording this chain-of-custody metadata is a small step that greatly strengthens any forensic report.

Processes

The goal of the memory dump is to preserve processes, injections, and shellcode before they disappear after a reboot. That means we need to focus on the processes that existed at capture time. Let’s list them all:

bash$ > vol -f infected.vmem windows.pslist

Suspicious processes are not always easy to spot. It depends on the attacker’s tactics. Ransomware processes, unlike persistence mechanisms, are often obvious because attackers tend to pick violent or alarming names for encryptors. But that’s not always the case, so let’s give our image a closer look.

Among other processes, a ransomware process sticks out. You may also notice or4qtckT.exe and other processes with unknown names. Random executable names are not definitive proof of maliciousness, but they’re a reliable starting point for closer inspection. Some legitimate software may also generate processes with random names, for example, Dr.Web, a Russian antivirus.

When a process name looks random, check several things: the process parent, the process start time (did it start right before the incident?), open network sockets, loaded DLLs, and whether the executable exists on disk or only in memory. Processes that only exist in the RAM image (no matching file on disk) often indicate in-memory unpacking or fileless behavior. These are important signals in malware analysis. Use plugins like windows.psscan (process scan) to find processes that pslist might miss and windows.pstree to visualize parent/child relationships. Also check windows.dlllist to see suspicious DLLs loaded into a process. Injected code often pulls suspicious DLL names or shows unnatural memory protections on executable pages.

Parent Relationships

Once you find malware, your next step is to find its parent. A parent is the process that launches another process. This is how you unravel the attack by going back in the timeline. windows.pslist has two important columns: PID (process ID) and PPID (parent process ID). The parent of WanaDecryptor has PID 2732. We can quickly search and find it.

Now we know that the process with a random name or4qtckT.exe initiated WanaDecryptor. As it might not be the only process initiated by that parent, let’s grep its PID and find out:

bash$ > vol -f infected.vmem windows.psscan | grep 2732

The parent process can show how the attacker entered the machine. It might be a user process opened by a phishing email, a scheduled task that ran at an odd hour, or a system service that got abused. Tracing parents helps you decide whether this was an interactive compromise (an attacker manually ran something) or an automated spread. If you see network-facing services as parents or child processes that match known service names (for example, svchost.exe variants), dig deeper. Some ransomware uses service abuse, scheduled tasks, or built-in Windows mechanisms to reach higher privileges or persistence.

Handles

In Windows forensics, when we say we are “viewing the handles of a process,” we mean examining the internal references that a process has opened to system resources. A handle in Windows is essentially a unique identifier (a number) that a process uses to access an operating system object. Processes do not work directly with raw resources like files, registry keys, threads, or network connections. Instead, when a process needs access to something, it asks Windows to open that object, and Windows returns a handle. That handle acts like a ticket which the process can use to interact with the object safely.

bash$ > vol -f infected.vmem windows.handles --pid 2732

First, we see a user (hacker) directory. That should be noted for further analysis, because user directories contain useful evidence in NTUSER.DAT and USRCLASS.DAT. These objects can be accessed after a full disk capture and will include thorough information about shares, directories, and objects the user accessed.

Inspecting the handles, we found an .eky file that was used to encrypt the system

This .eky file contains the secret the attacker needed to lock files on the system. These keys are brought from the outside and are not native system objects. Obtaining this key does not guarantee successful decryption. It depends on what kind of key file it is and how it was protected.

When you find cryptographic artifacts in handles, copy the file bytes, if possible, and get the hashes (SHA-256) before touching them. Export them into an isolated analysis workstation. Then compare the artifact to public resources and sandbox reports. Not every key-like file is the private key you need to decrypt. Sometimes attackers include only a portion or an encrypted container that requires an additional password or remote secret. Public repositories and collective projects (for example, NoMoreRansom and vendor decryptors) may already have decryption tools for some ransomware families, so check there before calling data irrecoverable.

Command Line

Now let’s inspect the command lines of the processes. Listing all command lines gives you more visibility to spot malicious behavior:

bash$ > vol -f infected.vmem windows.cmdline

You can also narrow it down to the needed PIDs or file names:

bash$ > vol -f infected.vmem windows.cmdline | grep or4

We can now see where the attack originated. After a successful compromise of a system or a domain, the attacker brought their malware to the system and encrypted it with their own keys.

The command line often contains the exact flags or network locations the attacker used (for example, -server 192.168.x.x or a path to an unpacker). Attackers sometimes use command-line switches to hide behavior, choose a configuration file, or provide a URL to download further payloads. If you can capture the command line, you often capture the attacker’s intent in plain text, which is invaluable evidence. Also check process environment variables, if those are available, because they might contain temporary filenames, credentials, or proxy settings the malware used.

Getting Hashes

Obviously the investigation does not stop here. You need to extract the file from memory, calculate its hash, and inspect how the malware behaves on AnyRun, VirusTotal, and other platforms. To extract the malware we first need to find its address in memory:

bash$ > vol -f infected.vmem windows.file | grep -i or4qtckT

Let’s pick the second hit and extract it now:

bash$ > vol -f infected.vmem windows.dumpfiles --physaddr 0x1fcaf798

The ImageSection dump (.img) usually looks like the program that was running in memory. It can include changes made while the program was loaded, such as unpacked code or adjusted memory addresses. The DataSection dump (.dat), on the other hand, shows what the file looks like on disk, or at least part of it. That’s why there are two dumps with the same name. Volatility detected both the in-memory version and the on-disk version of or4qtckT.exe

Next we generate the hash of the DataSectionObject and look it up on VirusTotal:

bash$ > sha256sum file.0x1fcaf798.0x85553db8.DataSectionObject.or4qtckT.exe.dat

We recommend using robust hashing (SHA-256 instead of MD5) to avoid collision issues.

For more information, go to Hybrid Analysis to get a detailed report on the malware’s capabilities.

Some platforms like VirusTotal, AnyRun, Hybrid Analysis, Joe Sandbox will produce behavioral reports, network traffic captures, and dropped files that help you map capabilities like network C2, persistence techniques, and whether the sample attempts to self-propagate. In our case, this sample has been found in online sandbox reports and is flagged with ransomware/WannaCry-like behavior. Sandbox summaries showed malicious activity consistent with file encryption and automated spread. When reading sandbox output, focus on three things: dropped files, outbound connections, and any use of legacy Windows features (SMB, WMI, PsExec) to move laterally.

Practical next steps for the investigator

First, preserve the memory image and any extracted files exactly as you found them. Do not run suspicious samples on your analysis workstation unless it is fully isolated. Second, gather network indicators (IP addresses, domain names) and add them to your blocklists and detection rules. Third, check for related persistence mechanisms on disk and in registry hives, if you have the disk image. Scheduled tasks, HKLM\Software\Microsoft\Windows\CurrentVersion\Run entries, service modifications, and driver loads are common. Fourth, feed the sample hash and any dropped files into public repositories and vendor sandboxes. These can help you find other victims and understand the campaign’s breadth. Finally, document everything, every command and every timestamp, so you can later show how the evidence was acquired, processed, and analyzed. For memory-specific checks, run Volatility plugins such as malfind (detect injection), ldrmodules (module loads), dlllist, netscan (network sockets), and registry plugins to inspect in-memory registry hives.

Summary

Think of memory as the attacker’s black box. It often holds the fleeting traces disk images miss, things like unpacked code, live network sockets, and cryptographic keys. Prioritizing memory first allows you to catch those traces before they’re gone. Volatility can help you list running processes, trace parent–child chains, inspect handles and command lines. You can also dump in-memory binaries and use them as artifacts for a more thorough analysis. Submitting these artifacts to sandboxes will give you a clear picture of what happened on your network, which will give you valuable IOCs to prevent this attack and techniques used. As a forensic analyst you are required to preserve the image intact, work with suspicious files in an isolated lab, and write down every command and timestamp to keep the chain of custody reliable and actions repeatable.

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.

For more Memory Forensics, check out our upcoming Memory Forensics class.

The post Digital Forensics: Investigating a Ransomware Attack 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.

Contributed by George Mack, Content Marketing Manager, Check Point Software.

A recent report has revealed that OneDrive is responsible for 30% of all cloud malware downloads, a far higher percentage than most other cloud applications. This is a dramatic increase of almost three times the amount from the previous year. This report highlights the need for greater security measures when using cloud storage applications.

Other cloud-based services that have been identified as vectors for malware downloads include SharePoint, which accounts for 7.2%, Gmail with 4%, Box with 3.6%, and Google Drive with 2.8%.

For the second year in a row, OneDrive has been the most widely used service for hosting malware. Hackers take advantage of these legitimate applications to upload and spread malware, as anyone can create an account on these sites. The associated brand recognition of Microsoft helps gain the victim’s trust to download the malware.

Thus, it is essential to scan any files originating from these sites. When a malicious file is downloaded from OneDrive, Drive, SharePoint, ShareFile, Box, or Dropbox, you need to have a security system in place that can detect and quarantine it to prevent it from spreading.

Ransomware is a particularly dangerous type of malware in this saga. Not only can it be delivered through OneDrive, but also to OneDrive, effectively targeting organizations’ data in the cloud and launching attacks on cloud infrastructure.

According to researchers, this approach involves using the built-in user-controlled versioning function to minimize the number of stored versions to one. This setting can be found in the versioning settings under list settings for each document library in OneDrive. However, setting the version limit to zero does not work for an attacker as existing versions can still be recovered by the user. If the limit is set to one, the file only needs to be encrypted twice before existing versions of the content are no longer accessible to the user. This gives the attacker the option of initiating double extortion if the file is exfiltrated prior to encryption.

With these threats in mind, what security solution can best prevent these attacks?

Check Point’s Harmony Email & Collaboration Suite provides a range of security measures to protect sensitive information and detect suspicious activity.

Data Leak Prevention and user behavior anomaly detection work together to identify compromised accounts and logins.

Content Disarm & Reconstruction (CDR) is an additional measure that helps protect end users from zero-day threats. This is accomplishing by removing any executable content from incoming files, rendering them safe for the recipient. All of this is done instantly and efficiently.

CDR is a process that works in real-time to break down files into their individual components, remove any elements that do not conform to the original file type’s specifications, and rebuild a “clean” version that can be sent to its intended destination. This process is beneficial because it removes zero-day malware and exploits, while avoiding the negative impacts on business productivity that come with sandbox detonation and quarantine delays.

Gartner, a leading research and advisory company, has declared that a Content Disarm and Reconstruction (CDR) system is an essential component of any email security solution. As cyber threats become more sophisticated, it is important for organizations to invest in a comprehensive email security solution that includes a CDR system.

Instances of malware sent through cloud services are rapidly increasing, posing a major risk for businesses. If you are not taking steps to protect these critical applications, then you are significantly heightening the chances of a major attack.

Check Point’s Harmony Email & Collaboration security solution is an invaluable tool for businesses of all sizes. It provides comprehensive protection against the latest email threats, such as phishing, malware, and ransomware. It also includes advanced analytics to detect and respond to suspicious activity. In addition, Harmony helps businesses comply with data privacy regulations, such as GDPR and HIPAA. With its advanced security features, Harmony Email & Collaboration can help businesses protect their data and ensure compliance with regulations.

If your organization needs to strengthen its security strategy, be sure to attend Check Point’s upcoming CPX 360 event. Register here.

Lastly, to receive cutting-edge cyber security news, best practices and resources in your inbox each week, please sign up for the CyberTalk.org newsletter. 

The post Do you use OneDrive or Google Drive? Watch out for this malware appeared first on CyberTalk.