Resources

Insights, events, and proof from the field

Latest blogs, whitepapers, webinars, in-person events, podcast episodes, and customer case studies — all in one place.

Blog

Latest posts

Thought leadership, product updates, and technical deep dives from the Elastio team.

View all posts
When the Attacker Never Sleeps: How Agentic AI Is Getting Past EDR

September 25, 2026

When the Attacker Never Sleeps: How Agentic AI Is Getting Past EDR

For most of the last decade, endpoint detection and response has been a backbone of enterprise defense. The model is straightforward: put a sensor on every host, watch for suspicious behavior, detect it, and respond before the attacker can do serious damage. Built into that model, however, is an assumption we rarely had to say out loud: the attacker operates at something close to human speed. That assumption is breaking down. Agentic AI is changing the tempo of an intrusion. An agent can conduct reconnaissance, choose its next move, write or modify code, test it, evaluate the result, and try again without waiting for a person at a keyboard. In November 2025, Anthropic disclosed what it described as the first documented large-scale cyberattack executed largely by AI. According to Anthropic, a state-sponsored group used AI agents to perform roughly 80 to 90 percent of the work against approximately 30 organizations, with humans stepping in at only a handful of decision points. That was an early warning. What has come since is more concerning. In its September 2026 threat report, Anthropic described a Russian state-nexus operator using AI agents to monitor how its malware performed against security products. When tooling was detected, the agents could modify and rebuild it in an effort to evade those defenses and then put the new version back into operation. Anthropic's conclusion captures the problem: capable adversaries can now "close the loop," bypassing traditional security detections faster than defenders can develop and deploy them. That is the challenge for EDR. Detection has always involved a race between attacker and defender. Defenders identify malicious behavior, improve detections and controls, and force attackers to change what they are doing. That friction has traditionally worked in the defender's favor because adapting takes time. Attackers have to understand why something failed, modify their approach, test it, and try again. Agentic AI compresses that cycle. An agent capable of evaluating its own results and modifying its tooling can potentially accomplish in minutes what once required an attacker to stop, diagnose a problem, rewrite code, test it, and redeploy it. A detection may still work exactly as designed. The problem is that the adversary may be able to adapt to that detection almost immediately. Speed compounds the problem. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time, the window between initial access and lateral movement, at 29 minutes. The fastest it observed was 27 seconds. In one case, data was being pulled out four minutes after the attacker got in. The same report found that operations by AI-enabled adversaries rose 89 percent year over year. EDR can automatically stop some malicious activity, and that capability remains enormously valuable. But when an intrusion can move from initial access to lateral movement or exfiltration in seconds or minutes, any defensive model that depends on a human seeing, understanding, and responding to an alert is increasingly at a disadvantage. There is also a quieter side to the problem. Sophisticated attacks do not necessarily have to look malicious on an endpoint. Attackers increasingly operate through valid credentials, legitimate administrative tools, and normal cloud services. Agentic systems can make that problem more difficult by allowing an adversary to continuously evaluate an environment and adjust its behavior based on what it encounters. EDR is very good at identifying activity that looks wrong on an endpoint. It has a much harder problem when the activity itself looks legitimate and the real issue is that the person or machine performing it should not be doing it. And some of the most damaging activity may never occur on a managed endpoint at all. Attackers can pivot into unmanaged systems, cloud workloads, storage platforms, identity infrastructure, and backup environments where endpoint visibility may be incomplete or nonexistent. If the destructive activity occurs somewhere the endpoint sensor cannot see, EDR cannot be expected to provide the entire answer. None of this means EDR has failed. It hasn't. EDR remains a critical security layer and stops an enormous amount of malicious activity. But organizations need to be clear-eyed about what any detection technology can and cannot do against an adversary capable of adapting in real time. The faster attackers can observe defensive controls and modify their behavior, the less comfortable organizations should be assuming that prevention and detection will catch everything. The safer planning assumption is that something eventually gets through. That changes the question. Instead of asking only, "Did we catch the attacker in the act?" organizations also need to ask, "Do we know what the attacker did to our data?" That is where the data itself becomes one of the most reliable witnesses. An attacker can change its tools, infrastructure, credentials, techniques, and timing. It can try to make its activity resemble legitimate administration. But the consequences of destructive activity ultimately have to exist somewhere. Encryption, corruption, deletion, unauthorized modification, and other changes to data can leave measurable evidence independent of the particular malware, technique, or infrastructure that caused them. That distinction matters because defenders do not necessarily need to recognize every version of an attack to determine that the integrity of their data has changed. It matters even more when it comes to recovery. Ransomware operators understand that backups are one of the defender's greatest sources of leverage. If attackers can corrupt, encrypt, delete, or otherwise undermine recovery data before the organization realizes what has happened, they can turn a security incident into a much larger operational crisis. An agentic attacker capable of operating quickly and adapting to defensive controls is particularly well suited to attacking that recovery process. That makes continuous validation of backup and recovery data increasingly important. Organizations need to know not simply that a backup exists, but whether the data inside it is intact, whether it has been altered, and which recovery point can actually be trusted. Because recovery is ultimately where the consequences of all of this become real. Agentic AI is changing the economics and speed of cyberattacks. Defenders cannot assume they will always identify a new technique, build a detection, and deploy it before the attacker changes again. The answer is not to abandon EDR or stop trying to detect the attacker. It is to recognize that detection alone cannot carry the entire burden. Watch the endpoint, yes. But verify the data. When the attacker never sleeps, certainty about what you can recover may be the control that matters most.

Read post →

Uncovering CRPx0 ClickFix campaign and Python-based Ransomware

September 18, 2026

Uncovering CRPx0 ClickFix campaign and Python-based Ransomware

