Countering Forensics Software by Baiting Them

Countering Forensics Software by Baiting Them

Speakers: Weihan Goh (Professor); Joseph Lim; Isaac Soon

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=nUh9GVYhjD8

Overview

This talk, presented by Professor Weihan Goh and his students Joseph Lim and Isaac Soon from Singapore, delves into a novel approach to anti-forensics in the mobile domain. Titled "Countering Forensics Software by Baiting Them," the presentation unveils a sophisticated methodology designed to silently manipulate or destroy data on an Android device while it is being extracted by mainstream forensic tools. The core innovation lies in deploying "honey tokens" as tripwires, which, when accessed by forensic software, trigger pre-configured anti-forensic payloads like data encryption or a factory reset.

The significance of this research cannot be overstated. It challenges the fundamental assumptions underpinning current mobile forensic workflows, where gaining initial device access is often considered the primary hurdle, with data extraction assumed to be a straightforward subsequent step. By demonstrating effective "second-layer countermeasures," the speakers highlight a critical vulnerability in the forensic process, forcing examiners to rethink their methodologies and the reliability of extracted evidence from potentially compromised environments. This work provides a crucial perspective from the adversary's viewpoint, pushing the boundaries of what's possible in digital self-defense.

Background

▶ Watch: Introduction to anti-forensic techniques against major tools (0:00)

Mobile forensics presents unique challenges compared to traditional computer forensics. While the latter often involves straightforward acquisition methods like plugging a USB drive into a write-blocker, mobile devices frequently require bypassing security measures to gain initial access before any data can be extracted. The typical mobile forensic workflow, as outlined by the speakers, involves gaining access (unlocking, bypassing security), extracting data (logical or physical), and then analyzing it. This workflow, adopted by popular tools like Cellebrite UFED, Magnet AXIOM, and Belkasoft, assumes that once access is gained, the extraction process is largely unhindered and yields reliable data.

However, this assumption overlooks the potential for "second-layer countermeasures" — a concept explored in this talk. The idea of weaponizing mobile devices against forensic tools is not entirely new; the speakers referenced Moxy Marlinspike's public statement threatening to "attack Cellebrite" if his Signal app was targeted. Furthermore, the concept of digital tripwires and anti-forensics has roots in earlier research, such as a 2011 paper by Professor Goh's team on creating systems that encrypt data unbeknownst to the analyst.

Conventional anti-forensic techniques in mobile environments typically involve overt actions like disabling USB debugging, monitoring for forensic software installations, blocking ADB connections, or killing forensic services. While effective in some scenarios, these methods are often obvious "red flags" to an experienced forensic examiner. Upon detecting such overt resistance, an examiner would likely switch to more advanced tactics, apply enhanced scrutiny, and potentially uncover the anti-forensic measures, ultimately still compromising the protected data. The critical flaw in these conventional approaches is their visibility, which fails to protect the data in the long run once the examiner adapts. The research presented here aims to overcome this by deploying silent, non-obvious countermeasures that operate stealthily in the background.

Key Findings

▶ Watch: Understanding the typical mobile forensics workflow and assumptions (2:00)

The central discovery of this research is the successful implementation of honey tokens as a silent, yet highly effective, anti-forensic mechanism against leading mobile forensic software. These honey tokens act as digital tripwires, designed to detect and respond to the broad, often indiscriminate, data acquisition strategies employed by forensic tools. The key findings include:

1. Silent Detection via Honey Tokens: The researchers developed "bait files" containing innocuous or "rubbish information" and strategically deployed them deep within the Android file system, often hidden within top-level directories like /documents or /pictures, or even within application-specific folders. These honey tokens are invisible to normal device users, ensuring they are not accidentally triggered.
2. inotify as the Trigger Mechanism: The system leverages inotify, a Linux kernel subsystem available in Android 6 and above (via Toybox), to monitor file system events. Specifically, it watches for file read events on the deployed honey tokens. When a forensic tool attempts to access or read these bait files during its data extraction process, inotify triggers a notification, signaling that a forensic examination is underway.
3. Dynamic Payload Activation: Upon detection, the system activates pre-defined anti-forensic payloads. The primary payloads demonstrated were:

