Post

Lockdown - Remediating Retrieval, Logging, and Tenant Isolation in RAG Systems

Capstone defensive audit and remediation walkthrough of the Lockdown room on TryHackMe, diagnosing and repairing three critical vulnerabilities in Bastion AI across metadata pre-filtering, log sanitization, and tenant isolation to reconstruct the complete flag.

Lockdown - Remediating Retrieval, Logging, and Tenant Isolation in RAG Systems

Overview

Most security assessments focus strictly on exploitation: discovering an unintended prompt injection, bypassing guardrails, or extracting confidential records. However, enterprise security engineering requires the inverse capability: diagnosing root-cause architectural flaws and prescribing exact, deterministic controls that eliminate vulnerabilities without degrading operational utility.

This room, Lockdown, serves as the final capstone challenge of Module 5 (Data Poisoning) and the culminating challenge of TryHackMe’s entire AI Security Learning Path. In this scenario, we operate as security engineers at Meridian Security Group auditing Bastion, an internal AI assistant deployed to answer employee policy and operational inquiries.

A baseline audit identified three open vulnerabilities in Bastion’s RAG architecture. Our objective is to confirm each vulnerability using diagnostic commands (SHOW LOGS, QUERY AS: [name], STATUS), identify the root cause, and prescribe the precise remediation control. Each accurate control triggers a configuration patch and reveals a flag fragment, combining to form the complete operational flag.

flowchart TD
    subgraph Bastion RAG System
        AUDIT[Security Engineer / Auditor] -->|Diagnostic Commands| BASTION[Bastion AI Assistant]
        BASTION --> VULN1[Vulnerability 1: Over-Permissive Retrieval]
        BASTION --> VULN2[Vulnerability 2: Plaintext Observability Logs]
        BASTION --> VULN3[Vulnerability 3: Missing Tenant / User Isolation]
    end

    subgraph Prescribed Remediations
        VULN1 -->|Control: Metadata Pre-Filtering| FIX1[Flag Fragment 1: THM{l0ck_]
        VULN2 -->|Control: Log Redaction| FIX2[Flag Fragment 2: d0wn_]
        VULN3 -->|Control: Strict Tenant Isolation| FIX3[Flag Fragment 3: s3cur3d}]
    end

    subgraph Assembly
        FIX1 --> FULL[Complete Flag: THM{l0ck_d0wn_s3cur3d}]
        FIX2 --> FULL
        FIX3 --> FULL
    end

    style VULN1 fill:#ffcdd2,stroke:#333
    style VULN2 fill:#ffcdd2,stroke:#333
    style VULN3 fill:#ffcdd2,stroke:#333
    style FULL fill:#d4edda,stroke:#333

1. Diagnostic Interface & Methodology

Bastion exposes an administrative chat console equipped with specialized diagnostic commands:

  • SHOW LOGS: Dumps backend retrieval logs, showing the raw document chunks, prompt context, and classification tags recorded during recent queries.
  • QUERY AS: [name]: Simulates query execution from the perspective of an arbitrary employee or tenant, testing whether identity verification and data segmentation are enforced.
  • STATUS: Reports the current security posture, showing which vulnerabilities remain open and displaying accumulated flag fragments.

To remediate a vulnerability, we must submit a clear, precise description of the required security control. Generic or vague proposals (e.g., “improve security” or “add a filter”) are rejected by Bastion’s verification engine.


2. Vulnerability 1: Over-Permissive Data Retrieval

Confirmation & Diagnosis

We begin by testing Bastion’s retrieval scope using general and restricted policy questions:

  • Querying for basic operational documents returns normal results.
  • Querying for sensitive company files (such as executive memos or unreleased financial projections) causes Bastion to pull and disclose confidential document chunks directly to an unauthenticated requester.

Root Cause Analysis

The retrieval layer performs an unconstrained similarity search across the entire vector index. Because vector databases measure geometric distance rather than clearance, sensitive chunks that share vocabulary with the query achieve high cosine similarity scores and are injected into the context window. No filtering occurs before the search is executed.

Remediation Control

