Free Windows Incident Response Simulator: Investigate a Compromised Workstation

Incident response becomes much easier to understand when you can investigate an incident yourself instead of only memorizing the phases of an IR framework.

What process is suspicious?

Where is the compromised workstation connecting?

Did the attacker create persistence?

Which user opened the malicious attachment?

Was there lateral movement?

Was data exfiltrated?

And most importantly: can you reconstruct the complete attack chain from the evidence?

The CertInstructor Windows Incident Response Simulator is a free browser-based lab designed to let you practice exactly that process.

Launch the lab:
https://go.certinstructor.org/labs/windows-ir-sim/

You play the role of a SOC analyst investigating a compromised Windows workstation using a simulated command prompt, system artifacts, event data, network connections, PowerShell history, and other evidence.

No Windows VM, malware sample, SIEM installation, or lab infrastructure is required.

Everything runs safely inside your browser.

What Is the Windows Incident Response Simulator?

The Windows Incident Response Simulator is a story-driven investigation lab.

You are presented with a security incident involving a Windows workstation.

The SIEM has detected suspicious outbound traffic. Windows Defender appears to have been disabled. Failed RDP activity has also been observed.

Your task is to investigate the endpoint and determine what happened.

The investigation is divided into four phases:

1. Detection

2. Investigation

3. Containment

4. Root Cause

Across these phases, you complete eight investigation objectives.

Instead of being given the answers, you use Windows commands to collect evidence and gradually reconstruct the incident.

The overall workflow is:

Alert → Investigate → Collect Evidence → Correlate → Contain → Determine Root Cause

Start With the Case Briefing

When the simulator opens, you receive an incident briefing.

The affected workstation has generated suspicious security alerts.

Your job is not simply to identify one malicious file.

You need to understand the full incident.

That means determining:

• Which process is malicious

• Which external systems are involved

• Whether persistence was established

• Which user was initially compromised

• Whether credentials were stolen

• Whether the attacker moved laterally

• Whether sensitive information was exfiltrated

• How the attack originally started

This is much closer to real incident-response reasoning than answering an isolated multiple-choice question.

Phase 1: Detection

The first phase focuses on identifying obvious signs of compromise.

Find the Suspicious Process

One of your first tasks is to examine running processes.

Try:

tasklist

The command displays processes currently running on the simulated Windows workstation.

Your job is to identify something that does not belong.

Attackers frequently attempt to disguise malware by using names that resemble legitimate Windows processes.

Instead of looking only for obviously malicious names, pay attention to:

• Slightly modified system-process names

• Unexpected processes

• Unusual parent/child relationships

• High or unexpected process IDs

• PowerShell activity associated with another suspicious process

The important skill is not memorizing the malware filename.

It is learning to recognize when a process does not fit the normal environment.

Investigate Network Connections

After identifying suspicious process activity, examine active network connections.

Try:

netstat -ano

The -ano options help reveal active connections together with process IDs.

Now correlate the information.

Ask:

Which PID owns the suspicious connection?

Does that PID match the suspicious process discovered earlier?

Is the destination internal or external?

Which port is being used?

Does the communication make sense for this workstation?

The simulator includes suspicious external connections alongside ordinary application traffic, so your task is to distinguish abnormal activity from legitimate network communication.

This introduces an important incident-response skill:

Process evidence + Network evidence = stronger conclusion

A strange process is interesting.

A strange process communicating with an unexpected external system is much more significant.

Phase 2: Investigation

Once you know that the workstation is compromised, the next question is:

What did the attacker do after gaining access?

The Investigation phase moves deeper into the endpoint.

Examine User Accounts

Attackers sometimes create additional accounts to maintain access.

Run:

net user

This displays user accounts on the simulated Windows system.

Look for accounts that appear unusual.

Examples of suspicious characteristics may include:

• Service-like names that you do not recognize

• Newly created administrative accounts

• Unexpected support or maintenance accounts

• Accounts created during the incident window

• Accounts with unusual privilege levels

