{
	"id": "30f4f456-0967-47e5-9056-f8055a0239bc",
	"created_at": "2026-04-06T00:11:39.541698Z",
	"updated_at": "2026-04-10T03:21:52.661395Z",
	"deleted_at": null,
	"sha1_hash": "18a8101ce5f59443fc2d43e54fabf738b3cee2b6",
	"title": "AZORult's End? Chrome Update Cripples Major Infostealer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 421521,
	"plain_text": "AZORult's End? Chrome Update Cripples Major Infostealer\r\nPublished: 2020-02-26 · Archived: 2026-04-05 18:36:51 UTC\r\nWhat’s Dead May Never Die: AZORult Infostealer Decommissioned Again\r\nBy KELA Cyber Team\r\nUpdated February 26, 2020\r\nBottom Line Up Front\r\nSince mid-February, discussions throughout multiple cybercrime communities have been noting that the main\r\npassword stealing features of the AZORult infostealer – one of the most prevalent stealers currently in use, and the\r\nmain culprit behind the ongoing campaign – have been disabled by a recent Google Chrome update. Since\r\nAZORult isn’t actively maintained, many actors are now regarding the stealer as fully decommissioned.\r\nOne Chrome Update to Rule Them All\r\nOver the last several days, threat actors in a variety of cybercrime forums have been spreading obituaries for\r\nAZORult – one of the major, most prevalent infostealers in use by the cybercrime underground. This is not the\r\nfirst time AZORult dies. In late 2018, sales by the official developer have stopped because the source code became\r\ntoo ubiquitous and sprang too many offshoots. However, as shown in our latest research, AZORult remained very\r\nhttps://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/\r\nPage 1 of 4\n\nactive – it’s been seen in recent campaigns and is directly related to over 300,000 infections paddled on the\r\nGenesis Store botnet market.\r\nThis time, the situation is different – the word around the cybercriminal underground is that AZORult is not\r\ncapable of handling features bundled by a recent Google Chrome update. One of AZORult’s main functions is\r\nstealing browser-saved credentials, and threat actors are claiming that Chrome’s move to hashing locally-saved\r\npassword in the AES-256 algorithm thwarts AZORult’s best efforts to steal them.\r\nTop: an obituary to AZORult posted in a closed Russian hacking forum; from Russian: “Azor is finished. Not only\r\nthat – all the older cracked versions of different stealers are finished”. Bottom: actors discussing AZORult’s\r\napparent demise on a different forum. From Russian: “What is the new encryption of passwords in chrome?”;\r\n“aes256”\r\nAs can be seen in the excerpt above – noting “all the older cracked versions of different stealers are finished” –\r\nAZORult is not the only stealer that was affected by the update. The Raccoon stealer, for example, was also\r\naffected by the update. However, unlike AZORult, Raccoon is actively maintained by a centralized management –\r\nand as such was able to adapt the malware to bypass Chrome’s effort to hide important user data. Other users have\r\nnoted KPot stealer has also updated its mechanisms to cope with the new update.\r\nhttps://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/\r\nPage 2 of 4\n\nWhat's Next?\r\nAZORult’s apparent demise – for now, at least – can also be tracked in Genesis. Following the methodology\r\noutlined in our latest research, we’re able to notice a turning point in the last week: for the first time in over a year,\r\nGenesis ditched AZORult and went all-in on a currently-unidentified trojan as the major infection type. This\r\nshowcases an important business principle: never have a single point of failure. The fact that Genesis was\r\ncultivating relationships with several malware providers just might have saved their business, as they were quickly\r\nable to fully pivot to a new malware.\r\nhttps://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/\r\nPage 3 of 4\n\na bar chart showing new infections in Genesis in the past week, broken down by infection type\r\nAZORult’s decommissioning in late 2018 was meant to leave a vacuum in the cybercrime financial ecosystem;\r\nmany new infostealers were publishing themselves as the new replacement for seemingly-dead malware. Now,\r\nwith no apparent heir to fix the deep issues caused by the new Chrome update, it seems that actors – if we’re\r\nextrapolating from Genesis – have actually decided to move on to new stealers. That is, of course, unless an actor\r\npicks up the AZORult source code and decides to adapt it to the new Chrome policies independently; a similar\r\napproach was taken by actors not long ago, when a new version of the stealer, coded in C++ opposed to its native\r\nDelphi, was found in active campaigns.\r\nOne interesting note to track would be AZORult’s non-infostealing features, which might not be affected by the\r\nChrome update – for example, it’s loader modules allowing spreading of other malware following  an AZORult\r\ninfection – shouldn’t be thwarted by the change in Chrome password encryption.\r\nFollowing our detailed methodologies and targeted Dark Net research, KELA plans to keep tabs on these changes\r\nin order to effectively defend our clients from commodity malware threats.\r\nSource: https://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/\r\nhttps://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://ke-la.com/whats-dead-may-never-die-azorult-infostealer-decommissioned-again/"
	],
	"report_names": [
		"whats-dead-may-never-die-azorult-infostealer-decommissioned-again"
	],
	"threat_actors": [],
	"ts_created_at": 1775434299,
	"ts_updated_at": 1775791312,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/18a8101ce5f59443fc2d43e54fabf738b3cee2b6.pdf",
		"text": "https://archive.orkl.eu/18a8101ce5f59443fc2d43e54fabf738b3cee2b6.txt",
		"img": "https://archive.orkl.eu/18a8101ce5f59443fc2d43e54fabf738b3cee2b6.jpg"
	}
}