• Data Encryption: Crucial "crown jewel" files (e.g., secrets.txt, secret_in_hidden.txt) are silently encrypted, rendering them unreadable and effectively unrecoverable by the forensic examiner.
• Factory Reset: A more extreme payload that wipes the entire device, destroying all evidence.

1. Effectiveness Against Mainstream Tools: The proof of concept demonstrated successful encryption of critical data against Cellebrite UFED, Belkasoft, and Magnet AXIOM. The technique proved particularly potent when these tools utilized MTP (Media Transfer Protocol) for bulk data acquisition, as MTP often involves traversing and reading directories where honey tokens are hidden.
2. Challenging Forensic Workflows: The research concludes that these "second layer countermeasures" can silently compromise evidence during extraction, necessitating a fundamental re-evaluation of long-standing forensic workflows. Gaining initial device access no longer guarantees reliable data acquisition, as the device itself can actively work against the forensic process.

Technical Deep Dive

▶ Watch: Identifying the blind spot: second-layer countermeasures (2:50)

The technical foundation of this anti-forensic system relies on a custom Android Open Source Project (AOSP) build, modified to host a custom system application. This application is responsible for deploying and monitoring the honey tokens, and subsequently executing the anti-forensic payloads.

At the heart of the detection mechanism is inotify. This Linux kernel subsystem provides a mechanism for monitoring file system events. In the Android userland, inotify is accessible via a command-line utility that is part of Toybox (included in Android 6 and above). The custom system application registers inotify watches on the specific honey token files and directories. It can monitor various events, but the critical ones for this application are:

• IN_OPEN: A file was opened.
• IN_ACCESS: A file was accessed (e.g., read).
• IN_CLOSE_NOWRITE: A file was closed, and no writes occurred.

When an inotify event corresponding to a read or access of a honey token is detected, it acts as the tripwire. The system then initiates the pre-configured anti-forensic payload.

Honey Token Implementation:

The honey tokens themselves are carefully crafted to blend into the file system and avoid accidental user interaction. They are typically:

• Hidden Files: Often named with a leading dot (e.g., .hidden_token.jpg) or placed within obscure subdirectories.
• Contextual Placement: For example, a honey token image file might be placed in the /pictures directory, or a secrets.txt in /documents.
• Programmatic Deployment: The system can deploy new honey tokens dynamically, for instance, when a new application is installed, mirroring the forensic tools' tendency to acquire data from newly installed apps. The talk showed examples of honey tokens deployed in pictures folders and even within Telegram directories. From a normal user's perspective, these files are not visible, ensuring the tripwire remains undisturbed until a forensic tool, which typically attempts to enumerate and read all files, accesses them.

Payload Execution:

Once inotify signals that a honey token has been accessed, the custom system application executes one of its anti-forensic payloads:

1. Data Encryption: This payload targets "crown jewel" files, such as secrets.txt or other sensitive user data like contacts and SMS messages. The talk demonstrated that secrets.txt was rendered unreadable after the encryption payload was triggered. While the specific encryption algorithm isn't detailed in the transcript, the effect is clear: the data becomes inaccessible.
2. Factory Reset: This is a more destructive payload, designed to wipe the entire device to its factory state, eradicating all user data and evidence. This is a powerful, albeit less subtle, countermeasure.

The choice of MTP (Media Transfer Protocol) as a primary target for these countermeasures is strategic. MTP is a common method used by forensic tools for logical extractions, particularly for accessing external storage and user-accessible files. Because MTP-based extractions often involve a comprehensive traversal of the file system, they are highly susceptible to triggering honey tokens placed in various directories. The "greed" of forensic tools to extract "everything" makes them vulnerable to this baiting strategy.

