detecting-ransomware-precursors-in-network

Detects pre-encryption ransomware indicators in network traffic using Zeek, Suricata, and SIEM correlation.

954|172|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/xalgord/xalgorix --skill detecting-ransomware-precursors-in-network
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: detecting-ransomware-precursors-in-network
Source: https://github.com/xalgord/xalgorix/tree/main/internal/tools/skills/data/ransomware-defense/detecting-ransomware-precursors-in-network
Command: npx skills add https://github.com/xalgord/xalgorix --skill detecting-ransomware-precursors-in-network

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Ransomware operators spend days or weeks inside a network before encryption begins, and most organizations miss the early warning signs. This Skill helps security teams detect ransomware precursor activity—C2 beaconing, credential harvesting, lateral movement, and data staging—during the window where containment can still prevent data loss.

Core Features & Use Cases

  • Network Detection Rules: Ready-to-deploy Suricata signatures and Zeek scripts for Cobalt Strike beacons, DCSync, PsExec, internal scans, and RDP brute force.
  • SIEM Correlation: Splunk SPL and Microsoft Sentinel KQL queries that chain low-severity precursor events into high-confidence alerts.
  • Threat Intelligence Integration: Automated ingestion of abuse.ch Feodo Tracker, URLhaus, ThreatFox, and CISA KEV feeds for ransomware IOCs.
  • Use Case: A SOC analyst receives an alert that a workstation connected to 47 internal hosts on port 445 at 2 AM. Using this Skill's workflow, they correlate Zeek conn.log, ssl.log beacon timing, and Kerberos TGS-REQ anomalies to confirm a Cobalt Strike foothold and isolate the host before encryption begins.

Quick Start

Ask the AI to build detection rules for Cobalt Strike beaconing and internal lateral movement using Zeek and Suricata on your network.

Frequently Asked Questions about detecting-ransomware-precursors-in-network

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect Cobalt Strike beacons in network traffic?

Detect Cobalt Strike beacons using Suricata TLS certificate rules for default profiles, plus JA3/JA4 fingerprinting and beacon-timing analysis for Malleable C2 profiles. Tools like RITA analyze Zeek logs for regular connection intervals with jitter, which catches beacons hidden inside encrypted traffic.

What network indicators appear before ransomware encryption?

Pre-encryption indicators include RDP brute force, Cobalt Strike or Sliver C2 callbacks, Kerberoasting and DCSync traffic, internal port scanning, PsExec service installs over SMB, and large SMB transfers indicating data staging. Mapping these to kill chain phases enables detection during the average 21-day dwell time.

Zeek vs Suricata for ransomware precursor detection?

Zeek generates structured protocol logs (SMB, Kerberos, DNS, TLS) ideal for behavioral analysis and beacon detection, while Suricata provides signature-based IDS/IPS alerting for known patterns like PSEXESVC and DCSync. This Skill uses both together, with SIEM correlation chaining their outputs.

Why do ransomware detection rules miss low-and-slow attacks?

Fixed thresholds like 20 failed logins per 60 seconds miss password spraying spread across hours, and default TLS certificate rules miss customized Malleable C2 profiles. Add per-destination distinct-account rules, JA3/JA4 fingerprinting, and beacon-timing analysis to close these gaps.

How do I validate ransomware detection rules before deployment?

Replay a labeled PCAP containing Cobalt Strike beacons, PsExec, and Kerberoasting through Suricata and Zeek, then confirm each rule fires and the SIEM chains events into one high-severity alert. Baseline a week of normal admin and scanner traffic to tune thresholds and reduce false positives.

When should I not use network-based ransomware detection?

This approach covers the pre-encryption detection window only; it does not handle post-encryption response or recovery. It also requires network TAP or SPAN access, DNS logging, and flow data, so environments without this visibility need host-based EDR telemetry instead.