1. Introduction: When Malicious Activity Looks Legitimate

A SOC analyst receives an alert for suspicious PowerShell execution on a Windows endpoint. The command uses a legitimate system utility, runs under a valid user account, and produces no immediate antivirus detection.

At first glance, the activity may appear routine.

A closer investigation reveals that the script was launched by an unexpected parent process, accessed a suspicious external destination, and was followed by an attempt to modify security settings.

The individual events may not tell the complete story. Together, however, they suggest an attempt to avoid detection while carrying out malicious activity.

This is the challenge of defence evasion: threat actors do not always need to develop entirely new tools. They may exploit trusted system functionality, abuse legitimate permissions, or manipulate the evidence security teams rely on.

Understanding these techniques helps analysts recognise suspicious behaviour before an attack progresses further.

2. What Is Defence Evasion?

In cybersecurity, defence evasion describes activity intended to avoid or interfere with security controls, detection mechanisms, or investigative visibility.

In the MITRE ATT&CK framework, Defence Evasion is represented by tactic TA0005.

It is important to distinguish a tactic from a technique:

• Tactic: The attacker's objective, such as avoiding detection.

• Technique: The method used to pursue that objective, such as impairing security tools or modifying files to conceal activity.

• Procedure: The specific way a threat actor implements a technique in a particular attack.

Defence evasion can occur at multiple stages of an intrusion. An attacker may attempt to bypass detection during initial execution, conceal activity while exploring a network, or interfere with monitoring before deploying a final payload.

Not every technique is malware-specific. Some involve legitimate administrative tools or configuration changes that become suspicious because of their context.

3. Abuse of Legitimate System Tools

One common approach is to use trusted tools already available on a compromised system. This behaviour is often associated with living off the land techniques.

On Windows, built-in interpreters and utilities can support legitimate administration, scripting, software installation, and troubleshooting. Threat actors may abuse the same capabilities to execute commands or perform actions without introducing an obviously malicious executable.

Examples include:

• PowerShell used to execute unexpected scripts.

• Windows Management Instrumentation (WMI) used for unauthorised execution or management activity.

• Command-line utilities used to retrieve files or launch processes.

• Legitimate system utilities used in unusual combinations or from unexpected parent processes.

What should a SOC analyst investigate?

Consider a hypothetical process chain:

WINWORD.EXE → powershell.exe → suspicious_child_process.exe

The chain suggests that Microsoft Word launched PowerShell, which subsequently launched another process. This is not proof of compromise, but it is a useful starting point.

An analyst should examine:

• The parent and child processes.

• The complete command-line arguments.

• The initiating user and logon session.

• Script and file activity around the same timestamp.

• Related network connections.

• Whether the activity matches normal behaviour for that application and user.

MITRE ATT&CK mapping: PowerShell (T1059.001), Windows Management Instrumentation (T1047), and System Binary Proxy Execution (T1218) may be relevant, depending on the observed behaviour.

4. Disabling or Impairing Security Tools

Threat actors may attempt to weaken endpoint protection or interfere with security monitoring. Their objective may be to create an opportunity for additional activity to proceed with a lower chance of detection.

Potential behaviours include attempts to disable antivirus protection, alter security configurations, stop security-related services, or tamper with endpoint detection components.

Other activity may target logging and monitoring rather than antivirus protection directly.

Example investigation

An endpoint generates the following sequence of alerts:

1. An unusual script executes under a user account.

2. A process attempts to change security-related settings.

3. A security service reports an unexpected state change.

4. Additional suspicious processes run shortly afterward.

The sequence warrants investigation as a possible defence-evasion attempt.

The analyst should establish whether the configuration change succeeded, which process initiated it, what privileges were used, and whether the security product recorded any loss of protection.

A command attempting to disable protection is not equivalent to a successful disablement. Analysts should distinguish between attempted interference, confirmed configuration changes, and actual loss of monitoring.

MITRE ATT&CK mapping: Impair Defenses (T1562) is the relevant technique family. The specific sub-technique depends on what was targeted, such as antivirus protection or logging.

5. Obfuscation and Concealment

Obfuscation changes how code or commands appear without necessarily changing their intended behaviour. Threat actors may use it to make suspicious activity harder to understand, inspect, or detect using simple signatures.

Examples include:

• Encoded or heavily transformed command strings.

• Scripts split across multiple variables or operations.

• Unusual character substitutions.

• Nested script interpreters.

• Renamed files intended to resemble legitimate components.

Obfuscation is not inherently malicious. Software developers and administrators also use encoding and transformation for legitimate purposes.

Investigation approach

When a suspicious command appears encoded or difficult to interpret, analysts should preserve the original command line and identify the process that executed it.

