A finance controller at an international organization noticed a large payment hadn’t arrived. That single observation unraveled a fraud that had been running, quietly and patiently, for more than two months, and had already moved roughly a million euros to accounts the organization didn’t control.

How the Attack Unfolded

It started with an ordinary-looking phishing email sent to multiple staff. One employee clicked the link and entered their login credentials into a fake portal. The organization had multi-factor authentication in place. The attacker got in anyway, using the harvested credentials to access the mailbox of the finance controller directly.

Then, for three weeks, nothing visibly happened. The attacker wasn’t stealing money yet. They were reading. They studied how invoices were sent, who approved payments, and critically, how the company handled requests to change a supplier’s bank account details, learning the organization’s own “new supplier form” process well enough to use it convincingly later.

On day 21, the attacker made their move, but not by inventing a fake invoice from scratch. They waited for the real finance controller, still completely unaware their account was compromised, to send a legitimate invoice to a real client. Right after, the attacker followed up from the same real account with updated bank details, routing the payment to an account they controlled. Investigators later described this as attackers exploiting the organization’s own legitimate workflow rather than trying to fake one from outside.

The attacker tried to expand twice more, attempting to compromise additional employee accounts on days 23 and 28. Both attempts failed. It didn’t matter. By day 44, fraudulent payments were already flowing to attacker-controlled accounts across multiple parts of the organization. Nobody noticed until day 72, when a payment simply didn’t show up where it should have, and someone finally asked why.

Why This Matters If You’re Not a Big Company

The number that should concern any business here isn’t the million euros. It’s the 72 days. That’s how long a fully functional, MFA-protected email account sat compromised, with an active attacker inside it, before a human noticed anything was wrong, and only because a payment failed to arrive rather than because any system flagged the intrusion itself.

This also wasn’t a poorly run finance department. The fraud worked precisely because it rode on top of a legitimate process the company already had, a real invoice, from a real account, followed by what looked like a normal correction. Attackers increasingly aren’t inventing fraud from nothing; they’re patiently learning a real business’s actual workflow and then inserting themselves into it at the exact right moment.

What Actually Would Have Stopped This

Two separate gaps allowed this to run as long as it did, and closing either one alone would have limited the damage significantly. The first is detection: continuous monitoring of the mailbox, watching specifically for new logins, unusual mailbox rules, and unfamiliar locations, would very plausibly have caught the initial compromise within minutes rather than weeks. Security researchers involved in the case estimated that with active monitoring in place, the account takeover could have been detected within about ten minutes of the first suspicious login.

The second gap is procedural, and it’s the one within full control of any business regardless of budget: a dual-approval requirement for changing anyone’s banking details, sometimes called a four-eyes rule, where a second person independently confirms any change to payment instructions, ideally by phone, using a number already on file rather than one in the email. That single process change would have stopped this fraud even with the mailbox still fully compromised.

Security Checklist for Your Business

• Require independent verification for any change to banking or payment details, by phone, using a previously known number, never a number or reply provided in the email itself.

• Monitor mailbox activity continuously, especially new inbox rules, forwarding changes, and logins from unfamiliar locations or devices.

• Treat MFA as a strong layer, not a guarantee. This organization had MFA and was still compromised through a convincing fake login page.

• Reconcile payments against original invoices promptly, rather than only noticing when a payment is overdue.

None of this requires a large security budget. It requires one hard rule around changing payment details, and eyes actually watching mailbox activity instead of assuming MFA has it covered. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Eye Security, “When Business Email Compromise Nearly Costs a Million: An Incident Response Story”.

In mid-May 2026, security researchers scanning the internet for exposed systems found something that shouldn’t have been reachable at all: a database belonging to Nextcloud, a major European cloud collaboration company, sitting fully open on the public internet with no authentication required. No password. No login screen. Anyone who found the address could browse straight in.

How the Attack Unfolded

Inside was roughly 367,000 records totaling about 8 gigabytes: staff email addresses, client company names and addresses, customer contracts, invoice-related correspondence, and internal scripts the company had built for specific clients. Some of it, notably, sat completely unencrypted, meaning sensitive contact details were readable the moment anyone opened the file.

The company traced the cause to what it called a misconfiguration of its hosting infrastructure, not a flaw in its actual product. Once notified, Nextcloud secured the exposed database within two days. The incident became public roughly two months later.

Why This Matters If You’re Not a Big Company

It’s tempting to read a story about a major cloud company and assume the lesson doesn’t apply to a smaller business. It’s actually the opposite. This wasn’t a sophisticated hack. Nobody breached a firewall or exploited a zero-day vulnerability. A database was set up, and at some point in that setup, a setting that should have required a login was left open, the same category of mistake that happens constantly when any business spins up a new cloud service, a new database, or a new file share and moves fast to get it working.

The researchers who found it made the uncomfortable point directly: if their team found the exposed data through routine scanning, malicious actors likely could too, because bots scanning the internet for exactly this kind of misconfiguration run constantly, at scale, with no target list required. An open database doesn’t need to be found by someone looking for you specifically. It just needs to be found.

What Actually Would Have Stopped This

The fix here isn’t exotic. It’s a review step that many businesses skip specifically because cloud services feel like someone else’s responsibility to secure once you’ve signed up. They aren’t. Every cloud database, storage bucket, or search index a business spins up needs its access settings explicitly verified as private, not assumed private by default, because defaults vary by provider and by service, and a single missed checkbox is functionally identical to leaving a filing cabinet unlocked in a public lobby.

The second piece is routine, ongoing scanning of your own external footprint. The same techniques researchers and attackers use to find exposed systems are available to run against your own organization proactively, and catching a misconfigured database yourself, before anyone else finds it, is the difference between a quiet fix and a public disclosure.

Security Checklist for Your Business

• Explicitly verify access controls on every cloud database, storage bucket, and search index, don’t assume a service is private by default.

• Encrypt sensitive data at rest, not just in transit, so a misconfiguration exposes far less even when it happens.

• Run regular external exposure scans against your own domains and cloud infrastructure to catch what an attacker’s scanner would find first.

• Review access settings any time a new cloud service is stood up, especially ones spun up quickly to solve an immediate problem, since speed is exactly when this kind of setting gets missed.

None of this requires enterprise tooling or a dedicated security team. It requires treating “is this actually private” as a question to verify, not assume, every time something new gets connected to the internet. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: TechRadar Pro, “Nextcloud Leaks 367K Records — European Cloud Giant Exposes Staff and Clients in Major Breach”.

What a New SMB Cybersecurity Report Found

CrowdStrike’s 2025 State of SMB Cybersecurity Report set out to measure the gap between how prepared small and mid-size businesses think they are and how prepared their budgets actually make them. The numbers land on two very different sides of that line. Ninety-three percent of SMBs consider themselves knowledgeable about cybersecurity risks, and 83% say they have a cybersecurity plan in place. On paper, that looks like a confident, well-prepared population of businesses.

Then the report asks about money, and the confidence evaporates. Only 36% of SMBs are actually investing in new security tools, and just 11% have adopted AI-powered defenses, the kind of tooling increasingly needed to keep pace with automated attacks. Most strikingly, only 6.5% of SMBs believe their current cybersecurity budget is actually sufficient. That’s not a company here or there feeling stretched. That’s the overwhelming majority of small and mid-size businesses in the survey knowing, in plain terms, that what they’re spending doesn’t match what they need.

The smallest and often fastest-growing businesses come out worst. Among SMBs with fewer than 50 employees, more than half allocate less than 1% of their annual budget to cybersecurity, and only 47% have a security plan at all, well below the 83% average across the broader SMB population. When it comes to actually choosing tools, 67% of SMBs prioritize affordability over protection against advanced threats, which only 57% ranked as a top priority. That’s a rational response to a real budget constraint, and also exactly the kind of tradeoff that leaves gaps.

Those gaps show up as incidents. Among SMBs with fewer than 25 employees that experienced a security incident, 29% involved ransomware, compared with 19% among larger SMBs. Smaller, leaner organizations, the ones most likely to be adding headcount, opening new locations, and growing revenue without a matching IT buildout, are getting hit by the most disruptive category of attack at a higher rate than their larger peers.

Why This Matters If You’re Not a Big Company

None of this is a story about companies that ignore security. It’s a story about companies that plan for it on paper and then can’t fund it in practice, which describes a lot of growing small and mid-size businesses. You hire five people this quarter, open a second office, add a new line of business, and your revenue climbs. Nobody sits down and asks whether the IT budget needs to climb along with it, because IT spending doesn’t announce itself as urgent the way payroll or rent does. It just quietly falls further behind the size of the company it’s supposed to protect.

That’s exactly the pattern the CrowdStrike numbers describe: a company with a real plan and real awareness, but a budget that was set for a smaller, simpler version of itself. Every new employee is another endpoint, another set of credentials, another person who can click the wrong link. Every new location is another network to secure. If the budget doesn’t grow with the business, the business is effectively getting less secure every quarter, even while everyone involved believes they’re doing the right things.

What Growing Businesses Should Do Instead

The fix isn’t a bigger budget for its own sake, it’s a budget that’s tied to something that actually changes as the company changes, like headcount, locations, or revenue, and gets reviewed at the same cadence as those numbers. A company that reviews its IT and security spending only when something breaks is, by definition, always reviewing it too late. Tying that review to a regular planning cycle, quarterly for fast-growing companies, at minimum annually for everyone else, keeps the budget from quietly falling behind the business it supports.

It also helps to separate “do we have a plan” from “can we actually execute the plan,” since the CrowdStrike data shows those two things diverging badly. A written policy that nobody funded isn’t protection. If affordability is genuinely the deciding factor in every tool purchase, that’s worth saying out loud to whoever owns the budget, rather than letting it stay an unstated assumption that shapes every decision by default.

