{
	"id": "eb3307c0-fb36-43de-8345-f1284e020058",
	"created_at": "2026-04-06T00:21:26.167082Z",
	"updated_at": "2026-04-10T13:11:39.008777Z",
	"deleted_at": null,
	"sha1_hash": "70410c67f83b9a984c8d3005ea974a919871a82d",
	"title": "Avzhan DDoS bot dropped by Chinese drive-by attack | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 356881,
	"plain_text": "Avzhan DDoS bot dropped by Chinese drive-by attack |\r\nMalwarebytes Labs\r\nBy hasherezade\r\nPublished: 2018-02-22 · Archived: 2026-04-05 14:06:15 UTC\r\nThe Avzhan DDoS bot has been known since 2010, but recently we saw it in wild again, being dropped by a\r\nChinese drive-by attack. In this post, we’ll take a deep dive into its functionality and compare the sample we\r\ncaptured with the one described in the past.\r\nAnalyzed sample\r\n05749f08ebd9762511c6da92481e87d8 – The main sample, dropped by the exploit kit\r\n5e2d07cbd3ef3d5f32027b4501fb3fe6 – Unpacked (Server.dll)\r\n05dfe8215c1b33f031bb168f8a90d08e – The version from 2010 (reference sample)\r\nBehavioral analysis\r\nInstallation\r\nAfter being deployed, the malware copies itself under a random name into a system folder, and then deletes the\r\noriginal sample:\r\nIts way to achieve persistence is by registering itself as a Windows Service. Of course, this operation requires\r\nadministrator rights, which means for successful installation, the sample must run elevated. There are no UAC\r\nbypass capabilities inside the bot, so it can only rely on some external droppers, using exploits or social\r\nengineering.\r\nExample of added registry keys, related to registering a new service:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 1 of 14\n\nWe find it also on the list of the installed services:\r\nThe interesting thing was also that the dropped main sample was infected with another malware, Virut – a very old\r\nfamily (and crashing on 64 bit systems). Once it was deployed, it started to infect other executables on the disk.\r\nMore about Virut we will cover in another post.\r\nNetwork traffic\r\nWe can see that the bot connects to its CnC:\r\nLooking at the network traffic, we see the beacon that is sent. It is in a binary format and contains information\r\ncollected about the victim system:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 2 of 14\n\nThe beacon is very similar to the one described in 2010 by Arbor Networks here. The server responds with a\r\nsingle NULL byte.\r\nDuring the experiments, we didn’t capture traffic related to the typical DDoS activities performed by this bot.\r\nHowever, we can see such capabilities clearly in the code.\r\nInside the sample\r\nStage 1: the loader\r\nThe sample is distributed in a packed form. The main sample’s original name is Cache.dat, and it exports one\r\nfunction: Ip.\r\nLooking inside the Ip, we can easily read that it creates a variable, fills it with strings, and then returns it:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 3 of 14\n\nThose are the same parameters that we observed during the behavioral analysis. For example, we can see that the\r\nservice name is “Nationalscm” and the referenced server, probably CnC is: wm.shiquanxian.cn:8080 (that resolves\r\nto: 103.85.226.65:8080). So, this is likely the function responsible for filling those parameters and passing them\r\nfurther.\r\nThe main function of this executable is obfuscated, and the flow of the code is hard to follow—it consists of small\r\nchunks of code connected by jumps, in between of which junk instructions are added:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 4 of 14\n\nHowever, just below the function Ip, we see another one that looks readable:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 5 of 14\n\nLooking at its features, we see that it is a good candidate for a function that actually unpacks and installs the\r\npayload in the following process:\r\n1. It takes some hardcoded buffer and processes it—that looks like de-obfuscating the payload.\r\n2. It searches a function “StartupService” in the export table of the unpacked payload—it gives us hint that\r\nthe unpacked content is a PE file.\r\n3. Finally, it calls the found function within the payload.\r\nWe can confirm this by observing the execution under the debugger. After the decoding function was called, we\r\nsee that indeed the buffer becomes a new PE file:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 6 of 14\n\nAt this moment, we can dump the buffer, trim it, and analyze it separately. It turns out that this is the core of the\r\nbot, performing all of the malicious operations. The PE file is in the raw format, so no unmapping is needed.\r\nFurther, the loader will allocate another area of memory and map there the payload into the Virtual Format so that\r\nit can be executed.\r\nAnti-dumping tricks\r\nThis malware uses few tricks to evade automated dumpers. First of all, the payload that is loaded is not aligned to\r\nthe beginning of the page:\r\nIf we dump it at this moment, we would also need to unmap it (i.e. by pe_unmapper) because this time it is in the\r\nVirtual Format. However, there are some unpleasant surprises: The relocation table and resources have been\r\nremoved after use by the loader. This is why it is usually more reliable to dump the payload before it is mapped.\r\nHowever, some of the data inside the payload may be also filled on load. So if we don’t dump both versions, we\r\nmay possibly miss some information.\r\nIn the version from 2010, the outer layer is missing. The malware is distributed via a single executable that is an\r\nequivalent of the payload unpacked from the current sample.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 7 of 14\n\nStage 2: the core\r\nBy following the aforementioned steps, we obtain the core DLL, named Server.dll. We find that the core is pretty\r\nold—this hash was seen for the first time on VirusTotal more than a year ago. However, it was not described in\r\ndetail at that time, so I think it is still worth analyzing.\r\nThe sample from 2010, in contrast, is not a DLL but a standalone EXE. Yet, looking at the strings and comparing\r\nboth with the help of BinDiff, we can see striking similarities that prove that the core didn’t evolve much.\r\nExecution flow\r\nThe execution starts in the exported function: StartupServer. At the beginning, the sample calls\r\nOutputDebugStringA with non-ascii content. What’s interesting is that the content is not random. The same bytes\r\nwere used previously in the loader, just before executing the function within the payload. Yet, its purpose remains\r\nunknown.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 8 of 14\n\nIt also tries to check if the current DLL has been loaded by the main module that exports a function “Ip.” If it is\r\nso, it calls it:\r\nAs we remember, the function with exactly this name was exported by the outer layer. It was supposed to retrieve\r\nthe configuration of the bot, such as the CnC address and Windows Service name. After being retrieved, the data\r\ngets copied into the bot’s data section (the configuration gets hardcoded into the bot).\r\nAfter that, the malware proceeds with its main functionality. We can see that the data that got retrieved and\r\nhardcoded is later being passed to the function installing the service:\r\nBased on the presence of the corresponding registry keys, the malware distinguishes if this is its first run or if it\r\nhad already been installed. Depending on this information, it can take alternative paths.\r\nIf the malware was not installed yet, it proceeds with the installation and exits afterward:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 9 of 14\n\nOtherwise, it runs its main service function:\r\nThe main service function is responsible for communication with the CnC. It deploys a thread that reads\r\ncommands and deploys appropriate actions:\r\nFunctionality\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 10 of 14\n\nFirst the bot connects to the CnC and sends a beacon containing information gathered about the\r\nvictim system:\r\nThe information gathered is detailed, containing processor features as well as the Internet speed. We saw this data\r\nbeing sent during the behavioral analysis.\r\nAfter the successful beaconing, it deploys the main loop, where is listens for the commands from the CnC, parses\r\nthem, and executes:\r\nAs we can see, the malware can act as a downloader—it can fetch and deploy a new executable from the link\r\nsupplied by the CnC:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 11 of 14\n\nThe CnC can also push an update of the main bot, as well as instruct the bot to fully remove itself.\r\nBut the most important capabilities lie in few different DDoS attacks that can be deployed remotely on any given\r\ntarget. The target address, as well as the attack ID, are supplied by the CnC.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 12 of 14\n\nAmong the requests that are prepared for the attacks, we can see the familiar strings, whose purpose was already\r\ndescribed in the report from 2010. We can see the malformed GET request:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 13 of 14\n\nAs an alternative, it may use one of the valid GET requests, for example:\r\nThe flooding function is deployed in a new thread, and repeats the requests in a loop until the stop condition is\r\nenabled. Example:\r\nConclusion\r\nThis bot is pretty simple, prepared by an unsophisticated actor. Featurewise, it hasn’t changed much\r\nover years. The only additions were intended to obfuscate the malware and give an ability to add the\r\nconfiguration by the outer layer.\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2018/02/avzhan-ddos-bot-dropped-by-chinese-drive-by-attack/"
	],
	"report_names": [
		"avzhan-ddos-bot-dropped-by-chinese-drive-by-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434886,
	"ts_updated_at": 1775826699,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/70410c67f83b9a984c8d3005ea974a919871a82d.pdf",
		"text": "https://archive.orkl.eu/70410c67f83b9a984c8d3005ea974a919871a82d.txt",
		"img": "https://archive.orkl.eu/70410c67f83b9a984c8d3005ea974a919871a82d.jpg"
	}
}