T1136.001 Local Account

This diagnostic statement implements security controls and restrictions for remote user access to systems. Remote user access control involves managing and securing how users remotely access systems, such as through encrypted connections and account use policies, which help prevent adversary access.

This diagnostic statement provides protections for production environments. Measures such as network segmentation and access control reduce the attack surface, restrict movement by adversaries, and protect critical assets and data from compromise.

This diagnostic statement protects against Local Account through the use of privileged account management and the use of multi-factor authentication.

This diagnostic statement protects against Local Account through the use of privileged account management. Employing auditing, privilege access management, and just in time access protects against adversaries trying to obtain illicit access to critical systems.

This diagnostic statement provides protection from Create Account through the implementation of privileged account management controls to limit credential access. Employing limitations to specific accounts, access control mechanisms, and auditing the attribution logs provides protection against adversaries attempting to create accounts.

This diagnostic statement protects against Create Account through the use of revocation of keys and key management. Employing limitations to specific accounts along with access control mechanisms provides protection against adversaries attempting to create accounts.

This diagnostic statement describes how the organization implement appropriate authentication requirements, including selecting mechanisms based on risk, utilizing multi-factor authentication where necessary, and safeguarding the storage of authenticators like pins and passwords to protect sensitive access credentials.

This diagnostic statement protects against Local Account through the use of hardened access control policies, secure defaults, password complexity requirements, multifactor authentication requirements, and removal of terminated accounts.

This vulnerability is exploited by an adversary who already has access to the victim system. This vulnerability, also known as SpoolFool, is a local privilege escalation vulnerability in the Windows Print Spooler service, which manages print operations on Windows systems. This vulnerability allows attackers to execute code with SYSTEM-level privileges by exploiting the `SpoolDirectory` configuration setting. The `SpoolDirectory` is writable by all users and can be manipulated using the `SetPrinterDataEx()` function, provided the attacker has `PRINTER_ACCESS_ADMINISTER` permissions. The exploit involves creating a directory junction and using a Universal Naming Convention (UNC) path to write a malicious DLL to a privileged directory, such as `C:\Windows\System32\spool\drivers\x64\4`. This DLL is then loaded and executed by the Print Spooler service, granting the attacker elevated privileges. This method circumvents previous security checks designed to prevent privilege escalation through the Print Spooler. The vulnerability has been exploited in the wild, with attackers using tools like the SpoolFool proof of concept (PoC) published on GitHub. One observed attack involved creating a local administrator account with a default password, indicating the potential for significant system compromise. The Gelsemium APT group has been linked to activity exploiting this vulnerability, highlighting its use in advanced persistent threat campaigns.

CVE-2022-47966 is a remote code execution vulnerability that affects many ManageEngine products due to misconfiguration of security features. Adversaries can utilized this vulnerability to run arbitrary java. APTs have been observed exploiting this vulnerability to gain access, to public-facing applications, establish persistence, and move laterally. They've also been observed to create local user accounts with administrative privileges, use valid but disabled user accounts, delete logs, establish command and control communications, ... **the list goes on and on due to fantastic, detailed reporting**

The Microsoft Sentinel Hunting "New User created on SQL Server" query can detect a specific type of potentially malicious local account creation. The following Microsoft Sentinel Analytics queries can identify potentially malicious local account creation: "Summary of users created using uncommon/undocumented commandline switches" which can identify use of the net command to create user accounts, "User created by unauthorized user", "User Granted Access and associated audit activity" and "User Granted Access and Grants others Access" which may identify account creation followed by suspicious behavior, "User account created and deleted within 10 mins" which suggests an account may have existed only long enough to fulfill a malicious purpose, and "Powershell Empire cmdlets seen in command line" which can identify use of Empire, including for account creation.

This control's "Immutable (read-only) root filesystem should be enforced for containers" recommendation can lead to preventing system files from being modified in Kubernetes containers thereby mitigating this sub-technique since adding an account (on Linux) requires modifying system files. Because this is a recommendation, its score is capped at Partial.

This control may alert on usage of the useradd command to create new users and the creation of local user accounts with suspicious similarity to other account names.

This control may detect when an account is created with an account name that closely resembles a standard Windows account or group name. This may be an account created by an attacker to blend into the environment. The following alerts may be generated: "Suspicious Account Creation Detected".

Google Security Ops is able to trigger based on suspicious system event logs, such as newly created local user accounts in Windows AD environments (e.g., event 4720). This technique was scored as minimal based on low or uncertain detection coverage factor. https://github.com/chronicle/detection-rules/blob/783e0e5947774785db1c55041b70176deeca6f46/soc_prime_rules/threat_hunting/windows/detects_local_user_creation.yaral

Identity Platform multi-tenancy uses tenants to create unique silos of users and configurations within a single Identity Platform project. It provides provides secure, easy-to-use authentication if you're building a service on Google Cloud, on your own backend or on another platform; thereby, helping to mitigate adversaries from gaining access to systems and accounts.