Security Checklist for Your Business

• Tie your IT budget to growth metrics. Set a rule, like a percentage of revenue or a per-employee amount, and revisit it every time headcount, locations, or revenue changes materially.

• Separate having a plan from funding a plan. A written security plan with no budget behind it protects nothing; check that the two actually match before you count on either.

• Prioritize protection alongside affordability, not affordability alone, when comparing tools, especially the smallest, fastest-scaling businesses where budgets are tightest.

• Review spending on a schedule, not a trigger. Waiting for an incident to reassess IT investment means the reassessment always comes after the damage is done.

The uncomfortable finding in this report isn’t that small businesses lack a plan. It’s that almost none of them believe their budget can actually support the one they have. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: CrowdStrike, “CrowdStrike Unveils State of SMB Cybersecurity Report: High Awareness, Lagging Protection”.

What the Data Shows

Every year, Flexera surveys IT and finance leaders for its State of the Cloud Report, and for five years running, the trend line on wasted cloud spend had been heading in the right direction. That streak broke in the 2026 report: estimated wasted cloud spend on infrastructure and platform services (IaaS and PaaS) climbed to 29%, the first increase in five years. In plain terms, almost a third of the money organizations are putting into cloud infrastructure is going toward resources that deliver nothing back — unused capacity, oversized instances, orphaned storage, and services nobody remembered to turn off.

The report ties the reversal directly to how fast AI adoption is moving. Cloud-based AI workloads are surging, and Flexera notes that “AI workloads behave differently than traditional cloud services, making visibility, governance and financial controls harder — but more essential — than ever.” Teams are standing up GPU-heavy workloads, new PaaS and SaaS tools, and experimental AI projects faster than their existing cost-tracking processes can keep up with, and the waste number is the receipt.

It’s not a new problem, just a worsening one. Flexera’s 2021 report already found organizations running over their public cloud budgets by an average of 24%, with wasted spend estimated around 30% even then. What’s changed is the scale: the 2026 report found 76% of large enterprises now spend more than $5 million a month on cloud services, meaning even a modest percentage of waste translates into real money fast. And across company sizes, 85% of respondents said managing cloud spend is their top challenge — ahead of security and ahead of managing software licenses, which is a notable thing for an industry that spends a lot of energy talking about security first.

None of this requires a breach, an outage, or a single dramatic “bill shock” headline to matter. It’s the slow, unglamorous kind of cost problem: nobody sets out to waste 29% of a cloud budget, it just accumulates one un-monitored resource, one forgotten test environment, and one “we’ll clean that up later” at a time.

Why This Matters If You’re Not a Big Company

It’s easy to read “$5 million a month” and assume this is purely an enterprise problem. It isn’t. The mechanics that produce that 29% waste figure — resources provisioned and never right-sized, services left running after a project ends, nobody clearly owning the monthly cloud bill — show up at any scale. A 20-person company running its email, backups, line-of-business software, and a couple of AI-powered tools in the cloud can waste the same percentage of its budget as a Fortune 500 company; it’s just a smaller number that’s easier to not notice, because nobody’s finance team is scrutinizing a $400 monthly overage the way they would a $400,000 one.

That’s actually the more dangerous version of the problem for a small or mid-size business. A big enterprise has a FinOps team whose entire job is watching this. A smaller business usually doesn’t have anyone watching it at all — the cloud bill just gets paid, and it creeps up a little every renewal cycle without anyone asking why. Multiply “managing cloud spend is our top challenge” (which 85% of organizations of every size said) by a business with no dedicated person tracking it, and the waste doesn’t get caught until someone finally looks at a year of invoices side by side.

What Businesses Should Do Instead

The fix isn’t exotic — it’s the same governance discipline Flexera’s report points to, just scaled down to fit a smaller IT footprint. Start with a straightforward inventory: what cloud and SaaS services are you actually paying for right now, and does someone specific own reviewing that list on a schedule? Most cloud waste isn’t malicious or even careless in the moment — it’s a resource that made sense when it was set up and was never revisited. A quarterly review that asks “do we still need this, and is it sized right” catches most of it.

Pair that with basic alerting. Every major cloud provider offers budget alerts and cost anomaly detection at little or no extra cost — the tools exist, they’re just frequently never turned on. And before adding new cloud or AI tools, it’s worth asking the boring question up front: who is responsible for this bill going forward, and where does it get reviewed? That single ownership question prevents more waste than almost any tool.

Security Checklist for Your Business

• Inventory every cloud and SaaS subscription. List what you’re actually paying for and assign someone to review it quarterly.

• Turn on budget alerts and anomaly detection. Most cloud providers include this at no extra cost — it just has to be switched on.

• Right-size and retire unused resources. Oversized instances, idle test environments, and orphaned storage are the most common sources of waste.

• Name an owner for every new cloud or AI tool. Before adopting anything new, decide who reviews its cost and usage going forward.

Cloud waste rarely announces itself with a single bad bill — it builds quietly until a year of invoices tells the real story. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Flexera, “Flexera Finds Cloud Value is Rising While AI Waste Grows”.

It started as one of the most common attack patterns there is: someone exposed a Remote Desktop (RDP) server directly to the internet, and an attacker began systematically guessing passwords against it. Security analysts at Huntress caught the activity through an unusual signal, domain enumeration commands running on the network, and traced it backward to find the login had actually succeeded, one account out of several that were targeted.

How the Attack Unfolded

What the attacker did next was notably unsophisticated in a way that made it easier to catch: rather than using automated credential-hunting tools, they opened Notepad and manually searched through files on the compromised system that looked like they might contain saved passwords. Forensic analysts later reconstructed this activity through the system’s jumplist records, effectively a log of recently opened files, which showed a methodical, manual search through anything password-themed.

Investigators also noticed the compromised account had been logged into from multiple, geographically distributed IP addresses, a signal of shared or rented attacker infrastructure rather than a single individual working alone. Pulling that thread led to something bigger: a network of domains including one directly linked to the Hive and BlackSuit ransomware operations, alongside supporting infrastructure disguised as a legitimate VPN service and other consumer-facing services. Analysts noted the domain naming convention itself echoed language associated with “big game hunting,” industry shorthand for deliberately targeting larger, higher-value organizations for ransomware deployment.

In this case, the network was isolated before ransomware was actually deployed. But the infrastructure uncovered behind it pointed to something worth every business understanding: a functioning marketplace where one group’s entire job is breaking in and selling that access to someone else’s ransomware operation.

Why This Matters If You’re Not a Big Company

The specialization here is the real story. Initial access brokers don’t need to know anything about ransomware, extortion negotiations, or data theft. Their entire business is finding exposed, poorly defended entry points, like an RDP server open to the internet with a guessable password, and selling that foothold to whoever wants it, often a completely separate criminal group running the actual ransomware operation.

That division of labor means an exposed RDP server with weak credentials isn’t just a risk on its own; it’s inventory in someone else’s supply chain, and it will be found by scanning, not by anyone researching your company specifically. Size doesn’t factor into whether a scanner finds an open RDP port. It only factors into what happens after someone buys the access.

What Actually Would Have Stopped This

The starting point is the most straightforward fix in this entire series: RDP should never be directly exposed to the open internet. It should sit behind a VPN or a Zero Trust access solution requiring authentication before RDP is ever reachable at all, with multi-factor authentication on that access layer specifically. That single architectural change removes the exact door this entire chain walked through.

Beyond that, this case is also a good example of logging working exactly as intended, even when it’s noisy. The analysts specifically noted that failed login attempts fill up log channels in large volumes, which can make it tempting to ignore them. Here, that same noisy log data, properly reviewed, was what surfaced the successful compromise and led to the broader infrastructure discovery before ransomware got deployed.

Security Checklist for Your Business

• Never expose RDP directly to the internet. Require VPN or Zero Trust access with MFA before RDP is reachable at all.

• Use unique, strong passwords and MFA on every remote access point, not just the ones that feel highest-risk.

• Actually review failed login patterns, rather than treating high log volume as noise to ignore. A string of failures followed by a success is a specific, detectable pattern.

• Isolate quickly on suspicious activity. In this case, network isolation before ransomware deployment was what kept a compromise from becoming an incident.

An exposed RDP server with a weak password isn’t a small risk because it seems old and well-known. It’s exactly the kind of opening a specialized criminal supply chain is built to find and sell. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Huntress, “Brute Force or Something More? Ransomware Initial Access Brokers Exposed”.

The Guest Who Never Checked Out

In September 2016, Marriott closed its acquisition of Starwood Hotels & Resorts, folding brands like Sheraton, Westin, and W Hotels into its portfolio and creating the largest hotel company in the world. What Marriott didn’t know at the time was that it had also acquired an intruder. According to Marriott’s own disclosure, attackers had been inside Starwood’s guest reservation database since 2014, two full years before the acquisition even closed.

The intrusion stayed hidden through the entire deal and for two more years after it. It wasn’t until September 8, 2018, that an internal Marriott security tool flagged a suspicious attempt to access the reservation database, using legitimate administrator credentials. Investigators who dug into that alert found a Remote Access Trojan and the credential-theft tool MimiKatz, which together had given the attackers ongoing control of an administrator account. It took Marriott until November 2018 to decrypt what had been taken and understand the scope, and the company went public with the breach on November 30, 2018.

The scale was staggering: up to 500 million guest records, including passport numbers and payment card data. The details of how that data was stored made things worse. Encryption keys for the payment card data were sitting on the same server as the encrypted data itself, and the majority of passport numbers had simply been saved in plain text, not encrypted at all. This wasn’t a sophisticated new attack technique defeating strong defenses. It was a years-old compromise sitting on top of years-old security shortcuts, and it had been there the entire time Marriott’s due diligence team was evaluating the deal.

