Welcome back, aspiring digital forensic investigators!

The world of cybercrime continues to grow every year, and attackers constantly discover new opportunities and techniques to break into systems. One of the most dangerous and well-organized ransomware groups in recent years was Conti. Conti operated almost like a real company, with dedicated teams for developing malware, gaining network access, negotiating with victims, and even providing “customer support” for payments. The group targeted governments, hospitals, corporations, and many other high-value organizations. Their attacks included encrypting systems, stealing data, and demanding extremely high ransom payments.

For investigators, Conti became an important case study because their operations left behind a wide range of forensic evidence from custom malware samples to fast lateral movement and large-scale data theft. Even though the group officially shut down after their internal chats were leaked, many of their operators, tools, and techniques continued to appear in later attacks. This means Conti’s methods still influence modern ransomware operations which makes it a valid topic for forensic investigators.

Today, we are going to look at a ransomware incident involving Conti malware and analyze it with Splunk to understand how an Exchange server was compromised and what actions the attackers performed once inside.

Splunk

Splunk is a platform that collects and analyzes large amounts of machine data, such as logs from servers, applications, and security tools. It turns this raw information into searchable events, graphs, and alerts that help teams understand what is happening across their systems in real time. Companies mainly use Splunk for monitoring, security operations, and troubleshooting issues. Digital forensics teams also use Splunk because it can quickly pull together evidence from many sources and show patterns that would take much longer to find manually.

Time Filter

Splunk’s default time range is the last 24 hours. However, when investigating incidents, especially ransomware, you often need a much wider view. Changing the filter to “All time” helps reveal older activity that may be connected to the attack. Many ransomware operations begin weeks or even months before the final encryption stage. Keep in mind that searching all logs can be heavy on large environments, but in our case this wider view is necessary.

Index

An index in Splunk is like a storage folder where logs of a particular type are placed. For example, Windows Event Logs may go into one index, firewall logs into another, and antivirus logs into a third. When you specify an index in your search, you tell Splunk exactly where to look. But since we are investigating a ransomware incident, we want to search through every available index:

index=*

This ensures that nothing is missed and all logs across the environment are visible to us.

Fields

Fields are pieces of information extracted from each log entry, such as usernames, IP addresses, timestamps, file paths, and event IDs. They make your searches much more precise, allowing you to filter events with expressions like src_ip=10.0.0.5 or user=Administrator. In our case, we want to focus on executable files and that is the “Image”. If you don’t see it in the left pane, click “More fields” and add it.

Once you’ve added it, click Image in the left pane to see the top 10 results. 

These results are definitely not enough to begin our analysis. We can expand the list using top: 

index=* | top limit=100 Image

Here the cmd.exe process running in the Administrator’s user folder looks very suspicious. This is unusual, so we should check it closely. We also see commands like net1, net, whoami, and rundll32.

In one of our articles, we learned that net1 works like net and can be used to avoid detection in PowerShell if the security rules only look for net.exe. The rundll32 command is often used to run DLL files and is commonly misused by attackers. It seems the attacker is using normal system tools to explore the system. It also might be that the hackers used rundll32 to stay in the system longer.

At this point, we can already say the attacker performed reconnaissance and could have used rundll32 for persistence or further execution.

Hashes

Next, let’s investigate the suspicious cmd.exe more closely. Its location alone is a red flag, but checking its hashes will confirm whether it is malicious.

index=* Image="C:\\Users\\Administrator\\Documents\\cmd.exe" | table Image, Hashes

Copy one of the hashes and search for it on VirusTotal.

The results confirm that this file belongs to a Conti ransomware sample. VirusTotal provides helpful behavior analysis and detection labels that support our findings. When investigating, give it a closer look to understand exactly what happened to your system.

Net1

Now let’s see what the attacker did using the net1 command:

index=* Image=*net1.exe

The logs show that a new user was added to the Remote Desktop Users local group. This allows the attacker to log in through RDP on that specific machine. Since this is a local group modification, it affects only that workstation.

In MITRE ATT&CK, this action falls under Persistence. The hackers made sure they could connect to the host even if other credentials were lost. Also, they may have wanted to log in via GUI to explore the system more comfortably.

TargetFilename

This field usually appears in file-related logs, especially Windows Security Logs, Sysmon events, or EDR data. It tells you the exact file path and file name that a process interacted with. This can include files being created, modified, deleted, or accessed. That means we can find files that malware interacted with. If you can’t find the TargetFilename field in the left pane, just add it.

Run:

index=* Image="C:\\Users\\Administrator\\Documents\\cmd.exe"

Then select TargetFilename

We see that the ransomware created many “readme” files with a ransom note. This is common behavior for ransomware to spread notes everywhere. Encrypting data is the last step in attacks like this. We need to figure out how the attacker got into the system and gained high privileges.

Before we do that, let’s see how the ransomware was propagated across the domain:

index=* TargetFileName=*cmd.exe

While unsecapp.exe is a legitimate Microsoft binary. When it appears, it usually means something triggered WMI activity, because Windows launches unsecapp.exe only when a program needs to receive asynchronous WMI callbacks. In our case the ransomware was spread using WMI and infected other hosts where the port was open. This is a very common approach. 

Sysmon Events

Sysmon Event ID 8 indicates a CreateRemoteThread event, meaning one process created a thread inside another. This is a strong sign of malicious activity because attackers use it for process injection, privilege escalation, or credential theft.

List these events:

index=* EventCode=8

Expanding the log reveals another executable interacting with lsass.exe. This is extremely suspicious because lsass.exe stores credentials. Attacking LSASS is a common step for harvesting passwords or hashes.

Another instance of unsecapp.exe being used. It’s not normal to see it accessing lsass.exe. Our best guess here would be that something used WMI, and that WMI activity triggered code running inside unsecapp.exe that ended up touching LSASS. The goal behind it could be to dump LSASS every now and then until the domain admin credentials are found. If the domain admins are not in the Protected Users group, their credentials are stored in the memory of the machine they access. If that machine is compromised, the whole domain is compromised as well.

Exchange Server Compromise

Exchange servers are a popular target for attackers. Over the years, they have suffered from multiple critical vulnerabilities. They also hold high privileges in the domain, making them valuable entry points. In this case, the hackers used the ProxyShell vulnerability chain. The exploit abused the mailbox export function to write a malicious .aspx file (a web shell) to any folder that Exchange can access. Instead of a harmless mailbox export, Exchange unknowingly writes a web shell directly into the FrontEnd web directory. From there, the attacker can execute system commands, upload tools, and create accounts with high privileges.

To find the malicious .aspx file in our logs we should query this:

index=* source=*sysmon* *aspx

We can clearly see that the web shell was placed where Exchange has web-accessible permissions. This webshell was the access point.

Timeline

The attack began when the intruder exploited the ProxyShell vulnerabilities on the Exchange server. By abusing the mailbox export feature, they forced Exchange to write a malicious .aspx web shell into a web-accessible directory. This web shell became their entry point and allowed them to run commands directly on the server with high privileges. After gaining access, the attacker carried out quiet reconnaissance using built-in tools such as cmd.exe, net1, whoami and rundll32. Using net1, the attacker added a new user to the Remote Desktop Users group to maintain persistence and guarantee a backup login method. The attacker then spread the ransomware across the network using WMI. The appearance of unsecapp.exe showed that WMI activity was being used to launch the malware on other hosts. Sysmon Event ID 8 logged remote thread creation where the system binary attempts to access lsass.exe. This suggests the attacker tried to dump credentials from memory. This activity points to a mix of WMI abuse and process injection aimed at obtaining higher privileges, especially domain-level credentials. 

Finally, once the attacker had moved laterally and prepared the environment, the ransomware (cmd.exe) encrypted systems and began creating ransom note files throughout these systems. This marked the last stage of the operation.

Summary

Ransomware is more than just a virus, it’s a carefully planned attack where attackers move through a network quietly before causing damage. In digital forensics we often face these attacks and investigating them means piecing together how it entered the system, what tools it used, which accounts it compromised, and how it spread. Logs, processes, file changes tell part of the story. By following these traces, we understand the attacker’s methods, see where defenses failed, and learn how to prevent future attacks. It’s like reconstructing a crime scene. Sometimes, we might be lucky enough to shut down their entire infrastructure before they can cause more damage.

If you need forensic assistance, you can hire our team to investigate and mitigate incidents. Additionally, we provide classes on digital forensics for those looking to expand their skills and understanding in this field. 

Welcome back, aspiring digital forensics investigators!

In the previous article we introduced Autopsy and noted its wide adoption by law enforcement, federal agencies and other investigative teams. Autopsy is a forensic platform built on The Sleuth Kit and maintained by commercial and community contributors, including the Department of Homeland Security. It packages many common forensic functions into one interface and automates many of the repetitive tasks you would otherwise perform manually.

Today, let’s focus on Autopsy and how we can investigate a simple case with the help of this app. We will skip the basics as we have previously covered it. 

Analysis

Artifacts and Evidence Handling

Start from the files you are given. In this walkthrough we received an E01 file, which is the EnCase evidence file format. An E01 is a forensic image container that stores a sector-by-sector copy of a drive together with case metadata, checksums and optional compression or segmentation. It is a common format in forensic workflows and preserves the information needed to verify later that an image has not been altered.

Before any analysis begins, confirm that your working copy matches the original by comparing hash values. Tools used to create forensic images, such as FTK Imager, normally generate a short text report in the same folder that lists the image metadata and hashes you can use for verification.

Autopsy also displays the same hash values once the image is loaded. To see that select the Data Source and view the Summary in the results pane to confirm checksums and metadata.

Enter all receipts and transfers into the chain of custody log. These records are essential if your findings must be presented in court.

Opening Images In Autopsy

Create a new case and add the data source. If you have multiple EnCase segments in the same directory, point Autopsy to the first file and it will usually pick up the remaining segments automatically. Let the ingest modules run as required for your investigative goals, and keep notes about which modules and keyword searches you used so your process is reproducible.

Identifying The Host

First let’s see the computer name we are looking at. Names and labelling conventions can differ from the actual system name recorded in the image. You can quickly find the host name listed under Operating System Information, next to the SYSTEM entry. 

Knowing the host name early helps orient the rest of your analysis and simplifies cross-referencing with network or domain logs.

Last Logins and User Activity

To understand who accessed the machine and when, we can review last login and account activity artifacts. Windows records many actions in different locations. These logs are extremely useful but also mean attackers sometimes attempt to use those logs to their own advantage. For instance, after a domain compromise an attacker can review all security logs and find machines that domain admins frequently visit. It doesn’t take much time to find out what your critical infrastructure is and where it is located with the help of such logs. 

In Autopsy, review Operating System, then User Accounts and sort by last accessed or last logon time to see recent activity. Below we see that Sivapriya was the last one to login.

A last logon alone does not prove culpability. Attackers may act during normal working hours to blend in, and one user’s credentials can be used by another actor. You need to use time correlation and additional artifacts before drawing conclusions.

Installed Applications

Review installed applications and files on the system. Attackers often leave tools such as Python, credential dumpers or reconnaissance utilities on disk. Some are portable and will be found in Temp, Public or user directories rather than in Program Files. Execution evidence can be recovered from Prefetch, NTUSER.DAT, UserAssist, scheduled tasks, event logs and other sources we will cover separately.

In this case we found a network reconnaissance tool, Look@LAN, which is commonly used for mapping local networks.

Signed and legitimate tools are sometimes abused because they follow expected patterns and can evade simple detection.

Network Information and IP Addresses

Finding the IP address assigned to the host is useful for reconstructing lateral movement and correlating events across machines and the domain controller. The domain controller logs validate domain logons and are essential for tracing where an attacker moved next. In the image you can find network assignments in registry hives: the SYSTEM hive contains TCP/IP interface parameters under CurrentControlSet\Services\Tcpip\Parameters\Interfaces and Parameters, and the SOFTWARE hive stores network profile signatures under Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed and \Unmanaged or NetworkList

If the host used DHCP, registry entries may show previously assigned IPs, but sometimes the attacker’s tools carry their own configuration files. In our investigation we inspected an application configuration file (irunin.ini) found in Program Files (x86) and recovered the IP and MAC address active when that tool was executed. 

The network adapter name and related entries are also recorded under SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards.

User Folders and Files