Executive Summary In August 2026, our team identified a new CRPx0 ransomware campaign that uses ClickFix-style social engineering to deliver a Python-based ransomware payload. The campaign begins with malicious HTML files that conceal the ClickFix content and eventually display a fake CAPTCHA verification page, instructing victims to open a terminal and paste a command copied from the webpage. Following execution, the campaign deploys the CRPx0 Loader, which prepares a Python environment and launches the ransomware payload on both Windows and macOS systems. The Loader also provides persistence, defense impairment, data collection, and system encryption capabilities. The campaign demonstrates a multi-stage architecture that combines several techniques to move from initial user interaction to ransomware deployment. CRPx0 uses encoded HTML content to conceal the initial delivery page, OS-specific commands to deploy the Loader, and a Python-based payload that is itself encoded and compressed. On Windows, the malware attempts to bypass UAC and terminate processes and services associated with a broad range of AV and EDR products, while persistence is established through Scheduled Tasks on Windows and Launch Agents on macOS. The malware also collects selected documents and high-value files, archives them, and sends them to attacker-controlled infrastructure before encryption. CRPx0 has also established a Ransomware-as-a-Service (RaaS) ecosystem to support the operation and scale victim acquisition through affiliates. Its affiliate offering advertises multiple capabilities, including “ClickFix Social-Engineering Delivery,” and provides affiliates with a dedicated panel for generating builds, managing operations, and reviewing payouts. This indicates that ClickFix is integrated into the group's broader ransomware service rather than being limited to a single intrusion. CRPx0 Threat Actor CRPx0 is a relatively new ransomware operation that emerged in spring 2026 and has rapidly expanded its activity, becoming one of the most active ransomware groups observed in recent months. Prior to its ransomware operations, actors associated with CRPx0 were reportedly involved in cryptocurrency-related fraud, including crypto flash-token schemes. The group has since transitioned to a RaaS model, enabling affiliates to conduct attacks and contributing to the rapid expansion of its operations. Since July 2026, CRPx0 has published 47 organizations on its leak site (hxxps://crpx0[.]su). The majority of the claimed victims are based in the United States , followed by Turkey , with the remaining organizations distributed across several other countries. While the leak-site listings represent claims by the threat actor and are not necessarily independently verified, the volume and pace of publications indicate that CRPx0 is actively expanding its ransomware operations and victim base. Figure 1: CRPx0 Ransomware data leak blog. CRPx0 operates a structured Ransomware-as-a-Service (RaaS) affiliate program, offering affiliates a 70% share of ransom proceeds. Prospective affiliates are required to apply to the program and pay a one-time $333 registration fee. The operation also imposes restrictions on targeting organizations located in CIS countries (stated on their affiliate program website), indicating a deliberate exclusion of specific regional victims from its targeting scope. To attract affiliates, CRPx0 advertises a range of attack capabilities, including “ClickFix Social-Engineering Delivery.” This capability is particularly relevant to the campaign analyzed in this report, where the threat actors leveraged ClickFix-based social engineering as an initial access and payload-delivery mechanism. CRPx0 also provides affiliates with a dedicated management panel for conducting and monitoring their operations. Through the panel, affiliates can generate ransomware builds, administer campaigns, and monitor their activities and payouts. Figure 2: CRPx0 Ransomware affiliate program. ClickFix Campaign In August 2026, CRPx0 launched a campaign employing a multi-stage infection chain designed to deliver its ransomware payload through ClickFix-based social engineering. The campaign begins with malicious HTML files and ultimately delivers the CRPx0 Loader, which prepares the Python runtime and executes the ransomware. Once deployed, the malware is capable of collecting data from compromised systems and encrypting files. The initial HTML file uses Base64 encoding to conceal its content and hinder straightforward analysis by web crawlers and security scanners. When loaded, the page decodes the embedded content and replaces the current document stream with a second HTML page containing the ClickFix lure. Figure 3: Encoded content of HTML file. The page impersonates a CAPTCHA verification mechanism and instructs the victim to open a terminal and paste a command from the clipboard. By following these instructions, the victim unknowingly executes the malicious command on their system. Figure 4: ClickFix CAPTCHA verification lure. Following successful execution, the webpage sends a notification to the C2 server (207.180.29[.]236) containing execution statistics, including the victim's operating system, unique identifier, and affiliate ID. Figure 5: Statistics sending function. The ClickFix page delivers OS-specific commands for Windows and macOS . On macOS, the command prepares a Python environment, downloads the CRPx0 Loader, and executes it as sys_service.py. On Windows, the command decodes and executes DLL, which is previously downloaded from the HTML web page. This DLL performs the equivalent setup by retrieving the required Python dependencies and launching the CRPx0 Loader as sys_service.py. This cross-platform delivery mechanism allows CRPx0 affiliates to use the same ClickFix infrastructure to deploy the ransomware operation against both Windows and macOS victims. Figure 6: Commands concealed in HTML file. CRPx0 Loader On Windows systems, the malicious DLL prepares a Python execution environment by downloading the Python runtime and required get-pip dependencies. It then executes the CRPx0 Loader, named sys-service.py, from the %TEMP%\Low_Graphics_Cache\ directory. This approach allows the malware to establish the required runtime environment on systems where Python is not otherwise installed. Figure 7: Execution of payload on Windows system. Initially, the Loader is in an encoded and compressed form. During execution, it decodes and decompresses an embedded payload, which is subsequently loaded as the main malware component. Figure 8: CRPx0 Loader encoded and compressed content. The resulting payload provides functionality for data collection and exfiltration to attacker-controlled C2 infrastructure, persistence, and EDR/AV evasion. It also contains functionality for encrypting compromised systems, including domain-wide encryption across the victim's network. Defense Impairment To evade detection and blocking by endpoint security solutions, the CRPx0 Loader implements several defense impairment techniques. The first stage attempts to bypass Windows User Account Control (UAC) and relaunch the current payload with elevated privileges. The malware creates a temporary registry entry under HKCU\Software\Classes\ms-settings\shell\open{random_suffix}\command , containing a command that launches the current Python interpreter and script. It then executes fodhelper.exe, a legitimate Windows executable that can be launched with elevated privileges without displaying a standard UAC prompt. The registry modification causes fodhelper.exe to execute the attacker-controlled command instead of its intended action, resulting in execution of the payload with elevated privileges. After a short delay, the malware removes the registry keys created during the process. Figure 9: UAC bypass function. The Loader then attempts to disable endpoint security products by terminating associated processes and services. The presence of both process and service names indicates that the malware attempts to impair endpoint protection across a broad range of security vendors rather than targeting a single product. Disabled Processes: MsMpEng.exe, NisSrv.exe, SecurityHealthSystray.exe, Sense.exe, MsSense.exe, AvastSvc.exe, AvastUI.exe, AVGSvc.exe, AVGUI.exe, avp.exe, kavfs.exe, kes.exe, ekrn.exe, egui.exe, eamonm.exe, eProxy.exe, ccSvcHst.exe, NortonSecurity.exe, SymCorpUI.exe, rtvscan.exe, McAfeeAP.exe, mfevtps.exe, mcshield.exe, masvc.exe, mfeann.exe, bdagent.exe, bdsvc.exe, bdredline.exe, SophosUI.exe, SophosFS.exe, SavService.exe, swi_service.exe, sophos_av.exe, pccntmon.exe, TmProxy.exe, TMBMSRV.exe, TmPfw.exe, tmccsf.exe, mbam.exe, mbamtray.exe, mbamservice.exe, CSAgent.exe, CSFalconService.exe, S1Agent.exe, SentinelWorker.exe, SentinelService.exe, cb.exe, CbDefense.exe, RepMgr.exe, CylanceSvc.exe, CylanceUI.exe, WRSA.exe, WRSVC.exe, WRCoreService.exe, cmdagent.exe, comodo.exe, cfp.exe, fsav32.exe, fsma32.exe, fsm32.exe, fsgk32.exe, a2daemon.exe, a2guard.exe, a2service.exe, fortiedr.exe, fortiservice.exe, forticlient.exe, Traps.exe, cytool.exe, panw_edr.exe, vprd.exe, VipreSvc.exe, VipreEndpoint.exe. Disabled Services: WinDefend, Sense, WdNisSvc, SecurityHealthService, wscsvc, MpsSvc, avast! Antivirus, AVG Antivirus, avast! Firewall, AVP, KAVFS, KES, ekrn, eamon, eProxy, Symantec AntiVirus, Norton Security, ccEvtMgr, ccSetMgr, rtvscan, McAfee McShield, McAfeeFramework, McAfeeEngineService, McAfeeAP, bdagent, BitDefender_ScanServer, BitDefender_UpdateServer, Sophos Anti-Virus, SavService, SophosClean, SophosConsole, swi_service, TmCCSF, TmProxy, TMMyWeb, TmPfw, MBAMService, MBAMAgent, S1Management, SentinelService, CSAgent, CSFalcon, CylanceSvc, WRCoreService, WRSA, cmdagent, F-Secure Software, F-Secure Network, FSGK32, EmsisoftSecurityService, EmsisoftProtectionService, FortiEDR, FortiClient, Traps, PaloAltoEDR, VipreSvc, VipreEndpoint. The Loader also implements self-deletion and cleanup functionality to remove artifacts from the compromised system. It creates a randomly named VBScript file in %TEMP%, which uses the Windows FileSystemObject to overwrite targeted files with a single space and recursively remove the targeted files or directories. Once the cleanup operation is completed, the VBScript deletes itself. Collection The CRPx0 Loader implements file collection functionality to identify and exfiltrate potentially valuable data from compromised systems. It searches the system for files matching predefined high-value keywords and file extensions, selecting up to five random documents and 10 high-value files. Document Extensions: .doc, .docx, .pdf, .csv, .xlsx, .pptx, .txt High Value Keywords: password, passwd, login, credential, secret, token, bank, wallet, crypto, bitcoin, ethereum, metamask, invoice, tax, financial, salary, payment, passport, license, ssn, social, identity, ssh, vpn, config, backup, database, db, private, confidential, key, seed, recovery, .kdbx, .keychain, .pem, .key, .env, .pfx, .p12 High Value Extensions: .kdbx, .keychain, .pem, .pfx, .p12, .p12, .env, .key, .ovpn, .keystore Skipped Directories: node_modules, __pycache__, venv, .git, AppData, Program Files, Program Files (x86), Windows, .cache, .npm, .vscode, .docker The selected files are collected into a ZIP archive named data_54b7e0_{OPERATION_ID}.zip, which is subsequently uploaded to the attacker-controlled C2 server. The use of both keyword- and extension-based filtering allows the malware to prioritize files that are more likely to contain sensitive or operationally valuable information. Persistence The CRPx0 Loader establishes persistence through platform-specific mechanisms on both macOS and Windows systems. On macOS, the malware creates a Launch Agent at ~/Library/LaunchAgents/com.apple.sync.plist . The configuration instructs macOS to execute the Python interpreter with the malware's application path when the user logs in or the Launch Agent is loaded. Figure 10: Persistence with Launch Agent function. On Windows, the Loader creates a Scheduled Task named ‘OneDrive Sync Maintenance’. The task is configured to execute the Python interpreter together with the CRPx0 Loader, allowing the malware to automatically restart after system events such as user logon. The names of persistence mechanisms on both platforms are designed to resemble legitimate system components and may help conceal the persistence mechanism. Figure 11: Scheduled Task persistence. Ransomware Functionality The Python payload contains the core local encryption routine. It begins with environment preparation, verifying the existence of a pre-generated scan report containing target files. If the required cryptography library is missing, the malware dynamically attempts to install it via pip into a temporary directory, ensuring it can execute even on stripped-down or isolated environments. For cryptographic setup, the function generates a unique, random symmetric Fernet key for the current infection session. Before encrypting any files, it aggressively attempts to send this key to the C2 server. Regardless of whether this "handshake" succeeds, it encrypts the symmetric key using a hardcoded RSA public key. This RSA-encrypted blob is later embedded into the header of every encrypted file, ensuring that only the attacker holding the corresponding private key can ever recover the symmetric key needed for decryption. Figure 12: Packet with decryption key sent to C2 server. The core encryption loop is highly optimized for speed and stealth. It reads the target file paths from the scan report, shuffles them to avoid predictable disk access patterns, and processes them concurrently using a multi-threaded ThreadPoolExecutor. To maximize speed and evade early detection, it employs partial encryption: it reads and encrypts only the first 1MB of each file, leaving the rest of the file data intact but rendering the file corrupted and unusable. It also employs anti-forensic techniques by preserving the original file's access and modification timestamps before deleting the original. Eventually, the function handles post-encryption actions and transitions to lateral movement. It alters the user's desktop wallpaper, drops ransom notes (HOW TO RECOVER.txt and HOW TO RECOVER.html) into the affected directories, and sends a final telemetry report to the C2 server detailing the encryption statistics (percentage complete, total size). The routine concludes by calling the network-wide propagation function, shifting the attack from local file encryption to active lateral movement. Next, payload implements a highly aggressive, multi-stage ransomware and worm propagation module designed to compromise an entire Active Directory domain or local network. For reconnaissance, it identifies the current domain, enumerates Domain Controllers via nltest, and discovers other network hosts using net view, local /24 subnet scanning, and ARP cache parsing to build a comprehensive list of target IP addresses. Once targets are identified, the malware attempts to encrypt files across network shares without initially needing to execute code on the remote machines. It connects to SMB port 445 on each target, enumerates accessible shared folders and recursively searches for user files. It encrypts files up to 5MB in size using the Fernet key, deliberately skipping critical system extensions (like .exe, .dll, or .sys) to prevent crashing the remote operating system. The encrypted data is written to a new file with a custom header containing the RSA-encrypted Fernet key, renamed with a specific extension, and the original files are deleted. Finally, the code attempts to copy and execute the malware payload on the discovered hosts to establish persistence and ensure the encryption process runs locally on each machine. On Windows, it uses SMB to drop the payload into the remote C$\Windows\Temp directory and executes it via wmic or scheduled tasks. On Linux/macOS, it leverages SSH keys found in known_hosts to copy and execute the payload via scp and ssh. If direct execution fails across the domain, it falls back to a viral GPO (Group Policy Object) attack by writing a malicious startup.bat script to the domain's SYSVOL share, ensuring the payload runs automatically whenever any machine in the domain boots or refreshes its policies. Throughout the entire attack, it continuously sends telemetry and status updates back to the C2 server. Figure 13: Ransom note HTML file. Outlook Despite its recent emergence, CRPx0 has already demonstrated the ability to combine ClickFix-based social engineering, cross-platform malware delivery, defense impairment, data theft, and domain-wide encryption into a single attack chain. The inclusion of “ClickFix Social-Engineering Delivery” in its affiliate offering suggests that this technique is likely to remain an important part of the group's future campaigns. At the time of our analysis, the CRPx0 Python Loader was hardly detectable by classical antivirus solutions. This increases the importance of behavioral and data-level detection, particularly for attacks that successfully bypass endpoint controls. Organizations should monitor for suspicious clipboard-based command execution, Python interpreters launched from temporary or user-writable directories, fodhelper.exe execution associated with registry modifications, attempts to terminate security products, and subsequent file collection or encryption activity. The campaign also demonstrates that endpoint detection alone may not be sufficient to prevent the impact of a successful ransomware intrusion. CRPx0 combines defense evasion with data theft and domain-wide encryption, meaning that even when the initial malware is difficult to detect, changes to organizational data and recovery points can provide an additional opportunity to identify the attack and limit its impact. Solutions such as Elastio's Ransomware Recovery and Detection can complement existing endpoint and network controls by inspecting data for ransomware activity and continuously identifying verified clean recovery points. Elastio's approach is designed to detect threats within live data, replicated data, and backups and provide evidence that recovery can be performed from a clean point. For organizations facing threats such as CRPx0, combining traditional prevention and detection controls with data-level ransomware detection and validated recovery can reduce the risk of prolonged disruption. In particular, continuously verifying the last known clean recovery point can help organizations avoid restoring compromised backups after a domain-wide encryption event. As CRPx0 continues to evolve its tooling and affiliate infrastructure, organizations should maintain layered detection capabilities while ensuring that recovery mechanisms are regularly validated and that clean recovery points remain available. Indicators of Compromise Type Value IP Address 207.180.29.236 Onion Domains tlxoddx4odmc2qvsmtsbgwwsv5j45osb5sox7mz6izxliuju5mkulzad.onion xburs4nr6cbuktokhqwefeh5hsjakz6usll5o7z5uhrfcnolakj4ptad.onion kqi5yty6ipuhwz4anutty6hob6et7dvnnxg6kcnulwedjaz5oton2zyd.onion Domains option.spark198.com crpx0.su crpxoxo.pw TOX ID 17EB54B8455144E088C7E77F88A97221C319F0CFE4FE306853EEB113EE8DB5607BB6EE481C7C Session ID 050546f6719172e04151c31acb37a242fa3eeff5766aa57331d26cc06e83e9e25b File Hashes f187b1d7d1757a1115207f0ae93130946925acb3af39cf1bf242a2443da4ded0 7e6d5f6d00c8f2cfadf3fb0c9abbb19f5e291e80729db1c839c78fa4a5bad46c 376cb49c86098078df3e7cdb563bd4ca8afa81356c4fdb098f56b59066c8cdab 28685dff00aa1752b62a8580955b2530d63092bdcc0528b872a668cddad78c11 5856f684c90dba657f5cd77dd337d81fd7503b5225e1843341c1f483eebc9560 0dc6a5ce14838813e297a83e3c3c0868c7a211ee2da9c9705e5a282e65f089fe ebb58e0cc4d8e081707f843508b13cc45c6f8c3dfff42f27c4fc4bc70493f0d7 bac340524549410f51b060f21abb7db30c0c5378edd2e3ac15b526e141417e89 8af1afc82c0d578a54cc34d09544a0695ec2b0d5f244bf1f1bb4993ee7614734 55a81d88fff3dc3de0e42724b0a992d4ef382b0e1a82187abf9d635ab89b2bae 290d41e7436238066a8aacbd63a805aeeefc00d8798116dc702eccf6df3eae37 6e59b6c75be99a538ab4c94a17698681695c7a6a2a6cf8161a5bf4bdee1299dc ef431e36a8ac12051af588d800e1d8128d583a9d4c68187709263a13564081cd 006bca7fca78e4cb9a9629c007d629d08f0ef64a58cf045860e5668b774b4539 3e70629521334cd25bd97522f8fc52703bed32e6a915c19ed741d72c9cb3b77a