You can investigate an individual account further with:

net user <username>

Do not decide that an account is malicious based only on its name.

Look at its context.

When was it created?

What groups does it belong to?

Does the account fit the normal environment?

Review the Security Event Timeline

Next, investigate the Windows security events.

The simulator accepts commands such as:

eventlog

to display relevant incident events.

Now begin thinking chronologically.

Look for the earliest suspicious activity.

You may see events related to:

• User activity

• Process execution

• Authentication

• Account creation

• File access

• PowerShell activity

• Lateral movement

Your goal is to identify the user involved in the original compromise and determine what happened first.

This is where incident response begins to resemble digital forensics.

Individual events become much more useful when arranged into a timeline.

For example:

User action → PowerShell execution → Malware process → External connection

A timeline helps transform unrelated-looking events into an attack narrative.

Phase 3: Containment

The third phase asks you to determine how far the incident spread and what information may have been affected.

Containment is not simply about disconnecting the first compromised machine.

You need to understand the attacker's reach.

Identify Lateral Movement

Attackers often attempt to move from the initial victim to other systems.

Use evidence from commands such as:

netstat -ano

or:

eventlog

and look for internal communication that deserves investigation.

SMB traffic on port 445, for example, may be relevant when combined with credential theft and other evidence.

Ask:

Which internal system did the compromised workstation access?

Was that communication expected?

Were stolen credentials used?

Should the second host also be isolated and investigated?

This teaches an important containment principle:

The first compromised machine may not be the only compromised machine.

Incident responders need to identify the scope before declaring containment successful.

Examine PowerShell History

PowerShell is an extremely useful administrative tool, but its capabilities also make PowerShell activity important during Windows incident investigations.

The simulator provides:

powershell-history

to inspect PowerShell command history associated with the incident.

Look carefully at what was executed.

The simulated history may reveal actions involving:

• Credential access

• Security-control changes

• Account creation

• Local administrator membership

• File copying

• Scheduled tasks

• Network communication

• Data transfer

Instead of treating each command independently, ask:

What objective was the attacker trying to achieve?

For example:

A credential-related command may support privilege escalation or lateral movement.

A file-copy command may indicate data collection.

An outbound web request involving a sensitive file may suggest exfiltration.

This is how individual commands become evidence of attacker behavior.

Determine What Data Was Exfiltrated

An important incident-response question is whether sensitive information left the environment.

Review PowerShell history and event evidence.

Look for:

• Files copied from another system

• Temporary staging locations

• Outbound upload commands

• Connections to command-and-control infrastructure

If data was exfiltrated, the incident may have consequences beyond simply cleaning the infected workstation.

The organization may need to consider:

• Which data was affected

• Who owned the data

• Whether credentials were exposed

• Whether additional systems are compromised

• Whether notification or reporting requirements apply

The simulator introduces this reasoning without requiring a real data breach environment.

Phase 4: Root Cause

Finding malware is not the same as determining root cause.

The final phase asks you to reconstruct how the incident started and connect the evidence into a complete attack chain.

Determine the Initial Access Vector

Review everything you have collected.

Do not focus only on the most dramatic event.

Instead, return to the beginning of the timeline.

Ask:

What happened before the malware appeared?

The investigation evidence allows you to determine the original attack vector.

This reinforces an important principle:

Root cause is about how the attacker gained the opportunity to compromise the system—not merely which malware happened to run afterward.

Understanding the initial access vector helps defenders choose the correct preventive controls.

Identify the C2 Infrastructure

You must also determine which infrastructure was used for command-and-control and data transfer.

Correlate:

• Network connections

• Process IDs

• PowerShell activity

• Event logs

This is another example of why evidence correlation matters.

A suspicious IP in isolation is simply an indicator.

The same IP appearing in command history, network connections, and exfiltration activity becomes much stronger evidence.

Use the Simulated Windows Terminal

A major part of the lab is the Windows command terminal.

You can use commands including:

tasklist

netstat -ano

net user

