Techniques

Registry Run Keys

Adversaries often seek to maintain a persistent presence within a target's computer system after initial access has been gained. One common method to achieve this persistence is by manipulating the startup processes of the host operating system. This can be accomplished in several ways, but two prevalent techniques involve the use of the Windows Registry Run Keys and the Startup Folder.

The Windows Registry is a database that stores low-level settings for the operating system and for applications that opt to use the Registry. Within the Registry, "run keys" are specific locations that dictate which programs are launched when a user logs into the system. By adding an entry to these run keys, adversaries can ensure their malicious program is executed automatically at each login.

These run keys are found under multiple hives in the Registry, such as HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE, allowing for different scopes of persistence (either individual user or system-wide). Entries in the run keys can directly reference executable files or, more subtly, list them as dependencies. For instance, using a "Depend" key with RunOnceEx allows for the loading of a Dynamic Link Library (DLL) file at logon, which might not be as readily noticed by users or security software.

Startup Folder

Another straightforward method for achieving persistence is by placing a program in the Windows startup folder. This folder is designed to automatically launch applications when a user logs into their account. There are actually two startup folders of interest: one that applies to individual user accounts and another that is system-wide, affecting all users who log into the computer.

When a program is placed in one of these startup folders, it will be executed under the context of the user who logs in, inheriting the permissions level of that account. This means if an adversary can place a malicious program in a startup folder of an account with high privileges, the malicious program will be executed with those same high privileges.

Scheduled Tasks

Adversaries frequently leverage Scheduled Tasks as a stealthy and reliable method for maintaining persistent access to compromised systems. Scheduled Tasks, a native feature of Windows operating systems, allow for the automatic execution of programs, scripts, or commands at predetermined times or intervals. This automation provides a powerful mechanism for attackers, as it enables malware to be continuously executed even after a system reboot or user logoff.

Scheduled Tasks can be configured to execute a wide range of file types, including:

• Executable files (like .exe or .dll files): These files contain pre-compiled code that can be directly executed by the operating system. Attackers can use executables to install additional malware, steal data, or disrupt system functions.

• Scripts (such as PowerShell, VBScript, or JavaScript): These are text files containing programming instructions that need to be interpreted by a specific software engine before execution. Attackers can leverage scripting languages due to their prevalence on Windows systems and their ability to automate tasks and interact with the system.

• Batch files (.bat or .cmd): These are text files containing a series of commands that are executed sequentially. Batch files are a simple but effective way for attackers to automate a sequence of malicious actions, such as downloading additional malware, modifying system settings, or deleting files.

Windows Services

Adversaries aiming to maintain a foothold within a target system often manipulate system-level processes to ensure their malicious payloads are executed repeatedly, securing their persistence within the system. One of the techniques employed involves leveraging Windows services, which are integral to the Windows operating system's functionality.

Understanding Windows Services

Windows services are specialized programs that perform functions to support other programs, particularly those that run in the background and don't require user interaction. These services can include anything from data backup utilities to server management tools and are essential for the operating system's stability and performance. When the system boots up, it automatically starts these services according to their configuration settings stored in the Windows Registry. This automatic execution feature is what adversaries exploit for persistence.

Exploitation by Adversaries

To achieve persistent execution of malicious payloads, adversaries may either install a new service or alter an existing one. By doing so, they ensure that their malicious code is executed every time the system starts, allowing them to maintain control over the compromised system, gather information, or spread within the network undetected.

The manipulation of service configurations can be achieved through various means:

• System Utilities: Tools like sc.exe (Service Controller) offer command-line options to create, modify, or delete services. Adversaries can use these tools to configure services to execute malicious executables or scripts at system startup.

• Direct Registry Modification: The Windows Registry holds the configuration information for each service, including the path to its executable file. By directly modifying these entries, adversaries can change which program a service executes, replacing legitimate services with malicious counterparts.

• Windows API Interaction: Advanced adversaries may interact directly with the Windows Application Programming Interface (API) to programmatically create, configure, or manipulate services. This method requires a deeper understanding of Windows internals but offers a more stealthy approach to achieving persistence.

DLL Side-Loading

One prevalent method of execution flow hijacking is DLL Side-Loading. This technique allows attackers to execute their malicious payloads under the guise of legitimate software processes, thereby evading detection and maintaining persistent access to the compromised system.

Understanding DLL Side-Loading

Dynamic Link Libraries (DLLs) are external code libraries used by programs to perform specific functions. When a program requires the functionality provided by a DLL, the Windows loader searches for this DLL using a predefined search order. DLL Side-Loading exploits this search process.

In a side-loading attack, adversaries place a malicious DLL into a directory from which a legitimate application will load it, usually because the malicious DLL has been given the same name as a legitimate DLL that the application expects to find and use. However, instead of merely waiting for the victim application to be launched during normal operations, adversaries might take a more proactive approach by directly invoking a legitimate application known to load the DLL in question. This ensures the execution of the malicious payload in a timely manner.

Valid Accounts

Valid accounts, whether they belong to users, administrators, or services, hold inherent privileges within a system or network. Adversaries who gain access to these accounts can leverage their associated permissions to maintain a persistent presence, often without raising immediate suspicion. This is because their actions appear to originate from legitimate users or processes.

Account Manipulation:

• Adding New Accounts: Adversaries with administrative access can create new accounts with elevated privileges. These accounts serve as backdoors, allowing them to regain access even if other compromised accounts are discovered. Attackers might create accounts with common names or usernames that blend in with legitimate accounts, making them harder to spot during audits. Unused or forgotten service accounts within an organization can be reactivated and used by attackers. These accounts are often overlooked, providing a stealthy avenue for persistence.

• Modifying Group Memberships: By adding compromised accounts to high-privilege groups (like administrators), attackers elevate their permissions, enabling them to carry out actions that wouldn't be possible with regular user accounts.

BITS Jobs

BITS (Background Intelligent Transfer Service) is a low-bandwidth, asynchronous file transfer mechanism in Windows that can be abused by adversaries to establish persistent access on a compromised system. There are two main ways an adversary can abuse BITS to achieve persistence:

• BITS Job Persistence: ​Adversaries can create a BITS job that downloads and executes a malicious payload, and then configure the job to run a program when the job completes. This ensures the malicious program is executed even after system reboots or the user logs off.

• BITS Job Notify Cmdline: Adversaries can use the SetNotifyCmdLine method of a BITS job to specify a program that runs after the job finishes transferring data or enters a particular state. This allows the adversary to persistently execute their own code on the compromised system.

Establishing Persistence with BITS Jobs

1. Creating the BITS Job: A malicious actor crafts a BITS job using various methods:

   • bitsadmin.exe (command-line tool)

   • PowerShell cmdlets (e.g., Start-BitsTransfer)

2. Defining the Task: The BITS job is configured to:

   • Transfer: Download a malicious payload from a remote server (attacker-controlled).

   • Persistence: Set to run at specific intervals (hourly, daily, on boot) or when certain triggers occur (network connectivity changes).

   • Priority: Often set to low to remain inconspicuous.

3. Hiding the Payload: The downloaded payload can be:

   • Hidden in system directories (e.g., System32)

   • Masqueraded as legitimate files

   • Obfuscated or encrypted

   • Executed directly from memory (fileless)

4. Self-Preservation: The BITS job might include mechanisms to:

   • Re-download the payload if deleted

   • Update the payload for new commands or features

5. Maintaining Control: The attacker communicates with the compromised system through:

   • The BITS job itself (sending status updates or receiving commands)

   • Additional malware components installed by the payload

   • Covert channels

Shortcut Modification

Configuring system settings to automatically execute a program during system boot or user logon is a common tactic used by adversaries to maintain persistence on a compromised system. One of the methods they employ involves the creation or modification of shortcuts, also known as symbolic links, which are designed to reference and execute other files or programs when opened.

Abuse of Shortcuts for Persistence

Shortcuts, typically found with a .lnk file extension in Windows, serve the purpose of providing quick access to files or programs located elsewhere in the system. However, this convenience also presents an opportunity for adversaries:

• Startup Folder Abuse: The startup folder in Windows is a specific directory that contains shortcut files executed automatically when a user logs into the system. By placing a malicious shortcut in the startup folder, adversaries ensure their payload is run at each logon, achieving persistence.

• Modifying Existing Shortcuts: Instead of creating a new shortcut, an adversary might modify the target path of an existing shortcut to point to their malicious executable. Consequently, when the shortcut is opened, it launches the malware, potentially granting the adversary persistent access.

