Behavior:Win32/MaleficAms: Why the Alert Returns After a Clean Scan

Behavior:Win32/MaleficAms is a Microsoft Defender detection for suspicious behavior. If it appears again after a clean full scan, compare the event time and affected item before deciding that removal failed. A new startup event, an old Protection History card, and an action that never finished need different responses. Keep unknown items blocked or quarantined, record what triggered the alert, and investigate that source. Do not restore the file or erase the history to see whether the warning comes back.

The useful question is: did Windows record new activity, or are you looking at the previous result? This guide follows that distinction through startup checks, scanning, and a controlled reboot comparison.

Record the full MaleficAms alert first

Open Windows Security from Start, then Virus & threat protection → Protection history. Expand the relevant card; administrator approval may be required to see its details. Microsoft uses this screen to show actions already taken as well as items needing attention.^[1] A card remaining visible is therefore different from a newly detected threat.

• Full detection name: copy it exactly, including the prefix and suffix. Behavior:Win32/MaleficAms.A and a VirTool:PowerShell/... label should not be silently combined.
• Event date and time: compare the time inside the expanded event with the current startup. The moment you noticed a notification is not necessarily the time of the underlying detection.
• Action status: record whether it says action needed, quarantined, blocked, or remediation incomplete.
• Affected item or process: copy the complete path and any command or additional details shown. A process name without its arguments may omit the file or command it was asked to run.

Keep the record privately. If you ask for help, remove personal usernames and other private information from screenshots; preserve the filename, relevant folder structure, time, and action status. Do not post a complete script or private file merely because a forum reply asks for it.

New detection, old history, or unfinished removal?

• The same old time and completed action remain visible. That card alone does not establish recurrence. Keep the item contained and look for a newer event before making more changes. Clearing the history would discard the comparison you need.
• A newer event appears after each sign-in. Record the affected item from the newest event and inspect its launch source below. Repeated timing suggests a startup trigger worth investigating; it does not identify which component is responsible.
• The card says action needed or remediation incomplete. Open its details and complete the supported action. For an unknown threat, keep it quarantined rather than allowing it. If the action fails again, save the error and affected path for escalation.^[1]
• The alert consistently follows a known application’s launch. Check the exact installed file, publisher, source, and version. This is a reason to investigate a possible false positive, not permission to exclude the application or run the blocked file again.

Why a full scan can be clean while MaleficAms returns

Microsoft documents Behavior:Win32/MaleficAms.A and describes malicious PowerShell activity that can change settings and support persistence. Its remediation guidance also notes that files and system changes may remain after the initial action.^[2] That explains why the launch source matters. It does not establish that every MaleficAms alert on every PC has the same payload or entry point.

A file scan and a behavior alert answer different questions. A full scan checks the items available to that scan; a behavior alert concerns activity observed when something runs. If the active component was blocked or its file quarantined, a later scan may find no accessible copy. A startup entry may nevertheless attempt another launch. Alternatively, there may be no new activity at all and only the previous card is being displayed.

Use the evidence to separate these possibilities. A newly timestamped event tied to the same startup source deserves investigation even after a clean scan. An unchanged completed record does not justify deleting unfamiliar folders. An Offline Scan that did not start adds no clean-scan evidence to either case.

The label also cannot tell you that passwords were stolen, that a rootkit is present, or that a particular recent legitimate download caused the problem. Those conclusions require additional findings.

Check what launches at startup

If the newest event occurs around sign-in, start with the path or process it names. In Task Scheduler, inspect a suspected task’s Triggers and Actions: what starts it, what program it invokes, and what arguments it supplies. Record these before changing anything. Do not run the task as a test.

A task that invokes powershell.exe is not automatically malicious. The relevant clue may be the script, arguments, or download source passed to that legitimate interpreter. Likewise, a reference to C:\Windows\System32\cmd.exe is a reason to inspect its command, not delete the Windows executable. A file in %LOCALAPPDATA%\Temp needs context; the directory alone is not a malware verdict.

