Category: Cybersecurity

The New Shape of Cyber Risk: From Human Attackers to Agentic AI


agentic-ai-cyber-risk-autonomous-ransomware

Excerpt: Autonomous AI systems are no longer a theoretical cyber risk. Recent security incidents show how agentic attackers can exploit, adapt, and move through infrastructure faster than traditional human-led operations.

Introduction

Cybersecurity has entered a new era — one defined not by human-operated malware, but by autonomous, agentic AI systems capable of executing full intrusion chains at machine speed. Recent incidents across the industry highlight how quickly the threat landscape is shifting, and why defenders must adapt just as rapidly.

This article summarizes the most significant recent events, including the July 2026 Hugging Face breach and the rise of JADEPUFFER, the first fully autonomous ransomware agent.

Hugging Face’s July 2026 Security Incident: A Fully Autonomous AI Intrusion

In July 2026, Hugging Face disclosed a breach into part of its production infrastructure — notable because the intrusion was driven end-to-end by an autonomous AI agent system. The attack began in the dataset-processing pipeline, where a malicious dataset exploited two code-execution paths to run unauthorized code. From there, the attacker escalated privileges, harvested cloud and cluster credentials, and moved laterally across internal clusters over a weekend.

Key characteristics of the attack:

  • Abuse of dataset loaders and template-injection vulnerabilities
  • Node-level escalation and credential harvesting
  • Thousands of autonomous actions across short-lived sandboxes
  • Self-migrating command-and-control hosted on public services
  • Over 17,000 logged events tied to the intrusion
  • No evidence of tampering with public models or datasets

Hugging Face responded by rebuilding compromised nodes, rotating credentials, tightening admission controls, and improving detection and alerting. The company also involved external forensic specialists and law enforcement.

This incident is widely considered the first real-world test of the “agentic attacker” model long predicted by security researchers.

JADEPUFFER: The First Fully Autonomous Ransomware Agent

Around the same time, researchers documented JADEPUFFER, a ransomware operation executed entirely by an autonomous AI agent. Sysdig’s analysis shows the agent independently chained reconnaissance, credential theft, lateral movement, privilege escalation, and destructive encryption — all without human operators issuing step-by-step commands.

Highlights from the JADEPUFFER campaign:

  • Exploited a known Langflow vulnerability, CVE-2025-3248
  • Harvested cloud and AI provider credentials
  • Pivoted into a production database environment
  • Encrypted 1,342 configuration records before issuing a ransom demand
  • Adapted to technical failures in real time, diagnosing and correcting issues in 31 seconds
  • Used custom ransomware, EncForge, targeting 180+ AI/ML file types, including model checkpoints, vector databases, SafeTensors, FAISS indexes, and training datasets

The Cloud Security Alliance notes that the novelty is not the techniques themselves — all were previously known — but the removal of humans from the decision loop, allowing the agent to exploit multiple configuration failures at machine speed.

The Compression of Time: Exploitation at Machine Speed

Across both incidents, one trend is clear: AI agents compress the timeline of exploitation from days or hours to minutes or seconds.

In the Hugging Face case, attackers executed thousands of actions across ephemeral sandboxes. In JADEPUFFER, the agent iteratively developed and deployed six payload-delivery scripts in under five minutes, correcting its own errors autonomously.

This acceleration fundamentally changes defensive requirements. Traditional SOC workflows cannot keep pace with autonomous adversaries.

What These Incidents Reveal About Agentic Attackers

1. AI Pipelines Are Now Primary Attack Surfaces

The Hugging Face breach began in dataset ingestion — a reminder that AI infrastructure itself is a high-value target.

2. Autonomous Agents Excel at Scale

Thousands of micro-actions across short-lived environments are trivial for AI systems but overwhelming for human analysts.

3. Command-and-Control Is Blending Into Legitimate Infrastructure

Self-migrating C2 hosted on public services makes attacker traffic harder to distinguish.

4. AI on Defense Is No Longer Optional

Hugging Face relied heavily on its own AI-driven anomaly detection and agentic analysis to reconstruct the attack timeline.

5. Policy Asymmetry Is Emerging

Attackers use unrestricted models; defenders often face guardrails that block forensic payloads — forcing fallback to self-hosted or open-weight models.