To resolve this flaw, the retrieval pipeline must restrict the candidate document set before computing vector similarity.

  • Prescribed Control: Metadata pre-filtering (or Implement metadata pre-filtering at retrieval time).
  • Engine Reaction: Bastion accepts the control, updates its vector query pipeline to append mandatory metadata constraints before ranking, and outputs the first flag fragment:
    1
    
    Flag Fragment 1: THM{l0ck_
    

3. Vulnerability 2: Plaintext Observability & Logging Exposure

Confirmation & Diagnosis

We execute the diagnostic logging inspection command:

1
SHOW LOGS

The output reveals that Bastion’s logging facility captures:

  1. The raw user input string.
  2. The full text of all retrieved document chunks (including [CONFIDENTIAL] blocks).
  3. The assembled augmented prompt.
  4. The generated completion.

Root Cause Analysis

To facilitate developer debugging and monitor model quality, the engineering team enabled full-payload logging. However, the centralized logging system is accessible across DevOps and internal operational teams who do not possess authorization to view raw confidential documents. The logging layer effectively created an unencrypted, searchable secondary store of protected enterprise data.

Remediation Control

Logging architectures must adhere to data minimization principles. Storing raw document text in logs violates confidentiality boundaries.

  • Prescribed Control: Log redaction (or Logging redaction / Log document identifiers instead of raw content).
  • Engine Reaction: Bastion modifies its telemetry pipeline to record only document IDs, execution latency, and token counts, stripping raw chunk text from observability streams. It outputs the second flag fragment:
    1
    
    Flag Fragment 2: d0wn_
    

4. Vulnerability 3: Missing Tenant and User-Level Isolation

Confirmation & Diagnosis

We evaluate tenant and user boundary enforcement using the impersonation diagnostic command:

1
2
QUERY AS: Alice
QUERY AS: Bob

We issue queries requesting personal HR files, disciplinary records, and private workspace notes. Bastion willingly executes the queries across user boundaries without validating whether the caller is actually Alice or Bob, returning private files from one user directly into another user’s session.

Root Cause Analysis

Bastion treats the caller identity as an arbitrary text parameter without validating session tokens or cryptographically signed identity assertions. Furthermore, all user data resides in a single flat vector namespace where documents from different users are intermingled.

Remediation Control

User-level and multi-tenant access control requires establishing non-bypassable boundaries at both the identity and data storage layers.

  • Prescribed Control: Strict tenant isolation (or Enforce tenant isolation in the vector database).
  • Engine Reaction: Bastion enforces cryptographic session validation and partitions the vector database into isolated per-user/per-tenant namespaces, blocking cross-user retrieval. It outputs the final flag fragment:
    1
    
    Flag Fragment 3: s3cur3d}
    

5. Architectural Transformation: Before vs. After

flowchart TD
    subgraph Insecure Architecture (Before Audit)
        Q1[User Query] --> S1[Global Unfiltered Similarity Search]
        S1 --> L1[Plaintext Full Context Logging]
        S1 --> C1[Shared Context Assembly]
        C1 --> GEN1[LLM Generation]
        Note1[Flaws: No Metadata Filter, Plaintext Logs, No Tenant Isolation]
    end

    subgraph Hardened Architecture (Remediated)
        Q2[Authenticated User Query] --> AUTH[Identity Verification Gate]
        AUTH --> T1[Namespace / Tenant Selection]
        T1 --> F1[Pre-Query Metadata Allowlist Filter]
        F1 --> S2[Restricted Vector Search]
        S2 --> L2[Sanitized Telemetry Logging<br>Document IDs & Hashes Only]
        S2 --> C2[Sanitized Context Assembly]
        C2 --> GEN2[LLM Generation]
    end

    style Note1 fill:#ffcdd2,stroke:#333
    style Hardened Architecture (Remediated) fill:#e8f5e9,stroke:#333

6. Flag Reconstruction

Combining the three recovered fragments:

  1. Fragment 1 (Data Retrieval): THM{l0ck_
  2. Fragment 2 (Logging): d0wn_
  3. Fragment 3 (Tenant Isolation): s3cur3d}
1
THM{l0ck_d0wn_s3cur3d}

Summary of Questions, Answers, and Flags

TaskQuestionAnswer / Flag
Task 1What is the first flag fragment after fixing the data retrieval vulnerability?THM{l0ck_
Task 1What is the second flag fragment after fixing the logging vulnerability?d0wn_
Task 1What is the third flag fragment after securing user-level access?s3cur3d}
Task 1 (Full)Complete reconstructed challenge flagTHM{l0ck_d0wn_s3cur3d}

You can find me online at:

My signature image

This post is licensed under CC BY 4.0 by the author.