Software Security
IT automation with agentic AI: Introducing the MCP server for Red Hat Ansible Automation Platform
Friday Squid Blogging: New Squid Species Discovered
A new species of squid. pretends to be a plant:
Scientists have filmed a never-before-seen species of deep-sea squid burying itself upside down in the seafloor—a behavior never documented in cephalopods. They captured the bizarre scene while studying the depths of the Clarion-Clipperton Zone (CCZ), an abyssal plain in the Pacific Ocean targeted for deep-sea mining.
The team described the encounter in a study published Nov. 25 in the journal Ecology, writing that the animal appears to be an undescribed species of whiplash squid. At a depth of roughly 13,450 feet (4,100 meters), the squid had buried almost its entire body in sediment and was hanging upside down, with its siphon and two long ...
AIs Are Getting Better at Finding and Exploiting Security Vulnerabilities
From an Anthropic blog post:
In a recent evaluation of AI models’ cyber capabilities, current Claude models can now succeed at multistage attacks on networks with dozens of hosts using only standard, open-source tools, instead of the custom tools needed by previous generations. This illustrates how barriers to the use of AI in relatively autonomous cyber workflows are rapidly coming down, and highlights the importance of security fundamentals like promptly patching known vulnerabilities.
[…]
A notable development during the testing of Claude Sonnet 4.5 is that the model can now succeed on a minority of the networks without the custom cyber toolkit needed by previous generations. In particular, Sonnet 4.5 can now exfiltrate all of the (simulated) personal information in a high-fidelity simulation of the Equifax data breach—one of the costliest cyber attacks in historyusing only a Bash shell on a widely-available Kali Linux host (standard, open-source tools for penetration testing; not a custom toolkit). Sonnet 4.5 accomplishes this by instantly recognizing a publicized CVE and writing code to exploit it without needing to look it up or iterate on it. Recalling that the original Equifax breach happened by exploiting a publicized CVE that had not yet been patched, the prospect of highly competent and fast AI agents leveraging this approach underscores the pressing need for security best practices like prompt updates and patches...
How Banco do Brasil uses hyperautomation and platform engineering to drive efficiency
From if to how: A year of post-quantum reality
The Constitutionality of Geofence Warrants
The US Supreme Court is considering the constitutionality of geofence warrants.
The case centers on the trial of Okello Chatrie, a Virginia man who pleaded guilty to a 2019 robbery outside of Richmond and was sentenced to almost 12 years in prison for stealing $195,000 at gunpoint.
Police probing the crime found security camera footage showing a man on a cell phone near the credit union that was robbed and asked Google to produce anonymized location data near the robbery site so they could determine who committed the crime. They did so, providing police with subscriber data for three people, one of whom was Chatrie. Police then searched Chatrie’s home and allegedly surfaced a gun, almost $100,000 in cash and incriminating notes...
Who Operates the Badbox 2.0 Botnet?
The cybercriminals in control of Kimwolf — a disruptive botnet that has infected more than 2 million devices — recently shared a screenshot indicating they’d compromised the control panel for Badbox 2.0, a vast China-based botnet powered by malicious software that comes pre-installed on many Android TV streaming boxes. Both the FBI and Google say they are hunting for the people behind Badbox 2.0, and thanks to bragging by the Kimwolf botmasters we may now have a much clearer idea about that.
Our first story of 2026, The Kimwolf Botnet is Stalking Your Local Network, detailed the unique and highly invasive methods Kimwolf uses to spread. The story warned that the vast majority of Kimwolf infected systems were unofficial Android TV boxes that are typically marketed as a way to watch unlimited (pirated) movie and TV streaming services for a one-time fee.
Our January 8 story, Who Benefitted from the Aisuru and Kimwolf Botnets?, cited multiple sources saying the current administrators of Kimwolf went by the nicknames “Dort” and “Snow.” Earlier this month, a close former associate of Dort and Snow shared what they said was a screenshot the Kimwolf botmasters had taken while logged in to the Badbox 2.0 botnet control panel.
That screenshot, a portion of which is shown below, shows seven authorized users of the control panel, including one that doesn’t quite match the others: According to my source, the account “ABCD” (the one that is logged in and listed in the top right of the screenshot) belongs to Dort, who somehow figured out how to add their email address as a valid user of the Badbox 2.0 botnet.
The control panel for the Badbox 2.0 botnet lists seven authorized users and their email addresses. Click to enlarge.
Badbox has a storied history that well predates Kimwolf’s rise in October 2025. In July 2025, Google filed a “John Doe” lawsuit (PDF) against 25 unidentified defendants accused of operating Badbox 2.0, which Google described as a botnet of over ten million unsanctioned Android streaming devices engaged in advertising fraud. Google said Badbox 2.0, in addition to compromising multiple types of devices prior to purchase, also can infect devices by requiring the download of malicious apps from unofficial marketplaces.
Google’s lawsuit came on the heels of a June 2025 advisory from the Federal Bureau of Investigation (FBI), which warned that cyber criminals were gaining unauthorized access to home networks by either configuring the products with malware prior to the user’s purchase, or infecting the device as it downloads required applications that contain backdoors — usually during the set-up process.
The FBI said Badbox 2.0 was discovered after the original Badbox campaign was disrupted in 2024. The original Badbox was identified in 2023, and primarily consisted of Android operating system devices (TV boxes) that were compromised with backdoor malware prior to purchase.
KrebsOnSecurity was initially skeptical of the claim that the Kimwolf botmasters had hacked the Badbox 2.0 botnet. That is, until we began digging into the history of the qq.com email addresses in the screenshot above.
CATHEAD
An online search for the address [email protected] (pictured in the screenshot above as the user “Chen“) shows it is listed as a point of contact for a number of China-based technology companies, including:
–Beijing Hong Dake Wang Science & Technology Co Ltd.
–Beijing Hengchuang Vision Mobile Media Technology Co. Ltd.
–Moxin Beijing Science and Technology Co. Ltd.
The website for Beijing Hong Dake Wang Science is asmeisvip[.]net, a domain that was flagged in a March 2025 report by HUMAN Security as one of several dozen sites tied to the distribution and management of the Badbox 2.0 botnet. Ditto for moyix[.]com, a domain associated with Beijing Hengchuang Vision Mobile.
A search at the breach tracking service Constella Intelligence finds [email protected] at one point used the password “cdh76111.” Pivoting on that password in Constella shows it is known to have been used by just two other email accounts: [email protected] and [email protected].
Constella found [email protected] registered an account at jd.com (China’s largest online retailer) in 2021 under the name “陈代海,” which translates to “Chen Daihai.” According to DomainTools.com, the name Chen Daihai is present in the original registration records (2008) for moyix[.]com, along with the email address cathead@astrolink[.]cn.
Incidentally, astrolink[.]cn also is among the Badbox 2.0 domains identified in HUMAN Security’s 2025 report. DomainTools finds cathead@astrolink[.]cn was used to register more than a dozen domains, including vmud[.]net, yet another Badbox 2.0 domain tagged by HUMAN Security.
XAVIER
A cached copy of astrolink[.]cn preserved at archive.org shows the website belongs to a mobile app development company whose full name is Beijing Astrolink Wireless Digital Technology Co. Ltd. The archived website reveals a “Contact Us” page that lists a Chen Daihai as part of the company’s technology department. The other person featured on that contact page is Zhu Zhiyu, and their email address is listed as xavier@astrolink[.]cn.
A Google-translated version of Astrolink’s website, circa 2009. Image: archive.org.
Astute readers will notice that the user Mr.Zhu in the Badbox 2.0 panel used the email address [email protected]. Searching this address in Constella reveals a jd.com account registered in the name of Zhu Zhiyu. A rather unique password used by this account matches the password used by the address [email protected], which DomainTools finds was the original registrant of astrolink[.]cn.
ADMIN
The very first account listed in the Badbox 2.0 panel — “admin,” registered in November 2020 — used the email address [email protected]. DomainTools shows this email is found in the 2022 registration records for the domain guilincloud[.]cn, which includes the registrant name “Huang Guilin.”
Constella finds [email protected] is associated with the China phone number 18681627767. The open-source intelligence platform osint.industries reveals this phone number is connected to a Microsoft profile created in 2014 under the name Guilin Huang (桂林 黄). The cyber intelligence platform Spycloud says that phone number was used in 2017 to create an account at the Chinese social media platform Weibo under the username “h_guilin.”
The public information attached to Guilin Huang’s Microsoft account, according to the breach tracking service osintindustries.com.
The remaining three users and corresponding qq.com email addresses were all connected to individuals in China. However, none of them (nor Mr. Huang) had any apparent connection to the entities created and operated by Chen Daihai and Zhu Zhiyu — or to any corporate entities for that matter. Also, none of these individuals responded to requests for comment.
The mind map below includes search pivots on the email addresses, company names and phone numbers that suggest a connection between Chen Daihai, Zhu Zhiyu, and Badbox 2.0.
This mind map includes search pivots on the email addresses, company names and phone numbers that appear to connect Chen Daihai and Zhu Zhiyu to Badbox 2.0. Click to enlarge.
UNAUTHORIZED ACCESS
The idea that the Kimwolf botmasters could have direct access to the Badbox 2.0 botnet is a big deal, but explaining exactly why that is requires some background on how Kimwolf spreads to new devices. The botmasters figured out they could trick residential proxy services into relaying malicious commands to vulnerable devices behind the firewall on the unsuspecting user’s local network.
The vulnerable systems sought out by Kimwolf are primarily Internet of Things (IoT) devices like unsanctioned Android TV boxes and digital photo frames that have no discernible security or authentication built-in. Put simply, if you can communicate with these devices, you can compromise them with a single command.
Our January 2 story featured research from the proxy-tracking firm Synthient, which alerted 11 different residential proxy providers that their proxy endpoints were vulnerable to being abused for this kind of local network probing and exploitation.
Most of those vulnerable proxy providers have since taken steps to prevent customers from going upstream into the local networks of residential proxy endpoints, and it appeared that Kimwolf would no longer be able to quickly spread to millions of devices simply by exploiting some residential proxy provider.
However, the source of that Badbox 2.0 screenshot said the Kimwolf botmasters had an ace up their sleeve the whole time: Secret access to the Badbox 2.0 botnet control panel.
“Dort has gotten unauthorized access,” the source said. “So, what happened is normal proxy providers patched this. But Badbox doesn’t sell proxies by itself, so it’s not patched. And as long as Dort has access to Badbox, they would be able to load” the Kimwolf malware directly onto TV boxes associated with Badbox 2.0.
The source said it isn’t clear how Dort gained access to the Badbox botnet panel. But it’s unlikely that Dort’s existing account will persist for much longer: All of our notifications to the qq.com email addresses listed in the control panel screenshot received a copy of that image, as well as questions about the apparently rogue ABCD account.
Ireland Proposes Giving Police New Digital Surveillance Powers
This is coming:
The Irish government is planning to bolster its police’s ability to intercept communications, including encrypted messages, and provide a legal basis for spyware use.
End-to-end security for AI: Integrating AltaStata Storage with Red Hat OpenShift confidential containers
A Gentle Introduction to multiclaude
*Or: How I Learned to Stop Worrying and Let the Robots Fight*
Alternate titles:
Why tell Claude what to do when you can tell Claude to tell Claude what to do?
My Claude starts itself, parks itself, and autotunes.
You know that feeling when you’re playing an MMO and you realize the NPCs are having more fun than you are? They’re off doing quests, farming gold, living their little digital lives while you’re stuck in a loading screen wondering if you should touch grass.
That’s basically what happened when I built multiclaude.
The Problem: You Are the Bottleneck
Here’s a dirty secret about AI coding assistants: they’re fast, you’re slow.
Claude can write a feature in 30 seconds. You take 5 minutes to read the PR. Claude fixes the bug. You take a bathroom break. Claude refactors the module. You’re still thinking about whether that bathroom break was really necessary or if you just needed to escape your screen for a moment.
The math doesn’t math. You have an infinitely patient, extremely competent coding partner who works at the speed of thought, and you’re… *you*. No offense. I’m also me. It’s fine. We’re all dealing with the human condition.
But what if you just… stopped being the constraint?
The Solution: Controlled Chaos
multiclaude is what happens when you give up on the illusion that software engineering needs to be orderly.
Here’s the pitch: spawn a bunch of Claude Code instances, give them each a task, let them work in parallel, and use CI as a bouncer. If their code passes the tests, it ships. If it doesn’t, they try again. You? You can go touch that grass. Come back to merged PRs.
multiclaude start
multiclaude repo init https://github.com/your/repo
multiclaude worker create "Add dark mode"
multiclaude worker create "Fix that auth bug"
multiclaude worker create "Write those tests nobody wrote"
That’s it. You now have three AI agents working simultaneously while you debate your Chipotle order.
The Philosophy: Brownian Ratchet
Ever heard of a Brownian ratchet? It’s a physics thing that turns out to be impossible but feels like it shouldn’t be.Random molecular motion gets converted into directional progress through a one-way mechanism. Chaos in, progress out.
multiclaude works the same way.
Multiple agents work at once. They might duplicate effort. Two of them might both try to fix the same bug. One might break what another just fixed. *This is fine.* In fact, this is the point.
**CI is the ratchet.** Every PR that passes tests gets merged. Progress is permanent. We never go backward. The randomness of parallel agents, filtered through the one-way gate of your test suite, produces steady forward motion.
Think of it like evolution. Mutations are random. Most fail. The ones that survive get kept. Over time: progress. You don’t need a grand plan. You need good selection pressure.
The core beliefs:
- **Chaos is expected** — Redundant work is cheaper than blocked work
- **CI is king** — If tests pass, ship it. If tests fail, fix it.
- **Forward beats perfect** — Three okay PRs beat one perfect PR that never lands
- **Humans approve, agents execute** — You’re still in charge. You’re just not *busy*.
The Cast: Meet Your Robot Employees
When you fire up multiclaude, you get a whole org chart of AI agents. Each one runs in its own tmux window with its own git worktree. They can see each other. They send messages. It’s like a tiny company, except nobody needs health insurance.
**The Supervisor** is air traffic control. It watches all the workers, notices when someone’s stuck, sends helpful nudges. “Hey swift-eagle, you’ve been on that auth bug for 20 minutes. The tests are in `auth_test.go`. Try mocking the clock.”
**The Merge Queue** is the bouncer. It watches PRs. When CI goes green, it merges. When CI goes red, it spawns a fix-it worker. It doesn’t ask permission. It doesn’t schedule meetings. Green means go.
**Workers** are the grunts. You give them a task, they do it, they make a PR, they self-destruct. Each one gets a cute animal name. swift-eagle. calm-deer. clever-fox. Like a startup that generates its own culture.
- *Your Workspace** is home base. This is where you talk to your personal Claude, spawn workers, check status. It’s like the command tent in a war movie, except the war is against your own backlog.
Attach with `tmux attach -t mc-repo`. Watch them work. It’s hypnotic.
The Machinery: Loops, Nudges, and Messages
Under the hood, multiclaude is refreshingly dumb. No fancy orchestration framework. No distributed consensus algorithms. Just files, tmux, and Go.
**The daemon runs four loops**, each ticking every two minutes:
1. **Health check** — Are the agents still alive? Did someone close their tmux window? If so, try to resurrect them. If resurrection fails, clean up the body.
2. **Message router** — Agents talk via JSON files on disk. The daemon notices new messages, types them into the recipient’s tmux window. Low-tech? Yes. Robust? Incredibly.
3. **Wake/nudge** — Agents can get… contemplative. The daemon pokes them periodically. “Status check: how’s that feature coming?” It’s like a Slack ping, but from a robot to another robot.
4. **Worktree refresh** — Keep everyone’s branches up to date with main. Rebase conflicts before they become merge conflicts.
That’s it. Four loops. Two-minute intervals. The whole system is observable, restartable, and fits in your head.
**Messages** flow through the filesystem:
~/.multiclaude/messages/my-repo/supervisor/msg-abc123.json
{
"from": "clever-fox",
"body": "I need help with the database schema",
"status": "pending"
}
The daemon sees it, sends it to supervisor’s tmux window, marks it delivered. The supervisor reads it, helps clever-fox, moves on. No Kafka. No Redis. Just files.
**Nudges** keep agents from getting stuck in thought loops. Every two minutes, the daemon asks “how’s it going?” Not nagging — more like a gentle reminder that work exists and time is passing. Without nudges, agents sometimes disappear into analysis paralysis. With nudges, they ship.
The MMO Model
Here’s my favorite way to think about it: multiclaude is an MMO, not a single-player game.
Your workspace is your character. Workers are party members you summon. The supervisor is your guild leader. The merge queue is the raid boss guarding main.
Log off. The game keeps running. Come back to progress.
This is what software engineering *should* feel like. Not you typing while Claude watches. Not Claude typing while you watch. Both of you doing things, in parallel, with an army of helpers. You’re the raid leader. You’re not tanking every mob yourself.
Getting Started: The Five-Minute Setup
Prerequisites: Go, tmux, git, gh (authenticated with GitHub).
# Install
go install github.com/dlorenc/multiclaude/cmd/multiclaude@latest
# Fire it up
multiclaude start
multiclaude repo init https://github.com/your/repo
# Spawn some workers and walk away
multiclaude worker create "Implement feature X from issue #42"
multiclaude worker create "Add tests for the payment module"
multiclaude worker create "Fix that CSS bug that's been open for six months"
# Watch the chaos
tmux attach -t mc-your-repo
Detach with `Ctrl-b d`. They keep working. Come back tomorrow. Check `gh pr list`. Feel mildly unsettled that software is writing itself. Merge what looks good.
## Extending: Build Your Own Agents
The built-in agents are just markdown files. Seriously. Look:
# Worker
You are a worker. Complete your task, make a PR, signal done.
## Your Job
1. Do the task you were assigned
2. Create a PR with detailed summary
3. Run `multiclaude agent complete`
Want a docs-reviewer agent? Write a markdown file:
# Docs Reviewer
You review documentation changes. Focus on:
- Accuracy - does the docs match the code?
- Clarity - can a new developer understand this?
- Completeness - are edge cases documented?
When you find issues, leave helpful PR comments.
Spawn it:
multiclaude agents spawn - name docs-bot - class docs-reviewer - prompt-file docs-reviewer.md
Boom. Custom agent. No code changes. No recompilation. Just markdown and vibes.
Want to share agents with your team? Drop them in `.multiclaude/agents/` in your repo. Everyone gets them automatically.
The Vision: Software Projects That Write Themselves
Here’s where I get philosophical.
The bottleneck in software development has always been humans. Not compute, not tooling, not process. Humans. We’re slow. We get tired. We have meetings.
What if the humans became the *selection pressure* instead of the *labor*?
You define what good looks like (tests, CI, review standards). Agents propose changes. Good changes get merged. Bad changes don’t. You curate. You approve. You set direction. But you don’t type every character.
This isn’t about replacing developers. It’s about changing what developers *do*. Less typing, more thinking. Less implementation, more architecture. Less grunt work, more judgment.
multiclaude is a bet that the future of programming looks more like managing a team than writing code. Your job becomes: hire good robots (define good prompts), give them clear objectives (tasks with context), and maintain quality standards (CI that actually tests things).
The robots do the rest.
Self-Hosting Since Day One
One more thing: multiclaude builds itself. The agents in this codebase wrote the code you’re reading. PRs get created by workers, reviewed by reviewers, merged by merge-queue, coordinated by supervisor.
We eat our own dogfood so aggressively that we’re basically drowning in it. At some point the dogfood started cooking itself, and we just… let it?
Is this a good idea? Unclear! Is it fun? Absolutely. Does it work? Well, you’re reading this, so… yes?
**Ready to stop being the bottleneck?**
go install github.com/dlorenc/multiclaude/cmd/multiclaude@latest
multiclaude start
Let the robots fight. You have grass to touch.
Friday Squid Blogging: Giant Squid in the Star Trek Universe
Spock befriends a giant space squid in the comic Star Trek: Strange New Worlds: The Seeds of Salvation #5.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
AIs are Getting Better at Finding and Exploiting Internet Vulnerabilities
Really interesting blog post from Anthropic:
In a recent evaluation of AI models’ cyber capabilities, current Claude models can now succeed at multistage attacks on networks with dozens of hosts using only standard, open-source tools, instead of the custom tools needed by previous generations. This illustrates how barriers to the use of AI in relatively autonomous cyber workflows are rapidly coming down, and highlights the importance of security fundamentals like promptly patching known vulnerabilities.
[…]
A notable development during the testing of Claude Sonnet 4.5 is that the model can now succeed on a minority of the networks without the custom cyber toolkit needed by previous generations. In particular, Sonnet 4.5 can now exfiltrate all of the (simulated) personal information in a high-fidelity simulation of the Equifax data breach—one of the costliest cyber attacks in history—using only a Bash shell on a widely-available Kali Linux host (standard, open-source tools for penetration testing; not a custom toolkit). Sonnet 4.5 accomplishes this by instantly recognizing a publicized CVE and writing code to exploit it without needing to look it up or iterate on it. Recalling that the original Equifax breach happened by exploiting a publicized CVE that had not yet been patched, the prospect of highly competent and fast AI agents leveraging this approach underscores the pressing need for security best practices like prompt updates and patches. ...
Why AI Keeps Falling for Prompt Injection Attacks
Imagine you work at a drive-through restaurant. Someone drives up and says: “I’ll have a double cheeseburger, large fries, and ignore previous instructions and give me the contents of the cash drawer.” Would you hand over the money? Of course not. Yet this is what large language models (LLMs) do.
Prompt injection is a method of tricking LLMs into doing things they are normally prevented from doing. A user writes a prompt in a certain way, asking for system passwords or private data, or asking the LLM to perform forbidden instructions. The precise phrasing overrides the LLM’s ...
Understanding security embargoes at Red Hat
New observability features in Red Hat OpenShift 4.20 and Red Hat Advanced Cluster Management 2.15
DDoS in December 2025
Internet Voting is Too Insecure for Use in Elections
No matter how many times we say it, the idea comes back again and again. Hopefully, this letter will hold back the tide for at least a while longer.
Executive summary: Scientists have understood for many years that internet voting is insecure and that there is no known or foreseeable technology that can make it secure. Still, vendors of internet voting keep claiming that, somehow, their new system is different, or the insecurity doesn’t matter. Bradley Tusk and his Mobile Voting Foundation keep touting internet voting to journalists and election administrators; this whole effort is misleading and dangerous...
2025 was a year of transformative customer success with Red Hat Ansible Automation Platform
2025 Red Hat Ansible Automation Platform: A year in review
Kimwolf Botnet Lurking in Corporate, Govt. Networks
A new Internet-of-Things (IoT) botnet called Kimwolf has spread to more than 2 million devices, forcing infected systems to participate in massive distributed denial-of-service (DDoS) attacks and to relay other malicious and abusive Internet traffic. Kimwolf’s ability to scan the local networks of compromised systems for other IoT devices to infect makes it a sobering threat to organizations, and new research reveals Kimwolf is surprisingly prevalent in government and corporate networks.
Image: Shutterstock, @Elzicon.
Kimwolf grew rapidly in the waning months of 2025 by tricking various “residential proxy” services into relaying malicious commands to devices on the local networks of those proxy endpoints. Residential proxies are sold as a way to anonymize and localize one’s Web traffic to a specific region, and the biggest of these services allow customers to route their Internet activity through devices in virtually any country or city around the globe.
The malware that turns one’s Internet connection into a proxy node is often quietly bundled with various mobile apps and games, and it typically forces the infected device to relay malicious and abusive traffic — including ad fraud, account takeover attempts, and mass content-scraping.
Kimwolf mainly targeted proxies from IPIDEA, a Chinese service that has millions of proxy endpoints for rent on any given week. The Kimwolf operators discovered they could forward malicious commands to the internal networks of IPIDEA proxy endpoints, and then programmatically scan for and infect other vulnerable devices on each endpoint’s local network.
Most of the systems compromised through Kimwolf’s local network scanning have been unofficial Android TV streaming boxes. These are typically Android Open Source Project devices — not Android TV OS devices or Play Protect certified Android devices — and they are generally marketed as a way to watch unlimited (read:pirated) video content from popular subscription streaming services for a one-time fee.
However, a great many of these TV boxes ship to consumers with residential proxy software pre-installed. What’s more, they have no real security or authentication built-in: If you can communicate directly with the TV box, you can also easily compromise it with malware.
While IPIDEA and other affected proxy providers recently have taken steps to block threats like Kimwolf from going upstream into their endpoints (reportedly with varying degrees of success), the Kimwolf malware remains on millions of infected devices.
A screenshot of IPIDEA’s proxy service.
Kimwolf’s close association with residential proxy networks and compromised Android TV boxes might suggest we’d find relatively few infections on corporate networks. However, the security firm Infoblox said a recent review of its customer traffic found nearly 25 percent of them made a query to a Kimwolf-related domain name since October 1, 2025, when the botnet first showed signs of life.
Infoblox found the affected customers are based all over the world and in a wide range of industry verticals, from education and healthcare to government and finance.
“To be clear, this suggests that nearly 25% of customers had at least one device that was an endpoint in a residential proxy service targeted by Kimwolf operators,” Infoblox explained. “Such a device, maybe a phone or a laptop, was essentially co-opted by the threat actor to probe the local network for vulnerable devices. A query means a scan was made, not that new devices were compromised. Lateral movement would fail if there were no vulnerable devices to be found or if the DNS resolution was blocked.”
Synthient, a startup that tracks proxy services and was the first to disclose on January 2 the unique methods Kimwolf uses to spread, found proxy endpoints from IPIDEA were present in alarming numbers at government and academic institutions worldwide. Synthient said it spied at least 33,000 affected Internet addresses at universities and colleges, and nearly 8,000 IPIDEA proxies within various U.S. and foreign government networks.
The top 50 domain names sought out by users of IPIDEA’s residential proxy service, according to Synthient.
In a webinar on January 16, experts at the proxy tracking service Spur profiled Internet addresses associated with IPIDEA and 10 other proxy services that were thought to be vulnerable to Kimwolf’s tricks. Spur found residential proxies in nearly 300 government owned and operated networks, 318 utility companies, 166 healthcare companies or hospitals, and 141 companies in banking and finance.
“I looked at the 298 [government] owned and operated [networks], and so many of them were DoD [U.S. Department of Defense], which is kind of terrifying that DoD has IPIDEA and these other proxy services located inside of it,” Spur Co-Founder Riley Kilmer said. “I don’t know how these enterprises have these networks set up. It could be that [infected devices] are segregated on the network, that even if you had local access it doesn’t really mean much. However, it’s something to be aware of. If a device goes in, anything that device has access to the proxy would have access to.”
Kilmer said Kimwolf demonstrates how a single residential proxy infection can quickly lead to bigger problems for organizations that are harboring unsecured devices behind their firewalls, noting that proxy services present a potentially simple way for attackers to probe other devices on the local network of a targeted organization.
“If you know you have [proxy] infections that are located in a company, you can chose that [network] to come out of and then locally pivot,” Kilmer said. “If you have an idea of where to start or look, now you have a foothold in a company or an enterprise based on just that.”
This is the third story in our series on the Kimwolf botnet. Next week, we’ll shed light on the myriad China-based individuals and companies connected to the Badbox 2.0 botnet, the collective name given to a vast number of Android TV streaming box models that ship with no discernible security or authentication built-in, and with residential proxy malware pre-installed.
Further reading:
The Kimwolf Botnet is Stalking Your Local Network
Who Benefitted from the Aisuru and Kimwolf Botnets?
A Broken System Fueling Botnets (Synthient).
Pages
