TryHackMe - Overflow The Jackpot CTF - Detection Engineering - Fresh Powder CFT (Bonus Challenge)
PR #1 — External RDP Logon From an Untrusted Source Grants Administrative Access
What is the detection trying to catch?
The rule is trying to detect successful RDP logons coming from untrusted sources, especially when the account could provide administrative access.
Windows generates Event ID 4624 for a successful logon.
For RDP:
-
LogonType 10= RemoteInteractive / RDP logon -
LogonType 7= Unlock
The final detection therefore looks for:
selection: EventID: 4624 LogonType: ['10', '7']
The idea is:
Detect successful RDP activity unless it matches a known legitimate source.
What was wrong originally?
The original exclusion was:
IpAddress|startswith: '203.0.113.'
The problem was that this was the attacker's source range, not a legitimate range.
So the rule was effectively saying:
"Ignore connections coming from the attacker."
That is the exact opposite of what the detection needed to do.
What is considered legitimate?
There are three legitimate scenarios:
1. Internal administrative hops
IpAddress|startswith: '10.40.'
Any traffic from 10.40.0.0/16 is considered legitimate.
2. Authorized VPN users
IpAddress|startswith: '10.90.' TargetUserName: ['r.doyle', 'k.nakamura', 'p.okonkwo']
Both conditions must match.
So:
10.90.x.x + r.doyle → legitimate 10.90.x.x + hacker → suspicious 192.168.x.x + r.doyle → suspicious
This is important because being inside the VPN range alone does not prove legitimacy.
3. SummitDesk MSP
IpAddress|startswith: '198.51.100.' TargetUserName: 'svc_summitdesk_support'
Again, both the IP range and the expected service account must match.
Why was LogonType 7 added?
The original rule only detected:
LogonType: 10
A Red Team operator could bypass this by resuming an existing RDP session through an unlock event:
LogonType 7
So the final rule detects both:
LogonType: ['10', '7']
Final logic
Successful RDP/Unlock | v Is it a legitimate internal hop? | No | v Is it an authorized VPN user? | No | v Is it SummitDesk + correct service account? | No | v ALERT
Main lesson
Build exclusions from documented legitimate behavior, not from assumptions about the attacker.
Also, always consider alternate event types that represent the same behavior.
PR #2 — NetScan Enumerates Writable Administrative Shares via a Delete.me Access Test
What is the detection trying to catch?
This detection looks for network-share activity associated with share discovery and access testing.
The relevant Windows event is:
Event ID 5145
This event records access to an object through a network share.
For example:
\\DC-CSRC01\C$\Users\Bob\delete.me
There are two important fields:
ShareName RelativeTargetName
What was wrong?
The original rule checked:
ShareName|endswith: 'delete.me'
But ShareName contains the actual share:
\\DC-CSRC01\C$
The delete.me object is stored in:
RelativeTargetName
For example:
ShareName: \\DC-CSRC01\C$ RelativeTargetName: Users\Bob\delete.me
So the original detection was checking the wrong field.
The fix
Instead of:
ShareName|endswith: 'delete.me'
the rule uses:
RelativeTargetName|endswith: 'delete.me'
Now the detection correctly looks for:
EventID = 5145 + RelativeTargetName ends with delete.me = ALERT
Why is delete.me important?
The scanning tool uses this artifact as an access test.
The attacker is effectively asking:
"Can I access this administrative share?"
For example:
Server A → C$ → access test Server B → C$ → access test Server C → ADMIN$ → access test
This can help an attacker discover where they have useful access.
Why is there no exclusion filter?
Because according to the environment documentation, legitimate activity does not produce this specific delete.me artifact.
Therefore:
condition: selection
is enough.
There is no known legitimate behavior that needs to be excluded.
Main lesson
Always verify what each field actually contains.
A field name can sound correct while containing completely different data from what you expect.
In this case:
ShareName → the share itself RelativeTargetName → object/path inside the share
PR #3 — Remote Access Tool Installed as a Service on Server Infrastructure
What is the detection trying to catch?
The goal is to detect a Remote Access Tool installed as a Windows Service on servers.
The relevant MITRE technique is:
T1543.003 — Windows Service
The idea is:
Attacker | v Install AnyDesk / ScreenConnect / TeamViewer | v Create Windows Service | v Remote access / persistence
Problem 1 — Wrong event and wrong field
The original detection used:
Image|endswith: '\AnyDesk.exe'
Image is generally associated with process creation.
But the behavior being detected is:
A Windows service was installed.
The correct event is:
Event ID 7045
So instead of looking for process creation, the detection needs to look at service installation.
Problem 2 — AnyDesk is legitimate on workstations
AnyDesk is not automatically malicious.
According to the environment documentation, it is legitimate on certain workstation classes:
SNW-PC* ALD-PC* TBL-PC*
But it should not be running as a service on server infrastructure.
So the detection needs an exclusion:
filter_workstation_class: ComputerName|startswith: - 'SNW-PC' - 'ALD-PC' - 'TBL-PC'
The logic becomes:
AnyDesk service on workstation ↓ Ignore AnyDesk service on server ↓ Alert
Problem 3 — endswith did not match the real value
The first fix tried:
ServiceFileName|endswith: '\AnyDesk.exe'
But the real Splunk value looked like:
C:\Program Files\AnyDesk\AnyDesk.exe --service
Notice:
AnyDesk.exe --service
The value does not end with:
AnyDesk.exe
It ends with:
--service
Therefore:
endswith: '\AnyDesk.exe'
does not match.
The correct operator is:
ServiceFileName|contains: 'AnyDesk.exe'
Problem 4 — Red Team bypassed an AnyDesk-only rule
If you only detect:
AnyDesk
an attacker can simply use:
ScreenConnect
or:
TeamViewer
The underlying technique is still the same:
Remote Access Tool + Windows Service = T1543.003
So the final detection includes:
OriginalFileName: - '7z.exe'
Oops — for PR #3 specifically, the relevant list is:
ServiceFileName|contains: - 'AnyDesk.exe' - 'ScreenConnect' - 'TeamViewer'
Final logic
Event 7045 | v AnyDesk / ScreenConnect / TeamViewer? | v Is it on an authorized workstation? | +---- YES → Ignore | +---- NO → ALERT
Main lesson
Do not trust field names or assumed values.
Verify:
- the correct event,
- the actual populated field,
- the real value in Splunk,
- the correct matching operator.
Also, detect the technique, not just one specific tool.
PR #4 — 7-Zip Archives Data Directly From a Live Network Share
What is the detection trying to catch?
The attacker is archiving data directly from a network share:
\\FS-RESV01\Reservations\
instead of first copying the data locally.
Conceptually:
Network Share | v Archive utility | v Archive | v Potential exfiltration
This relates to:
- T1560.001 — Archive Collected Data
- T1567 — Exfiltration-related behavior
Problem 1 — -p was the wrong indicator
The original rule checked:
CommandLine|contains: '-p'
The assumption was that password-protected archives would be suspicious.
But the real attacker command line did not contain -p.
The real anomaly was:
The archiver was reading directly from a live network share.
So the detection was looking for the wrong thing.
Problem 2 — Generic \\ matching created false positives
The team tried to detect a UNC path by looking for backslashes.
For example:
CommandLine|contains: '\\'
But after the rule was converted into SPL, the escaping caused the generated query to effectively match a generic backslash pattern.
That meant normal Windows paths could match:
C:\Windows\ C:\Program Files\ C:\Users\
The result was:
24 false positives
including an unrelated legitimate shared-backup job.
The team verified this by running the actual generated SPL directly in Splunk and inspecting the matching events.
That is excellent detection debugging.
Problem 3 — Use specific server/share names
Instead of trying to detect every possible UNC path, the rule uses known server-tier shares:
CommandLine|contains: - 'FS-RESV01\' - 'BKP-CSRC01\' - 'DC-CSRC01\' - 'DC-CSRC02\' - 'DC-CSRC03\' - 'HV-CSRC01\'
So:
7z.exe + \\FS-RESV01\... ↓ match
while:
7z.exe + C:\Users\Bob\... ↓ no match
This is much more precise.
Red Team bypasses
1. WinRAR / Rar
If you only detect 7-Zip:
7z.exe
the attacker can switch to:
WinRAR.exe Rar.exe
So the rule includes all of them.
2. PowerShell
An attacker can avoid external archiving tools entirely:
Compress-Archive
So there is a separate PowerShell detection:
Image|endswith: '\powershell.exe' CommandLine|contains: 'Compress-Archive'
combined with the network-share condition.
3. Rename 7-Zip
An attacker can rename:
7z.exe
to:
update.exe
If you detect only the Image path, you lose the match.
The rule therefore uses:
OriginalFileName
which comes from embedded PE metadata.
4. Use another server
If you only detect:
FS-RESV01
the attacker can simply use:
BKP-CSRC01 DC-CSRC01 ...
So the detection covers the known server-tier shares.
Legitimate monthly export
There is also a legitimate recurring job:
ParentImage|endswith: '\wscript.exe' CommandLine|contains: 'ReservationsExport_'
That activity needs to be excluded.
Therefore:
condition: ... and not filter_monthly_export
Final logic
┌─ 7-Zip / WinRAR / Rar │ + │ Server share │ └──────────────┐ │ OR │ PowerShell + Compress-Archive + Server share │ v SUSPICIOUS │ v Monthly export? / \ YES NO | | IGNORE ALERT
Main lesson
Detect the actual behavior, not an incidental characteristic like -p.
And:
Always test the generated SIEM query, not just the YAML rule.
PR #5 — Lynx Ransomware Payload Executed With Distinctive Encryption Flags
What is the detection trying to catch?
This detection targets Lynx ransomware, using:
T1486 — Data Encrypted for Impact
The important behavior is the use of the distinctive flags:
--dir --mode fast
For example:
w.exe --dir C:\Data --mode fast
The combination is highly useful because it is associated with the ransomware behavior.
Problem 1 — Wrong parent process
The original rule expected:
ParentImage|endswith: '\services.exe'
But the real event showed:
ParentImage = cmd.exe
So the actual execution chain was:
cmd.exe | v ransomware payload
not:
services.exe | v ransomware payload
Therefore the parent-process condition was simply wrong.
Problem 2 — Legitimate DiskOptimizer uses the same flags
There is a legitimate nightly job:
DiskOptimizer.exe
which also uses:
--dir --mode fast
Therefore, if you detect only:
CommandLine|contains|all: - '--dir' - '--mode fast'
you will detect both:
Lynx ransomware ↓ ALERT DiskOptimizer ↓ FALSE POSITIVE
You need an exclusion.
Problem 3 — The first fix could be bypassed by renaming
The first fix anchored the selection on:
Image|endswith: '\w.exe'
along with the flags.
That creates a problem.
The attacker can rename the ransomware:
w.exe
to:
DiskOptimizer.exe
and put it in the legitimate DiskOptimizer directory.
Now:
Image ends with \w.exe? ↓ NO
Therefore:
selection = FALSE
The detection never reaches the useful exclusion logic.
This is an important Sigma logic concept:
selection AND NOT filter
only helps if the event first matches selection.
Final solution
The final rule removes the filename from the selection entirely:
selection: CommandLine|contains|all: - '--dir' - '--mode fast'
Now the detection says:
"I do not care what the executable is called. If this distinctive command-line behavior occurs, investigate it."
Then the legitimate tool is excluded using:
filter_diskoptimizer: OriginalFileName: 'DiskOptimizer.exe'
and:
condition: selection and not filter_diskoptimizer
Why OriginalFileName?
An attacker can easily change:
filename
and:
path
For example:
malware.exe ↓ DiskOptimizer.exe
But the PE may still contain:
OriginalFileName = w.exe
So:
Filename: DiskOptimizer.exe OriginalFileName: w.exe
The detection sees:
--dir + --mode fast + OriginalFileName != DiskOptimizer.exe ↓ ALERT
This is harder to spoof than simply changing the filename or installation path.
It is not impossible to forge, but it raises the bar.
The final logic
--dir + --mode fast | v MATCH | v OriginalFileName = DiskOptimizer.exe? / \ YES NO | | IGNORE ALERT
Legitimate example
Image: C:\Program Files\DiskOptimizer\DiskOptimizer.exe OriginalFileName: DiskOptimizer.exe CommandLine: DiskOptimizer.exe --dir C:\Data --mode fast
Result:
MATCH + DiskOptimizer metadata ↓ IGNORE
Malicious renamed payload
Image: C:\Program Files\DiskOptimizer\DiskOptimizer.exe OriginalFileName: w.exe CommandLine: DiskOptimizer.exe --dir C:\Data --mode fast
Result:
MATCH + OriginalFileName != DiskOptimizer.exe ↓ 🚨 ALERT
The main lessons from all 5 PRs
If you want to remember the whole set, I would reduce them to these five principles:
| PR | Main lesson |
|---|---|
| #1 — RDP | Build exclusions from real legitimate behavior, not the attacker's IP. |
| #2 — NetScan | Verify which field actually contains the data you want to detect. |
| #3 — Remote Access Tool | Verify the real event, field, value, and operator using SIEM ground truth. |
| #4 — 7-Zip | Detect the actual behavior, test the generated SIEM query, and think about tool alternatives. |
| #5 — Lynx | Don't anchor detection on easily spoofed filenames; use behavioral indicators + harder-to-spoof metadata. |
And there's a common pattern across all five:
Initial assumption ↓ Detection fails / produces FPs ↓ Check raw Splunk ground truth ↓ Understand the real behavior ↓ Red Team tries a bypass ↓ Harden the detection ↓ Final Sigma rule
That is essentially the detection engineering workflow these five PRs are teaching.
Comments
Post a Comment