Masquerading

Appearance can suggest legitimacy without proving it

Masquerading makes an artifact or activity appear legitimate through names, locations, icons, metadata, or other presentation. The actor may imitate familiar software or expected administrative behavior. The purpose is to influence human or automated interpretation, but the underlying behavior still needs investigation.

A familiar name is weak evidence because names are often easy to choose. An unfamiliar name is also weak evidence because internal tools and new software may be legitimate. Evaluate provenance, actual path, content identity, permissions, and observed actions together.

A familiar-looking process runs from an unusual location

In a fictional endpoint case, a process resembles a common system component but executes from a user's temporary directory. The analyst checks the exact path and spelling, signature information, file hash, creation history, parent process, and behavior.

A legitimate portable utility could explain the location. The team compares the artifact with an approved source and the user's work. Avoid declaring maliciousness solely because a path differs from the most familiar installation.

Conversely, a plausible icon or description should not outweigh unexplained execution and network activity. Presentation metadata can be copied independently of the code's origin or purpose.

Verify identity through stronger evidence

Content hashes identify specific bytes, while valid signatures provide information under the relevant signing trust model. Neither alone establishes that the program's use was authorized in this context. Combine them with package provenance, deployment records, and the actual actions.

Compromise Host Software Binary concerns changed existing software, while Hide Artifacts concerns reduced visibility. A masquerading artifact can be visible and still misleading. Map the observed mechanism rather than automatically assigning every concealment-related technique.

Preserve the original filename, path, metadata, and relevant records before renaming or deletion where practical. Cleanup can remove the presentation details that explain why the activity was initially trusted.

Respond to the behavior behind the disguise

Contain unauthorized execution or access as justified, review how the artifact arrived, and investigate related changes. Removing a misleading filename does not address an abused account or a recurring launch mechanism.

Improve detection using more than a name match. Expected paths, provenance, parent-child context, and behavior can help distinguish legitimate use while avoiding brittle assumptions that attackers must retain one spelling.

For practice, compare an approved internal tool with a fictional executable imitating a system component. Identify the evidence that establishes origin and authorized purpose. Write a conclusion that separates misleading presentation from confirmed harmful actions. MITRE ATT&CK, Logs and telemetry, and Incident reporting and handover support that evidence-based description.

Related concepts

• Incident response