Research concept · sample output format

Illustrative investigation brief

Illustrative format—not an actual investigation or validated detection. All events, hosts, and addresses below are synthetic. Addresses use RFC 5737 documentation ranges and example.org. No real customer, person, credential, or production log is represented.

Synthetic only
Editorial demonstration
Not AI inference output
Not human-reviewed on real data

Back to concept page

Brief metadata (synthetic)

Case label: SYN-DEMO-2026-001 (fictional)
Subject: Synthetic tenant “example-msp-lab” on example.org
Sources provided (fictional package): Invented normalized identity extract; invented normalized endpoint activity extract combining process-launch and network-destination fields. Not a native Microsoft, EDR, or other vendor export schema—fields were authored for this page only.
Time window (UTC): 2026-11-05 14:00:00Z – 2026-11-05 16:00:00Z
Reviewer: None — this page was authored as static documentation, not as a reviewed engagement deliverable

Synthetic source events

Reserved documentation addresses used consistently: 192.0.2.10 = first client; 203.0.113.50 = alternate client; 198.51.100.20 = shared illustrative service edge for login.example.org and tickets.example.org. Hostnames under example.org only.

Synthetic identity events
Event ID	UTC timestamp	Observed record (synthetic)
EVT-IDP-1001	2026-11-05 14:12:03Z	User `alex.operator@example.org` password sign-in success from 192.0.2.10 to IdP host `login.example.org` (edge 198.51.100.20). MFA method: app push — result success.
EVT-IDP-1002	2026-11-05 14:12:41Z	Same user issued OAuth token for app `tickets.example.org` (service edge 198.51.100.20). Client 192.0.2.10. Result success.
EVT-IDP-1003	2026-11-05 14:18:09Z	Same user password sign-in failure from 203.0.113.50 to `login.example.org`. Reason code (synthetic): bad_password. No MFA prompt recorded.
EVT-IDP-1004	2026-11-05 14:19:02Z	Password sign-in success for `alex.operator@example.org` from 203.0.113.50 after MFA app push success.
EVT-EP-2201	2026-11-05 14:21:17Z	Host `ws-lab-07.example.org` — invented normalized endpoint activity record with two distinct fields: process launched = `browser.exe`; network-destination signal = TCP connection to 198.51.100.20 (`tickets.example.org` service edge), destination port 443 (synthetic). Optional correlation field maps session to alex.operator. This is not a claim that a process-start event alone proved a page navigation, and it is not a vendor EDR/Microsoft native schema.

Observed facts

Statements limited to what the synthetic events literally show.

EVT-IDP-1001 and EVT-IDP-1002 show a successful MFA’d sign-in and app token issuance from 192.0.2.10 for alex.operator@example.org.
EVT-IDP-1003 shows a failed password attempt for the same user from 203.0.113.50 about six minutes later.
EVT-IDP-1004 shows a subsequent successful MFA’d sign-in from 203.0.113.50.
EVT-EP-2201’s synthetic normalized endpoint record includes a browser process launch and a network connection to tickets.example.org (198.51.100.20:443) shortly after EVT-IDP-1004. It does not, by itself, prove which URL path was loaded in the browser UI.
No synthetic event in this package records malware alerts, privilege elevation, or data-export actions.

Uncertain hypotheses

Not established by the synthetic evidence. Listed only to show how a brief might separate speculation.

H1 (unconfirmed): The 203.0.113.50 success might be the same operator on a second network path—or a different person with the password. Events alone do not decide.
H2 (unconfirmed): The failed attempt (EVT-IDP-1003) might be a typo by the legitimate user before succeeding from the same address.
H3 (unconfirmed): Device ws-lab-07.example.org might be the operator’s usual lab workstation; no asset inventory was included in the synthetic package.

Plausible benign explanation

A routine operator could sign in from an office-like documentation address (192.0.2.10), then later sign in from a lab or remote documentation address (203.0.113.50) after one mistyped password, and open the ticketing app. That story is consistent with the synthetic events but is not proven without additional context (device ownership, expected travel/VPN patterns, user interview).

Missing evidence

No VPN or Wi-Fi association logs tying 192.0.2.10 or 203.0.113.50 to a physical site.
No prior baseline of usual sign-in addresses for alex.operator@example.org.
No ticket or change-record confirming planned remote work.
No full MFA challenge detail beyond success/failure flags in the invented normalized identity extract.

Analyst next checks (illustrative)

Confirm whether 203.0.113.50 is an expected lab/VPN egress for this user (asset or network owners)—reference EVT-IDP-1003 / EVT-IDP-1004.
Ask the account owner whether they signed in around 14:12Z and 14:19Z UTC on 2026-11-05.
If available in a real case: pull device inventory for ws-lab-07.example.org and compare to fields analogous to EVT-EP-2201.
Do not treat this sample as authorization to contact real users or pull production logs.

Limits of this sample

No accuracy rate, time-saved claim, or detection-performance statistic is stated or implied.
No threat-intelligence assertion (no APT name, no malware family, no “confirmed compromise”).
No offensive technique instructions and no real credentials.
This is not a product deliverable and not proof of operational capability.

Concept overview Email interest (nonsensitive)

Do not send logs, credentials, personal data, CUI, or classified information.