File Metadata

A subject uses files with canary tokens as a tripwire mechanism to detect the presence of security personnel or investigation activities within a compromised environment. This method involves strategically placing files embedded with special identifiers (canary tokens) that trigger alerts when accessed. For example:

The subject creates files containing canary tokens—unique identifiers that generate an alert when they are accessed, opened, or modified. These files can appear as regular documents, logs, configurations, or other items that might attract the attention of an investigator during a security response.

The subject strategically places these files in various locations within the environment:

• Endpoints: Files with canary tokens are stored in directories where digital forensics or malware analysis is likely to occur, such as system logs, user data directories, or registry entries.
• Cloud Storage: The files are uploaded to cloud storage buckets, virtual machines, or application databases where security teams might search for indicators of compromise.
• Network Shares: Shared drives and network locations where forensic investigators or security tools may perform scans.

Once in place, the canary token within each file serves as a silent tripwire. The token monitors for access and automatically triggers an alert if an action is detected:

• Access Detection: If a security tool, administrator, or investigator attempts to open, modify, or copy the file, the embedded canary token sends an alert to an external server controlled by the subject.
• Network Traffic: The token can initiate an outbound network request (e.g., HTTP, DNS) to a specified location, notifying the subject of the exact time and environment where the access occurred.
• Behavior Analysis: The subject might include multiple canary files, each with unique tokens, to identify the pattern of investigation, such as the sequence of directories accessed or specific file types of interest to the security team.

Upon receiving an alert from a triggered canary token, the subject can take immediate steps to evade detection:

• Alert the Subject: The canary token sends a covert signal to the subject's designated server or communication channel, notifying them of the potential investigation.
• Halt Malicious Activity: The subject can use this warning to suspend ongoing malicious actions, such as data exfiltration or command-and-control communications, to avoid further detection.
• Clean Up Evidence: Scripts can be triggered to delete or alter logs, remove incriminating files, or revert system configurations to their original state, complicating any forensic investigation.
• Feign Normalcy: The subject can restore or disguise compromised systems to appear as though nothing suspicious has occurred, minimizing signs of tampering.

By using files with canary tokens as tripwires, a subject can gain early warning of investigative actions and respond quickly to avoid exposure. This tactic allows them to outmaneuver standard security investigations by leveraging silent alerts that inform them of potential security team activity.

A subject embeds data within image files to hide sensitive content and exfiltrate it, in a way that conceals both the data and the act of exfiltration. Unlike encryption alone, this attempts to hide the existence of the data.

Trade-offs

• LSB and EOF: High capacity, low complexity, fragile to inspection
• Transform and Edge-based: Higher stealth, lower capacity, more resilient
• Appended EOF: Minimal technical skill required, common in low-effort exfiltration attempts

A subject embeds data within an audio file or audio stream so that the concealed information is carried inside apparently legitimate sound content. The audio may continue to play normally, while modifications to the underlying samples, frequency components, timing, phase, or file structure contain a hidden payload.

Audio steganography may be used to conceal sensitive organizational data within music, voice recordings, podcasts, meeting recordings, sound effects, or other audio content before the file is transferred through an approved or commonly used communication channel. The subject may select audio because normal variations in sound, background noise, and compression can make small alterations difficult to identify through ordinary review.

Methods may include modifying the least significant bits of audio samples, altering phase or frequency characteristics, inserting information into low-audibility ranges, using echo-based encoding, or appending data within fields not required for normal playback. The concealed payload may also be encrypted before embedding, preventing recovery of its contents even where investigators identify that steganography has been used.

A subject embeds data within a video file or video stream to conceal sensitive information inside apparently legitimate visual or audiovisual content.

Video files provide multiple locations for hidden data, including individual frames, color values, compression coefficients, motion data, audio tracks, subtitles, metadata, and unused container structures. A subject may distribute a payload across many frames or components, reducing the amount of alteration applied to any single part of the file.

The resulting video may appear and play normally while carrying documents, source code, credentials, records, archives, or other organizational data. The subject may transfer the video through email, cloud storage, messaging platforms, or media-sharing services where large audiovisual files are expected.

A subject conceals information within apparently ordinary written text by manipulating characters, spacing, formatting, language patterns, or other textual features that are unlikely to attract attention during normal reading.

The visible content may appear to be a legitimate email, document, chat message, report, source-code comment, or other written communication. Hidden information may be encoded through additional spaces or tabs, capitalization, punctuation, selected words, spelling variations, character placement, font changes, Unicode substitutions, zero-width characters, or bidirectional control characters.

Text steganography may be used to communicate small quantities of sensitive information, instructions, identifiers, authentication material, or encoded content without creating an obvious attachment or visible block of ciphertext.

A subject conceals data within a business document by using content, objects, fields, formatting, or internal structures that are not visible during ordinary viewing.

The carrier may be a word-processing document, spreadsheet, presentation, Portable Document Format file, or another document type routinely used by the organization. The document may open and display expected content while containing hidden text, files, archives, scripts, worksheets, comments, embedded objects, metadata, or other concealed material.

Methods may include white text on a white background, extremely small font sizes, content positioned outside the visible page, hidden spreadsheet rows or worksheets, concealed presentation objects, embedded files, unused form fields, custom metadata, document layers, or internal package relationships.

A subject conceals data within unused, ignored, optional, or non-rendered areas of a file or container so that the carrier continues to function normally while the hidden payload remains outside the content presented to the viewer.

The technique may use padding, reserved fields, unused headers, slack areas, archive comments, trailing data, application-specific metadata, or other structures retained during transfer but not normally displayed or processed. Examples include placing data after the logical end of a file, storing content in unused container fields, or exploiting differences between how applications and security tools interpret the same format.

This behavior may frustrate investigation because the visible content appears benign and the concealed data may only be identified through structural parsing, hexadecimal examination, file carving, or validation against the relevant file-format specification.

A subject intentionally alters host-based log records to conceal, misattribute, or misrepresent activity conducted on an endpoint, server, or other operating system.

The subject may change timestamps, account names, event identifiers, source addresses, command details, or action outcomes within Windows Event Logs, Linux system or audit logs, macOS logs, security-agent logs, or other locally stored records. Modification may be performed using administrative tools, scripts, third-party log scrubbers, or direct access to .evtx, .log, or other log files.

Investigators should compare local records with centrally forwarded logs, Endpoint Detection and Response (EDR) telemetry, process execution records, file metadata, and File Integrity Monitoring (FIM) events. This Sub-section applies where log content is altered but the record or log remains present.

A subject clears, truncates, redirects, or suppresses Z shell (Zsh) command history to prevent executed commands from being reviewed. The subject may delete or truncate the history file, clear commands held within the current session, change or unset the HISTFILE parameter, reduce the number of commands retained through SAVEHIST, redirect history to a non-persistent location, or modify shell startup files to prevent future commands from being written.

The Zsh history file is commonly stored as .zsh_history within the subject’s home directory, although its location is determined by the configured HISTFILE parameter. Investigators should examine the presence, size, timestamps, and contents of the history file; changes to .zshrc and other shell configuration files; macOS File System Events; and process or endpoint telemetry showing commands that do not appear in the surviving history.