None of this was Marriott’s doing in the sense that its own engineers didn’t build the vulnerable system. But Marriott inherited it anyway, along with the legal, financial, and reputational exposure that came with it. The breach eventually led to regulatory penalties in multiple jurisdictions and a multistate U.S. settlement of $52 million, on top of Marriott’s own remediation and legal costs. The attacker had already checked in years before the acquisition. Nobody checked the guest list before signing the deal.

Why This Matters If You’re Not a Big Company

It’s easy to read this and think “that’s a Fortune 500 problem.” It isn’t. Small and mid-size businesses acquire other small businesses, get acquired themselves, and merge operations with partners constantly, buying out a competitor, absorbing a smaller shop, combining back-office systems after a merger. The dollar amounts are smaller, but the mechanics are identical: you’re taking on someone else’s IT environment, their vendor relationships, their old software, and whatever has been quietly living in their network, sometimes for years.

The difference is that a company the size of Marriott at least ran some due diligence, and a hidden, well-concealed compromise still slipped through. Most small business deals run none at all. IT and security review rarely make the checklist next to financial audits and contract review, because nobody thinks to ask, or nobody on the deal team knows what to ask. That gap doesn’t get smaller just because the company is smaller. If anything, it gets bigger, because small businesses are less likely to have monitoring in place that would have caught an intrusion in the first place, acquired or not.

What Actually Would Have Stopped This

Real IT due diligence during an acquisition isn’t a box to check, it’s an actual technical review: bringing in someone to look at the target company’s network for signs of existing compromise, not just asking their IT contact if everything is fine. That means checking for unusual administrator activity, unfamiliar remote access tools, unpatched systems, and data that’s stored or encrypted improperly, the exact category of issue that let Marriott’s attackers move payment card data and its encryption keys off the same server for two years without anyone noticing.

It also means treating the acquired environment as untrusted until it’s been reviewed, rather than plugging it straight into your existing network and inheriting whatever risk comes with it. A compromise assessment before close, and continued monitoring immediately after, would have given Marriott a real shot at catching this years earlier than a suspicious database query eventually did on its own.

Security Checklist for Your Business

• Treat IT review as a deal requirement. Any acquisition or merger, no matter the size, should include a technical security assessment before you sign, not after.

• Assume the target’s network could already be compromised. Have someone actually look for signs of intrusion rather than taking a verbal assurance at face value.

• Isolate before you integrate. Keep an acquired company’s systems segmented from yours until they’ve been reviewed and cleaned up, not connected on day one.

• Check how sensitive data is actually stored. Encryption only helps if the keys aren’t sitting next to the data they protect, and unencrypted data in the clear defeats the purpose entirely.

Acquisitions move fast, and IT due diligence is one of the easiest things to skip when everyone’s focused on the financials. Marriott’s experience shows how expensive that shortcut can get, even for a company with real resources behind it. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: CSO Online, “Marriott data breach FAQ: How did it happen and what was the impact?”.

What Happened

In July 2008, Terry Childs was the network administrator responsible for FiberWAN, the network connecting hundreds of San Francisco city and county departments and buildings, including police records and payroll systems, back to a central data center. When a dispute with his supervisors came to a head, Childs refused to hand over the network’s administrative passwords, even when his managers asked him directly on an open conference line.

This wasn’t a hypothetical “what if the IT person won’t cooperate” scenario — it played out inside a city government with real consequences. According to Network World’s coverage of Childs’s criminal trial, he had configured the network’s routers to store their settings in memory rather than on their hard drives, meaning the devices would lose their configuration entirely if they ever lost power, making any workaround around him dramatically harder. A juror on the case, himself a network engineer, summed it up: “The city was denied access to the network. He knew the steps he was taking were creating a perfect storm.”

For roughly 12 days, city officials had no administrative access to the network carrying their own government’s data. Then-Mayor Gavin Newsom later testified that the city had been “in peril,” with officials cut off from police records and payroll data because the one person who held the keys wouldn’t hand them over. Recovering control cost the city roughly $900,000. Childs was ultimately convicted of a felony count of denying computer services, sentenced to four years in prison, and later ordered to pay nearly $1.5 million in restitution.

The most uncomfortable detail to come out of the trial wasn’t really about Childs at all. A juror who worked in networking told reporters that city IT management had “done everything wrong” in letting one employee become the sole holder of that much access, with no shared documentation and no one else who could step in. It didn’t take a hacker breaking in from the outside. It only took one employee and one bad afternoon.

Why This Matters If You’re Not a Big Company

San Francisco had an entire IT department, and the crisis still came down to one person holding knowledge nobody else had. Most small and mid-size businesses don’t have that department — they have one IT employee, or a two-person team, or an owner who’s been quietly acting as the de facto sysadmin for years. The gap this case exposes isn’t really about malice; it’s about what happens when critical access, passwords, and system knowledge exist in exactly one place. Whether that person is uncooperative, unreachable, out sick, or simply gives two weeks’ notice, the effect on the business is the same: nobody else can get in.

For an SMB, that single point of failure usually isn’t a dramatic standoff — it’s a router nobody remembers the login for, a domain registrar account tied to a personal email address that left with the employee, or a backup system only one person ever configured. It doesn’t need a courtroom to become a serious problem. It just needs that person to be gone when something breaks.

What Actually Would Have Stopped This

The fix here isn’t more trust in the IT person — it’s less dependence on any single one. Administrative credentials for core systems (network devices, domain registrars, cloud consoles, backup platforms) belong in a shared password manager with role-based access, not in one employee’s head or personal notes. At least one other person, whether that’s an owner, a second staff member, or an outside partner, should be able to get into every critical system without needing that specific individual available.

Documentation is the other half of it. A basic, current, written record of what systems exist, where they live, and how they’re accessed turns a single point of failure into something any competent person can pick up. It doesn’t need to be elaborate. It needs to exist somewhere more than one person can reach.

Security Checklist for Your Business

• Store admin credentials centrally. Put passwords for network gear, domain registrars, and cloud accounts in a shared business password manager, not one person’s memory or personal files.

• Give at least two people access. Every critical system should have a second authorized person, internal or outside, who can get in if the primary person is unavailable.

• Keep basic infrastructure documentation current. A simple written record of what exists and how to reach it is worth more during a crisis than anyone’s tribal knowledge.

• Review access when roles change. Update shared credentials and permissions whenever an IT employee’s role shifts, not just when they formally leave.

A city with a full IT department still lost control of its own network because access lived in one person’s head. For a business with one IT employee, that same gap is even easier to fall into — and even more disruptive to close after the fact. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Network World, “Admin who kept SF network passwords found guilty”.

What the Data Shows

When offices shut down in 2020, businesses everywhere did the same thing in a hurry: they stood up VPN access for anyone who needed to work from home, then kept adding more of it as hybrid schedules became permanent. Four years later, Zscaler’s ThreatLabz 2024 VPN Risk Report, based on a survey of more than 600 IT, security, and networking professionals, put a number on what that left behind. Fifty-six percent of organizations said they’d experienced a cyberattack that exploited VPN vulnerabilities in the past year, and 91% said they were concerned that a VPN could lead to a compromising breach.

The report’s most telling finding isn’t about attacks that already happened, it’s about the access sitting there waiting to be misused. Because VPNs are built to hand out full network access once a login succeeds, 92% of respondents said they were specifically worried about third parties with VPN access, contractors, vendors, former partners, acting as backdoors into systems those third parties had no real reason to reach. That’s not a hypothetical edge case. It’s the design of the tool: a VPN doesn’t usually ask what a user actually needs to touch, it just puts them on the network and lets internal routing sort out the rest.

The consequences of that design show up in the breach data too. Among organizations that were actually compromised through a VPN vulnerability, 53% reported that attackers moved laterally once inside, spreading from the entry point to other systems on the network. That’s a direct result of the same broad-access problem: a single compromised VPN account isn’t a single-system problem, it’s a foothold that can reach almost anywhere the network allows.

None of this describes a single dramatic incident. It describes an accumulated condition, one that built up gradually as businesses added remote access faster than they audited it, and it’s exactly the kind of risk that doesn’t show up until someone goes looking for it.

Why This Matters If You’re Not a Big Company

It’s tempting to read a survey like this as an enterprise problem, since large organizations have more VPN concentrators, more contractors, more moving parts to lose track of. But the underlying dynamic scales down just as easily. A ten-person business that went remote in 2020 likely set up VPN or remote-desktop access for employees, maybe a vendor who helped with the transition, maybe an old contractor who did a project two years ago. Small businesses don’t run identity audits on a schedule the way larger IT departments do, which means that access is more likely to still be there, not less.

The math is simple and unflattering: fewer people means fewer eyes on who still has a login, and a smaller IT footprint often means nobody owns the job of periodically checking. An account that was reasonable to create in 2020 doesn’t announce itself as unreasonable in 2026. It just sits there, working exactly the way it was set up to work, until someone other than its intended user finds it.

What Actually Would Have Stopped This

The fix isn’t a single tool, it’s a mindset shift: access should be reviewed on a schedule, not left to exist until someone remembers to remove it. That means a recurring check, quarterly is reasonable for most small businesses, of who has VPN or remote access, whether they still need it, and whether that access grants more of the network than their actual job requires. A departing employee or a finished vendor contract should trigger an access removal the same day, not whenever someone happens to notice.

