Can a Cyber Attack Map Actually Tell You About Ransomware? What zcrLog Shows Instead
Attack maps don't know your systems; ransomware never labels itself. See how to read incidents, MITRE techniques and rules in zcrLog. Try the free demo.
You've probably seen those world maps with red lines shooting across continents, labeled "Live Cyber Attack Map." They look thrilling — straight out of a spy movie. But ask a straight question: can it tell you whether someone in your organization is getting brute-forced on RDP right now? No, not even close. Almost all of those maps show aggregated traffic from honeypots and sensors scattered around the world — not data from your specific systems.
And ransomware itself never puts up a sign that says "Ransomware." It shows up as a chain of small events: repeated password attempts (brute force) → taking control of other machines on the network (lateral movement) → pulling data out (data exfiltration) → and only then encrypting everything at the end. By the time anyone notices, it's usually too late. So this article isn't about pretty "attack maps" you scroll past for entertainment — it's a walkthrough of zcrLog's actual Threat Analysis panel, free to try in the demo, with a look at what each tab measures, how to read them together, and what a ransomware chain looks like across them.
What a Global Attack Map Can Actually Do (and Can't)
The maps you typically see at conferences or expo booths pull together traffic from honeypots and sensors spread across multiple countries, then display it as lines shooting across a world map in real time. It looks great, it grabs attention, and it tells you the broad-strokes story that "the world is a mess right now" — but it doesn't know your organization. There's no incident ID to dig into, no button to click for details on who got hit with what, and most importantly, it isn't an operational tool for a SOC team. It's ambient display — something you leave running on a screen in the conference room.
What a security team actually needs isn't a picture of the whole world — it's a specific question answered: "Who is trying to get into our systems right now, and how far have they gotten?"
What zcrLog's Threat Analysis Looks Like
zcrLog's Threat Analysis section has 5 sub-tabs: Threat Incidents, Detection Rules Management, Mitre Attack Panel, Attack Map, and IP Intelligence — the five share some overlapping detection vocabulary, but each covers something different: live traffic, incident records, ATT&CK techniques, detection rules, and a lookup for a single IP address. (See zcrLog — the live demo needs the demo login, demo / demo.)
Attack Map — Traffic Broken Down by Direction, Type and Origin
The Attack Map page has a time selector, and every figure on it depends on the window you pick.
For whichever window you pick, the page summarizes the traffic: the total number of events, how they split between inbound and outbound, how many countries they come from, a breakdown by event type (such as brute force and scan), and the top source countries with their share. Read those together rather than one at a time. A window made up mostly of plain connections tells you little. A rise in brute force from one country can be a lead. And outbound traffic you can't explain deserves a second look, because data exfiltration and command-and-control traffic often leave in that direction.
The traffic keeps changing, so what matters is the shape of the mix, not any single number. The map doesn't label any of this as ransomware, and that's exactly the point this article wants to make: it gives you the raw ingredients, and you have to go to the next tab to find the "footprint."
Threat Incidents — Where Ransomware Actually Leaves Its Footprint
This tab is the heart of the article. It lists incidents, one per row, with fields such as an incident ID, a type, a severity, a status (for example open or closed), a threat count, the user involved, source and destination IPs, and the MITRE tactic and technique the incident maps to.
Look at how the incident types are named. In the demo data they describe behavior, such as brute force, lateral movement or data exfiltration, and none of them is called "ransomware." This is exactly what newer playbook writers tend to get wrong: ransomware usually isn't detected as "ransomware" from the start. It tends to surface as a successful brute force, followed by movement to another remote service. In ATT&CK terms, that's T1110 (Brute Force, under Credential Access, TA0006) followed by T1021 (Remote Services, under Lateral Movement, TA0008). That maps onto a very common ransomware attack chain: hammer away at RDP or VPN credentials exposed to the internet, then use that foothold to reach other machines. (I wrote about this in more depth in Exposed RDP Is Ransomware Gangs' Favorite Entry Point, if you want to go deeper — and it matches what CISA's own #StopRansomware advisories describe: exposed, brute-forceable RDP/VPN as one of the leading initial access vectors across multiple ransomware groups.)
Here are three example rows, invented for illustration and not taken from any real environment:
- A brute-force incident, severity Medium, still open — someone is guessing credentials against an account. It's the earliest link in the chain, which usually makes it a cheap moment to act: look at where the attempts come from and what they target (for example an exposed RDP or VPN service), and whether any guess worked.
- A lateral-movement incident, severity High, still open — a foothold is being used to reach other machines. Most teams would put it near the top of the queue, because the steps that follow it, such as data exfiltration and file encryption, are harder to undo.
- A malware incident, severity High, already closed — closed means the incident is no longer open, not necessarily that the cause is gone, so it's worth checking that the user and the hosts involved were looked at too.
Read the first two in sequence, a brute-force incident and then a lateral-movement incident involving the same user, and you're looking at the opening moves of a ransomware chain, and of plenty of other intrusions. What sets ransomware apart is the last step, file encryption, often preceded by data exfiltration.
Mitre Attack Panel — Cards, Not a Matrix Grid
Most people are used to the ATT&CK Matrix as a grid of boxes, but this page in zcrLog renders as technique cards, with a summary line at the top counting the techniques and events detected.
Each card is one technique. It shows the technique's ID and name (T1110 Brute Force or T1021 Remote Services, say), a severity and a risk score, the tactic it belongs to, how many events, hosts and sources it counts, and the detection method behind it. Each card also links out to the MITRE reference and shows the time window in which the technique was observed, so you can trace back when the activity happened.
This is where you go from a single incident to the wider picture. When an incident maps to a technique, look for that technique's card. The card is a separate view, not a breakdown of the incident, so treat its counts as context rather than as the incident's own numbers. A technique with many hosts behind it usually points to a broader problem than one with a single host. And if cards for both T1110 and T1021 show up in the same time window, that could be the two-step pattern from the previous section, though the cards alone don't show whether the same hosts were involved.
Detection Rules Management — Pre-Built Rules, Including One Specifically for Ransomware
This tab includes ready-made rule templates, such as brute force over SSH, data exfiltration and SQL injection. In the rule list, each rule shows fields such as its severity, the condition logic it uses and its status.
The one most relevant to this article's topic is a rule called Ransomware File Extension. As the name suggests, it looks for ransomware's tail-end signal: a large batch of files suddenly being renamed to a new set of extensions all at once, the classic tell of mass file encryption. It sits at the opposite end of the chain from the brute-force and remote-services techniques above: those point at the break-in, this one points at the damage, and you want rules at both ends.
For each rule, look at three things: how severe an alert from it is, what condition it uses, and what its status says.
IP Intelligence — The Fifth Tab
The last tab in the Threat Analysis group is IP Intelligence, a lookup tool where you type in an IP address and search it (it doesn't automatically pull in IPs from the other four tabs).
Why "Seeing" Alone Isn't Enough
Picture a security camera outside your front door. It sees everyone who walks past the gate, all day long. But if nobody connects the dots — that the person who walked by this morning is the same person trying to pry open a window at midnight — the camera is just recording footage. It isn't preventing anything. Attack maps work the same way: watching alone isn't enough. You need to connect the dots too.
That's why zcrLog's Threat Analysis isn't just "displaying a map" — it lets a SOC team move from the overview in Attack Map into the details in Threat Incidents, switch to the related technique in Mitre Attack Panel, and check back whether Detection Rules Management already has a rule watching that spot. All in one console (switching tabs yourself — there's no automatic cross-tab drill-down), with no jumping between 4-5 separate tools on different screens — something zcrLog was built to do from day one, not a feature bolted on afterward.
Side by Side
| Topic | Typical Public Attack Map | zcrLog Threat Analysis |
|---|
| Data shown | Aggregated traffic from honeypots/sensors worldwide, not specific to any organization | Events with incident IDs you can dig into |
| Ransomware identification | No direct label — you have to infer it | Also no direct label, but you can look for the T1110→T1021 pattern across incidents and technique cards, plus a dedicated Ransomware File Extension rule aimed at the late-stage signal |
| Click to investigate | Not possible — it's a still image for looks | Switch between Attack Map, Threat Incidents, and Mitre Attack Panel in one console (manual tab switching, not auto drill-down) |
| Ready-made detection rules | None | Ready-made templates in Detection Rules Management, including one for ransomware file extensions |
If you want to know what it costs to get a panel like this for your own organization, check out all the zcrLog plans.
What to Check When You Open It Yourself
The example rows above are invented for illustration. The live demo needs the demo login (demo / demo); when you open it, read the structure, not the numbers. A quick path through it:
- In Attack Map, pick a time window and read the inbound/outbound split and the event-type mix together.
- In Threat Incidents, look at an incident's type, severity and status, and note the MITRE technique it maps to.
- In Mitre Attack Panel, find the card for that technique and see how many hosts and sources it counts.
- In Detection Rules Management, look for a rule aimed at the late-stage signal, and note its severity, its condition and its status.
- In IP Intelligence, look up one of the addresses from the incident you picked; the tab won't fill it in for you.
Nothing connects these tabs automatically, so you're the one doing the joining. That's the skill worth practicing.
If you want a primer on MITRE ATT&CK before trying the demo, read What Is MITRE ATT&CK?. Or if you're interested in the details of setting up ransomware detection rules in a SIEM, there's a dedicated article on that: Where to Start When Setting Up Ransomware Detection Rules in a SIEM.
The Bottom Line
A beautiful attack map on the big screen at a conference isn't a tool that actually stops ransomware, because it doesn't know your systems — and ransomware itself never puts up a sign announcing what it is. It hides inside a chain of small events: a successful brute force, followed by movement to a remote service. What you actually need is a system that shows the overview, lets you drill into details, and has rules already watching the spots attacks tend to land on. All of that is free to try for real in zcrLog's demo — don't take our word for it, go see it yourself.
Want to talk through your organization's ransomware readiness? Get in touch:
Sources
- CISA — #StopRansomware Guide and individual #StopRansomware group advisories (e.g. Akira, Gunra) — confirm exposed, brute-forceable RDP/VPN as a recurring leading initial access vector across multiple ransomware groups
- MITRE ATT&CK — T1110 Brute Force and T1021 Remote Services