{
	"id": "b289c8f1-9597-4511-9bdc-d91a521c9673",
	"created_at": "2026-04-06T00:18:17.33422Z",
	"updated_at": "2026-04-10T03:20:29.900466Z",
	"deleted_at": null,
	"sha1_hash": "e22cf459f532c5937759fef80e3833f2d0472c45",
	"title": "Botception with Necurs: Botnet distributes script with bot capabilities",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 282014,
	"plain_text": "Botception with Necurs: Botnet distributes script with bot\r\ncapabilities\r\nBy Adolf Streda \u0026 Jan Sirmer 4 May 2018\r\nArchived: 2026-04-05 16:53:47 UTC\r\nVBScript allows threat actors to steal personal data and make victims vulnerable to keyloggers, banking malware\r\nand ransomware\r\nOver the past few days, we have been analyzing a development with the Necurs botnet - a cybercrime operation\r\ndating back to 2012 that quickly became one of the largest spam botnets in the world. We reported on the\r\ninfamous cybergang responsible for the distribution of global malware campaigns such as “Locky” and\r\n“GlobeImposter” in two blog posts (here and here) that explained how malware is spread via Necurs. And now we\r\nhave seen a new link to that chain with attackers serving brand new files via the same botnet. These files are\r\nspreading malicious Visual Basic Scripts (VBScripts) and our analysis suggests that the authors are using the\r\nservices provided by the Necurs botnet to reach more victims. The ultimate goal of the attackers is to make\r\nsystems vulnerable to attacks with the ability to steal personal data and to infect them with keyloggers, banking\r\nmalware, and ransomware.\r\nAn examination of the source code suggests that the VBScripts are hosting a severe form of malware known as\r\nAgony Rootkit used to infect the Master Boot Record (MBR) of computers. This can be particularly destructive.\r\nBy infecting the MBR, the malware is able to execute before systems boot-up allowing it to bypass security\r\nsoftware. It then inserts a backdoor into the operating system which gives the attacker full control of the machine.\r\nWith these administrative rights, the attacker can install worms, keyloggers and other malicious files. They can\r\nalso access stored data including personal or financial information, putting users at risk.\r\nA deeper look inside the VBScripts distributed by Necurs\r\nBelow are examples of live VBScripts in action. At first glance, it appears to include random numerical\r\ncombinations that could be discarded as junk, possibly added to alter the code structure in order to evade\r\ndetection. However, we spent some time investigating the code via the decryption function and spotted some logic\r\nbehind its construction.  \r\nThe scripts themselves are around 72KB and are similar in composition except for some small changes in the\r\nobfuscation methods.\r\nhttps://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nPage 1 of 5\n\nA closer look at the code reveals some important information. We noticed that the function uses ReadLine on the\r\nfile itself to decrypt the control panel (below):\r\nThe script is really easy to deobfuscate; the only issue is comment removal — which is often present in analytical\r\ntools — that can mislead the analysts.\r\nAfter decrypting these comments, in version one, we spotted a nice piece of code which could be used as a\r\nmodeling example “How to write the control panel for your malware in VBS”. The next version is less self\r\nexplanatory and readable.\r\nIt's probable that the authors of VBScripts connected with the authors of the Necurs botnet because of its scale and\r\npotential for ubiquitous email scams. The scripts appear to work as a downloader and control panel for the Agony\r\nrootkit, however changing the payload is particularly easy. This could open the door to more severe malware\r\ninfections for victims in the future, such as ransomware or banking Trojans. \r\nThe malware control panel includes unusually beautiful code\r\nThe code itself contains very well-named variables and also debugging output to a log file. However, debugging is\r\nswitched off by default as the variable isDebug is set to false. The debugging output informs about every\r\nimportant subroutine and contains strings such as:\r\n\"Preparing done!\" (initialization and installation phase finished)\r\n\"Oh, its main cycle! CMD response\" \u0026 cmd (after receiving a new command)\r\n\"F***! Panel maybe die! I will try to change it...\" (new command has less than 4 characters)\r\n\"Unistall [sic] command gotted!\" (uninstall command received)\r\n\"Oh, its ddos command!\" (ddos command received)\r\n“ddos finished! Sended \"\u0026cnt\u0026\" requests!\" (ddos command finished)\r\nInterestingly, this makes this code unusually beautiful as one rarely stumbles upon a relatively well-structured and\r\n“commented” piece of code with self-documenting names, particularly when the subject is malware.\r\nhttps://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nPage 2 of 5\n\nAs well, the code reveals some important information about its creator. The author appears to have a problem with\r\nthe past tense of irregular verbs such as to get or to send. In addition, several log entries use incorrect English\r\nlanguage sentence construction, such as \"Panel maybe die!\".  It could suggest that the author’s first language is not\r\nEnglish, however this may well be staged.\r\nThe script initializes its variables such as Command and Control (C\u0026C) addresses, various paths and several\r\nobjects that are used to interface system functions. Then, the script tries to install itself to the folder %APPDATA%\r\nunder the names \u003cHWID\u003e.vbs, g_\u003cHWID\u003e.vbs_w.vbs (HWID being a random sequence of letters loaded from\r\nregistry or generated at startup), and possibly \u003cstatic_number_sequence\u003e_log.txt and relaunch itself from the\r\n%APPDATA% directory. After the initial installation, it checks whether another instance of the script is running.\r\nPersistence is key, so if only one instance is running, a task named ChromeUpdate is created to launch the first file\r\non user log on. Also, multiple registry entries that launch the script at startup are created. Otherwise, the script\r\nquits.\r\nOnce the script gets over the initialization, it has to ask the C\u0026C servers for commands and process them. That is\r\nwhere a traditional event loop comes in. Verification that the script is located in the %APPDATA% directory has\r\nto be passed first, otherwise agony is invoked six times before proceeding to the next iteration. Let us assume that\r\nthis test has passed. Now the script sends a POST request with a rather long GET data string, e.g.:\r\nos=Windows 10 Enterprise\u0026user=Evzen@DEMO-PC\u0026av=Avast AntivirusWindows Defender\u00267045Mb #\r\nIntel(R) Core(TM)CPU E5-2690 v4 @ 2.60GHz # Standard VGA Graphics\r\nAdapter\u0026hwid=AABBccddEEFFGGhhiiJJKKLLm\u0026x=64\r\nThe only fields that require some discussion are _fw_ and _hwid_. \"fw\" describes the hardware (specifically RAM\r\nsize # CPU info # GPU info), while \"hwid\" is a 25-character long random string generated at first launch and\r\nsaved into the registry at HKEY_CURRENT_USER\\Software\\ARRSSS.\r\nThe response contains a command. These commands have a very similar structure and every command triggers a\r\nconfirmation that is sent again as a POST request to the same address as a command request, however the data\r\nstring differs:\r\nok=\u003czid\u003e\u0026hwid=\u003chwid\u003e in case of success\r\nerror=\u003czid\u003e\u0026hwid=\u003chwid\u003e in case of an error\r\nThe value \u003czid\u003e is given by the command string. All available commands are listed below:\r\nCommand Command string Action\r\ndownload\r\ndownload!\u003curl\u003e!\r\n\u003czid\u003e\r\nDownload a file from \u003curl\u003e and execute it.\r\nhttps://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nPage 3 of 5\n\nupdate update!\u003curl\u003e!\u003czid\u003e Download a PE file from \u003curl\u003e, save it to %TEMP% and execute it.\r\nplugin plugin!\u003curl\u003e!\u003czid\u003e\r\nDownload a dll from \u003curl\u003e, save it to %TEMP% use RUNDLL32.exe\r\nto execute it.\r\nuninstall\r\nuninstall!\u003cdata\u003e!\r\n\u003czid\u003e\r\nReplace dropped files and a log by a file with one whitespace.\r\nddos ddos!\u003curl\u003e!\u003ccount\u003e Send \u003ccount\u003e POST requests to \u003curl\u003e.\r\nThe denial-of-service (DDoS) attack that can be caused with the above command initiated by this script also\r\ncarries some data. It seems that these attacks can be identified by the associated data, as all the scripts collected so\r\nfar have the POST data hard-coded:\r\nufgiweugdiqwfgqofwg=325872346782356786426526349865923659\r\nNow the script also ends up in several invocations of agony. The agony function serves three purposes. It checks\r\nwhether the script is running in the installation directory. The result only affects which copy of the scripts is\r\nlaunched if no instance of %APPDATA%\\\u003cHWID\u003e.vbs or g_%APPDATA%\\\u003cHWID\u003e.vbs_w.vbs is running, and\r\nthe log entry suggests that this is intended as a self-defense. Moreover, if the script is not named \u003cHWID\u003e.vbs and\r\nlocated in %APPDATA%, it overwrites its two files by \u003cstatic_number_sequence\u003e_log.txt and adds itself to\r\nstartup through registry entries:\r\nHKEY_CURRENT_USER\\software\\microsoft\\windows\\currentversion\\run\\\r\nHKEY_LOCAL_MACHINE\\software\\microsoft\\windows\\currentversion\\run\\\r\nHKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\\r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\r\nEvery agony ends up with 500 milliseconds of a blissful Sleep, a function suspending the code execution for a\r\ngiven time.\r\nVersion progression\r\nA new version, discovered approximately a day after the described script’s release, brought several updates. In the\r\nnew version, the payload is hidden beyond another .vbs file that acts as a downloader for the following stage.\r\nMoreover, its functions seem to have been refactored as e.g. the agony function is now removed in favour of a\r\nsimple Sleep and the detection of an antivirus installed on the system is now hidden in a function called func15.\r\nAlso, the script installs itself only to %APPDATA%/\u003cHWID\u003e.vbs, which simplifies checking for running\r\ninstances, which means that only one function is  necessary for checking.\r\nhttps://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nPage 4 of 5\n\nThe command structure is simplified to only include the functions download, update, and uninstall. The command\r\nupdate now expects a Visual Basic script, while update expects a Portable Executable (PE) file.\r\nThe last significant addition is a new function called psCommand that, as expected, executes a command in\r\nPowerShell. Currently, this is only used in the initialization.\r\nVBS decryptor: 0089A6E7E92B75952F5C2E3A04A7AB65133F4CCA732BC96ECB0A34389D8FC7F4 (v1)\r\nDae17df6225f05e99bf0e84b3a8438560befc7eb6bd07a7b4d4e451ec33b6a5f (v2)\r\nVBS control panel:\r\n3011126B5210298D843D6D3B84143BE292633A4A7C0D14E947AE6BE11B74CE2F (v1)\r\n676abca2210742e57b432558276b616b1e4e5286c772aed8c63efed230ff2430 (v2)\r\nSource: https://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nhttps://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://blog.avast.com/botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs"
	],
	"report_names": [
		"botception-with-necurs-botnet-distributes-script-with-bot-capabilities-avast-threat-labs"
	],
	"threat_actors": [],
	"ts_created_at": 1775434697,
	"ts_updated_at": 1775791229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e22cf459f532c5937759fef80e3833f2d0472c45.pdf",
		"text": "https://archive.orkl.eu/e22cf459f532c5937759fef80e3833f2d0472c45.txt",
		"img": "https://archive.orkl.eu/e22cf459f532c5937759fef80e3833f2d0472c45.jpg"
	}
}