Read post →

Annual DR Testing vs Continuous Recovery Validation: Why One Test a Year Is Not Enough

August 6, 2026

Annual DR Testing vs Continuous Recovery Validation: Why One Test a Year Is Not Enough

Your last DR test passed. The team picked a date, chose a backup, spun up the workloads in a recovery account, hit the RTO target, and signed the report. That report is true, and it is narrow. It proves that on the day you tested, one recovery point restored and came up. It does not prove that the recovery point you would reach for during an actual ransomware incident is free of ransomware today, or that it would restore at all. That gap is the difference between annual DR testing and continuous recovery validation. An annual test is a snapshot of a single restore path on a single date. Ransomware does not wait for the test window, and it does not respect the recovery point you happened to validate last quarter. What an annual DR test actually proves A traditional DR test answers a mechanical question: if we restore this backup, does the system come back within the recovery time objective? That is worth knowing. It exercises the runbook, the IAM roles, the network cutover, and the people who run them. AWS built this pattern into the platform. AWS Backup restore testing runs restore jobs on a scheduled cadence, monitors how long each restore takes, and lets you audit whether restores meet your target time. It restores a recovery point, confirms the restore completes, and then deletes the restored resource. That is a real control, and a scheduled restore test contributes to what regulators ask for. DORA (Regulation (EU) 2022/2554) sets digital operational resilience testing and ICT risk-management obligations that run wider than any single annual restore: a full testing programme, backup and recovery procedures, and periodic assessment of ICT systems supporting critical or important functions. An annual DR test is one input to that programme, not the whole of it. The mechanical question and the integrity question are not the same question. A restore that completes on time still tells you nothing about whether the data inside that recovery point was already encrypted, corrupted, or carrying malware when the backup was written. The three assumptions an annual test bakes in Every annual DR test carries three assumptions that hold on test day and quietly expire afterward. The date is fixed. You validated a restore on, say, March 12. An attacker who detonates on March 10 does not get the March 12 backup. They get whatever recovery points exist in August, none of which your test touched. The recovery point is chosen. Restore testing selects the latest eligible recovery point or a random one from a defined window. During a real incident you do not get to choose a known-good backup. You have to find one, under pressure, from a set that may all be contaminated. The failure mode is operational, not adversarial. DR planning grew up around hardware failure, power loss, and site outages. In those events, the data in the backup is assumed clean. Ransomware breaks that assumption. The threat is inside the recovery point. NIST names this directly. NIST SP 800-184 , the Guide for Cybersecurity Event Recovery, treats validating recovery capabilities as an ongoing discipline, not a one-time checkbox. Section 3.1 states that “exercises and tests should be performed periodically” to build real-world recovery capability. Periodic is the operative word, and it points in the same direction as continuous. NIST does not set a fixed cadence here; the annual floor that many teams actually run to comes from regulatory regimes, not from NIST. DORA (Regulation (EU) 2022/2554) and sector rules oblige regular resilience testing, and an annual test is a common way to meet that bar. But even a test that clears the regulatory minimum still validates one date; it does not track the state of a live environment where new backups are written every day. Continuous validation asks a different question every day Continuous recovery validation inverts the model. Instead of proving one restore path worked on one date, it inspects the configured recovery points on supported sources as they are written and asks whether the data inside shows signs of ransomware encryption, malware, or corruption. Elastio runs this inspection continuously and out-of-band. The Hunt Engine performs Deep File Inspection on backup data, checking for ransomware encryption, malware, and corruption without touching production systems and without agents on the protected workloads. Because it inspects configured recovery points rather than a sampled one, it can name the last-known clean recovery point across the estate it covers, including points a scheduled test would never select. Continuous does not mean instantaneous or all-seeing. There is scan latency between a backup completing and a verdict being available, so the most recent recovery point may not yet be inspected. The finding also covers only what is inspected: the data inside the recovery points and resource types in scope, reporting that no supported indicators of ransomware, malware, or corruption were detected. That is a strong signal about the data, and it is not the same as proving the workload will restore and run, which is what isolated restore testing establishes. A state Department of Public Health running on AWS described the before state plainly: the lack of verified backups meant every incident carried the risk of downtime and reintroducing threats. Their security manager compared ransomware recovery to walking a tightrope, then replaced that guesswork with continuous verification that identifies the last-known clean recovery point and when the infection started. The shift was not from slow recovery to fast recovery. It was from guessing which backup was safe to knowing. The failure mode a passing test hides Here is the scenario an annual test does not catch. Ransomware operators frequently sit in an environment for weeks before they encrypt anything, using that dwell time to disable defenses, exfiltrate data, and spread. During that window, every backup you take is a backup of a compromised environment. The malware is dormant in the data, not yet detonated. Your DR test in that window passes. The restore completes, the RTO is met, the report is green. What the test cannot see is that the recovery point it validated already contains the attacker. Restore it after detonation and you reinstall the intrusion. The timing is what defeats the annual model: the test proves a restore path on the day the calendar picked, while the recovery point that carries the infection is written on some other day the calendar never checks. A test that only measures whether the restore mechanism works will never surface that. Key Distinction This is also where “immutable” gets misread. An immutable backup cannot be altered after it is written. That protects the copy from tampering. It does nothing to prove the data was clean at the moment it was written. Immutability plus an annual restore test can produce a perfectly preserved, perfectly restorable copy of an infected system. The real axis is cadence and coverage The annual model optimizes for one recovery point, one date, one clean path. The real problem is coverage across the whole estate over time. Coverage means every workload, not the handful chosen for the test. It means every recovery point, not the latest one in a window. It means AWS Backup, EBS and RDS snapshots, DRS replicas, S3, and EFS, all inspected on the same basis, so a clean point in one data source does not create false confidence about another. JetSweep, working with a sports-equipment manufacturer on AWS, layered continuous Deep File Inspection onto AWS Elastic Disaster Recovery and AWS Backup so that every recovery point is inspected automatically, not sampled on a schedule. The disaster recovery setup already handled replication and failover. What it could not do on its own was check whether the replicated data carried hidden encryption or corruption. None of this replaces the annual test. Keep it. Exercise the people, the runbook, and the RTO. Meet the regulatory cadence. Continuous validation runs underneath it and narrows the question the annual test structurally cannot: which recovery points show no supported indicators of compromise, so the candidate you take into an isolated restore test is a clean starting point rather than a guess. This is a different axis from your RPO. RPO tells you how much data you could lose measured in time; it says nothing about whether the recovery point at that boundary is clean. Why RPO is not enough for ransomware recovery works through that distinction. Cadence and coverage of validation are the missing dimension, and an annual test does not measure either. What to change before your next test cycle If your DR program still runs on an annual proof point, the smallest useful change is to stop treating the passing test as evidence that a clean recovery point exists today. It is evidence that one restore path worked on one date. Add continuous integrity inspection so that on the day you are actually attacked, finding the last-known clean recovery point is a lookup, not a gamble. See what a continuous view of your recovery points would show Run our recovery assessment against your existing backup estate and find out which recovery points show no supported indicators of compromise. Request an Assessment Sources [1] Amazon Web Services, Restore testing , AWS Backup Developer Guide [2] NIST, SP 800-184: Guide for Cybersecurity Event Recovery , Bartock, Cichonski, Souppaya, Smith, Witte, and Scarfone, 2016 [3] European Parliament and Council, Regulation (EU) 2022/2554 (DORA) on digital operational resilience for the financial sector , 2022 [4] Elastio, Proving backup integrity for public health on AWS [5] Elastio, Proving AWS recovery readiness with JetSweep [6] Elastio, RPO is not enough for ransomware recovery

