Talk: Countering Forensics Software by Baiting Them research

15:00-15:30 PDT Saturday | Aug 9^th 2025
DEF CON Creator Stage 2 (Room 232) | Las Vegas Convention Center
Adversary Tactics

There's been remarkably little discussion about how mobile forensic tools fare against adversarially modified environments, particularly in terms of forensic reliability. Tools (and investigators) often assume that target devices function as expected, with minimal scrutiny of whether that assumption holds. Our research demonstrates otherwise - sophisticated anti-forensic techniques placed within Android devices can silently compromise evidence, placing longstanding investigative and extraction methodologies at risk.

Our research addresses a blind spot in Android logical extraction workflows - namely, an assumption that once mobile forensic software overcome the hurdle of device access, the extraction is assumed to follow correctly. While forensics software excel at getting a foot in the door, from our actual tests they offer little against stealthy, second-layer countermeasures that can silently manipulate or destroy data post-access.

Detailed talk outline :

1. 1. The Big Picture: Why "First Stage" Access Isn't Enough

   Our work emphasizes that silently undermining evidence post-access is surprisingly feasible; investigators must adopt new strategies and validation checks to guard against these stealthy manipulations.

   1. Common Assumption in Mobile Forensics
      • Many forensic practitioners assume that once they've unlocked an Android device or bypassed its security (e.g., unlocking bootloaders, gaining root, or enabling USB debugging), they can reliably extract data without further interference.
      • This assumption underpins the workflow of a number of mainstream forensic software (Cellebrite UFED, Belkasoft X, Magnet Axiom, etc.), which prioritize device access as the primary hurdle.
   2. Reality Check: Second-Layer Countermeasures
      • Even after these software achieve first-stage access, adversaries can embed hidden "traps" or stealthy manipulations within the OS itself.
      • Investigators may see device contents, but data can be surreptitiously encrypted, altered, or deleted during the extraction process, possibly without any outward sign of tampering.
   3. Research Focus
      • We designed and tested second-layer anti-forensic measures that quietly target the extraction phase.
      • The goal is to show how traditional forensic workflows (like MTP pulls or mass ADB file acquisitions) become vulnerable even after the so-called "first stage" is defeated.
2. 2. Introduction & Rethinking Traditional Anti-Forensics

   This section contrasts classical, overt anti-forensics with our stealth-based alternative, explaining why stealth is increasingly critical in adversarial environments.

   1. Current Anti-Forensic Landscape
      • Conventional anti-forensic tactics on Android devices include (but is not limited to):
      • Disabling USB debugging entirely or disallowing it when certain conditions are detected.
      • Blocking ADB connections upon sensing forensic software or suspicious package installations.
      • Detecting package installations (especially known forensic agent apps) and then taking immediate obstructive measures (e.g., shutting down services).
   2. Why Traditional Methods Raise Red Flags
      • Overt actions (e.g., severing USB connections abruptly) instantly raise suspicion among investigators.
      • Once alerted, examiners may decide to switch to alternate or more advanced techniques, leading to enhanced scrutiny that can uncover additional subterfuge.
   3. Need for a Stealthier Alternative
      • Primary Goal: Let forensic examiners believe the device is functioning in a manner conducive to forensic extraction.
      • Delay or mask any interference until as close to the actual data acquisition, especially if it involves massive or high-value targets.
   4. Transition to Honey Token Methodology
      • Instead of traditional anti-forensics, we present an approach reliant on covert triggers that only spring into action under specific conditions (e.g., reading a particular file).
      • This approach reduces immediate red flags and preserves the illusion that all is normal, right until critical data acquisition events commence.
3. 3. Repurposing Honey Tokens: Concept & Implementation

   Honey tokens function as a stealth detection mechanism, culminating in well-timed sabotage that seamlessly blends into the OS environment.

   1. Honey tokens 101
      • Hidden "bait" files deliberately placed in the filesystem.
      • The moment these files are read or pulled by a forensic software, they trigger anti-forensic mechanisms.
      • Rationale: Single-file triggers blend seamlessly into the device's landscape, exploiting assumptions of "clean" or "neutral" filesystem structures.
   2. Why Use Honey Tokens?
      • Investigators typically do not suspect random benign files, hence stealth factor.
      • Even if the device has been "unlocked," honey tokens activate only when a tool attempts a mass acquisition (like through MTP or ADB pull), precisely at or close to the moment when real evidence is about to be copied.
   3. Technical Mechanism: inotify
      • The Linux kernel's inotify subsystem can watch for file operations; we leverage this in our honey tokens.
      • Once a honey token is accessed (read, opened, or even enumerated in some cases), an event is generated that can fire a script to e.g., encrypt, delete, or modify targeted data.
   4. Suitable File Types & Placement
      • Any file can be a token; photos, documents, or even configuration files.
      • Avoid using directories as inotify watchers on directories can yield countless false positives, making stealth triggers less controlled.
      • Strategic Locations:
      • External storage (commonly targeted by MTP scans).
      • Internal storage (can be accessed by rooted ADB pulls).
   5. Countermeasures Linked to Honey Tokens
      • Data Destruction: Scripted wiping of "crown jewel" files once a token is accessed, or factory resetting of device.
      • On-the-Fly Encryption: Rapid encryption of evidence, rendering it unreadable to examiners who started the pull.
      • More Complex Actions: Potential for real-time communication to external servers, alerting an adversary network, or performing "counter-attacks."
