Daily Digest

Dutch authorities just dropped the hammer on two hosting company owners, seizing 800 servers and making arrests in a case that reads like a spy thriller with a data center twist. The co-owners are accused of knowingly providing IT infrastructure to Russian intelligence agencies for cyberattacks, influence operations, and disinformation campaigns targeting the European Union. This isn't just another takedown—it's a direct hit on the supply chain of Russian cyber aggression. If you're running a business in Europe, using cloud services, or even just browsing the web, the infrastructure these men allegedly operated has likely touched your digital life. The message is clear: hosting malicious actors comes with real consequences, and the Dutch aren't playing games.

**What exactly happened** On May 18, the Dutch financial crime agency FIOD arrested a 57-year-old from Amsterdam and a 39-year-old from The Hague, charging them with violating sanctions law. The arrests came alongside the seizure of 800 servers connected to their hosting operations. These men were the co-owners of two internet hosting companies that had effectively taken over the technical infrastructure of Stark Industries Solutions—a provider sanctioned by the EU last year for being a frequent launchpad for Russian intelligence cyberattacks. The investigation zeroed in on how these hosting companies allegedly made economic resources available to EU-sanctioned entities, effectively bypassing sanctions meant to cripple Russia's cyber capabilities. **Who is affected and how** The immediate targets were European governments, critical infrastructure, and private sector organizations hit by DDoS attacks, disinformation campaigns, and cyber espionage. But the ripple effects extend to every internet user in the EU. The proxy and anonymity services provided by this infrastructure masked the origins of attacks, making it harder to trace and stop malicious activity. For businesses, this means potential exposure to attacks that could have been prevented if the hosting providers had complied with sanctions. For everyday users, it means their data and privacy were collateral damage in a larger geopolitical conflict playing out in server racks. **The real-world impact and consequences** The seizure of 800 servers is a significant operational blow. It disrupts the command-and-control infrastructure used by Russian hacking groups, at least temporarily. But the impact goes deeper—it sends a signal that European authorities are willing to pursue not just the hackers, but the enablers who provide them with digital safe havens. The arrests also highlight a growing trend: sanctions enforcement is moving beyond traditional financial channels into the technical infrastructure that powers cyber operations. This could force hosting providers worldwide to tighten their compliance measures or face similar consequences. **Technical breakdown** Stark Industries Solutions emerged just two weeks before Russia invaded Ukraine, which should have been a red flag. The provider quickly became a source of massive DDoS attacks against European targets and a top supplier of proxy and anonymity services linked to Russian-backed hacking groups. The arrested men's companies essentially provided Stark with connectivity to the larger internet, acting as upstream providers. By controlling these conduits, they could route traffic from Russian intelligence operations through their networks, making it appear as if attacks originated from legitimate European IP addresses. The 800 servers seized likely contained logs, routing data, and evidence of this traffic manipulation. **What should be done — mitigation and recommendations** For organizations: Review your supply chain for any services that might route through questionable hosting providers. Implement network monitoring to detect unusual traffic patterns that could indicate proxy or anonymity service usage. For hosting providers: This is a wake-up call to strengthen your KYC (Know Your Customer) processes. Verify who your upstream and downstream partners are, and don't ignore red flags like companies that appear suspiciously close to geopolitical events. For policymakers: Continue expanding sanctions enforcement to cover technical infrastructure. The Dutch model of pursuing hosting providers directly could become a template for other nations. **Why this matters in the bigger cybersecurity landscape** This case represents a paradigm shift in how we think about cyber defense. We've long focused on stopping the attackers themselves, but the real leverage point might be the infrastructure they depend on. By targeting the hosting providers, authorities are attacking the foundation of Russian cyber operations. The 800 servers seized aren't just hardware—they're a symbol that the digital battlefield is expanding. Every hosting provider, every data center, every internet exchange point is now a potential chokepoint in the fight against state-sponsored cyberattacks. The Dutch have shown that when you starve the infrastructure, you starve the attack.

A CISA contractor just did the unthinkable: they posted the agency’s deepest secrets on a public GitHub account named “Private-CISA.” We’re talking plaintext credentials to dozens of internal systems, AWS GovCloud keys, and sensitive data—all sitting in the open for anyone to find. Lawmakers are now demanding answers, and CISA is scrambling to contain the fallout. If you work in government, defense, or critical infrastructure, this leak puts your data at risk. The question isn’t if bad actors saw it, but how much they already took.