Read post →

July 29, 2026

EDR, SIEM, CNAPP, and Immutable Backups: The Ransomware Recovery Gap They Leave

In Verizon’s 2026 Data Breach Investigations Report , 69% of ransomware victims did not pay the ransom. Declining to pay shifts the response onto recovery, because the alternative to paying for the attacker’s decryption key is restoring from your own data. The DBIR shows that refusal is climbing and the median ransom paid is falling, to $139,875 from $150,000 the year before. 48% of confirmed breaches involved ransomware, up from 44% 69% of ransomware victims did not pay the ransom 31% of breaches started with vulnerability exploitation, the top entry route for the first time in 19 years 62% of breaches involved the human element The 2026 DBIR is the largest in the report’s history : more than 31,000 security incidents and over 22,000 confirmed breaches across 145 countries, covering November 2024 through October 2025. Ransomware appeared in 48% of those confirmed breaches, and the human element in 62%. Those headline numbers describe how attackers got in and what they did once inside. They do not tell you the one thing that decided how each victim’s year ended, which was whether a clean, restorable recovery point existed when the encryption started. Not paying is a recovery bet When 69% of victims decline to pay, the ransom stops being the center of the incident. Recovery becomes the lever that determines downtime, disclosure timing, and negotiating position. The criminal economics point the same way. Chainalysis tracked on-chain ransom payments falling roughly 8% to about $820M in 2025 even as claimed attacks rose by about half. That shift puts weight on a capability the DBIR cannot see. The report classifies confirmed breaches by initial vector, actor, and action. It does not record, for each victim, the age of the most recent recovery point that was verified clean and proven restorable. That number is what separates an organization that recovers in days from one that inherits the attacker’s preferred timeline. Vulnerability exploitation moved to the front, and it changes the backup question For the first time in 19 years , software vulnerability exploitation passed stolen credentials as the top way into a breach, reaching 31% of breaches . Verizon also reported that attackers are using AI to compress the time from a disclosed vulnerability to a working exploit from months to hours. Faster exploitation compresses the time defenders have to react, and backup jobs keep running between the moment of compromise and the moment it is detected. If the intrusion predates your most recent recovery point, that recovery point can contain the malware, the staged tooling, or the altered data the attacker left behind. The backup succeeded. The copy is intact. It is also unsafe to restore. Key Distinction Immutability protects a recovery point from being changed or deleted during its retention window. It does not prove the data inside that recovery point was clean when the copy was written. A locked vault full of compromised data preserves the problem precisely. Attackers reach the backups before they encrypt Targeting recovery is common enough to have its own entry in the attacker playbook. MITRE catalogs the behavior as T1490, Inhibit System Recovery , the technique for disabling or destroying a victim’s recovery options. Survey data shows how often it is attempted: in Sophos research , 94% of ransomware victims said attackers tried to compromise their backups during the attack, and 57% of those attempts succeeded. The outcome gap is the part worth taking to a budget conversation. Organizations whose backups were compromised faced a median recovery bill near $3M, against roughly $375K for those whose backups survived, and they were about twice as likely to pay. Backups also fail under pressure for reasons that have nothing to do with an attacker. In the State of Ransomware 2025 , 38% of organizations that paid more than the original demand reported their backups had failed or malfunctioned, whether from compromise, misconfiguration, or an untested restore. At decision time the cause matters less than the result: no recovery point the team can rely on. By the time encryption begins, the attacker has often already touched the backup tools your response plan is about to call. The number that decides the outcome is not in the DBIR The DBIR is a strong map of how breaches begin. It is not a recovery readiness score, and it was never meant to be. Whether declining to pay holds up depends on a number the DBIR never collected: the age of your last verified-clean, restorable recovery point for each tier-zero service. Most teams cannot produce that number on demand, because their backup dashboards report job success, not data integrity. Closing that gap means treating recovery as something you can prove, not assume. For each critical service, the useful evidence is concrete: when the most recent recovery point was confirmed free of malware and encryption, who confirmed it, whether a restore was tested against realistic conditions, and how far back an analyst would have to search to find a point written before the intrusion. That last figure depends on detecting compromise inside the backup data itself, off the production trust path, so a compromised environment cannot certify its own copies. Run that evidence forward and the first question in the runbook changes. When nearly half of breaches involve ransomware and the recovery plane is a primary target, “do we have a backup” is the wrong place to start. The question that matches the threat is which recovery point the team can defend as clean, current, and restorable, and who is authorized to act on it. Read the full research behind these numbers Our research report, Ransomware Recovery in 2026, reconciles the 2026 DBIR with Chainalysis, Mandiant, Sophos, ENISA, and four named incident cost breakdowns, then defines the recovery-assurance metrics and maturity model boards can score against. Get the 2026 Report Sources [1] Verizon, 2026 Data Breach Investigations Report, Executive Summary , 2026 [2] Verizon, Vulnerability exploitation is the top breach entry point, 2026 DBIR finds , 2026 [3] Chainalysis, 2026 Crypto Crime Report: Crypto Ransomware , February 2026 [4] Sophos, The State of Ransomware 2025 , June 2025 [5] Sophos, The Impact of Compromised Backups on Ransomware Outcomes , 2024 [6] MITRE ATT&CK, T1490: Inhibit System Recovery