Examine the Users folder thoroughly. Attackers may intentionally store tools and scripts in other directories to create false flags, so check all profiles, temporary locations and shared folders. When you extract an artifact for analysis, hash it before and after processing to demonstrate integrity. In this case we located a PowerShell script that attempts privilege escalation.

The script checks if it is running as an administrator. If elevated it writes the output of whoami /all to %ALLUSERSPROFILE%\diag\exec_<id>.dat. If not elevated, it temporarily sets a value under HKCU\Environment\ProcExec with a PowerShell launch string, then triggers the built-in scheduled task \Microsoft\Windows\DiskCleanup\SilentCleanup via schtasks /run in the hope that the privileged task will pick up and execute the planted command, and finally removes the registry value. Errors are logged to a temporary diag file.

The goal was to validate a privilege escalation path by causing a higher-privilege process to run a payload and record the resulting elevated identity.

Credential Harvesting

We also found evidence of credential dumping tools in user directories. Mimikatz was present in Hasan’s folder, and Lazagne was also detected in Defender logs. These tools are commonly used to extract credentials that support lateral movement. The presence of python-3.9.1-amd64.exe in the same folder suggests the workstation could have been used to stage additional tools or scripts for propagation.

Remember that with sufficient privileges an attacker can place malicious files into other users’ directories, so initial attribution based only on file location is tentative.

Windows Defender and Detection History

If endpoint protection was active, its detection history can hold valuable context about what was observed and when. Windows Defender records detection entries can be found under C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory*. 
Below we found another commonly used tool called LaZagne, which is available for both Linux and Windows and is used to extract credentials. Previously, we have covered the use of this tool a couple of times and you can refer to Powershell for Hackers – Basics to see how it works on Windows machines.

Correlate those entries with file timestamps, prefetch data and event logs to build a timeline of execution.

Zerologon

It was also mentioned that the attackers attempted the Zerologon exploit. Zerologon (CVE-2020-1472) is a critical vulnerability in the Netlogon protocol that can allow an unauthenticated attacker with network access to a domain controller to manipulate the Netlogon authentication process, potentially resetting a computer account password and enabling impersonation of the domain controller. Successful exploitation can lead to domain takeover. 

Using keyword searches across the drive we can find related files, logs and strings that mention zerologon to verify any claims. 

In the image above you can see NTUSER.DAT contains “Zerologon”. NTUSER.DAT is the per-user registry hive stored in each profile and is invaluable for forensics. It contains persistent traces such as Run and RunOnce entries, recently opened files and MRU lists, UserAssist, TypedURLs data, shells and a lot more. The presence of entries in a user’s NTUSER.DAT means that the user’s account environment recorded those actions. The entry appears in Sandhya’s NTUSER.DAT in this case, it suggests that the account participated in this activity or that artifacts were created while that profile was loaded.

Timeline

Pulling together the available artifacts suggests the following sequence. The first login on the workstation appears to have been by Sandhya, during which a Zerologon exploit was attempted but failed. After that, Hasan logged in and used tools to dump credentials, possibly to start moving laterally. Evidence of Mimikatz and a Python installer were found in Hasan’s directory. Finally, Sivapriya made the last recorded login on this workstation and a PowerShell script intended to escalate privileges was found in their directory. This script could have been used during lateral activity to escalate privileges on other hosts or if local admin rights were not assigned to Hasan, another attacker could have tried to escalate their privileges using Sivapriya’s account. At this stage it is not clear whether multiple accounts represent separate actors working together or a single hacker using different credentials. Resolving that requires cross-host correlation, domain controller logs and network telemetry.

Next Steps and Verification

This was a basic Autopsy workflow. For stronger attribution and a complete reconstruction we need to collect domain controller logs, firewall and proxy logs and any endpoint telemetry available. Specialised tools can be used for deeper analysis where appropriate.

Conclusion

As you can see, Autopsy is an extensible platform that can organize many routine forensic tasks, but it is only one part of a comprehensive investigation. Successful disk analysis depends on careful evidence handling and multiple data sources. It’s also important to confirm hashes and chain of custody before and after the analysis. When you combine solid on-disk analysis with domain and network logs, you can move from isolated observations to a defensible timeline and conclusions. 

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.