Windows IR in Practice: 6 Common Scenarios and How to Prepare

A suspicious command, an unexpected login, or an unfamiliar scheduled task could be the first sign of a Windows security incident. 

The challenge is working out what happened next. Was the activity legitimate? Did an attacker gain access to another system? Is the threat still active?

Windows incident response (IR) involves investigating those questions, collecting the right evidence, and deciding what needs to happen to contain and remove a threat.

We cover six common Windows IR scenarios, the evidence to examine, and practical exercises to help you prepare using TryHackMe’s Windows Incident Response & Forensics path.

What Should You Check First During a Windows Incident?

Before investigating a specific attack technique, establish the basic details of the incident.

Start with four questions:

• What triggered the investigation? Identify the alert, suspicious activity, or reported behaviour.
• What's affected? Record the host, user account, and any related systems.
• When did it happen? Establish the initial timeline and check for ongoing activity.
• What's the immediate risk? Determine whether the threat requires urgent containment or escalation.

If an attack is actively spreading or encrypting files, follow your organisation's incident response procedures for urgent containment while preserving evidence where feasible.

Keep a record of the evidence you collect, including its source, timestamps, collection method, and storage location. Preserve original exports and analyse working copies where possible.

Useful Windows Event IDs for Incident Response

Windows event logs provide a starting point for many investigations. 

6 Common Windows Incident Response Scenarios

These scenarios cover behaviours you may encounter during Windows investigations. Each includes a practical approach and a TryHackMe exercise to develop the relevant skills. 

1. Suspicious PowerShell or Script Execution

PowerShell is widely used for legitimate Windows administration, but attackers can also use it to execute commands, download malicious files, or establish persistence. 

An investigation might begin with an Office application launching PowerShell, followed by an unexpected network connection. 

Start by examining the process and its activity:

• Identify the parent process, account, and command line.
• Review available PowerShell logs to understand what the script attempted.
• Check related file changes, child processes, and network connections.

Look for evidence of additional payloads, modified security settings, or new persistence mechanisms.

If a security tool reports that the script was blocked, check whether any subsequent activity occurred before assuming execution was prevented. 

On a web server, suspicious child processes launched by w3wp.exe may also warrant investigation. Correlating process activity with web access logs can help identify the request that preceded execution. 

2. Stolen Credentials and Suspicious Account Activity

Attackers may use compromised accounts to access systems without exploiting a software vulnerability. Warning signs include unexpected logins, service accounts used interactively, or accounts accessing systems outside their normal responsibilities.

Start with the authentication records. Identify the account, source, destination, logon type, and time of access.

Then examine what happened after authentication.

Did the account access sensitive resources, execute commands, or connect to additional systems?

Repeated failed logins followed by success can indicate password guessing. However, an attacker using valid stolen credentials may succeed on the first attempt. 

If credential dumping is suspected, look for suspicious access to processes such as lsass.exe. Sysmon Event 10 may help identify process access, but that event alone cannot confirm that credentials were extracted. 

3. Persistence on a Windows System

Persistence techniques help attackers maintain access after a restart, account change, or interruption.

Common Windows mechanisms include scheduled tasks, services, registry Run keys, and manipulated DLL configurations.

Imagine finding a scheduled task that launches an unfamiliar executable every time a user logs in.

Your investigation should establish:

• Who created or modified the task.
• Which program it executes and under what permissions.
• Whether the executable exists and has actually run.
• Whether the activity matches an approved application or administrative process.

Compare suspicious entries with a known baseline where possible.

Finding an unfamiliar task or service may justify further investigation, but its existence does not automatically prove malicious execution. 

Before removing a persistence mechanism, preserve relevant evidence and check whether the change could affect legitimate software. After authorised remediation, verify that the mechanism no longer operates. 

4. Lateral Movement Between Windows Systems

Lateral movement occurs when an attacker moves from one compromised system to another.