Demo / Proof of Concept

▶ Watch: Limitations of obvious and easily detectable anti-forensic methods (4:05)

The speakers presented three compelling video demonstrations, showcasing their anti-forensic system's effectiveness against industry-standard mobile forensic tools: Cellebrite UFED, Belkasoft, and Magnet AXIOM.

Cellebrite UFED

The first demonstration targeted Cellebrite UFED, a widely used mobile forensic solution.

1. Setup: Honey tokens were strategically placed as hidden files within top-level file system directories, including the /pictures directory. The "crown jewel" files, secrets.txt and secret_in_hidden.txt (located in a subfolder), were pre-populated with sensitive data.
2. Extraction Process: The Cellebrite UFED extraction was initiated using default settings. The process was observed to occur in distinct stages:

• Stage 1 (Call logs to Calendar): Cellebrite employs an agent that is sideloaded onto the device to directly access data types like contacts and SMS. During this stage, the honey tokens were not triggered, and these specific data types remained unencrypted.
• Stage 2 (Pictures to Archives): Crucially, during this stage, the Cellebrite software's overview screen was observed to open and read files within the /pictures directory. Because a honey token was placed there, this action immediately triggered the encryption payload. The encryption process for the crown jewel files began before the extraction for this stage was fully completed.
• Stage 3 (ADB Backup): The final stage involved an ADB backup to pull remaining data.

