Detection and Analysis (TryHackMe)

Link to the challenge on TryHackMe: Detection and Analysis

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, 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.

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

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

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

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

Task 7

index=ir nexus-verify.thm

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

index=ir nexus-verify.thm

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.