**What exactly happened** On May 18, KrebsOnSecurity broke the story: a CISA contractor with admin access to the agency’s code platform created a public GitHub profile called “Private-CISA.” Inside? Plaintext credentials to dozens of internal CISA systems, including AWS GovCloud keys. The contractor even disabled GitHub’s built-in protection against publishing sensitive credentials in public repos. The commit logs show this was no accident—it was a deliberate bypass of security controls. **Who is affected and how** The exposed data includes credentials for systems used by CISA, the Department of Homeland Security, and potentially other federal agencies. Anyone with access to that GitHub repo could have used those keys to log into CISA’s cloud infrastructure. Lawmakers from both parties are now demanding answers. Sen. Maggie Hassan and Rep. Bennie Thompson have sent letters to CISA’s acting director, asking for a full accounting of what was leaked and when. **The real-world impact and consequences** CISA insists “there is no indication that any sensitive data was compromised.” But experts who reviewed the repo say it was created in November 2025 and gained its most sensitive secrets in late April 2026. That’s months of potential exposure. A malicious actor could have cloned the repo, extracted the keys, and quietly accessed CISA systems without leaving a trace. The real damage may not be known for years. **Technical breakdown** The contractor used the public GitHub repo as a “working scratchpad” or synchronization mechanism between work and home machines. They disabled GitHub’s secret scanning, which normally blocks commits containing credentials. Experts from Truffle Security analyzed the repo and found it contained plaintext passwords, API keys, and cloud service credentials. The contractor’s actions suggest a pattern of convenience over security—using public infrastructure to move data between devices. **What should be done — mitigation and recommendations** CISA is now racing to invalidate the leaked credentials and rotate all affected keys. But this is a massive undertaking: each system requires manual reconfiguration, and some may have dependencies that break during rotation. For other agencies and contractors, the lesson is clear: enforce strict controls on code repositories, mandate secret scanning, and monitor for unauthorized public repos. Zero-trust architectures should assume credentials are already compromised. **Why this matters in the bigger cybersecurity landscape** This incident exposes a fundamental flaw in how government agencies manage contractor access. When a single contractor can bypass security controls and post secrets to a public repo, the entire system is broken. It also highlights the tension between convenience and security. The contractor likely used GitHub to sync files because it was easier than using approved tools. That’s a failure of policy, training, and enforcement. For the cybersecurity community, this is a wake-up call: insider threats aren’t always malicious. Sometimes they’re just careless. And careless can be just as dangerous as malicious when it comes to national security.

A 23-year-old Ottawa man named Jacob Butler—known online as “Dort”—was arrested Wednesday for allegedly building and operating the Kimwolf botnet, an IoT malware strain that enslaved millions of devices worldwide. This isn’t just another cyber arrest: Kimwolf powered some of the largest DDoS attacks in recent history, hitting targets from the Department of Defense to journalists and security researchers. If you own a digital photo frame, webcam, or any poorly secured smart device, you might have been part of this army without knowing it. The arrest sends a clear signal: law enforcement is finally catching up to the botnet-as-a-service underground. But the real question is—how many more “Dorts” are still out there?

**What exactly happened** Canadian police, acting on a U.S. extradition warrant, arrested Jacob Butler in Ottawa on Wednesday. The criminal complaint, unsealed in an Alaska district court, charges him with aiding and abetting computer intrusion for operating the Kimwolf botnet. Butler, known as “Dort” in cybercrime circles, was publicly named by KrebsOnSecurity in February 2026 after he allegedly launched DDoS, doxing, and swatting attacks against the journalist and a security researcher. The arrest is the culmination of a cross-border investigation involving the Ontario Provincial Police, the FBI, and the Department of Defense’s Criminal Investigative Service. Butler now faces charges in both Canada and the United States, with an initial court hearing scheduled for next week. **Who is affected and how** Kimwolf specifically targeted Internet-of-Things devices that are traditionally “firewalled” from the rest of the internet—think digital photo frames, webcams, and other smart gadgets with weak security. These infected devices were then rented out to other cybercriminals or forced into massive DDoS attacks. The botnet didn’t just hit random targets. It attacked Internet address ranges belonging to the Department of Defense, making this a national security concern. Journalists, researchers, and anyone relying on internet infrastructure also felt the heat during Kimwolf’s peak activity over the past six months. **The real-world impact and consequences** The impact goes beyond technical disruption. DDoS attacks from Kimwolf were record-breaking in scale, capable of taking down major websites and services. For the DoD, this meant potential interference with military communications and operations. For Butler personally, the consequences are severe. If extradited, tried, and convicted in the U.S., he faces up to 10 years in prison. However, the sentencing guidelines may reduce that due to his youth, lack of prior criminal history, and potential cooperation with investigators. Still, this arrest sends a strong deterrent message to other botnet operators. **Technical breakdown (the “how”)** Kimwolf worked by scanning the internet for IoT devices with default or weak credentials. Once inside, it enslaved the device into a botnet army. The malware was designed to be fast-spreading, leveraging the sheer number of vulnerable devices to amplify attack power. The infected devices were then used in two primary ways: rented as a DDoS-for-hire service to other criminals, or directly commanded to flood targets with traffic. Because many of these devices were behind firewalls, they were harder to detect and takedown than traditional botnets. **What should be done — mitigation and recommendations** For individuals and organizations, the first step is simple: change default passwords on all IoT devices. Disable unnecessary remote access features and keep firmware updated. For enterprises, network segmentation can limit the blast radius if a device gets infected. Law enforcement agencies should continue cross-border collaboration like this case shows. The DoJ’s involvement with Canadian authorities and the DoD’s investigative unit highlights the need for multi-agency coordination against botnet infrastructure. **Why this matters in the bigger cybersecurity landscape** The Kimwolf arrest is a landmark moment for IoT security enforcement. It proves that even anonymous botnet operators can be tracked, named, and arrested—even across international borders. But it also underscores a grim reality: millions of devices remain vulnerable to similar attacks. As IoT adoption explodes, the attack surface grows exponentially. This case should be a wake-up call for manufacturers to build security into devices from the start, not as an afterthought. For now, the takedown of Kimwolf is a win—but the war against botnets is far from over.

