Class: Backdoor
Backdoors are designed to give malicious users remote control over an infected computer. In terms of functionality, Backdoors are similar to many administration systems designed and distributed by software developers. These types of malicious programs make it possible to do anything the author wants on the infected computer: send and receive files, launch files or delete them, display messages, delete data, reboot the computer, etc. The programs in this category are often used in order to unite a group of victim computers and form a botnet or zombie network. This gives malicious users centralized control over an army of infected computers which can then be used for criminal purposes. There is also a group of Backdoors which are capable of spreading via networks and infecting other computers as Net-Worms do. The difference is that such Backdoors do not spread automatically (as Net-Worms do), but only upon a special “command” from the malicious user that controls them.Read more
Platform: Win32
Win32 is an API on Windows NT-based operating systems (Windows XP, Windows 7, etc.) that supports execution of 32-bit applications. One of the most widespread programming platforms in the world.Family: PPdoor
No family descriptionExamples
73A7EEE5BE8B71F6DA38C89022A45BAEAFFDA69A902A16D9A00F51888D447501
E656F148514391B82C095A265B8A7ADC
21FD7F46BD68151AAF35BE261BACE487
0DEEF6BB33B9CEEF60480E8B30D72E70
Tactics and Techniques: Mitre*
Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token.
An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These token can then be applied to an existing process (i.e. Token Impersonation/Theft) or used to spawn a new process (i.e. Create Process with Token). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.(Citation: Pentestlab Token Manipulation)
Any standard user can use the runas command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account. There are also other mechanisms, such as Active Directory fields, that can be used to modify access tokens.
Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token.
An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These token can then be applied to an existing process (i.e. Token Impersonation/Theft) or used to spawn a new process (i.e. Create Process with Token). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.(Citation: Pentestlab Token Manipulation)
Any standard user can use the runas command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account. There are also other mechanisms, such as Active Directory fields, that can be used to modify access tokens.
Adversaries may clear Windows Event Logs to hide the activity of an intrusion. Windows Event Logs are a record of a computer’s alerts and notifications. There are three system-defined sources of events: System, Application, and Security, with five event types: Error, Warning, Information, Success Audit, and Failure Audit.
The event logs can be cleared with the following utility commands:
* wevtutil cl system
* wevtutil cl application
* wevtutil cl security
These logs may also be cleared through other mechanisms, such as the event viewer GUI or PowerShell. For example, adversaries may use the PowerShell command Remove-EventLog -LogName Security to delete the Security EventLog and after reboot, disable future logging. Note: events may still be generated and logged in the .evtx file between the time the command is run and the reboot.(Citation: disable_win_evt_logging)
Adversaries may clear Windows Event Logs to hide the activity of an intrusion. Windows Event Logs are a record of a computer’s alerts and notifications. There are three system-defined sources of events: System, Application, and Security, with five event types: Error, Warning, Information, Success Audit, and Failure Audit.
The event logs can be cleared with the following utility commands:
* wevtutil cl system
* wevtutil cl application
* wevtutil cl security
These logs may also be cleared through other mechanisms, such as the event viewer GUI or PowerShell. For example, adversaries may use the PowerShell command Remove-EventLog -LogName Security to delete the Security EventLog and after reboot, disable future logging. Note: events may still be generated and logged in the .evtx file between the time the command is run and the reboot.(Citation: disable_win_evt_logging)
Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token.
An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These token can then be applied to an existing process (i.e. Token Impersonation/Theft) or used to spawn a new process (i.e. Create Process with Token). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.(Citation: Pentestlab Token Manipulation)
Any standard user can use the runas command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account. There are also other mechanisms, such as Active Directory fields, that can be used to modify access tokens.
Adversaries may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (LSASS). After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. These credential materials can be harvested by an administrative user or SYSTEM and used to conduct Lateral Movement using Use Alternate Authentication Material.
As well as in-memory techniques, the LSASS process memory can be dumped from the target host and analyzed on a local system.
For example, on the target host use procdump:
* procdump -ma lsass.exe lsass_dump
Locally, mimikatz can be run using:
* sekurlsa::Minidump lsassdump.dmp
* sekurlsa::logonPasswords
Built-in Windows tools such as comsvcs.dll can also be used:
* rundll32.exe C:WindowsSystem32comsvcs.dll MiniDump PID lsass.dmp full(Citation: Volexity Exchange Marauder March 2021)(Citation: Symantec Attacks Against Government Sector)
Windows Security Support Provider (SSP) DLLs are loaded into LSASS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user’s Domain password or smart card PINs. The SSP configuration is stored in two Registry keys: HKLMSYSTEMCurrentControlSetControlLsaSecurity Packages and HKLMSYSTEMCurrentControlSetControlLsaOSConfigSecurity Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.(Citation: Graeber 2014)
The following SSPs can be used to access credentials:
* Msv: Interactive logons, batch logons, and service logons are done through the MSV authentication package.
* Wdigest: The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges.(Citation: TechNet Blogs Credential Protection)
* Kerberos: Preferred for mutual client-server domain authentication in Windows 2000 and later.
* CredSSP: Provides SSO and Network Level Authentication for Remote Desktop Services.(Citation: TechNet Blogs Credential Protection)
Adversaries may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (LSASS). After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. These credential materials can be harvested by an administrative user or SYSTEM and used to conduct Lateral Movement using Use Alternate Authentication Material.
As well as in-memory techniques, the LSASS process memory can be dumped from the target host and analyzed on a local system.
For example, on the target host use procdump:
* procdump -ma lsass.exe lsass_dump
Locally, mimikatz can be run using:
* sekurlsa::Minidump lsassdump.dmp
* sekurlsa::logonPasswords
Built-in Windows tools such as comsvcs.dll can also be used:
* rundll32.exe C:WindowsSystem32comsvcs.dll MiniDump PID lsass.dmp full(Citation: Volexity Exchange Marauder March 2021)(Citation: Symantec Attacks Against Government Sector)
Windows Security Support Provider (SSP) DLLs are loaded into LSASS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user’s Domain password or smart card PINs. The SSP configuration is stored in two Registry keys: HKLMSYSTEMCurrentControlSetControlLsaSecurity Packages and HKLMSYSTEMCurrentControlSetControlLsaOSConfigSecurity Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.(Citation: Graeber 2014)
The following SSPs can be used to access credentials:
* Msv: Interactive logons, batch logons, and service logons are done through the MSV authentication package.
* Wdigest: The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges.(Citation: TechNet Blogs Credential Protection)
* Kerberos: Preferred for mutual client-server domain authentication in Windows 2000 and later.
* CredSSP: Provides SSO and Network Level Authentication for Remote Desktop Services.(Citation: TechNet Blogs Credential Protection)
* © 2024 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.