Implications for Security Leaders

Treat AI Pipelines as Critical Assets

Sandbox untrusted data, enforce strict validation, and monitor execution paths.

Detect Agentic Behavior, Not Just Signatures

Look for high-volume, low-signal activity across short-lived environments.

Adopt AI-Native Forensics and Response

Use LLM-based triage, automated timeline reconstruction, and anomaly detection.

Plan for Policy Asymmetry

Prepare fallback strategies when commercial AI guardrails interfere with incident response.

Update Incident Playbooks for AI-Driven Attacks

Include rapid secret rotation, node rebuilds, and AI-specific containment steps.

Conclusion: The First Real Test of the Agentic-Attacker Era

The Hugging Face breach and JADEPUFFER ransomware campaign are early but decisive signals that autonomous, AI-driven offensive tooling is no longer theoretical. We have entered an era where attacks are designed by humans but executed by agents, and defense must evolve accordingly.

Organizations that adopt AI-native visibility, detection, and response will be best positioned to survive the next wave of agentic attackers.

References

  1. Hugging Face. “Security incident disclosure — July 2026.” Published July 16, 2026.
  2. Sysdig Threat Research Team. “JADEPUFFER: Agentic ransomware for automated database extortion.” Published July 1, 2026.
  3. Cloud Security Alliance AI Safety Initiative. “JADEPUFFER: The First Fully Autonomous Ransomware Agent.” Published July 3, 2026.
  4. Cloud Security Alliance AI Safety Initiative. “Hugging Face’s Autonomous AI Agent Breach.” Published July 20, 2026.
  5. BleepingComputer. “JadePuffer agentic attacks now target AI model data with ransomware.” Published July 20, 2026.
  6. The Hacker News. “New ENCFORGE Ransomware Targets AI Model Files in Langflow RCE Attack.” Published July 21, 2026.

Runbook: Defending Against the Axios NPM Zero-Day Supply Chain Attack with Microsoft Sentinel

Author: Lizet Pena De Sola

Created: 2026-04-10

Last Updated: 2026-06-02
Criticality: High
Estimated Duration: Immediate containment: 2-4 hours; full remediation and validation: 1-5 business days depending on environment size
Audience: Security operations, SOC Analysts, SOC Engineers, DevSecOps, platform engineering, application owners, incident response teams, and cloud security teams
Category: Supply Chain Security; Microsoft Sentinel; Threat Intelligence; Node.js; NPM

Purpose

This runbook provides a checklist-driven response and hardening guide for organizations defending against the Axios NPM supply chain compromise. The campaign involved malicious Axios package releases 1.14.1 and 0.30.4, a malicious dependency named plain-crypto-js, and cross-platform payload delivery associated with WAVESHAPER.V2. Use this document to coordinate containment, detection, threat intelligence ingestion, incident response, credential rotation, recovery, and long-term supply chain hardening. This was zero-day attack launched from March 31st, 2026; to April 2nd, 2026. This runbook was used as an example to conduct Security Incident Response activities on affected organizations.

Threat Summary

  • Impacted ecosystem: NPM / Node.js applications and build environments using Axios directly or transitively
  • Known malicious Axios versions: 1.14.1 and 0.30.4
  • Known safe rollback examples: 1.14.0, 0.30.3, or earlier known-good, approved versions
  • Malicious dependency: plain-crypto-js, including reported versions 4.2.0 and 4.2.1
  • Execution method: NPM post install hook executing an obfuscated JavaScript dropper
  • Target platforms: Windows, macOS, and Linux
  • Primary risk: Developer workstation, CI/CD, build server, package cache, and credential exposure leading to downstream compromise

Prerequisites

  • Access to source control, dependency manifests, lockfiles, SBOMs, and artifact/package registry logs.
  • Access to CI/CD platforms, build runners, container build images, and deployment logs.
  • Microsoft Sentinel workspace with relevant endpoint, identity, cloud, DNS, proxy, firewall, and Defender data connectors flowing.
  • Microsoft Sentinel Contributor or higher permissions to manage threat intelligence indicators and analytics rules.
  • Authority to isolate endpoints, pause pipelines, rotate secrets, block network indicators, and rebuild affected systems.

