Attackers thrive on easy targets, don’t be one.
Ethical Threat Insight: How insecurely installed 3rd-party software can hurt you
Single, high-value action to do today: audit any recently installed third-party Windows software for who can write files where it installs…then lock it down.
Why that matters: attackers don’t need complex exploits if they can abuse commonly overlooked issues. Like insecure software installs and writable system locations. Fixing those stops a huge class of easy abuses.
1. Unquoted service paths
What: A Windows service configured with a path that has spaces and isn’t wrapped in quotes, e.g.
C:\\Program Files\\Acme App\\svc.exeWhy: Windows will try to run the first valid executable along the path. An attacker who can write to
C:\\Program.exeorC:\\Program Files\\Acme.execan get code run as the service account.Fix: Inspect services (
sc qcor use Services.msc). If the path contains spaces and no quotes, update the service to wrap the path in quotes or reinstall correctly. Replace or modify the service ImagePath to the quoted full path.
2. Modifiable installation directories
What: Apps that install into folders that non-admins or users can write to (e.g.,
C:\\Program Files\\Vendorwith permissive ACLs, or worse:C:\\Users\\Public\\VendorApp).Why: If an attacker can drop a DLL/executable into that folder, they can escalate when a privileged process loads that code.
Fix: On a machine, pick one recent third-party install and check ACLs (
icacls "C:\\path\\to\\install"). Remove unnecessary write permissions for non-admin users. If the installer needs to run updates, create a controlled updater account or service with constrained rights.
3. Insecure MSI (Windows Installer repairs abused for SYSTEM)
What: Windows caches MSI files in
C:\\Windows\\Installer. Normal users can trigger “repair” operations, and if the installer is misconfigured, repair actions may run asNT AUTHORITY\\SYSTEM.Why: If the repair process looks for files or DLLs in folders where standard users have write access (like
C:\\Windows\\Temp), attackers can drop a malicious DLL and get it executed as SYSTEM for instant privilege escalation.Fix: Audit cached MSI repair paths with msi_search. Ensure installers don’t execute from or reference user-writable folders. Lock down ACLs on
C:\\Windows\\Temp,C:\\ProgramData, and any install subfolders. Prefer signed MSIs from trusted vendors.
4. Writable SYSTEM path
What: The OS
PATHincludes directories that non-admins can write to (or system directories themselves with loose ACLs).Why: If a low-privilege user can create
net.exeorcmd.exeearlier on the PATH, a privileged process that resolves that binary may execute attacker code.Fix: Inspect system PATH (
echo %PATH%). Ensure all entries that run in system or service contexts are in locations only writable by Admins/SYSTEM. Remove user-writable directories from the system PATH.
Example playbook you complete in 5 minutes (pick a high-value machine):
Run the following from PowerShell to check for unquoted service paths:
Get-WmiObject win32_service | select Name,PathName,StartMode,StartName | where {$*.StartMode -ne "Disabled" -and $*.StartName -eq "LocalSystem" -and $*.PathName -notmatch """ -and $*.PathName -notmatch "C:\Windows"} | Format-ListFor a selected app, run
icacls "C:\\Program Fileslt;Vendor>"and look forEveryoneorUserswithMorF. Remove those ACLs.Audit for MSI repair vulnerabilities with msi_search. To identify MSI repair operations that could be hijacked. Pay special attention to repair actions referencing
C:\\Windows\\Tempor other writable locations.Run
echo %PATH%and and confirm no user-writable folders precedeC:\\Windows\\System32
This really just scratches the surface of the risks of 3rd party software. We haven’t even talked about IDEs or AI coding platforms. That’s an even wilder and crazier attack surface, as I am sure you know.
If you want to dig into this more, I did an entire webinar on this topic.
All the best
Spencer Alessi