The deeper fix is moving away from the assumption baked into traditional VPNs, that a valid login should mean broad network access. Zero Trust approaches, which grant access to specific applications or systems rather than the whole network, directly address the exact worry that 92% of the survey’s respondents raised about third parties: even if a credential is compromised or a former contractor’s login is still active, the blast radius stays small because there was never a wide-open network to move laterally across in the first place.

Security Checklist for Your Business

• Run a quarterly access review. List everyone with VPN or remote access and confirm each one still needs it, not just that the account still works.

• Kill access same-day on offboarding. Employee departures and vendor contract endings should trigger immediate removal, not a cleanup task for later.

• Scope access to what’s needed. Move away from all-or-nothing VPN access toward tools that grant specific application access instead of the whole network.

• Treat third-party access as higher risk by default. Vendor and contractor accounts deserve extra scrutiny and shorter renewal cycles than employee accounts.

Remote access tools don’t expire on their own, and nobody schedules time to notice the ones nobody’s using. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Zscaler, “New VPN Risk Report: 56% of Enterprises Attacked via VPN Vulnerabilities”.

How a Personal Computer Became the Way In

In 2022, LastPass, the password manager used by more than 30 million people and 85,000 businesses, disclosed a second security incident that traced back to something far more mundane than a sophisticated zero-day attack on its infrastructure. The attacker targeted a senior DevOps engineer, one of only four employees at the company with access to the decryption keys protecting its cloud backups. Rather than attacking LastPass’s corporate network directly, the attacker went after that engineer’s home computer.

According to LastPass’s own account of the incident, the attacker exploited a vulnerability in a third-party media software package installed on the engineer’s personal machine to achieve remote code execution and plant a keylogger. That keylogger sat quietly, capturing everything typed on the device, including the moment the engineer authenticated into their LastPass corporate vault with a master password and multi-factor authentication.

With that captured master password and an active authenticated session, the attacker logged into the engineer’s corporate vault and exported its contents, including shared folder entries that held the access and decryption keys to LastPass’s cloud storage environment. Using those stolen keys, the attacker went on to access and decrypt cloud backups containing customer vault data, billing information, and a backup of the company’s MFA and federation database. The intrusion ran from August 12 to October 26, 2022, before LastPass identified and shut it down, publishing a full account of what happened the following March.

Nothing about the attack that eventually reached millions of customer vaults started with a flaw in LastPass’s own network. It started with software the company had no visibility into, running on a device the company did not manage, that happened to hold a live, authenticated line into its most sensitive systems.

Why This Matters If You’re Not a Big Company

It’s tempting to read this as a story about a security vendor and move on, but the actual failure point has nothing to do with being in the security business. It’s a personal device, outside any managed policy, holding an active session into company systems. Every business with employees who check email on their own phone, log into a shared drive from a home laptop, or keep a company app signed in on personal hardware has that same shape of exposure, whether or not anyone has ever written it down as a risk.

Small and mid-size businesses are, if anything, more exposed to this pattern, not less. A large company at least has some chance of catching unusual account activity through logging and monitoring. Most small businesses have no equivalent visibility into what’s happening on an employee’s personal laptop or phone, no way to know what other software is installed on it, and often no written policy establishing what that device is and isn’t allowed to touch. The device itself becomes an invisible extension of the business network that nobody is actually watching.

What Actually Would Have Stopped This

The fix here isn’t complicated, and it doesn’t require banning personal devices outright. It requires drawing a clear line around what a personal device is allowed to access and backing that line with technical controls rather than trust alone. Multi-factor authentication should require a second factor the attacker can’t also capture through a keylogger, such as a hardware security key or an authenticator app tied to a separate device, rather than relying solely on something typed on the same compromised machine. Sensitive access, like the decryption keys a handful of engineers held in this case, should also be walled off so that no single compromised device or account can reach it alone.

Just as important is simply having a policy that says which devices can touch company systems and what has to be true about them first, patched, monitored, and free of unrelated consumer software, before they’re trusted with a live session into anything sensitive. Without that line drawn anywhere, every employee’s personal laptop is a potential front door nobody at the company knows exists.

Security Checklist for Your Business

• Write down your device policy. Spell out which personal devices can access company email, files, or systems, and what conditions they have to meet first.

• Separate MFA from the device being protected. Use a hardware key or a separate authenticator app rather than a factor that lives on the same machine a keylogger could compromise.

• Limit who holds the master keys. Restrict access to your most sensitive systems and credentials to as few people as the job actually requires.

• Keep personal and work software apart. Discourage installing unrelated consumer software, like media servers or file-sharing tools, on any device used to reach company systems.

A single unmanaged personal computer, running software nobody at the company ever approved, was enough to unravel one of the most trusted names in password security. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: CSO Online, “Hacked home computer of engineer led to second LastPass data breach”.

What the Numbers Actually Show

Most businesses can point to a server outage or a big system failure and name the cost. What’s harder to see is the slow leak: the fifteen minutes someone spends staring at a frozen screen, the email that sits unread in a support queue, the “I’ll just deal with it later” that turns into an afternoon. A 2023 survey from Electric AI, an IT services company that surveyed 1,049 employed Americans, tried to put a number on exactly that leak, and the number is bigger than most owners would guess.

The headline figure: employers waste an average of $4,072 per employee every year because of tech issues. That’s not hardware replacement or software licensing, it’s the cost of paid time spent waiting, troubleshooting, and working around problems instead of working. Respondents said they spend almost three hours a week dealing with tech issues, which the survey calculated out to more than 140 hours a year, roughly three and a half work weeks, per employee, gone.

The survey also found the pain isn’t evenly distributed. Remote workers reported the highest rate of wasted time from tech problems, 73%, compared with 41% of hybrid employees and 22% of employees working fully on-site, a gap that tracks with how much harder it is to get quick, in-person help when you’re not in the building. More than half of respondents, 55%, described their company’s technology as outdated, and less than half said their company’s IT support actually resolved their issues effectively when they asked for help.

One more finding is worth pulling out on its own: when official IT support is slow or absent, the burden doesn’t disappear, it shifts to coworkers. The survey found that a majority of younger workers specifically felt that being constantly asked for tech help by colleagues held back their own work. In other words, when there’s no reliable place to send a tech problem, it doesn’t get solved faster. It just gets handed to whoever’s desk is closest, and now two people are stuck instead of one.

Why This Matters If You’re Not a Big Company

Do that math against a real team. A twenty-person company losing even half of that $4,072-per-employee figure, roughly $2,000 a person, is looking at $40,000 a year quietly draining out of productivity nobody put on a budget line. A larger company can absorb that in a rounding error. A twenty-person company feels it in missed deadlines, in a project that always seems to be a week behind, in the same three people fielding “can you look at this real quick” questions all day instead of doing their actual jobs.

This is exactly where being small or mid-size makes the problem worse, not better. Big companies have a dedicated help desk with a ticketing system, defined response times, and staff whose whole job is making tech problems go away quickly. Most small and mid-size businesses don’t. Instead, IT support is whoever’s good with computers, handled between their real responsibilities, or it’s a break-fix vendor you call after something’s already broken and then wait on. Both setups mean the fifteen-minute problem realistically takes an hour or a day to actually get resolved, and that gap compounds every single week.

What Businesses Should Do Instead

The fix isn’t more technology, it’s a faster, more reliable path to a fix when something goes wrong. That means a real point of contact for IT issues with an actual response-time expectation attached to it, not “someone will get to it eventually.” It also means proactively replacing the technology the survey flagged as the biggest drag, aging, outdated equipment, on a planned schedule rather than waiting for it to fail mid-task.

It also means measuring this at all. Most small businesses have never tracked how much time their team actually loses to tech problems in a given month, which is exactly why it’s easy to underestimate. A managed IT provider with defined response-time commitments turns that guesswork into a number you can see, and gives your team someone to call other than the coworker at the next desk.

Security Checklist for Your Business

• Set a real response-time standard. Define how fast a tech issue should get acknowledged and resolved, and hold whoever handles IT, internal or outsourced, to it.

• Track the hours, not just the tickets. Ask your team occasionally how much time tech issues actually cost them in a week; most owners are surprised by the answer.

• Replace aging equipment on a schedule. Don’t wait for old hardware to fail mid-task; a planned refresh cycle is cheaper than the downtime it prevents.

• Give employees one clear place to go. A defined IT contact, not “ask whoever’s nearby,” keeps the burden off your most tech-savvy staff and gets issues fixed faster.

Three hours a week per employee doesn’t sound like much until you multiply it across a whole team and a whole year. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Electric AI, “Wasted Talent: Time Lost to (Old) Tech Issues”.

What Happened

In December 2020, a ransomware attack hit Comprehensive Neurology, PC, a neurology practice in New York. The attack encrypted the practice’s IT network and its electronic protected health information, locking staff out of the very systems they needed to run the office. The exposed data included patient names, clinical information, health insurance details, demographic information, Social Security numbers, and driver’s license numbers, the kind of information that follows a patient around for years, not months.

The practice reported the breach, and the HHS Office for Civil Rights (OCR), the federal agency that enforces HIPAA, opened an investigation. What OCR found wasn’t that the practice had ignored some obscure technical requirement. It was more basic than that: Comprehensive had never conducted an accurate and thorough risk analysis to identify potential risks and vulnerabilities to the confidentiality, integrity, and availability of the patient data it held. That’s not a suggestion buried in HIPAA’s fine print. It’s one of the foundational, required steps of the Security Rule, the starting point every other safeguard is supposed to build on.

In April 2025, OCR announced a settlement: Comprehensive Neurology agreed to pay $25,000 and to operate under a two-year, monitored corrective action plan. That plan requires the practice to actually conduct the risk analysis it had skipped, build a risk management plan to address what that analysis turns up, revise its written HIPAA policies and procedures, and put its staff through HIPAA training tied to their actual job duties. OCR noted this was its 12th ransomware-related enforcement action and the 8th under its Risk Analysis Initiative, a specific enforcement push aimed squarely at practices that never did this foundational work.