Severity and Activation Criteria

Activate this playbook if any of the following are true:

  • Axios version 1.14.1 or 0.30.4 appears in source repositories, package lockfiles, SBOMs, container images, deployed applications, developer machines, or CI/CD environments.
  • plain-crypto-js version 4.2.0 or 4.2.1 appears in dependency trees or package caches.
  • Node.js, npm, yarn, pnpm, or build processes spawned shell, PowerShell, curl, bash, zsh, Python, or suspicious child processes during package installation.
  • Any known command-and-control indicator, file hash, suspicious payload path, or persistence artifact is observed.
  • Secrets, tokens, cloud credentials, signing keys, or npm tokens were present on a system where the compromised dependency may have executed.

Phase 1: Immediate Containment Checklist

  • [ ] Open a high-severity incident and assign SOC, DevSecOps, platform, and application owners.
    Owner: Incident Commander
    Evidence: Incident ID
  • [ ] Pause nonessential CI/CD pipelines that build or deploy Node.js applications until dependency checks are complete.
    Owner: DevSecOps
    Evidence: Pipeline freeze record
  • [ ] Block known C2 domain and IP indicators at DNS, proxy, firewall, EDR, and cloud egress controls.
    Owner: Network Security
    Evidence: Change ticket / policy ID
  • [ ] Configure private package repositories to deny/remove use of known malicious Axios versions and the malicious dependency.
    Owner: Platform Engineering
    Evidence: Registry policy
  • [ ] Identify systems that executed package installation during the exposure window and prioritize them for isolation and triage.
    Owner: SOC / Endpoint
    Evidence: Device list
  • [ ] If plain-crypto-js is detected, treat the host or build environment as compromised until rebuilt or fully remediated.
    Owner: Incident Response
    Evidence: Containment decision
  • [ ] Preserve relevant logs, dependency manifests, lockfiles, build artifacts, EDR telemetry, and network logs before cleanup.
    Owner: Forensics
    Evidence: Evidence location

Phase 2: Dependency Exposure Assessment Checklist

  • [ ] Search source repositories for direct Axios version references.
    How to validate: Review package.json, workspace files, monorepos, and package manager configuration.
  • [ ] Search lockfiles for malicious Axios versions and plain-crypto-js.
    How to validate: Inspect package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml.
  • [ ] Inspect dependency trees for transitive exposure.
    How to validate: Use package manager dependency tree commands, SBOM tools, software composition analysis, or internal dependency inventory.
  • [ ] Review private registry, proxy, and artifact repository download logs.
    How to validate: Look for downloads of Axios 1.14.1, Axios 0.30.4, or plain-crypto-js.
  • [ ] Review container images and build layers.
    How to validate: Scan base images, app images, ephemeral builder images, and cached dependency layers.
  • [ ] Review developer workstation package caches.
    How to validate: Check npm, yarn, pnpm, and shared build caches; clear caches after evidence collection.
  • [ ] Document every affected repository, build pipeline, host, image, and deployed service.
    How to validate: Maintain an exposure register with owner, status, and remediation evidence.

Phase 3: Microsoft Sentinel Threat Intelligence Checklist

Use Microsoft Sentinel threat intelligence to convert the campaign IOCs into managed STIX objects that can drive analytics, hunting, and incident creation.

  • [ ] Confirm permissions and connectors.
    Details: Ensure the Threat Intelligence solution and relevant data connectors are enabled and telemetry is flowing.
  • [ ] Open the Sentinel threat intelligence management interface.
    Details: In the Defender portal, navigate to Threat intelligence > Intel management.
  • [ ] Create campaign-specific STIX indicators.
    Details: Add indicators for C2 domains, URLs, IP addresses, and file hashes listed in the IOC appendix.
  • [ ] Use consistent tags.
    Details: Suggested tags: Axios-NPM-Compromise, SupplyChain, UNC1069, WAVESHAPER-V2, NodeJS.
  • [ ] Set confidence, validity, source, and TLP.
    Details: Use values aligned with your threat intelligence policy and extend validity for high-value indicators where appropriate.
  • [ ] Create relationships.
    Details: Relate indicators to threat actor, malware, attack pattern, campaign, and affected identity objects where your TI model supports it.
  • [ ] Bulk import where possible.
    Details: Use CSV, STIX/TAXII, or approved TI platform workflows for multiple indicators. Note: IOCs are available under Threat Intelligence in the Unified Security Experience portal for organizations using Microsoft Sentinel in Defender.
  • [ ] Review indicator freshness.
    Details: Validate that analytics rules can match indicators within expected lookup and refresh behavior.