Read post →

What Is Ransomware Recovery Attestation? An Elastio Framework for Documenting a Clean Restore Point

July 20, 2026

What Is Ransomware Recovery Attestation? An Elastio Framework for Documenting a Clean Restore Point

The question that ends most board cyber briefings is not “Do we have backups?” It is “How do you know you can actually recover?” The honest answer from most security teams is a backup success rate and a last DR test date. Neither one proves that the recovery point you would restore from today is free of ransomware. Recovery attestation closes that gap. A recovery attestation is documented proof that a specific recovery point passed content-integrity inspection with no supported indicators of ransomware detected, tied to an asset and a timestamp, and that its candidate clean point was confirmed by isolated restore testing. It is the evidence a CISO can put in front of a board, an audit committee, a regulator, or an insurer without reconstructing anything under deadline. Definition A recovery attestation is documented proof that a specific recovery point passed content-integrity inspection with no supported indicators of ransomware detected, tied to an asset and a timestamp, and that its candidate clean point was confirmed by isolated restore testing. This is an Elastio framework, not settled industry terminology. Regulators require you to test recovery and validate the integrity of restored data. They do not use the phrase “recovery attestation,” and no standards body has ratified it as a defined term. We use it because the market lacks a clean name for the artifact that answers the board’s real question, and because the artifact is what our platform produces after every hunt cycle. Attestation is the evidence artifact, not the capability Recovery assurance and recovery attestation are related but distinct. Our recovery assurance work is the operational capability: continuous content-integrity inspection of recovery points across live data, replicated data, and backups, paired with isolated restore testing of the candidate clean point. Recovery attestation is the artifact that capability produces. Assurance is the machine. Attestation is the receipt. A capability with no artifact cannot survive an audit. A team can run continuous validation and still fail a DORA resilience review or an insurance renewal if it has no dated, asset-level record it can hand over. Attestation is what turns an internal control into external evidence. What a recovery attestation actually contains Treat an attestation as a compliance object, not a marketing claim. To be usable as board or audit evidence, it needs concrete fields: Asset identity. The specific system, volume, database, or workload the recovery point belongs to, not a vault name. Recovery point and timestamp. Which point in time was inspected, and when the inspection ran. Verdict. Clean or compromised, with the finding detail if compromised. Method. How the verdict was reached. In Elastio’s case, Deep File Inspection by the Hunt Engine, which opens and inspects inside each file rather than reading metadata, entropy scores, or backup job status. Clean boundary. The dividing line in time between recovery points that are verified clean and those that are not, so recovery decisions have a floor. Chain of evidence. A retained log a third party can review, so the attestation is auditable after the fact. A backup success report has none of these except a timestamp. It confirms a copy completed. It says nothing about whether the data inside that copy was already encrypted or carrying a dormant payload when the job ran. Why “the backup succeeded” is not attestation The failure mode plays out the same way in most incidents. The backup jobs are green. The storage is immutable. Then the team restores a recovery point and reintroduces the same ransomware that caused the outage, because the malware was already present when that point was written. Immutability protected the copy from deletion. It never proved the contents were clean. A green job status and an object-lock flag are two facts about the copy. Neither is a verdict on the data, and a board asking whether you can recover is asking for the verdict. An attestation is worth the most when it exists before you need it. A regulated auto insurance firm running Veeam had Elastio inspecting its backups every day , so the dated clean-or-compromised record for each recovery point already existed when a compromised document surfaced inside a backup. The firm did not have to reconstruct evidence under deadline; the attestation was a standing artifact, refreshed each cycle, rather than a report someone assembles after the audit committee asks. That is the operational shape of attestation: a running record the audit request reads, already written before the request arrives. Where the evidence is actually used Recovery attestation is not a compliance requirement by name. It is the artifact that satisfies recovery-integrity expectations that already exist in the primary texts. NIST SP 800-184, Guide for Cybersecurity Event Recovery (Bartock et al., December 2016), frames recovery as a process that must be planned, tested, and improved, with recovery decisions grounded in verified system and data state rather than assumption. An attestation is the record of that verification for a given recovery point. For EU financial entities, DORA Article 12 (Regulation (EU) 2022/2554) requires documented backup and restoration procedures, ICT systems that are physically and logically segregated from the source, and data-integrity checks during recovery, including multiple checks and reconciliations. A dated, asset-level clean-or-compromised record helps satisfy that obligation by supplying evidence those checks ran, where a written procedure only shows they were planned. Under NYDFS 23 NYCRR 500 , covered entities must maintain recovery capability and, under Section 500.17, provide an annual certification of compliance. A continuous evidence log of recovery-point integrity supports that certification without reconstructing it from memory the week before it is due. The SEC cybersecurity disclosure rules (Release Nos. 33-11216; 34-97989, adopted July 26, 2023) require disclosure of a material cybersecurity incident on Form 8-K within four business days of a materiality determination, plus periodic disclosure of risk-management processes under Regulation S-K Item 106. The rules do not require recovery attestation. Attestation data may support the Item 106 risk-management disclosure by documenting the recovery-integrity process, and it can help scope impact for the incident timeline. For healthcare, HIPAA’s contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and procedures for periodic testing and revision. It does not name content inspection. Attestation records can be used to demonstrate the testing and integrity work behind that standard on an ongoing basis, not once a year. None of these rules names recovery attestation as a requirement. Each one obliges you to plan, test, or disclose recovery-integrity work, and a dated attestation is evidence that the work happened. From attestation to a board pack The board does not need the raw log. It needs a short, defensible summary drawn from it. A recovery attestation reduces to a handful of numbers a director can act on: Percentage of critical assets under continuous inspection. Age of the last-known clean recovery point for the most critical systems. Number of active threats found in recovery data this period. The clean boundary for the systems that would carry the business through an outage. Those numbers replace the two answers boards usually get, backup success rate and last test date, with a statement about whether the organization can recover to a clean state today. That is a materially different claim, and it is one the CISO can defend under questioning because it traces back to dated, asset-level evidence rather than a plan on a shelf. The gap most teams discover here is that they have the capability conversation but not the artifact. They can describe continuous validation. They cannot produce a recovery point, a timestamp, and a verdict when the audit committee asks for one specific system. If you want to see what that evidence looks like against your own environment, our Recovery Assessment runs against an existing backup estate and returns the last-known clean recovery point per service and where the gaps are. Bring the output to your next board or audit meeting and answer the recovery question with a document instead of a promise. See your last-known clean recovery point Our Recovery Assessment runs against your existing backup estate and returns the last verified-clean recovery point per service, plus where the gaps are. Bring the output to your next board or audit meeting. Run a Recovery Assessment Sources [1] NIST, SP 800-184: Guide for Cybersecurity Event Recovery , Bartock, Cichonski, Souppaya, Smith, Witte, Scarfone, December 2016 [2] European Union, Regulation (EU) 2022/2554 (DORA), Article 12: Backup policies and procedures, restoration and recovery procedures and methods , 2022 [3] New York State Department of Financial Services, 23 NYCRR Part 500: Cybersecurity Requirements for Financial Services Companies [4] U.S. Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure: Small Entity Compliance Guide , 2023 [5] U.S. Department of Health and Human Services, 45 CFR 164.308: Administrative safeguards (HIPAA Security Rule) [6] Elastio, How an auto insurance firm proved backup integrity before an attack