What stands out about this case is its scale. This isn’t a hospital network or a national health plan; it’s a single neurology practice, the kind of operation that might have a handful of providers and a small office staff. The fine itself, $25,000, is modest as these things go. But the two-year federal monitoring period, the legal exposure, and the operational disruption of a ransomware attack in the first place are not modest at all for a practice that size.

Why This Matters If You’re Not a Big Company

It’s tempting to read HIPAA enforcement news and assume it only applies to organizations with compliance departments and general counsel on retainer. This case says otherwise. OCR didn’t single out Comprehensive Neurology because it was large or high-profile; it’s neither. It got flagged because a breach happened, and when regulators looked underneath it, there was no risk analysis to point to. That’s a gap that exists at plenty of small medical, dental, and healthcare practices right now, not because anyone is being careless, but because a formal risk analysis often just never makes it onto the to-do list of a busy front office.

The same logic extends past healthcare. Any small business holding sensitive customer data, health records, financial information, personal identifiers, is one incident away from the same kind of scrutiny this practice faced. You don’t need to be a target of interest to attackers to get hit; ransomware operators are largely opportunistic, and a small practice’s systems are often easier to break into than a large hospital’s. The fine here is a reminder that “we didn’t know we were vulnerable” is not a defense once regulators start asking what you did to find out.

What Actually Would Have Stopped This

A risk analysis isn’t a technical audit that requires an in-house IT department to perform. It’s a documented process: inventory where patient or customer data lives, identify what could go wrong with it, unpatched software, unsegmented networks, weak backup practices, missing multi-factor authentication, and write down what you’re doing about each risk you find. HIPAA has required this for years, and OCR’s Risk Analysis Initiative exists specifically because so many practices, especially small ones, still haven’t done it.

Beyond the paperwork, the practical safeguards that follow from a real risk analysis are the ones that actually blunt a ransomware attack: offline or immutable backups that a network-wide encryption event can’t reach, multi-factor authentication on remote access and email, and a patched, monitored network that limits how far an attacker can move once they’re in. None of that requires enterprise budget. It requires doing the assessment first, so you know what to fix.

Security Checklist for Your Business

• Conduct a documented risk analysis. Identify where sensitive data lives, what could compromise it, and put your findings in writing, not just in your head.

• Keep offline or immutable backups. A ransomware attack that encrypts your live network shouldn’t be able to touch your recovery copy too.

• Require MFA on remote access and email. This closes one of the most common doors ransomware operators use to get in.

• Train staff on their specific HIPAA duties. Generic annual training slides don’t stick the way role-specific guidance does.

A $25,000 fine and two years of federal monitoring started with a step that costs far less than either: writing down where the risks actually are. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: HHS Office for Civil Rights Settles HIPAA Ransomware Cybersecurity Investigation with Neurology Practice.

Insurers Are Raising the Bar, and Claims Are Getting Harder to Collect

For years, the standard advice around cyber insurance was simple: buy a policy, file a claim if something happens, get paid. That relationship is changing. According to reporting in Infosecurity Magazine’s year-end look at the cyber insurance market, 56% of CISOs said their organization had a cyber insurance payout denied over the past year, a statistic attributed to Marie Wilcox, VP at security vendor Binalyze and a board director at the Chartered Institute of Information Security (CIISec).

The reasons behind those denials are telling. The article reports that rejections increasingly come down to firms lacking “evidence to prove that they had mitigated risks” and being unable to “produce a full timeline of a breach” when a claim is filed. In other words, insurers aren’t just asking whether you had a policy in place. They’re asking whether you can document, after the fact, exactly what your security controls were doing and precisely how the incident unfolded.

Ryan Rubin, EMEA cyber practice lead at risk consultancy Ankura, put the underwriting shift in blunt terms: “Companies will find themselves having to increasingly demonstrate higher levels of cyber controls maturity before being offered insurance.” He also noted that insurers are growing more cautious in general, “given continued large claims relating to ransomware and business interruption costs,” making them “more hesitant to offer wide coverage.” Wilcox added that the outlook for the year ahead “looks far more challenging” for the people responsible for security programs, with underwriting criteria tightening and compliance expectations rising alongside it.

The article also points to the cost of getting this wrong. It cites Jaguar Land Rover’s August 2025 cyberattack, which had no active cyber insurance policy in place at the time and which the piece estimates cost the UK economy roughly £1.9 billion. By contrast, Marks & Spencer’s April 2025 incident was covered, with a claim reported around £100 million. Having a policy and having a policy that actually pays out turned out to be two very different things.

Why This Matters If You’re Not a Big Company

It’s tempting to read this as an enterprise problem — big companies, big claims, big consultants weighing in. But the underlying shift applies with more force, not less, to smaller businesses. Large organizations generally have security teams, incident response retainers, and the internal logging infrastructure to reconstruct a breach timeline on demand. Most small and mid-size businesses don’t have any of that by default, which means exactly the kind of documentation insurers now expect — proof that controls were in place and working, plus a clear record of what happened — is often the first thing missing when a claim gets filed.

The market dynamics work against smaller businesses too. When insurers pull back on “wide coverage” and raise the bar on controls maturity industry-wide, that bar doesn’t get set separately for a 20-person company versus a 2,000-person one. It gets set once, and smaller businesses either meet it with the same rigor or find themselves in the growing group getting a denial, a higher premium, or a non-renewal notice at the worst possible time — right after an incident, when there’s no runway left to fix the gap.

What Businesses Should Do Instead

The practical takeaway isn’t just “have security tools.” It’s “have security tools that produce a record you can hand to an insurer, and know where that record lives before you ever need it.” That means MFA enforced across email, remote access, and admin accounts, not just checked as a box on a renewal questionnaire. It means endpoint detection and response (EDR) that’s actually logging and alerting, not sitting unmonitored. And it means backups that are tested, offline or immutable, and verified to restore, since “we had backups” and “we can prove our backups worked” are very different claims to make to an insurer after the fact.

Just as important: treat your cyber insurance application and renewal process as a real audit, not paperwork. If you can’t currently answer “what does our breach timeline documentation look like” or “can we prove our MFA coverage is complete,” that’s the gap to close before a renewal, not after a claim gets denied.

Security Checklist for Your Business

• Enforce MFA everywhere, not selectively. Email, remote access, and admin accounts all need it, and you should be able to prove coverage is complete when asked.

• Deploy EDR with active monitoring. A security tool that isn’t generating logs and alerts someone reviews doesn’t help you document an incident later.

• Test your backups, not just schedule them. Offline or immutable backups that have been verified to actually restore are what insurers and your own recovery plan both need.

• Keep incident documentation insurer-ready. Know in advance how you’d reconstruct a breach timeline, since that evidence gap is a leading reason claims get denied.

Insurers aren’t just asking whether you bought a policy anymore — they’re asking whether you can prove your controls actually work, and that’s a harder bar to clear without help. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Soft Market, Hard Choices: The State of Cyber Insurance.

One Report, One Audit, One Settlement

Gibson Overseas, Inc., a Commerce, California-based provider of housewares products, found itself on the wrong end of a software compliance investigation after someone submitted a confidential report through BSA | The Software Alliance’s piracy-reporting website. BSA is the trade group that represents major software publishers, including Microsoft and Adobe, and one of the things it does on their behalf is investigate reports of unlicensed software use inside businesses.

The report didn’t need to come from a hacker, a disgruntled ex-employee’s lawsuit, or a government regulator. It just needed to come from someone who noticed the company was running more copies of software than it had paid for, and who knew where to send that information. From there, BSA opened an investigation into Gibson Overseas’s use of Adobe and Microsoft software.

The case ended the way most of these do: not in court, but in a negotiated settlement. Gibson Overseas agreed to pay $65,000, delete every unlicensed copy of the software in question, purchase legitimate licenses to replace what it had been using, and put stronger software asset management practices in place going forward. A company representative said in a statement that the audit had let the organization implement processes to make sure licensing issues didn’t resurface. A BSA vice president added that organizations need to maintain sound procedures to ensure the software running their business is properly licensed.

Nothing about this case involved a data breach, stolen credentials, or a ransomware note. It started with software that had simply been installed more times, or on more machines, than the license agreement allowed, and it ended with a bill, a licensing cleanup, and a public press release with the company’s name attached.

Why This Matters If You’re Not a Big Company

It’s tempting to read a case like this and assume software licensing enforcement is something that happens to bigger companies with bigger IT footprints. It isn’t. BSA’s reporting program exists specifically to catch this kind of thing at businesses of any size, and the trigger is almost always mundane: a spreadsheet of purchased licenses that fell out of sync with what actually got installed, a laptop imaged from an old master copy, an employee who installed a personal copy of Office or Photoshop on a work machine because it was faster than filing a request.

Small and mid-size businesses are, if anything, more exposed to this kind of drift. There’s rarely a dedicated person tracking every license against every install, software gets added and removed as staff turn over, and nobody notices the gap until someone outside the company reports it. The report itself can come from almost anyone with visibility into what’s installed, current employees, former employees, or even competitors. Once BSA has a report, the investigation and the negotiation happen regardless of company size.

What Actually Would Have Stopped This

The fix here isn’t exotic. It’s a basic software asset management practice: keep an accurate, current record of every software license the business owns and match it against every installation on every device. When someone leaves, when a machine is retired, or when a new license is purchased, that record should get updated the same day, not caught up on once a year. A lot of businesses have some version of this list, but it drifts out of date within months because nobody owns keeping it current.

