Marker File Mutex Gating

A lightweight runtime gating mechanism: the dropper checks for the existence of a specific file (typically under %appdata% or %TEMP%). If present, the gated payload branch is skipped. If absent, the file is created and the payload proceeds. This serves as a poor-man's mutex — preventing redundant re-execution of the same payload branch on subsequent runs, and potentially acting as a primitive anti-sandbox signal (sandbox environments that snapshot between runs may not persist the marker).

Detection / Fingerprint

• Calls to ExpandEnvironmentStringsW + PathCombineW + PathFileExistsW + CreateFileW (CREATE_ALWAYS) in sequence.
• Hardcoded marker filenames in .rdata (e.g. d3333333333333333333.txt, f3f3f3d3d.txt).
• No named mutex (CreateMutexW) — uses filesystem objects instead.

Observed In

• phorpiex campaign droppers ^[/intel/analyses/025f57988953e3d23e1657a9af5610887e57c5390a82f73b4b2b99c30eef3b70.html] ^[/intel/analyses/6b8527a7f761e8a5489b81ea8a79cbbbd9c09485b9b5d7c28cd892ef66599339.html]

Related Techniques

• mutex-single-instance — the more common CreateMutexW / CreateEventW approach
• gettickcount-anti-emulation-loop — another primitive anti-sandbox / anti-emulation technique observed in the same campaign