Windows object permissions as a backdoor

  • Adding his account to Administrators group,
  • Creating new administrative account,
  • Creating a Scheduled Task, providing a privileged access after the eradication,
  • Installing specialized Windows Service,
  • Installing DLLs, being automatically loaded by highly-privileged processes,
  • Replacing legitimate files with malicious ones,
  • Creating WMI event filters and consumers,
  • Manipulating encryption keys needed for offline access,
  • Etc.
  • Very quick to plant,
  • No additional binaries/tools required, only built-in OS tools,
  • Easy to plant remotely,
  • Impossible to find, unless an admin looks specifically for them,
  • Very rarely checked by scanning tools.
  • Cover only “user to admin” privilege escalation scenarios.
  • User is an admin for a moment,
  • User launches cmd.exe using its temporary superpowers,
  • User modifies ACLs of utilman.exe, taking its ownership and adding himself to the list
Modified ACL of the Utilman.exe utility
  • User removes his privileges, and behaves politely,
  • Admins fix the vulnerability,
  • User logs back on as regular user,
  • User overwrites the original utilman.exe with cmd.exe, for example using “type c:\windows\system32\cmd.exe > c:\windows\system32\utilman.exe
  • User presses Ctrl+Alt+Del, and then Win+U and has admin access again.
Utilman.exe seen as legitimate file, despite ACL modification
  • Windows Operating System files, being used by highly privileged processes. Hundreds of EXE and DLL files actually. Some of them may be exploited easily, other may require dropping own binary file, but any approach based on comprehensive list and manual check is irrational.
  • Program Files, and other non-windir locations, being used by highly privileged processes. Such locations are used typically by third-party software, and they exist on each Windows based machine. It may be slightly harder to pick ideal candidate, but at the same time, every single computer may be slightly different making the detection even harder.
  • Registry permissions. Less known than file permissions, which makes them even more tempting to exploit. As registry settings determine the OS behavior, changes may disrupt security in multiple different ways. For example, the REG_MULTI_SZ value “Notification Packages” in the Control\Lsa determines which DLL is loaded by the lsass.exe. It allows to perform multiple sneaky attacks, but at the same time is a great backdoor, as the DLL added to the list by an attacker will be loaded at every boot, executing its code in the SYSTEM context.
Modified ACL of the registry key
  • Windows Service permissions. Even less known, however easy to display with “sc.exe sdshow servicename”. Even if the result may be a bit intimidating at the first sight, it is perfectly precise, well documented and powerful. The only enigmatic part here is the way how it is displayed, as it is “Security Descriptor Definition Language” or SDDL. Under the hood, it is just an ACL, specifying who can start or stop the service, change its configuration etc. If an attacking user provides himself a possibility of changing the configuration, he owns the system forever. When he wants to re-gain admin superpowers, he can change the existing configuration to make Service Manager launch malicious executable, instead of legitimate one.
Spooler service permissions
  • System privileges. System privileges are not object permissions, but they may be treated as permissions for the entire Operating System. Some privileges are relatively harmless, as changing the timezone or even shutting down the server will not make user the admin again, while others may be dangerous. Especially SeRestorePrivilege, and SeTakeOwnershipPrivilege may be tempting for an attacker, as both allow to gain admin privileges with couple of command lines and no third-party tools. More complicated, but still successful scenarios rely on SeAssignPrimaryTokenPrivilege, SeCreateTokenPrivilege, SeDebugPrivilege, SeLoadDriverPrivilege, SeManageVolumePrivilege and SeTcbPrivilege. Restore and TakeOwnership privileges are used to gain control over sensitive Operating System files, and the attack itself resembles the scenario with utilman.exe, as described above.
SeRestorePrivilege assigned to an unprivileged user
  • Active Directory. Even if out of scope (it is not a Windows object, and it cannot be called a local privilege escalation), Active Directory is mentioned here to remind, that it is vulnerable to the same type of permission-based attacks.
Displaying file owner using PowerShell
Audit trace for permission change
  • Log centralization — to prevent log manipulation by an unwanted admin, and to prevent old events overwriting if defenders analyze the case long time after the attack;
  • Analytics — to avoid manual review of millions of entries, and to provide some alerting.
  • Analyzing ACLs for files and directories. As manual review is pointless (fresh Windows installation may contain over 100k files), the only reasonable way relies on automation. PowerShell Get-Acl cmdlet exposes SDDL property of file objects. It is possible to look for anomalies, broken inheritance, unusual owners etc. The best result may be achieved when comparing the compromised state to the healthy one, taken from baseline, similar machine or a trusted backup. Get-Acl returns owners of filesystem objects as well, both as dedicated property, and as a part of the SDDL string.
Displaying owners of multiple files using PowerShell
  • Analyzing ACLs for Registry keys. The same approach and set of scripts used for filesystem may be used, as PowerShell exposes both filesystem, and registry as PSDrive object.
Getting registry permissions using PowerShell
  • Analyzing Services ACLs. PowerShell may help with automation, but reading permissions is slightly more complex, as Get-Acl requires GetSecurityDescriptor method exposed by an investigated object, and Get-Service does not have it. One of the workarounds relies on WMI.
Getting service permissions with PowerShell and WMI
  • Analyzing system privileges. As there is no official offline way to read privileges database, and no PowerShell or even .Net implementation, privileges are the hardest area for automated analysis. The evidence should be collected while system is still alive, and it may use secedit with /export parameter, or quite complex PowerShell wrapper for LsaEnumerateAccountsWithUserRight() API function.
Dump of privileges using secedit

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

WSO2 Identity Server X509 authenticator configuration to support ‘X509v3 Subject Alternative Name’…

{UPDATE} PumiLumi LITE Hack Free Resources Generator

Recap of Zecrey AMA

How they do Reconnaissance?

How to Activate 2-factor Authentication on Discord

How to Choose the Best Security Camera for Your House

3

{UPDATE} Idle Miner Inc Hack Free Resources Generator

Password Managers: You’re Doing It Wrong

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Grzegorz Tworek

Grzegorz Tworek

More from Medium

PowerShell Obfuscation

Investigating Windows — TryHackMe writeup

Ghidra Setup

Image Analysis -Osint Tools