The other piece is making license compliance part of routine IT hygiene rather than something only checked when a demand letter shows up. Doing an internal license audit once or twice a year, comparing installed software against paid licenses, catches problems before an outside report does, and it costs a fraction of what a settlement and legal fees would.

Security Checklist for Your Business

• Keep a live software license inventory. Track every paid license against every actual installation, updated the day something changes, not once a year.

• Run your own internal audit periodically. Compare installed software to purchased licenses at least annually, before anyone outside the company does it for you.

• Standardize how software gets installed. Route new software requests through IT rather than letting employees install what’s convenient on their own.

• Retire licenses when machines or staff leave. Deactivate and reclaim licenses immediately during offboarding or hardware retirement, not months later.

A software licensing gap doesn’t need a hacker to find it, it just needs one report to a website. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Global Housewares Provider Pays $65,000 to Settle Claims of Unlicensed Software Use.

What Happened

Sudhish Kasaba Ramesh worked as an engineer at Cisco Systems until he resigned in roughly April 2018. Five months later, in September 2018, he still had a way to reach Cisco’s cloud infrastructure. According to the Department of Justice, Ramesh accessed Cisco’s systems without authorization by deploying code from his own personal Google Cloud Project account into Cisco’s environment, which was hosted on Amazon Web Services.

The code he ran did real, deliberate damage. It deleted 456 virtual machines that supported Cisco’s WebEx Teams application. The immediate effect was that more than 16,000 WebEx Teams accounts were shut down, some for as long as two weeks, while Cisco worked to rebuild what had been destroyed. The DOJ press release notes no customer data was compromised in the incident, but the operational damage alone was substantial: Cisco spent approximately $1.4 million on employee time to restore the environment and issued more than $1 million in refunds to affected customers.

Ramesh pleaded guilty in August 2020 to one count of intentionally accessing a protected computer without authorization and recklessly causing damage, under the federal Computer Fraud and Abuse Act. He faced up to five years in prison and a $250,000 fine, with sentencing handled by Judge Lucy H. Koh in the Northern District of California.

What stands out isn’t the sophistication of the attack, it wasn’t sophisticated. It’s the timeline. This wasn’t a hacker breaking through Cisco’s defenses from the outside. It was a five-month gap between an employee’s last day and the moment his access to company infrastructure was actually, fully cut off.

Why This Matters If You’re Not a Big Company

Cisco has an entire security operations team, and it still took an intentionally destructive former employee five months to get caught doing this. A small or mid-size business doesn’t have that team, and it usually doesn’t have Cisco’s ability to absorb a two-week outage across a third of its customer base and simply write a $2.4 million check to make it right.

What makes this case relevant to a 20-person accounting firm or a regional manufacturer isn’t the scale, it’s the mechanism. Offboarding is one of the most routine things a business does. Someone quits, someone gets fired, someone gets laid off, and it happens constantly, often without a formal IT step built into the process at all. If a company as resourced as Cisco can leave a five-month hole in its access controls, a smaller business without a dedicated IT or security function is at least as likely to leave an old employee’s login, VPN credential, or cloud account sitting active long after that person has stopped showing up to work.

What Actually Would Have Stopped This

The fix here isn’t exotic. It’s a documented, enforced offboarding checklist that runs the same way every single time someone leaves, whether they quit on good terms or get walked out the same day. That means disabling accounts, revoking VPN and remote access, pulling API keys and cloud credentials, and removing the person from every system they ever touched, not just email and the badge reader. The Cisco case involved cloud infrastructure access specifically, the kind of access that’s easy to overlook because it doesn’t live in the same list as someone’s email login.

The second piece is a regular access audit, not just an offboarding event. A quarterly review of who has access to what, cross-checked against current employees, catches the account that offboarding missed. Ramesh had access for five months after he resigned. A quarterly audit would have caught that within ninety days, and depending on timing, potentially before the September damage occurred at all.

Security Checklist for Your Business

• Build one offboarding checklist. Cover every system, not just email, VPN, and file shares, but cloud consoles, API keys, and any personal-device access tied to work accounts.

• Revoke access the same day someone leaves, regardless of whether the departure is voluntary, and regardless of how the person left on good terms.

• Run a quarterly access audit that cross-references active accounts against current employees, so a missed revocation gets caught in weeks, not months.

• Treat cloud and infrastructure credentials as seriously as email. They’re often the ones offboarding checklists forget, and they’re the ones that can do the most damage.

A five-month gap in access revocation turned one departing engineer into a two-week outage and a seven-figure bill for a company with a full security team behind it. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: U.S. Attorney’s Office, Northern District of California, “San Jose Man Pleads Guilty to Damaging Cisco’s Network”.

What the Data Shows

Netskope Threat Labs spends its time watching what actually flows across enterprise networks, not what IT policy says should flow across them. Its January 2025 Cloud and Threat Report, built from telemetry across its customer base over the course of 2024, put a number on something most IT teams already suspected but rarely have hard data on: 88% of all employees used a personal cloud app, meaning an app instance tied to their own account rather than a company-managed one, at least once a month. That’s not a niche behavior. That’s nearly the entire workforce.

The more important number sits inside that one. Of those employees, more than one in four, 26%, weren’t just logging into a personal Gmail or a personal Google Drive to check something. They were uploading, posting, or otherwise sending data into it. And when Netskope’s researchers broke down what kind of data was actually crossing that line, the largest category, 60% of all policy violations, was regulated data: personal information, financial records, healthcare data, the kind of information that carries breach-notification obligations the moment it leaves a company’s control. Behind that came intellectual property at 16%, source code at 13%, and passwords or access keys at 11%.

None of this requires a sophisticated attacker or a clever phishing lure. It’s an employee finishing a report from home on a personal laptop and emailing themselves the file. It’s someone backing up client records to their own Google Drive because it’s faster than requesting access to the company’s system. It’s a departing employee moving a folder of “their” work to a personal OneDrive on the way out. Each individual action looks harmless in the moment. At the scale Netskope measured it, across a full year of traffic, it adds up to a steady, largely invisible drain of regulated and proprietary data into accounts no IT department controls, secures, or can revoke.

That’s the core problem shadow IT creates: not that employees are being reckless, but that they’re solving real work problems using whatever’s fastest, and the fastest option is almost never the one IT signed off on. The data doesn’t go anywhere dramatic. It just goes somewhere IT can’t see, can’t audit, and can’t pull back if that personal account is later compromised, sold in an account-recycling marketplace, or simply left logged in on a shared family computer.

Why This Matters If You’re Not a Big Company

It’s tempting to read a stat like “88% of employees” and assume it’s describing a 50,000-person enterprise with sprawling departments nobody can fully monitor. It isn’t. The behavior underneath that number, an employee moving a file to a personal account because it’s convenient, doesn’t scale with company size. A 12-person accounting firm has the exact same dynamic as a Fortune 500 company: people finishing work at home, syncing folders to whatever cloud app they already have open, and reaching for their own login when the company system is slow or the access request would take too long.

Small and mid-size businesses are actually in a worse position on this specific risk, not a better one. Larger organizations at least have a chance of running a cloud access security tool that flags this kind of data movement. Most small businesses have no visibility into it at all, which means the first sign of a problem is usually a client asking why their financial records showed up somewhere they shouldn’t have, or a departing employee’s personal Drive account turning out to still have last quarter’s client files sitting in it, discovered only when something goes wrong.

What Actually Would Have Stopped This

The fix here isn’t a lecture about policy. It’s closing the gap between “the sanctioned way to do this” and “the fastest way to do this,” because employees will always default to whichever one wins. That means IT-approved cloud storage and file-sharing tools need to actually be as convenient as the personal alternative, accessible from home, easy to request access to, and not gated behind a multi-day approval process that pushes people toward Google Drive out of sheer impatience.

The second piece is visibility. A business doesn’t need enterprise-grade cloud security software to catch most of this; it needs basic controls, like blocking uploads to unmanaged personal cloud accounts at the network or endpoint level, and a clear, low-friction path for employees to request an exception when they genuinely need one. Pair that with an offboarding checklist that actually asks “what personal apps did this person have company files in” rather than just disabling their company email, and the two biggest exposure windows, ongoing quiet leakage and departure-day data walking out the door, both shrink substantially.

Security Checklist for Your Business

• Make the approved tool the fast tool. If requesting access to company file storage takes days, employees will default to personal apps out of pure convenience — fix the friction, not just the policy.

• Block uploads to unmanaged personal cloud accounts. Basic DLP or endpoint controls can stop company data from flowing into personal Google Drive, OneDrive, or webmail accounts without slowing down legitimate work.

• Build shadow IT checks into offboarding. Ask departing employees directly what personal apps might still hold company files, not just what company accounts to disable.

• Audit what’s actually being used, not what’s approved. Periodically review network and cloud traffic for personal app usage — the gap between policy and reality is exactly where this risk lives.

The uncomfortable part of this data isn’t that employees are trying to cause harm. It’s that convenience quietly wins over policy almost every time, and most small businesses have no way to even see it happening. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Netskope, “Netskope Threat Labs: Phishing Clicks Nearly Tripled in 2024, Ubiquitous Use of Personal Cloud Apps and GenAI Tools Require Modern Workplace Security to Mitigate Risk”.

A Decade of Warnings, Then a Total Meltdown

When a winter storm swept the central United States the week before Christmas in 2022, airlines across the country scrambled to reroute crews and rebook passengers. Every major carrier weathered it. Southwest Airlines did not. Over ten days, the airline cancelled roughly 16,700 flights, stranding crews and passengers nationwide in what became one of the worst operational failures in U.S. airline history. The proximate cause, according to Southwest’s own leadership, was crew-scheduling software that simply could not keep pace once the number of reassignments needed spiked past what the system was built to handle.

