CVE-2024-38189

What it actually does

CVE-2024-38189 is a Microsoft Project remote code execution vulnerability. A specially crafted Project document can trigger unsafe processing in Microsoft Project and cause attacker-controlled code to run on the workstation when a user opens the file. Successful exploitation runs code in the context of the signed-in user, which can allow data access, malware execution, persistence setup, lateral movement tooling, and further privilege escalation if the user has elevated rights. The vulnerability requires user interaction but no attacker authentication, and Microsoft has confirmed active exploitation in the wild.

Why it matters to the business

An attacker can use malicious Microsoft Project files in phishing or document-sharing lures to compromise employee workstations. This can lead to theft of business documents, credential harvesting, malware deployment, operational disruption, and potential movement into broader enterprise systems. Because this vulnerability is in CISA KEV with a remediation due date of 2024-09-03 and has observed in-the-wild exploitation, organizations should treat unpatched Microsoft Project, Office, Microsoft 365 Apps, and Office LTSC installations as high-priority exposure even though exploitation requires a user to open a file.

How an attack unfolds

An attacker typically prepares a malicious Microsoft Project file and delivers it through email, collaboration platforms, file-sharing links, or a compromised website. The lure is designed to convince the recipient to open the file in Microsoft Project. When the vulnerable application parses the crafted content, the flaw is triggered and code executes with the privileges of the current user. The attacker can then run a payload such as a downloader, command shell, script interpreter, credential theft tool, or remote access trojan. Post-exploitation activity may include establishing persistence, collecting local files and browser credentials, contacting command-and-control infrastructure, and using stolen credentials or remote management tools for lateral movement. Public reporting identifies active exploitation, but no specific ransomware use is indicated by the provided KEV metadata.

How to fix it

Apply the relevant Microsoft security updates for Microsoft Project, Microsoft Office, Microsoft 365 Apps, and Office Long Term Servicing Channel. Use Microsoft Update, Microsoft Configuration Manager, Intune, WSUS, Office Deployment Tool, or enterprise patch tooling to ensure affected products receive the August 2024 security updates or later cumulative updates. Where immediate patching is not possible, reduce risk by blocking or quarantining Microsoft Project attachments from untrusted sources, enforcing Protected View and Mark-of-the-Web handling, disabling untrusted Office macros and active content, restricting script interpreters and living-off-the-land binaries through application control, and limiting local administrative privileges. Because this CVE is listed in CISA KEV, remediation should be prioritized ahead of routine patch cycles if any vulnerable Microsoft Project or Office installations remain.

How to confirm the fix worked

Confirm that Microsoft Project and Office installations show build levels that include the August 2024 security update or later. Validate coverage across Microsoft 365 Apps, Office LTSC, Microsoft Office, and Project 2016 installations, including systems that are not always connected to central patch management. Review software inventory for remaining installations of Microsoft Project or Office components that have not received recent updates. Test enterprise controls by attempting to open benign Project files from Internet-marked locations and confirming that Protected View, attachment detonation, EDR monitoring, and application-control policies behave as expected. For exposure validation, search endpoint inventories for WINPROJ.EXE versions below the patched baseline and verify that update channels are not deferred beyond the patched release.

Typical attack path

1. Attacker identifies targets likely to open Microsoft Project or Office project-planning documents.
2. Attacker creates or obtains a weaponized Microsoft Project file that triggers the vulnerability.
3. Attacker delivers the file through phishing email, shared cloud storage, messaging platforms, or a malicious download link.
4. User opens the crafted file in a vulnerable Microsoft Project or Office installation.
5. Microsoft Project processes the malicious content and executes attacker-controlled code in the user's context.
6. Initial payload launches a script interpreter, downloader, or remote access tool.
7. Attacker establishes persistence, performs discovery, steals credentials or files, and attempts lateral movement.

How to detect it

Investigate endpoint, email, proxy, and EDR telemetry for signs that a Microsoft Project file was opened shortly before suspicious process creation or outbound network activity. Key evidence sources include Windows process creation logs, Sysmon Event ID 1 process creation, Sysmon Event ID 3 network connections, Microsoft Defender for Endpoint advanced hunting, Office telemetry, email security gateway attachment logs, web proxy download logs, and EDR file/quarantine records. Focus on WINPROJ.EXE launching unusual child processes, creating executables or scripts in user-writable directories, or initiating network connections to unfamiliar external hosts. Review recent inbound attachments and downloaded files with Microsoft Project extensions, especially those from external senders or Internet-marked sources. On suspected systems, collect the opened document, prefetch entries, Amcache/ShimCache, RecentDocs, Office file MRU entries, browser download history, and EDR timeline around the time the file was opened. Also look for follow-on behaviors such as credential dumping, scheduled task creation, Run key persistence, unusual PowerShell commands, encoded command execution, suspicious DLL loading, and remote access tool installation. There are no universal file hashes or network indicators for this vulnerability; detection should be behavior-based and correlated to Microsoft Project document handling.

• WINPROJ.EXE
• winproj.exe
• WINPROJ.EXE -> powershell.exe
• WINPROJ.EXE -> cmd.exe
• WINPROJ.EXE -> wscript.exe
• WINPROJ.EXE -> cscript.exe
• WINPROJ.EXE -> mshta.exe
• WINPROJ.EXE -> rundll32.exe
• WINPROJ.EXE -> regsvr32.exe
• WINPROJ.EXE -> certutil.exe
• WINPROJ.EXE -> bitsadmin.exe
• WINPROJ.EXE -> curl.exe
• WINPROJ.EXE -> wget.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\cmd.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\mshta.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\rundll32.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\regsvr32.exe
• ParentImage=*\\WINPROJ.EXE Image=*\\Windows\\System32\\certutil.exe
• powershell.exe -enc
• powershell.exe -EncodedCommand
• %APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup
• HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
• HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
• .mpp
• .mpt
• .mpx

What your security team should do

• Prioritize patching of Microsoft Project and Office installations because the vulnerability is in CISA KEV and has active exploitation in the wild.
• Hunt for suspicious Microsoft Project activity, especially WINPROJ.EXE spawning command shells, script interpreters, download utilities, or DLL execution utilities.
• Temporarily block or sandbox inbound Microsoft Project files from external senders until patch compliance is confirmed.
• Ensure Office Protected View, Mark-of-the-Web enforcement, and macro/active-content restrictions are enabled and centrally managed.
• Use EDR or application control to prevent Office applications from launching child processes such as PowerShell, cmd, wscript, mshta, rundll32, regsvr32, and certutil unless explicitly required.
• Review email, web proxy, and collaboration-platform logs for externally delivered Project files followed by endpoint alerts or unusual network connections.
• Educate help desk and end users to report unexpected project-planning documents, especially those requiring them to bypass security warnings.
• After remediation, run targeted threat hunts for persistence, credential theft, and remote access tooling on systems where suspicious Project documents were opened.