net user <username>

whoami /priv

ipconfig

dir

schtasks

wmic startup list

eventlog

powershell-history

systeminfo

hostname

You can type:

help

to see available commands.

These commands expose different parts of the simulated endpoint.

The objective is not simply to learn syntax.

Think of each command as answering an investigative question.

tasklist

What is running?

netstat -ano

Who is communicating with whom?

net user

Which accounts exist?

schtasks

Was persistence created through scheduled tasks?

wmic startup list

What runs automatically at startup?

eventlog

What does the security timeline show?

powershell-history

What commands were executed during the compromise?

This produces a much more useful way to remember incident-response commands.

Do not memorize:

command → definition

Instead remember:

investigative question → command → evidence

Collect Evidence as You Investigate

As you execute relevant commands, the simulator automatically adds important findings to the Evidence Collected panel.

This allows you to see your investigation build over time.

Evidence may include information related to:

• Suspicious processes

• Network connections

• Accounts

• PowerShell activity

• Persistence

• Credential access

• Internal movement

• Data exfiltration

Think of this panel as a lightweight evidence board.

By the end of the investigation, you should be able to connect these artifacts into a coherent story.

Use the Alert Timeline

The left side of the simulator also provides an initial Alert Timeline.

Examples include:

• Failed RDP activity

• Windows Defender being disabled

• Suspicious outbound communication

These are initial leads.

They are not necessarily the complete story.

This reflects an important SOC concept:

An alert tells you where to begin investigating.

It does not always tell you the root cause.

Your job is to investigate beyond the alert.

Use Hints Strategically

Each objective includes progressive hints.

Try not to use them immediately.

A better process is:

1. Read the objective.

2. Decide what information you need.

3. Choose a command.

4. Analyze the output.

5. Correlate with existing evidence.

6. Submit your answer.

7. Use a hint only when necessary.

Hints can reduce your score when repeatedly used, encouraging independent investigation.

The goal is not to punish mistakes.

It is to make you think before asking the simulator for more information.

Copy Commands and Terminal Evidence

The simulator provides copy functions for both mission commands and terminal output.

This can be useful when creating investigation notes.

For example, you might document:

Finding: Suspicious process identified

Command: tasklist

Evidence: Process name and PID

Follow-up: Check active connections for the same PID

Then:

Finding: External reverse connection

Command: netstat -ano

Evidence: External IP, destination port, matching PID

This is very similar to how analysts build an investigation narrative from artifacts.

Complete the Incident Report

After completing all four phases, the simulator generates a Case Closed — Incident Report.

This is one of the most useful parts of the lab.

Instead of ending with only a score, the final report summarizes the incident.

It includes sections such as:

• Executive Summary

• Attack Chain

• Indicators of Compromise

• Collected Evidence

• Final Score

• Recommendations

The attack chain connects the incident from initial access through later attacker activity.

The final report may cover stages such as:

Initial Access

↓

Execution

↓

Persistence

↓

Privilege Escalation

↓

Lateral Movement

↓

Data Exfiltration

↓

Command and Control

This helps you see how individual findings fit into a complete compromise.

Understand Indicators of Compromise

The final report also summarizes IOCs discovered during the investigation.

These may include:

• Attacker IP addresses

• C2 infrastructure

• Malicious process names

• Backdoor accounts

• Suspicious attachments

But remember:

An IOC is evidence—not the entire incident.

A strong investigation explains how the indicators relate to one another.

For example:

Malicious attachment → PowerShell → Malware → Reverse shell → Credential theft → Lateral movement → Exfiltration

That relationship is more useful than a disconnected list of IP addresses and filenames.

Incident Response Is About Reconstruction

One of the biggest lessons from the simulator is that incident response is essentially a reconstruction problem.

At the beginning, you know very little.

You may only have:

Suspicious outbound traffic

and:

Security software disabled

Then you gather evidence.

Gradually you discover:

Process

↓

Connection

↓

Persistence

↓

Compromised user

↓