What made the story bigger than one bad week of weather was the paper trail behind it. A Dallas Morning News investigation traced more than a decade of warning signs that Southwest’s technology was falling behind: a 2011 telecommunications and loyalty-program failure, a 2015 crew-scheduling breakdown during a Chicago snowstorm that drew a $1.6 million Department of Transportation fine, a single router failure in 2016 that cascaded into 2,300 cancellations and cost the airline an estimated $54 million in lost revenue and added expenses, and repeated reservation-system outages through 2021. Union leaders representing pilots, flight attendants, and ground crews had been raising the same complaint for years: the systems running the airline’s day-to-day operations were old, patched together, and not being replaced fast enough.

Southwest’s own executives acknowledged this pattern on the record, well before December 2022. In 2017, then-Chief Operating Officer Mike Van de Ven told reporters, “to be real blunt, up until about 2010, it all worked pretty well… we’re at that point that we need to make some investments.” In late 2021, incoming CEO Bob Jordan said employees lacked the tools to manage operational complexity and that the airline needed to modernize. Those were not hidden concerns; they were public statements about known gaps, made a year and five years, respectively, before the gaps caused a nationwide meltdown.

The financial reckoning came fast. Southwest ultimately committed to spending $1.3 billion annually on IT upgrades starting in 2023, on top of $500 million already spent on a 2017 reservation-system overhaul and $2 billion committed in mid-2022 for other technology upgrades. The company also faced a $140 million civil penalty from the Department of Transportation over the meltdown, on top of the direct costs of rebooking, refunds, and reputational damage. None of that spending had to happen on an emergency timeline. It could have happened years earlier, at a fraction of the cost of a crisis response.

Why This Matters If You’re Not a Big Company

It’s tempting to read a story about a major airline and assume it doesn’t apply to a 30-person company running a couple of on-site servers. But the mechanism is identical, just at a different scale. Southwest didn’t fail because one system was old; it failed because years of “we’ll get to it next budget cycle” decisions compounded until an ordinary stress event, a winter storm, hit systems that no longer had the headroom to absorb it. Small and mid-size businesses make that exact same trade-off every year when a server, firewall, or backup appliance quietly ages past its support window and nobody re-evaluates the risk because it’s “still running fine.”

The difference is that a small business doesn’t get a decade of near-misses and public warnings before the bill comes due, and it doesn’t have $1.3 billion a year to throw at a crisis fix. When aging hardware finally fails, or an unsupported system finally gets exploited, most small businesses are looking at days of downtime, lost customer trust, and a scramble to replace equipment on the worst possible timeline, all at once, with no warning window to plan around.

What Actually Would Have Stopped This

The fix here isn’t exotic. It’s a documented hardware and software lifecycle plan, reviewed on a regular schedule, that treats “still running” as a different question from “still supported and still able to handle load.” Servers, network hardware, and line-of-business systems should have a known refresh date tied to vendor end-of-support dates, not to whether they happen to still boot. Southwest’s own history shows the cost of skipping this: a single aging router failure in 2016 cascaded into a multi-day, $54 million crisis, and it still took another six years and a much larger meltdown before the spending actually happened.

Just as important is treating internal warnings the way Southwest’s union leadership was treated: as data, not noise. If the people closest to the systems, IT staff, an MSP, or frontline employees, are flagging that equipment is aging out or struggling under normal load, that’s the signal to budget for a refresh before a storm, a traffic spike, or an attacker forces the issue on someone else’s timeline.

Security Checklist for Your Business

• Track support end dates, not just uptime. Know exactly when every server, firewall, and network device loses vendor support, and budget its replacement before that date, not after something breaks.

• Treat single points of failure as unacceptable. A single aging router or server took down thousands of Southwest flights in 2016; identify anything in your environment with no backup or failover path.

• Listen to your own team’s warnings. If staff or your IT provider have flagged aging or struggling systems more than once, that’s a budget item, not a recurring complaint to note and move past.

• Plan refreshes on a schedule, not a crisis. A predictable three-to-five-year hardware refresh cycle costs far less, and causes far less disruption, than replacing everything at once after a failure.

Southwest’s meltdown didn’t start with the weather; it started with years of technology decisions that kept getting pushed to next year. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: The Dallas Morning News, “Southwest Airlines’ December meltdown came after years of tech failures”.

What Happened

On December 27, 2024, customers of Bench Accounting logged in, or tried to, and found a single message where their bookkeeping platform used to be: “We regret to inform you that as of December 27, 2024, the Bench platform will no longer be accessible.” No slow wind-down, no months-long transition plan. The Canada-based startup, which had raised $113 million from investors including Shopify and Bain Capital Ventures and employed more than 600 people, simply went dark, according to TechCrunch’s reporting the same day.

More than 35,000 U.S. small businesses used Bench to handle their bookkeeping and, for many, their tax preparation. All of that lived inside Bench’s platform: transaction categorization, financial statements, and the underlying documents accountants and the IRS would eventually want to see. When the platform disappeared, so did straightforward access to all of it, right in the middle of a stretch when small businesses are closing out their books for the year and starting to think about tax season.

Bench’s own guidance to customers captured how tight the timeline was: download your data by December 30, just three days out, with a hard cutoff for full access by March 2025, and in the meantime, go file a six-month extension with the IRS because your bookkeeping situation is now unresolved. The company also pointed customers toward Kick, a competing startup, as a place to land. Founder Ian Crosby later said on LinkedIn that he’d been replaced by the board months earlier and that the shutdown followed a change in direction he didn’t control, which doesn’t change what customers faced: a vendor that held their financial records was gone, and the clock to get that data out was measured in days.

For a business owner, none of this involved a hack, a phishing email, or a criminal actor. It was simply a company deciding, or being forced, to stop operating, and taking customer access down with it on a timeline no customer set.

Why This Matters If You’re Not a Big Company

It’s easy to read this and think “that’s an accounting-specific story,” but the actual lesson has nothing to do with bookkeeping. Small and mid-size businesses routinely hand critical, hard-to-recreate data, financial records, customer histories, project files, communications, to a single SaaS vendor and treat the vendor’s platform as the only copy. That works fine every single day the vendor is in business. It stops working the day they’re not, and smaller vendors serving smaller customers don’t come with the assumption of permanence that a Microsoft or Google carries.

The businesses hit hardest by the Bench shutdown weren’t reckless. They picked a well-funded, VC-backed platform that looked stable right up until it wasn’t. That’s exactly the point: vendor stability is not something you can judge from the outside, and a funding round or a big customer logo tells you almost nothing about what happens if the company runs out of runway or a board makes a call the founder doesn’t agree with. The only thing that protects you from that uncertainty is not depending on any single vendor as your only copy of the data.

What Actually Would Have Stopped This

The fix here isn’t complicated, but it does need to be deliberate: export your data out of every SaaS platform you rely on, on a regular schedule, and keep that export somewhere you control, not inside the same vendor’s ecosystem. For bookkeeping specifically, that means periodic exports of financial statements, transaction detail, and source documents to a format you can open without that vendor’s login. The same logic applies to CRM data, project management platforms, and anything else where “the app” is currently the only place the information lives.

It’s also worth reading the contract or terms of service for exactly this scenario before you need it: what happens to your data if the vendor shuts down, how much notice are they obligated to give, and can you get a full export on demand rather than only during a wind-down window. Most businesses never check. The businesses that weren’t scrambling in December 2024 were the ones already exporting Bench data regularly as a matter of habit, not the ones who happened to get lucky.

Security Checklist for Your Business

• Export critical data on a recurring schedule. Don’t wait for a shutdown notice; pull financial, customer, and project data out of every core SaaS platform regularly and store it somewhere you control.

• Read the data-portability terms before you sign up. Know what a vendor owes you for notice and export access if they ever shut down or discontinue a product.

• Keep an offline or vendor-independent copy of anything irreplaceable. A single platform should never be the only place records like tax documents or financial statements exist.

• Ask your MSP to inventory your SaaS dependencies. Knowing exactly which vendors hold which critical data makes a sudden shutdown a manageable task instead of a scramble.

A business doesn’t need to get hacked to lose access to its own records; sometimes a vendor just closes the doors. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: TechCrunch, “Bench shuts down, leaving thousands of businesses without access to accounting and tax docs”.

What Happened

On Friday, July 19, 2024, a faulty software update from cybersecurity vendor CrowdStrike crashed roughly 8.5 million Windows computers worldwide, sending them into repeated reboot loops. The disruption hit airlines, hospitals, and banks first, which is where most of the headlines went. But CrowdStrike’s customer base extends well past the Fortune 500, and the damage reached far smaller operations that had nothing to do with the mistake and no way to route around it.

In Manhattan, Tsvetta Kaleynska runs a small consulting firm called RILA Global Consulting. When the outage hit, she couldn’t pay her employees, missed a Friday contract deadline, and lost a prospective client worth roughly a quarter of her annual earnings because Docusign was unreachable. “If I were part of a big company, then I would be able to delegate and get support from computer science or security services,” she told the Associated Press. “But as a small business owner, I am depending only on myself.”

The pattern repeated across industries. In Melbourne, Australia, locksmith Chris Seabrook lost the ability to send or receive email, access his files, manage his schedule, or create invoices. In Maryland, a virtual mental health practice called Telapsychiatry had therapists locked out of the computers and phone systems they needed to see patients, and had to improvise with Zoom and Ring Central to keep appointments running. A Manhattan restaurant group, Handcraft Hospitality, couldn’t reach its cloud-based accounting software to view receipts, process invoices, or run employee paychecks.