Phase 4: Sentinel Analytics Rule Checklist

Use the Microsoft Sentinel TI map… analytics rule templates to generate alerts and incidents when threat indicators match ingested telemetry.

  • [ ] IP indicators
    Checklist: Enable a relevant TI map IP rule for network, firewall, DNS, proxy, cloud activity, or endpoint telemetry sources available in your workspace.
  • [ ] Domain and URL indicators
    Checklist: Enable TI map rules that match DNS, proxy, Defender, and network logs against campaign domains and URLs.
  • [ ] File hash indicators
    Checklist: Enable file-hash TI map rules for endpoint telemetry such as Defender device file events.
  • [ ] Scheduling
    Checklist: Use the default schedule where appropriate, then tune frequency based on telemetry latency and SOC requirements.
  • [ ] Entity mapping
    Checklist: Confirm IP, URL, host, file hash, account, and process entity mappings are present and useful for investigation.
  • [ ] Incident generation
    Checklist: Enable incident creation and route incidents to the correct SOC queue. Utilize the TI Map Analytic Rule templates to create rules that detect the campaign IoCs in the organization. Convert specific Hunting Queries into custom detections or ARs in Sentinel.
  • [ ] Automation
    Checklist: Attach automation rules or playbooks for enrichment, owner notification, endpoint isolation requests, and ticket creation.
  • [ ] Validation
    Checklist: Review the SecurityAlert table and Sentinel incidents to verify rules are producing actionable results.

Phase 5: Detection Engineering and Hunting Checklist

Sample hunting queries

The following sample hunting queries were taken from the Microsoft Security Blog article Mitigating the Axios npm supply chain compromise and can be adapted for your environment and available telemetry. They cover

  • suspicious network connections
    • npm/node child process chains
    • file artifacts
    • Windows persistence indicators

Sample query: devices with suspicious network connections related to the compromise


DeviceNetworkEvents
| where RemoteUrl has_any (“sfrclak.com”) or RemoteIP in (“142.11.206.73″,”23.254.167.216”)
| where RemotePort == 8000 or InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort

DeviceNetworkEvents

| where RemoteUrl has_any (“sfrclak.com”) or RemoteIP in (“142.11.206.73″,”23.254.167.216”)| where RemotePort == 8000 or InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort

Sample query: suspicious process chains from npm or node execution


DeviceProcessEvents
| where InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)
| where FileName in~ (“cmd.exe”,”powershell.exe”,”curl.exe”,”bash”,”zsh”,”python”,”python3″,”wt.exe”)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

Sample query: file artifacts associated with Windows, macOS, and Linux payloads


DeviceFileEvents
| where FolderPath has_any (“%PROGRAMDATA%”,”/Library/Caches/com.apple.act.mond”,”/tmp”)
| where FileName in~ (“wt.exe”,”system.bat”,”ld.py”,”setup.js”)
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, SHA256

Sample query: persistence and command execution indicators on Windows


DeviceRegistryEvents
| where RegistryKey has @”\\Software\\Microsoft\\Windows\\CurrentVersion\\Run”
| where RegistryValueName =~ “MicrosoftUpdate”
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData

Tune these sample queries to your specific tables, connector coverage, retention window, and field names. If you use Microsoft Sentinel with Defender XDR data, you may need to adapt the table names or add joins for broader coverage. If you use a different EDR solution, modify the queries above to adapt to the endpoint telemetry you are capturing in your SIEM.

  • [ ] NPM postinstall execution
    Hunt for: Package installation events where node, npm, yarn, or pnpm spawns shell interpreters or download utilities.
  • [ ] Windows execution
    Hunt for: node.exe spawning cmd.exe, powershell.exe, copied wt.exe, curl.exe, hidden windows, execution policy bypass, or payloads in %TEMP%.
  • [ ] Windows persistence
    Hunt for: %PROGRAMDATA%\system.bat and registry Run key value named MicrosoftUpdate under HKCU:\Software\Microsoft\Windows\CurrentVersion\Run.
  • [ ] macOS execution
    Hunt for: Downloads or execution from /Library/Caches/com.apple.act.mond, suspicious curl, bash, or zsh launched during package installation.
  • [ ] Linux execution
    Hunt for: Downloads or execution of /tmp/ld.py, Python backdoor execution, suspicious outbound traffic from developer or build systems.
  • [ ] Network activity
    Hunt for: Connections to known C2 infrastructure (IoCs related to campaign), port 8000, 60-second beaconing, Base64-encoded JSON beacons, and the User-Agent mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0).
  • [ ] Forensic cleanup attempts
    Hunt for: Deletion of setup.js, changes replacing package.json from package.md, or package metadata reverting after installation.
  • [ ] Credential exposure
    Hunt for: Access to environment variables, cloud credentials, npm tokens, SSH keys, signing keys, keychain material, or CI/CD secrets from affected systems.

Phase 6: Credential Rotation Checklist

If the malicious dependency executed on a host, assume secrets accessible to that host may be compromised.

  • [ ] NPM tokens
    Action: Revoke and reissue maintainer, automation, publish, and read tokens. Enforce least privilege and MFA.
  • [ ] CI/CD secrets
    Action: Rotate pipeline variables, deployment tokens, service connections, webhook secrets, and runner credentials.
  • [ ] Cloud credentials
    Action: Rotate access keys, service principals, workload identities, and deployment credentials used on affected hosts.
  • [ ] Source control credentials
    Action: Rotate personal access tokens, deploy keys, SSH keys, and GitHub/GitLab/ADO tokens exposed to affected systems.
  • [ ] Application secrets
    Action: Rotate database credentials, API keys, signing secrets, OAuth client secrets, and third-party service keys.
  • [ ] Secrets in local files
    Action: Identify plaintext secrets in .env, shell profiles, credential files, package manager config, and local key stores.
  • [ ] Audit usage
    Action: Review authentication logs for unusual use before and after rotation.

Phase 7: Recovery Checklist

  • [ ] Roll back Axios to a known-good approved version.
    Validation: Confirm lockfiles and deployed artifacts no longer reference malicious versions.
  • [ ] Remove plain-crypto-js from dependency trees unless explicitly business-approved and verified benign.
    Validation: Dependency tree and SBOM scans are clean.
  • [ ] Clear local, shared, and CI package caches.
    Validation: npm, yarn, pnpm, build cache, and artifact cache cleanup records exist.
  • [ ] Rebuild affected developer workstations and CI runners from known-good images when compromise is likely.
    Validation: Fresh images deployed and old runners decommissioned.
  • [ ] Rebuild application artifacts after dependency rollback.
    Validation: New builds must use pinned dependencies and trusted artifact sources.
  • [ ] Redeploy only after validation gates pass.
    Validation: Security scan, dependency review, and incident commander approval are complete.

Phase 8: Long-Term Hardening Checklist

  • [ ] Dependency pinning
    Implementation guidance: Require lockfiles and deterministic builds. Avoid unbounded semver ranges for production builds.
  • [ ] Private registry controls
    Implementation guidance: Use allowlists, quarantine newly published packages, and block known-bad package versions.
  • [ ] Auto-update governance
    Implementation guidance: Disable unsafe automatic upgrades for critical dependencies. Require review and staged rollout.
  • [ ] Package provenance
    Implementation guidance: Prefer packages with provenance metadata, signed artifacts, verified maintainers, and transparent release processes.
  • [ ] Build isolation
    Implementation guidance: Run builds in ephemeral, sandboxed environments with minimal host filesystem access.
  • [ ] Secret vaulting
    Implementation guidance: Remove plaintext secrets from developer machines and build environments; use managed identity and secure vaults.
  • [ ] Maintainer protection
    Implementation guidance: Require MFA, phishing-resistant authentication where possible, least-privilege package publishing, and emergency token revocation procedures.
  • [ ] Continuous monitoring
    Implementation guidance: Monitor package registry events, dependency drift, newly added postinstall scripts, and build-time process anomalies.
  • [ ] SBOM and SCA coverage
    Implementation guidance: Generate SBOMs for applications and images, store them with releases, and continuously scan for compromised package versions.

