# Response and Recovery (TryHackMe)

Link to the challenge on TryHackMe: [Response and Recovery](https://tryhackme.com/room/responseandrecovery)

## **Introduction**

Response and Recovery picks up where Detection and Analysis left off: the investigation into the compromised [l.chen@nexusfinancial.thm](mailto:l.chen@nexusfinancial.thm) account has confirmed malicious inbox rules designed to silently delete incoming security alerts (matching on keywords like security, alert, suspicious, password, verify) so the victim would never see warning emails about the compromise. This room shifts focus from detection to the next phase of the incident response lifecycle — containment, eradication, and recovery — walking through how to scope the full extent of attacker activity, including any data exfiltration, before remediating the account and hardening against recurrence. This writeup covers the SPL queries used to confirm the malicious rule's exact filtering logic and to check whether the attacker exfiltrated any files during their access window.

```markdown
index=ir user="l.chen@nexusfinancial.thm" inboxrule
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/33b1dd4f-b070-416c-b655-c0946d8d646d.png align="center")

`security;alert;suspicious;password;verify`

```markdown
index=ir user="l.chen@nexusfinancial.thm" Operation="New-InboxRule"
| spath output=rule_name path="Parameters{}.Value"
| table _time, user, Operation, rule_name
| sort + _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/2cd8f821-c066-4aa4-888a-97b6f57537f4.png align="center")

```markdown
index=ir user="l.chen@nexusfinancial.thm" Operation="New-InboxRule" DeleteMessage
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/60c59289-590c-4bee-ba63-8fb58bb27182.png align="center")

```markdown
index=ir Operation="New-InboxRule"
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/fd3303d4-9908-41c9-b502-5ceaf08b9fec.png align="center")

```markdown
index=ir
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/2b586488-9650-4cb4-85d5-b731ed4b0312.png align="center")

```markdown
index=ir action=downloaded
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/b94e3384-632b-47c5-9fb0-ec43c73b99c4.png align="center")

```markdown
index=ir Operation=FileDownloaded user="l.chen@nexusfinancial.thm"
| table _time, user, Operation, SourceFileName, ObjectId
| sort + _time
```

![](https://cdn.hashnode.com/uploads/covers/5f4a98085ee1ba597542e097/700fa872-6758-4e00-85ea-ed617193f9f4.png align="center")

## **Conclusion:**

Response and Recovery reinforces a lesson that's easy to skip past in detection-focused rooms: finding the malicious inbox rule isn't the end of the investigation; it's the point where scope expands. Confirming the rule's `DeleteMessage` action against specific keywords showed clear intent to blind the victim to their own compromise, and pivoting to `Operation=FileDownloaded` events for the same user closed the loop on whether the attacker touched sensitive files while inside the mailbox. Together, these two rooms model a realistic BEC lifecycle end-to-end: initial access, persistence via mail rules, and the containment/recovery work of confirming exactly what was rules, seen, deleted, and taken before you can call an incident closed.