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.

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 Originator.Module is valid, the source of the attack is Module
  • If the Originator.Module is invalid but the Originator.ReturnModule is valid, the source of the attack is the ReturnModule
  • If the Originator.Module is invalid and the Originator.ReturnModule is invalid, the source of the attack cannot be identified
  • If the Header.CurrentProcess is invalid, the attack took place at boot time when no processes were created (Header.CurrentProcess will always be valid for user-mode events)
  • If the 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 CurrentProcess, Module and ReturnModule all invalid
  • After the first process is created, 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 Originator.Module is valid, the source of the attack is Module
  • If the Originator.Module is invalid but the Originator.ReturnModule is valid, the source of the attack is the ReturnModule
  • If the Originator.Module is invalid and the Originator.ReturnModule is invalid, the source of the attack cannot be identified
  • If the Header.CurrentProcess is invalid, the attack took place at boot time when no processes were created (Header.CurrentProcess will always be valid for user-mode events)
  • If the 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 CurrentProcess, Module, and ReturnModule invalid
  • After the first process is created, 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 Originator.Module is valid, the source of the attack is Module
  • If the Originator.Module is invalid but the Originator.ReturnModule is valid, the source of the attack is the ReturnModule
  • If the Originator.Module is invalid and the Originator.ReturnModule is invalid, the source of the attack cannot be identified
  • If the Header.CurrentProcess is invalid, the attack took place at boot time when no processes were created (Header.CurrentProcess will always be valid for user-mode events)
  • If the 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 CurrentProcess, Module and ReturnModule invalid
  • After the first process is created, 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 Originator.Module is valid, the source of the attack is Module
  • If the Originator.Module is invalid but the Originator.ReturnModule is valid, the source of the attack is the ReturnModule
  • If the Originator.Module is invalid and the Originator.ReturnModule is invalid, the source of the attack cannot be identified
  • If the Header.CurrentProcess is invalid, the attack took place at BOOT time when no processes were created.
  • If the 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
    • WriteProcessMemory
    • ReadProcessMemory (only when a process tries to read the lsass.exe memory)
    • SetContextThread
    • QueueApcThread
    • NtSetInformationProcess (only when a process tries to set an instrumentation callback)
  • Linux
    • ptrace
    • process_vm_rw
    • 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:

  1. Checks done for the PROC_OPT_PROT_PREVENT_CHILD_CREATION protection flag
  2. Stolen token checks
  3. Token privileges checks
  4. Pivoted stack checks
  5. Debug flag checks
  6. Heap spray checks
  7. Thread shellcode checks
  8. 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 Originator.Module is valid, the source of the attack is Module
  • Originator.Module should always be valid. Originator.ReturnModule may be invalid.
  • If the 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 Header.CurrentProcess should be equal to 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 Originator.Module is valid, the source of the attack is Module
  • Originator.Module should always be valid. Originator.ReturnModule may be invalid.
  • If the Header.CurrentProcess is valid, the attack took place inside that process:
    • If the Header.Type is introEngineNotificationCmdLine, Header.CurrentProcess is the parent process (the one that provided the malicious command line).
    • If the Header.Type is introEngineNotificationCodeExecution and the attack took place in user-mode, this is the source and destination process. Note that Header.CurrentProcess should be equal to 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 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.