Ransomware Detection Lab with Sysmon

Detect simulated ransomware attacks using Sysmon and Atomic Red Team.

Introduction

30 Second Summary

Ransomware is one of the most destructive threats in cybersecurity today. Organizations lose access to their files, pay millions in ransom, and spend weeks recovering. The difference between a catastrophic breach and a contained incident often comes down to one thing: how fast you detect the attack.

In this project, you will build a fully operational ransomware detection lab on your Windows 11 machine. You will install endpoint monitoring, simulate a safe ransomware attack, detect it in real time, and create a tested incident response checklist.

What You'll Build

By the end, you will run a simulated ransomware attack on your own machine, watch your detection system catch every malicious file drop as it happens, and have a response playbook ready to hand to any team.

By the end of this project, you'll have:

  • A custom Sysmon detection configuration that catches ransomware-like file encryption patterns and system recovery sabotage the moment they happen on your machine.
  • A documented attack timeline showing exactly how you traced a simulated ransomware strike from the first file drop to the full picture, mapped to real-world MITRE ATT&CK techniques.
  • A tested incident response checklist structured around the NIST Cybersecurity Framework that you can apply to real ransomware events or hand to a security team.
  • Secret Mission: Build a real-time PowerShell monitoring script that alerts you the instant ransomware indicators appear in your logs.

Are there any prerequisites?

You need a Windows 11 machine with administrator rights. You will also need PowerShell (included with Windows 11) and an internet connection to download the tools in Step 1.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. Ransomware is one of the most common and damaging threats organizations face today. Understanding how to detect and respond to it starts with building the detection system yourself.

Install Sysmon and Atomic Red Team

Before you can detect ransomware, you need the right sensors in place. Think of it like installing a security camera before you test whether it catches intruders.

In this step, you will install two tools. Sysmon gives your machine detailed endpoint telemetry (who created what file, which process ran which command). Atomic Red Team gives you safe, repeatable attack simulations mapped to the MITRE ATT&CK framework.

In this step, get ready to:
  • Install Sysmon from Microsoft Sysinternals and confirm it is logging events.
  • Install the Invoke-AtomicRedTeam PowerShell module with its atomics library.
  • Verify both tools are operational and ready for ransomware detection work.
Download and install Sysmon

Sysmon (System Monitor) is a Windows service from Microsoft Sysinternals that logs detailed system activity to the Windows Event Log. It captures process creations, file creations, and network connections that standard Windows logging misses.

  • Press the Windows key to open your search bar.
  • Type PowerShell and select Run as administrator.
  • Click Yes on the User Account Control prompt that appears.

Why Administrator?

Sysmon installs a kernel-level driver that monitors system activity. This requires elevated privileges to install and run. Keep this Administrator PowerShell window open for the rest of the project.

  • Create a working folder for this project and download Sysmon by running these commands:
# Create a folder to hold our lab files
New-Item -ItemType Directory -Path C:\SysmonLab -Force

# Download Sysmon from Microsoft Sysinternals
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "C:\SysmonLab\Sysmon.zip"

What does this code do?

  • New-Item -ItemType Directory -Path C:\SysmonLab -Force creates a folder at C:\SysmonLab to store our project files.
  • Invoke-WebRequest downloads the official Sysmon zip archive from Microsoft Sysinternals directly to that folder.
  • Extract the zip file and install Sysmon by running these commands:
# Extract the Sysmon zip archive
Expand-Archive -Path "C:\SysmonLab\Sysmon.zip" -DestinationPath "C:\SysmonLab\Sysmon" -Force

# Install Sysmon with default settings
C:\SysmonLab\Sysmon\Sysmon64.exe -accepteula -i

What does this code do?

  • Expand-Archive unzips the downloaded file into C:\SysmonLab\Sysmon.
  • Sysmon64.exe -accepteula -i accepts the license agreement and installs Sysmon as a Windows service with default monitoring rules. The -accepteula flag skips the interactive license prompt. The -i flag tells Sysmon to install the service and driver.

You should see output confirming that Sysmon was installed successfully, including a line mentioning the Sysmon service is started.

  • Confirm the Sysmon service is running by running:
Get-Service Sysmon64

You should see the service listed with a status of Running.

Service not showing as Running?

  • Make sure you ran PowerShell as Administrator. Sysmon cannot install without elevated privileges.
  • If you see an error about the file not being found, verify the download completed by running dir C:\SysmonLab\Sysmon and looking for Sysmon64.exe.

Help me troubleshoot Sysmon installation issues on Windows 11.

Install the Invoke-AtomicRedTeam PowerShell module

Atomic Red Team is a library of small, focused test scripts that simulate real attacker techniques. Each test maps to a specific MITRE ATT&CK technique ID, so you always know exactly what behavior you are simulating.

  • Install the Invoke-AtomicRedTeam module and its dependency by running:
# Install the Atomic Red Team PowerShell modules
Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser

What does this command do?

This installs two PowerShell modules: invoke-atomicredteam (the test runner) and powershell-yaml (required for reading test definition files). The -Scope CurrentUser flag installs them for your user account only, without requiring system-wide permissions.

PowerShell will ask you to confirm installation from an untrusted repository (PSGallery). Type Y and press Enter to continue.

  • Download the atomics folder containing all the test definitions by running:
# Download and install the atomic test definitions
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing); Install-AtomicRedTeam -getAtomics

What does this command do?

  • IWR (Invoke-WebRequest) downloads the Atomic Red Team install script from GitHub.
  • IEX (Invoke-Expression) runs that script immediately.
  • Install-AtomicRedTeam -getAtomics downloads the full library of test definitions to C:\AtomicRedTeam. This folder contains hundreds of safe attack simulations organized by ATT&CK technique ID.

This download may take a minute or two depending on your internet connection. You will see progress output as the atomics folder is populated.

  • Add a Windows Defender exclusion to prevent it from quarantining the test files by running:
# Prevent Defender from quarantining Atomic Red Team test files
Add-MpPreference -ExclusionPath "C:\AtomicRedTeam"

Why add a Defender exclusion?

Atomic Red Team's test files contain payloads designed to mimic real attack behavior. Windows Defender will flag and quarantine them because they look like malware. Adding the exclusion tells Defender to leave C:\AtomicRedTeam alone so the tests can run.

You will remove this exclusion in the Before You Go section when you are done with the project.

  • Verify the exclusion was applied by running:
(Get-MpPreference).ExclusionPath

You should see C:\AtomicRedTeam listed in the output.

Defender exclusion not appearing?

  • Make sure you are running PowerShell as Administrator. The Add-MpPreference command requires elevated privileges.
  • If you see a PermissionDenied error, close PowerShell and reopen it with Run as administrator.

Help me add a Windows Defender exclusion path using PowerShell.

Verify both installations

Now let's confirm that both Sysmon and Atomic Red Team are fully operational before moving on.

  • Open Event Viewer by running:
eventvwr.msc
  • In the left panel of Event Viewer, expand Applications and Services Logs.
  • Expand Microsoft, then Windows, then scroll down and click Sysmon.
  • Click Operational.

You should see events already appearing in the log. These are Sysmon recording process and file activity on your machine since installation.

What is the Sysmon Operational log?

This is where Sysmon writes all its telemetry. The full path is Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. Every process creation, file creation, and network connection that Sysmon captures lands here. In the next step, you will write custom rules to filter this log for ransomware indicators.

  • Before you run this next command, what do you think it will show? Try to predict based on the technique ID T1486 (Data Encrypted for Impact).
  • Confirm Atomic Red Team is ready by running this command back in your Administrator PowerShell window:
Invoke-AtomicTest T1486 -ShowDetails

You should see a list of available tests for technique T1486 (Data Encrypted for Impact), including test names, descriptions, supported platforms, and attack commands. This confirms the module is loaded and can read the atomics library.

Command not recognized?

  • If you see a "not recognized" error, the module may not have imported. Run Import-Module invoke-atomicredteam and try again.
  • If you see an error about the atomics path, verify the folder exists by running dir C:\AtomicRedTeam\atomics\T1486.

Help me get Invoke-AtomicTest working in PowerShell.

Your detection tools are installed and operational. Next up, you will write a custom Sysmon configuration that filters for ransomware-specific behaviors.

Configure Sysmon for Ransomware Detection

Sysmon is installed and logging, but right now it's running with default settings. That means it captures generic system activity without focusing on anything specific.

To catch ransomware, you need detection rules that zero in on the exact behaviors ransomware uses. In this step, you'll write a focused configuration file that tells Sysmon what to watch for: suspicious file extensions and commands that destroy system backups.

In this step, get ready to:
  • Create a custom Sysmon configuration file with ransomware-specific detection rules.
  • Apply the configuration and confirm Sysmon loaded it successfully.
Create the ransomware detection configuration

Your configuration file needs to monitor two key ransomware behaviors. First, it watches for files being created with known ransomware extensions like .akira and .locked. Second, it watches for commands that delete shadow copies or disable system recovery.

  • Create a folder to hold your detection lab files by running this command:
mkdir C:\SysmonLab
  • Confirm the folder was created by running:
dir C:\SysmonLab

You should see an empty directory listing confirming C:\SysmonLab exists.

  • Create the ransomware detection configuration file by running this command:
@"
<Sysmon schemaversion="4.82">
  <HashAlgorithms>SHA256</HashAlgorithms>
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <CommandLine condition="contains">vssadmin delete shadows</CommandLine>
      <CommandLine condition="contains">wmic shadowcopy delete</CommandLine>
      <CommandLine condition="contains">recoveryenabled no</CommandLine>
    </ProcessCreate>
    <FileCreate onmatch="include">
      <TargetFilename condition="end with">.akira</TargetFilename>
      <TargetFilename condition="end with">.locked</TargetFilename>
      <TargetFilename condition="end with">.encrypted</TargetFilename>
      <TargetFilename condition="contains">akira_readme</TargetFilename>
      <TargetFilename condition="contains">YOUR_FILES</TargetFilename>
      <TargetFilename condition="contains">DECRYPT</TargetFilename>
      <TargetFilename condition="contains">RANSOM</TargetFilename>
    </FileCreate>
  </EventFiltering>
</Sysmon>
"@ | Set-Content -Path C:\SysmonLab\ransomware-config.xml

What does this configuration do?

This config uses EventFiltering rules with onmatch="include" to log ONLY events that match your patterns. Everything else is ignored.

  • The ProcessCreate section (Event ID 1) watches for commands that ransomware uses to destroy backups. Commands like vssadmin delete shadows wipe Volume Shadow Copies, removing your ability to restore files.
  • The FileCreate section (Event ID 11) watches for files with known ransomware extensions. The .akira extension matches the Akira ransomware family. Ransom note filenames like YOUR_FILES and DECRYPT are common across many ransomware variants.
  • The condition attribute controls matching. The value end with matches file extensions at the end of a path. The value contains matches substrings anywhere in the filename or command line.
  • Confirm the file was written correctly by running:
Get-Content C:\SysmonLab\ransomware-config.xml

You should see the full XML configuration printed in your terminal, starting with <Sysmon schemaversion="4.82">.

Seeing an empty file or error?

  • Make sure the "@ closing delimiter is on its own line with no leading spaces. PowerShell here-strings require this exact formatting.
  • If you see a red error about an unrecognized token, re-paste the entire command from @" through the Set-Content line as one block.
  • help me fix a PowerShell here-string error when creating my Sysmon config file

✔️ Awesome, I've got everything!

Great. Make sure the XML output matches what you pasted, then move on to apply it.

ⓧ I'd like to double check the full code

Your ransomware-config.xml file should contain exactly this:

<Sysmon schemaversion="4.82">
  <HashAlgorithms>SHA256</HashAlgorithms>
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <CommandLine condition="contains">vssadmin delete shadows</CommandLine>
      <CommandLine condition="contains">wmic shadowcopy delete</CommandLine>
      <CommandLine condition="contains">recoveryenabled no</CommandLine>
    </ProcessCreate>
    <FileCreate onmatch="include">
      <TargetFilename condition="end with">.akira</TargetFilename>
      <TargetFilename condition="end with">.locked</TargetFilename>
      <TargetFilename condition="end with">.encrypted</TargetFilename>
      <TargetFilename condition="contains">akira_readme</TargetFilename>
      <TargetFilename condition="contains">YOUR_FILES</TargetFilename>
      <TargetFilename condition="contains">DECRYPT</TargetFilename>
      <TargetFilename condition="contains">RANSOM</TargetFilename>
    </FileCreate>
  </EventFiltering>
</Sysmon>
Apply the configuration to Sysmon

With the config file written, you need to tell Sysmon to use it. The -c flag reloads Sysmon's configuration from a file without reinstalling the service.

  • Apply your ransomware detection configuration by running:
sysmon -c C:\SysmonLab\ransomware-config.xml

You should see a message confirming the configuration was updated successfully.

What does the -c flag do?

The -c parameter updates the configuration of an already-running Sysmon service. It hot-swaps the filtering rules without restarting or reinstalling anything. Sysmon logs a configuration change event (Event ID 16) every time this happens.

Before you check Event Viewer, what event do you expect to find that proves the configuration loaded?

  • Switch to Event Viewer.
  • Navigate to Applications and Services Logs > Microsoft > Windows > Sysmon > Operational.
  • Right-click the Operational log and select Filter Current Log.
  • In the Event IDs field, type 16 and click OK.

You should see an Event ID 16 entry with a recent timestamp. This is the Sysmon configuration change event, confirming your new ransomware detection rules are now active.

Don't see Event ID 16?

  • Make sure you ran the sysmon -c command from an Administrator PowerShell prompt. A non-elevated prompt cannot update the Sysmon configuration.
  • Click Refresh in Event Viewer's right-hand pane. New events do not appear automatically.
  • Verify the file path is correct by running Test-Path C:\SysmonLab\ransomware-config.xml in PowerShell. It should return True.
  • help me troubleshoot why my Sysmon configuration change event is not appearing

Your detection system is now armed. Sysmon is watching for exactly the patterns that real ransomware like Akira leaves behind. Next up, you'll put these rules to the test by safely simulating a ransomware attack.

Simulate a Ransomware Attack

Your detection rules are now active and watching for ransomware-like behavior. The real test of any security configuration is whether it actually catches something.

In this step, you will simulate a safe ransomware attack using Atomic Red Team. These simulations create harmless files that mimic what real ransomware does after encrypting a victim's data. Your Sysmon configuration should detect every artifact the moment it hits the disk.

