Reference: EDR Events¶
Overview¶
This page provides a detailed overview of all events generated by the LimaCharlie Endpoint Agent. Each event type represents a specific system activity, from process creation to network connections and file modifications. Events serve as key components in detection, response, and monitoring, enabling security teams to track, analyze, and take action on endpoint behavior. Use this guide to understand the purpose and structure of each event for effective threat detection and investigation.
Generally, event types ending with *_REP are emitted in response to a command being issued to the endpoint agent.
EDR Events by Supported OS¶
These are the events emitted by the endpoint agent for each supported operating system. Below the table, you can find descriptions of each event type.
Event Descriptions¶
APP_CONTROL_DENIED¶
Generated by Application Control when the policy denies an execution. APP_CONTROL_IS_ENFORCED tells you whether the sensor blocked it (1) or, in a permissive or permissive_sync policy, only reported a would-be block (0).
When the policy has summarizing on, which is the case for policies delivered by the Application Control extension, only the first occurrence of a repeated block in a five-minute window is reported as APP_CONTROL_DENIED. The repeats are folded into an APP_CONTROL_DENIED_SUMMARY event.
Fields marked optional are absent, never empty or zero, when the sensor does not know the value.
| Field | Description |
|---|---|
FILE_PATH |
Path of the program. |
PROCESS_ID |
Process ID of the execution. |
HASH |
SHA-256 of the file. Optional. |
APP_CONTROL_DECISION |
The decision the sensor reached: 1 deny, 2 unresolved. |
APP_CONTROL_REASON |
The reason for the decision, as a number. See Reason codes. |
APP_CONTROL_MODE |
Mode of the policy in effect: 0 off, 1 permissive, 2 permissive_sync, 3 enforcing. |
APP_CONTROL_GENERATION |
Generation of the policy the sensor was running. |
APP_CONTROL_POLICY_LABEL |
The name of the policy that produced the event, which is the record name of the policy in the app_control_policy hive. Optional. |
APP_CONTROL_IS_ENFORCED |
1 if the sensor blocked the execution, 0 if it only reported it. |
APP_CONTROL_MATCHED_RULE |
The rule that matched. Optional. |
APP_CONTROL_MATCHED_RULE_ID |
The id of the rule that matched, which is the record name in the app_control_rule hive. Optional. |
APP_CONTROL_SIGNER |
The signer the sensor saw. Optional. |
APP_CONTROL_SIGNING_ID |
The code-signing identifier the sensor saw (macOS). Optional. |
APP_CONTROL_SIGNATURE_STATUS |
What the code signature check concluded: 1 valid, 2 unsigned, 3 invalid, 4 untrusted, 5 expired. Optional, absent when no check was made. |
APP_CONTROL_VENDOR_TRUSTED |
1 if the program counts as the operating system vendor's own, 0 if not, whatever the policy then did with that. Optional, absent when it could not be established. |
APP_CONTROL_ISSUER_THUMBPRINT |
SHA-256 thumbprint, in hex, of the authority that issued the signing certificate. Windows only, optional. Can be pasted into a signer_root rule. |
APP_CONTROL_ROOT_THUMBPRINT |
SHA-256 thumbprint, in hex, of the root of the certificate chain the operating system validated. Windows only, optional. Can be pasted into a signer_root rule. |
APP_CONTROL_HASH_SOURCE |
Where HASH came from: 1 the bytes that were judged, 2 the file at the same path, read after the decision. Optional, present with HASH. |
USER_ID |
User ID the execution was run as. Optional. |
USER_NAME |
User name the execution was run as. Optional. |
PARENT |
The launching process, as a sequence holding its PROCESS_ID and FILE_PATH. Optional. |
COMMAND_LINE |
Command line of the execution. Optional. Reported on macOS, and in permissive mode, where the sensor takes it from process telemetry. |
APP_CONTROL_BUNDLE_PATH |
Path of the enclosing .app bundle (macOS). Optional. |
PACKAGE_NAME |
Bundle identifier of the application (macOS). Optional. |
PACKAGE_VERSION |
Bundle version of the application (macOS). Optional. |
APP_CONTROL_PRODUCT_NAME |
ProductName from the file's version resource (Windows). Optional. |
APP_CONTROL_COMPANY_NAME |
CompanyName from the file's version resource (Windows). Optional. |
APP_CONTROL_FILE_VERSION |
FileVersion from the file's version resource (Windows). Optional. |
ORIGINAL_FILE_NAME |
OriginalFilename from the file's version resource (Windows). Optional. |
Available on Windows and macOS.
Reason codes¶
APP_CONTROL_REASON is one of these numbers. Only a denied or unresolved decision becomes an event. The allow reasons below are decisions the sensor makes and counts, so you will not see them in APP_CONTROL_DENIED.
| Code | Name | Decision | Meaning |
|---|---|---|---|
0 |
sensor_self |
Allow | The program is the sensor's own. |
1 |
allow_rule |
Allow | An allow rule matched. |
2 |
vendor_trust |
Allow | Implicit OS vendor trust. |
3 |
installer_child |
Allow | The process was started by a trusted installer, or by one of its descendants. The matched rule is the installer rule. |
4 |
installed_by_installer |
Allow | A trusted installer wrote these exact bytes. The matched rule is the installer rule. |
10 |
deny_rule |
Deny | A deny rule matched. |
11 |
no_match |
Deny | Nothing matched, and the policy is an allowlist. |
20 to 60 |
Unresolved | The sensor could not decide. These come with APP_CONTROL_UNRESOLVED. 20 to 28 concern the policy (absent, invalid, refused, expired, not newer), 30 to 33 the enforcement channel, 40 to 45 time or capacity, 50 to 52 a file that could not be read or fully examined, and 60 the authorizer itself. |
APP_CONTROL_RESIDENT¶
Generated by Application Control when a policy arrives and a program that was already running is one the policy refuses, according to the policy's on_enable. It is not an execution that was refused, so it is a separate event from APP_CONTROL_DENIED: a detection on APP_CONTROL_DENIED does not fire for it.
The sensor looks at running programs once for each policy generation it installs, and again after the sensor restarts. A policy with on_enable: leave, or with mode: off, produces none.
The event carries the fields of APP_CONTROL_DENIED, with these differences:
| Field | Description |
|---|---|
APP_CONTROL_IS_ENFORCED |
1 if the sensor terminated the program, which only happens with on_enable: terminate and mode: enforcing. 0 if it was only reported. |
APP_CONTROL_DECISION |
1, the policy refuses the program. |
An unresolved verdict, such as a signature the sensor could not check, is never reported or acted on.
The sensor also reports counters in the status it sends with each policy sync:
| Field | Description |
|---|---|
APP_CONTROL_N_RESIDENT |
Running programs the installed policy refused. Present unless on_enable is leave. |
APP_CONTROL_N_TERMINATED |
How many of those the sensor terminated. Present unless on_enable is leave. |
APP_CONTROL_N_INSTALLED |
File digests that trusted installers wrote and that the sensor now lets run. Present only when the policy names an installer. |
Available on Windows and macOS.
APP_CONTROL_UNRESOLVED¶
Generated by Application Control when the sensor could not evaluate an execution and allowed it. Its fields are the ones listed for APP_CONTROL_DENIED, and the optional ones may be absent.
An unresolved execution in an enforcing policy is never folded into a summary: each one ran unjudged on a host that is meant to be stopping things, so each is reported on its own.
Available on Windows and macOS.
APP_CONTROL_DENIED_SUMMARY¶
Generated by Application Control when a policy has summarizing on and a verdict repeated. The first occurrence of a verdict is always reported immediately as APP_CONTROL_DENIED (or APP_CONTROL_UNRESOLVED), so alerting stays real time. Repeats of the same verdict within five minutes of the first are counted instead of reported, and a single APP_CONTROL_DENIED_SUMMARY is generated when that window closes. No summary is generated when nothing repeated.
Two occurrences are the same verdict when they name the same program (by SHA-256 when the sensor took one, otherwise by path, signer and signing identifier) and drew the same decision, for the same reason and rule, with the same enforcement.
A summary has its own event name on purpose, so a detection rule written against APP_CONTROL_DENIED does not fire a second time for occurrences it was already told about. Write a rule against APP_CONTROL_DENIED_SUMMARY if you want one.
It describes the first occurrence in the window. It carries FILE_PATH, PROCESS_ID (of that first occurrence), HASH, APP_CONTROL_DECISION, APP_CONTROL_REASON, APP_CONTROL_MODE, APP_CONTROL_GENERATION, APP_CONTROL_POLICY_LABEL, APP_CONTROL_IS_ENFORCED, APP_CONTROL_MATCHED_RULE, APP_CONTROL_MATCHED_RULE_ID, APP_CONTROL_SIGNER and APP_CONTROL_SIGNING_ID as described for APP_CONTROL_DENIED, plus:
| Field | Description |
|---|---|
APP_CONTROL_COUNT |
How many times the verdict occurred in the window, the occurrence already reported as APP_CONTROL_DENIED included. |
APP_CONTROL_FIRST_TS |
When the first occurrence happened, in epoch milliseconds. |
APP_CONTROL_LAST_TS |
When the last occurrence happened, in epoch milliseconds. |
The per-execution context (user, launching process, command line, version information) is not repeated on a summary, since it differs between the occurrences it stands for.
Available on Windows and macOS.
AUTORUN_CHANGE¶
Generated when an Autorun is changed.
Platforms:
{
"REGISTRY_KEY": "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
"TIMESTAMP": 1627497894000
}
CLOUD_NOTIFICATION¶
This event is a receipt from the agent that it has received the task sent to it, and includes high-level errors (if any).
Platforms:
{
"NOTIFICATION_ID": "ADD_EXFIL_EVENT_REQ",
"NOTIFICATION": {
"INVESTIGATION_ID": "digger-4afdeb2b-a0d8-4a37-83b5-48996117998e"
},
"HCP_IDENT": {
"HCP_ORG_ID": "c82e5c17d5194ef5a4acc454a95d31db",
"HCP_SENSOR_ID": "8fc370e6699a49858e75c1316b725570",
"HCP_INSTALLER_ID": "00000000000000000000000000000000",
"HCP_ARCHITECTURE": 0,
"HCP_PLATFORM": 0
},
"EXPIRY": 0
}
CODE_IDENTITY¶
Unique combinations of file hash and file path. This event is emitted the first time the combination is seen, typically when the binary is executed or loaded. Therefore it's a great event to look for hashes without being overwhelmed by process execution or module loads.
ONGOING_IDENTITY
The ONGOING_IDENTITY event emits code signature information even if not newly seen, however this data can become duplicative and verbose.
Platforms:
{
"MEMORY_SIZE": 0,
"FILE_PATH": "C:\\Users\\dev\\AppData\\Local\\Temp\\B1B207E5-300E-434F-B4FE-A4816E6551BE\\dismhost.exe",
"TIMESTAMP": 1456285265,
"SIGNATURE": {
"CERT_ISSUER": "C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Code Signing PCA",
"CERT_CHAIN_STATUS": 124,
"FILE_PATH": "C:\\Users\\dev\\AppData\\Local\\Temp\\B1B207E5-300E-434F-B4FE-A4816E6551BE\\dismhost.exe",
"CERT_SUBJECT": "C=US, S=Washington, L=Redmond, O=Microsoft Corporation, OU=MOPR, CN=Microsoft Corporation"
},
"HASH": "4ab4024eb555b2e4c54d378a846a847bd02f66ac54849bbce5a1c8b787f1d26c"
}
CONNECTED¶
This event is generated when a Sensor connects to the cloud.
Platforms:
{
"HOST_NAME" : "demo-win-2016",
"IS_SEGREGATED" : 0,
"KERNEL_ACQ_AVAILABLE" : 1,
"MAC_ADDRESS" : "42-01-0A-80-00-02"
}
CONTAINER_LIST_REP¶
Response event for the container_list sensor command.
Platforms: Linux
Each entry in CONTAINERS describes one container or, when --include-images
is used, one local image (CONTAINER_IS_IMAGE). Entries discovered from cgroups
but not enriched by a container daemon are marked CONTAINER_IS_PARTIAL, and
CONTAINER_DAEMON_ERRORS counts the daemon queries that failed.
CONTAINER_ID is the full 64-character identifier, not the shortened form the
Docker CLI prints. CONTAINER_IMAGE_DIGEST is a bare 64-character digest with
no sha256: prefix.
The agent enriches records by querying the Docker and Podman sockets. It has no
containerd or CRI-O client, so containers under those runtimes are discovered by
scanning cgroups alone and are always reported as partial, carrying
CONTAINER_ID, CONTAINER_RUNTIME, PROCESS_ID and STATE but no name or
image reference. On a containerd-only host, such as a typical Kubernetes node,
every entry is partial. --include-images and --include-stopped likewise
apply to Docker and Podman only.
Sample Event:
{
"event": {
"CONTAINERS": [
{
"CONTAINER_ID": "b66423fa5cb15cb7dad7ee901e91d4e022916fdc977ba43c30b8ca2f953e8d79",
"CONTAINER_RUNTIME": "docker",
"NAME": "web-frontend",
"CONTAINER_IMAGE_REF": "nginx:1.27",
"CONTAINER_IMAGE_DIGEST": "9c2b0f6cd1a54e5f3f8c2b1d7e4a09b3c65d8e2f1a4b7c093d6e5f8a2b1c4d7e0",
"CONTAINER_CREATED_AT": 1756684800000,
"STATE": "running",
"PROCESS_ID": 4812
}
],
"SCAN_ENTRIES_SCANNED": 217,
"CONTAINER_DAEMON_ERRORS": 0,
"CONTAINER_IS_PARTIAL": 0,
"SCAN_IS_TRUNCATED": 0,
"SCAN_STOPPED_REASON": "complete"
}
}
DEBUG_DATA_REP¶
Response from a get_debug_data request. It reports the sensor's own internal state at the moment of the request, including PACKAGE_VERSION_STRING and PACKAGE_VERSION_GIT (the running build), UPTIME, PROCESS_ID, PERCENT_CPU, MEMORY_USAGE, TIMEDELTA (the sensor's clock offset), KERNEL_ACQ_AVAILABLE, and, starting with sensor version 5.3.6, LOSS_ACCOUNTING.
Platforms:
LOSS_ACCOUNTING¶
Added in sensor version 5.3.6
LOSS_ACCOUNTING is reported only by sensors running version 5.3.6 or later. Older sensors answer get_debug_data without it, and its absence from a reply says nothing about whether that sensor has dropped events — it only means the sensor is too old to report the figures.
LOSS_ACCOUNTING is a sub-sequence describing what the sensor's outbound event queue has thrown away since the sensor started, together with the queue's current depth and the bounds it is being measured against.
It answers a different question than DATA_DROPPED: DATA_DROPPED tells you that a sensor is losing events right now, while LOSS_ACCOUNTING tells you how much that host has lost in total, in events and in bytes, and how close its queue is to saturating. Event sizes span several orders of magnitude — a DNS request event is a few hundred bytes, a command receipt can be a megabyte — so a count of lost events on its own does not describe how much data was actually lost.
| Field | Type | Description |
|---|---|---|
LOSS_EVICTED_EVENTS |
uint64 | Cumulative number of events discarded from the front of the queue to make room for newer ones. Any non-zero value means the queue reached one of its bounds at least once. |
LOSS_EVICTED_BYTES |
uint64 | Estimated size, in bytes, of the events counted by LOSS_EVICTED_EVENTS. |
LOSS_REFUSED_EVENTS |
uint64 | Cumulative number of events rejected as they were queued, because a single event was larger than the queue's entire byte budget and no amount of eviction would have made room for it. |
LOSS_REFUSED_BYTES |
uint64 | Estimated size, in bytes, of the events counted by LOSS_REFUSED_EVENTS. |
LOSS_QUEUED_EVENTS |
uint32 | Number of events waiting in the queue at the moment the reply was produced. |
LOSS_QUEUED_BYTES |
uint32 | Estimated size, in bytes, of the events waiting in the queue at that moment. |
LOSS_MAX_EVENTS |
uint32 | The event-count bound the queue is enforcing. Defaults to 10000; 0 means no limit. |
LOSS_MAX_BYTES |
uint32 | The byte bound the queue is enforcing. Defaults to 52428800 (50 MB); 0 means no limit. |
Sample LOSS_ACCOUNTING value (the rest of the DEBUG_DATA_REP fields are omitted):
{
"LOSS_ACCOUNTING": {
"LOSS_EVICTED_EVENTS": 1423,
"LOSS_EVICTED_BYTES": 5218764,
"LOSS_REFUSED_EVENTS": 0,
"LOSS_REFUSED_BYTES": 0,
"LOSS_QUEUED_EVENTS": 9998,
"LOSS_QUEUED_BYTES": 41904128,
"LOSS_MAX_EVENTS": 10000,
"LOSS_MAX_BYTES": 52428800
}
}
Interpreting LOSS_ACCOUNTING¶
- The four loss totals are cumulative and are never reset while the sensor runs. A single sample tells you what has been lost since the sensor process started; to get a rate, request
get_debug_datatwice and subtract. Restarting the sensor — including an upgrade — returns the totals to0. - The byte figures are estimates of the in-memory size of the events, measured as they were queued. They are not the number of bytes those events would have weighed on the wire, so treat them as a measure of how much telemetry was lost rather than as an exact transfer size.
- Read the loss totals against the depth and bounds in the same sequence.
LOSS_QUEUED_*andLOSS_MAX_*are the denominator: several hundred evicted events on a queue that is now nearly empty describes a burst that has already passed, while the same number on a queue sitting atLOSS_MAX_EVENTSorLOSS_MAX_BYTESdescribes a host that is still shedding telemetry. - Both bounds are enforced on every event that enters the queue, so eviction can be triggered by either the event count or the byte budget. A host generating many small events reaches
LOSS_MAX_EVENTSfirst; a host producing a few very large events reachesLOSS_MAX_BYTESfirst. - A non-zero
LOSS_REFUSED_EVENTSmeans individual events too large for the queue, which is a different problem than an overloaded queue and is not solved by the host catching up on its backlog. - These totals are accounted separately from the counter behind
DATA_DROPPED. Requestingget_debug_datadoes not consume or reset anythingDATA_DROPPEDreports, so the two signals can be used together.
DIR_FIND_REP¶
Response event for the dir_find sensor command.
Platforms: macOS | Windows | Linux
FILES holds one entry per hit. HASH_MD5, HASH_SHA1 and HASH (SHA-256)
are present only when --with-hashes was requested. FILE_IS_DIRECTORY marks
directory hits returned by --include-dirs.
Every bounded search reports how much work it did, so a truncated result is never mistaken for an empty one:
SCAN_ENTRIES_SCANNED: filesystem entries examinedSCAN_FILES_SCANNED: files considered after the include/exclude expressionsSCAN_BYTES_PROCESSED: bytes readSCAN_IS_TRUNCATED:1when a budget stopped the search earlySCAN_STOPPED_REASON: which budget stopped it, one ofcomplete,max_results,max_entries,max_secondsormax_bytes
Sample Event:
{
"event": {
"FILES": [
{
"FILE_PATH": "C:\\Users\\jdoe\\Downloads\\setup.exe",
"FILE_SIZE": 481232,
"MODIFICATION_TIME": 1756771200000,
"HASH_MD5": "77a097c81e679798f68f968be1498620",
"HASH_SHA1": "55c92f35ad24bc59ca2ea74028203ae3a3a7d493",
"HASH": "aeb6310a1ac57c1beb98d74361c58b056522780c1b4d60e7a6c605ecaed47e01"
}
],
"SCAN_ENTRIES_SCANNED": 18422,
"SCAN_FILES_SCANNED": 15310,
"SCAN_BYTES_PROCESSED": 4812331,
"SCAN_IS_TRUNCATED": 0,
"SCAN_STOPPED_REASON": "complete"
}
}
DIR_FINDHASH_REP¶
Response event for the dir_find_hash sensor command.
Platforms:
Sample Event:
{
"DIRECTORY_LIST": [
{
"HASH": "f11dda931637a1a1bc614fc2f320326b24336c5155679aa062acae7c79f33d67",
"ACCESS_TIME": 1535994794247,
"FILE_SIZE": 113664,
"CREATION_TIME": 1467173189067,
"MODIFICATION_TIME": 1467173190171,
"FILE_NAME": "MALWARE_DEMO_WINDOWS_1.exe",
"ATTRIBUTES": 32,
"FILE_PATH": "c:\\users\\dev\\desktop\\MALWARE_DEMO_WINDOWS_1.exe"
},
{
"HASH": "e37726feee8e72f3ab006e023cb9d6fa1a4087274b47217d2462325fa8008515",
"ACCESS_TIME": 1535989041078,
"FILE_SIZE": 1016320,
"CREATION_TIME": 1522507344821,
"MODIFICATION_TIME": 1522507355732,
"FILE_NAME": "lc_win_64.exe",
"ATTRIBUTES": 32,
"FILE_PATH": "c:\\users\\dev\\desktop\\lc_win_64.exe"
}
],
"HASH": [
"f11dda931637a1a1bc614fc2f320326b24336c5155679aa062acae7c79f33d67",
"e37726feee8e72f3ab006e023cb9d6fa1a4087274b47217d2462325fa8008515"
],
"FILE_PATH": "*.exe",
"DIRECTORY_LIST_DEPTH": 0,
"DIRECTORY_PATH": "c:\\users\\dev\\desktop\\"
}
DIR_LIST_REP¶
Response event for the dir_list sensor command. Includes Alternate Data Streams on Windows.
Platforms:
Sample Event:
{
"DIRECTORY_LIST": [
{
"FILE_NAME": "vssdk_full.exe",
"CREATION_TIME": 1553437930012,
"MODIFICATION_TIME": 1553437937000,
"STREAMS": [
{
"FILE_NAME": "::$DATA",
"SIZE": 13782032
}
],
"ACCESS_TIME": 1567868284440,
"FILE_SIZE": 13782032,
"ATTRIBUTES": 32,
"FILE_PATH": "c:\\users\\dev\\desktop\\vssdk_full.exe"
},
{
"FILE_NAME": "UniversalLog.txt",
"CREATION_TIME": 1553028205525,
"MODIFICATION_TIME": 1553028206289,
"STREAMS": [
{
"FILE_NAME": "::$DATA",
"SIZE": 125
},
{
"FILE_NAME": ":Zone.Identifier:$DATA",
"SIZE": 377
}
],
"ACCESS_TIME": 1567868284158,
"FILE_SIZE": 125,
"ATTRIBUTES": 32,
"FILE_PATH": "c:\\users\\dev\\desktop\\UniversalLog.txt"
}
]
}
DNS_REQUEST¶
Generated from DNS responses and therefore includes both the requested domain and the response from the server. If the server responds with multiple responses (as allowed by the DNS protocol) the N answers will become N DNS_REQUEST events, so you can always assume one DNS_REQUEST event means one answer.
Platforms:
DRIVER_CHANGE¶
Generated when a driver is changed.
Platforms:
{
"PROCESS_ID": 0,
"SVC_DISPLAY_NAME": "HbsAcq",
"SVC_NAME": "HbsAcq",
"SVC_STATE": 1,
"SVC_TYPE": 1,
"TIMESTAMP": 1517377895873
}
EXISTING_PROCESS¶
This event is similar to the NEW_PROCESS event. It gets emitted when a process existed prior to the LimaCharlie sensor loading.
Platforms:
FILE_CREATE¶
Generated when a file is created.
Note:
On macOS and Linux, file events require the sensor's kernel acquisition component to be installed and active (system extension or kext on macOS, eBPF kernel module on Linux). Without it, no
FILE_CREATEevents are generated. On Windows the kernel acquisition driver provides full coverage; a user-mode fallback emits a reduced set when the driver is not loaded.
Platforms:
{
"FILE_PATH": "C:\\Users\\dev\\AppData\\Local\\Microsoft\\Windows\\WebCache\\V01tmp.log",
"TIMESTAMP": 1468335271948
}
FILE_DEL_REP¶
Response event for the file_del sensor command.
Platforms:
Sample Event:
FILE_DELETE¶
Generated when a file is deleted.
Note:
On macOS and Linux, file events require the sensor's kernel acquisition component to be installed and active (system extension or kext on macOS, eBPF kernel module on Linux). Without it, no
FILE_DELETEevents are generated. On Windows the kernel acquisition driver provides full coverage; a user-mode fallback emits a reduced set when the driver is not loaded.Be Aware:
When adding this event to an event collection rule, you will be monitoring system-wide. This could result in a large number of events.
Best Practices:
- Utilize this selectively (ex. deploy on only suspect systems)
- Use Exfil watch rules to specify paths that are of high interest
- Consider using File Integrity Monitoring (FIM)
- Look for this on an ad-hoc basis from the Sensor Console. ex.
Platforms:
{
"FILE_PATH": "C:\\Users\\dev\\AppData\\Local\\Temp\\EBA4E4F0-3020-459E-9E34-D5336E244F05\\api-ms-win-core-processthreads-l1-1-2.dll",
"TIMESTAMP": 1468335611906
}
FILE_GET_REP¶
Response event for the file_get sensor command.
Platforms:
Sample Event:
{
"FILE_CONTENT": "$BASE64_ENCODED_FILE_CONTENTS",
"FILE_PATH": "C:\\windows\\system32\\svchost.exe",
"FILE_SIZE": 78880
}
FILE_GREP_REP¶
Response event for the file_grep sensor command.
Platforms: macOS | Windows | Linux
FILE_MATCHES is a flat list of matches across all files. MATCH_PATTERN_INDEX
is the zero-based index of the --pattern that matched. FILE_CONTENT carries
the matched bytes plus any requested --context-bytes, and is absent entirely
when the search was run with --no-content. It is base64-encoded, because the
matched region is raw bytes and need not be valid text. MATCH_OFFSET and
MATCH_LENGTH describe the match within the file, not within FILE_CONTENT.
Every bounded search reports how much work it did, so a truncated result is never mistaken for an empty one:
SCAN_ENTRIES_SCANNED: filesystem entries examinedSCAN_FILES_SCANNED: files considered after the include/exclude expressionsSCAN_BYTES_PROCESSED: bytes readSCAN_IS_TRUNCATED:1when a budget stopped the search earlySCAN_STOPPED_REASON: which budget stopped it, one ofcomplete,max_results,max_entries,max_secondsormax_bytes
Sample Event:
{
"event": {
"FILE_MATCHES": [
{
"FILE_PATH": "/home/jdoe/app/.env",
"MATCH_PATTERN_INDEX": 0,
"MATCH_OFFSET": 412,
"MATCH_LENGTH": 21,
"FILE_CONTENT": "REJfSE9TVD0xMC4wLjAuNQpleHBvcnQgQVdTX1NFQ1JFVF9BQ0NFU1NfS0VZPXdKYWxyWFV0bkZFTUkvSzdNREVORwoj"
}
],
"SCAN_ENTRIES_SCANNED": 9014,
"SCAN_FILES_SCANNED": 7781,
"SCAN_BYTES_PROCESSED": 33814402,
"SCAN_IS_TRUNCATED": 0,
"SCAN_STOPPED_REASON": "complete"
}
}
FILE_HASH_REP¶
Response event for the file_hash sensor command.
Platforms:
Sample Event:
{
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Windows\\System32\\svchost.exe",
"HASH": "31780ff2aaf7bc71f755ba0e4fef1d61b060d1d2741eafb33cbab44d889595a0",
"SIGNATURE": {
"CERT_ISSUER": "C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011",
"CERT_SUBJECT": "C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Publisher",
"FILE_CERT_IS_VERIFIED_LOCAL": 1,
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Windows\\System32\\svchost.exe"
}
}
FILE_INFO_REP¶
Response event for the file_info sensor command.
Platforms:
Sample Event:
{
"ACCESS_TIME": 1686685723546,
"ATTRIBUTES": 0,
"CREATION_TIME": 1686685723546,
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Windows\\System32\\svchost.exe",
"FILE_SIZE": 78880,
"MODIFICATION_TIME": 1686685723546
}
FILE_MODIFIED¶
Generated when a file is modified.
Note:
On macOS and Linux, file events require the sensor's kernel acquisition component to be installed and active (system extension or kext on macOS, eBPF kernel module on Linux). Without it, no
FILE_MODIFIEDevents are generated. On Windows the kernel acquisition driver provides full coverage; a user-mode fallback emits a reduced set when the driver is not loaded.Be Aware:
When adding this event to an event collection rule, you will be monitoring system-wide. This could result in a large number of events.
Best Practices:
- Utilize this selectively (ex. deploy on only suspect systems)
- Use Exfil watch rules to specify paths that are of high interest
- Consider using File Integrity Monitoring (FIM)
- Look for this on an ad-hoc basis from the Sensor Console. ex.
Platforms:
{
"FILE_PATH": "C:\\Users\\dev\\AppData\\Local\\Microsoft\\Windows\\WebCache\\V01.log",
"TIMESTAMP": 1468335272949
}
FILE_MOV_REP¶
Response event for the file_mov sensor command.
Platforms:
Sample Event:
FILE_TYPE_ACCESSED¶
Generated when a new process is observed interacting with certain file types.
The RULE_NAME component is the class of file extension involved:
- Rule 1:
.doc,.docm,.docx - Rule 2:
.xlt,.xlsm,.xlsx - Rule 3:
.ppt,.pptm,.pptx,.ppts - Rule 4:
.pdf - Rule 5:
.rtf - Rule 50:
.zip - Rule 51:
.rar - Rule 64:
.locky,.aesir
Platforms:
FIM_ADD¶
Response event for the fim_add sensor command. An ERROR: 0 implies the path was successfully added.
Platforms:
Output:
FIM_REMOVE¶
Response event for the fim_del sensor command. An ERROR: 0 implies the path was successfully removed.
An ERROR: 3 response implies the provided path was not found in the list of FIM patterns.
Platforms:
Output:
FIM_HIT¶
A file, directory, or registry key being monitored by File & Registry Integrity Monitoring has been modified.
Platforms:
{
"PROCESS": {
"MEMORY_USAGE": 25808896,
"TIMESTAMP": 1541348299886,
"COMMAND_LINE": "\"C:\\WINDOWS\\regedit.exe\" ",
"PROCESS_ID": 4340,
"THREADS": 3,
"USER_NAME": "BUILTIN\\Administrators",
"FILE_PATH": "C:\\WINDOWS\\regedit.exe",
"PARENT_PROCESS_ID": 6260
},
"REGISTRY_KEY": "\\REGISTRY\\MACHINE\\SOFTWARE\\ActiveState\\New Value #1",
"PROCESS_ID": 4340
}
FIM_LIST_REP¶
Response event for the fim_get sensor command. The response will be a JSON list of FIM patterns.
Platforms:
Output:
GET_DOCUMENT_REP¶
Generated when a doc_cache_get task requests a cached document.
Platforms:
GET_EXFIL_EVENT_REP¶
Response from an exfil_get sensor command.
Platforms:
HIDDEN_MODULE_DETECTED¶
Generated when a hidden_module_scan command is issued.
Note that the name of the event does not confirm the presence of a hidden module. Please check the output to
confirm whether a hidden module was detected.
Platforms:
Sample Event:
HISTORY_DUMP_REP¶
Response from history_dump sensor command. Does not itself contain the historic events but will be generated along them.
Platforms:
HTTP_REQUEST¶
This event is emitted whenever an HTTP request is made.
Platforms:
Sample Event:
{
"URL": "https://play.google.com/log?authuser=0",
"IP_ADDRESS": "172.217.2.142",
"RESULT": 200,
"PARENT": {
"URL": "https://console.cloud.google.com"
}
}
HTTP_REQUEST_HEADERS¶
Provides HTTP Request headers.
Platforms:
Sample Event:
{
"HEADERS": [
{
"NAME": "User-Agent",
"VALUE": "Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36"
},
{
"NAME": "Accept",
"VALUE": "*/*"
}
]
}
HTTP_RESPONSE_HEADERS¶
Provides HTTP Response headers.
Platforms:
Sample Event:
{
"HEADERS": [
{
"NAME": "content-length",
"VALUE": "859"
},
{
"NAME": "cache-control",
"VALUE": "max-age=3600"
},
{
"NAME": "content-encoding",
"VALUE": "br"
},
{
"NAME": "content-type",
"VALUE": "text/html; charset=utf-8"
},
{
"NAME": "etag",
"VALUE": "\"1540d7725dd15680377d45886baba56f620f7692faa530bc3597226ffadd77d1-br\""
},
{
"NAME": "last-modified",
"VALUE": "Thu, 21 Dec 2023 23:59:32 GMT"
},
{
"NAME": "referrer-policy",
"VALUE": "sameorigin"
},
{
"NAME": "strict-transport-security",
"VALUE": "max-age=3600 ; includeSubDomains"
},
{
"NAME": "x-content-type-options",
"VALUE": "nosniff"
},
{
"NAME": "x-frame-options",
"VALUE": "sameorigin"
},
{
"NAME": "accept-ranges",
"VALUE": "bytes"
},
{
"NAME": "date",
"VALUE": "Fri, 22 Dec 2023 19:10:58 GMT"
},
{
"NAME": "x-served-by",
"VALUE": "cache-dub4332-DUB"
},
{
"NAME": "x-cache",
"VALUE": "HIT"
},
{
"NAME": "x-cache-hits",
"VALUE": "1"
},
{
"NAME": "x-timer",
"VALUE": "S1703272259.579745,VS0,VE1"
},
{
"NAME": "vary",
"VALUE": "x-fh-requested-host, accept-encoding"
},
{
"NAME": "alt-svc",
"VALUE": "h3=\":443\";ma=86400,h3-29=\":443\";ma=86400,h3-27=\":443\";ma=86400"
}
]
}
LOG_GET_REP¶
Response from a log_get or artifact_get request.
For a multi-file artifact_get --root-dir request, the event carries a FILES
list with one entry per selected file (FILE_PATH, PAYLOAD_ID, ERROR, and
ERROR_MESSAGE on failure), plus the scan accounting fields
SCAN_ENTRIES_SCANNED, SCAN_FILES_SCANNED, SCAN_BYTES_PROCESSED,
SCAN_IS_TRUNCATED and SCAN_STOPPED_REASON.
LOG_LIST_REP¶
Response from a log_list request.
MEM_FIND_HANDLES_REP¶
Response event for the mem_find_handle sensor command.
Platforms:
MEM_FIND_STRING_REP¶
Response event for the mem_find_string sensor command.
Platforms:
MEM_HANDLES_REP¶
Response event for the mem_handles sensor command. This event will contain an array of handles identified in memory.
Platforms:
Sample Event:
{
"HANDLES": [
{
"HANDLE_NAME": "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options",
"HANDLE_TYPE": "Key",
"HANDLE_VALUE": 4,
"PROCESS_ID": 908
},
{
"HANDLE_NAME": "\\KnownDlls",
"HANDLE_TYPE": "Directory",
"HANDLE_VALUE": 48,
"PROCESS_ID": 908
},
"..."]
}
MEM_MAP_REP¶
Response event for the mem_map sensor command. This event will contain an array of arrays, representing processes and their associated memory data.
Platforms:
Sample Event:
{
"MEMORY_MAP": [
{
"BASE_ADDRESS": 94100802174976,
"MEMORY_ACCESS": 6,
"MEMORY_SIZE": 4096,
"MEMORY_TYPE": 3
}
]
}
MEM_READ_REP¶
Response event for the mem_read sensor command.
Platforms:
Sample Event:
MEM_STRINGS_REP¶
Response event for the mem_strings sensor command. The response will contain two arrays of arrays, STRINGSA and STRINGSW.
Platforms:
Sample Event:
{
"PROCESS_ID" : 745,
"STRINGSA" : [
[
0 : "/lib64/ld-linux-x86-64.so.2",
1 : "__gmon_start__"
]
]
}
MODULE_LOAD¶
Generated when a module (like DLL on Windows) is loaded in a process.
Platforms:
{
"MEMORY_SIZE": 241664,
"PROCESS_ID": 2904,
"FILE_PATH": "C:\\Windows\\System32\\imm32.dll",
"MODULE_NAME": "imm32.dll",
"TIMESTAMP": 1468335264989,
"BASE_ADDRESS": 140715814092800
}
NETSTAT_REP¶
Response from a netstat command to list active network sockets.
Platforms:
Sample Event:
{
"FRIENDLY": 0,
"NETWORK_ACTIVITY": [
{
"DESTINATION": {
"IP_ADDRESS": "0.0.0.0",
"PORT": 0
},
"PROCESS_ID": 856,
"PROTOCOL": "tcp4",
"SOURCE": {
"IP_ADDRESS": "0.0.0.0",
"PORT": 135
}
}
]
}
NETWORK_CONNECTIONS¶
List of recent network connections performed by a process.
Platforms:
{
"NETWORK_ACTIVITY": [
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50396
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "23.214.49.56",
"PORT": 80
}
},
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50397
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "189.247.166.18",
"PORT": 80
}
},
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50398
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "23.217.70.67",
"PORT": 80
}
},
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50399
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "104.110.238.53",
"PORT": 80
}
},
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50400
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "23.214.49.56",
"PORT": 80
}
},
{
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50401
},
"IS_OUTGOING": 1,
"DESTINATION": {
"IP_ADDRESS": "204.79.197.203",
"PORT": 80
}
}
],
"HASH": "2de228cad2e542b2af2554d61fab5463ecbba3ff8349ba88c3e48637ed8086e9",
"COMMAND_LINE": "C:\\WINDOWS\\system32\\msfeedssync.exe sync",
"PROCESS_ID": 6968,
"FILE_IS_SIGNED": 1,
"USER_NAME": "WIN-5KC7E0NG1OD\\dev",
"FILE_PATH": "C:\\WINDOWS\\system32\\msfeedssync.exe",
"PARENT_PROCESS_ID": 1892
}
NEW_DOCUMENT¶
Generated when a file is created that matches a set list of locations and extensions. It indicates the file has been cached in memory and can be retrieved using the doc_cache_get task.
The following file patterns are considered "documents":
.bat.js.ps1.sh.py.exe.scr.pdf.doc.docm.docx.ppt.pptm.pptx.xlt.xlsm.xlsx.vbs.rtf.hta.lnk.xsl.com.png.jpg.asp.aspx.php\windows\system32\
Platforms:
{
"FILE_PATH": "C:\\Users\\dev\\Desktop\\evil.exe",
"TIMESTAMP": 1468335816308,
"HASH": "aeb6310a1ac57c1beb98d74361c58b056522780c1b4d60e7a6c605ecaed47e01"
}
NEW_NAMED_PIPE¶
This event is emitted when a new Named Pipe is created by a process.
Platforms:
{
"FILE_PATH": "\\Device\\NamedPipe\\LOCAL\\mojo.6380.1072.2134013463507075011",
"PROCESS_ID": 6380
}
NEW_PROCESS¶
Generated when a new process starts.
Platforms:
{
"PARENT": {
"PARENT_PROCESS_ID": 7076,
"COMMAND_LINE": "\"C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\devenv.exe\" ",
"MEMORY_USAGE": 438730752,
"PROCESS_ID": 5820,
"THREADS": 39,
"FILE_PATH": "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\devenv.exe",
"BASE_ADDRESS": 798949376
},
"PARENT_PROCESS_ID": 5820,
"COMMAND_LINE": "-q -s {0257E42D-7F05-42C4-B402-34C1CC2F2EAD} -p 5820",
"FILE_PATH": "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcpackages\\VCPkgSrv.exe",
"PROCESS_ID": 1080,
"THREADS": 9,
"MEMORY_USAGE": 8282112,
"TIMESTAMP": 1456285660,
"BASE_ADDRESS": 4194304
}
NEW_REMOTE_THREAD¶
Generated when a thread is created by a process in another process. This is often used by malware during various forms of code injection.
In this case, the process id 492 created a thread (with id 9012) in the process id 7944. The parent process is also globally uniquely identified by the routing/parent and the process where the thread was started is globally uniquely identified by the routing/target (not visible here).
Platforms:
NEW_TCP4_CONNECTION¶
Generated when a new TCPv4 connection is established, either inbound or outbound.
Platforms:
{
"PROCESS_ID": 6788,
"DESTINATION": {
"IP_ADDRESS": "172.16.223.219",
"PORT": 80
},
"STATE": 5,
"TIMESTAMP": 1468335512047,
"SOURCE": {
"IP_ADDRESS": "172.16.223.163",
"PORT": 63581
}
}
NEW_TCP6_CONNECTION¶
Generated when a new TCPv6 connection is established, either inbound or outbound.
Platforms:
NEW_UDP4_CONNECTION¶
Generated when a new UDPv4 socket "connection" is established, either inbound or outbound.
Platforms:
NEW_UDP6_CONNECTION¶
Generated when a new UDPv6 socket "connection" is established, either inbound or outbound.
Platforms:
OPEN_NAMED_PIPE¶
This event is emitted when an existing Named Pipe is opened by a process.
Platforms:
OS_AUTORUNS_REP¶
Response from an os_autoruns request.
Platforms:
Sample Event:
{
"TIMESTAMP": 1456194620,
"AUTORUNS": [
{
"REGISTRY_KEY": "Software\\Microsoft\\Windows\\CurrentVersion\\Run\\VMware User Process",
"FILE_PATH": "\"C:\\Program Files\\VMware\\VMware Tools\\vmtoolsd.exe\" -n vmusr",
"HASH": "036608644e3c282efaac49792a2bb2534df95e859e2ddc727cd5d2e764133d14"
}
]
}
OS_DRIVERS_REP¶
Response from an os_drivers request.
Platforms:
Sample Event:
{
"SVCS": [
{
"PROCESS_ID": 0,
"SVC_TYPE": 1,
"SVC_NAME": "1394ohci",
"SVC_STATE": 1,
"HASH": "9ecf6211ccd30273a23247e87c31b3a2acda623133cef6e9b3243463c0609c5f",
"SVC_DISPLAY_NAME": "1394 OHCI Compliant Host Controller",
"EXECUTABLE": "\\SystemRoot\\System32\\drivers\\1394ohci.sys"
}
]
}
OS_KILL_PROCESS_REP¶
Response from an os_kill_process request.
Platforms:
Sample Event:
OS_PACKAGES_REP¶
List of packages installed on the system. This is currently Windows only but will be expanded to MacOS and Linux in the future.
Platforms:
Sample Event:
OS_PROCESSES_REP¶
Response from an os_process request.
Platforms:
Sample Event:
{
"PROCESSES": [
{
"COMMAND_LINE": "/sbin/init",
"FILE_PATH": "/usr/lib/systemd/systemd",
"HASH": "477209848fabcaf52c060d98287f880845cb07fc9696216dbcfe9b6ea8e72bcd"
}
]
}
OS_RESUME_REP¶
Response from an os_resume request.
Platforms:
OS_SERVICES_REP¶
Response from an os_services request.
Platforms:
Sample Event:
{
"SVCS": [
{
"PROCESS_ID": 0,
"SVC_TYPE": 32,
"DLL": "%SystemRoot%\\System32\\AJRouter.dll",
"SVC_NAME": "AJRouter"
}
]
}
OS_SUSPEND_REP¶
Response from an os_suspend request.
Platforms:
OS_USERS_REP¶
Response from an os_users request.
Platforms:
Sample Event:
OS_VERSION_REP¶
Response from an os_version request.
Platforms:
Sample Event:
PCAP_LIST_INTERFACES_REP¶
Response from a pcap_ifaces request.
Platforms:
Sample Event:
PROCESS_ENVIRONMENT¶
Generated when a process starts. It lists all environment variables associated with that new process.
Platforms:
{
"ENVIRONMENT_VARIABLES": [
"LANG=en_US.UTF-8",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NOTIFY_SOCKET=/run/systemd/notify",
"LISTEN_PID=18950",
"LISTEN_FDS=2"
],
"PROCESS_ID": 13463
}
RECEIPT¶
This event is used as a generic response to some commands. The contents of a RECEIPT event usually contain an ERROR code that you can use to determine if the command was successful (see Error Codes for the complete list). It's often a good idea to issue the original command with an investigation_id which will get echoed in the RECEIPT related to that command to make it easier to track.
Platforms:
REGISTRY_CREATE¶
This event is generated whenever a registry key / value is created on a Windows OS.
Platforms:
{
"PROCESS_ID": 764,
"REGISTRY_KEY": "\\REGISTRY\\A\\{fddf4643-a007-4086-903e-be998801d0f7}\\Events\\{8fb5d848-23dc-498f-ac61-84b93aac1c33}"
}
REGISTRY_DELETE¶
This event is generated whenever a registry key / value is deleted on a Windows OS.
Platforms:
{
"PROCESS_ID": 764,
"REGISTRY_KEY": "\\REGISTRY\\A\\{fddf4643-a007-4086-903e-be998801d0f7}\\Events\\{8fb5d848-23dc-498f-ac61-84b93aac1c33}"
}
REGISTRY_LIST_REP¶
This event is generated in response to the reg_list command to list keys and values in a registry key.
Platforms:
Sample Event:
{
"REGISTRY_KEY": [
"ActiveState"
],
"ROOT": "hklm\\software",
"REGISTRY_VALUE": [
{
"TYPE": 4,
"NAME": "Order"
}
],
"ERROR": 0
}
REGISTRY_GET_REP¶
This event is generated in response to the reg_get command to fetch a single named value from a registry key.
Note: Added in sensor version 5.3.0.
The VALUE field holds the value's data when it is under the size cap; for larger values, SIZE is returned instead. ERROR is the Windows error code (0 on success).
Platforms:
Sample Event:
{
"ROOT": "hklm\\software\\microsoft\\windows\\currentversion\\run",
"NAME": "OneDrive",
"TYPE": 1,
"VALUE": "\"C:\\Program Files\\Microsoft OneDrive\\OneDrive.exe\" /background",
"ERROR": 0
}
REGISTRY_WRITE¶
This event is generated whenever a registry value is written to on a Windows OS.
The REGISTRY_VALUE contains the first 16 bytes of the value written to the registry. If this value is a valid ASCII or Unicode string, the value will be as-is. On the other hand if the value is binary data, it will be a base64 encoded string, see examples below.
The SIZE is the size value used in the original registry write call. The TYPE is the Windows data type of the entry written as per Microsoft's definition.
Platforms:
Valid string payload:
{
"PROCESS_ID":1820,
"REGISTRY_KEY":"\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows Defender\\Diagnostics\\LastKnownGoodPlatformLocation",
"REGISTRY_VALUE":"C:\\Progr",
"SIZE":1,
"TYPE":1,
}
Binary payload:
{
"PROCESS_ID": 1700,
"REGISTRY_KEY": "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Diagnostics\\DiagTrack\\HeartBeats\\Default\\LastHeartBeatTime",
"REGISTRY_VALUE": "bMPGjjDM1wE=","SIZE": 11,
"TYPE": 11
}
REJOIN_NETWORK¶
Emitted after a sensor is allowed network connectivity again (after it was previously segregated). An error code of 0 indicates success.
Platforms:
Sample Event:
REMOTE_PROCESS_HANDLE¶
Generated whenever a process opens a handle to another process with access flags like VM_READ, VM_WRITE, or PROCESS_CREATE_THREAD.
The ACCESS_FLAGS is the access mask as defined in Microsoft's Process Security and Access Rights reference.
Platforms:
REPO_LIST_REP¶
Response event for the repo_list sensor command.
Platforms: macOS | Windows | Linux
REPOSITORY_LIST holds one entry per git working copy found. Each entry carries
DIRECTORY_PATH (the working copy) and REPOSITORY_GIT_DIR (its git directory,
which differs for linked worktrees and submodules), plus the checked-out
revision.
REPOSITORY_HEAD_COMMIT: the commitHEADresolves toREPOSITORY_HEAD_REF: the branchHEADpoints at, absent on a detachedHEADREPOSITORY_IS_DETACHED:1whenHEADnames a commit rather than a branchREPOSITORY_REMOTES: the configured remotes, each withNAMEandURLREPOSITORY_SUBMODULES: present only when--with-submoduleswas requested, each withNAME,DIRECTORY_PATHandURLas declared in.gitmodules
The reply echoes the budgets it ran under and reports the work it did, so a truncated result is never mistaken for an empty one:
SCAN_ENTRIES_SCANNED: filesystem entries examinedSCAN_IS_TRUNCATED:1when a budget stopped the search earlySCAN_STOPPED_REASON: which budget stopped it, one ofcomplete,max_results,max_entriesormax_seconds
DIRECTORY_PATH at the top level lists the roots that were searched, and is
absent when the command ran against the agent's own per-platform defaults.
Sample Event:
{
"event": {
"REPOSITORY_LIST": [
{
"DIRECTORY_PATH": "C:\\Users\\jdoe\\src\\lc-test-repo",
"REPOSITORY_GIT_DIR": "C:\\Users\\jdoe\\src\\lc-test-repo\\.git",
"REPOSITORY_HEAD_COMMIT": "0123456789abcdef0123456789abcdef01234567",
"REPOSITORY_HEAD_REF": "refs/heads/main",
"MODIFICATION_TIME": 1756771200000,
"REPOSITORY_REMOTES": [
{
"NAME": "origin",
"URL": "https://github.com/example/lc-test-repo.git"
}
],
"REPOSITORY_SUBMODULES": [
{
"NAME": "vendor/dep",
"DIRECTORY_PATH": "vendor/dep",
"URL": "https://github.com/example/dep.git"
}
]
},
{
"DIRECTORY_PATH": "C:\\Users\\jdoe\\src\\detached",
"REPOSITORY_GIT_DIR": "C:\\Users\\jdoe\\src\\detached\\.git",
"REPOSITORY_HEAD_COMMIT": "fedcba9876543210fedcba9876543210fedcba98",
"REPOSITORY_IS_DETACHED": 1,
"MODIFICATION_TIME": 1756771200000
}
],
"REPOSITORY_WITH_SUBMODULES": 1,
"DIRECTORY_LIST_DEPTH": 6,
"SCAN_ENTRIES_SCANNED": 1195,
"SCAN_MAX_ENTRIES": 500000,
"SCAN_MAX_RESULTS": 200,
"SCAN_MAX_SECONDS": 120,
"SCAN_IS_TRUNCATED": 0,
"SCAN_STOPPED_REASON": "complete"
}
}
SEGREGATE_NETWORK¶
Emitted when a sensor is segregated (isolated) from the network using the segregate_network command. An error code of 0 indicates success.
Platforms:
Sample Event:
SENSITIVE_PROCESS_ACCESS¶
Generated when a process gains sensitive access to operating system processes like lsass.exe on Windows.
Note
SENSITIVE_PROCESS_ACCESS currently is only emitted for processes accessing lsass.exe on Windows.
Platforms:
{
"EVENTS": [
{
"event": {
"COMMAND_LINE": "C:\\WINDOWS\\system32\\lsass.exe",
"FILE_PATH": "C:\\WINDOWS\\system32\\lsass.exe",
"PARENT_PROCESS_ID": 484,
"PROCESS_ID": 636,
"THREADS": 12,
"USER_NAME": "BUILTIN\\Administrators"
}
}
]
}
SERVICE_CHANGE¶
Generated when a Service is changed.
Platforms:
{
"PROCESS_ID": 0,
"SVC_TYPE": 32,
"DLL": "%SystemRoot%\\system32\\wlidsvc.dll",
"SVC_NAME": "wlidsvc",
"SVC_STATE": 1,
"HASH": "b37199495115ed423ba99b7317377ce865bb482d4e847861e871480ac49d4a84",
"SVC_DISPLAY_NAME": "Microsoft Account Sign-in Assistant",
"TIMESTAMP": 1467942600540,
"EXECUTABLE": "%SystemRoot%\\system32\\svchost.exe -k netsvcs"
}
SSH_LOGIN¶
Generated when a user logs in via SSH.
Platforms:
SELF_TEST¶
Internal event to manually request a power-on-self-test (POST) from the sensor.
SHUTTING_DOWN¶
Event generated when the sensor shuts down. Note: this event may not be observed if the host shuts down abruptly or too quickly.
Platforms:
Event Data¶
| Field | Type | Notes |
|---|---|---|
| ts | Epoch timestamp |
Sample Event:
SSH_LOGOUT¶
Generated when a user logs out via SSH.
Platforms:
STARTING_UP¶
Event generated when the sensor starts.
Platforms:
Event Data¶
| Field | Type | Notes |
|---|---|---|
| ts | Epoch timestamp |
Sample Event:
TERMINATE_PROCESS¶
Generated when a process exits.
Platforms:
TERMINATE_TCP4_CONNECTION¶
Generated when a TCPv4 connection terminates.
{
"DESTINATION": {
"IP_ADDRESS": "61.55.252.93",
"PORT": 443
},
"PROCESS_ID": 4784,
"SOURCE": {
"IP_ADDRESS": "172.16.223.138",
"PORT": 50145
}
}
TERMINATE_TCP6_CONNECTION¶
Generated when a TCPv6 connection terminates.
TERMINATE_UDP4_CONNECTION¶
Generated when a UDPv4 socket terminates.
TERMINATE_UDP6_CONNECTION¶
Generated when a UDPv6 socket terminates.
THREAD_INJECTION¶
This event is generated when the sensor detects what looks like a thread injection into a remote process.
Platforms:
{
"event": {
"EVENTS": [
{
"event": {
"ACCESS_FLAGS": 2097151,
"PARENT_PROCESS_ID": 5380,
"PROCESS_ID": 4276,
"SOURCE": {
"BASE_ADDRESS": 140701160243200,
"COMMAND_LINE": "\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\" --continue-active-setup",
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe",
"HASH": "c47fc20231ffc1e3befef952478363bff96cf3af1f36da4bd1129c8ed0e17fdb",
"MEMORY_USAGE": 5881856,
"PARENT_ATOM": "df4e951a09e365cb46c36c11659ee556",
"PARENT_PROCESS_ID": 5972,
"PROCESS_ID": 5380,
"THIS_ATOM": "37b57d228af708b25d097f32659ee557",
"THREADS": 3,
"TIMESTAMP": 1704912214704,
"USER_NAME": "WINDOWS-SERVER-\\whitney"
},
"TARGET": {
"COMMAND_LINE": "C:\\Windows\\system32\\sppsvc.exe",
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Windows\\system32\\sppsvc.exe",
"HASH": "1ca5b9745872748575c452e456966b8ed1c4153757e9f4faf6f86c78c53d4ae8",
"MEMORY_USAGE": 6156288,
"PARENT_ATOM": "74be005ef68f6edb8682d972659ee024",
"PARENT_PROCESS_ID": 628,
"PROCESS_ID": 4276,
"THIS_ATOM": "fe1dee93442392ea97becdad659ee516",
"THREADS": 3,
"TIMESTAMP": 1704912150174,
"USER_NAME": "NT AUTHORITY\\NETWORK SERVICE"
}
},
"routing": {
"arch": 2,
"did": "",
"event_id": "d61caa47-225a-4f6a-9f3a-6094cdb3c383",
"event_time": 1704912219717,
"event_type": "REMOTE_PROCESS_HANDLE",
"ext_ip": "104.198.223.172",
"hostname": "windows-server-2022-bc76d608-9d83-4c6c-bdd5-f86bbd385a94-0.c.lc-demo-infra.internal.",
"iid": "3c5c33e6-daaf-4029-be0b-94f50b86777e",
"int_ip": "10.128.15.197",
"moduleid": 2,
"oid": "bc76d608-9d83-4c6c-bdd5-f86bbd385a94",
"parent": "37b57d228af708b25d097f32659ee557",
"plat": 268435456,
"sid": "ccd0c386-88c1-4f8d-954c-581a95a1cc34",
"tags": [
"windows"
],
"target": "fe1dee93442392ea97becdad659ee516",
"this": "87509849fc608bce8a236f49659ee55b"
}
},
{
"event": {
"PARENT_PROCESS_ID": 5380,
"PROCESS_ID": 4276,
"SOURCE": {
"BASE_ADDRESS": 140701160243200,
"COMMAND_LINE": "\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\" --continue-active-setup",
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe",
"HASH": "c47fc20231ffc1e3befef952478363bff96cf3af1f36da4bd1129c8ed0e17fdb",
"MEMORY_USAGE": 5881856,
"PARENT_ATOM": "df4e951a09e365cb46c36c11659ee556",
"PARENT_PROCESS_ID": 5972,
"PROCESS_ID": 5380,
"THIS_ATOM": "37b57d228af708b25d097f32659ee557",
"THREADS": 3,
"TIMESTAMP": 1704912214704,
"USER_NAME": "WINDOWS-SERVER-\\whitney"
},
"TARGET": {
"COMMAND_LINE": "C:\\Windows\\system32\\sppsvc.exe",
"FILE_IS_SIGNED": 1,
"FILE_PATH": "C:\\Windows\\system32\\sppsvc.exe",
"HASH": "1ca5b9745872748575c452e456966b8ed1c4153757e9f4faf6f86c78c53d4ae8",
"MEMORY_USAGE": 6156288,
"PARENT_ATOM": "74be005ef68f6edb8682d972659ee024",
"PARENT_PROCESS_ID": 628,
"PROCESS_ID": 4276,
"THIS_ATOM": "fe1dee93442392ea97becdad659ee516",
"THREADS": 3,
"TIMESTAMP": 1704912150174,
"USER_NAME": "NT AUTHORITY\\NETWORK SERVICE"
},
"THREAD_ID": 3672
},
"routing": {
"arch": 2,
"did": "",
"event_id": "ece7d85e-a43c-49d3-bc9a-28ace6dc1b02",
"event_time": 1704912219967,
"event_type": "NEW_REMOTE_THREAD",
"ext_ip": "104.198.223.172",
"hostname": "windows-server-2022-bc76d608-9d83-4c6c-bdd5-f86bbd385a94-0.c.lc-demo-infra.internal.",
"iid": "3c5c33e6-daaf-4029-be0b-94f50b86777e",
"int_ip": "10.128.15.197",
"moduleid": 2,
"oid": "bc76d608-9d83-4c6c-bdd5-f86bbd385a94",
"parent": "37b57d228af708b25d097f32659ee557",
"plat": 268435456,
"sid": "ccd0c386-88c1-4f8d-954c-581a95a1cc34",
"tags": [
"windows"
],
"target": "fe1dee93442392ea97becdad659ee516",
"this": "b30a499edf9ec2e424b07d20659ee55b"
}
}
]
}
"ts": "2024-01-10 18:43:39"
}
USB_DEVICE_LIST_REP¶
Response event for the usb_list_devices sensor command.
Platforms: macOS | Windows | Linux
USB_DEVICES holds one entry per USB device currently attached, and is an empty
list when the host has none. ERROR is 0 on success. The related
usb_list_keys command reports only mass-storage keys, whereas this one reports
every attached device whatever its class.
Each entry describes the device and the interfaces it exposes:
USB_VENDOR_IDandUSB_PRODUCT_ID: the USB vendor and product identifiers, as integers rather than the hexadecimal notation vendor lists useUSB_DEVICE_CLASS: the device-level USB class,0when the class is declared per interface insteadUSB_USB_VERSION: the USB revision as hundredths, so300is USB 3.0 and210is USB 2.1. The agent decodes the device's binary-coded-decimal descriptor into this form, and reports0when the descriptor is not valid BCD rather than guessing at it.USB_MANUFACTURER_STRING,USB_PRODUCT_STRING,USB_SERIAL_NUMBER: the descriptor strings, each omitted entirely when the device does not report itUSB_INTERFACES: one entry per interface, withUSB_INTERFACE_CLASS,USB_INTERFACE_SUBCLASSandUSB_INTERFACE_PROTOCOL. A device that exposes no interfaces reports an empty list.
Sample Event:
{
"event": {
"USB_DEVICES": [
{
"USB_VENDOR_ID": 2385,
"USB_PRODUCT_ID": 5734,
"USB_DEVICE_CLASS": 0,
"USB_USB_VERSION": 300,
"USB_MANUFACTURER_STRING": "Kingston",
"USB_SERIAL_NUMBER": "BAD0USB",
"USB_INTERFACES": [
{
"USB_INTERFACE_CLASS": 8,
"USB_INTERFACE_SUBCLASS": 6,
"USB_INTERFACE_PROTOCOL": 80
},
{
"USB_INTERFACE_CLASS": 3,
"USB_INTERFACE_SUBCLASS": 1,
"USB_INTERFACE_PROTOCOL": 1
}
]
}
],
"ERROR": 0
}
}
USER_LOGIN¶
Generated when a user logs in to the operating system.
Platforms:
USER_LOGOUT¶
Generated when a user logs out of the operating system.
Platforms:
USER_OBSERVED¶
Generated the first time a user is observed on a host.
Platforms:
VOLUME_MOUNT¶
This event is generated when a volume is mounted.
Platforms:
VOLUME_UNMOUNT¶
This event is generated when a volume is unmounted.
Platforms:
YARA_DETECTION¶
Generated when a YARA scan finds a match.
Platforms: