Hands-On DARPA TC E3: Entity & Event Statistics

This document provides a deep dive into the entity and event statistics of three key DARPA TC E3 datasets: CADETS (FreeBSD), ClearScope (Android), and THEIA (Linux). The following analysis offers critical insights for feature engineering and APT detection modeling.

1. Headline Numbers & Cross-Dataset Observations

Entity	CADETS	ClearScope	THEIA
Event	41,350,895	143,732,321	106,044,692
Subject	224,629	5,529	279,391
FileObject	2,503,402	233,006	1,062,289
NetFlowObject	155,322	179,702	245,107
MemoryObject	—	—	5,661,799
Principal	63	73	61
UnnamedPipeObject	56,675	586	—
SrcSinkObject	113,350	72,321	—
Host	3	3	4

Three things jump out before any feature engineering:

1. The three datasets are not interchangeable. Each has a different "shape" — different dominant entities, different dominant events, different Subject density. Treating them as one benchmark (as much of the SOTA literature does) is statistically dishonest.
2. MemoryObject only exists in THEIA. Confirmed: CADETS and ClearScope do not instrument memory at the object level.
3. Principal counts are tiny across the board (61–73). A Principal node type would be near-degenerate; this belongs as a Subject attribute, not its own node class.

Cross-Dataset Event Observations

• No single dataset has both strong memory and strong principal signal. THEIA gives memory but not auth; CADETS gives auth but barely any memory. Claims of "complete APT kill-chain coverage" on a single E3 dataset should be read with skepticism.

• Event distribution is wildly skewed in every dataset. The top 1–2 event types account for 50–80% of the volume:

  • CADETS: EVENT_READ (30%) + EVENT_CLOSE (15%)
  • ClearScope: EVENT_READ (82%)
  • THEIA: EVENT_MPROTECT (52%) + EVENT_RECVFROM (13%)

  This means raw event counts in a node's neighborhood are dominated by mundane I/O. Edge-type weighting or rare-event upweighting is essential — a uniformly-trained GNN will mostly learn "what does normal READ traffic look like."

---

2. Per-Dataset Insights & Raw Statistics

2.1 CADETS (FreeBSD)

• Subject density is healthy (224K Subjects / 41M events ≈ 184 events/process). A standard Process–File–NetFlow graph works well here.
• Principal/auth signal is the strongest of the three. 304K EVENT_CHANGE_PRINCIPAL + 10.5K EVENT_LOGIN events. This is the only dataset where privilege-escalation modeling has real signal density.
• Memory-injection signal is weak. Only 11.5K EVENT_MPROTECT events — about 0.03% of events. EVENT_MMAP is plentiful (4.6M) but mostly benign file-backed mappings. CADETS is not the dataset for fileless-malware detection.
• UnnamedPipeObject (56K) is non-trivial but still benign-dominated. FreeBSD shell pipelines and daemon IPC produce most of these. Adding them inflates the graph without proportionate signal.
• SrcSinkObject (113K) is large enough to merit a histogram check. Don't include blindly; pull the subtype distribution first.

View CADETS Raw Statistics

Entities

Entity Type	Count
Event	41,350,895
FileObject	2,503,402
Subject	224,629
NetFlowObject	155,322
SrcSinkObject	113,350
UnnamedPipeObject	56,675
Principal	63
Host	3

Events (Top)

Event Type	Count	% of Events
EVENT_READ	12,628,773	30.54%
EVENT_CLOSE	6,156,317	14.89%
EVENT_MMAP	4,648,096	11.24%
EVENT_FCNTL	4,499,422	10.88%
EVENT_LSEEK	4,016,402	9.71%
EVENT_OPEN	3,843,415	9.29%
EVENT_WRITE	1,694,987	4.10%
EVENT_CHANGE_PRINCIPAL	304,919	0.74%
EVENT_FORK	223,781	0.54%
EVENT_EXECUTE	210,947	0.51%
EVENT_MPROTECT	11,580	0.03%
EVENT_LOGIN	10,562	0.03%

(Note: Table truncated to show significant events for APT modeling)

---

2.2 ClearScope (Android)

• Subject count is pathologically low. 5,529 Subjects against 143M events is ~26K events per process. Android has few, long-running services handling everything. Standard process-centric provenance modeling will not work here — most of the graph collapses onto a handful of mega-nodes.
• EVENT_READ dominance (118M, 82%) signals over-instrumentation. Most reads are framework/library calls inside the JVM/ART runtime. Aggressive event filtering is mandatory.
• Memory signal is essentially absent. 18K EVENT_MMAP, no EVENT_MPROTECT. EVENT_LOADLIBRARY (1.7K) is the closest Android analog and is the only memory-adjacent feature worth using.
• No EVENT_FORK, no EVENT_EXECUTE, no EVENT_LOGIN. Process-creation and authentication semantics are abstracted by the Android framework. Privilege escalation cannot be modeled the way it is on Unix.
• Practical implication: ClearScope likely needs a different graph schema (object-centric, or app-component-centric) rather than the Process–File–NetFlow schema used elsewhere.

View ClearScope Raw Statistics

Entities

Entity Type	Count
Event	143,732,321
FileObject	233,006
NetFlowObject	179,702
SrcSinkObject	72,321
Subject	5,529
UnnamedPipeObject	586
Principal	73
Host	3

Events (Top)

Event Type	Count	% of Events
EVENT_READ	118,737,306	82.61%
EVENT_WRITE	11,422,645	7.95%
EVENT_CLOSE	5,957,623	4.14%
EVENT_DUP	3,295,663	2.29%
EVENT_OPEN	436,091	0.30%
EVENT_MODIFY_PROCESS	363,674	0.25%
EVENT_CONNECT	54,830	0.04%
EVENT_CLONE	20,050	0.01%
EVENT_MMAP	18,716	0.01%
EVENT_LOADLIBRARY	1,752	0.00%

---

2.3 THEIA (Linux)

• MemoryObject is fully populated (5.66M nodes). This is the right dataset for fileless-malware / injection detection.
• EVENT_MPROTECT dominates the event stream (55.4M, 52% of all events). This is not all attack signal — Linux glibc loading, JIT compilers, and runtime linkers generate massive volumes of legitimate mprotect calls.
  • Filter aggressively: Keep only mprotects that result in W+X (writable+executable) regions, or transitions from non-exec to exec. The other 95%+ are benign and should be dropped.
• No EVENT_CHANGE_PRINCIPAL, no EVENT_LOGIN. Privilege-escalation modeling has to rely on UID changes inferred from process state. THEIA is not the dataset for credential/privilege-focused detection.
• No SrcSink, no UnnamedPipe. Cleaner graph schema, fewer modeling choices to make.
• Healthy Subject density (279K). Standard process-centric provenance works.

View THEIA Raw Statistics

Entities

Entity Type	Count
Event	106,044,692
MemoryObject	5,661,799
FileObject	1,062,289
Subject	279,391
NetFlowObject	245,107
Principal	61
Host	4

Events (Top)

Event Type	Count	% of Events
EVENT_MPROTECT	55,432,813	52.27%
EVENT_RECVFROM	14,219,453	13.41%
EVENT_READ	8,369,451	7.89%
EVENT_OPEN	6,613,272	6.24%
EVENT_MMAP	5,970,986	5.63%
EVENT_WRITE	3,679,281	3.47%
EVENT_CONNECT	592,840	0.56%
EVENT_CLONE	239,820	0.23%
EVENT_EXECUTE	116,887	0.11%

---

3. Recommended Entity Set Per Dataset

CADETS

• Nodes: Subject, FileObject, NetFlowObject
• Subject Attributes: Current UID/EUID, principal-change count
• Special Edge Types: EVENT_CHANGE_PRINCIPAL (with before/after UID as edge features), EVENT_LOGIN, EVENT_EXECUTE
• Skip: UnnamedPipeObject, SrcSinkObject (revisit only after subtype histogram), MemoryObject (doesn't exist)

THEIA

• Nodes: Subject, FileObject, NetFlowObject, MemoryObject (filtered)
• MemoryObject Filter: Retain only objects involved in suspicious mprotect transitions (→ W+X, or anonymous + exec). Dropping the bulk of legitimate JIT/loader noise is non-negotiable; otherwise the 5.66M nodes will swamp the rest of the graph.
• Special Edge Types: Filtered EVENT_MPROTECT, EVENT_MMAP with anonymous+exec flags, EVENT_EXECUTE, EVENT_CLONE
• Skip: Principal modeling (no CHANGE_PRINCIPAL events to learn from)

ClearScope

• Nodes: Subject, FileObject, NetFlowObject (Subjects are mega-nodes)
• Mandatory Preprocessing: Filter EVENT_READ aggressively (most are runtime-internal). Without this, 82% of edges are framework noise.
• Special Edges: EVENT_LOADLIBRARY (best available memory-injection proxy)
• Skip: UnnamedPipeObject (586 instances), SrcSinkObject, anything principal-related
• Honest Assessment: ClearScope may not benefit from a generic provenance pipeline at all. Consider whether including it as a third dataset is helping your evaluation or just inflating the table.

---

4. Pitfalls Flagged by the Statistics

Methodological Gaps

Reporting strong THEIA numbers without disclosing your mprotect filtering policy is the kind of methodological gap reproducibility studies flag. Document the filter explicitly.

• The "MPROTECT trap" in THEIA: Generating high accuracy numbers on THEIA without filtering the 55M EVENT_MPROTECT edges often indicates the model is just memorizing benign JIT behaviors rather than learning attack patterns.
• The "Subject collapse" in ClearScope: Any node-level metric (FPR per node, attack node recall) is misleading on ClearScope because the node count is artificially small. Edge-level or event-window metrics are more honest here.
• Cross-dataset uniformity claims: If your pipeline applies identical hyperparameters and identical entity schemas to all three datasets, you are leaving signal on the table on at least two of them. Per-dataset configuration is the technically correct choice, even though it makes academic papers harder to write.

---

5. Bottom Line

1. Use CADETS for principal/privilege-escalation modeling.
2. Use THEIA for memory-injection modeling (with aggressive mprotect filtering).
3. Treat ClearScope as a separate problem that may need its own schema.

Encode Principal as an attribute, not a standalone node type. Filter the dominant event types before graph construction in every dataset, but especially in THEIA (EVENT_MPROTECT) and ClearScope (EVENT_READ).