Table of Contents
CyberFortress now continuously watches your backups for signs of ransomware and other unusual activity, and surfaces anything worth a second look right in the portal. This article explains what the feature does, what an alert means (and what it doesn't), how to respond, and what deeper protection is on the way.
Why we built this
Ransomware rarely announces itself. By the time an attack is visible on your production systems, it has often been quietly at work for days, and one of the first places that leaves a trace is your backups, where change rates spike, retention gets shortened, or recovery points start disappearing.
Your backups are also your last line of defense. If they're intact, a ransomware incident is a recovery exercise; if they've been tampered with, it's a crisis. So we watch them closely and tell you the moment something looks off — while you still have clean recovery points to fall back on.
This monitoring runs automatically in the background. It doesn't change how your backups run, and it doesn't affect backup or restore performance.
What an alert does — and does not — mean
An alert means: "this activity looks different from your account's normal pattern, or matches a known risk indicator, and is worth reviewing."
An alert does not mean your data has been encrypted, deleted, or compromised. Nothing in your backups, to our knowledge, has changed, been locked, quarantined, or removed as a result of an alert. Detection only observes and reports — it never modifies your data. Think of it as a smoke detector: it tells you where to look, it doesn't put anything at risk.
Most alerts, especially in the first weeks after the feature is enabled, turn out to be normal activity that simply looked unusual to a system still learning your patterns. That's expected, and it's easy to confirm and clear.
How detection works
It learns your normal, not a generic average
There's no universal definition of "suspicious." A nightly change rate that's routine for a busy file server would be alarming for a rarely-touched archive. So instead of applying one fixed rule to everyone, the system builds a baseline for each account — your typical backup volume, how much data usually changes between backups, and how your restore-point counts trend over time — and measures new activity against that.
This is why a brand-new account, or one that has just had a major change, may see a few early alerts: the baseline is still forming. As more backups complete and expected activity is confirmed, the picture sharpens, and alerts become rare and meaningful.
It runs on backup metadata, never your content
Detection looks at metadata — volumes, counts, timestamps, retention and immutability settings, and (for the advanced tiers described below) file names and extensions. It does not read, open, or analyze the contents of your files, emails, or documents. Your data stays private; we only ever look at the shape of it.
The two kinds of signals
Alerts come from two independent systems. Knowing which one fired tells you how urgent it is.
1. Behavioral detection (pattern-based)
A model continuously scores your backup activity against the baseline it has learned for your account and flags meaningful departures from it.
Example signals:
- A sudden, large jump in how much data changed in a single backup — a classic early fingerprint of mass encryption.
- An unusual burst of file changes in a Microsoft 365 workload.
- Backup volume or restore-point behavior that breaks a long-established rhythm.
Because this is pattern-based, a legitimate-but-large event — a data migration, onboarding a new workload, a seasonal surge, a bulk cleanup — can occasionally trigger a behavioral alert. These are the easiest to recognize and clear, because you'll usually know exactly what caused them.
2. Known-indicator detection (signature-based)
This checks your backup activity against concrete, well-understood risk indicators. It isn't a guess — when one of these fires, a recognized red flag was genuinely present.
Example signals:
- Retention reduced — your backup retention window was shortened, which can shrink how far back you're able to recover.
- Immutability / Ransomware & Insider Protection (RIP) reduced — protections that keep recovery points from being altered or deleted were weakened.
- Large restore-point deletion — an unusually large removal of recovery points.
These deserve prompt attention. Sometimes they're the result of a deliberate, authorized change on your side — but because each one directly affects your ability to recover, it's always worth confirming that the change was intentional.
Reading the risk level
Every alert carries a risk level so you can triage at a glance:
| Risk | What it suggests | Suggested response |
| 🟢 Green | Informational — noted, low concern. | Review at your convenience. |
| 🟡 Yellow | Activity outside your usual pattern. | Take a look when you can; confirm whether it was expected. |
| 🔴 Red | A strong behavioral anomaly or a known-bad indicator. | Review promptly and contact Support if it wasn't an intentional change. |
An alert can also change level over time as more evidence accumulates across subsequent backups.
What's monitored by default
Every eligible account is covered automatically — there's nothing to install or configure. Out of the box, you get:
- Behavioral anomaly detection across your backup storage and change trends.
- Protective-setting monitoring — alerts if backup retention, immutability, or Ransomware & Insider Protection (RIP) windows are reduced.
- Restore-point deletion monitoring — alerts on large or unusual removals of recovery points.
These run continuously and stay out of your way until there's genuinely something to see.
Who gets notified
When an alert opens, we email the account contacts on file (and your partner, if you work with CyberFortress through one). In the coming weeks, you'll also gain the ability to send CyberFortress portal events, including but not limited to these events, to your own syslog / SIEM — so your security team can pick them up in the tooling they already use.
You can also review every alert, open or closed, in the portal at any time.
What to do when you receive an alert
- Open the alert in the portal. It names the affected item, the risk level, and exactly which signal(s) fired — behavioral, a specific known indicator, or both.
- Check it against your own recent activity. Ask: Did we run a large migration, change a retention or immutability policy, decommission a workload, or clean up old restore points around this time? If the alert lines up with something intentional, it's expected.
-
Close expected alerts — and tell the system how to treat them. When an alert reflects legitimate activity, close it as a false positive using one of two options (see Resolving an alert below for the full details):
- Benign and expected — Learn: use for normal, recurring activity you'd expect to see again (a routine, large weekly job, a predictable seasonal spike). The system folds it into your baseline, so similar activity won't alert again — this is how detection calibrates to your account.
- Benign but unusual — Do not learn: use for a genuine one-off — a data migration, a bulk cleanup, a decommission. The alert clears and won't re-fire on that event, but the spike is not treated as your new normal, so detection stays sensitive to a real attack of the same shape later.
- If you're unsure which fits, do not learn is the safer choice.
- For anything unexpected — especially a 🔴 Red or a known-indicator alert — contact CyberFortress Support right away. We'll investigate alongside you and confirm whether any action is needed. Your backups remain safe and fully recoverable while we look.
Seeing more alerts than you expected early on? In the first weeks after this feature is enabled, the behavioral model is still learning your account's normal rhythm, so it deliberately errs on the side of caution. This settles quickly as it calibrates and as expected activity is confirmed.
Resolving an alert: what each option does
When you close an alert, you tell the system how to treat the flagged activity going forward. That choice matters — it's how the detection model gets smarter (or avoids being fooled). Marking something a "false positive" is not an automatic "treat this as normal from now on"; you decide.
Confirm as a threat (the flagged window is excluded, and the baseline rebuilds)
Use when the activity is genuinely suspicious. The alert is confirmed as a real incident, the flagged period is permanently kept out of the model's idea of "normal" (and retained for the audit trail), and the account's baseline is rebuilt from known-clean history. This makes sure a real attack pattern is never quietly learned as acceptable.
False positive → Benign and expected — Learn (the flagged window is folded into the baseline)
Use when the activity was legitimate and representative of this account's normal operations — something you'd expect to see again (e.g., a recurring large weekly job that the model simply hadn't seen enough of yet). The flagged period is added back into the clean history and learned, so genuinely similar activity won't alert again. This is how the model calibrates during the early baseline period.
False positive → Benign but unusual — Do not learn (the flagged window is discarded, not learned)
Use when the activity was legitimate but a one-off you would not want treated as normal — a one-time data migration, a bulk cleanup, a decommission. The alert closes and won't re-fire on that event, but the flagged period is thrown away rather than folded into the baseline. This is the safety valve: it means a rare, spiky-but-benign event doesn't teach the model that "sudden mass change is normal for this account" — which would otherwise blind it to a real attack of the same shape later.
The one distinction to remember: Learn vs. Do not learn. Both close a false-positive alert, but only Learn teaches the model that the activity is normal. When in doubt on a large, unusual-but-legitimate event, choose Do not learn — it's the safer default, because it clears the alert without eroding the model's sensitivity to a genuine attack.
Frequently asked questions
Does this mean I was hacked?
No. An alert is an early-warning signal that something looked unusual or matched a risk indicator — not confirmation of an attack. Many alerts are legitimate activity. Treat it as a prompt to verify, not a reason to panic.
Does CyberFortress read my files or data?
No. Detection uses metadata only — sizes, counts, timestamps, settings, and (in the advanced tiers) file names. The contents of your files, emails, and documents are never read or analyzed.
Will this slow down my backups or restores?
No. Monitoring runs independently of your backup and restore jobs and has no effect on their performance.
Why did I get an alert when nothing is wrong?
Most likely a legitimate change — a migration, a policy update, a large cleanup — that looked unusual to a system still learning your account's baseline. Confirm it was expected and close it; the model learns from that.
How is this different from the inline malware detection built into Veeam Backup & Replication?
They're separate, complementary layers. Veeam Backup & Replication's inline malware detection runs on the backup infrastructure itself, inspecting data as it's backed up (see Veeam's documentation: Viewing malware detection events). CyberFortress's anomaly detection is our own monitoring of your backup behavior and protective settings across your whole service. For Managed Backup (Enhanced & Managed tiers), where Veeam's inline scanner is available, we also bring its per-recovery-point verdict into the portal as one additional indicator — so you see both Veeam's finding and our own signals in one place. Our behavioral and known-indicator detection runs regardless of whether Veeam's inline scanning applies to your service.
Coming soon: Enhanced Detection (early access)
Everything above is the foundation. We're piloting two deeper layers of protection and are looking for a small group of beta customers to try them first and help shape them. If either fits your environment, we'd love to have you in the early-access group.
🔬 Microsoft 365 Advanced Protection
Goes beyond behavioral trends to inspect the files inside your Microsoft 365 backups — Exchange, OneDrive, SharePoint, and Teams. As new and changed items are backed up, it checks them against known ransomware file extensions and ransom-note filenames — the concrete fingerprints attackers leave behind. That means we can tell you not just that something looks wrong, but what and where, down to the specific item and workload. It examines file names and metadata only; your content is never read.
🖥️ Managed Backup — Enhanced & Managed tiers
Brings detection down to the individual VM and workload level, and surfaces Veeam's own built-in malware verdict for each recovery point directly in your portal. Instead of a single signal for the whole service, you get per-machine visibility and an authoritative clean/suspicious/infected flag on every backup — so a problem on one workload stands out immediately.
Both are in early access and not yet generally available. Interested in beta testing? Reach out to your CyberFortress account team or Support to raise your hand, and we'll get you set up.
Questions?
If you're ever unsure about an alert, don't hesitate — that's exactly what we're here for. Contact CyberFortress Support, and we'll walk through it with you. When it comes to your data, we'd always rather take a look together than let something slide.