Microsoft Sysinternals Autoruns can expose logon entries, scheduled tasks, services, and other automatic launch locations. Inspect an entry’s properties and target. Microsoft documents that unchecking its box disables the entry; deleting it is a separate action.^[3]

1. Match the source. Connect the alert’s affected item with a task action, startup command, or application. Matching only the time or a familiar process name is insufficient.
2. Check the actual target. Review the file location, publisher and signature, installation source, and security findings. A signature can help identify a publisher; it does not certify that every action the program performs is safe.
3. Contain an identified unwanted item. If the evidence identifies a malicious or unwanted launch entry, record it and disable that specific entry reversibly. Remove identified threats with the security tool. If its purpose remains unclear, seek help with the record instead of disabling everything.

Keep changes narrow enough that you can tell what affected the next result. Do not disable all PowerShell tasks, delete every unsigned entry, or paste a registry-cleaning script into an administrator terminal.

Scan, reboot, and compare the next event

Update the security tool’s definitions and run a full scan. Review and act on identified threats, then save the scan result. With recurring alerts, removing a visible file may leave a loader, task, service, or bundled component that attempts to recreate the activity. Run Gridinsoft Anti-Malware to check for malicious files and startup components behind the recurring alerts, review the findings, and remove detected threats. Keep the PC’s protection active throughout the cleanup.

Save your work and restart once after the cleanup. Compare the newest event with your original record:

• No newer event; previous action completed: resume ordinary use cautiously and monitor the same symptom. This supports that the observed recurrence has stopped, but cannot reconstruct what happened before cleanup.
• New event, same source: the cleanup has not resolved the trigger. Preserve both records and investigate the remaining source rather than repeating the identical scan indefinitely.
• New event, different source: record the new target separately. Check whether it belongs to the same installed bundle or another launch location before grouping it with the first finding.
• Entry or security setting reappears after removal: stop treating this as a notification-only issue. Use the Windows security audit after malware to check persistence and changed settings, or get qualified help.

This comparison is an investigation method, not a recommendation to deliberately execute a suspicious file. If there is active remote control, continuing downloads, or destructive activity, disconnect the PC from the network and escalate without waiting for another experiment.

Could MaleficAms be a false positive?

It is possible, but “the full scan was clean” does not settle it. Build the case around the specific affected file and action: whether the application came from its official publisher, whether its signature and version match, and whether the publisher or Microsoft has confirmed a detection issue affecting that build.

Use the guide to conflicting antivirus results to interpret disagreements without treating a detection count as a vote. Do not upload private files to a public scanning service. Keep the item blocked while the issue is investigated; adding a folder-wide exclusion would also permit unrelated files in that folder.

If Offline Scan does not start—or an account is at risk

If selecting Offline Scan produces no restart or no scan screen, follow the Defender Offline Scan troubleshooting guide. It checks the active antivirus, administrator request, recovery environment, and scan-start evidence. A failed launch is a separate Windows troubleshooting problem, not confirmation that MaleficAms defeated the scanner.

If a suspicious command or file already ran, or you have unfamiliar logins or account changes, secure affected accounts from a known-clean device. Change exposed passwords, revoke unfamiliar sessions, and review recovery methods and multifactor authentication. Local malware removal does not revoke a stolen session.

Persistent verified malicious launches, recurring security tampering, or a system you cannot reliably repair may justify a clean Windows installation. Preserve necessary personal documents safely and rebuild from trusted installation media; avoid restoring the untrusted installer or startup configuration. A solitary old, completed history card is not enough reason to erase the PC.

References

1. Microsoft. “Protection History in the Windows Security App.” Microsoft Support, accessed September 15, 2026. Protection History actions and status.
2. Microsoft. “Behavior:Win32/MaleficAms.A.” Microsoft Security Intelligence, updated May 19, 2025; accessed September 15, 2026. MaleficAms.A threat description.
3. Russinovich, Mark. “Autoruns v14.3.” Microsoft Sysinternals, June 17, 2026; accessed September 15, 2026. Autoruns usage and startup locations.