Backdoors & Breaches: Logon Scripts
This blog post discusses the relevance and techniques involved in logon script abuse. While the Backdoors & Breaches card is featured for this topic, the post will provide context for understanding how an attacker can abuse this functionality and details that are useful in monitoring for such abuses.
Operating systems typically have features that allow an administrator or user to automatically execute commands during session initiation to ease the burden of administration in the context of a given environment. An attacker can take advantage of those features to execute commands of their own in order to gain initial access, establish persistence, or perform lateral movement.
This type of attack can be most devastating in the context of a corporate Active Directory environment. As a result, the discussion will center around the Microsoft Windows operating system. However, administrators and security analysts should realize that many of the capabilities we will be investigating are available in other operating systems and those vendor appliances installed on our networks.
In the context of this post, I consider a “Logon Script” any functionality that supports automated command execution during user session initialization. So, what techniques might an attacker try to obtain authentication-based execution?
- Modification of registry keys
- Local filesystem-based automated execution
- Default domain logon script modification
- Group policy modification
- User object attribute modification
This surely is not an exhaustive list. However, it includes techniques that are most widely known and some things that we have encountered on recent engagements. Let’s explore each technique individually to more comprehensively understand it.
Modification of Registry Keys
This technique is age-old and highly instrumented by Antivirus and Endpoint Detection and Response tools. The Microsoft Windows registry contains several keys that can be used to execute content when the user logs onto the target host. The most widely discussed keys include:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
In fact, there are many other options for execution and a comprehensive treatment can be found at https://attack.mitre.org/techniques/T1060/.
If an attacker is able to successfully modify one of the referenced keys successfully, the system will execute the target application each time the user authenticates.
As an organization, it would be a wise investment to ensure that your chosen endpoint protection software identifies modification of the referenced registry keys to prevent abuse. In addition, it would be prudent to monitor for new registry keys used for this type of abuse.
Local Filesystem-based Automated Execution
When an attacker gains a “logon script” type automated execution using the local filesystem, the typical attack vector is the user or system’s startup folder.
- C:\Users\<user name>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
- C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
By default, the system startup folder is not writable by standard users. However, some organizations still grant local administrative permissions to their user populations.
In any case, your chosen endpoint protection software should identify when these folders are modified. The contents of the folder should be monitored and investigated when changes do occur.
Default Domain Logon Script Modification
Probably the most widely understood “Logon Script” functionality is the use of scripts found in the \\<domain>\SYSVOL\Scripts share or an equivalent Group Policy Object that defines the Logon/Logoff script policy element.
An attacker can easily discover the target logon script by inspecting the Active Directory scriptPath attribute of user objects.
In addition, the attacker can search the \\<domain>\SYSVOL\policies share for the presence of the Logon folder.
Once the target scripts are discovered, the attacker can check those locations for the ability to write to the files. If write access is allowed, the attacker can use the script to attack anyone to which the logon script has been prescribed. Where write access is not allowed, the attacker can trace execution to determine whether additional scripts or binaries are called by the initial script and evaluate NTFS permissions in those locations.
As a result, the organization must periodically ensure that NTFS permissions set on domain login scripts and any branching locations are appropriately restricted.
Group Policy Modification
In this case, the attacker finds that their user account has permission to modify Group Policy Objects within the Group Policy hierarchy.
With the ability to modify policy, the attacker has a number of options available to them. One of those options is to deploy their own logon script policy. In a recent engagement, this yielded administrative access on all computers where the policy was applied.
BloodHound is an excellent way to identify attack paths in this manner. When write access is identified on a GPO (GenericWrite or GenericAll) as a standard domain user, the organization should audit to ensure that permissions are properly restricted.
Furthermore, the organization should periodically audit permissions on all Group Policy Objects to ensure that permissions are correct.
User Object Attribute Modification
A similar condition arises when the attacker has control of a user with the ability to modify attributes of objects within the Active Directory schema. In the context of this post, the object type would be users. This vector is similar to the previous one. However, instead of modifying a Group Policy Object, the attacker simply modifies the ScriptPath attribute on the writable user account.
The default location of logon scripts is the \\<domain>\SYSVOL\Scripts folder. However, this attribute will also happily accept any valid UNC path. As a result, the attacker can update the attribute to point to a writable share where a malicious script can be planted.
This is another area BloodHound can help identify issues that might allow privilege escalation within the environment. A path exhibiting this condition would show GenericWrite or GenericAll between a user or group node and another user.
To catalog and audit all Active Directory delegated permissions within your environment, you can use the PowerShell script below published by Netwrix.
https://raw.githubusercontent.com/thephoton/activedirectory-delegation-searcher/master/search.ps1
Conclusion
The ability to automatically execute scripts or commands during session initialization is a very powerful feature that decreases administrative burden on IT staff. However, an attacker who stumbles on an opportunity to abuse one of the techniques described above may have a significant opportunity to escalate privilege, move laterally, and persist within the environment. Knowing this, organizations need to pay very close attention to configuration changes within the environment and ensure that in-place protections are catching common abuses.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