In this step, get ready to:
  • Run a PureLocker ransom note simulation that drops a ransom note on your Desktop.
  • Run an Akira ransomware simulation that drops 100 encrypted-looking files and a ransom note.
  • Record timestamps for correlating simulation events with Sysmon logs.
Run the PureLocker ransom note simulation

The first simulation mimics what the PureLocker ransomware family does after encrypting files. It drops a ransom note called YOUR_FILES.txt on the victim's Desktop, telling them their data has been locked.

This maps to MITRE ATT&CK technique T1486 (Data Encrypted for Impact).

  • In your Administrator PowerShell prompt, record the current time so you can correlate events later:
Get-Date
  • Note the timestamp that appears. You will use this to filter Sysmon logs in the next step.
  • Run the PureLocker ransom note simulation (T1486 Test 5) by running this command:
Invoke-AtomicTest T1486 -TestNumbers 5

What does this command do?

Invoke-AtomicTest executes a specific test from the Atomic Red Team library.

  • T1486 is the MITRE ATT&CK technique ID for Data Encrypted for Impact.
  • -TestNumbers 5 selects only the PureLocker test, which creates a single ransom note file on the Desktop.
  • Check your Desktop. You should see a new file called YOUR_FILES.txt has appeared.

Don't see YOUR_FILES.txt on your Desktop?

  • Make sure you are running PowerShell as Administrator. This test requires elevated privileges.
  • Confirm the Defender exclusion is still active for C:\AtomicRedTeam. Without it, Defender may quarantine the test payload before it runs.
  • Run Invoke-AtomicTest T1486 -TestNumbers 5 -ShowDetails to check the test definition is accessible.

Help me troubleshoot why T1486 Test 5 did not create YOUR_FILES.txt on my Desktop.

Run the Akira ransomware file drop simulation

The second simulation is more aggressive. It mimics the Akira ransomware family, which encrypts files and renames them with a .akira extension.

This test drops 100 files with the .akira extension into C:\ and creates an akira_readme.txt ransom note on your Desktop.

  • First, download any prerequisites the test needs by running:
Invoke-AtomicTest T1486 -TestNumbers 10 -GetPrereqs

What are prerequisites in Atomic Red Team?

Some tests depend on additional files or tools to run properly. The -GetPrereqs flag checks whether those dependencies exist and downloads them if they are missing.

  • Record the current time again before running the Akira test:
Get-Date
  • Note this second timestamp. Now execute the Akira ransomware simulation by running:
Invoke-AtomicTest T1486 -TestNumbers 10

Before you check the results, what do you expect to find on your system given that this test simulates file encryption?

  • Verify the Akira artifacts were created by running:
Get-ChildItem C:\ -Filter *.akira | Select-Object -First 5

You should see files named like test.1.akira, test.2.akira, and so on listed in the output.

  • Also check your Desktop for the Akira ransom note:
Test-Path $env:USERPROFILE\Desktop\akira_readme.txt

This should return True, confirming the ransom note was dropped.

Seeing a parser error when running Test 10?

If you see an error mentioning a missing string terminator, your atomics folder may contain an older version of the T1486 test definition with a known script quoting issue.

  • Update your atomics folder by re-running the install script with the -getAtomics flag to pull the latest fixed definitions.
  • Then retry Invoke-AtomicTest T1486 -TestNumbers 10.

Help me fix a parser error when running Invoke-AtomicTest T1486 -TestNumbers 10 on Windows 11.

Confirm your simulation artifacts and note the timestamps

Both simulations have run. You now have ransomware artifacts sitting on your system exactly as they would during a real incident. The key difference is that these are safe test files created by Atomic Red Team, not actual malware.

  • Leave all the simulation artifacts in place. You will analyze them in Event Viewer during the next step and clean them up afterward.
  • Write down both timestamps you recorded (from before Test 5 and before Test 10). You will use these to filter Sysmon events in Step 4.

Why keep the artifacts?

In a real incident, you would preserve evidence before cleaning up. Deleting artifacts before analysis destroys the forensic trail. Keeping them in place lets you practice the detection and analysis workflow in the next step, just as you would during a real investigation.

Let's confirm the full picture. Before you run this final check, predict how many .akira files you expect to see based on what the Akira test description told you.

  • Confirm all expected artifacts exist by running:
# Check PureLocker ransom note
Test-Path $env:USERPROFILE\Desktop\YOUR_FILES.txt

# Count Akira encrypted files
(Get-ChildItem C:\ -Filter *.akira).Count

# Check Akira ransom note
Test-Path $env:USERPROFILE\Desktop\akira_readme.txt

You should see True, then 100, then True. That confirms all three artifact types landed successfully.

Save your timestamps somewhere accessible

Copy both timestamps into a Notepad window or sticky note. In the next step you will paste them into Event Viewer's time filter to narrow down exactly which Sysmon events correspond to your simulations.