Read post →

June 30, 2026

The 2026 DBIR Makes Recovery Your Ransomware Plan. Can You Prove It Works?

In Verizon’s 2026 Data Breach Investigations Report , 69% of ransomware victims did not pay the ransom. Declining to pay shifts the response onto recovery, because the alternative to paying for the attacker’s decryption key is restoring from your own data. The DBIR shows that refusal is climbing and the median ransom paid is falling, to $139,875 from $150,000 the year before. 48% of confirmed breaches involved ransomware, up from 44% 69% of ransomware victims did not pay the ransom 31% of breaches started with vulnerability exploitation, the top entry route for the first time in 19 years 62% of breaches involved the human element The 2026 DBIR is the largest in the report’s history : more than 31,000 security incidents and over 22,000 confirmed breaches across 145 countries, covering November 2024 through October 2025. Ransomware appeared in 48% of those confirmed breaches, and the human element in 62%. Those headline numbers describe how attackers got in and what they did once inside. They do not tell you the one thing that decided how each victim’s year ended, which was whether a clean, restorable recovery point existed when the encryption started. Not paying is a recovery bet When 69% of victims decline to pay, the ransom stops being the center of the incident. Recovery becomes the lever that determines downtime, disclosure timing, and negotiating position. The criminal economics point the same way. Chainalysis tracked on-chain ransom payments falling roughly 8% to about $820M in 2025 even as claimed attacks rose by about half. That shift puts weight on a capability the DBIR cannot see. The report classifies confirmed breaches by initial vector, actor, and action. It does not record, for each victim, the age of the most recent recovery point that was verified clean and proven restorable. That number is what separates an organization that recovers in days from one that inherits the attacker’s preferred timeline. Vulnerability exploitation moved to the front, and it changes the backup question For the first time in 19 years , software vulnerability exploitation passed stolen credentials as the top way into a breach, reaching 31% of breaches . Verizon also reported that attackers are using AI to compress the time from a disclosed vulnerability to a working exploit from months to hours. Faster exploitation compresses the time defenders have to react, and backup jobs keep running between the moment of compromise and the moment it is detected. If the intrusion predates your most recent recovery point, that recovery point can contain the malware, the staged tooling, or the altered data the attacker left behind. The backup succeeded. The copy is intact. It is also unsafe to restore. Key Distinction Immutability protects a recovery point from being changed or deleted during its retention window. It does not prove the data inside that recovery point was clean when the copy was written. A locked vault full of compromised data preserves the problem precisely. Attackers reach the backups before they encrypt Targeting recovery is common enough to have its own entry in the attacker playbook. MITRE catalogs the behavior as T1490, Inhibit System Recovery , the technique for disabling or destroying a victim’s recovery options. Survey data shows how often it is attempted: in Sophos research , 94% of ransomware victims said attackers tried to compromise their backups during the attack, and 57% of those attempts succeeded. The outcome gap is the part worth taking to a budget conversation. Organizations whose backups were compromised faced a median recovery bill near $3M, against roughly $375K for those whose backups survived, and they were about twice as likely to pay. Backups also fail under pressure for reasons that have nothing to do with an attacker. In the State of Ransomware 2025 , 38% of organizations that paid more than the original demand reported their backups had failed or malfunctioned, whether from compromise, misconfiguration, or an untested restore. At decision time the cause matters less than the result: no recovery point the team can rely on. By the time encryption begins, the attacker has often already touched the backup tools your response plan is about to call. The number that decides the outcome is not in the DBIR The DBIR is a strong map of how breaches begin. It is not a recovery readiness score, and it was never meant to be. Whether declining to pay holds up depends on a number the DBIR never collected: the age of your last verified-clean, restorable recovery point for each tier-zero service. Most teams cannot produce that number on demand, because their backup dashboards report job success, not data integrity. Closing that gap means treating recovery as something you can prove, not assume. For each critical service, the useful evidence is concrete: when the most recent recovery point was confirmed free of malware and encryption, who confirmed it, whether a restore was tested against realistic conditions, and how far back an analyst would have to search to find a point written before the intrusion. That last figure depends on detecting compromise inside the backup data itself, off the production trust path, so a compromised environment cannot certify its own copies. Run that evidence forward and the first question in the runbook changes. When nearly half of breaches involve ransomware and the recovery plane is a primary target, “do we have a backup” is the wrong place to start. The question that matches the threat is which recovery point the team can defend as clean, current, and restorable, and who is authorized to act on it. Read the full research behind these numbers Our research report, Ransomware Recovery in 2026, reconciles the 2026 DBIR with Chainalysis, Mandiant, Sophos, ENISA, and four named incident cost breakdowns, then defines the recovery-assurance metrics and maturity model boards can score against. Get the 2026 Report Sources [1] Verizon, 2026 Data Breach Investigations Report, Executive Summary , 2026 [2] Verizon, Vulnerability exploitation is the top breach entry point, 2026 DBIR finds , 2026 [3] Chainalysis, 2026 Crypto Crime Report: Crypto Ransomware , February 2026 [4] Sophos, The State of Ransomware 2025 , June 2025 [5] Sophos, The Impact of Compromised Backups on Ransomware Outcomes , 2024 [6] MITRE ATT&CK, T1490: Inhibit System Recovery

