Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0355: Analytic 0355

Adversary renames LOLBINs or deploys binaries with spoofed file names, internal PE metadata, or misleading icons to appear legitimate. File creation is followed by execution or service registration inconsistent with known usage.

EnterpriseAN0355AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic matters because attackers may make malicious or misused Windows binaries look routine by renaming legitimate LOLBINs or using spoofed file names, PE metadata, or icons. For leaders, the practical risk is that security teams may trust familiar-looking executables or services unless they validate file identity, location, metadata, and post-creation behavior together.

Executive priority

Prioritize this as a Windows endpoint detection and response-readiness issue. The business decision is whether the organization can distinguish legitimate administrative tooling from lookalike binaries before they become persistent services or trusted operational processes. Leaders should ask whether SOC evidence includes file creation, execution, service registration, and file metadata, and whether analysts have baselines for known legitimate usage.

Technical view

For Windows SOC and IR teams, validate detection logic around newly created executables whose names, internal PE metadata, icons, paths, or service registrations do not align with expected legitimate usage. Because no official detection logic is provided, teams should build or review analytics that correlate file creation followed by execution or service registration, with emphasis on inconsistencies between file name, signer, path, PE metadata, and observed behavior.

Likely telemetry

  • Windows file creation events for executable files
  • Process execution telemetry including image path, command line, parent process, and hashes
  • Windows service creation or registration events
  • PE metadata such as original file name, product name, company name, version info, and icon characteristics
  • Code signing and certificate validation data

Detection direction

  • Correlate executable file creation with subsequent process execution or service registration rather than relying on file name alone.
  • Compare displayed file name and path against PE internal metadata, digital signature, hash reputation, and expected Windows or application locations.
  • Tune carefully for legitimate software installers, updaters, and administrative tools that may create and run binaries or services during normal operations.
  • Review blind spots where endpoint tools do not capture PE metadata, service creation, or short-lived process execution.
  • Because no ATT&CK tactic or relationship context is supplied, avoid assuming a specific campaign phase; treat this as a behavior-level analytic requiring local baselining.

Mitigation priorities

  • Ensure Windows endpoint logging captures file creation, process execution, service registration, code signing status, and relevant PE metadata.
  • Maintain baselines for legitimate system binaries, administrative tools, approved service paths, and expected signer/path combinations.
  • Use application control, allowlisting, or policy-based execution controls where operationally feasible to reduce execution of suspicious lookalike binaries.
  • Strengthen SOC triage playbooks so analysts verify identity indicators beyond the executable name, including path, signature, hash, metadata, and service configuration.
  • Periodically test detection content with benign simulations of renamed or metadata-inconsistent binaries to confirm telemetry and alert fidelity.
Analyst notes and limits

The supplied object is a detection analytic, AN0355, for Windows. It describes adversaries renaming LOLBINs or deploying binaries with spoofed names, PE metadata, or icons, followed by execution or service registration inconsistent with known usage. No relationship context, tactic mapping, or official detection text was supplied, so the take focuses on defensible validation themes rather than specific rule syntax.

This assessment is limited to the provided ATT&CK fields and external reference. It does not establish active exploitation, attribution, prevalence, business impact, or guaranteed detection coverage. Local endpoint telemetry, baselines, and service inventory are required to determine practical coverage and false-positive rates.

Official MITRE ATT&CK definition

Analytic 0355

Adversary renames LOLBINs or deploys binaries with spoofed file names, internal PE metadata, or misleading icons to appear legitimate. File creation is followed by execution or service registration inconsistent with known usage.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
d95851ab53b453eb...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d95851ab53b4…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0355
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.