mirror of
https://github.com/MBCProject/mbc-markdown
synced 2026-06-08 11:36:36 +00:00
Staging (#85)
* Janet mbc updates (#84) * Added Unprotect techniques to respective behaviors and or methods. * Unprotect updates MBC * Unprotect techniques mapped in MBC --------- Co-authored-by: Ryan Xu <ryanxu@wustl.edu> * Fixing redundant Detection sec in sandbox detect --------- Co-authored-by: quant23va <105243450+quant23va@users.noreply.github.com>
This commit is contained in:
Ryan Xu
@@ -42,40 +42,40 @@ Details on methods of detecting debuggers are given in the references; many are
|
||||
|---|---|---|
|
||||
|**API Hook Detection**|B0001.001|Module bounds based [[7]](#7).|
|
||||
|**Anti-debugging Instructions**|B0001.034|Malware code contains mnemonics related to anti-debugging (e.g., rdtsc, icebp).|
|
||||
|**CheckRemoteDebuggerPresent**|B0001.002|The kernel32!CheckRemoteDebuggerPresent function calls NtQueryInformationProcess with ProcessInformationClass parameter set to 7 (ProcessDebugPort constant).|
|
||||
|**CheckRemoteDebuggerPresent**|B0001.002|The kernel32!CheckRemoteDebuggerPresent function calls NtQueryInformationProcess with ProcessInformationClass parameter set to 7 (ProcessDebugPort constant).This method is related to Unprotect technique U0121.|
|
||||
|**Check Processes**|B0001.038|The malware may check running processes for specific strings such as "malw" to detect a analysis environment.|
|
||||
|**CloseHandle**|B0001.003|(NtClose); If an invalid handle is passed to the CloseHandle function and a debugger is present, then an EXCEPTION_INVALID_HANDLE (0xC0000008) exception will be raised. [[7]](#7)|
|
||||
|**CloseHandle**|B0001.003|(NtClose); If an invalid handle is passed to the CloseHandle function and a debugger is present, then an EXCEPTION_INVALID_HANDLE (0xC0000008) exception will be raised. [[7]](#7) This method is related to Unprotect technique U0114.|
|
||||
|**Debugger Artifacts**|B0001.004|Malware may detect a debugger by its artifact (window title, device driver, exports, etc.).|
|
||||
|**Hardware Breakpoints**|B0001.005|(SEH/GetThreadContext); Debug registers will indicate the presence of a debugger. See [[7]](#7) for details.|
|
||||
|**Interruption**|B0001.006|If an interruption is mishandled by the debugger, it can cause a single-byte instruction to be inadvertently skipped, which can be detected by malware. Examples include Interrupt 0x2d and Interrupt 1 [[7]](#7).|
|
||||
|**IsDebuggerPresent**|B0001.008|The kernel32!IsDebuggerPresent API function call checks the PEB BeingDebugged flag to see if the calling process is being debugged. It returns 1 if the process is being debugged, 0 otherwise. This is one of the most common ways of debugger detection.|
|
||||
|**Memory Breakpoints**|B0001.009|(PAGE_GUARD); Guard pages trigger an exception the first time they are accessed and can be used to detect a debugger. See [[7]](#7) for details.|
|
||||
|**Hardware Breakpoints**|B0001.005|(SEH/GetThreadContext); Debug registers will indicate the presence of a debugger. See [[7]](#7) for details. This method is related to Unprotect technique U0127.|
|
||||
|**Interruption**|B0001.006|If an interruption is mishandled by the debugger, it can cause a single-byte instruction to be inadvertently skipped, which can be detected by malware. Examples include Interrupt 0x2d and Interrupt 1 [[7]](#7). This method is related to Unprotect technique U0129.|
|
||||
|**IsDebuggerPresent**|B0001.008|The kernel32!IsDebuggerPresent API function call checks the PEB BeingDebugged flag to see if the calling process is being debugged. It returns 1 if the process is being debugged, 0 otherwise. This is one of the most common ways of debugger detection.This method is related to Unprotect technique U0122.|
|
||||
|**Memory Breakpoints**|B0001.009|(PAGE_GUARD); Guard pages trigger an exception the first time they are accessed and can be used to detect a debugger. See [[7]](#7) for details. This method is related to Unprotect technique U0102.|
|
||||
|**Memory Write Watching**|B0001.010|[[7]](#7)|
|
||||
|**Monitoring Thread**|B0001.011|Malware may spawn a monitoring thread to detect tampering, breakpoints, etc.|
|
||||
|**NtQueryInformationProcess**|B0001.012|Calling NtQueryInformationProcess with its ProcessInformationClass parameter set to 0x07 (ProcessDebugPort constant) will cause the system to set ProcessInformation to -1 if the process is being debugged. Calling with ProcessInformationClass set to 0x0E (ProcessDebugFlags) or 0x11 (ProcessDebugObject) are used similarly. Testing "ProcessDebugPort" is equivalent to using the kernel32!CheckRemoteDebuggerPresent API call (see next method).|
|
||||
|**NtQueryObject**|B0001.013|The ObjectTypeInformation and ObjectAllTypesInformation flags are checked for debugger detection.|
|
||||
|**NtSetInformationThread**|B0001.014|Calling this API with a fake class length or thread handle can indicate whether it is hooked. After calling NtSetInformationThread properly, the HideThreadFromDebugger flag is checked with the NtQueryInformationThread API. [[7]](#7)|
|
||||
|**NtQueryInformationProcess**|B0001.012|Calling NtQueryInformationProcess with its ProcessInformationClass parameter set to 0x07 (ProcessDebugPort constant) will cause the system to set ProcessInformation to -1 if the process is being debugged. Calling with ProcessInformationClass set to 0x0E (ProcessDebugFlags) or 0x11 (ProcessDebugObject) are used similarly. Testing "ProcessDebugPort" is equivalent to using the kernel32!CheckRemoteDebuggerPresent API call (see next method). This method is related to Unprotect technique U0120.|
|
||||
|**NtQueryObject**|B0001.013|The ObjectTypeInformation and ObjectAllTypesInformation flags are checked for debugger detection. This method is related to Unprotect technique U0118.|
|
||||
|**NtSetInformationThread**|B0001.014|Calling this API with a fake class length or thread handle can indicate whether it is hooked. After calling NtSetInformationThread properly, the HideThreadFromDebugger flag is checked with the NtQueryInformationThread API. [[7]](#7)This method is related to Unprotect technique U0119.|
|
||||
|**NtYieldExecution/SwitchToThread**|B0001.015|[[7]](#7)|
|
||||
|**OutputDebugString**|B0001.016|(GetLastError); The OutputDebugString function will demonstrate different behavior depending whether or not a debugger is present. See [[7]](#7) for details.|
|
||||
|**OutputDebugString**|B0001.016|(GetLastError); The OutputDebugString function will demonstrate different behavior depending whether or not a debugger is present. See [[7]](#7) for details. This method is related to Unprotect technique U0117.|
|
||||
|**Page Exception Breakpoint Detection**|B0001.017|[[7]](#7)|
|
||||
|**Parent Process**|B0001.018|(Explorer.exe); Executing an application by a debugger will result in the parent process being the debugger process rather than the shell process (Explorer.exe) or the command line. Malware checks its parent process; if it's not explorer.exe, it's assumed to be a debugger. [[7]](#7)|
|
||||
|**Process Environment Block**|B0001.019|The Process Environment Block (PEB) is a Windows data structure associated with each process that contains several fields, such as "BeingDebugged," "NtGlobalFlag," and "IsDebugged". Testing the value of this PEB field of a particular process can indicate whether the process is being debugged. Testing "BeingDebugged" is equivalent to using the kernel32!IsDebuggerPresent API call (see separate method).|
|
||||
|**Process Environment Block**|B0001.019|The Process Environment Block (PEB) is a Windows data structure associated with each process that contains several fields, such as "BeingDebugged," "NtGlobalFlag," and "IsDebugged". Testing the value of this PEB field of a particular process can indicate whether the process is being debugged. Testing "BeingDebugged" is equivalent to using the kernel32!IsDebuggerPresent API call (see separate method). This method is related to Unprotect technique U0113.|
|
||||
|**Process Environment Block BeingDebugged**|B0001.035|The BeingDebugged field is tested to determine whether the process is being debugged.|
|
||||
|**Process Environment Block IsDebugged**|B0001.037|The IsDebugged field is tested to determine whether the process is being debugged.|
|
||||
|**Process Environment Block NtGlobalFlag**|B0001.036|The NtGlobalFlag field is tested to determine whether the process is being debugged.|
|
||||
|**Process Environment Block NtGlobalFlag**|B0001.036|The NtGlobalFlag field is tested to determine whether the process is being debugged. This method is related to Unprotect technique U0111.|
|
||||
|**Process Jobs**|B0001.020|[[7]](#7)|
|
||||
|**ProcessHeap**|B0001.021|Process heaps are affected by debuggers. Malware can detect a debugger by checking heap header fields such as Flags (debugger present if value greater than 2) or ForceFlags (debugger present if value greater than 0).|
|
||||
|**ProcessHeap**|B0001.021|Process heaps are affected by debuggers. Malware can detect a debugger by checking heap header fields such as Flags (debugger present if value greater than 2) or ForceFlags (debugger present if value greater than 0).This method is related to Unprotect technique U0112.|
|
||||
|**RtlAdjustPrivilege**|B0001.022|Malware may call RtlAdjustPrivilege to detect if a debugger is attached (or to prevent a debugger from attaching).|
|
||||
|**SeDebugPrivilege**|B0001.023|(Csrss.exe); Using the OpenProcess function on the csrss.exe process can detect a debugger. [[7]](#7)|
|
||||
|**SetHandleInformation**|B0001.024|(Protected Handle)|
|
||||
|**Software Breakpoints**|B0001.025|(INT3/0xCC)|
|
||||
|**Software Breakpoints**|B0001.025|(INT3/0xCC) This method is related to Unprotect technique U0105.|
|
||||
|**Stack Canary**|B0001.026|Similar to the anti-exploitation method of the same name, malware may try to detect mucking with values on the stack.|
|
||||
|**TIB Aware**|B0001.027|Malware may access information in the Thread Information Block (TIB) for debug detection or process obfuscation detection. The TIB can be accessed as an offset of the segment register (e.g., fs:[20h]).|
|
||||
|**TLS Callbacks**|B0001.029|[[7]](#7)|
|
||||
|**Timing/Delay Check**|B0001.028|Malware may compare time between two points to detect unusual execution, such as the (relative) massive delays introduced by debugging.|
|
||||
|**Timing/Delay Check GetTickCount**|B0001.032|Malware uses GetTickCount function in a timing/delay check.|
|
||||
|**Timing/Delay Check QueryPerformanceCounter**|B0001.033|Malware uses QueryPerformanceCounter in a timing/delay check.|
|
||||
|**UnhandledExceptionFilter**|B0001.030|The UnhandledExceptionFilter function is called if no registered exception handlers exist, but it will not be reached if a debugger is present. See [[7]](#7) for details.|
|
||||
|**Timing/Delay Check**|B0001.028|Malware may compare time between two points to detect unusual execution, such as the (relative) massive delays introduced by debugging. This method is related to Unprotect techniques U110 and U1308.|
|
||||
|**Timing/Delay Check GetTickCount**|B0001.032|Malware uses GetTickCount function in a timing/delay check. This method is related to Unprotect technique U0125.|
|
||||
|**Timing/Delay Check QueryPerformanceCounter**|B0001.033|Malware uses QueryPerformanceCounter in a timing/delay check. This method is related to Unprotect techniques U110 and U1309.|
|
||||
|**UnhandledExceptionFilter**|B0001.030|The UnhandledExceptionFilter function is called if no registered exception handlers exist, but it will not be reached if a debugger is present. See [[7]](#7) for details. Row 11 This method is related to Unprotect technique U0108.|
|
||||
|**WudfIsAnyDebuggerPresent**|B0001.031|Includes use of WudfIsAnyDebuggerPresent, WudfIsKernelDebuggerPresent, WudfIsUserDebuggerPresent.|
|
||||
|
||||
## Use in Malware
|
||||
|
||||
@@ -49,7 +49,7 @@ The related **Debugger Evasion ([T1622](https://attack.mitre.org/techniques/T162
|
||||
|**Code Integrity Check**|B0002.005|Check that the unpacking code is unmodified. Variation exists where unpacking code is part of the "key" used to unpack, therefore any Software Breakpoints during debugging causes unpacking to completely fail or result in malformed unpacked code.|
|
||||
|**Exception Misdirection**|B0002.006|Using exception handling (SEH) to cause flow of program to non-obvious paths.|
|
||||
|**Get Base Indirectly**|B0002.007|CALL to a POP; finds base of code or data, often the packed version of the code; also used often in obfuscated/packed shellcode.|
|
||||
|**Guard Pages**|B0002.008|Encrypt blocks of code individually and decrypt temporarily only upon execution.|
|
||||
|**Guard Pages**|B0002.008|Encrypt blocks of code individually and decrypt temporarily only upon execution. This method is related to Unprotect technique U0102.|
|
||||
|**Hook Interrupt**|B0002.009|Modification of interrupt vector or descriptor tables.|
|
||||
|**Import Obfuscation**|B0002.010|Add obfuscation between imports calls and APIs.|
|
||||
|**Inlining**|B0002.011|Variation of static linking where full API code inserted everywhere it would have been called.|
|
||||
|
||||
@@ -43,10 +43,10 @@ The related **Virtualization/Sandbox Evasion ([T1497](https://attack.mitre.org/t
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Alternative ntdll.dll**|B0003.001|A copy of ntdll.dll is dropped to the filesystem and then loaded. This alternative DLL is used to execute function calls to evade sandboxes which use hooking in the operating system's ntdll.dll.|
|
||||
|**API Hammering**|B0003.012|Uses of a huge number of calls to Windows APIs as a form of extended sleep to evade analysis in sandbox environments.|
|
||||
|**API Hammering**|B0003.012|Uses of a huge number of calls to Windows APIs as a form of extended sleep to evade analysis in sandbox environments. This method is related to Unprotect technique U1305.|
|
||||
|**Code Integrity Check**|B0003.011|Compares memory-based and disk-based versions of itself. If differences are detected, the malware alters its execution, possibly acting destructively.|
|
||||
|**Data Flood**|B0003.002|Overloads a sandbox by generating a flood of meaningless behavioral data. [[1]](#1)|
|
||||
|**Delayed Execution**|B0003.003|Stalling code is typically executed before any malicious behavior. The malware's aim is to delay the execution of the malicious activity long enough so that an automated dynamic analysis system fails to extract the interesting malicious behavior. This method is very similar to ATT&CK's [Virtualization/Sandbox Evasion: Time Based Evasion](https://attack.mitre.org/techniques/T1497/003/) sub-technique.|
|
||||
|**Delayed Execution**|B0003.003|Stalling code is typically executed before any malicious behavior. The malware's aim is to delay the execution of the malicious activity long enough so that an automated dynamic analysis system fails to extract the interesting malicious behavior. This method is very similar to ATT&CK's [Virtualization/Sandbox Evasion: Time Based Evasion](https://attack.mitre.org/techniques/T1497/003/) sub-technique. This method is related to Unprotect technique U1318.|
|
||||
|**Demo Mode**|B0003.004|Inclusion of a demo binary/mode that is executed when token is absent or not privileged enough.|
|
||||
|**Drop Code**|B0003.005|Original file is written to disk then executed. May confuse some sandboxes, especially if the dropped executable must be provided specific arguments and the original dropper is not associated with the drop file(s).|
|
||||
|**Encode File**|B0003.006|Encode a file on disk, such as an implant's config file.|
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
|
||||
# Memory Dump Evasion
|
||||
|
||||
Malware hinders retrieval and/or discovery of the contents of the physical memory of the system on which the malware instance is executing [[1]](#1).
|
||||
Malware hinders retrieval and/or discovery of the contents of the physical memory of the system on which the malware instance is executing [[1]](#1).
|
||||
|
||||
## Methods
|
||||
|
||||
@@ -41,7 +41,7 @@ Malware hinders retrieval and/or discovery of the contents of the physical memor
|
||||
|**Erase the PE header**|B0006.002|Erase PE header from memory.|
|
||||
|**Feed Misinformation**|B0006.008|API behavior can be altered to prevent memory dumps. For example, inaccurate data can be reported when the contents of the physical memory of the system on which the malware instance is executing is retrieved. See [Hooking](../credential-access/hooking.md).|
|
||||
|**Flow Opcode Obstruction**|B0006.009|Flow opcodes (e.g., jumps, loops) are removed and emulated (or decrypted) by the packer during execution, resulting in incorrect dumps. [[4]](#4).|
|
||||
|**Guard Pages**|B0006.006|Encrypt blocks of code individually and decrypt temporarily only upon execution.|
|
||||
|**Guard Pages**|B0006.006|Encrypt blocks of code individually and decrypt temporarily only upon execution. This method is related to Unprotect technique U0102.|
|
||||
|**Hide virtual memory**|B0006.003|Hide arbitrary segments of virtual memory.|
|
||||
|**On-the-Fly APIs**|B0006.007|Resolve API addresses before each use to prevent complete dumping.|
|
||||
|**SizeOfImage**|B0006.004|Set the SizeOfImage field of PEB.LoaderData to be huge.|
|
||||
|
||||
@@ -41,12 +41,12 @@ The related **Virtualization/Sandbox Evasion ([T1497](https://attack.mitre.org/t
|
||||
|---|---|---|
|
||||
|**Check Clipboard Data**|B0007.001|Checks clipboard data which can be used to detect whether execution is inside a sandbox.|
|
||||
|**Check Files**|B0007.002|Sandboxes create files on the file system. Malware can check the different folders to find sandbox artifacts.|
|
||||
|**Human User Check**|B0007.003|Detects whether there is any "user" activity on the machine, such as the movement of the mouse cursor, non-default wallpaper, or recently opened Office files. Directories or file might be counted. If there is no human activity, the machine is suspected to be a virtualized machine and/or sandbox. Other items used to detect a user: mouse clicks (single/double), DialogBox, scrolling, color of background pixel [[3]](#3). This method is similar to ATT&CK's [Virtualization/Sandbox Evasion: User Activity Based Checks](https://attack.mitre.org/techniques/T1497/002/) sub-technique.|
|
||||
|**Human User Check**|B0007.003|Detects whether there is any "user" activity on the machine, such as the movement of the mouse cursor, non-default wallpaper, or recently opened Office files. Directories or file might be counted. If there is no human activity, the machine is suspected to be a virtualized machine and/or sandbox. Other items used to detect a user: mouse clicks (single/double), DialogBox, scrolling, color of background pixel [[3]](#3). This method is similar to ATT&CK's [Virtualization/Sandbox Evasion: User Activity Based Checks](https://attack.mitre.org/techniques/T1497/002/) sub-technique. This method is also related to Unprotect techniques U1316 and U1317.|
|
||||
|**Injected DLL Testing**|B0007.004|Testing for the name of a particular DLL that is known to be injected by a sandbox for API hooking is a common way of detecting sandbox environments. This can be achieved through the kernel32!GetModuleHandle API call and other means.|
|
||||
|**Product Key/ID Testing**|[B0007.005](#b0007005-snippet)|Checking for a particular product key/ID associated with a sandbox environment (commonly associated with the Windows host OS used in the environment) can be used to detect whether a malware instance is being executed in a particular sandbox. This can be achieved through several means, including testing for the Key/ID in the Windows registry.|
|
||||
|**Screen Resolution Testing**|B0007.006|Sandboxes aren't used in the same manner as a typical user environment, so most of the time the screen resolution stays at the minimum 800x600 or lower. No one is actually working on a such small screen. Malware could potentially detect the screen resolution to determine if it's a user machine or a sandbox.|
|
||||
|**Self Check**|B0007.007|Malware may check its own characteristics to determine whether it's running in a sandbox. For example, a malicious Office document might check its file name or VB project name.|
|
||||
|**Timing/Date Check**|B0007.008|Calling GetSystemTime or equiv and only executing code if the current date/hour/minute/second passes some check. Often this is for running only after or only until a specific date. This behavior can be mitigated in non-automated analysis environments.|
|
||||
|**Screen Resolution Testing**|B0007.006|Sandboxes aren't used in the same manner as a typical user environment, so most of the time the screen resolution stays at the minimum 800x600 or lower. No one is actually working on a such small screen. Malware could potentially detect the screen resolution to determine if it's a user machine or a sandbox. This method is related to Unprotect technique U1315.|
|
||||
|**Self Check**|B0007.007|Malware may check its own characteristics to determine whether it's running in a sandbox. For example, a malicious Office document might check its file name or VB project name. This method is related to Unprotect technique U1303.|
|
||||
|**Timing/Date Check**|B0007.008|Calling GetSystemTime or equiv and only executing code if the current date/hour/minute/second passes some check. Often this is for running only after or only until a specific date. This behavior can be mitigated in non-automated analysis environments. This method is related to Unprotect technique U1005.|
|
||||
|**Timing/Uptime Check**|B0007.009|Comparing single GetTickCount with some value to see if system has been started at least *X* amount ago. This behavior can be mitigated in non-automated analysis environments.|
|
||||
|**Test API Routines**|B0007.010|Calls Windows API routines with invalid arguments to identify error supression.|
|
||||
|
||||
@@ -113,18 +113,6 @@ mov bl, 1
|
||||
</pre>
|
||||
</details>
|
||||
|
||||
## Detection
|
||||
|
||||
|Tool: capa|Mapping|APIs|
|
||||
|---|---|---|
|
||||
|[check for microsoft office emulation](https://github.com/mandiant/capa-rules/blob/master/anti-analysis/anti-vm/vm-detection/check-for-microsoft-office-emulation.yml)|[Sandbox Detection::Product Key/ID Testing (B0007.005)|CreateFile|
|
||||
|[check for sandbox and av modules](https://github.com/mandiant/capa-rules/blob/master/anti-analysis/anti-av/check-for-sandbox-and-av-modules.yml)|Sandbox Detection (B0007)|GetModuleHandle|
|
||||
|
||||
|Tool: CAPE|Mapping|APIs|
|
||||
|---|---|---|
|
||||
|[antisandbox_joe_anubis_files.py](https://github.com/kevoreilly/community/blob/master/modules/signatures/antisandbox_joe_anubis_files.py)|Sandbox Detection::Check Files (B0007.002)|--|
|
||||
|[antisandbox_cuckoo_files](https://github.com/kevoreilly/community/blob/master/modules/signatures/antisandbox_cuckoo_files.py)|Sandbox Detection::Check Files (B0007.002)|--|
|
||||
|
||||
## References
|
||||
|
||||
<a name="1">[1]</a> https://www.fireeye.com/blog/threat-research/2011/01/the-dead-giveaways-of-vm-aware-malware.html
|
||||
|
||||
@@ -43,7 +43,7 @@ The related **Virtualization/Sandbox Evasion ([T1497](https://attack.mitre.org/t
|
||||
|**Check File and Directory Artifacts**|B0009.001|Virtual machines create files on the file system (e.g., VMware creates files in the installation directory C:\Program Files\VMware\VMware Tools). Malware can check the different folders to find virtual machine artifacts (e.g., Virtualbox has the artifact VBoxMouse.sys). [[2]](#2)|
|
||||
|**Check Memory Artifacts**|B0009.002|VMware leaves many artifacts in memory. Some are critical processor structures, which, because they are either moved or changed on a virtual machine, leave recognizable footprints. Malware can search through physical memory for the strings VMware, commonly used to detect memory artifacts. [[2]](#2)|
|
||||
|**Check Named System Objects**|B0009.003|Virtual machines often include specific named system objects by default, such as Windows device drivers, which can be detected by testing for specific strings, whether found in the Windows registry or other places.|
|
||||
|**Check Processes**|B0009.004|The VMware Tools use processes like VMwareServices.exe or VMwareTray.exe, to perform actions on the virtual environment. Malware can list the processes and searches for the VMware string. Processes related to Virtualbox can be detected by the malware by querying the process list. [[2]](#2)|
|
||||
|**Check Processes**|B0009.004|The VMware Tools use processes like VMwareServices.exe or VMwareTray.exe, to perform actions on the virtual environment. Malware can list the processes and searches for the VMware string. Processes related to Virtualbox can be detected by the malware by querying the process list. [[2]](#2) This method is related to Unprotect technique U1334.|
|
||||
|**Check Registry Keys**|B0009.005|Virtual machines register artifacts in the registry, which can be detected by malware. For example, a search for "VMware" or "VBOX" in the registry might reveal keys that include information about a virtual hard drive, adapters, running services, or a virtual mouse. [[2]](#2) Example registry key value artifacts include "HARDWARE\Description\System (SystemBiosVersion) (VBOX)" and "SYSTEM\ControlSet001\Control\SystemInformation (SystemManufacturer) (VMWARE)"; example registry key artifacts include "SOFTWARE\VMware, Inc.\VMware Tools (VMWARE)" and "SOFTWARE\Oracle\VirtualBox Guest Additions (VBOX)". [[5]](#5)|
|
||||
|**Check Running Services**|B0009.006|VMwareService.exe runs the VMware Tools Service as a child of services.exe. It can be identified by listing services. [[2]](#2)|
|
||||
|**Check Software**|B0009.007|Malware may check software version; for example, to determine whether the software is relatively current.|
|
||||
@@ -56,28 +56,28 @@ The related **Virtualization/Sandbox Evasion ([T1497](https://attack.mitre.org/t
|
||||
|**HTML5 Performance Object Check**|B0009.011|In three browser families, it is possible to extract the frequency of the Windows performance counter frequency, using standard HTML and Javascript. This value can then be used to detect whether the code is being executed in a virtual machine, by detecting two specific frequencies commonly used in virtual but not physical machines.|
|
||||
|**Human User Check**|B0009.012|Detects whether there is any "user" activity on the machine, such as the movement of the mouse cursor, non-default wallpaper, or recently opened Office files. Directories or file might be counted. If there is no human activity, the machine is suspected to be a virtualized machine and/or sandbox. Other items used to detect a user: mouse clicks (single/double), DialogBox, scrolling, color of background pixel, change in foreground window [[5]](#5). This method is very similar to ATT&CK's [Virtualization/Sandbox Evasion: User Activity Based Checks](https://attack.mitre.org/techniques/T1497/002/) sub-technique.|
|
||||
|**Instruction Testing**|[B0009.029](#b0009029-snippet)|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - CPUID**|B0009.034|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) Checking the CPU ID found within the registry can provide information to system type.|
|
||||
|**Instruction Testing - IN**|B0009.035|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - CPUID**|B0009.034|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) Checking the CPU ID found within the registry can provide information to system type. This method is related to Unprotect technqiue U1324.|
|
||||
|**Instruction Testing - IN**|B0009.035|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) This method is related to Unprotect technique U1323.|
|
||||
|**Instruction Testing - RDTSC**|B0009.036|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - SGDT/SLDT (no pill)**|B0009.031|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) The No Pill technique relies on the fact that the LDT structure is assigned to a processor not an Operating System. The LDT location on a host machine will be zero and on a virtual machine will be non-zero.|
|
||||
|**Instruction Testing - SIDT (red pill)**|B0009.030|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) Red Pill is an anti-VM technique that executes the SIDT instruction to grab the value of the IDTR register. The virtual machine monitor must relocate the guest's IDTR to avoid conflict with the host's IDTR. Since the virtual machine monitor is not notified when the virtual machine runs the SIDT instruction, the IDTR for the virtual machine is returned.|
|
||||
|**Instruction Testing - SMSW**|B0009.032|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - STR**|B0009.033|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - VMCPUID**|B0009.037|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - VPCEXT**|B0009.038|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2)|
|
||||
|**Instruction Testing - SGDT/SLDT (no pill)**|B0009.031|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) The No Pill technique relies on the fact that the LDT structure is assigned to a processor not an Operating System. The LDT location on a host machine will be zero and on a virtual machine will be non-zero. This method is related to Unprotect technique U1327.|
|
||||
|**Instruction Testing - SIDT (red pill)**|B0009.030|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) Red Pill is an anti-VM technique that executes the SIDT instruction to grab the value of the IDTR register. The virtual machine monitor must relocate the guest's IDTR to avoid conflict with the host's IDTR. Since the virtual machine monitor is not notified when the virtual machine runs the SIDT instruction, the IDTR for the virtual machine is returned. This method is related to Unprotect technique U1328.|
|
||||
|**Instruction Testing - SMSW**|B0009.032|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) This method is related to Unprotect technique U1326.|
|
||||
|**Instruction Testing - STR**|B0009.033|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) This method is related to Unprotect technique U1325.|
|
||||
|**Instruction Testing - VMCPUID**|B0009.037|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) This method is related to Unprotect technique U1322.|
|
||||
|**Instruction Testing - VPCEXT**|B0009.038|The execution of certain x86 instructions will result in different values when executed inside of a VM instead of on bare metal. Accordingly, these can be used to detect the execution of the malware in a VM. [[2]](#2) This method is related to Unprotect technique U1321.|
|
||||
|**Modern Specs Check**|B0009.013|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment.|
|
||||
|**Modern Specs Check - Drive size**|B0009.015|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Most modern machines have at least 80 GB disks. May use DeviceloControl (IOCTL_DISK_GET_LENGTH_INFO) or GetDiskFreeSpaceEx (TotalNumberOfBytes) [[5]](#5).|
|
||||
|**Modern Specs Check - Drive size**|B0009.015|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Most modern machines have at least 80 GB disks. May use DeviceloControl (IOCTL_DISK_GET_LENGTH_INFO) or GetDiskFreeSpaceEx (TotalNumberOfBytes) [[5]](#5). This method is related to Unprotect technique U1312.|
|
||||
|**Modern Specs Check - Keyboard layout**|B0009.019|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Check keyboard layout.|
|
||||
|**Modern Specs Check - Printer**|B0009.017|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks whether there is a potential connected printer or default Windows printers; if not a virtual environment is suspected.|
|
||||
|**Modern Specs Check - Processor count**|B0009.018|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks number of processors; single CPU machines are suspect.|
|
||||
|**Modern Specs Check - Total physical memory**|B0009.014|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Most modern machines have at leave 4 GB of memory. (GlobalMemoryStatusEx) [[5]](#5).|
|
||||
|**Modern Specs Check - USB drive**|B0009.016|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks whether there is a potential USB drive; if not a virtual environment is suspected.|
|
||||
|**Modern Specs Check - Printer**|B0009.017|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks whether there is a potential connected printer or default Windows printers; if not a virtual environment is suspected. This method is related to Unprotect technique U1309.|
|
||||
|**Modern Specs Check - Processor count**|B0009.018|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks number of processors; single CPU machines are suspect. This method is related to Unprotect technique U1340.|
|
||||
|**Modern Specs Check - Total physical memory**|B0009.014|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Most modern machines have at leave 4 GB of memory. (GlobalMemoryStatusEx) [[5]](#5). This method is related to Unprotect technique U1313.|
|
||||
|**Modern Specs Check - USB drive**|B0009.016|Different aspects of the hardware are inspected to determine whether the machine has modern characteristics. A machine with substandard specifications indicates a virtual environment. Checks whether there is a potential USB drive; if not a virtual environment is suspected. This method is related to Unprotect technique U1310.|
|
||||
|**Unique Hardware/Firmware Check**|B0009.023|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment.|
|
||||
|**Unique Hardware/Firmware Check - BIOS**|B0009.024|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. Characteristics of the BIOS, such as version, can indicate virtualization.|
|
||||
|**Unique Hardware/Firmware Check - CPU Location**|B0009.027|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. When an Operating System is virtualized, the CPU is relocated. [[2]](#2)|
|
||||
|**Unique Hardware/Firmware Check - CPU Name**|B0009.026|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. Checks the CPU name to determine virtualization.|
|
||||
|**Unique Hardware/Firmware Check - I/O Communication Port**|B0009.025|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. VMware uses virtual I/O ports for communication between the virtual machine and the host operating system to support functionality like copy and paste between the two systems. The port can be queried and compared with a magic number VMXh to identify the use of VMware.|
|
||||
|**Unique Hardware/Firmware Check - MAC Address**|B0009.028|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. VMware uses specific virtual MAC address that can be detected. The usual MAC address used started with the following numbers: "00:0C:29", "00:1C:14", "00:50:56", "00:05:69". Virtualbox uses specific virtual MAC address that can be detected by Malware. The usual MAC address used started with the following numbers: 08:00:27. [[2]](#2)|
|
||||
|**Unique Hardware/Firmware Check - I/O Communication Port**|B0009.025|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. VMware uses virtual I/O ports for communication between the virtual machine and the host operating system to support functionality like copy and paste between the two systems. The port can be queried and compared with a magic number VMXh to identify the use of VMware. This method is related to Unprotect technique U1336.|
|
||||
|**Unique Hardware/Firmware Check - MAC Address**|B0009.028|Malware may check for hardware characteristics unique to being virtualized, allowing the malware to detect the virtual environment. VMware uses specific virtual MAC address that can be detected. The usual MAC address used started with the following numbers: "00:0C:29", "00:1C:14", "00:50:56", "00:05:69". Virtualbox uses specific virtual MAC address that can be detected by Malware. The usual MAC address used started with the following numbers: 08:00:27. [[2]](#2) This method is related to Unprotect technique U1335.|
|
||||
|
||||
|
||||
## Use in Malware
|
||||
|
||||
@@ -40,7 +40,7 @@ Some methods apply to both types of disassemblers; others apply to one type and
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Conditional Misdirection**|B0012.002|Conditional jumps are sometimes used to confuse disassembly engines, resulting in the wrong instruction boundaries and thus wrong mnemonic and operands; may be identified by instructions *jmp/jcc to a label+#* (e.g., JNE loc_401345fe+2).|
|
||||
|**Desynchronizing Opaque Predicates**|B0012.006|Opaque predicates inject superfluous branches into the disassembly, resulting in disassembly desynchronization, as well as code bloat. The junk bytes introduced damage the disassembly process when the bytes are treated as code. [[5]](#5)|
|
||||
|**Desynchronizing Opaque Predicates**|B0012.006|Opaque predicates inject superfluous branches into the disassembly, resulting in disassembly desynchronization, as well as code bloat. The junk bytes introduced damage the disassembly process when the bytes are treated as code. [[5]](#5) This method is related to Unprotect technique U0201.|
|
||||
|**VBA Stomping**|B0012.005|Typically, VBA source code is compiled into p-code, which is stored with compressed sourced code in the OLE file with VBA macros. VBA Stomping - when the VBA source code is removed and only the p-code remains - makes analysis much harder. See [[3]](#3) for an analysis of a VBA-Stomped malicious VBA Office document. See [[4]](#4) for information on Evil Clippy, a tool that creates malicious MS Office documents.|
|
||||
|**Value Dependent Jumps**|B0012.003|Explicit use of computed values for control flow, often in the same basic block or function.|
|
||||
|
||||
|
||||
@@ -40,23 +40,23 @@ For encryption and encoding characteristics of malware samples, as well as malwa
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Argument Obfuscation**|B0032.020|Simple number or string arguments to API calls are calculated at runtime, making analysis more difficult.|
|
||||
|**API Hashing**|B0032.001|Instead of storing function names in the Import Address Table (IAT) and calling GetProcAddress, a DLL is loaded and the name of each of its exports is hashed until it matches a specific hash. Manual symbol resolution is then used to access and execute the exported function. This method is often used by shellcode because it reduces the size of each import from a human-readable string to a sequence of four bytes. The Method is also known as "Imports by Hash" and "GET_APIS_WITH_CRC." [[1]](#1)|
|
||||
|**API Hashing**|B0032.001|Instead of storing function names in the Import Address Table (IAT) and calling GetProcAddress, a DLL is loaded and the name of each of its exports is hashed until it matches a specific hash. Manual symbol resolution is then used to access and execute the exported function. This method is often used by shellcode because it reduces the size of each import from a human-readable string to a sequence of four bytes. The Method is also known as "Imports by Hash" and "GET_APIS_WITH_CRC." [[1]](#1) This method is related to Unprotect technique U0217.|
|
||||
|**Code Insertion**|B0032.002|Insert code to impede disassembly and make analysis more difficult.|
|
||||
|**Data Value Obfuscation**|B0032.008|Obfuscate data values through indirection of local or global variables. For example, the instruction *if (a == 0) do x* can be obfuscated by setting a global variable, *Z*, to zero and using it in the instruction: *if (a==Z) do x*. [NEEDS REVIEW]|
|
||||
|**Dead Code Insertion**|B0032.003|Include "dead" code with no real functionality. When executing, malware may skip over such code via an opaque predicate.|
|
||||
|**Entry Point Obfuscation**|B0032.009|Obfuscate the entry point of the malware executable.|
|
||||
|**Fake Code Insertion**|B0032.004|Add fake code similar to known packers or known goods to fool identification. Can confuse some automated unpackers.|
|
||||
|**Guard Pages**|B0032.010|Encrypt blocks of code individually and decrypt temporarily only upon execution.|
|
||||
|**Guard Pages**|B0032.010|Encrypt blocks of code individually and decrypt temporarily only upon execution. This method is related to Unprotect technique U0102.|
|
||||
|**Import Address Table Obfuscation**|B0032.011|Obfuscate the import address table.|
|
||||
|**Import Compression**|B0032.012|Store and load imports with a compact import table format. Each DLL needed by the executable is mentioned in the IAT, but only one function from each/most is imported; the rest are imported via GetProcAddress calls.|
|
||||
|**Instruction Overlap**|B0032.013|Jump after the first byte of an instruction to confuse disassembler.|
|
||||
|**Interleaving Code**|B0032.014|Split code into sections that may be rearranged and may be connected by unconditional jumps. When instructions are out of order, writing a function signature is more difficult.|
|
||||
|**Jump Insertion**|B0032.005|Insert jumps to make analysis visually harder.|
|
||||
|**Junk Code Insertion**|B0032.007|Insert dummy code between relevant opcodes. Can make signature writing more complex.|
|
||||
|**Merged Code Sections**|B0032.015|Merge all sections resulting in just one entry in the sections table to make readability more difficult. May affect some detection signatures if written to be section dependent.|
|
||||
|**Opaque Predicate**|B0032.019|An opaque predicate either always jumps (jumping over dead or junk code) or never jumps (executing essential code), but determining the execution path can be difficult.|
|
||||
|**Junk Code Insertion**|B0032.007|Insert dummy code between relevant opcodes. Can make signature writing more complex. This method is related to Unprotect technique U0204.|
|
||||
|**Merged Code Sections**|B0032.015|Merge all sections resulting in just one entry in the sections table to make readability more difficult. May affect some detection signatures if written to be section depe
|
||||
|**Opaque Predicate**|B0032.019|An opaque predicate either always jumps (jumping over dead or junk code) or never jumps (executing essential code), but determining the execution path can be difficult. This method is related to Unprotect technique U0201.|
|
||||
|**Stack Strings**|[B0032.017](#b0032017-snippet)|Build and decrypt strings on the stack at each use, then discard to avoid obvious references.|
|
||||
|**Structured Exception Handling (SEH)**|B0032.016|A portion of the code always generates an exception so that malicious code is executed with the exception handling. See [[3]](#3).|
|
||||
|**Structured Exception Handling (SEH)**|B0032.016|A portion of the code always generates an exception so that malicious code is executed with the exception handling. See [[3]](#3). This method is related to Unprotect technique U0218.|
|
||||
|**Symbol Obfuscation**|B0032.018|Remove or rename symbolic information commonly inserted by compilers for debugging purposes.|
|
||||
|**Thunk Code Insertion**|B0032.006|Variation on Jump Insertion. Used by some compilers for user-generated functions.|
|
||||
|**Variable Recomposition**|B0032.021|Variables, often strings, are broken into multiple parts and stored out of order, in different memory ranges, or both. They must then be recomposed before use, making analysis difficult.|
|
||||
@@ -78,7 +78,7 @@ For encryption and encoding characteristics of malware samples, as well as malwa
|
||||
|
||||
## Code Snippets
|
||||
|
||||
### B0032.017 SNippet
|
||||
### B0032.017 Snippet
|
||||
<details>
|
||||
<summary> Executable Code Obfuscation::Stack Strings </summary>
|
||||
SHA256: 304f533ce9ea4a9ee5c19bc81c49838857c63469e26023f330823c3240ee4e03
|
||||
|
||||
@@ -40,7 +40,7 @@ This description refines the ATT&CK **Obfuscated Files or Information: Software
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Armadillo**|F0001.012|Uses Armadillo.|
|
||||
|**ASPack**|F0001.013|Uses ASPack.|
|
||||
|**ASPack**|F0001.013|Uses ASPack. This method is related to Unprotect technique U1411.|
|
||||
|**Confuser**|F0001.009|Uses Confuser packer.|
|
||||
|**Custom Compression**|F0001.005|Uses a custom algorithm to compress an executable file.|
|
||||
|**Custom Compression of Code**|F0001.006|Uses a custom algorithm to compress opcode mnemonics.|
|
||||
@@ -49,9 +49,9 @@ This description refines the ATT&CK **Obfuscated Files or Information: Software
|
||||
|**Standard Compression**|F0001.002|Uses a standard algorithm, such as UPX or LZMA, to compress an executable file.|
|
||||
|**Standard Compression of Code**|F0001.003|Uses a standard algorithm to compress the opcode mnemonics.|
|
||||
|**Standard Compression of Data**|F0001.004|Uses a standard algorithm to compress strings and variables (executable file data).|
|
||||
|**Themida**|F0001.011|Uses Themida.|
|
||||
|**UPX**|F0001.008|Uses UPX packer.|
|
||||
|**VMProtect**|F0001.010|Uses VMProtect.|
|
||||
|**Themida**|F0001.011|Uses Themida.This method is related to Unprotect technique U1406.|
|
||||
|**UPX**|F0001.008|Uses UPX packer. This method is related to Unprotect technique U1402.|
|
||||
|**VMProtect**|F0001.010|Uses VMProtect. This method is related to Unprotect technique U1410.|
|
||||
|
||||
## Use in Malware
|
||||
|
||||
|
||||
@@ -32,6 +32,8 @@ Malware generates the domain name of the controller to which it connects. Access
|
||||
|
||||
The related **Dynamic Resolution: Domain Generation Algorithms ([T1568.002](https://attack.mitre.org/techniques/T1568/002/))** ATT&CK sub-technique (oriented toward an adversary perspective with examples that include malware) was defined subsequent to this MBC behavior.
|
||||
|
||||
This behavior is related to Unprotect technique U0906.
|
||||
|
||||
## Use in Malware
|
||||
|
||||
|Name|Date|Method|Description|
|
||||
|
||||
@@ -34,7 +34,7 @@ Malware may install itself in areas other than the hard drive. [[1]](#1)
|
||||
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Fileless Malware**|B0027.001|Stores itself in memory.|
|
||||
|**Fileless Malware**|B0027.001|Stores itself in memory. This method is related to Unprotect technique U1205.|
|
||||
|**Registry Install**|B0027.002|Stores itself in the Windows registry.|
|
||||
|
||||
## Use in Malware
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
# Disable or Evade Security Tools
|
||||
|
||||
Malware may disable or evade security tools to avoid detection. Security tools include OS security features and updating tools, anti-virus (AV) tools, firewalls, tool components providing security related logging and/or reporting, and Antimalware Scan Interface (AMSI) related capabilities.
|
||||
Malware may disable or evade security tools to avoid detection. Security tools include OS security features and updating tools, anti-virus (AV) tools, firewalls, tool components providing security related logging and/or reporting, and Antimalware Scan Interface (AMSI) related capabilities. This behavior is related to Unprotect technique U0508.
|
||||
|
||||
Malware-related methods extending ATT&CK's definition are below.
|
||||
|
||||
|
||||
@@ -30,6 +30,8 @@
|
||||
|
||||
Malware may hide files and folders to avoid detection and/or to persist on the system. See potential methods below.
|
||||
|
||||
This behavior is related to Unprotect technique U1230.
|
||||
|
||||
See ATT&CK: **Hide Artifacts: Hidden Files and Directories ([T1564.001](https://attack.mitre.org/techniques/T1564/001/))**.
|
||||
|
||||
## Methods
|
||||
|
||||
@@ -48,8 +48,8 @@ See ATT&CK: **Hijack Execution Flow ([T1574](https://attack.mitre.org/techniques
|
||||
|---|---|---|
|
||||
|**Abuse Windows Function Calls**|F0015.006|Malware abuses native Windows function calls to transfer execution to shellcode that it loads into memory. A pointer to the callback function is used to supply the memory address of the shellcode. Functions that can be abused include EnumResourceTypesA and EnumUILanguagesW. [[4]](#4)|
|
||||
|**Export Address Table Hooking**|F0015.001|Malware (e.g. rootkit) hooks the export address table (EAT).|
|
||||
|**Import Address Table Hooking**|F0015.003|Malware (e.g. rootkit) modifies a process's import address table (IAT), which stores pointers to imported API functions.[[1]](#1)|
|
||||
|**Inline Patching**|F0015.002|Inline patching (inline hooking) is done by modifying the beginning of a function (e.g., first bytes) in order to redirect the execution flow to custom code (i.e. redirecting code flow) before jumping back to the original function.[[2]](#2)|
|
||||
|**Import Address Table Hooking**|F0015.003|Malware (e.g. rootkit) modifies a process's import address table (IAT), which stores pointers to imported API functions.[[1]](#1) This method is related to Unprotect technique U1217.|
|
||||
|**Inline Patching**|F0015.002|Inline patching (inline hooking) is done by modifying the beginning of a function (e.g., first bytes) in order to redirect the execution flow to custom code (i.e. redirecting code flow) before jumping back to the original function.[[2]](#2) This method is related to Unprotect technique U1205.|
|
||||
|**Procedure Hooking**|F0015.007|Intercepts and executes designated code in response to events such as messages, keystrokes, and mouse inputs. [[5]](#5)|
|
||||
|**Shadow System Service Dispatch Table Hooking**|F0015.004|The Shadow System Service Dispatch Table (SSDT) can be hooked similarly to how the SSDT and IAT are hooked. The target of the hooking with the Shadow SSDT is the Windows subsystem (win32k.sys).[[3]](#3)|
|
||||
|**System Service Dispatch Table Hooking**|F0015.005|Malware (e.g. rootkit, malicious drivers) may hook the system service dispatch table (SSDT), also called the system service descriptor table. The SSDT contains information about the service tables used by the operating system for dispatching system calls. Hooking the SSDT enables malware to hide files, registry keys, and network connections.[[3]](#3)|
|
||||
|
||||
@@ -47,11 +47,11 @@ Instead of being listed alphabetically, methods have been grouped to better faci
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Encoding**|E1027.m01|A malware sample, file, or other information is encoded.|
|
||||
|**Encoding-Custom Algorithm**|E1027.m03|A custom algorithm is used to encode a malware sample, file or other information.|
|
||||
|**Encoding-Standard Algorithm**|[E1027.m02](#e1027m02-snippet)|A standard algorithm (e.g., base64) is used to encode a malware sample, file, or other information.|
|
||||
|**Encryption**|E1027.m04|A malware sample, file, or other information is encrypted.|
|
||||
|**Encoding-Custom Algorithm**|E1027.m03|A custom algorithm is used to encode a malware sample, file or other information. This method is related to Unprotect technique U0702.|
|
||||
|**Encoding-Standard Algorithm**|[E1027.m02](#e1027m02-snippet)|A standard algorithm (e.g., base64) is used to encode a malware sample, file, or other information. This method is related to Unprotect technique U0701 and U0706.|
|
||||
|**Encryption**|E1027.m04|A malware sample, file, or other information is encrypted. This method is related to Unprotect technique U0703.|
|
||||
|**Encryption-Custom Algorithm**|E1027.m08|A custom algorithm is used to encrypt a malware sample, file, or other information.|
|
||||
|**Encryption-Standard Algorithm**|E1027.m05|A standard algorithm (e.g., Rijndael/AES, DES, RC4) is used to encrypt a malware sample, file, or other information.|
|
||||
|**Encryption-Standard Algorithm**|E1027.m05|A standard algorithm (e.g., Rijndael/AES, DES, RC4) is used to encrypt a malware sample, file, or other information. This method is related to Unprotect technique U0701.|
|
||||
|**Encryption of Code**|E1027.m06|A file's executable code is encrypted, but not necessarily the file's data.|
|
||||
|**Encryption of Data**|E1027.m07|A file's data is encrypted, but not necessarily the file's code.|
|
||||
|
||||
|
||||
@@ -34,23 +34,23 @@ See ATT&CK: **Process Injection ([T1055](https://attack.mitre.org/techniques/T10
|
||||
|
||||
|ID|ATT&CK Sub-Technique|Notes|
|
||||
|---|---|---|
|
||||
|E1055.001|Dynamic-link Library Injection|Malware creates a thread using CreateRemoteThread (or NtCreateThreadEx, RtlCreateUserThread) and LoadLibrary. The path to the malware's malicious dynamic-link library (DLL) is written in the virtual address space of another process; the malware ensures the remote process loads it by creating a remote thread in the target process. This is one of the most common process injection methods, called *Classic DLL Injection via CreateRemoteThread and LoadLibrary* in [[1]](#1).|
|
||||
|E1055.002|Portable Executable Injection|Malware copies its malicious code into an existing open process and causes it to execute via shellcode or by calling CreateRemoteThread (instead of passing the address of the LoadLibrary), called *Portable Executable Injection* in [[1]](#1).|
|
||||
|E1055.003|Thread Execution Hijacking|Malware targets an existing thread of a process, avoiding noisy process or thread creations operations, called *Thread Execution Hijacking* in [[1]](#1).|
|
||||
|E1055.004|Asynchronous Procedure Call|Malware may leverage Asynchronous Procedure Calls (APC) to force another thread to execute its code by attaching it to the APC Queue of the target thread (using QueueUserAPC / NtQueueApcThread), called AtomBombing [[3]](#3), also called *APC Injection and AtomBombing* in [[1]](#1).|
|
||||
|E1055.011|Extra Window Memory Injection|Malware may inject into Explorer tray window’s extra window memory, called *Extra Window Memory Injection* in [[1]](#1).|
|
||||
|E1055.012|Process Hollowing|Instead of injecting code into a program, malware can upmap (hollow out) legitimate code from memory of a target process, overwriting it with a malicious executable, called *Process Hollowing* in [[1]](#1).|
|
||||
|E1055.001|Dynamic-link Library Injection|Malware creates a thread using CreateRemoteThread (or NtCreateThreadEx, RtlCreateUserThread) and LoadLibrary. The path to the malware's malicious dynamic-link library (DLL) is written in the virtual address space of another process; the malware ensures the remote process loads it by creating a remote thread in the target process. This is one of the most common process injection methods, called *Classic DLL Injection via CreateRemoteThread and LoadLibrary* in [[1]](#1). This method is related to Unprotect technique U1226.|
|
||||
|E1055.002|Portable Executable Injection|Malware copies its malicious code into an existing open process and causes it to execute via shellcode or by calling CreateRemoteThread (instead of passing the address of the LoadLibrary), called *Portable Executable Injection* in [[1]](#1). This method is related to Unprotect technique U1216.|
|
||||
|E1055.003|Thread Execution Hijacking|Malware targets an existing thread of a process, avoiding noisy process or thread creations operations, called *Thread Execution Hijacking* in [[1]](#1). This method is related to Unprotect technique U1223.|
|
||||
|E1055.004|Asynchronous Procedure Call|Malware may leverage Asynchronous Procedure Calls (APC) to force another thread to execute its code by attaching it to the APC Queue of the target thread (using QueueUserAPC / NtQueueApcThread). AtomBombing [[1]](#1)[[3]](#3), a variant of APC injection, occurs when the attacker stores malicious code in the global atom table. The APC gets the targeted process to retrieve the code that will be injected to the memory of the targeted process. This method is related to Unprotect technique U1221 and U1220.|
|
||||
|E1055.011|Extra Window Memory Injection|Malware may inject into Explorer tray window’s extra window memory, called *Extra Window Memory Injection* in [[1]](#1). This method is related to Unprotect technique U1219.|
|
||||
|E1055.012|Process Hollowing|Instead of injecting code into a program, malware can upmap (hollow out) legitimate code from memory of a target process, overwriting it with a malicious executable, called *Process Hollowing* in [[1]](#1). This method is related to Unprotect technique U1225.|
|
||||
|
||||
Methods not captured by ATT&CK Process Injection sub-techniques are listed below. Note that IAT hooking and inline hooking (aka userland rootkits) are defined as methods under the [Hijack Execution Flow](../defense-evasion/hijack-execution-flow.md) behavior.
|
||||
Methods not captured by ATT&CK Process Injection sub-techniques are listed below. Note that IAT hooking and inline hooking (aka userland rootkits) are defined as methods under the [Hijack Execution Flow](../defense-evasion/hijack-execution-flow.md) behavior.
|
||||
|
||||
## Methods
|
||||
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Hook Injection via SetWindowsHooksEx**|E1055.m01|Malware can leverage hooking functionality to have its malicious DLL loaded upon an event getting triggered in a specific thread, which is usually done by calling SetWindowsHookEx to install a hook routine into the hook chain. [[1]](#1)|
|
||||
|**Hook Injection via SetWindowsHooksEx**|E1055.m01|Malware can leverage hooking functionality to have its malicious DLL loaded upon an event getting triggered in a specific thread, which is usually done by calling SetWindowsHookEx to install a hook routine into the hook chain. [[1]](#1) This method is related to Unprotect technique 1227.|
|
||||
|**Injection and Persistence via Registry Modification**|E1055.m02|Malware may insert the location of its malicious library under a registry key (e.g., Appinit_DLL, AppCertDlls, IFEO) to have another process load its library. [[1]](#1)|
|
||||
|**Injection via Windows Fibers**|E1055.m05|Malware executes shellcode via Windows fibers by converting a thread to a fiber. [[5]](#5)|
|
||||
|**Injection using Shims**|E1055.m03|Malware may use shims to target an executable (shims are a way of hooking into APIs and targeting specific executables and are provided by Microsoft for backward compatibility, allowing developers to apply program fixes without rewriting code). [[1]](#1)|
|
||||
|**Injection using Shims**|E1055.m03|Malware may use shims to target an executable (shims are a way of hooking into APIs and targeting specific executables and are provided by Microsoft for backward compatibility, allowing developers to apply program fixes without rewriting code). [[1]](#1) This method is related to Unprotect technique U1218.|
|
||||
|**Patch Process Command Line**|E1055.m04|Malware patches the PEB of a process to spoof the arguments.|
|
||||
|
||||
## Use in Malware
|
||||
|
||||
@@ -30,6 +30,8 @@
|
||||
|
||||
Malware may include code that relies on specific actions by a user to execute. Note that this MBC behavior differs from [User Execution](https://attack.mitre.org/techniques/T1204) in that it does do not include direct code execution (user action for *initial* execution) - MBC does not encompass ATT&CK's Initial Access Tactic.
|
||||
|
||||
This behavior is related to Unprotect technique U1339.
|
||||
|
||||
See ATT&CK Technique: **User Execution ([T1204](https://attack.mitre.org/techniques/T1204/))**.
|
||||
|
||||
## Use in Malware
|
||||
|
||||
@@ -39,7 +39,7 @@ Malware may generate traffic from the victim system such as clicks of advertisin
|
||||
|Name|ID|Description|
|
||||
|---|---|---|
|
||||
|**Advertisement Replacement Fraud**|E1643.m02|Malware injects ad windows onto websites the user views. [[2]](#2)|
|
||||
|**Click Hijacking**|E1643.m01|Malware alters DNS server settings to route to a rogue DNS server: when the user clicks on a search result link displayed through a search engine query, malware re-routes the user to different website. Instead of going to the requested site, the user is taken to an alternate website such that the click triggers payment to the threat actor. [[1]](#1)|
|
||||
|**Click Hijacking**|E1643.m01|Malware alters DNS server settings to route to a rogue DNS server: when the user clicks on a search result link displayed through a search engine query, malware re-routes the user to different website. Instead of going to the requested site, the user is taken to an alternate website such that the click triggers payment to the threat actor. [[1]](#1) This method is related to Unprotect technique U0904.|
|
||||
|
||||
## Use in Malware
|
||||
|
||||
|
||||
@@ -28,6 +28,7 @@
|
||||
|
||||
# Suspend Thread
|
||||
|
||||
This behavior is related to Unprotect technique U0101.
|
||||
|
||||
## Use in Malware
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Behaviors that enable malware to remain on a system regardless of system events,
|
||||
* **Bootkit** [F0013](../defense-evasion/bootkit.md)
|
||||
* **Component Firmware** [F0009](../persistence/component-firmware.md)
|
||||
* **Hide Artifacts** [E1564](../defense-evasion/hide-artifacts.md)
|
||||
* **Hidden Files and Directories** [F0005](../defense-evasion/hidden-files-and-directories.md)
|
||||
* **Hidden Files and Directories** [F0005](../defense-evasion/hidden-files-and-directories.md) This method is related to Unprotect technique U1230.
|
||||
* **Hijack Execution Flow** [E1574](../defense-evasion/hijack-execution-flow.md)
|
||||
* **Install Insecure or Malicious Configuration** [B0047](../defense-evasion/install-insecure-or-malicious-configuration.md)
|
||||
* **Kernel Modules and Extensions** [F0010](../persistence/kernel-modules-and-extensions.md)
|
||||
|
||||
Reference in New Issue
Block a user