Read post →

Podcast

Detonation Point

Conversations with investigators, CISOs, and researchers on the front lines of cybercrime.

All episodes
The Evolution of the CISO: Cybersecurity, Risk & Leadership

September 7, 2026

The Evolution of the CISO: Cybersecurity, Risk & Leadership

with Charles Blauner

Charles Blauner, a pioneer in the field and former Global Head of Information Security at Citi, draws on more than two decades leading security at some of the world's largest banks to explain why the CISO role is fundamentally about business risk — covering resilience and leadership under pressure, cybersecurity regulation, why information sharing remains harder for fraud and financial crime than for security, and the unfinished work around identity and vulnerability management as AI reshapes the landscape.

Listen on Spotify →

Thinking Like an Attacker: Red Teaming & Modern Cyber Threats

August 31, 2026

Thinking Like an Attacker: Red Teaming & Modern Cyber Threats

with William Wright, Closed Door Security

William Wright, CEO of Closed Door Security, shares stories from a career breaking into banks and critical infrastructure to show how social engineering and physical security gaps give attackers a way in — and discusses how AI is transforming cyber reconnaissance and enabling more convincing voice and deepfake scams, the risks of sharing personal information online, and the growing scale of organized scam operations.

Listen on Spotify →

Cyber Fraud, Social Engineering & Sports Talk