Rollback Plan

  1. If a remediation deployment fails, stop the deployment and keep the previous known-good production artifact running only if it is confirmed not to contain malicious Axios versions or plain-crypto-js.
  2. If the previous artifact is exposed, prioritize emergency rollback to an earlier clean build, hotfix build with pinned safe dependencies, or temporary service isolation.
  3. If credentials were rotated incorrectly, use break-glass procedures to restore service using newly issued credentials, not previously exposed secrets.
  4. If Sentinel analytics rules generate excessive noise, tune scope and source connectors, but do not remove campaign indicators until containment and hunting are complete.

Post-Checks

  • [ ] No source repository, lockfile, SBOM, artifact, image, or deployed workload references Axios 1.14.1, Axios 0.30.4, or malicious plain-crypto-js versions.
  • [ ] No active endpoint telemetry indicates WAVESHAPER.V2 payload paths, persistence artifacts, suspicious child processes, or known file hashes.
  • [ ] No DNS, proxy, firewall, endpoint, or cloud logs show active communication with known C2 infrastructure.
  • [ ] All credentials accessible to affected systems were rotated and suspicious authentication activity was reviewed.
  • [ ] Microsoft Sentinel TI objects and TI map analytics rules are active, producing useful incidents, and routed to the correct SOC workflow.
  • [ ] Affected developer machines, build runners, and caches have been rebuilt or remediated according to incident response decisions.
  • [ ] Lessons learned are documented and long-term hardening tasks are assigned with owners and due dates.

Appendix A: Baseline Indicators of Compromise

Validate indicators with your threat intelligence source of record before enforcement. Indicators can age quickly and should be managed with confidence, validity, source, and TLP metadata.

Network Indicators

IP Addresses

  • 142.11.206.73
    Type: IP address
    Notes: Reported C2 for WAVESHAPER.V2
  • 23.254.167.216
    Type: IP address
    Notes: Reported suspected UNC1069 infrastructure

Domains

  • sfrclak[.]com
    Type: Domain
    Notes: Reported C2 for WAVESHAPER.V2

URLs

  • http://sfrclak[.]com:8000
    Type: URL
    Notes: Reported C2 endpoint
  • http://sfrclak[.]com:8000/6202033
    Type: URL
    Notes: Reported payload/C2 path

File Indicators

SHA256 Indicators

  • e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09
    Type: SHA256
    Notes: SILKBELL setup.js JavaScript dropper
  • fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf
    Type: SHA256
    Notes: WAVESHAPER.V2 Linux Python RAT
  • 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a
    Type: SHA256
    Notes: WAVESHAPER.V2 macOS native binary
  • 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101
    Type: SHA256
    Notes: WAVESHAPER.V2 Windows Stage 1
  • ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
    Type: SHA256
    Notes: Reported WAVESHAPER.V2-related hash
  • f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd
    Type: SHA256
    Notes: system.bat
  • 58401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668
    Type: SHA256
    Notes: plain-crypto-js-4.2.1.tgz

Appendix B: Microsoft Sentinel Implementation Notes

  • Threat indicators can come from TI feeds, TI platforms, bulk flat-file import, or manual input. TI Feeds for MDTI are now available in Microsoft Sentinel for this campaign.
  • Sentinel analytics rules that use threat intelligence should use the TI map… format so indicators can map to ingested events.
  • Review required data sources for each TI map rule before enabling it.
  • Use entity mappings, so incidents contain usable IP, domain, URL, file, account, device, and process context.
  • Consider automation rules and Logic Apps playbooks for enrichment, notification, ticketing, and response orchestration.
  • Monitor active rules and generated alerts in Sentinel, including the SecurityAlert, AlertInfo and AlertEntity tables and incident queue.

Contacts

  • Incident Commander: Assign per incident
  • SOC Lead: Assign per incident
  • SOC Analysts/Engineer: assign hunting and detection activities (AR enablements, creation of custom detections etc.)
  • DevSecOps Lead: Assign per incident
  • Platform Engineering Lead: Assign per incident
  • Application Owner: Assign per impacted service

Source References