# Trusted By Default (TryHackMe)

Link to the challenge on TryHackMe: [**Trusted By Default**](https://tryhackme.com/room/trustedbydefault)

### Introduction

**Trusted By Default** is a Splunk-based investigation room on TryHackMe that drops you into a live-fire correlation exercise across web logs, Windows Security events, and Zeek network data. No file uploads, no lab setup — the evidence is already indexed, and the challenge is entirely about knowing how to ask the right SPL questions of it.

The premise: a suspicious POST request lands on a web server, and from there you're tracing the full blast radius — which account got compromised, how it moved laterally, what privileges it grabbed, and where the attacker actually landed for hands-on access.

Tools/sources involved:

*   Splunk SPL (`rex`, `stats`, `search`, field extraction against raw XML)
    
*   IIS web logs
    
*   Windows Security Event Logs (`XmlWinEventLog:Security`, EventCode 4624/4728)
    
*   Zeek `conn.log` for network-layer correlation
    

The room's biggest lesson showed up early and repeated throughout: **the field/host you expect is rarely the field/host that has the data.** Logons authenticated against a domain controller get logged on the DC, not the resource being accessed. Splunk's automatic XML field extraction doesn't always parse cleanly. And the question's terminology ("batch logon") didn't always match the actual `LogonType` value in the event — Type 4 showed up for one hop, Type 3 for another, and the room expected you to catch the mismatch rather than pattern-match on wording.

## Case Briefing

### **Prerequisites**

*   [Splunk: The Basics](https://tryhackme.com/room/splunk101)
    
*   [Splunk: Exploring SPL](https://tryhackme.com/room/splunkexploringspl)
    
*   [Incident Handling with Splunk](https://tryhackme.com/room/splunk201)
    

## The Investigation

Open **Search & Reporting**. The evidence is already indexed; you do not need to upload files or configure Splunk.

### **Investigation Guidance**

*   Start broad enough to compare normal and abnormal activity.
    
*   Inspect the returned fields before adding filters.
    
*   Use the value recovered in one question as the pivot for the next.
    
*   Use source-specific endpoint fields instead of Splunk's ingestion `host` field.
    
*   Use decimal bytes for an exact transfer total unless a question requests another unit.
    

The main incident activity occurs on **11 August 2026**.

### Answer the questions below

Review the web logs for the unusual POST request associated with the start of the incident. What URI path was requested? Submit the complete path beginning with a forward slash. `/portal/REDACTED.aspx`

```markdown
POST
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/01d0a688-8f67-4256-8320-cb77396f276d.png align="center")

Inspect the same suspicious POST event and examine the client details recorded with it. Which source IP submitted the request? Submit the IP address only. `10.xx.73.xx`

Correlate the suspicious web request with Windows logons on AUR-WEB01. Which non-system account received a batch logon shortly before the request?

```markdown
index=* host=AUR-DC01.aurora.local EventCode=4624 earliest="08/11/2026:09:00:00" latest="08/11/2026:09:15:40"
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/43f77c8e-e773-49fc-bd9c-b2df0408dcc9.png align="center")

```markdown
index=* host=AUR-DC01.aurora.local sourcetype="XmlWinEventLog:Security" EventCode=4624 earliest="08/11/2026:09:00:00" latest="08/11/2026:09:15:40"
| rex field=_raw "Name='LogonType'>(?<LogonType>\d+)<"
| rex field=_raw "Name='TargetUserName'>(?<TargetUserName>[^<]+)<"
| rex field=_raw "Name='IpAddress'>(?<IpAddress>[^<]+)<"
| search IpAddress="10.81.73.36"
| table _time, LogonType, TargetUserName, IpAddress
| sort _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/aaf0c958-77df-4e83-94de-83887f2cdb6e.png align="center")

What Windows logon type was recorded for that batch logon? `4`

After the web-server activity, review Windows group-membership changes involving the Portal Application Service account. Which privileged group was modified? Submit the group name exactly as recorded.

```markdown
index=* host=AUR-DC01.aurora.local (EventCode=4728 OR EventCode=4732 OR EventCode=4756)
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/1f70c8ef-1ce6-45a6-8e99-9af7d427695b.png align="center")

Inspect the same group-membership event. Which user performed the change? Submit the username only.

```markdown
index=* host=AUR-DC01.aurora.local EventCode=4624 earliest="08/11/2026:00:00:00" latest="08/11/2026:23:59:59"
| rex field=_raw "Name='LogonType'>(?<LogonType>\d+)<"
| rex field=_raw "Name='TargetUserName'>(?<TargetUserName>[^<]+)<"
| rex field=_raw "Name='IpAddress'>(?<IpAddress>[^<]+)<"
| search LogonType=4
| table _time, LogonType, TargetUserName, IpAddress
| sort _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/8abea328-e82e-4211-9846-198faed75fc6.png align="center")

Continue into successful logon events on the file server during the short window after the group change. Which non-built-in account generated both network and remote-interactive logon types? Submit the account name only.

```markdown
index=* host=AUR-DC01.aurora.local EventCode=4624 earliest="08/11/2026:09:16:43" latest="08/11/2026:09:30:00"
| rex field=_raw "Name='TargetUserName'>(?<TargetUserName>[^<]+)<"
| rex field=_raw "Name='LogonType'>(?<LogonType>\d+)<"
| where NOT match(TargetUserName, "\$$") AND NOT match(TargetUserName, "^(SYSTEM|NETWORK SERVICE|LOCAL SERVICE|ANONYMOUS LOGON)")
| stats values(LogonType) as LogonTypes by TargetUserName
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/b1c8303c-6618-4837-a11d-f9e2e5ba57e8.png align="center")

Inspect the successful logons for that account. Which numeric LogonType identifies the remote-interactive session? Submit the number only. `10`

> LogonType 10 is the standard Windows code for RemoteInteractive — i.e., an RDP session — as opposed to Type 3 (Network), which is what you saw for SMB/file-share style access.

Use the source IP from the suspicious POST as the source-side pivot and correlate RDP activity in the short incident window. Which destination IP is associated with the sustained connection rather than the immediately reset attempts? Submit the IP address only.  

```markdown
index=* host=AUR-DC01.aurora.local sourcetype="XmlWinEventLog:Security" EventCode=4624 earliest="08/11/2026:00:00:00" latest="08/11/2026:23:59:59"
| table _time, EventCode, Logon_Type, TargetUserName, IpAddress
| sort _time
```

**output**

```markdown
_time    EventCode    Logon_Type    TargetUserName    IpAddress
2026-08-11 09:14:00.127    4624         SYSTEM    -
2026-08-11 09:14:00.272    4624         AUR-FS01$    10.81.112.251
2026-08-11 09:14:00.293    4624         AUR-WEB01$    10.81.70.212
2026-08-11 09:14:00.347    4624         AUR-DC01$    ::1
2026-08-11 09:14:00.404    4624         AUR-DC01$    2001:0:285a:882:142d:2071:cb2e:7695
2026-08-11 09:14:00.414    4624         AUR-DC01$    -
2026-08-11 09:14:00.453    4624         AUR-DC01$    2001:0:285a:882:142d:2071:cb2e:7695
2026-08-11 09:14:00.458    4624         AUR-DC01$    -
2026-08-11 09:14:02.445    4624         AUR-DC01$    ::1
2026-08-11 09:14:02.469    4624         AUR-DC01$    fe80::a0dc:d225:c12b:48d3
2026-08-11 09:14:02.486    4624         AUR-DC01$    fe80::a0dc:d225:c12b:48d3
2026-08-11 09:14:02.512    4624         AUR-DC01$    ::1
2026-08-11 09:14:18.197    4624         SYSTEM    -
2026-08-11 09:14:20.301    4624         SYSTEM    -
2026-08-11 09:14:20.383    4624         UMFD-0    -
2026-08-11 09:14:20.383    4624         UMFD-0    -
2026-08-11 09:14:20.394    4624         UMFD-1    -
2026-08-11 09:14:20.395    4624         UMFD-1    -
2026-08-11 09:14:20.407    4624         SYSTEM    -
2026-08-11 09:14:20.536    4624         NETWORK SERVICE    -
```

Inspect the sustained RDP connection identified in the previous step. What resp\_bytes value records the data returned by the destination? Submit digits only.

```markdown
index=* sourcetype=zeek:conn dest_port=3389 earliest="08/11/2026:09:16:43" latest="08/11/2026:09:30:00"
| table _time, id.orig_h, id.resp_h, id.orig_p, id.resp_p, resp_bytes, orig_bytes, duration
| sort _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/07c26fb6-c759-4d54-b8f7-dbef1cc596f2.png align="center")

### Conclusion

**The kill chain, pieced together:**

1.  Attacker submits a malicious POST to `/portal/REDACTED.aspx` from `10.xx.73.xx`
    
2.  `svc-webapp` (the Portal Application Service account) authenticates via NTLM from that same source IP — Type 3 network logon
    
3.  [`a.ng`](http://a.ng), a human account, triggers a Type 4 batch logon shortly after
    
4.  [`a.ng`](http://a.ng) uses that session to add `svc-webapp` into a privileged AD group (`FS-Admins`) — a textbook privilege escalation via group membership abuse
    
5.  The now-privileged account logs into the file server with both network (Type 3) and remote-interactive (Type 10) sessions
    
6.  Zeek `conn.log` confirms a sustained RDP connection (port 3389) to the file server, distinguishing genuine interactive access from noise/reset attempts
    

**Key takeaways:**

*   **Source-specific fields > Splunk's ingestion** `host`**.** Domain-authenticated logons are recorded on the DC (`Computer` field in the XML), not the target resource. If you filter on `host=<target-server>` for a 4624 event, you'll come up empty even though the evidence exists.
    
*   **Don't trust event-code assumptions blindly.** "Batch logon" in the question phrasing didn't always mean `LogonType=4` in the raw data — one step in the chain was actually `LogonType=3`. Pivoting on a confirmed indicator (source IP) is more reliable than filtering on assumed terminology.
    
*   **XML field extraction needs manual** `rex`**.** Splunk's default field extraction for `XmlWinEventLog:Security` doesn't reliably surface nested `<Data Name='X'>` values as usable fields — regex against `_raw` is the dependable path.
    
*   **Group membership changes (4728/4732/4756) are a critical pivot point.** `TargetUserName` in these events is the group, not the account added — `MemberName` holds the account. Easy to get backwards on a first pass.
    

**OWASP/CWE mapping:**

*   CWE-269 (Improper Privilege Management) — the `FS-Admins` group modification
    
*   CWE-798 / T1078 (Valid Accounts, MITRE ATT&CK) — reuse of `svc-webapp` and [`a.ng`](http://a.ng) credentials for lateral movement
    
*   T1021.001 (Remote Services: RDP) — the sustained RDP session to the file server
    

**Remediation:**

*   Alert on any 4728/4732/4756 event where the modifying account isn't a designated AD admin
    
*   Restrict service accounts like `svc-webapp` from being addable to privileged groups at all (deny-by-default group nesting policies)
    
*   Flag batch/service logons (Type 4) immediately followed by interactive AD changes — that sequence alone is a strong anomaly signal
    
*   Monitor for RDP sessions immediately following a privilege escalation event, especially from accounts that don't normally have interactive logon rights