August 25, 2026

Cyber Fraud, Social Engineering & Sports Talk

with Stephen Dougherty, RexxField

Stephen Dougherty, now CEO of RexxField, returns with a frontline view of the evolving cyber fraud landscape — business email compromise, pig butchering and crypto scams, AI-powered social engineering, and the work of recovering stolen funds for victims — before reflecting with Matt on the nine years since they helped launch the U.S. Secret Service's Global Investigative Operations Center, and closing with some Philadelphia sports talk.

Listen on Spotify →

From Federal Cybercrime Prosecutor to Big Tech Security Leader

August 17, 2026

From Federal Cybercrime Prosecutor to Big Tech Security Leader

with Joe Sullivan

Joe Sullivan, a federal cybercrime prosecutor for nearly eight years before leading security at eBay, PayPal, Facebook, Uber, and Cloudflare, traces the evolution of cybercrime from the earliest electronic-crime investigations to the challenges facing Big Tech today — covering post-9/11 investigations, the Patriot Act, international cases, and what changes when you move from prosecuting attackers to defending against them.

Listen on Spotify →

SIM Swapping: How to Protect Your Digital Identity

August 4, 2026

SIM Swapping: How to Protect Your Digital Identity

with Mark Kreitzman, Efani

Mark Kreitzman, General Manager and co-founder of Efani, became a SIM swapping victim despite two decades building cybersecurity companies — and turned that into a mission. He explains how the attack works, why your mobile number has become the master key to your digital identity, how attackers use social engineering to bypass traditional security, and the practical steps anyone can take to protect themselves.

Listen on Spotify →

Webinars

Recent webinars

On-demand and upcoming sessions on ransomware resilience, AWS, and recovery assurance.

Webinars & events

Solution briefs

Architecture deep dives

Technical briefs on how Elastio integrates with AWS Backup, Veeam, and other platforms to deliver provable ransomware recovery.

All solution briefs