Credential theft

↓

Lateral movement

↓

Exfiltration

↓

Root cause

This is exactly why disciplined investigation matters.

A Practical Windows IR Workflow

When investigating a suspicious Windows endpoint, a simplified workflow might look like this:

1. Confirm the alert

Understand what triggered the investigation.

2. Examine running processes

Look for unexpected or suspicious execution.

3. Inspect network connections

Identify unusual internal and external communication.

4. Investigate accounts

Look for unexpected or newly created users.

5. Check persistence

Review scheduled tasks and startup mechanisms.

6. Examine security events

Build a timeline of relevant activity.

7. Review PowerShell and command history

Understand what actions occurred on the host.

8. Determine scope

Identify lateral movement and additional affected systems.

9. Identify affected data

Determine whether information was accessed or exfiltrated.

10. Determine root cause

Understand how initial access occurred.

11. Contain and remediate

Remove attacker access and address affected systems.

12. Document

Create an incident report containing evidence, IOCs, timeline, impact, and recommendations.

The simulator condenses many of these concepts into a manageable browser-based exercise.

Why Randomized Incident Data Matters

The simulator can generate different incident indicators, including IP addresses, process names, user accounts, host information, and other artifacts.

Your current incident dataset is retained while you work through the case.

This helps discourage simple answer memorization.

Instead of remembering:

"The answer is always this IP."

you need to use the evidence available in your current investigation.

That is much closer to the skill incident-response training should develop.

Your Progress Is Saved

The simulator can retain your current phase, score, evidence, command history, and incident state in the browser.

You can leave and return without immediately losing the investigation.

Use RESET when you want to clear the case and begin a fresh incident.

A new run is useful because the investigation methodology remains the same even when some of the indicators change.

That is the real learning objective:

Learn the process, not the answer.

Who Is This Lab For?

The CertInstructor Windows Incident Response Simulator is suitable for:

• SOC analyst learners

• Incident response students

• Blue-team practitioners

• Digital forensics students

• Windows security learners

• Cybersecurity certification candidates

• Help desk and system administrators moving into security

• Anyone learning endpoint investigation

It can complement study involving:

• Incident response

• Endpoint investigation

• Windows security

• Threat detection

• IOC analysis

• Persistence

• Credential theft

• Lateral movement

• Data exfiltration

• Root-cause analysis

How This Lab Differs From the SOC Log Lab

The two labs complement each other, but they focus on different skills.

The SOC Log Analysis Lab emphasizes:

Search → Filter → Correlate logs → Identify indicators

The Windows Incident Response Simulator emphasizes:

Investigate endpoint → Collect evidence → Reconstruct attack chain → Determine root cause

In simple terms:

SOC Log Lab:
"Something suspicious happened. Find it in the logs."

Windows IR Simulator:
"This workstation is compromised. Determine exactly what happened."

That makes them useful as sequential training exercises.

Continue Into Incident Response and Recovery

After finishing this simulator, you can continue with the Incident Response Lab — Fix the System.

The learning progression becomes:

SOC Log Analysis

Detect suspicious activity.

↓

Windows Incident Response Simulator

Investigate the compromised endpoint and reconstruct the attack.

↓

Incident Response Lab

Troubleshoot, remediate, restart services, and validate recovery.

Together, they cover different stages of the defensive security workflow.

Start Investigating

A good incident responder does not jump directly from an alert to a conclusion.

They collect evidence.

They correlate artifacts.

They build a timeline.

They determine scope.

They identify root cause.

And they document what happened.

The CertInstructor Windows Incident Response Simulator gives you a safe environment to practice that process directly in your browser.

Start the investigation here:

https://go.certinstructor.org/labs/windows-ir-sim/

Work through all four phases:

Detection → Investigation → Containment → Root Cause

Follow the evidence, reconstruct the attack chain, and complete the final incident report.

No VM or installation is required.

CertInstructor — Learn · Practice · Certify

Explore more cybersecurity learning resources:

https://certinstructor.org