Ingext
Incident Investigation
The AI-assist escalated a CRITICAL SentinelOne detection on old_msedge.exe, citing an unmitigated ransomware threat and flagging the asset-profile snapshot as inconsistent. Four grounds were tested against the raw SentinelOne threat record, the live endpoint, and the agent's 30-day history. All four survive: the file is unsigned and novel to the tenant, the detection is a real-time behavioral one (not a stale scan), the live endpoint confirms the host is still infected, and zero containment actions have been taken.
Confirmed malicious — an unsigned executable masquerading under the Microsoft Edge updater's own temp path deleted a shadow copy and was flagged Ransomware at malicious confidence by a dynamic behavioral engine, and remains unmitigated on a currently-connected, infected endpoint. Isolate the host and open incident response now; this is not closed by this review.
| Subject | OPS-LAPTOP-07 (asset; last user Sam Rivera) |
| Tenant | Acme Corp |
| Window | 2026-09-23 → 2026-10-23 |
| Incident time | 2026-10-23 06:54:13Z (detected); 06:54:29Z (confidence raised to malicious) |
| Peak riskScore | 9600 (7200 from the EDR rule, 1200 from Ingext_SentinelOne_NewActiveThreat) |
| AI-assist verdict | ESCALATE_TO_TIER_TWO, actionable=true |
| Rules | SentinelOne:EDR_old_msedge.exe_-_Shadow_Copy_Deletion_detected, Ingext_SentinelOne_NewActiveThreat |
Quoted from the AI-Assistant comment on the ticket (report.activity_summary, report.recommendation, summary, keyQuestions).
Confirmed from the raw SentinelOneThreat record (lake_search, managed-SentinelOne): mitigationStatus: not_mitigated, the per-action mitigationStatus[] array is empty (no kill, no quarantine attempted at all), detectionEngines: ["DBT - Executables"] and detectionType: dynamic (a real-time behavioral verdict, not a static-hash hit), initiatedBy: agent_policy (on-execution). fileVerificationType: NotSigned, isValidCertificate: false, publisherName: "" — the file sits in the genuine Edge updater's temp path (Program Files (x86)\Microsoft\Edge\Temp\3120_1188240511\old_msedge.exe) but carries no Microsoft signature, i.e. it is masquerading as an Edge-update artifact rather than being one.
Confirmed as stale, not as evidence of safety. investigate_sentinelone_alert's live endpoint record and the raw SentinelOneThreat document (both read ~1 minute after detection) show agentIsActive: true, agentInfected: true, activeThreats: 1, externalIp: 198.51.100.140 — matching the activity's own recorded IP — and lastActiveDate: 2026-10-23T06:55:16Z. The sentinelOneAgent resource-table snapshot the ticket's profile step read (isActive: false, activeThreats: 0, externalIp: 198.51.100.141, lastActiveDate: 2026-10-22T16:37Z) is a cached inventory copy lagging the live record by hours, matching this account's known inventory-lag gap (previously confirmed on HR-LAPTOP-02, 2026-10-07).
198.51.100.140 is this agent's own ordinary external (NAT/ISP) IP, not a connection destination — the same address was logged as this host's externalIp on its earlier, benign test.virus.text ticket on 2026-10-06. This account has no FortiGate/firewall table populated for this host (NetworkFortigateTraffic/NetworkFortigateEvent exist on the account but a WindowsAudit lookup for this hostname returned 0 rows in a ±24h window — a WORKGROUP laptop, not domain-joined, so the usual domain-controller-fed audit source has no visibility here); outbound-connection validation for this host is a gap, not a negative.
Zero. A 30-day lake_search on the exact SHA1 and, separately, on the exact threat name old_msedge.exe (excluding this ticket) returned no other hits on the tenant — the hash and filename are novel. The rule itself has fired on 0 other entities in the last 7 days, and the broader Ingext_SentinelOne_NewActiveThreat rule (any new SentinelOne threat, any host) also returned only this one entity in the same window — confirming the search mechanism returns real matches (it is not a broken filter) and that no other host on the tenant had any SentinelOne threat activity in that period either.
The behavior summary buckets this to 06:54:00–06:55:00Z; the raw SentinelOne threat and activity records carry the real times below.
| Time (UTC) | Actor | Event |
|---|---|---|
| 2026-10-23 06:54:13.780Z | explorer.exe (user Sam Rivera) | old_msedge.exe launched with --profile-directory="Profile 6"; SentinelOne identifies the threat (identifiedAt) |
| 2026-10-23 06:54:29.359–393Z | SentinelOne Behavioral AI (DBT - Executables) | Threat confidence set to malicious, classification Ransomware; indicator "Deletes shadow copy" recorded; mitigationStatus: not_mitigated |
| 2026-10-23 06:54:40.000Z | Ingext | Ingext_SentinelOne_NewActiveThreat fires: "New active threat identified on OPS-LAPTOP-07." |
| 2026-10-23 06:55:16.245Z | SentinelOne agent (live check) | Endpoint still connected: agentIsActive=true, agentInfected=true, activeThreats=1 — no kill, no quarantine recorded since detection |
| 2026-10-23 06:55:44.710Z | Ingext | incidentDetectionTime — ticket raised, AI-Assistant posts ESCALATE_TO_TIER_TWO |
Step 2 census, within Acme Corp only, last 7 days.
0 other entities on the exact rule; 1 entity tenant-wide on the broader new-threat rule (this same ticket), which is the control proving the search can return a positive.
| Rule | Other entities (7d) | Highest scorer |
|---|---|---|
| SentinelOne:EDR_old_msedge.exe_-_Shadow_Copy_Deletion_detected | 0 | — |
| Ingext_SentinelOne_NewActiveThreat (control, any host) | 0 (1 total, this ticket) | ops-laptop-07, 1200 |
Each negative below was run against a control proving the query finds these operations elsewhere on the tenant — a zero from a broken query looks identical to a real one.
test.virus.text) within seconds, and the user himself (Sam Rivera, a management console user) marked it a false positive. The agent's full 30-day activity facet for this agent shows exactly one 2001 (killed) and one 2004 (quarantined) event in that period, and both date to the 2026-10-06 ticket, not to old_msedge.exe — zero containment actions exist for this threat.initiatedBy: agent_policy (on-execution/real-time), not full_disk_scan; originatorProcess: explorer.exe with processUser: OPS-LAPTOP-07\Sam Rivera matching the endpoint's lastLoggedInUserName — the logged-in user launched it directly. Control: agentRegisteredAt is 2026-07-09, three and a half months before detection, ruling out a first-full-disk-scan artifact.publisherName and certificateId are both empty and fileVerificationType: NotSigned / isValidCertificate: false — this is not Microsoft's own Edge update binary (which would be Microsoft-signed). No application census was run because there is no named vendor or publisher to check it against.indicators[] (70 entries: Chromium/KeePass/password-manager memory access, Azure AD PRT theft, keylogger installation, DLL injection/hollowing, Kerberoasting pattern, SAM queries, ETW/event-log tampering, multiple persistence mechanisms) are collected across the whole storyline (7D2A41F09C3B6E58), rooted at explorer.exe — the data available here cannot say which process raised each one. Only "Deletes shadow copy" is the alert's own namesake finding and is directly tied to this detection. The rest are an open forensic question for IR, not something this review can rule in or out from the SentinelOne index alone.The external IP is a red herring, not an indicator. 198.51.100.140 is this laptop's ordinary internet-facing address — it also appears on the same host's benign ticket from 2026-10-06. It is not evidence of a C2 destination.
Asset-profile snapshots on this account lag the live SentinelOne record. This is the second time this gap has been measured on Acme Corp (previously on HR-LAPTOP-02, 2026-10-07): the AI-assist's getSentinelOneAssetProfile step returned a clean, hours-stale snapshot while the live endpoint and the raw threat record both showed an active infection within a minute of detection. Treat sentinelOneAgent/profile output as a lower bound on risk, never as clearance, for anything inside the last day.
Confirmed malicious and still live — isolate OPS-LAPTOP-07 from the network now, kill and quarantine old_msedge.exe (SHA1 d41f7e09a2c35b86e1f04c7a9b2d6e381f5a0c24 / SHA256 3c9b07a4e1f25d68b0a4c71e9f23d5b8a6e04f17c2d9b3a85e1f60c4d7b29a03) in the SentinelOne console, and open a full IR workflow: acquire memory/$MFT/prefetch/SRUM, and reset Sam Rivera's credentials and any browser or password-manager secrets the storyline's credential-access indicators may have exposed.
Hunt tenant-wide for the same SHA1/SHA256 before treating the scope as one host — the hash and filename are novel to Acme Corp as of this review, so a clean 30-day census today does not rule out a second host detonating it tomorrow.
Settle the open attribution question in the SentinelOne console's storyline view (7D2A41F09C3B6E58) — which process raised the credential-access, injection and persistence indicators — before scoping containment down to this one file, and request firewall/proxy visibility for this host if the customer has it outside this platform.
No rule tuning proposed: the EDR rule has never fired on another entity in 7 days and the hash/filename are new to the tenant. This is a first occurrence, not a noisy rule.
Evidence: behavior (1 summary, 2 behaviorRule hits, riskScore 9600), SentinelOne (investigate_sentinelone_alert: 1 alert + 1 threat + 1 activity + live endpoint; lake_search managed-SentinelOne: 2 SentinelOneThreat / 2 SentinelOneAlert / 34 SentinelOneActivity records for this agent over 30 days; 0 other-tenant hits for this SHA1 or threat name in 30 days), WindowsAudit (0 rows for this host, ±24h — gap), behavior_summary_search base-rate census (0 other entities on the exact rule, 1 entity tenant-wide on the broader new-threat rule, 7 days). All findings: Acme Corp only.