Your machine now looks like it has been hit by ransomware. Next up, you will hunt for these events in Sysmon's logs and build a forensic timeline of the attack.

Detect and Analyze the Attack in Event Viewer

You now have live ransomware simulation artifacts on your machine and a Sysmon log full of events triggered by those artifacts. The real question is: can your detection configuration actually catch what just happened?

In this step, you will hunt through Sysmon's telemetry in Windows Event Viewer, identify the exact events your ransomware config captured, and build an attack timeline mapped to MITRE ATT&CK technique T1486. This is the core skill of detection engineering: turning raw log data into a clear story of what happened, when, and how.

In this step, get ready to:
  • Filter Sysmon logs to isolate the ransomware file creation events.
  • Build an attack timeline mapping events to MITRE ATT&CK T1486.
  • Clean up simulation artifacts to restore your system.
Filter the Sysmon log for ransomware events

Your Sysmon configuration logged every file creation that matched your ransomware patterns. Now you need to find those events among all the other system activity.

  • Press the Windows key to open your search bar.
  • Type Event Viewer and press Enter to open it.
  • In the left pane, expand Applications and Services Logs.
  • Expand Microsoft, then Windows, then scroll down to Sysmon.
  • Click Operational under Sysmon to view the Sysmon event log.

You should see a list of events. Many of these are from your simulations, but there may also be other system events mixed in.

  • In the Actions pane on the right, click Filter Current Log.
  • In the Event IDs field, type 11 to show only FileCreate events.
  • Click OK to apply the filter.

The log now shows only Event ID 11 (FileCreate) entries. You should see events with filenames containing .akira, akira_readme, and YOUR_FILES from the time window when you ran your simulations.

What should I see in each event?

Click on any of the filtered events to view its details in the lower pane. Each Event ID 11 entry contains key forensic fields:

  • TargetFilename shows the full path of the file that was created (the ransomware indicator).
  • Image shows which process created the file (this tells you what executable performed the action).
  • ProcessId identifies the specific process instance.
  • User shows which account the process ran under.
  • Click on one of the events with .akira or YOUR_FILES in the filename.
  • In the General tab below, note the Image field. It should show powershell.exe because Invoke-AtomicTest ran via PowerShell.
  • Note the User field. It shows your admin account name.
  • Note the UtcTime field. This is the precise timestamp of the file creation.

Don't see any Event ID 11 events?

  • Make sure you navigated to the correct log path: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. The Sysmon log is NOT under Windows Logs.
  • Confirm your filter shows 11 in the Event IDs field. If the field is blank, the filter shows all events.
  • If the log is empty, Sysmon may not be running with your custom config. Switch back to your admin PowerShell and run sysmon -c C:\SysmonLab\ransomware-config.xml to reapply it, then re-run the Atomic Red Team tests.

Help me troubleshoot why my Sysmon config is not capturing FileCreate events

Build an attack timeline from the events

Individual log entries are data points. An attack timeline turns them into a story that answers the questions any incident responder would ask: What happened? When? How?

  • Scroll through your filtered Event ID 11 events and identify the earliest and latest timestamps from your simulation.
  • Note the first event's timestamp as the attack start time.
  • Note the last event's timestamp as the attack end time.

Now map what you see to the MITRE ATT&CK framework. Every event in your filtered list maps to a single technique: T1486 (Data Encrypted for Impact).

  • Open Notepad or any text editor to document your timeline.
  • Record the following for your attack timeline:
  • MITRE ATT&CK technique: T1486 (Data Encrypted for Impact).
  • Process: powershell.exe (running Invoke-AtomicTest).
  • User context: your admin account name from the User field.
  • Attack start: timestamp of the earliest Event ID 11 from your simulations.
  • Attack end: timestamp of the latest Event ID 11 from your simulations.
  • Files affected: YOUR_FILES.txt (Test 5 PureLocker), plus .akira extension files and akira_readme ransom note (Test 10 Akira).
  • Detection method: Sysmon Event ID 11 FileCreate with ransomware-config.xml rules matching file extensions and filenames.

Why map to MITRE ATT&CK?

MITRE ATT&CK is the industry-standard language for describing adversary behavior. When you label events with technique IDs like T1486, anyone on a security team instantly understands what type of attack you observed.

In a real incident, you would also look for T1490 (Inhibit System Recovery) where attackers delete shadow copies before encrypting. Your Sysmon config is already watching for those commands, even though the simulation only triggered T1486.

Clean up the simulation artifacts

Your analysis is complete. The simulation files still exist on disk, so you need to remove them using Atomic Red Team's built-in cleanup commands.

  • Switch back to your Administrator PowerShell window.
  • Clean up the PureLocker ransom note (Test 5) by running this command:
Invoke-AtomicTest T1486 -TestNumbers 5 -Cleanup
  • Clean up the Akira ransomware files (Test 10) by running this command:
Invoke-AtomicTest T1486 -TestNumbers 10 -Cleanup

What do these cleanup commands do?

Each Atomic Red Team test includes a cleanup block that reverses whatever the test created. Test 5's cleanup removes YOUR_FILES.txt from your Desktop. Test 10's cleanup removes the .akira extension files and akira_readme ransom note.

Before you verify, what do you expect to see (or not see) on your Desktop and file system now?

  • Verify the cleanup by checking your Desktop for YOUR_FILES.txt. It should be gone.
  • Run this command to confirm no .akira files remain:
Get-ChildItem -Path C:\ -Filter *.akira -Recurse -ErrorAction SilentlyContinue

If the cleanup succeeded, this command returns no output. The simulation artifacts are gone and your system is back to its pre-test state.

Still seeing .akira files or YOUR_FILES.txt?

If the cleanup command reported errors or files remain, you can remove them manually:

  • Delete the Desktop ransom note: Remove-Item "$env:USERPROFILE\Desktop\YOUR_FILES.txt" -Force.
  • For leftover .akira files, check the paths shown in your Event Viewer events and delete them with Remove-Item.

Help me manually remove leftover Atomic Red Team simulation files

You have just completed an end-to-end detection cycle: a simulated attack triggered your Sysmon rules, you identified the events in Event Viewer, correlated them into a timeline, and mapped them to MITRE ATT&CK. Next up, you will turn this experience into a structured incident response checklist using the NIST Cybersecurity Framework.

Build Your Incident Response Checklist

You now have hands-on evidence of what a ransomware attack looks like in Sysmon logs. You built an attack timeline, identified the responsible process, and mapped events to MITRE ATT&CK techniques.

In a real incident, you won't have the luxury of calmly opening Event Viewer after the fact. You need a structured playbook ready before an attack happens, so every responder knows exactly what to look for, how to contain the damage, and how to restore operations. In this step, you'll build that playbook using the NIST Cybersecurity Framework structure.

In this step, get ready to:
  • Create an incident response checklist structured around the NIST CSF Detect, Respond, and Recover phases.
  • Add a MITRE ATT&CK mapping section covering T1486, T1490, T1562.001, and T1083 with their corresponding Sysmon Event IDs.
Create the NIST CSF incident response checklist

The NIST Cybersecurity Framework organizes cybersecurity activities into five functions: Identify, Protect, Detect, Respond, and Recover. For incident response, you focus on the last three. Each section answers a different question during an active attack.

What do Detect, Respond, and Recover mean?

Detect defines how you identify that a cybersecurity event is occurring. It enables timely discovery of attacks through log analysis and anomaly detection.

Respond covers the actions you take to contain the impact of a detected incident. This includes killing processes, isolating machines, and preserving evidence.

Recover focuses on restoring capabilities and services that were impaired. This means backups, integrity checks, and getting back to normal operations.

You'll store your checklist in the same C:\SysmonLab folder alongside your Sysmon configuration.

  • Create the checklist file with the Detect section by running this command in your Administrator PowerShell prompt:
# Create the incident response checklist with the Detect section
Set-Content -Path "C:\SysmonLab\incident-response-checklist.txt" -Value @"
=== INCIDENT RESPONSE CHECKLIST ===
Based on NIST Cybersecurity Framework (Detect, Respond, Recover)

--- DETECT ---

Sysmon Indicators to Monitor:

[Event ID 11 - FileCreate]
- File extensions: .akira, .locked, .encrypted
- Indicator filenames: akira_readme, YOUR_FILES, DECRYPT, RANSOM
- Log path: Applications and Services Logs > Microsoft > Windows > Sysmon > Operational
- Key fields: TargetFilename, Image, ProcessId, User, UtcTime

[Event ID 1 - ProcessCreate]
- Commands: vssadmin delete shadows, wmic shadowcopy delete, recoveryenabled no
- Key fields: CommandLine, Image, User, ParentImage, UtcTime

Detection Speed (from simulation):
- Time from attack start to first Sysmon event: immediate (real-time logging)
- Time to identify in Event Viewer: depends on filter setup and active monitoring
"@

What does this command do?

The Set-Content cmdlet creates a new file at the specified path and writes the here-string (everything between @" and "@) as its content.

The Detect section documents exactly what you observed in Event Viewer during the simulation. Event ID 11 catches ransomware file creation. Event ID 1 catches shadow copy deletion commands that disable recovery.

  • Confirm the file was created by running:
Get-Content "C:\SysmonLab\incident-response-checklist.txt"

You should see the full Detect section printed in your terminal, starting with the header and listing both Event ID 11 and Event ID 1 indicators.

  • Now add the Respond section by running:
# Add the Respond section to the checklist
Add-Content -Path "C:\SysmonLab\incident-response-checklist.txt" -Value @"

--- RESPOND ---

Immediate Containment Actions:

1. ISOLATE the machine from the network
   - Disconnect Ethernet cable or disable Wi-Fi adapter
   - Do NOT power off (preserves memory evidence)

2. IDENTIFY and KILL the malicious process
   - Check Sysmon Event ID 1 for the process name and PID
   - Use Task Manager or: taskkill /PID <pid> /F
   - Note the parent process chain

3. PRESERVE evidence
   - Export Sysmon log (right-click log > Save All Events As)
   - Screenshot active network connections (netstat -ano)
   - Document timeline: first indicator, scope, affected files
"@

Why isolate before shutting down?

Powering off a machine destroys volatile memory evidence (running processes, network connections, encryption keys in RAM). Disconnecting the network stops the ransomware from spreading to other machines or exfiltrating data while preserving that evidence for forensic analysis.

  • Verify the Respond section was appended by running:
Get-Content "C:\SysmonLab\incident-response-checklist.txt" | Select-Object -Last 15

You should see the three containment actions (ISOLATE, IDENTIFY and KILL, PRESERVE) with their sub-steps.

  • Add the Recover section by running:
# Add the Recover section to the checklist
Add-Content -Path "C:\SysmonLab\incident-response-checklist.txt" -Value @"

--- RECOVER ---

Restoration Steps:

1. RESTORE from offline backups
   - Use backups stored offline or in immutable storage
   - Verify backup integrity before restoration
   - Restore to a clean, verified system image

2. VERIFY system integrity
   - Run full antimalware scan on restored system
   - Check that Sysmon and security tools are operational
   - Verify no persistence mechanisms remain (scheduled tasks, registry)

3. RE-ENABLE disabled recovery mechanisms
   - Confirm Volume Shadow Copy Service is running
   - Verify bcdedit recovery settings are enabled
   - Test that System Restore points can be created
"@

Why offline backups specifically?

Modern ransomware actively targets connected backup drives and network shares. Only backups stored offline (disconnected from the network) or in immutable storage (write-once, cannot be overwritten) survive a ransomware attack. This is why T1490 (Inhibit System Recovery) exists as a technique. Attackers delete shadow copies to eliminate the easy recovery path.

  • Verify the complete checklist so far by checking the file length:
(Get-Content "C:\SysmonLab\incident-response-checklist.txt").Count

You should see a line count around 50-55, confirming all three NIST CSF sections are in the file.

File appears empty or too short?

Make sure you ran each command in order. Set-Content creates the file, and Add-Content appends to it. If you ran Set-Content more than once, it overwrites the file each time.

If the file is missing entirely, confirm you are running PowerShell as Administrator and that C:\SysmonLab exists from earlier steps.

Help me troubleshoot my incident response checklist file.

Add the MITRE ATT&CK mapping section

Your checklist tells responders what to do. Now you need to tell them what to look for at the technique level. The MITRE ATT&CK framework catalogs adversary behaviors into numbered techniques. Mapping each technique to a specific Sysmon Event ID means a responder can immediately filter Event Viewer for the right data.

  • Add the MITRE ATT&CK mapping section to your checklist by running:
# Add MITRE ATT&CK mapping section
Add-Content -Path "C:\SysmonLab\incident-response-checklist.txt" -Value @"

--- MITRE ATT&CK MAPPING ---

T1486 - Data Encrypted for Impact
  Sysmon Event ID: 11 (FileCreate)
  Pattern: New files with .akira, .locked, .encrypted extensions
  Pattern: Ransom note files (YOUR_FILES.txt, akira_readme)

T1490 - Inhibit System Recovery
  Sysmon Event ID: 1 (ProcessCreate)
  Pattern: CommandLine contains vssadmin delete shadows
  Pattern: CommandLine contains wmic shadowcopy delete
  Pattern: CommandLine contains recoveryenabled no

T1562.001 - Disable Security Tools
  Sysmon Event ID: 1 (ProcessCreate)
  Pattern: Commands stopping or disabling security services
  Pattern: Tamper protection bypass attempts

T1083 - File and Directory Discovery
  Sysmon Event ID: 1 (ProcessCreate)
  Pattern: File enumeration commands (dir, tree, Get-ChildItem)
  Pattern: Scanning for valuable file types before encryption
"@

What do these four techniques cover?

T1486 is what your simulation tested. The attacker encrypts files and drops ransom notes.

T1490 is what your Sysmon config detects via ProcessCreate rules. The attacker deletes shadow copies so victims cannot restore files without paying.

T1562.001 is the attacker disabling antivirus or endpoint detection tools before deploying ransomware. T1083 is the reconnaissance phase where the attacker scans for high-value files to encrypt.

  • Verify the mapping was added by viewing the last section:
Get-Content "C:\SysmonLab\incident-response-checklist.txt" | Select-Object -Last 20

You should see all four MITRE ATT&CK techniques (T1486, T1490, T1562.001, T1083) with their corresponding Sysmon Event IDs and expected patterns.

