A confidence the scenario's author stated when writing it — not a measured rate. Nothing here has yet been scored against a human's later verdict; calibration arrives when outcomes exist (R96), and until then no figure is invented for it.
This is a simulation
nothing here was observed
Written as a simulation of the June 2017 NotPetya outbreak, from the published record. None of the telemetry below was observed — not on this estate and not on anyone else’s; it is what that shape of attack would look like in these records. The sources are named so the shape can be checked against them.
A destructive wiper arrived inside a trojanised vendor update, took svc-deploy's credentials out of memory, spread to fs-04 and dc-01 both with those credentials and by exploiting an unpatched SMB service, and overwrote boot records behind a ransom note that cannot be paid. (confidence 0.94)hypothesis-0, SEC-0005-a, SEC-0005-b, SEC-0005-c, SEC-0005-d, SEC-0005-e, SEC-0005-g, SEC-0005-i
A destructive wiper arrived inside a trojanised vendor update, took svc-deploy's credentials out of memory, spread to fs-04 and dc-01 both with those credentials and by exploiting an unpatched SMB service, and overwrote boot records behind a ransom note that cannot be paid. (confidence 0.94)hypothesis-0, SEC-0005-a, SEC-0005-b, SEC-0005-c, SEC-0005-d, SEC-0005-e, SEC-0005-g, SEC-0005-i
How it unfolded
If we had acted sooner
○estimate
Acting on host:fin-034 at 23:49Z — the first moment the records would have justified it — would have pre-empted 4 recorded steps over the following 20 minutes.
What would not have happened
23:54Zaccount:svc-deploydeployment credentials read out of process memorySEC-0005-c
23:59Zhost:fs-04written to over ADMIN$ with the stolen credentialsSEC-0005-d
00:02Zhost:fs-04malformed SMBv1 transaction against the unpatched serviceSEC-0005-e
00:09Zhost:fs-04boot record overwritten with no copy kept, and a reboot scheduledSEC-0005-f
Draft: Compromise Software Supply Chain observed in INC-2026-0905
○parses as sigma◆indicator match
Drafted for T1195.002 Compromise Software Supply Chain (Initial Access), from the events this incident’s causal step cites.
EventIDno stored event for this step carries EventID; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
ShareNameno stored event for this step carries ShareName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
Draft: Exploitation of Remote Services observed in INC-2026-0905
○parses as sigma◆indicator match
Drafted for T1210 Exploitation of Remote Services (Lateral Movement), from the events this incident’s causal step cites.
SubjectUserNamepayload.principal on SEC-0005-e is 'fs-04', which is a host and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
(none)payload.detection_type on SEC-0005-e is 'smb_remote_code_execution', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
Draft: Disk Structure Wipe observed in INC-2026-0905
○parses as sigma◆indicator match
Drafted for T1561.002 Disk Structure Wipe (Impact), from the events this incident’s causal step cites.
SubjectUserNamepayload.principal on SEC-0005-f is 'fs-04', which is a host and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
A destructive wiper arrived inside a trojanised vendor update, took svc-deploy's credentials out of memory, spread to fs-04 and dc-01 both with those credentials and by exploiting an unpatched SMB service, and overwrote boot records behind a ransom note that cannot be paid.
04notify_analyst●risk 0expects no state changerollback: none
Risk shown is the action’s base score. Effective risk rises with blast radius, production environment, and low confidence — it never falls, and the dashboard never computes it here.
Timeline
agent:sentinelcorrelatedupdate fetch, unlisted binary, credential read and admin-share writes to two hosts inside eleven minutes
agent:analystdiagnosedthe ransom note is contradicted by the installation ID and by the overwritten boot record — this destroys rather than encrypts
dharmaescalatedisolate_host scores 67 → senior tier, and the plan touches a domain controller
A destructive wiper arrived inside a trojanised vendor update, took svc-deploy's credentials out of memory, spread to fs-04 and dc-01 both with those credentials and by exploiting an unpatched SMB service, and overwrote boot records behind a ransom note that cannot be paid.94% stated
No record of this stage. The loop reached escalated without it.
Execution
▲never ran
The only path to a write
No record of this stage. The loop reached escalated without it.
Verification
▲never ran
Observed state against expected state
No record of this stage. The loop reached escalated without it.
Effective risk
▲64
high · base 55
Blast radius
3
~0 users
Rollback
rejoin_network
tested and available
Why the risk rose
base risk of isolate_host55
blast radius: 3 entities+9
effective risk64
Adjustments only ever raise risk. An action cannot argue its way into a lower tier.
What success will look like
networkisolated
edrreachable
Declared before execution. Verification compares observed state to this, and a check with no observation counts as a failure — “don’t know” is never recorded as success.
requires: senior_operatorverdict expires — a stale approval cannot be replayed against changed state
host:fin-034 — a binary outside the vendor manifest, through the signed update channel
account:svc-deploy — deployment credentials read out of process memorychain-1, SEC-0005-c
host:fs-04 — written to over ADMIN$ with the stolen credentialschain-2, SEC-0005-d
host:fs-04 — malformed SMBv1 transaction against the unpatched servicechain-3, SEC-0005-e
host:fs-04 — boot record overwritten with no copy kept, and a reboot scheduledchain-4, SEC-0005-f, SEC-0005-g
What was ruled out
Ruled out: Ransomware. The data is encrypted and recoverable — pay the demand or wait for a key.hypothesis-1, SEC-0005-i, SEC-0005-g
What was done
Nothing was executed. The plan was drawn up and did not run.INC-2026-0905
What was verified
No verification is recorded, so nothing here says the incident was resolved rather than merely closed.INC-2026-0905
Adopting this is adopt_report — scored 44, approval required by operator.
Nothing here has been adopted. This document is assembled from the incident each time it is asked for, so it cannot go stale against the incident it describes — and it cannot be saved into something that stops saying draft.
host:fin-034 — a binary outside the vendor manifest, through the signed update channelchain-0, SEC-0005-a, SEC-0005-b
account:svc-deploy — deployment credentials read out of process memorychain-1, SEC-0005-c
host:fs-04 — written to over ADMIN$ with the stolen credentialschain-2, SEC-0005-d
host:fs-04 — malformed SMBv1 transaction against the unpatched servicechain-3, SEC-0005-e
host:fs-04 — boot record overwritten with no copy kept, and a reboot scheduledchain-4, SEC-0005-f, SEC-0005-g
What to do
1. isolate_host — rollback: rejoin_network; authorisation: not scored for this incident yetplan-1
2. revoke_session — rollback: reissue_session; authorisation: not scored for this incident yetplan-2
3. block_ip — rollback: unblock_ip; authorisation: not scored for this incident yetplan-3
4. notify_analyst — rollback: none declared; authorisation: not scored for this incident yetplan-4
traffic_from_ip should read denied after step 3plan-3
Adopting this is adopt_playbook — scored 44, approval required by operator.
Nothing here has been adopted. This document is assembled from the incident each time it is asked for, so it cannot go stale against the incident it describes — and it cannot be saved into something that stops saying draft.
Timed from 7 stored event(s); each step is dated to the earliest record that established it.
Downstream reach of host:fin-034 taken from 3 stored access edge target(s), each citing its own evidence. A later step not among them is reported as unavoidable rather than counted.
Assumes the action would have been immediate and complete. Nothing stored measures how long it takes to apply or whether it fully works.
Assumes the attacker would not have taken another route. The records describe what happened once; they cannot say what would have been tried next, and a determined intruder blocked at one path is not a stopped one.
Derived from this incident’s stored timeline and the access edges between its entities, both of which cite their own evidence. It is an estimate, not a measurement: nothing recorded here says what the intruder would have done next.
SubjectUserNamepayload.principal on SEC-0005-a is '192.0.2.30->fin-034:443', which is a network_flow and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
(none)payload.detection_type on SEC-0005-a is 'software_update_fetched', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-a names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
SubjectUserNamepayload.principal on SEC-0005-b is 'fin-034', which is a host and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
(none)payload.detection_type on SEC-0005-b is 'binary_outside_vendor_manifest', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-b names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
The rule
# DRAFT - assembled from one incident's stored telemetry. Not deployed,
# not validated against a live log pipeline, and not adopted.
# Incident: INC-2026-0905
# Technique: T1195.002 Compromise Software Supply Chain (Initial Access)
#
# Every field below was read from a stored event:
# DestinationPort <- entity_ref.id (matches this incident only); SEC-0005-a
# DestinationHostname <- entity_ref.id (matches this incident only); SEC-0005-a
# SourceIp <- entity_ref.id (matches this incident only); SEC-0005-a
# Computer <- entity_ref.id (matches this incident only); SEC-0005-b
#
# WARNING: every field is an instance value. This matches this incident and not the technique.
title: 'Draft: Compromise Software Supply Chain observed in INC-2026-0905'
id: 68dd7552-ded9-57bf-bc48-51d4465cd80c
status: experimental
description: 'Drafted from INC-2026-0905, which recorded: a binary outside the vendor manifest, through
the signed update channel. Fields below were read from SEC-0005-a, SEC-0005-b.'
references:
- INC-2026-0905
- SEC-0005-a
- SEC-0005-b
author: Sati (drafted from one incident; not validated against live telemetry)
date: 2026/10/18
tags:
- attack.initial_access
- attack.t1195.002
logsource:
category: security
product: pashupatastra
service: demo
detection:
selection:
DestinationPort: 443
DestinationHostname: fin-034
SourceIp: 192.0.2.30
Computer: fin-034
condition: selection
falsepositives:
- Every field is specific to INC-2026-0905 (DestinationPort=443, DestinationHostname=fin-034, SourceIp=192.0.2.30,
Computer=fin-034). This will match unrelated activity on the same entities and nothing elsewhere.
level: high
x-provenance:
DestinationPort:
source_field: entity_ref.id
observed_in:
- SEC-0005-a
generalises: false
DestinationHostname:
source_field: entity_ref.id
observed_in:
- SEC-0005-a
generalises: false
SourceIp:
source_field: entity_ref.id
observed_in:
- SEC-0005-a
generalises: false
Computer:
source_field: entity_ref.id
observed_in:
- SEC-0005-b
generalises: false
x-not-mapped:
SubjectUserName: 'payload.principal on SEC-0005-b is ''fin-034'', which is a host and not an account.
Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored
value, and match nothing'
(none): payload.detection_type on SEC-0005-b is 'binary_outside_vendor_manifest', which is this platform's
own detector label rather than a field of the source log. Sigma matches what the log recorded, not
what we concluded from it, so there is no field for this and inventing one would encode our verdict
as somebody else's observation
(prose): labels.summary on SEC-0005-b names the detail a stronger rule would key on, in prose written
for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is
the guessing this module refuses everywhere else
x-warning: Every field in this rule is an instance value from this incident. It would have matched this
occurrence and will not match another; it is an indicator match, not a behavioural detection.
Drafted from stored telemetry, never deployed and never adopted. Every field above was read from an event this incident cites; nothing was written from what a model knows about Sigma. Every rule the console holds, drafted and written →
(none)payload.detection_type on SEC-0005-c is 'credential_dump', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-c names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
The rule
# DRAFT - assembled from one incident's stored telemetry. Not deployed,
# not validated against a live log pipeline, and not adopted.
# Incident: INC-2026-0905
# Technique: T1003 OS Credential Dumping (Credential Access)
#
# Every field below was read from a stored event:
# TargetUserName <- entity_ref.id (matches this incident only); SEC-0005-c
# SubjectUserName <- payload.principal (matches this incident only); SEC-0005-c
#
# WARNING: every field is an instance value. This matches this incident and not the technique.
title: 'Draft: OS Credential Dumping observed in INC-2026-0905'
id: 0dc83fea-a4ac-53be-9d88-f3bf6ebd413e
status: experimental
description: 'Drafted from INC-2026-0905, which recorded: deployment credentials read out of process memory.
Fields below were read from SEC-0005-c.'
references:
- INC-2026-0905
- SEC-0005-c
author: Sati (drafted from one incident; not validated against live telemetry)
date: 2026/10/18
tags:
- attack.credential_access
- attack.t1003
logsource:
category: security
product: pashupatastra
service: demo
detection:
selection:
TargetUserName: svc-deploy
SubjectUserName: svc-deploy
condition: selection
falsepositives:
- Every field is specific to INC-2026-0905 (TargetUserName=svc-deploy, SubjectUserName=svc-deploy). This
will match unrelated activity on the same entities and nothing elsewhere.
level: high
x-provenance:
TargetUserName:
source_field: entity_ref.id
observed_in:
- SEC-0005-c
generalises: false
SubjectUserName:
source_field: payload.principal
observed_in:
- SEC-0005-c
generalises: false
x-not-mapped:
(none): payload.detection_type on SEC-0005-c is 'credential_dump', which is this platform's own detector
label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded
from it, so there is no field for this and inventing one would encode our verdict as somebody else's
observation
(prose): labels.summary on SEC-0005-c names the detail a stronger rule would key on, in prose written
for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is
the guessing this module refuses everywhere else
x-warning: Every field in this rule is an instance value from this incident. It would have matched this
occurrence and will not match another; it is an indicator match, not a behavioural detection.
Drafted from stored telemetry, never deployed and never adopted. Every field above was read from an event this incident cites; nothing was written from what a model knows about Sigma. Every rule the console holds, drafted and written →
RelativeTargetNameno stored event for this step carries RelativeTargetName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
SubjectUserNameno stored event for this step carries SubjectUserName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
IpAddressno stored event for this step carries IpAddress; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
Held, and deliberately not mapped
SubjectUserNamepayload.principal on SEC-0005-d is 'fin-034', which is a host and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
(none)payload.detection_type on SEC-0005-d is 'smb_admin_share_write', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-d names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
The rule
# DRAFT - assembled from one incident's stored telemetry. Not deployed,
# not validated against a live log pipeline, and not adopted.
# Incident: INC-2026-0905
# Technique: T1021.002 SMB/Windows Admin Shares (Lateral Movement)
#
# Every field below was read from a stored event:
# Computer <- entity_ref.id (matches this incident only); SEC-0005-d
#
# This telemetry could not supply, and a reviewer should add:
# EventID - no stored event for this step carries EventID; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
# ShareName - no stored event for this step carries ShareName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
# RelativeTargetName - no stored event for this step carries RelativeTargetName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
# SubjectUserName - no stored event for this step carries SubjectUserName; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
# IpAddress - no stored event for this step carries IpAddress; the normalized event model (events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
#
# WARNING: every field is an instance value. This matches this incident and not the technique.
title: 'Draft: SMB/Windows Admin Shares observed in INC-2026-0905'
id: 16c6a14c-7bbf-5567-ae4c-6dc11cc4073e
status: experimental
description: 'Drafted from INC-2026-0905, which recorded: written to over ADMIN$ with the stolen credentials.
Fields below were read from SEC-0005-d. Some fields this technique usually keys on are absent - see
x-gaps.'
references:
- INC-2026-0905
- SEC-0005-d
author: Sati (drafted from one incident; not validated against live telemetry)
date: 2026/10/18
tags:
- attack.lateral_movement
- attack.t1021.002
logsource:
category: security
product: pashupatastra
service: demo
detection:
selection:
Computer: fin-034
condition: selection
falsepositives:
- Every field is specific to INC-2026-0905 (Computer=fin-034). This will match unrelated activity on the
same entities and nothing elsewhere.
- The selection tests a single field (Computer), so anything carrying that value matches regardless of
behaviour.
level: high
x-provenance:
Computer:
source_field: entity_ref.id
observed_in:
- SEC-0005-d
generalises: false
x-gaps:
EventID: no stored event for this step carries EventID; the normalized event model (events.py) has no
field it maps from, so a rule for T1021.002 keying on it would be inventing the value
ShareName: no stored event for this step carries ShareName; the normalized event model (events.py) has
no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
RelativeTargetName: no stored event for this step carries RelativeTargetName; the normalized event model
(events.py) has no field it maps from, so a rule for T1021.002 keying on it would be inventing the
value
SubjectUserName: no stored event for this step carries SubjectUserName; the normalized event model (events.py)
has no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
IpAddress: no stored event for this step carries IpAddress; the normalized event model (events.py) has
no field it maps from, so a rule for T1021.002 keying on it would be inventing the value
x-not-mapped:
SubjectUserName: 'payload.principal on SEC-0005-d is ''fin-034'', which is a host and not an account.
Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored
value, and match nothing'
(none): payload.detection_type on SEC-0005-d is 'smb_admin_share_write', which is this platform's own
detector label rather than a field of the source log. Sigma matches what the log recorded, not what
we concluded from it, so there is no field for this and inventing one would encode our verdict as
somebody else's observation
(prose): labels.summary on SEC-0005-d names the detail a stronger rule would key on, in prose written
for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is
the guessing this module refuses everywhere else
x-warning: Every field in this rule is an instance value from this incident. It would have matched this
occurrence and will not match another; it is an indicator match, not a behavioural detection.
Drafted from stored telemetry, never deployed and never adopted. Every field above was read from an event this incident cites; nothing was written from what a model knows about Sigma. Every rule the console holds, drafted and written →
(prose)labels.summary on SEC-0005-e names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
The rule
# DRAFT - assembled from one incident's stored telemetry. Not deployed,
# not validated against a live log pipeline, and not adopted.
# Incident: INC-2026-0905
# Technique: T1210 Exploitation of Remote Services (Lateral Movement)
#
# Every field below was read from a stored event:
# Computer <- entity_ref.id (matches this incident only); SEC-0005-e
#
# WARNING: every field is an instance value. This matches this incident and not the technique.
title: 'Draft: Exploitation of Remote Services observed in INC-2026-0905'
id: bd51730b-50a3-544d-a914-4cca77636a29
status: experimental
description: 'Drafted from INC-2026-0905, which recorded: malformed SMBv1 transaction against the unpatched
service. Fields below were read from SEC-0005-e.'
references:
- INC-2026-0905
- SEC-0005-e
author: Sati (drafted from one incident; not validated against live telemetry)
date: 2026/10/18
tags:
- attack.lateral_movement
- attack.t1210
logsource:
category: security
product: pashupatastra
service: demo
detection:
selection:
Computer: fs-04
condition: selection
falsepositives:
- Every field is specific to INC-2026-0905 (Computer=fs-04). This will match unrelated activity on the
same entities and nothing elsewhere.
- The selection tests a single field (Computer), so anything carrying that value matches regardless of
behaviour.
level: high
x-provenance:
Computer:
source_field: entity_ref.id
observed_in:
- SEC-0005-e
generalises: false
x-not-mapped:
SubjectUserName: 'payload.principal on SEC-0005-e is ''fs-04'', which is a host and not an account.
Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored
value, and match nothing'
(none): payload.detection_type on SEC-0005-e is 'smb_remote_code_execution', which is this platform's
own detector label rather than a field of the source log. Sigma matches what the log recorded, not
what we concluded from it, so there is no field for this and inventing one would encode our verdict
as somebody else's observation
(prose): labels.summary on SEC-0005-e names the detail a stronger rule would key on, in prose written
for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is
the guessing this module refuses everywhere else
x-warning: Every field in this rule is an instance value from this incident. It would have matched this
occurrence and will not match another; it is an indicator match, not a behavioural detection.
Drafted from stored telemetry, never deployed and never adopted. Every field above was read from an event this incident cites; nothing was written from what a model knows about Sigma. Every rule the console holds, drafted and written →
(none)
payload.detection_type on SEC-0005-f is 'scheduled_reboot_registered', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-f names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
SubjectUserNamepayload.principal on SEC-0005-g is 'fs-04', which is a host and not an account. Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored value, and match nothing
(none)payload.detection_type on SEC-0005-g is 'boot_record_overwritten', which is this platform's own detector label rather than a field of the source log. Sigma matches what the log recorded, not what we concluded from it, so there is no field for this and inventing one would encode our verdict as somebody else's observation
(prose)labels.summary on SEC-0005-g names the detail a stronger rule would key on, in prose written for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is the guessing this module refuses everywhere else
The rule
# DRAFT - assembled from one incident's stored telemetry. Not deployed,
# not validated against a live log pipeline, and not adopted.
# Incident: INC-2026-0905
# Technique: T1561.002 Disk Structure Wipe (Impact)
#
# Every field below was read from a stored event:
# Computer <- entity_ref.id (matches this incident only); SEC-0005-f, SEC-0005-g
#
# WARNING: every field is an instance value. This matches this incident and not the technique.
title: 'Draft: Disk Structure Wipe observed in INC-2026-0905'
id: 8aaad194-4a33-5f7a-a824-a912d6cb51ed
status: experimental
description: 'Drafted from INC-2026-0905, which recorded: boot record overwritten with no copy kept, and
a reboot scheduled. Fields below were read from SEC-0005-f, SEC-0005-g.'
references:
- INC-2026-0905
- SEC-0005-f
- SEC-0005-g
author: Sati (drafted from one incident; not validated against live telemetry)
date: 2026/10/18
tags:
- attack.impact
- attack.t1561.002
logsource:
category: security
product: pashupatastra
service: demo
detection:
selection:
Computer: fs-04
condition: selection
falsepositives:
- Every field is specific to INC-2026-0905 (Computer=fs-04). This will match unrelated activity on the
same entities and nothing elsewhere.
- The selection tests a single field (Computer), so anything carrying that value matches regardless of
behaviour.
level: high
x-provenance:
Computer:
source_field: entity_ref.id
observed_in:
- SEC-0005-f
- SEC-0005-g
generalises: false
x-not-mapped:
SubjectUserName: 'payload.principal on SEC-0005-g is ''fs-04'', which is a host and not an account.
Mapping it to a user field would put a hostname in a username: the rule would parse, cite a real stored
value, and match nothing'
(none): payload.detection_type on SEC-0005-g is 'boot_record_overwritten', which is this platform's
own detector label rather than a field of the source log. Sigma matches what the log recorded, not
what we concluded from it, so there is no field for this and inventing one would encode our verdict
as somebody else's observation
(prose): labels.summary on SEC-0005-g names the detail a stronger rule would key on, in prose written
for a human. Parsing hostnames out of it would make the rule depend on sentence structure, which is
the guessing this module refuses everywhere else
x-warning: Every field in this rule is an instance value from this incident. It would have matched this
occurrence and will not match another; it is an indicator match, not a behavioural detection.
Drafted from stored telemetry, never deployed and never adopted. Every field above was read from an event this incident cites; nothing was written from what a model knows about Sigma. Every rule the console holds, drafted and written →
correlated — update fetch, unlisted binary, credential read and admin-share writes to two hosts inside eleven minutes
○observeddrishti
the installation ID is random bytes rather than anything derived from a key, and no key material left the host — there is nothing the fixed address could decrypt in exchange
○observeddrishti
a note demanding 300 USD of bitcoin to one fixed address, carrying an installation ID for the victim to send back
○observeddrishti
the first sector of fs-04's system disk was overwritten and the original master boot record was not copied anywhere on the volume
○observeddrishti
a scheduled task was registered on fs-04 and dc-01 to reboot in fifty-seven minutes
○observeddrishti
fs-04 accepted a malformed SMBv1 transaction from fin-034 of the shape used to execute code on an unpatched service
○observeddrishti
fin-034 wrote to ADMIN$ on fs-04 and dc-01 within forty seconds, authenticating as svc-deploy; it had contacted neither before
○reasonedbuddhi
Ransomware. The data is encrypted and recoverable — pay the demand or wait for a key. (6%) · ruled out by SEC-0005-i, SEC-0005-g
○reasonedbuddhi
A destructive wiper arrived inside a trojanised vendor update, took svc-deploy's credentials out of memory, spread to fs-04 and dc-01 both with those credentials and by exploiting an unpatched SMB service, and overwrote boot records behind a ransom note that cannot be paid. (94%)
○observeddrishti
that binary read lsass memory; svc-deploy's deployment credentials were recovered in cleartext
○observeddrishti
the updater wrote and launched a binary the vendor's published manifest for 7.4.11 does not list
○observeddrishti
fin-034 fetched build 7.4.11 from the vendor update endpoint at 192.0.2.30 — signed, on schedule, and indistinguishable from every other Tuesday
