Class: Email-Worm
Email-Worms spread via email. The worm sends a copy of itself as an attachment to an email message or a link to its file on a network resource (e.g. a URL to an infected file on a compromised website or a hacker-owned website). In the first case, the worm code activates when the infected attachment is opened (launched). In the second case, the code is activated when the link to the infected file is opened. In both case, the result is the same: the worm code is activated. Email-Worms use a range of methods to send infected emails. The most common are: using a direct connection to a SMTP server using the email directory built into the worm’s code using MS Outlook services using Windows MAPI functions. Email-Worms use a number of different sources to find email addresses to which infected emails will be sent: the address book in MS Outlook a WAB address database .txt files stored on the hard drive: the worm can identify which strings in text files are email addresses emails in the inbox (some Email-Worms even “reply” to emails found in the inbox) Many Email-Worms use more than one of the sources listed above. There are also other sources of email addresses, such as address books associated with web-based email services.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: Zhelatin
No family descriptionExamples
D936B40494A379C7416279B73008E1760498E515F7A91AE1EA9A5EFF429C5E32
34279C994A471CE995A7AFD8071E50A6
D808F1AC14EBAB5338554D58DE6A7F90
7C4F7C1B8585F4B222D955FC69869162
Tactics and Techniques: Mitre*
Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions.(Citation: TechNet Services) Windows service configuration information, including the file path to the service’s executable or recovery programs/commands, is stored in the Windows Registry.
Adversaries may install a new service or modify an existing service to execute at startup in order to persist on a system. Service configurations can be set or modified using system utilities (such as sc.exe), by directly modifying the Registry, or by interacting directly with the Windows API.
Adversaries may also use services to install and execute malicious drivers. For example, after dropping a driver file (ex: `.sys`) to disk, the payload can be loaded and registered via Native API functions such as `CreateServiceW()` (or manually via functions such as `ZwLoadDriver()` and `ZwSetValueKey()`), by creating the required service Registry values (i.e. Modify Registry), or by using command-line utilities such as `PnPUtil.exe`.(Citation: Symantec W.32 Stuxnet Dossier)(Citation: Crowdstrike DriveSlayer February 2022)(Citation: Unit42 AcidBox June 2020) Adversaries may leverage these drivers as Rootkits to hide the presence of malicious activity on a system. Adversaries may also load a signed yet vulnerable driver onto a compromised machine (known as “Bring Your Own Vulnerable Driver” (BYOVD)) as part of Exploitation for Privilege Escalation.(Citation: ESET InvisiMole June 2020)(Citation: Unit42 AcidBox June 2020)
Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges. Adversaries may also directly start services through Service Execution. To make detection analysis more challenging, malicious services may also incorporate Masquerade Task or Service (ex: using a service and/or payload name related to a legitimate OS or benign software component).
Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions.(Citation: TechNet Services) Windows service configuration information, including the file path to the service’s executable or recovery programs/commands, is stored in the Windows Registry.
Adversaries may install a new service or modify an existing service to execute at startup in order to persist on a system. Service configurations can be set or modified using system utilities (such as sc.exe), by directly modifying the Registry, or by interacting directly with the Windows API.
Adversaries may also use services to install and execute malicious drivers. For example, after dropping a driver file (ex: `.sys`) to disk, the payload can be loaded and registered via Native API functions such as `CreateServiceW()` (or manually via functions such as `ZwLoadDriver()` and `ZwSetValueKey()`), by creating the required service Registry values (i.e. Modify Registry), or by using command-line utilities such as `PnPUtil.exe`.(Citation: Symantec W.32 Stuxnet Dossier)(Citation: Crowdstrike DriveSlayer February 2022)(Citation: Unit42 AcidBox June 2020) Adversaries may leverage these drivers as Rootkits to hide the presence of malicious activity on a system. Adversaries may also load a signed yet vulnerable driver onto a compromised machine (known as “Bring Your Own Vulnerable Driver” (BYOVD)) as part of Exploitation for Privilege Escalation.(Citation: ESET InvisiMole June 2020)(Citation: Unit42 AcidBox June 2020)
Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges. Adversaries may also directly start services through Service Execution. To make detection analysis more challenging, malicious services may also incorporate Masquerade Task or Service (ex: using a service and/or payload name related to a legitimate OS or benign software component).
Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions.(Citation: TechNet Services) Windows service configuration information, including the file path to the service’s executable or recovery programs/commands, is stored in the Windows Registry.
Adversaries may install a new service or modify an existing service to execute at startup in order to persist on a system. Service configurations can be set or modified using system utilities (such as sc.exe), by directly modifying the Registry, or by interacting directly with the Windows API.
Adversaries may also use services to install and execute malicious drivers. For example, after dropping a driver file (ex: `.sys`) to disk, the payload can be loaded and registered via Native API functions such as `CreateServiceW()` (or manually via functions such as `ZwLoadDriver()` and `ZwSetValueKey()`), by creating the required service Registry values (i.e. Modify Registry), or by using command-line utilities such as `PnPUtil.exe`.(Citation: Symantec W.32 Stuxnet Dossier)(Citation: Crowdstrike DriveSlayer February 2022)(Citation: Unit42 AcidBox June 2020) Adversaries may leverage these drivers as Rootkits to hide the presence of malicious activity on a system. Adversaries may also load a signed yet vulnerable driver onto a compromised machine (known as “Bring Your Own Vulnerable Driver” (BYOVD)) as part of Exploitation for Privilege Escalation.(Citation: ESET InvisiMole June 2020)(Citation: Unit42 AcidBox June 2020)
Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges. Adversaries may also directly start services through Service Execution. To make detection analysis more challenging, malicious services may also incorporate Masquerade Task or Service (ex: using a service and/or payload name related to a legitimate OS or benign software component).
Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it starts programs or applications called services that perform background system functions.(Citation: TechNet Services) Windows service configuration information, including the file path to the service’s executable or recovery programs/commands, is stored in the Windows Registry.
Adversaries may install a new service or modify an existing service to execute at startup in order to persist on a system. Service configurations can be set or modified using system utilities (such as sc.exe), by directly modifying the Registry, or by interacting directly with the Windows API.
Adversaries may also use services to install and execute malicious drivers. For example, after dropping a driver file (ex: `.sys`) to disk, the payload can be loaded and registered via Native API functions such as `CreateServiceW()` (or manually via functions such as `ZwLoadDriver()` and `ZwSetValueKey()`), by creating the required service Registry values (i.e. Modify Registry), or by using command-line utilities such as `PnPUtil.exe`.(Citation: Symantec W.32 Stuxnet Dossier)(Citation: Crowdstrike DriveSlayer February 2022)(Citation: Unit42 AcidBox June 2020) Adversaries may leverage these drivers as Rootkits to hide the presence of malicious activity on a system. Adversaries may also load a signed yet vulnerable driver onto a compromised machine (known as “Bring Your Own Vulnerable Driver” (BYOVD)) as part of Exploitation for Privilege Escalation.(Citation: ESET InvisiMole June 2020)(Citation: Unit42 AcidBox June 2020)
Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges. Adversaries may also directly start services through Service Execution. To make detection analysis more challenging, malicious services may also incorporate Masquerade Task or Service (ex: using a service and/or payload name related to a legitimate OS or benign software component).
* © 2024 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.