{
	"id": "86a65dc8-c4c3-4d80-8ffc-02d104dfe65f",
	"created_at": "2026-04-06T00:15:30.101341Z",
	"updated_at": "2026-04-10T03:20:47.645315Z",
	"deleted_at": null,
	"sha1_hash": "54683223071430b071e6d5def1554dca6228465c",
	"title": "Kimwolf Howls from Inside the Enterprise",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 154037,
	"plain_text": "Kimwolf Howls from Inside the Enterprise\r\nBy Renée Burton\r\nPublished: 2026-01-13 · Archived: 2026-04-05 21:27:16 UTC\r\nOn January 2nd, new research revealed that the tremendous growth of the Kimwolf Botnet was fueled by tricking\r\nresidential proxy services into relaying malicious commands to vulnerable devices on the local Wi-Fi network.\r\nMoreover, mobile apps may add devices to a proxy network in ways that may not be obvious to the end user,\r\nturning them into an unwitting infection vector. From our DNS telemetry, we found evidence of Kimwolf probing\r\nfor vulnerable devices using residential proxy services in enterprises and institutions around the world.\r\nAlarmingly, nearly 25% of Infoblox Threat Defense Cloud customers made queries to Kimwolf domains,\r\nsuggesting the presence of proxy endpoints in those networks. This blog contains lessons learned, findings, and\r\nrecommendations for organizations of all sizes.\r\nI was sitting in a hospital cafeteria while I read Brian Kreb’s article, “The Kimwolf Botnet is Stalking Your\r\nLocal Network.” The story sent a chill up my back, and I immediately wondered what damage could be done in\r\nthe hospital setting. New research by Synthient showed how a DNS trick by threat actors, in combination with a\r\nlot of vulnerable devices and security holes, allowed the Kimwolf operators to take over millions of devices in\r\nhome networks in a matter of months. Much of the threat stems from mobile apps with integrated proxy-monetization components and insecure consumer devices, but it feels like the tip of the iceberg. The glue holding\r\nall this together is residential proxy services which route internet traffic through consumer devices and internet\r\nservice providers (ISP), making it appear as though it originates from a residence. While they have legitimate\r\npurposes, the security community has seen time and again that residential proxy services can be abused for a range\r\nof nefarious purposes.\r\nThe article also reminded me of questions I had literally tucked into a note to myself, entitled “weird Aisuru\r\nresolutions,” after reading another of Brian’s blogs on the Aisuru botnet. At that time, I scoured Infoblox DNS\r\ntelemetry to check whether any of our customers had evidence of infections. The Aisuru botnet used DNS TXT\r\nrecords to deliver command-and-control (C2) locations to compromised devices. With a bit of DNS magic, I\r\ndiscovered a few unpublished domains and verified one botnet member using our cloud DNS resolvers… but that\r\n“compromised device” was inside a security company and likely a researcher. Either way, the botnet member\r\nwasn’t receiving commands because the domains were already blocked by Threat Defense. Aisuru used Google\r\nDNS-over-HTTPS (DOH) and so it was possible we didn’t see all the infected devices. In this case, the customer\r\nwas blocking DOH and redirecting the queries through our cloud resolvers. In any event, we didn’t have much\r\nindication of Aisuru in customer networks.\r\nBut some pieces didn’t add up. There were a few domains supposedly associated with Aisuru that resolved to non-routable IP addresses, e.g., 127.0.0.1 or 0.0.0.0. We saw these at low levels across multiple customers. These\r\ndomains didn’t have TXT records and didn’t fit the Aisuru domain profile I had built. Indeed, the one customer\r\nwith a confirmed Aisuru botnet member didn’t query any of these domains!\r\nhttps://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/\r\nPage 1 of 4\n\nIt is very time consuming and often super tricky to figure out the origin of a DNS query, especially when we are\r\nobserving it at a recursive resolver that may be many links away from the origin. The mysterious queries matched\r\nthe pattern we see for open resolvers and I confirmed a few sources were open resolvers but then drew the faulty\r\nconclusion that they were all somehow Aisuru probing open resolvers–a classic example of confirmation bias at\r\nwork.\r\nI asked around in the security community about the weird resolutions, but finding no answers, I wrote that note to\r\nmyself and moved on to other research. The revelations from Synthient shed new light on these queries—it\r\nseemed that Kimwolf operators were probing our customer networks. Within hours, I was peppering Ben\r\nBrundage, the founder of Synthient, with questions. He provided a critical piece of information: an exact\r\ntimestamp that I could map into our logs.\r\nKimwolf scans for vulnerable devices through residential proxy services, leveraging existing compromised\r\ndevices, mobile apps, and other proxy endpoints. Most vulnerable devices are Android TVs, so we don’t expect to\r\nsee many true botnet members in our Threat Defense Cloud customer environments, which are primarily large\r\nenterprises and institutions. That said, the ability to probe the local network and compromise devices is risky\r\nenough that organizations should pay attention.\r\nSo, what did we see at our DNS resolvers? We had queries from about 5% of our customers between September\r\n2nd and October 3rd for the domain reported by Krebs in November as dominating the global DNS charts. But\r\nthat was early on, and over time, the number of impacted customers grew substantially. Figure 1 shows the\r\nnumber of queries per day since October 1st.\r\nFigure 1. Presence of Kimwolf botnet queries within Infoblox Threat Defense Cloud customer environments; in\r\nmany cases, these queries were not resolved due to customer policy settings. On the most active day, 8% of Threat\r\nDefense Cloud customers were probed by Kimwolf operators.\r\nThe graph shows a gap in Kimwolf queries from early October to early November, which Ben confirmed matches\r\nthe activity Synthient observed. A new domain, xd.resi[.]to, shows up a few weeks later, also returning non-routable IPs. Only one customer made queries to the short-lived xd.mob[.]to, on November 22nd. Then in late\r\nDecember 2025, we see queries for the newer domains.\r\nIn total, nearly 25% of our cloud customers made a query to a Kimwolf domain since October 1st. To be clear, this\r\nsuggests that nearly 25% of customers had at least one device that was an endpoint in a residential proxy service\r\ntargeted by Kimwolf operators. Such a device, maybe a phone or a laptop, was essentially co-opted by the threat\r\nhttps://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/\r\nPage 2 of 4\n\nactor to probe the local network for vulnerable devices. A query means a scan was made, not that new devices\r\nwere compromised. Lateral movement would fail if there were no vulnerable devices to be found or if the DNS\r\nresolution was blocked.\r\nThese customers are based all over the world, and in a wide range of verticals, from education to healthcare; see\r\nFigure 2.\r\nFigure 2. A distribution of industries with Kimwolf-related DNS queries\r\nKimwolf uses and abuses residential proxies to spread and monetize their footprint. Two such companies\r\nmentioned in the Synthient report were IPIDEA and Plainproxies. IPIDEA is the largest proxy service in the\r\nworld, while Plainproxies’ footprint grows through developer adoption of their Byteconnect SDK. In response to\r\nSynthient’s vulnerability notification, IPIDEA improved the security of their product, while Plainproxies had not\r\nresponded at the time of Synthient’s disclosure. Krebs on Security also reported that Plainproxies did not\r\nrespond to a request for comment.\r\nHow present are these two proxy services, independent of Kimwolf activity? Over 20% of Threat Defense Cloud\r\ncustomers made queries to the IPIDEA API endpoint that returns information about an IP address, indicating\r\npossible devices with the proxy SDK installed. About a dozen customers made queries to the Plainproxies’ domain\r\nthat returns a list of proxy relay addresses. Of note, during the time when we saw no queries to Kimwolf domains,\r\nwe still observed queries for both proxy services (Figure 3). These are only two of many residential proxy services\r\nthat could be used by threat actors for malicious activity.\r\nhttps://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/\r\nPage 3 of 4\n\nFigure 3. Queries from Infoblox Threat Defense Cloud customers to domains related to residential proxy services,\r\nIPIDEA and Plainproxies\r\nLike Aisuru, Kimwolf may have very little foothold in Infoblox customer environments. However, the use of DNS\r\nand residential proxies to probe networks should be a wake-up call for everyone. This time it is Android TVs, but\r\nwhat if it is heart monitors next time?\r\nEvery organization has unique security concerns, but we recommend the following:\r\nRisk-averse organizations should consider mechanisms, including protective DNS, to detect and block\r\nresidential proxies within the network.\r\nReview your DNS query logs, if you have them, for the presence of queries to known Kimwolf domains.\r\nIf you use protective DNS, check your current response policies. Risk-averse organizations should consider\r\nblocking bogon resolutions, as well as suspicious and malicious domains.\r\nCheck your IP addresses with Synthient or another organization tracking Kimwolf and residential proxies.\r\nRelated Domains:\r\nxd.mob[.]to (this domain is parked and was used for testing, it seems)\r\nxd.resi[.]to\r\n14emeliaterracewestroxburyma02132[.]su\r\n713mtauburnctcolumbusoh43085[.]st\r\nhahaezretard3.713mtauburnctcolumbusoh43085[.]st\r\nr.lolbrogg123424[.]com\r\nipinfo[.]ipidea[.]io (abused residential proxy service endpoint)\r\nnew-endpoints.byteconnect[.]io (abused residential proxy service endpoint)\r\n0\r\nSource: https://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/\r\nhttps://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.infoblox.com/blog/threat-intelligence/kimwolf-howls-from-inside-the-enterprise/"
	],
	"report_names": [
		"kimwolf-howls-from-inside-the-enterprise"
	],
	"threat_actors": [],
	"ts_created_at": 1775434530,
	"ts_updated_at": 1775791247,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/54683223071430b071e6d5def1554dca6228465c.pdf",
		"text": "https://archive.orkl.eu/54683223071430b071e6d5def1554dca6228465c.txt",
		"img": "https://archive.orkl.eu/54683223071430b071e6d5def1554dca6228465c.jpg"
	}
}