Skip to content

dwm.exe

Desktop Window Manager

Composes the desktop from what each window draws off screen into the image you see.

Normal Profile

These are the values a genuine copy shows. Treat any value that differs as a lead.

Parent
winlogon.exe (a value that published detection rules check for)Source: Elastic: Unusual Parent-Child Relationship (opens in a new tab)Elastic's rule also allows wininit.exe, and dwm.exe itself.
Path
System32 (a value that published detection rules check for)C:\Windows\System32\dwm.exeSource: SigmaHQ: System File Execution Location Anomaly (opens in a new tab)
Account
Read it from each copy's token on a clean machine of the same build, with Process Explorer live or windows.getsids in memory.
Session
Read each copy's SessionId with Get-CimInstance Win32_Process or windows.pslist, then sign in a second person and look again.
Instances
Count copies per session on a clean machine of the same build, before and after a second sign-in.
Starts
Compare each copy's start with its session's sign-in on a clean machine of the same build.
Command Line
Read it elevated with Get-CimInstance Win32_Process on a clean machine of the same build.
Signed By
Check the file with Sigcheck, which reads catalogue signatures too, on a clean machine of the same build.

A value that published detection rules check for.No public source states this value, so compare with a clean machine of the same Windows build.

Why It Matters

It composes the desktop you see, so its name looks routine in any listing. A copy outside System32, or one that Winlogon did not start, needs a reason.

What It Does

With desktop composition, introduced in Windows Vista, windows no longer draw straight to the screen. Each draws to an off-screen surface in video memory, and the Desktop Window Manager renders those surfaces into the desktop image you see. Its visual effects, such as window transitions, come from that composition. It runs from System32, and Elastic's rule expects winlogon.exe or wininit.exe to start it. A dwm.exe in another folder, with no valid signature, or under another parent is the one to check.

Microsoft's overview, which still describes Windows Vista features such as Flip3D, calls DWM a service, the Desktop Window Manager Session Manager. On current Windows, Elastic's detection rule expects dwm.exe's parent to be winlogon.exe, wininit.exe or dwm.exe itself, so a copy with any other parent needs a reason.

Microsoft documents neither its account nor how many copies run, so read both on a clean machine of the same build before judging a copy. Velociraptor's Windows.System.UntrustedBinaries checks dwm.exe's signature by default.

How Attackers Abuse It

Each line is a way this process is misused, with the page that shows how to spot it.

  • Malware takes the name dwm.exe and runs from a user folder, borrowing a name every desktop shows.Wrong Path
  • A file named dwm.exe with no valid signature, which Velociraptor's Windows.System.UntrustedBinaries checks for by default.Renamed, Unsigned or Falsely Signed Binaries

Red Flags

Each sign below links to the page that shows how to confirm it.

How to Check It

Each page shows how to check this process, on a running machine and in a memory image.

What Records It

Each record names its log and what must be switched on to get it.

Record and Where It LandsWhat to ReadHow to Turn It On
4688 A new process has been created (opens in a new tab)SecurityIt is written on the computer the process ran on.For a New Process Name ending in dwm.exe, the Creator Process Name should be winlogon.exe and the path System32.Process Trees and Call Chains shows how to read it.Turn on Audit Process Creation. For the command line, also turn on Include command line in process creation events.
1 Process creation (opens in a new tab)Microsoft-Windows-Sysmon/OperationalIt is written on any Windows computer running Sysmon.Image, ParentImage and User for each copy.Process Trees and Call Chains shows how to read it.Run Sysmon with ProcessCreate events in its configuration.
DeviceProcessEvents (opens in a new tab)Each row is a process creation or a related event, naming the new process, the process that created it and that creator's parent.Defender XDR, advanced huntingFolderPath, InitiatingProcessFileName, AccountName and CreatedProcessSessionId for each copy.The Defender for Endpoint sensor on the device

Hunt It

The same hunt is written for four tools, so pick the one you use. Defender XDR and Sentinel queries are in KQL, which you paste into Advanced hunting in the Defender portal or into Sentinel's Logs page. Splunk queries are in SPL, for its Search page, and Velociraptor queries are in VQL, which you run as a hunt.

Reads the DeviceProcessEvents table in Defender XDR advanced hunting, from devices onboarded to Defender for Endpoint. Before you read no rows as clean, check that it recorded the genuine copy at a recent boot or sign-in. A hit is a lead, so check the file's signer and where it came from before you call it malicious.

KQLDefender XDR, Advanced hunting
// dwm.exe outside C:\Windows\System32, or created by anything but winlogon.exe, wininit.exe or dwm.exeDeviceProcessEvents| where Timestamp > ago(30d)| where FileName =~ "dwm.exe"| where not(FolderPath matches regex @"(?i)^C:\\Windows\\System32(\\dwm\.exe)?$")    or InitiatingProcessFileName !in~ ("winlogon.exe", "wininit.exe", "dwm.exe")| project Timestamp, DeviceName, FolderPath, ProcessCommandLine, AccountName, CreatedProcessSessionId, InitiatingProcessFileName, InitiatingProcessFolderPath

Changes by Version

This process has changed between versions, so read a machine against its own.

Sources