Only seeing partial output?

If you see fewer than four techniques, the Add-Content command may have been truncated. Re-run the full Add-Content command from above. It will append again, so if you get duplicates, delete the file with Remove-Item "C:\SysmonLab\incident-response-checklist.txt" and rebuild from the first Set-Content command.

Help me fix my MITRE ATT&CK mapping section.

Verify your completed checklist

Before you run the final check, predict what you expect to see. Your file should have four major sections: the header, Detect, Respond, Recover, and MITRE ATT&CK Mapping.

  • Display the full checklist by running:
Get-Content "C:\SysmonLab\incident-response-checklist.txt"

You should see the complete incident response checklist scrolling through your terminal. It starts with the Detect section listing Sysmon indicators, continues through the Respond section with three containment actions, the Recover section with three restoration steps, and ends with the MITRE ATT&CK mapping covering four techniques.

✔️ I see all four sections

Your incident response checklist is complete. You now have a structured, tested playbook that maps directly to what you observed during the ransomware simulation.

ⓧ I see missing or duplicated sections

The cleanest fix is to rebuild the file from scratch. Delete it and re-run all four commands in order:

  • Delete the file:
  • Run the Set-Content command (creates the Detect section).
  • Run the first Add-Content (Respond section).
  • Run the second Add-Content (Recover section).
  • Run the third Add-Content (MITRE ATT&CK mapping).
Remove-Item "C:\SysmonLab\incident-response-checklist.txt"

Then scroll up and re-run each of the four PowerShell commands in order.

Secret mission

Build a Real-Time Ransomware Alert Script

Your detection system works, but you have to manually open Event Viewer to find attacks. What if your machine could alert you the instant ransomware indicators appear? Build a PowerShell monitoring script that watches Sysmon logs in real time and fires color-coded alerts within seconds of a threat.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally and all tools are free, so there are no ongoing costs.

Resources you used:

  • Sysmon service (running with your custom ransomware detection configuration).
  • Atomic Red Team framework at C:\AtomicRedTeam.
  • Windows Defender exclusion for C:\AtomicRedTeam.
  • SysmonLab folder at C:\SysmonLab (contains ransomware-config.xml and Monitor-RansomwareEvents.ps1).
  • PowerShell modules (invoke-atomicredteam and powershell-yaml).

Keep everything running

No action needed. Choose this if you want ongoing endpoint monitoring on your machine.

  • Sysmon continues running in the background with your ransomware detection rules active. It uses minimal system resources and provides real-time endpoint telemetry.
  • Atomic Red Team stays installed at C:\AtomicRedTeam for future testing against additional MITRE ATT&CK techniques.
  • The Defender exclusion remains in place so Atomic Red Team test files are not quarantined.
  • Your C:\SysmonLab folder remains available with your config file and monitoring script.

Pause - I'll come back to this later

Remove Atomic Red Team to free up disk space, but keep Sysmon running for ongoing protection.

  • Remove the Defender exclusion by running this command in an Administrator PowerShell prompt:
Remove-MpPreference -ExclusionPath "C:\AtomicRedTeam"
  • Delete the Atomic Red Team folder by running:
Remove-Item -Recurse -Force C:\AtomicRedTeam
  • Sysmon keeps running with your ransomware detection configuration. You can reinstall Atomic Red Team later to run more tests.
  • Your C:\SysmonLab folder stays intact with your config file and monitoring script.

Delete - I don't want to use this again

Remove all project resources and start fresh. Run each of these commands in an Administrator PowerShell prompt.

  • Uninstall Sysmon by running:
sysmon -u
  • Remove the Defender exclusion by running:
Remove-MpPreference -ExclusionPath "C:\AtomicRedTeam"
  • Delete the Atomic Red Team folder by running:
Remove-Item -Recurse -Force C:\AtomicRedTeam
  • Delete the SysmonLab folder by running:
Remove-Item -Recurse -Force C:\SysmonLab
  • Uninstall the PowerShell modules by running:
Uninstall-Module invoke-atomicredteam,powershell-yaml
  • After running all commands, your system is back to its original state with no project artifacts remaining.

Nice Work!

Nice Work!

Nice work! You just built a fully operational ransomware detection and response system from scratch.

You've learned how to:

  • Install and configure Sysmon with a custom ransomware detection ruleset targeting file encryption patterns and system recovery sabotage.
  • Safely simulate ransomware behavior using Atomic Red Team mapped to MITRE ATT&CK technique T1486, then detect and trace the attack end-to-end in Windows Event Viewer.
  • Create a tested incident response checklist structured around the NIST Cybersecurity Framework (Detect, Respond, Recover) with specific Sysmon event indicators and MITRE ATT&CK technique mappings.
  • (Secret Mission) Build a real-time PowerShell monitoring script that alerts on ransomware indicators the moment they appear in Sysmon logs.

Ready to quiz yourself?