Where authorised and safe, the content can be decoded or deobfuscated in a controlled analysis environment. Investigators should then assess the resulting behaviour, including file access, process creation, registry changes, and network activity.

The goal is to understand what the code does rather than classify it as malicious solely because it is difficult to read.

MITRE ATT&CK mapping: Obfuscated Files or Information (T1027).

6. Process Injection and Memory-Based Activity

Some threats attempt to execute code within another process or manipulate process memory. These techniques can complicate investigations because the visible process may be a legitimate application rather than a clearly malicious executable.

Process injection can be used to execute code in the context of another process, while other memory-related techniques may attempt to hide or alter execution.

Why it matters

Traditional investigations that focus only on files written to disk may miss important evidence. Some malicious activity may occur primarily in memory, while supporting artefacts remain limited or short-lived.

Analysts should look for:

• EDR detections involving suspicious memory operations.

• Unexpected relationships between processes.

• Unusual access to another process's memory.

• Behaviour inconsistent with the apparent purpose of an application.

• Related module loads, thread activity, or follow-on execution where telemetry supports those observations.

These indicators require careful interpretation. Debuggers, security products, accessibility tools, and other legitimate software can also interact with process memory.

MITRE ATT&CK mapping: Process Injection (T1055). The applicable sub-technique depends on the specific behaviour observed.

7. Masquerading and File Name Manipulation

Threat actors may attempt to make malicious files resemble legitimate applications, operating-system components, or trusted software.

A file might use a familiar name while being stored in an unusual directory. Another may imitate a legitimate application icon or use a misleading extension.

For example, an executable named similarly to a Windows component may appear in a user-writable temporary directory rather than its expected system location.

Investigation approach

File names alone are weak evidence. Analysts should examine:

• The complete file path.

• Digital-signature status and signer information.

• File hash and metadata.

• File creation and modification timestamps.

• Parent process and execution history.

• Whether the file is expected on that endpoint.

• Related detections and network activity.

A legitimate-looking name does not establish legitimacy, and an unsigned file is not automatically malicious.

MITRE ATT&CK mapping: Masquerading (T1036).

8. Log Tampering and Evidence Removal

Security logs are essential for reconstructing an incident. If logs are deleted, modified, or prevented from recording activity, investigators may lose visibility into important parts of an attack.

Threat actors may attempt to clear operating-system event logs, alter logging configurations, or interfere with telemetry collection.

This can affect both immediate detection and later forensic analysis.

What should analysts look for?

Potential indicators include:

• Unexpected event-log clearing activity.

• Abrupt gaps in telemetry.

• Logging configuration changes that lack an approved change record.

• Security monitoring services stopping unexpectedly.

• Differences between endpoint, central SIEM, and other independent records.

A gap in logging is not proof of tampering. It can also result from collection failures, retention policies, system outages, or misconfiguration.

Investigators should compare independent data sources and establish whether the gap coincides with other suspicious events.

MITRE ATT&CK mapping: Indicator Removal (T1070), including Clear Windows Event Logs (T1070.001) when that behaviour is supported by evidence.

9. Registry and Configuration Manipulation

The Windows registry stores system and application configuration. Threat actors may modify registry values to support execution, persistence, or security-control interference.

For example, a registry modification may establish a startup mechanism or change a security-related setting.

Registry changes are common during normal software installation and system administration, so context is essential.

Investigation approach

Analysts should identify:

1. The exact registry key and value that changed.

2. The previous and new values, if available.

3. The process and account responsible for the modification.

4. The timestamp and surrounding process activity.

5. Whether the change matches an approved application or administrative task.

6. Whether the modified setting was subsequently used.

Not every registry modification is defence evasion. A change may instead support persistence or another objective. ATT&CK mapping should reflect the behaviour and purpose supported by the evidence.

10. Manipulating Cloud and Identity Security Controls

Defence evasion is not limited to endpoints. In cloud and identity environments, attackers may attempt to alter logging, modify security policies, weaken monitoring, or interfere with controls that would otherwise expose their activity.

Potential areas of investigation include:

• Unexpected changes to audit or diagnostic settings.

• Attempts to disable or alter security monitoring.

• Unusual identity-policy modifications.

• Changes to permissions that reduce oversight or enable further actions.

• Deletion or modification of logs and security-related resources.

Example: suspicious cloud logging changes

A cloud audit alert identifies an API call that modifies a logging configuration. The activity originates from a valid administrative identity, but the change was not expected.

A SOC analyst should examine the actor's authentication history, role assignments, source IP, API sequence, change approvals, and subsequent actions. The analyst should also confirm whether logging was actually reduced or disabled and whether other data sources retained the events.

