T1151 · threatengine.sh

Home/ATT&CK Technique/Space after Filename

ATT&CK Technique

Space after Filename

T1151 · stealth, execution

▤ Generate a SIEM detection for T1151 ◈ Deployable detections for T1151 ⚠ CVEs mapped to T1151 ♛ Hunt package for T1151

Adversaries can hide a program's true filetype by changing the extension of a file. With certain file types (specifically this does not work with .app extensions), appending a space to the end of a filename will change how the file is processed by the operating system. For example, if there is a Mach-O executable file called evil.bin, when it is double clicked by a user, it will launch Terminal.app and execute.

If this file is renamed to evil.txt, then when double clicked by a user, it will launch with the default text editing application (not executing the binary). However, if the file is renamed to "evil.txt " (note the space at the end), then when double clicked by a user, the true file type is determined by the OS and handled appropriately and the binary will be executed. Adversaries can use this feature to trick users into double clicking benign-looking files of any format and ultimately executing something malicious.

LinuxmacOS

▸ How to use this page - the detection-engineering loop

Attackers have goals (tactics - “get credentials”, “move laterally”) and techniques are the concrete methods they use to reach them. This page is one method - T1151 - broken into everything you need to catch it.

The loop this page is built for (this is the job):

Understand the behaviour - read the description and the Atomic Tests to see exactly what the attacker does on a host or network.
Find the telemetry - what data source would reveal it (process creation, registry, network flow, auth logs). Detection Coverage shows which surfaces already have a rule and which are blind.
Get or write the detection - adapt ready logic (CAR Analytics, SIEM Detections, Falco, or Sigma via Generate a SIEM detection), or author your own.
Test it - run an Atomic Test in a lab and confirm your rule actually fires. A detection you have not tested is a hope, not coverage.
Deploy and tune - push it, then watch for false positives and adjust.

What each panel is for:

Atomic Testssafely reproduce the technique in a lab to validate that a detection fires. Detection Coveragewhich detection surfaces have a rule for this technique; none is a blind spot to close, or simply not applicable (YARA matches files, not network behaviour). CAR / SIEM / Falcoready-made detection logic (Splunk SPL, Elastic EQL, Sentinel KQL, Falco) you adapt to your own SIEM. Mitigationsreduce exposure so the technique is harder to use at all - prevent, not just detect. Actors / Attributionwho actually uses this, so you prioritise by your own threat model. Attack Path / LOTLwhat attackers do before and after this step, and the legitimate tools they abuse to do it.

Where this fits: you usually arrive here from a CVE (“which techniques does it enable”) and leave with a tested detection deployed. The buttons above jump straight to building one, the deployable rules, the CVEs that use T1151, and a hunt package.

◈

Detection Coverage

0/9 layers

Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).

Behavioral / log (Sigma) none

Analytics (MITRE CAR) none

Runtime / container (Falco) none

File / malware (YARA) none

Network (Suricata/Snort) none

Vuln scan (Nuclei) none

SIEM (Splunk ESCU) none

SIEM (Elastic) none

SIEM (Azure Sentinel) none

External lookups - second-class, for what we don’t hold ourselves

MITRE ATT&CK Atomic Red Team car (MITRE)