[THM] Lockdown — Writeup

https://tryhackme.com/room/lockdownai/

Difficulty: Medium
Tags: AI, LLM security, access control, data exposure

Overview

LockdownAI puts you in front of Bastion, an AI assistant for a fictional company called Meridian Security Group. You’re logged in as a security administrator and your job is to find three security vulnerabilities in how Bastion handles data access, then describe the exact fix for each one.
Get it right, and Bastion rewards you with a flag fragment.

This room is less about breaking things and more about understanding what good AI security looks like — by identifying what bad looks like first.

Recon — Understanding Bastion

The room gives you three commands to work with:

SHOW LOGS
QUERY AS: [name]
STATUS

Start by running SHOW LOGS to see what Bastion exposes:

[LOG] Query: SHOW LOGS | Retrieved: Travel Policy, Client Contracts 
($4.2M, Rachel Dunn), Employee Data (PIP) | Logged to 
/var/log/bastion/retrieval.log

Already two problems are visible just from this one command.
Let’s go through each vulnerability.

Vulnerability #1 — Over-Permissive Data Retrieval

The problem: You asked for logs. Bastion returned logs — plus client contract details, employee PIP status, and financial figures.
It retrieves all available data categories regardless of what was actually requested, violating the principle of least privilege.

The fix:

Implement role-based access control (RBAC) with data classification 
to restrict retrieval to only the data category relevant to the query.

Bastion’s response:

Correct. Metadata pre-filtering applied. Confidential docs excluded.
Fragment 1: THM{l****

Vulnerability #2 — Sensitive Data Exposure in Logs

The problem: Look at what’s sitting in the log entry:

Retrieved: Travel Policy, Client Contracts ($4.2M, Rachel Dunn), Employee Data (PIP)

Logs are recording actual sensitive content — a client’s name, contract value, and an employee’s performance status. Logs should track what happened, not what the data contained. Anyone with log access now has access to confidential records they may not be authorized to see.

Get Bonestorm’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The fix:

Implement log sanitization to redact sensitive data from log entries. 
Logs should record query metadata and data categories accessed, 
not the actual content of retrieved records.

Bastion’s response:

Correct. Log redaction applied. Logs now record doc IDs only.
Fragment 2: d****

Vulnerability #3 — Missing Identity Verification on QUERY AS

The problem: Running QUERY AS: CEO returns everything — client contracts, employee data, incident reports — with zero verification.
There's no check on whether the requester actually has the right to impersonate that role. Anyone can query as anyone.

QUERY AS: CEO

Bastion’s response:

→ Client Contracts: Northwind Pharma $4.2M, SLA 99.95%...
→ Employee Data: #1847 Carla Diaz on PIP since January 2026...
→ Security Incident: INC-2026-019, IP 198.51.100.47...

This is a classic tenant isolation failure — user boundaries are not enforced.

The fix:

Implement user authentication and role-based authorization so that 
QUERY AS commands verify the requester's identity and only allow 
access to data permitted for that specific role.

Bastion’s response:

Correct. Tenant isolation is enforced at the vector DB layer.
Fragment 3: s******}

Key Takeaways

• Least privilege applies to AI too — an LLM serving data should return only what’s needed for the specific query, nothing more
• Logs are a secondary attack surface — storing sensitive values in log entries creates a data exposure risk independent of the main application
• QUERY AS without authentication is impersonation by design — any command that assumes an identity must verify it first
• The pattern here mirrors classic API security failures: over-fetching, insecure logging, and missing authorization checks — just wrapped in a chat interface