None of these businesses had installed CrowdStrike themselves in any meaningful sense, and none of them had done anything wrong. They were simply downstream of a single vendor’s mistake, with no second system, no offline process, and no alternative way to reach the tools their business ran on. Days after the outage was fixed, many were still working through the backlog.

Why This Matters If You’re Not a Big Company

The gap the AP kept surfacing in its reporting was resources, not fault. A large enterprise IT department can often fail over to a different tool, work from paper temporarily with a plan already in place, or throw a team of specialists at getting critical systems back online within hours. A one-person locksmith shop or a three-location restaurant group typically has none of that in reserve. As one expert quoted in the coverage put it, big companies have a “sizable number of experts on their payroll,” while small businesses face an “uphill battle” with far fewer technical resources to draw on when something like this happens.

That imbalance is exactly why single points of failure matter more, not less, for smaller operations. If your business runs on one cloud provider, one accounting platform, and one email system, with no fallback for any of them, an outage anywhere in that stack becomes an outage in your entire business. You don’t need to be targeted by an attacker or make a mistake yourself to lose a day of revenue, a client, or your ability to pay employees. You just need to be a customer of whoever had the bad day.

What Actually Would Have Stopped This

No single business could have stopped CrowdStrike’s update from shipping, and that’s the point: the fix here isn’t preventing the outage, it’s surviving it. That starts with knowing which of your systems are true single points of failure, the ones where, if they go down, your business simply stops, and building even a basic manual workaround for each one. For the businesses in this story, that would have meant a documented way to process payroll without the primary software, an offline or alternate method for signing contracts, and a backup line of communication with clients that didn’t depend on one platform staying up.

It also means treating “the cloud provider will keep it running” as a plan you never actually wrote down. A short, practical continuity plan, who does what, using what alternate tool or process, when a core system goes dark, turns a chaotic scramble into a known set of steps your team can execute in the first hour instead of the third day.

Security Checklist for Your Business

• Map your single points of failure. List every system that, if it went down for a day, would stop the business entirely, and start there.

• Write down a manual fallback for payroll, invoicing, and client communication, even a simple one, so a platform outage doesn’t mean a full stop.

• Diversify where it’s cheap to. Don’t route every critical function, email, e-signature, payments, through the same single vendor when a second option exists.

• Test your plan before you need it. A continuity plan nobody has walked through is just a document, not a capability.

The businesses in this story weren’t breached, careless, or slow to patch. They were simply one vendor away from being unable to operate, and had no plan for that day. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Associated Press via PBS NewsHour, “Many small businesses struggle to resume normal operations days after global tech outage”.

Ransomware built by a group researchers track as DeadLock represents a shift worth every business owner understanding, not because it encrypts files, all ransomware does that, but because of what it deliberately destroys before it ever touches a single document.

How the Attack Unfolded

Before encryption starts, DeadLock runs a preparation phase aimed specifically at an organization’s ability to recover. Microsoft’s threat intelligence team found it systematically disables Volume Shadow Copy and Windows Backup services, the built-in Windows features many small businesses rely on as their safety net. It goes further, also targeting Hyper-V services that support virtual machines, and Active Directory services that every application and administrator depends on for authentication. Then it empties the recycle bin and clears or disables event logs, cutting off both easy recovery options and the evidence an investigator would need to reconstruct what happened.

When it runs with administrator access, and it’s specifically built to try to obtain that access, it gains the ability to touch protected files, interfere with security software, and remove the exact safety nets a business would reach for first.

The result, in the cases Microsoft studied, wasn’t simply “we lost some files.” It was organizations with backups that were technically intact, discovering that a clean copy of the data alone wasn’t enough to bring the business back.

Why This Matters If You’re Not a Big Company

Most businesses think about ransomware protection as a single question: do we have backups? This case shows that’s the wrong question, or at least an incomplete one. Researchers draw a sharp distinction between restoring and recovering: a restore returns a copy of protected data. A recovery returns a fully working business service, including the identity systems, network configuration, encryption keys, and infrastructure settings that data depends on to actually function.

That distinction shows up in painfully specific ways. A database can restore successfully while the encryption key needed to read it is gone. A server can come back online without the network routing or naming settings that let anything actually reach it. A recovery plan built months ago can be quietly out of date the moment infrastructure changes, meaning the plan and the live environment no longer match by the time you need them to.

This matters just as much for a ten-person company running everything through a few cloud services as it does for a large enterprise. The dependency chain, identity, network, keys, configuration, is just as real at small scale. It’s simply less likely anyone has ever tested whether it actually reconnects after a real failure.

What Actually Would Have Stopped This

The fix isn’t a better backup tool. It’s testing the full recovery, not just the data copy. That means confirming your recovery plan restores identity systems, encryption keys, private networking, DNS, and application configuration, not only files and databases. It means verifying your backups are genuinely immutable against a compromised administrator account, since an attacker with admin rights can otherwise delete or encrypt the backups right along with everything else. And it means actually rehearsing a full recovery on a regular schedule, because environments change faster than backup plans get reviewed, and a plan nobody has tested since it was written is a plan you’re hoping works, not one you know works.

Security Checklist for Your Business

• Confirm backups cover the full dependency chain, not just data: identity, encryption keys, network configuration, and DNS all need a documented recovery path.

• Verify immutability against an administrator account, not just against outside attackers. Backups an admin login can delete are backups ransomware with admin access can delete too.

• Test a full recovery on a real schedule, not just a data restore. The gap between “we have backups” and “we can actually recover” only shows up when you try.

• Keep a recovery point that predates the compromise, not just the newest backup available, since some ransomware sits quietly for a period before triggering encryption.

A backup you’ve never tested recovering from is a plan, not a safety net. The businesses that come back quickly from an incident like this are the ones who found the gaps in a drill, not during the actual emergency. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Microsoft Threat Intelligence, on DeadLock ransomware, as reported by Decryption Digest, “DeadLock Ransomware Recovery: Why Backups Alone Aren’t Enough”.

The Company That Had a Recovery Plan — And Lost Anyway

Code Spaces was a small company offering code hosting and collaboration tools for software teams, built entirely on Amazon Web Services. In June 2014, it was hit with a DDoS attack, and shortly after, an intruder gained access to the company’s AWS EC2 control panel. The attacker left extortion messages through a Hotmail account, demanding payment to hand back control.

Code Spaces tried to do the obvious thing: change the passwords and lock the attacker out. But by then the intruder had already set up backup logins of their own. When the team moved to retake the account, the attacker retaliated by systematically destroying what was there. In the company’s own words, “he had removed all EBS snapshots, S3 buckets, all AMI’s, some EBS instances and several machine instances.” Most of the company’s data, machine configurations, and offsite backups were partially or completely wiped out in the process.

The bitter irony is that Code Spaces believed it was covered. The company had publicly stated it maintained “a full recovery plan that has been proven to work,” including offsite backups. What that plan didn’t account for was that those backups, along with everything else, were reachable through the exact same AWS control panel the attacker had already compromised, with no multi-factor authentication standing in the way. Separate backups only protect you if an attacker (or a fire, or a flood) can’t reach them too.

Code Spaces never came back from it. The company’s own statement was blunt: the cost of resolving the incident would put them in “an irreversible position both financially and in terms of ongoing credibility.” They shut down entirely, spending their final days helping customers pull out what data they could before the business ceased trading for good.

Why This Matters If You’re Not a Big Company

It’s tempting to read this and think “we’re not a tech company running on AWS, this doesn’t apply to us.” But strip away the cloud-specific details and the failure is completely ordinary: one login, one control panel, one point of failure that touched both the live systems and the backups meant to save them if something went wrong. That’s not a big-company problem. It’s the default setup for most small and mid-size businesses that never had someone sit down and design their backups on purpose.

Most SMBs assume they’re covered because “we have backups” — a server that copies files somewhere, a NAS in the closet, a folder synced to the cloud. What almost never gets asked is: if the thing that destroys your main system also has access to your backup, are you actually protected? A fire that takes out the office takes out the NAS sitting in it too. A compromised admin account that can delete production data can usually delete the backup copies sitting right next to it. A plan that’s never been tested against that scenario isn’t really a plan — it’s an assumption.

What Actually Would Have Stopped This

The fix here isn’t complicated, but it does take deliberate setup. Backups need to be isolated from the systems they protect — physically, logically, or both — so that whatever destroys your production environment (a hacker, a fire, a hardware failure, a ransomware payload) can’t also reach the copy meant to bring you back. That means offsite or cloud backups with separate credentials from your day-to-day admin account, ideally with multi-factor authentication and some form of immutability or delayed deletion so a single compromised login can’t wipe out both the original and the backup in one move.

Just as important: a recovery plan is only real if it’s been tested. Code Spaces believed its plan worked because it had never been forced to prove otherwise under attack. A backup you haven’t tried restoring from, on a schedule you actually rehearse, is a hope, not a plan.

Security Checklist for Your Business

• Separate your backup credentials. Don’t let the same login that manages daily operations also be able to delete your backups — use distinct accounts with MFA required.

• Isolate backups from production. Keep at least one copy offline, air-gapped, or in a separate account/environment that a compromised system can’t reach.

• Test your restores on a schedule. A backup nobody has restored from is unverified — treat quarterly test restores as non-negotiable, not optional.

• Write down the actual recovery steps. Document who does what, in what order, so recovery doesn’t depend on one person’s memory during a crisis.

A backup plan only counts if it survives the exact disaster it was built for. MSP Today’s trusted tech partner is JK Computer Solutions. If you want a second set of eyes on your setup, get in touch.

Source: Help Net Security, “Code hosting Code Spaces destroyed by extortion hack attack”.