=============== Alerts & Events =============== Violations ========== Violations are sent when HVI detects a potential attack. Each violation type is suited to various kinds of attacks, but they don't necessarily indicate exactly what type of attack was triggered: for example, and EPT violation can be generated for a user-mode exploit (execution), for a kernel rootkit (write inside a protected area) or for a kernel exploit (read from the NT EAT). Each violation contains the **MITRE ID** of the identified attack as disclosed on the official `MITRE website `__. The same type of violation may contain different MITRE IDs, depending on the circumstances of its generation. .. note:: Originator and Victim are keywords used to easily identify who generated the attack (originator) and which resources were attacked (victim). .. note:: This is high level description of the events generated by Introcore. A full technical descriptions of these structures can be found in the `Doxygen code documentation <../_static/doxygen/html/index.html>`_. Extended Page Table Violation (EVENT_EPT_VIOLATION) --------------------------------------------------- This event is generated for a range of memory access violations. Events that will lead to an EPT violation being generated include: - Writing to a read-only section inside a protected kernel or user module on both Windows and Linux - Writing the vDSO page on Linux - Writing the SSDT on 32 bit Windows - Writing the IDT on Windows or Linux - Writing the Hal Dispatch Table (if SPP is present) on Windows - Writing to a driver-object or the fast I/O dispatch on Windows - Writing the HAL interrupt controller on Windows - Reading the Exports section of the Windows kernel image - Reading the code section of the Linux kernel image - Executing code from the HAL heap region of the Windows kernel - Executing code from the SharedUserData page on Windows - Executing code from a memory region that does not belong to a legitimately loaded module, on both Windows and Linux - Accessing the #VE agent memory area (for read, write or execute) from the untrusted EPT view - Accessing the guest memory not belonging to the #VE agent (execute) from the protected EPT view Identifying the EPT violation attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - If the :code:`Originator.Module` is invalid but the :code:`Originator.ReturnModule` is valid, the source of the attack is the :code:`ReturnModule` - If the :code:`Originator.Module` is invalid and the :code:`Originator.ReturnModule` is invalid, the source of the attack **cannot be identified** - If the :code:`Header.CurrentProcess` is invalid, the attack took place at boot time when no processes were created (:code:`Header.CurrentProcess` will always be valid for user-mode events) - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process: - If the attack took place in **user-mode**, this is the source & destination process.  - If the attack took place in **kernel-mode**, this was the currently active process, and it does not necessary mean that it has anything to do with the attack (kernel events can take place in any random process) .. note:: - For kernel BOOT events, before any processes are created, it is possible to have events with :code:`CurrentProcess`, :code:`Module` and :code:`ReturnModule` all invalid - After the first process is created, :code:`CurrentProcess` will **always** be valid Control Register Violation (EVENT_CR_VIOLATION) ----------------------------------------------- This event is generated when HVI detects that a control register is being modified with malicious intent. Currently, the bits controlling **SMEP** & **SMAP** inside **CR4** are protected - each attempt to clear any of these bits will generate an event of this type, on both Windows and Linux. Identifying the CR violation attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - If the :code:`Originator.Module` is invalid but the :code:`Originator.ReturnModule` is valid, the source of the attack is the :code:`ReturnModule` - If the :code:`Originator.Module` is invalid and the :code:`Originator.ReturnModule` is invalid, the source of the attack **cannot be identified** - If the :code:`Header.CurrentProcess` is invalid, the attack took place at boot time when no processes were created (:code:`Header.CurrentProcess` will always be valid for user-mode events) - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process: - If the attack took place in **user-mode**, this is the source and destination process.  - If the attack took place in **kernel-mode**, this was the currently active process, and it does not necessary mean that it has anything to do with the attack (kernel events can take place in any random process) .. note:: - For kernel boot events, before any processes are created, it is possible to have events with :code:`CurrentProcess`, :code:`Module`, and :code:`ReturnModule` invalid - After the first process is created, :code:`CurrentProcess` will **always** be valid Model Specific Register Violation (EVENT_MSR_VIOLATION) ------------------------------------------------------- An event of this type is generated when at attempt to modify a Model Specific Register is detected. Currently, the following registers are protected on both Windows and Linux: - IA32_SYSENTER_EIP (x86) - IA32_SYSENTER_ESP (x86) - IA32_SYSENTER_CS (x86) - IA32_STAR (x64) - IA32_LSTAR (x64) Identifying the MSR violation attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - If the :code:`Originator.Module` is invalid but the :code:`Originator.ReturnModule` is valid, the source of the attack is the :code:`ReturnModule` - If the :code:`Originator.Module` is invalid and the :code:`Originator.ReturnModule` is invalid, the source of the attack **cannot be identified** - If the :code:`Header.CurrentProcess` is invalid, the attack took place at boot time when no processes were created (:code:`Header.CurrentProcess` will always be valid for user-mode events) - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process:  - If the attack took place in **user-mode**, this is the source and destination process.  - If the attack took place in **kernel-mode**, this was the currently active process, and it does not necessary mean that it has anything to do with the attack (kernel events can take place in any random process) .. note:: - For kernel BOOT events, before any processes are created, it is possible to have events with :code:`CurrentProcess`, :code:`Module` and :code:`ReturnModule` invalid - After the first process is created, :code:`CurrentProcess` will **always** be valid Extended Control Register Violation (EVENT_XCR_VIOLATION) --------------------------------------------------------- These events are reserved for Extended Control Registers violations. Currently, no such events are generated on Windows or Linux. Descriptor Table Register Violation (EVENT_DTR_VIOLATION) ----------------------------------------------------------- This event is generated if a malicious **LIDT** or a **LGDT** was issued by the guest. This structure can be sent on both Windows and Linux. Note that DTR violations are sent only for **IDTR**/**GDTR modifications**, and not for **LDTR**/**TR** modifications. Identifying the DTR violation attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - If the :code:`Originator.Module` is invalid but the :code:`Originator.ReturnModule` is valid, the source of the attack is the :code:`ReturnModule` - If the :code:`Originator.Module` is invalid and the :code:`Originator.ReturnModule` is invalid, the source of the attack **cannot be identified** - If the :code:`Header.CurrentProcess` is invalid, the attack took place at BOOT time when no processes were created. - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process: - If the attack took place in **kernel-mode**, this was the currently active process, and it does not necessary mean that it has anything to do with the attack (kernel events can take place in any random process) Memory Copy Violation (MEMCOPY_VIOLATION_TYPE) ---------------------------------------------- This alert is generated when a memory copy violations takes place - for example, when a process tries to inject code or data inside another, protected process. It can be generated in the following cases: - Windows - :code:`WriteProcessMemory` - :code:`ReadProcessMemory` (only when a process tries to read the **lsass.exe** memory) - :code:`SetContextThread` - :code:`QueueApcThread` - :code:`NtSetInformationProcess` (only when a process tries to set an instrumentation callback) - Linux - :code:`ptrace` - :code:`process_vm_rw` - :code:`access_remote_vm` Integrity Violation (EVENT_INTEGRITY_VIOLATION) ----------------------------------------------- An alert of this type is generated when a memory zone protected by the integrity mechanism has been modified. Situations which will lead to such an alert being generated are: - Modifications to a Driver Object or a Fast I/O dispatch routine in Windows - A token has been stolen from a more privileges process on Windows - The privileges of a process token have been maliciously altered on Windows - The creds field has been altered for a process on Linux - An infinity-hook has been detected inside the kernel on Windows - An IDT modification has been detected - A Hal Dispatch Table modification has been detected on Windows - The HalPerformanceCounter function pointer, which gets called on KeQueryPerformanceCounter, was modified and the modification has been detected on Windows - The security descriptor pointer or the Access Control Lists (SACL/DACL) have been modified on Windows - A modification on certain SharedUserData fields, as well as any modification after the SharedUserData structure. - A modification of an interrupt object from KPRCB's InterruptObject array. Integrity violations will be sent for structures which cannot be protected using regular EPT, because too many writes are being generated. Any structure could be protected using this mechanism. For some of these structures, Sub-Page Permissions can be used to reduce the granularity of the hook from 4K to 128B. Translation Violation (EVENT_TRANSLATION_VIOLATION) --------------------------------------------------- Alert generated when a virtual memory translation is maliciously modified. This can happen in the following situations: - A swapped-in page has been modified since it was swapped out (example: the page was modified inside the paging file) - The Cr3 of the System process has been modified (example: a rootkit tries to remap the kernel paging tables) - The self-map entry of a process has been modified - A translation has been modified without being intercepted by the PT filter, if it is enabled Process Creation Violation (EVENT_PROCESS_CREATION_VIOLATION) ------------------------------------------------------------- This event is generated when HVI detects that a process has been created in suspicious conditions. Such conditions are: - The parent process has the **PROC_OPT_PROT_PREVENT_CHILD_CREATION** flag enabled - The parent process starts the child process with the debug-flag set - The parent process has a pivoted stack - The parent process has a stolen token, from a more privileged process - The parent process contains heap-spray patterns - The parent process has altered privileges - The thread that created the process points to a shellcode These process creation events represent the DPI - Deep Process Inspection protection technique, and except for the processes with the **PROC_OPT_PROT_PREVENT_CHILD_CREATION** flag set, such alerts can be generated for any process, even for those which are not protected. .. note:: There is a clear hierarchy of events in this case, and if a process creation violates multiple rules, only one event is generated with that specific rule. The order is as follows: #. Checks done for the **PROC_OPT_PROT_PREVENT_CHILD_CREATION** protection flag #. Stolen token checks #. Token privileges checks #. Pivoted stack checks #. Debug flag checks #. Heap spray checks #. Thread shellcode checks #. Security descriptor pointer and ACLs checks Module Load Violation (EVENT_MODULE_LOAD_VIOLATION) --------------------------------------------------- This event is generated when HVI detects executions inside suspicious modules while they are loading. For example, this is the event generated in double agent detection & blocking, when a suspicious module loads before kernel32.dll. Identifying the module load violation attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - :code:`Originator.Module` should always be valid. :code:`Originator.ReturnModule` may be invalid. - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process: - If the attack took place in **user-mode**, this is the source and destination process. Note that :code:`Header.CurrentProcess` should be equal to :code:`Victim`. Engines Detection Violation (EVENT_ENGINES_DETECTION_VIOLATION) --------------------------------------------------------------- This is a generic violation event generated when the engines report a detection for a buffer that has been sent by Introcore. For now, only the following types of buffers are scanned by Introcore using the engines: - The command line of a process which has the **PROC_OPT_PROT_SCAN_CMD_LINE** (note that PowerShell.exe normally has this flag set) - A memory region that has been executed inside the guest, outside a legitimately loaded module Identifying engines detection the attack source ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If the :code:`Originator.Module` is valid, the source of the attack is :code:`Module` - :code:`Originator.Module` should always be valid. :code:`Originator.ReturnModule` may be invalid. - If the :code:`Header.CurrentProcess` is valid, the attack took place inside that process: - If the :code:`Header.Type` is :code:`introEngineNotificationCmdLine`, :code:`Header.CurrentProcess` is the parent process (the one that provided the malicious command line). - If the :code:`Header.Type` is :code:`introEngineNotificationCodeExecution` and the attack took place in **user-mode**, this is the source and destination process. Note that :code:`Header.CurrentProcess` should be equal to :code:`Victim`. Events ====== Process Creation/Termination (EVENT_PROCESS_EVENT) -------------------------------------------------- These are sent whenever a new process is created or terminated, on both Windows and Linux. This type of event is enabled using the **INTRO_OPT_ENABLE_MISC_EVENTS** option. Module load/unload (EVENT_MODULE_EVENT) --------------------------------------- These events are sent whenever a new kernel module is loaded or unloaded on both Windows and Linux. In addition, on Windows, such an event will be sent for user-mode modules as well, but only those loaded/unloaded from protected processes. This type of event is enabled using the **INTRO_OPT_ENABLE_MISC_EVENTS** option.  Agent events (EVENT_AGENT_ACTION) --------------------------------- This event is used for communication with in-guest agents. The content is agent-specific. More info about agents communication and injection flow can be found in the :ref:`Agents Architecture section `. OS crash (EVENT_CRASH_EVENT) ---------------------------- This event is generated when a guest OS crashes (BSOD on Windows or panic on Linux). This type of event is enabled using the **INTRO_OPT_ENABLE_MISC_EVENTS** option.  User Mode Exception (EVENT_EXCEPTION_EVENT) ------------------------------------------- This event is generated when an exception is generated inside a user mode process. This type of event is enabled using the **INTRO_OPT_ENABLE_MISC_EVENTS** option.  Connections (EVENT_CONNECTION_EVENT) ------------------------------------ This event describes a TCP/IP connection identified inside the guest. The connection events are sent whenever an exploit is detected.