4. 4. Evaluating the New Approach Against Traditional Forensic Software

   Despite variations in approach, all tested forensic software tested remain susceptible to stealth sabotage, demonstrating that focusing on second-layer stealth is both practical and highly effective; this section shall incorporate developers' replies when we get them.

   1. Test Environment and Methodology
      • Devices and OS Modifications: Custom AOSP Android build with kernel and system changes (e.g., edits to init.rc, etc.) to enable honey tokens and corresponding file encryption anti-forensic measures.
      • Forensic Software Tested Against:
      • Belkasoft X
      • Magnet Axiom
      • Cellebrite UFED
      • Evaluation Criteria:
      • Whether the software's MTP-based file acquisitions inadvertently triggers the honey tokens (and consequently activate the anti-forensic measures).
      • How the software responded (or failed to respond) to mid-extraction sabotage (e.g., encrypted files).
      • Belkasoft X Findings
        • "Pull Everything" Strategy: MTP acquisition typically downloads all files, including benign-looking ones.
        • Honey Token Trigger: As soon as Belkasoft tries to retrieve the token, the system triggers encryption or data destruction.
        • Investigator's Perspective: Might see incomplete data or file corruption only after some portion has been pulled.
      • Magnet Axiom Findings
        • Similar Bulk Pull Logic: Also vulnerable to any token file in a targeted directory.
        • Observation: Software does not robustly differentiate or confirm file authenticity prior to mass acquisition.
      • Cellebrite UFED Findings
        • Cellebrite previews certain files (like images) before acquisition, and accidentally triggers the tokens way before actual MTP pull.
5. 5. Demonstration: Honey Tokens in Action

   A demonstration underscoring how straightforward it is to embed triggers in the OS that forensic practitioners can't easily detect or bypass.

   1. Context of Manual Acquisition
      • Some investigators prefer manual ADB pulls to target specific directories or files for a "finer" approach rather than utilizing a tool.
      • If honey tokens reside in any commonly pulled location, they can still trigger sabotage when that specific folder is pulled.
   2. Video / Live Demo - Manual ADB Pull
      • Setup: A device running our adversarially modified OS which has honey token deployment and management.
      • Sequence:
      1. Investigator initiates a "targeted" ADB pull of folder /Documents which contains sample "crown jewel" files within its subdirectories.
      2. Honey token hidden in /Documents get accessed.
      3. Consequently, the system immediately executes an encryption countermeasure against "crown jewel" files.
      4. Investigator sees encrypted data upon inspection.
   3. Video / Live Demo - Tests Against Forensic Software
      • With the permission of the forensic software developers whose software we tested our approach on, we will demonstrate how honey token anti-forensics works against their software; this is currently pending responsible disclosure with the software developers.
6. 6. Mitigating Honey Token Attacks: Defensive Strategies

   While these second-layer threats are hard to counter, there are strategic adaptations investigators can employ, though each has its own trade-offs.

   1. Selective vs. Bulk Acquisition
      • Idea: Perform a directory scan for file metadata (name, size, date) without opening files, then manually pick items to pull; selective acquisition means honey tokens are not immediately triggered.
      • Downside: Significantly increases the time and effort required, especially for large file systems; human decision-making can be susceptible to mistakes as well.
   2. Accelerated Acquisition to Beat Encryption
      • If the adversary's encryption routine is slow or resource-intensive, investigators might outpace the sabotage by pulling data faster than it can be encrypted.
      • Practical Hurdle: Requires tailored hardware setups (faster connections, optimized processes) and real-time monitoring to see if sabotage begins.
   3. Targeting Countermeasure Weak Spots
      • On-the-fly encryption of large files can strain CPU / memory, potentially exposing anomalies for the investigator to detect.
   4. Cold System Forensics
      • Power Down the Device: Minimizes or eliminates software-based sabotage vectors if the OS can't run; focus on physical extraction (if ever possible).
      • Major Caveat: Powers off potential ephemeral data (RAM, running processes) and might risk altering certain filesystem metadata.
   5. Evidence of Detective Mechanisms (Honey Tokens)
      • File Watch Patterns: Checking for unusual watchers (like inotify) within the device's process list, which could indicate active monitoring of benign files.
7. 7. Conclusion & Q&A
   1. Recap of Core Lessons
      • Gaining the "first stage" of access (bypassing lock screens, enabling ADB, etc.) does not guarantee safe or comprehensive data extraction.
      • Honey tokens illustrate how stealthy triggers can disrupt conventional forensic workflows.
      • Major forensic software remain vulnerable to silent sabotage, despite their strengths at initial access.
   2. Call to Action for Practitioners and Developers
      • Forensic practitioners: Incorporate verification steps post-access, watch for triggers, log inconsistencies, and consider more selective tactics.
      • Software developers: Implement detection measures or provide detailed logs that can identify suspicious file manipulations during acquisition.
   3. Open Forum
      • If time is available, address audience questions, e.g., on real-life implications, specialized use cases, or future expansions.
   4. Final Word
      • The research highlights a critical gap in the forensic process assumption. Defeating initial defenses does not automatically mean the device is safely yielding its secrets - be prepared for deeper adversarial tactics.