A valid cloud identity does not guarantee that an action is legitimate. Conversely, an unusual configuration change may be authorised maintenance.

The investigation must establish both the technical outcome and the operational context.

11. A Practical SOC Investigation Workflow

When investigating suspected defence evasion, analysts should correlate related events and build a timeline rather than rely on a single detection.

Step 1: Validate the alert

Identify the affected asset, user, process, alert reason, timestamp, and security control involved. Confirm whether the alert represents attempted behaviour or a verified change.

Step 2: Reconstruct process activity

Review parent-child relationships, command lines, process identities, and nearby file or registry operations. Determine which process initiated the suspicious action.

Step 3: Verify the security-control state

If an alert suggests that protection was disabled or logging was modified, establish whether the change succeeded and what visibility was affected.

Step 4: Correlate independent telemetry

Review EDR, Windows event logs, SIEM records, identity logs, cloud audit trails, and network data as relevant. Look for evidence that confirms or contradicts the suspected sequence.

Step 5: Establish intent and context

Check change-management records, administrative activity, expected application behaviour, and known software updates. Avoid declaring malicious intent based only on the use of a legitimate tool.

Step 6: Assess the wider incident

Search for related process activity, file hashes, persistence mechanisms, security configuration changes, and suspicious authentication or network events across other systems.

Step 7: Contain and remediate

Follow incident-response procedures. Depending on the confirmed risk, actions may include isolating an endpoint, restoring security settings, revoking compromised credentials, blocking confirmed malicious infrastructure, and preserving forensic evidence.

Step 8: Improve detection

Document the behaviour and identify opportunities for new analytics, correlation rules, or telemetry improvements. Tune detections to reduce false positives without creating visibility gaps.

12. Detection Opportunities for SOC Teams

BehaviourUseful telemetryInvestigation focusUnexpected script executionEDR and process-creation logsParent process, command line, user contextSecurity-control interferenceEDR alerts and security configuration logsAttempted versus successful changesSuspicious memory operationsEDR behavioural telemetryProcess relationships and memory-access behaviourMisleading executable namesFile metadata and process telemetryPath, signature, hash, execution historyEvent-log clearingWindows Security logs and central SIEMActor, timestamp, related events, logging gapsUnusual registry changesEDR, Sysmon, and registry auditingChanged value, initiating process, purposeCloud logging modificationCloud audit logsIdentity, API calls, permissions, resulting stateUnexpected security-policy changesIdentity-provider audit logsActor, source, scope, approval, subsequent activity

The effectiveness of these detections depends on telemetry coverage and configuration. Where visibility is incomplete, improving collection may be as important as writing new detection rules.

13. Prevention and Defensive Recommendations

Organisations can make defence evasion more difficult and improve their ability to detect it through layered controls.

• Protect security tools: Restrict administrative access and use tamper-protection features where supported.

• Centralise logs: Forward important security events to a protected central platform so local log deletion does not remove every copy.

• Monitor configuration changes: Alert on unexpected changes to endpoint protection, audit policies, scheduled tasks, services, and cloud logging.

• Apply least privilege: Limit who can modify security settings and use separate privileged accounts for administration.

• Use behavioural detection: Correlate process, file, registry, memory, identity, and network activity instead of relying exclusively on signatures.

• Restrict unnecessary scripting: Apply appropriate application-control and script policies without disrupting legitimate administrative work.

• Maintain visibility: Monitor collection failures, unexpected telemetry gaps, and changes to logging configuration.

• Use change-management records: Compare security-related changes with approved maintenance and deployment activity.

• Test detections safely: Use authorised simulations and controlled exercises to validate alerts and response procedures.

• Preserve evidence: Retain relevant telemetry and document response actions to support incident reconstruction.

Conclusion

Modern defence evasion is not a single technique. It is a collection of behaviours designed to reduce visibility, undermine security controls, or make malicious activity harder to investigate.

Threat actors may abuse legitimate tools, obfuscate commands, manipulate processes, disguise files, tamper with logs, or alter cloud security configurations. Many of these actions also occur during legitimate administration, making context and correlation essential.

For SOC analysts, the key is to determine what changed, which process or identity initiated the change, whether it succeeded, and what happened before and after it.

By combining endpoint, identity, cloud, and network telemetry, security teams can identify suspicious patterns, investigate potential control interference, and improve their ability to detect attacks that attempt to remain hidden.

Further Reading

• MITRE ATT&CK: Defence Evasion

• MITRE ATT&CK: Impair Defenses

• MITRE ATT&CK: Indicator Removal

• Microsoft Sysinternals

• CISA — Cybersecurity advisories and defensive guidance.