• Masquerading Malicious Shortcuts: To reduce the likelihood of detection, adversaries may disguise malicious shortcuts to look like legitimate programs. They can achieve this through masquerading, changing the icon and the name of the shortcut to mimic trusted software, thereby deceiving users into executing malicious code unwittingly.

External Remote Services

The exploitation of external-facing remote services is a technique increasingly used by adversaries to maintain persistence within a target network. This approach involves leveraging the very tools and protocols that organizations rely on to facilitate remote access to internal resources from outside the physical premises. VPNs (Virtual Private Networks), Citrix systems, and various other remote access mechanisms are prime targets due to their widespread use and critical role in modern IT infrastructure.

Persistent Access through Remote Services

External-facing remote services are particularly appealing for maintaining persistence due to their design to be always accessible from outside the organization's physical premises.

• VPN Exploitation: VPNs create an encrypted tunnel between a remote user's device and the organization's network, providing a secure path for accessing internal resources. Adversaries can exploit weakly secured VPNs, either by using stolen credentials to masquerade as legitimate users or by exploiting vulnerabilities in the VPN software itself.

• Citrix and Remote Desktop Services: Services like Citrix allow for remote access to a virtual desktop or specific applications running on the organization's network. Gaining access to these services can give adversaries the same level of access as a legitimate user, including access to sensitive applications and data.

• Access Mechanism Abuse: Once inside, adversaries can use these remote services as a redundant channel for persistence. This means that even if the primary method of access they used to infiltrate the network is discovered and closed off, they can still retain access through the compromised remote service.

Web Shell

A web shell is essentially a malicious script or piece of code that is uploaded to a vulnerable web server. This script operates as a backdoor, granting attackers remote access and control over the server. Because web servers are designed to be accessible from the internet, a web shell provides the attacker with a powerful gateway into the organization's internal networks.

Web shells can be written in any scripting language supported by the server, such as PHP, ASP, JSP, or Perl. Once installed, a web shell can provide an adversary with various capabilities, including, but not limited to:

• Executing arbitrary commands on the server

• Uploading and downloading files

• Accessing and manipulating databases

• Moving laterally within the network to compromise additional systems

• Serving as a launchpad for further attacks or reconnaissance activities

DLL Search Order Hijacking

DLL Search Order Hijacking exploits the standard procedure Windows systems follow to locate and load the DLLs that programs require at runtime. By targeting applications that load DLLs without specifying their full paths, attackers can force a program to load a malicious DLL instead of the legitimate one, thus gaining execution within a system each time the victim program is run.

DLL Search Order: A predefined sequence of directories Windows checks when an application needs to load a DLL. This order typically includes:

1. The directory of the application itself

2. The system directory (e.g., C:\Windows\System32)

3. The 16-bit system directory (e.g., C:\Windows\System)

4. The Windows directory (e.g., C:\Windows)

5. Directories listed in the PATH environment variable

The Exploit: Hijacking the Search Order

1. Attackers seek to identify vulnerable applications that load DLLs without specifying their full paths. These applications rely on the system's search order to locate the DLLs.

2. The attacker places a specially crafted malicious DLL with the same name as a legitimate DLL in a directory higher up in the search order.

3. When the vulnerable application runs and tries to load the legitimate DLL, Windows finds the malicious one first and loads it instead.

4. The malicious DLL gains execution within the context of the application.

Other Methods of DLL Hijacking

DLL redirection involves altering the DLL search order by directly modifying system settings, such as registry values, or by creating a redirection file in the application's directory. This technique can force a program to load a different DLL from a new location specified by the attacker. The redirection is often achieved by changing settings that control how Windows resolves DLL paths, compelling the application to load a malicious DLL instead of the intended one.

Local Account

Local accounts are user profiles that are configured to grant access to a single system or service. Unlike domain accounts, which provide access across multiple systems within an organization, local accounts typically have permissions restricted to their host system. These accounts are used for a variety of legitimate purposes, including user access, remote support, running specific services, or performing system administration tasks.

In the context of Windows systems, for example, local accounts can be easily created using built-in command-line tools provided by the operating system, such as the net user command. With administrative access, an adversary can execute a command like net user /add [username] [password] to create a new user account with desired credentials.

Local accounts can be hidden from standard user interfaces, making them difficult for system administrators to discover. Attackers can use various techniques to achieve this, including:

• Modifying Registry Entries: By manipulating specific registry keys, attackers can prevent local accounts from showing up in user lists or login screens.

• Using Obscure Account Names: Attackers might choose names that blend in with system accounts or appear non-threatening to avoid scrutiny.

Adversarial Use of Local Accounts

• Stealth: Since local accounts are a standard feature of operating systems and are commonly used for legitimate purposes, the creation of an additional account might not immediately raise suspicion, especially in environments where monitoring and auditing practices are lax.

• Persistence: Once created, these accounts provide a dependable method for attackers to regain access to compromised systems, serving as a fallback mechanism if other access vectors are closed.

Winlogon Helper DLL

Winlogon.exe is a critical Windows component that plays a key role in managing user logon and logoff processes. It handles the loading of user profiles, facilitates the locking and unlocking of the user interface, and manages other logon/logoff related functionalities.

Registry Keys and Persistence

The Windows Registry is a hierarchical database that stores low-level settings for the operating system and for applications that opt to use the Registry. Within this database, certain subkeys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon are specifically designed to manage additional helper programs that Winlogon uses to facilitate its operations. These include:

• Userinit: Specifies the program that is launched immediately after a user logs on. By default, this points to userinit.exe, but adversaries can modify it to include malicious executables.

• Shell: Determines the program that serves as the system shell; by default, this is explorer.exe. Malicious modifications can replace the shell with a harmful executable that would run after logon.

• Notify: Contains subkeys that specify DLLs to be loaded at user logon. Malicious entries can be added here to ensure a DLL is executed during the logon process.

Adversaries may tamper with these and other related Registry keys to force Winlogon to load and execute malicious DLLs and/or executables during the logon process. This technique provides a reliable means of executing malicious code each time a user logs into the system, thereby establishing persistence.

Bootkit

A bootkit is a type of malware designed to infect the boot sectors of a hard drive, including critical components like the Master Boot Record (MBR) and Volume Boot Record (VBR). The MBR is the first sector of a computer's hard drive that the BIOS loads and executes to start the boot loader, which then initiates the loading of the operating system. Similarly, the VBR is found at the beginning of each partition on the disk, playing a crucial role in the boot process for the specific partition.

By modifying these areas, an adversary can divert the normal boot process to execute malicious code before the operating system loads. This gives the bootkit a high level of stealth and control, allowing it to load drivers, services, or kernel modules that can compromise the system's integrity from the outset of the boot process.

The Threat Posed by Bootkits

The primary threat of bootkits lies in their ability to persist at a fundamental level of the computing environment:

• Stealth: Since bootkits load before the operating system and any security software, they can effectively hide their presence, manipulating the system from the ground up without detection.

• Persistence: By residing in the boot sector, a bootkit ensures it is executed with every system start, making it an extremely persistent form of malware. This persistence remains intact even through operating system re-installations, as long as the boot sectors are not explicitly overwritten during the process.

• Control: Bootkits can bypass operating system security mechanisms by gaining control of the system at the earliest stage of the boot process. This allows for the disabling of security software and the installation of additional malware components without restriction.

Logon Script

In Windows environments, adversaries often leverage logon scripts—scripts that are executed automatically when a user logs into the system—to ensure their malicious code is run persistently, thus maintaining their presence on the compromised system.

Windows provides the capability to run scripts automatically at user logon, a feature intended for legitimate administrative purposes such as setting up the user environment, mapping network drives, or applying updates. These scripts can be specified for individual users or groups through various methods, including Group Policy Objects (GPO) or directly via the Windows Registry. One such method involves adding a path to the desired script in the HKCU\Environment\UserInitMprLogonScript Registry key. When a user logs on, the system processes this entry and executes the specified script, making it an attractive vector for adversaries seeking to automate the execution of malicious code.

Access Requirements

The ability to add or modify logon scripts for persistence typically requires access to the user's account or higher-level privileges:

• Local Credentials: If the adversary's goal is to maintain persistence on a single system for a specific user, modifying the HKCU\Environment\UserInitMprLogonScript Registry key under the user's profile may suffice. This requires access to the user's credentials.

• Administrator Account: To apply logon scripts across multiple users or the entire system, administrator-level access is generally required. This allows the adversary to modify group policies or make broader changes to the Registry affecting all users.