TryHackMe: Payload Walkthrough

Arman Kumar

03:14 — The Alert That Shouldn’t Exist

The alert arrived at 03:14.

No deployments were scheduled. No infrastructure changes were logged. Yet the inference server had started making outbound HTTPS requests to an unknown address. The requests were blocked only after an automated detection rule triggered.

That meant one thing: something malicious had been running quietly in production.

This room revolves around investigating an AI supply chain compromise, where a malicious model was introduced into production and remained undetected for weeks.

Starting the Investigation

The incident directory contained:

• Deployment logs
• Network logs
• Production model
• Candidate replacement model
• Clean baseline model

The first step was reconstructing the deployment timeline.

By reading deployment.log, it became clear that the replacement model came from an unexpected organization:

trustworthy-ai-lab

The name looked safe, but that’s exactly what made it suspicious.

Dwell Time

Next, I compared the deployment timestamp against the SOC alert.

The compromised model had been active for:

21 days

Three full weeks of undetected malicious activity.

That’s a huge detection gap.

Decompiling the Production Model

The production model needed deeper inspection.

After decompilation, the malicious payload revealed something dangerous: it could execute shell commands directly using:

system()

That immediately elevated the incident from suspicious to critical.

The payload then executed:

hostname

Why?

To fingerprint the compromised host before exfiltration.

Classic attacker behavior.

Beacon Analysis

The outbound traffic logs contained beacon data showing communication with external infrastructure.

The HTTP method used was:

POST

That confirmed the server wasn’t just checking connectivity — it was transmitting data outward.

Candidate Replacement Model

Engineering had staged a new model called:

candidate_model.h5

Before deployment, it needed inspection.

Running the supplied analysis tool exposed a suspicious layer:

manipulate_output

This suggested the replacement model may also have been compromised.

In other words: the attacker wasn’t done.

Recovering the Flag

The attacker split the campaign ID across multiple artifacts to avoid easy detection.

Combining data from:

• beacon_capture.log
• Candidate model inspection

Recovered the complete flag:

THM{b4ckd00r_1n_pl41n_s1ght}

Final Answers

• Replacement organization: trustworthy-ai-lab
• Days before alert: 21
• Execution function: system
• Shell command: hostname
• HTTP method: POST
• Suspicious layer: manipulate_output

Flag

THM{b4ckd00r_1n_pl41n_s1ght}

Final Thoughts

This room demonstrates why AI model supply chains must be treated like software supply chains.

A model file is not just weights.

It can contain:

• Executable payloads
• Hidden backdoors
• Data exfiltration logic
• Persistence mechanisms

Security teams must inspect models before deployment, verify provenance, and continuously monitor runtime behavior.

Because sometimes the most dangerous compromise is the one that looks completely normal.

on Medium, where people are continuing the conversation by highlighting and responding to this story.