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
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

PCI DSS 4.0, Ransomware, and the Recovery Question It Leaves Open

June 30, 2026

PCI DSS 4.0, Ransomware, and the Recovery Question It Leaves Open

Ransomware lands in the cardholder-data environment. PCI DSS told you to segment it, log it, and protect the stored account data. It did not tell you how to prove you can bring that environment back clean. It is the gap a ransomware event walks straight through. PCI DSS 4.0 is a strong control standard for protecting cardholder data at rest and in transit. It is comparatively quiet on whether you can recover that data after an attack, and quiet in a way that stays invisible until you are mid-incident. What PCI DSS 4.0 does cover The current standard, PCI DSS v4.0.1 , was published in June 2024 as a clarifying revision, and the future-dated requirements from v4.0 became mandatory for all applicable entities on 31 March 2025 . Several of its requirements touch the ransomware lifecycle: Requirement 12.10 mandates an incident response plan that is implemented and tested, so the team has a defined way to respond when the CDE is affected. Requirement 3 protects stored account data through encryption and key management. Requirement 10 logs and monitors access to cardholder data and systems. Requirement 11 requires regular testing of security, including change and tamper detection. These are real controls and they do useful work. They reduce the odds of an intrusion and improve the odds you notice one. Where the standard goes quiet What the standard does not do is require you to prove that the cardholder-data environment can be restored from a recovery point known to be clean. Requirement 12.10 is about responding to an incident. It is not a mandate to validate that your backups of the CDE are free of the attacker before you rely on them. This is not a criticism of the standard’s intent. It is a precise statement of scope. PCI DSS is built to protect cardholder data and keep it out of the wrong hands. Provable recovery of that data after a destructive attack sits at the edge of what it asks for, which leaves the decision, and the risk, with you. Requirement 12.10 does ask you to test the incident response plan, which exercises the response process. It does not require you to attempt a restore and confirm the recovered cardholder-data environment is free of the attacker, which is the test that actually predicts whether recovery works. PCI DSS protects cardholder data. It does not prove you can bring it back clean. The recovery problem is bigger than the assessed CDE PCI DSS lets you shrink the assessment by segmenting the cardholder-data environment away from the rest of the network. That scoping is a sound way to reduce audit burden. It is not a boundary ransomware respects. If an intruder gets a foothold, restoring the CDE often depends on systems that sit outside the assessed scope: directory services, DNS, hypervisors, and the backup infrastructure itself. A clean CDE restore that has nowhere trustworthy to land is still a failed recovery. The recovery question is wider than the boundary the assessment drew. Why the gap bites in a ransomware event Here is where the quiet requirement gets loud. An attacker reaches the CDE and dwells before detonating. Your backups of that environment keep running, and they capture the intrusion along with the data. When you restore, the recovery point you reach for may already contain the attacker’s foothold, the staged tooling, or partially encrypted data. Bringing it back re-introduces that exposure into the environment that holds account data. The result is a fresh cardholder-data problem on top of the outage. Blind vs. evidenced A restore decision made blind versus made with evidence looks like this. Blind: the team picks the newest backup of the CDE, restores it, and hopes the intrusion is not in it. Evidenced: the team picks the newest recovery point that has been inspected and confirmed free of ransomware, restores it, and can show the QSA why that copy was safe. Same backup estate, opposite risk posture. Closing the gap without waiting for the standard You do not have to wait for a future revision to address this. The move is to treat the CDE’s recovery points the way you treat its access: as something to verify, not assume. Inspect the recovery points for the cardholder-data environment for ransomware and unauthorized encryption. Keep a named, most-recent clean copy per critical system. Hold the evidence so it is ready when a QSA, or an actual incident, asks for it. Knowing where that data actually lives is the first move, since cardholder data tends to sprawl beyond the assessed CDE; data classification finds the account data sitting where it should not be. Because cardholder data can live in object storage, securing Amazon S3 data against ransomware is a practical starting point for where that inspection has to reach. Treating CDE recovery points as something to prove rather than assume is the discipline What Is Recovery Assurance? describes. Could you prove your CDE recovery point is clean? Pick the systems inside your CDE and ask one question: could you hand a QSA evidence that the recovery point you would restore is clean? A Recovery Posture Assessment shows you where the gap is before an attacker does. Run a Recovery Posture Assessment Sources [1] PCI Security Standards Council, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x . Future-dated v4.0 requirements mandatory 31 March 2025 [2] PCI Security Standards Council, Document Library (PCI DSS v4.0.1) . Requirements 3, 10, 11, and 12.10; v4.0.1 published 11 June 2024 [3] Elastio, Securing Amazon S3 Data Against Ransomware Attacks [4] Elastio, What Is Recovery Assurance? [5] Elastio, Recovery Posture Assessment [6] Elastio, Data Classification: Sensitive Data as a Threat Finding

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