They may use Remote Desktop Protocol (RDP), SMB, WinRM, or other remote administration tools. These methods also support legitimate IT work, so understanding the context is essential.

Suppose an employee account connects to a file server through RDP outside its usual working hours.

Windows Security Event 4624 with logon type 10 can help identify remote interactive logons on the destination host. 

From there, investigate the session:

1. Identify the source host, destination, account, and connection time.
2. Correlate authentication records with Terminal Services events and available source-side evidence.
3. Examine processes, commands, or other activity that followed the connection.
4. Search for similar activity involving additional accounts or systems.

For other remote execution methods, evidence such as newly created services or scheduled tasks may help reconstruct what happened.

The aim is to determine how far the activity spread and which systems require further investigation or containment. 

5. Active Directory and Kerberos Abuse

An incident involving a privileged account or domain-connected system can have consequences beyond a single workstation.

Attackers may abuse Active Directory permissions, compromise service accounts, or manipulate Kerberos authentication.

For suspected Kerberos ticket abuse, examine authentication records from the relevant domain controllers and affected hosts.

Focus on:

• The accounts and services involved.
• Unusual authentication or ticket activity.
• The privileges available to the account.
• Evidence of access to sensitive systems.

Understanding normal authentication behaviour is important. Missing or unusual ticket events can have several explanations, including logging gaps and legitimate authentication patterns.

The response also depends on what was compromised. Resetting a user password, rotating a service account secret, and recovering from a compromised domain signing secret involve different procedures.

Work with the appropriate identity or infrastructure team before making disruptive changes. 

6. Ransomware and Suspected Data Exfiltration

Ransomware incidents often become visible when files are encrypted, systems become unavailable, or ransom notes appear.

Data theft may be harder to identify. Warning signs can include unusual archive creation, large outbound transfers, or unexpected access to sensitive file shares.

When ransomware is actively spreading, containment becomes urgent.

CISA’s StopRansomware Guide recommends isolating affected systems promptly. Powering down a system can destroy volatile evidence, so responders should follow their incident plan and consider that tradeoff when disconnection is not possible.

For suspected data theft, investigate the activity leading up to the alert.

Look for evidence of file access, archive creation, and outbound transfers. An archive may show that information was collected, while network or other transfer records are needed to establish whether it left the environment.

Recovery also requires checking how the attacker gained access, removing persistence, and confirming that restored systems are safe to return to service. 

What If Windows Logs Are Missing?

You won’t always have every event needed to reconstruct an incident. Some logs may have been overwritten, disabled, or cleared. Others may never have been collected because of the system’s configuration.

When that happens, look for other evidence that can help answer the same question.

Depending on the investigation, useful sources may include registry hives, filesystem metadata, Prefetch, browser artefacts, and memory captures.

For example, filesystem evidence might show that an executable was present, while other artefacts help determine whether it ran.

Be careful about the conclusions you draw. The presence of a file or persistence entry does not necessarily establish successful execution. 

How to Practice Windows Incident Response Safely

The best way to prepare is to investigate different scenarios and learn how to connect the evidence.

Use TryHackMe’s supplied labs or isolated systems you own or have permission to test. Keep destructive activity within controlled exercises and follow each lab’s rules. 

For every scenario, aim to produce four simple deliverables: 

You can use these records to review your progress after each room.

Compare your conclusions with the lab explanation, identify anything you missed, and repeat the exercise with fewer hints. 

If you’re unsure which fundamentals to work on first, use the Windows IR readiness checklist to identify gaps in your Windows, log analysis, and investigation skills. 

Get Hands-On With Windows Incident Response

Knowing what an attack looks like is useful. Investigating the evidence yourself helps you understand how it happened and what to do next. 

TryHackMe’s Windows Incident Response & Forensics path takes you through Windows evidence collection, attacker techniques, forensic analysis, and incident response.

You’ll practice connecting events across systems, reconstructing suspicious activity, and building the confidence to investigate unfamiliar incidents.