Imagine a cybersecurity agency—the very one tasked with protecting America’s digital infrastructure—accidentally leaving its own master keys out in the open. That’s exactly what happened when a CISA contractor posted highly privileged AWS GovCloud credentials and internal system details on a public GitHub repository. This isn’t just a slip-up; experts are calling it one of the most egregious government data leaks in recent memory. If you care about national security, cloud security, or how even the pros can stumble, this story is a wake-up call. The risk? Any threat actor who stumbled upon this repo could have accessed classified government systems.

**What exactly happened** A contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository named “Private-CISA.” Until last weekend, it contained a treasure trove of sensitive data: AWS GovCloud keys, plaintext passwords, internal logs, and detailed documentation on how CISA builds, tests, and deploys software. The leak was flagged by Guillaume Valadon, a researcher at GitGuardian, a firm that constantly scans public code repositories for exposed secrets. Valadon noted that the repository owner wasn’t responding to alerts, which made the situation even more alarming. **Who is affected and how** The exposed credentials granted access to highly privileged AWS GovCloud accounts—the government’s secure cloud environment for sensitive workloads. Also compromised were internal CISA systems, including those used for software development and deployment. This means any malicious actor who found the repo could have potentially accessed, modified, or exfiltrated data from these systems. The leak also exposed internal processes, giving adversaries a blueprint of CISA’s operational playbook. **The real-world impact and consequences** Security experts described this as one of the most egregious government data leaks in recent history. The exposure of cloud keys and internal documentation could allow attackers to pivot from the cloud into on-premises systems, escalating their access. For an agency like CISA, which is supposed to be the gold standard for cybersecurity, this is deeply embarrassing. It also undermines public trust in the government’s ability to protect its own digital assets, let alone the nation’s. **Technical breakdown (the “how” explained simply)** The contractor disabled a default GitHub security setting that blocks users from publishing SSH keys or other secrets in public repositories. This is a classic case of misconfiguration. The repository contained credentials stored in plaintext within CSV files and logs. Commit logs showed the contractor had been syncing files between a work laptop and a home computer since November 2025, using GitHub as a makeshift file-sharing tool. This is a textbook example of poor security hygiene—treating a public code repository like a personal cloud drive. **What should be done — mitigation and recommendations** Immediately, CISA should rotate all exposed credentials, revoke access keys, and audit the contractor’s account activity. They must also enforce strict policies against storing secrets in code repositories. For any organization, the fix is straightforward: use secret scanning tools (like GitGuardian), enable GitHub’s default security blocks, and educate employees on secure development practices. Never store credentials in plaintext, and never use public repos for internal file synchronization. **Why this matters in the bigger cybersecurity landscape** This leak highlights a persistent vulnerability in modern development: the human factor. Even at the highest levels of government, misconfigurations and poor habits can lead to catastrophic exposures. It also underscores the importance of continuous monitoring. If not for GitGuardian’s automated scans, this leak might have gone unnoticed indefinitely. For the cybersecurity community, this is a stark reminder that no one is immune to basic mistakes—and that vigilance must be constant, not just for the companies we protect, but for ourselves.