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.
APP_CONTROL_POLICY_REP¶
Response event for the app_control_policy
sensor command. Requires sensor version 5.4.0 or later.
Platforms: macOS | Windows
| Field | Description |
|---|---|
ERROR |
0. The command succeeds even when no policy is installed. |
APP_CONTROL_STATUS |
The sensor's Application Control status, the same block it sends in SYNC. See below. |
FILE_PATH |
Where the sensor keeps its cached copy of the policy on the host. Reported even when no policy is installed. |
APP_CONTROL_N_RULES |
The number of rules in the installed policy. Always present, 0 when there is no policy. |
APP_CONTROL_RULES |
The rules, as a list of APP_CONTROL_RULE entries. At most 256 are listed; compare their number with APP_CONTROL_N_RULES to tell whether the list was capped. Absent when the policy has no rules. |
APP_CONTROL_STATUS holds, among others:
APP_CONTROL_MODE:0off,1permissive,2permissive_sync,3enforcingAPP_CONTROL_STANCE:0blocklist,1allowlistAPP_CONTROL_GENERATION: the generation of the installed policy, which is the time the cloud issued it, in seconds since the epochAPP_CONTROL_POLICY_AGE_SEC: how old the installed policy is, in secondsAPP_CONTROL_N_EVALUATED,APP_CONTROL_N_DENIED,APP_CONTROL_N_UNRESOLVED: counts of the executions judged, denied and left unresolvedAPP_CONTROL_KEY_ID: the ids of the policy signing keys this sensor accepts, 8 bytes each, concatenated. Absent when the sensor holds no key. Only theapp_control_policyreply carries it;SYNCdoes notAPP_CONTROL_REFUSED: present when the sensor declined a policy, with the refusedAPP_CONTROL_GENERATION, theAPP_CONTROL_REASON(listed under Managed alerts) and theTIMESTAMPof the refusal
Each APP_CONTROL_RULE carries:
APP_CONTROL_RULE_ACTION:0allow,1denyAPP_CONTROL_RULE_KIND: what the rule matches:0path (an exact path, or a directory when the value ends in a separator),1signer (Apple Team ID on macOS, Authenticode publisher on Windows),2signing identifier (macOS),3signer root (SHA-256 thumbprint of a certificate in the chain),4SHA-256 of the fileAPP_CONTROL_RULE_VALUE: the value matchedAPP_CONTROL_RULE_ID: the rule's record name in theapp_control_rulehive. Absent when the policy carried no id for it
AUTORUN_CHANGE¶
Generated when an Autorun is changed.
Platforms:
{
"REGISTRY_KEY": "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
"TIMESTAMP": 1627497894000
}
CERT_STORE_LIST_REP¶
Response event for the cert_store_list
sensor command. Requires sensor version 5.4.2 or later.
Platforms: macOS | Windows | Linux
CERTIFICATES holds one entry per certificate per store. A certificate present
in two stores appears twice, once under each.
CERT_STORE: the store it was found in, such asLocalMachine\ROOT,/etc/ssl/certs/ca-certificates.crtorSystem.keychainHASH: the SHA-256 fingerprint of the certificate, in hexadecimalHASH_SHA1: the SHA-1 fingerprint, which is the thumbprint Windows displaysCERT_SUBJECT,CERT_ISSUER: the subject and issuer namesCERT_SERIAL: the serial number, in hexadecimalCERT_NOT_BEFORE,CERT_NOT_AFTER: the validity period, in milliseconds since the epoch. Absent for a date before 1970CERT_IS_CA:1when the certificate is a certificate authority. Absent otherwiseCERT_SELF_SIGNED:1when its subject and issuer are the same, as for a root. Absent otherwiseCERT_IS_PARSE_ERROR:1when the certificate could not be parsed. Such an entry carries onlyCERT_STORE,HASH,HASH_SHA1and this flag
The reply also describes the listing itself:
SCHEMA_VERSION: the version of this reply's layout, currently1CERT_STORES_READ: how many stores were readCERT_STORES_FAILED: how many stores exist but could not be readIS_TRUNCATED:1when a bound stopped the listing earlySCAN_STOPPED_REASON:complete, or the bound that stopped it:max_results(the--max-resultslimit),max_bytes(the total size of the certificates parsed),max_store_certs(a single store holding more certificates than the agent reads from one store) ormax_entries(an anchor directory, the keystore locations or the total amount of files read reached the agent's limit). Any of them means some certificates were not listed
When ERROR is present, the listing was refused or failed, and the reply
carries no certificates and none of the fields above.
Sample Event:
{
"event": {
"CERTIFICATES": [
{
"CERT_STORE": "/etc/ssl/certs/ca-certificates.crt",
"HASH": "96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6",
"HASH_SHA1": "cabd2a79a1076a31f21d253635cb039d4329a5e8",
"CERT_SUBJECT": "C=US, O=Internet Security Research Group, CN=ISRG Root X1",
"CERT_ISSUER": "C=US, O=Internet Security Research Group, CN=ISRG Root X1",
"CERT_SERIAL": "8210cfb0d240e3594463e0bb63828b00",
"CERT_NOT_BEFORE": 1433415878000,
"CERT_NOT_AFTER": 2064567878000,
"CERT_IS_CA": 1,
"CERT_SELF_SIGNED": 1
}
],
"CERT_STORES_READ": 1,
"CERT_STORES_FAILED": 0,
"SCHEMA_VERSION": 1,
"IS_TRUNCATED": 0,
"SCAN_STOPPED_REASON": "complete"
}
}
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"
}
}
CRASH_DUMP_INFO_REP¶
Response event for the crash_dump_info
sensor command. Requires sensor version 5.4.2 or later.
Platforms: Windows
A host with no dumps is a success with an empty CRASH_DUMPS list. When
ERROR is not 0, for example because the path given with --file-path is
not a dump, the reply carries no list.
| Field | Description |
|---|---|
ERROR |
0 on success. |
CRASH_DUMPS |
One CRASH_DUMP entry per dump. See below. |
SCAN_IS_TRUNCATED |
1 when more dumps were waiting than --limit allowed. Run the command again for the next ones. |
CRASH_DUMPS_ALREADY_LISTED |
How many dumps on the host an earlier plain listing already reported, and were left out. |
CRASH_DUMPS_SINCE |
For a plain listing, the time the listing started from: dumps modified after it are reported. In milliseconds since the epoch. Absent on a first listing. |
Each CRASH_DUMP describes one dump. Fields the dump does not contain are
absent rather than empty.
The file and the stop:
FILE_PATH,FILE_SIZE,MODIFICATION_TIME: the dump fileCRASH_DUMP_TYPE: the kind of dump:1complete,2kernel,4small,5bitmap,6live bitmap,8kernel memory,9kernel and user memory,10complete memoryCRASH_DUMP_IS_LIVE:1for a live kernel report, which Windows writes without stopping the machine. Absent for a real crashCRASH_TIME: when the crash happened, in milliseconds since the epochSYSTEM_UPTIME: how long the host had been up, in millisecondsBUGCHECK_CODE,BUGCHECK_NAME,BUGCHECK_DESCRIPTION: the stop code, for example209(0xD1),DRIVER_IRQL_NOT_LESS_OR_EQUAL, with a descriptionBUGCHECK_PARAMETERS: the stop code's four parametersERROR_MESSAGE: notes about what could not be read from the dump
The machine:
VERSION_MAJOR,BUILD_NUMBER,SERVICE_PACK,PRODUCT_TYPE,SUITE: the Windows version that crashedMACHINE_TYPE,CRASH_ARCHITECTURE,NUMBER_OF_PROCESSORS
The analysis, for a small memory dump only:
PROBABLE_CAUSE: the strongest candidate fromCRASH_CANDIDATESCRASH_CANDIDATES: the drivers the evidence implicates, strongest first. Each carriesMODULE_NAME,BASE_ADDRESS,MEMORY_SIZE,TIMESTAMP, theMEMORY_ADDRESSthat implicated it, aREASONin words, and aCONFIDENCE:highwhen Windows named the driver or a stop code parameter points inside it,lowwhen it is only the first driver found on the crashing thread's stack. When the driver is found on the host's disk, it also carries itsFILE_PATH, its signer asCERT_SUBJECT,FILE_IS_SIGNED, andIMAGE_MATCHES_DUMP,1when the file on disk is the same build that was loaded at the crashCRASH_CULPRIT: the driver Windows itself blamed, when it named oneINSTRUCTION_POINTER,STACK_POINTER,CRASH_EXCEPTION(with itsEXCEPTION_CODE): where the crashing thread wasSTACK_TRACE: the crashing thread's stack, as frames with aMEMORY_ADDRESSand, when a loaded driver holds it, theMODULE_NAME,BASE_ADDRESSandMODULE_OFFSET.SCAN_IS_TRUNCATEDis1when the stack was longer than the sensor readsMODULES: the drivers loaded at the crash, each withMODULE_NAME,FILE_PATH,BASE_ADDRESS,MEMORY_SIZEand its linkTIMESTAMP. The size and link time identify the exact build of a driver to a symbol serverUNLOADED_MODULES: drivers unloaded before the crash. Their address range may have been reused, so a stack frame can resolve to a different driver than the one that was really thereCRASH_DATA_BLOCKS: extra memory Windows saved in the dump, each block with itsMEMORY_ADDRESS,MEMORY_SIZEand theSTACK_TRACEof driver addresses found in it
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:
FILE_CONTENT: the bytes read, base64-encoded. Absent when nothing was readFILE_SIZE: the size of the file. For a Linux kernel file whose reported size is wrong (most of/proc,/sysand/sys/kernel/security), sensors from version 5.4.2 report the size they actually read insteadIS_TRUNCATED:1when the file continues pastFILE_CONTENT. Use it, rather than comparingFILE_SIZEwith the content, to tell whether the whole file was returned. Sensors from version 5.4.2 onlyERROR: present only when the read failed
Sample Event:
{
"FILE_CONTENT": "$BASE64_ENCODED_FILE_CONTENTS",
"FILE_PATH": "C:\\windows\\system32\\svchost.exe",
"FILE_SIZE": 78880,
"IS_TRUNCATED": 0
}
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, returned by the os_packages command.
Each entry in PACKAGES can include the following fields. Availability depends on the platform, package source, and sensor build.
| Field | RPCM tag | Description |
|---|---|---|
PACKAGE_NAME |
105 | Package name. |
PACKAGE_VERSION |
106 | Package version, when available. |
OS_PACKAGE_PUBLISHER |
286 | Publisher from the Windows uninstall-registry Publisher value. |
OS_PACKAGE_UNINSTALL_STRING |
287 | Uninstall command from the Windows uninstall-registry UninstallString value. |
OS_PACKAGE_INSTALL_LOCATION |
288 | Installation directory from the Windows uninstall-registry InstallLocation value. |
OS_PACKAGE_SOURCE |
296 | Package inventory source, such as a package manager. |
OS_PACKAGE_ARCHITECTURE |
297 | Package architecture, when available. |
OS_PACKAGE_PATH |
298 | Exact file path associated with the package, when available. |
OS_PACKAGE_ORIGIN |
299 | Package origin reported by the inventory source, when available. |
OS_PACKAGE_PUBLISHER, OS_PACKAGE_UNINSTALL_STRING, and OS_PACKAGE_INSTALL_LOCATION are Windows-only and are only sent by newer Windows sensors. Each field is optional and omitted when its registry value is empty. OS_PACKAGE_INSTALL_LOCATION (288) is an installation directory, distinct from the exact file path in OS_PACKAGE_PATH (298).
Platforms:
Sample Event:
{
"PACKAGES": [
{
"PACKAGE_NAME": "Example App",
"PACKAGE_VERSION": "1.0",
"OS_PACKAGE_PUBLISHER": "Example Software",
"OS_PACKAGE_UNINSTALL_STRING": "\"C:\\Program Files\\Example App\\uninstall.exe\"",
"OS_PACKAGE_INSTALL_LOCATION": "C:\\Program Files\\Example App"
}
]
}
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_SECURITY_STATE_REP¶
Response event for the os_security_state
sensor command. Requires sensor version 5.4.2 or later. The items each platform
reports are listed with the command.
Platforms: macOS | Windows | Linux
SECURITY_ITEMS holds one entry per setting:
NAME: the item's stable, dotted name, such aslinux.sysctl.kernel.yama.ptrace_scopeSECURITY_ITEM_STATUS:0read,1absent from this host,2unreadable,3present but not in a known shapeSECURITY_ITEM_VALUE: the raw value. Present only when the status is0, so a setting that could not be read never looks like one that is offSECURITY_ITEM_SOURCE: where the value was read from, such as a file path, a registry value or a WMI class
On Linux the reply also carries:
KERNEL_MODULES: each loaded kernel module, as aMODULE_NAMEKERNEL_MODULE_RULES: eachblacklistandinstallrule in the modprobe configuration, withKERNEL_MODULE_RULE_KIND(blacklistorinstall),MODULE_NAME,COMMAND_LINE(the command aninstallrule runs instead of loading the module), andFILE_PATHandLINE_NUMBERlocating the rule
The reply also carries SCHEMA_VERSION, the version of its layout, currently
1, and IS_TRUNCATED, which is 1 when a bound left items, modules or rules
out. When ERROR is present, the snapshot could not be taken and the reply
carries none of these fields.
Sample Event:
{
"event": {
"SECURITY_ITEMS": [
{
"NAME": "linux.sysctl.kernel.yama.ptrace_scope",
"SECURITY_ITEM_STATUS": 0,
"SECURITY_ITEM_VALUE": "1",
"SECURITY_ITEM_SOURCE": "/proc/sys/kernel/yama/ptrace_scope"
},
{
"NAME": "linux.efi.secure_boot",
"SECURITY_ITEM_STATUS": 1,
"SECURITY_ITEM_SOURCE": "/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c"
}
],
"KERNEL_MODULES": [
{ "MODULE_NAME": "ksmbd" }
],
"KERNEL_MODULE_RULES": [
{
"KERNEL_MODULE_RULE_KIND": "install",
"MODULE_NAME": "ksmbd",
"COMMAND_LINE": "/bin/false",
"FILE_PATH": "/etc/modprobe.d/ksmbd.conf",
"LINE_NUMBER": 1
}
],
"SCHEMA_VERSION": 1,
"IS_TRUNCATED": 0
}
}
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"
}
TOASTER_NOTIFY_REP¶
Response event for the toaster_notify
sensor command. Requires sensor version 5.4.0 or later.
Platforms: macOS | Windows
The reply repeats the request's TOAST_PRIORITY (0 information, 1
warning, 2 critical), TOAST_TITLE and TOAST_TEXT, and adds:
| Field | Description |
|---|---|
ERROR |
0 when the notice was accepted. See below. |
TOAST_DELIVERED |
How many users' trays showed the notice at once. 0 is a success too, and the usual answer when no tray was running: the notice is held and shown as each tray starts. |
ERROR_MESSAGE |
Why the notice was refused. Present only when ERROR is not 0. |
ERROR |
Meaning |
|---|---|
0 |
The notice was shown, or held for the trays being started |
50 |
The sensor could not start the notification service |
87 |
Nothing was left to show once the title and text were cleaned, or the priority was invalid |
170 |
Refused by the rate limit: the same notice was shown in the last 30 seconds, or more than 5 notices were shown in the last minute. Also returned when the notification service could not be reached |
Sample Event:
{
"event": {
"TOAST_PRIORITY": 1,
"TOAST_TITLE": "Security notice",
"TOAST_TEXT": "IT Security is investigating this computer.",
"ERROR": 0,
"TOAST_DELIVERED": 1
}
}
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: