# Detection and Analysis (TryHackMe)

Link to the challenge on TryHackMe: [Detection and Analysis](https://tryhackme.com/room/detectionandanalysis)

## **Introduction**

Detection and Analysis on TryHackMe puts you in the seat of an incident responder investigating a suspected business email compromise at Nexus Financial. The room hands you a Splunk index (`ir`) full of authentication logs, Exchange mailbox activity, and inbox rule changes, and asks you to reconstruct the attack timeline from raw log data rather than a pre-packaged alert. The investigation centers on a single user account, [l.chen@nexusfinancial.thm](mailto:l.chen@nexusfinancial.thm), and traces a path from repeated failed logins, to a successful authentication from a suspicious IP, through to mailbox manipulation that's a classic post-compromise BEC technique. This writeup walks through the SPL queries I used to pivot from initial indicator to full picture, and what each stage of the investigation revealed.

```markdown
index=ir l.chen@nexusfinancial.thm action=failure
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/b3b44159-57f1-4dc6-8344-056412a6937b.png align="center")

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/c509d637-9db3-401a-9f56-bc965b38de28.png align="center")

```markdown
index=ir l.chen@nexusfinancial.thm action=failure ipAddress="223.123.4.50"
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/52ab50de-1dc7-4fc4-bac1-0137522b5370.png align="center")

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/f21df6fb-eda1-4d2d-9d68-c62c0cf61e96.png align="center")

```markdown
index=ir user="l.chen@nexusfinancial.thm" ipAddress="223.123.4.50"
| sort + _time
| table _time, user, action
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/607d7d37-9c27-4cd2-996d-65ec64cc8944.png align="center")

```markdown
index=ir user="l.chen@nexusfinancial.thm" app=Exchange
| spath output=subject path="Folders{}.FolderItems{}.Subject"
| table _time, user, subject
| sort + _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/e1787371-33a7-4ffd-ae49-10ac0923e844.png align="center")

## Task 7

```markdown
index=ir nexus-verify.thm
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/1e196ca2-f38e-4879-9e66-226a8a5717b3.png align="center")

```markdown
index=ir l.chen@nexusfinancial.thm New-InboxRule
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/ac0f7463-f97e-4042-958c-d20f9829a458.png align="center")

```markdown
index=ir nexus-verify.thm
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/39077668-43ac-4087-9ccf-c3b73604ba06.png align="center")

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/bc3debd9-33f2-497c-9344-6af94d09101f.png align="center")

### **Conclusion**

This room is a solid, low-friction exercise in log-driven incident response: no exploitation required, just disciplined pivoting through authentication logs, Exchange audit data, and inbox rule creation events to reconstruct what an attacker did after landing on a compromised account. The key takeaway is that BEC attacks rarely stop at the initial login — the real damage (and the real detection opportunity) is in what happens after: new inbox rules that silently redirect or hide inbound mail, often tied to a lookalike phishing domain like nexus-verify.thm used to harvest credentials in the first place. Correlating `New-InboxRule` events against known-bad IPs and domains turned this from a single suspicious login into a full attacker narrative, which is exactly the kind of connective work SOC analysis actually looks like day to day.