1. Results: Post-extraction analysis of the logical and backup folders revealed that the secrets.txt and secret_in_hidden.txt files were successfully encrypted and unreadable. The demonstration also highlighted that while initial extraction of contacts/SMS in Stage 1 might not show encryption (as the trigger hadn't occurred), any subsequent re-extraction or re-analysis of the device would find these data types encrypted, as the payload had already been activated.

Belkasoft

The second demonstration focused on Belkasoft Evidence Center.

1. Setup: Similar to the Cellebrite test, crown jewel files were prepared. The Belkasoft acquisition process was configured to use the MTP option to acquire all files from the system and external storage.
2. Extraction Process: Belkasoft began its extraction by traversing the top-level external storage directory (internal shared storage). During this initial scan, it downloaded one of the honey token files.
3. Results: This download immediately triggered the encryption countermeasure payload. By the time Belkasoft completed its extraction, the crown jewel files were found to be successfully encrypted, rendering them inaccessible to the forensic examiner.

Magnet AXIOM

The final demonstration targeted Magnet AXIOM.

1. Setup: In this scenario, a large file (balance.txt) was moved to the documents directory and renamed ignore.txt to act as a honey token. The purpose of using a large file was to slow down the extraction process, providing more time for the encryption payload to complete its work before the target data could be fully acquired.
2. Extraction Process: Magnet AXIOM's MTP extraction process was initiated. As AXIOM traversed the file system, it accessed the ignore.txt honey token.
3. Results: The encryption payload was triggered. Verification using ADB logcat showed a flurry of inotify events, confirming the activation of the file observer service and the ongoing encryption. Subsequent examination of the extracted data confirmed that the crown jewel files were encrypted. The use of a larger honey token file successfully bought enough time for the encryption process to complete, further demonstrating the adaptability of the anti-forensic strategy.

These demonstrations collectively showcased that the honey token approach, coupled with inotify and various payloads, constitutes a robust and stealthy anti-forensic capability against leading commercial tools, particularly when they rely on MTP for broad data acquisition.

Defensive Implications

▶ Watch: Introducing covert anti-forensics by baiting forensic tools (5:55)

The revelations from this talk pose significant challenges to the mobile forensics community and necessitate a re-evaluation of current practices. The primary defensive implications for forensic examiners and tool developers include:

1. Rethink Acquisition Strategies: Selective vs. Bulk Acquisition: The "greedy" approach of extracting "everything" from a device, while seemingly thorough, is precisely what makes forensic tools vulnerable to honey tokens. Defenders should move towards more selective acquisition methods, targeting only specific data types or locations known to be relevant to the case. This requires a deeper understanding of the device's file system structure and the specific anti-forensic techniques that might be deployed. However, the challenge lies in knowing what constitutes "selective" without prior knowledge of the anti-forensic mechanisms present.
2. Exploit Weaknesses in Anti-Forensic Mechanisms: Examiners need to understand the characteristics of potential anti-forensic payloads. For instance, if an anti-forensic technique relies on a large file to slow down extraction and gain time for encryption (as seen in the Magnet AXIOM demo), examiners could potentially detect unusually large, seemingly innocuous files in common directories. Identifying these anomalies could signal a compromised environment.
3. Consider Cold System Forensics: While increasingly difficult with modern, highly integrated devices, cold system forensics methods like chip-off or advanced bootloader exploits (if available) might become more critical. These techniques often bypass the active operating system, potentially neutralizing software-based anti-forensic measures like honey tokens and inotify monitoring. However, the speakers acknowledge that these methods are becoming more complex and less universally applicable.
4. "Know Your Tools": This is perhaps the most critical takeaway for forensic practitioners. The talk highlighted a significant gap: a lack of research into how mobile forensic tools behave in adversarially modified environments. Examiners often trust their tools implicitly, assuming they function as intended regardless of device state. It is imperative for forensic experts to:

• Test and Verify: Rigorously test their forensic tools against devices intentionally configured with anti-forensic measures. This "adversarial testing" will reveal vulnerabilities and limitations.
• Understand Tool Internals: Gain a deeper understanding of how their tools interact with the device's file system, which protocols they use (e.g., MTP, ADB), and at what stages they access different data types. This knowledge can inform more resilient acquisition strategies.
• Be Aware of Red Flags: While the presented anti-forensics are designed to be silent, examiners should remain vigilant for any unexpected behavior, errors, or inconsistencies during extraction that might indicate a compromised environment.

1. Rethink Forensic Workflows: The traditional workflow where "gaining device access is just the beginning" needs to be extended. The next step, "what happens during forensic extraction," can no longer be assumed to be a safe and unadulterated process. Workflows must incorporate checks for adversarial modifications and contingency plans for potentially compromised evidence.

In essence, the talk serves as a wake-up call, urging the forensic community to adapt to a new era where the target device itself can become an active participant in the anti-forensic battle, silently undermining evidence integrity.

Key Takeaways

• Honey tokens are effective tripwires: Strategically placed, hidden bait files can silently detect forensic tool activity.
• inotify enables stealthy detection: Leveraging the Linux kernel's inotify subsystem allows for real-time monitoring of file access events, triggering anti-forensic payloads without alerting the examiner.
• Mainstream tools are vulnerable: Cellebrite UFED, Belkasoft, and Magnet AXIOM were successfully baited, demonstrating a significant weakness in their MTP-based bulk acquisition methods.
• Second-layer countermeasures challenge traditional forensics: The ability to encrypt or destroy data during extraction fundamentally alters the reliability of evidence acquired from compromised devices.
• Forensic examiners must "know their tools": Understanding the internal workings and limitations of forensic software, and testing them against adversarial environments, is crucial for effective defense.
• Rethink acquisition strategies: Moving from indiscriminate bulk acquisition to more selective, targeted data extraction is essential to mitigate the risk of triggering anti-forensic measures.

About the Speaker(s)

The research presented was a collaborative effort led by Professor Weihan Goh, who teaches a digital forensics module at a university in Singapore. He describes himself as "basically the nobody" but is the driving force behind this academic work. The core intellectual contributions to the honey token development came from his students, Joseph Lim and Isaac Soon, who were instrumental in designing and implementing the anti-forensic system. Another student, Wilson Aloas, was also involved in the project. The entire team is based in Singapore, highlighting the global nature of cybersecurity research.