{
	"id": "808e2988-3f7d-4d0f-93d6-b628bafe97d2",
	"created_at": "2026-04-06T00:10:59.688583Z",
	"updated_at": "2026-04-10T13:11:34.75837Z",
	"deleted_at": null,
	"sha1_hash": "cb9fc523410acbb7492c93e72a6322071323ea68",
	"title": "BE2 extraordinary plugins, Siemens targeting, dev fails",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 557208,
	"plain_text": "BE2 extraordinary plugins, Siemens targeting, dev fails\r\nBy Kurt Baumgartner\r\nPublished: 2015-02-17 · Archived: 2026-04-05 18:30:41 UTC\r\nOur November post introducing our BlackEnergy2 (BE2) research described new findings on the group’s activity.\r\nWe presented both details on their plugins and significant findings about some of their targets and victims. In this\r\npost, let’s examine several additional plugins more closely, targeting details around BE2 Siemens exploitation, and\r\nsome of their unusual coding failures.\r\nWe previously introduced an unknown set of plugins and functionality for the linux platform, six in total. For the\r\nwindows platform, we collected 17 plugins. The last post noted the difficulty in collecting on this group. We finish\r\ndescriptions for our set in this post.\r\nbs\r\ncert\r\ndstr\r\nfs\r\ngrc\r\njn\r\nkl\r\nprx\r\nps\r\nrd\r\nscan\r\nsn\r\nss\r\ntv\r\nupd\r\nusb\r\nvsnet\r\nWe also collected plugins for the MIPS/ARM architectures, as noted in the previous BE2 post.\r\nweap\r\nps\r\nnm\r\nsnif\r\nhook\r\nuper\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 1 of 11\n\nLet’s first examine some of the newest and most surprising Windows plugins. It’s interesting that all of these\r\nplugins use a custom “FindByHash” function to evade detection schemes and to slow analysis…\r\nThe “Destroy” plugin, dstr\r\nName dstr.dll\r\nMD5 8a0a9166cd1bc665d965575d32dfa972\r\nType Win32 DLL\r\nSize 26,474 bytes\r\nCompiledOn 2014.06.17 08:42:43\r\nThe most troubling plugin in the list is the “dstr” plugin. It is a Windows-only plugin. It was used to overwrite\r\ndata by the BE2 actor, destroying data stored on hard drives by overwriting file contents. While its use may be\r\nintended to cover their tracks, it is heavy handed to use this type of tool to cover one’s tracks in a network. Most\r\nlikely it is a tool of sabotage, much like the Destover wiper seen on Sony Pictures Entertainment’s networks.\r\nHowever, it’s interesting that the BE2 developers created wiper code different from the Destover and Shamoon\r\nwiper malware we saw in the Saudi Aramco and SPE attacks. Instead of re-using the commercial EldoS RawDisk\r\ndrivers in their malware, the BE2 developers wrote their own low-level disk and file destruction routines. It’s also\r\na much more chilling deployment of wipers – instead of a poorly defended media studio, it was delivered to ICS\r\nenvironments.\r\nIn order to overwrite stored data on all Windows versions, the dstr plugin supports both user-mode and kernel-mode wiper functionality, which is somewhat surprising. The component maintains both an embedded win32\r\nlibrary and win64 driver modules for its kernel mode functionality. They are rc4 encrypted.\r\nUser-mode functionality\r\nThe plugin identifies device id’s for the system’s HDD and creates a handle to the system’s physical drive, with\r\n“GENERIC_READ or GENERIC_WRITE” access. Several calls to DeviceIoControl collects data on the physical\r\nlocation of the volume, and the size and properties of this disk. It uses DeviceIoControl with the\r\nIOCTL_DISK_GET_DRIVE_GEOMETRY control code in order to retrieve Bytes Per Sector value. dstr then\r\nwipes out all open handles to the disk by dismounting it with the FSCTL_DISMOUNT_VOLUME control code.\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 2 of 11\n\nThis routine prepares the system for overwrite and ensures no conflicts for plugin file I/O. Then it makes multiple\r\nWriteFile calls to write a zeroed out buffer to disk.\r\nThe dstr plugin maintains code for unlocking and deleting the BE2 driver from disk, furthering the group’s goal of\r\nkeeping their traces hidden from researchers. And notice the FindByHash set of calls above, this sfc_os call\r\ndisables Windows File Protection for a minute while an application can delete or modify the locked file. So this\r\nplugin and its call can proceed and delete the driver.\r\nThe plugin looks over all the services in the %system32%\\drivers folder and checks the write permission. If\r\naccess is provided, it unlocks the file, rewrites the embedded driver under the existing driver name and launches it.\r\nDrivers and kernel mode functionality\r\nDecrypted 32-bit driver\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 3 of 11\n\nName driver.sys\r\nMD5 c4426555b1f04ea7f2e71cf18b0e5b6c\r\nType Win32 driver\r\nSize 5,120 bytes\r\nCompiledOn 2014.06.10 13:12:22 GMT\r\nDecrypted 64-bit driver\r\nName driver.sys\r\nMD5 2cde6f8423e5c01da27316a9d1fe8510\r\nType Win64 driver\r\nSize 9,136 bytes\r\nCompiledOn 2014.06.10 13:12:04 GMT\r\nThe 32-bit and 64-bit drivers are identical and compiled from the same source code. These small Windows drivers\r\nare supposed to support FAT32 and NTFS file systems, and contain two large code implementation mistakes. In\r\nspite of these flaws, it is clear that the author’s goal was to parse a file system and then write random data across\r\nfiles.\r\nThese coding fails are unique to this dstr plugin, suggesting a development team effort behind the plugin set code.\r\nFail #1: The authors reversed the routines for FAT32 and NTFS data wiping when checking the presence of the\r\n“FAT32” string in the first 1024-bytes of the system drive.\r\nFail #2: In the FAT32 routine the Root Directory Sector Number is calculated and is dealt as the absolute offset\r\ninside the file rather than next multiplying this number by the bytes per sector\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 4 of 11\n\nIn comparison, there is no such mistake in the NTFS routine and the calculation of the MFT offset is implemented\r\nproperly:\r\nGoal – File Content Corruption\r\nApart from that, it is interesting that the authors implement NTFS wiping in an unusual way with strange logic\r\ncompared to FAT32 ‘straightforward’ wiping. The plugin accomplishes checks for FILE records and at first skips\r\nthem. Then under certain conditions it rewrites non-FILE record sectors with random buffer which probably\r\ncorresponds to some file contents and proceeds looping. Then it ends up rewriting the first sectors of MFT and\r\nMFT mirror.\r\ngrc, plus.google.com replacement communications plugin\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 5 of 11\n\nName grc.dll\r\nMD5 ee735c244a22b4308ea5d36afee026ab\r\nType Win32 DLL\r\nSize 15,873 bytes\r\nCompiledOn 2013.09.25 07:19:31\r\nThis plugin creates a backup communications channel to yet another legitimate service. Most likely this backup\r\nchannel is used to cloak outbound communications on monitored networks. We have seen APT using everything\r\nfrom Twitter to Google Docs to hide communications in plain sight, and this time the abused service is Google\r\nPlus.\r\nThis plugin implements the standard Windows HTTP services to interact with Google Plus over https, seeking to\r\nfind a png file.\r\nThe plugin is provided with a specific Google Plus id to connect with, and uses the OLE stream Windows\r\nstructured storage API along with the GDI+ bitmap functions to handle and parse this png file. This png file\r\ncontent is actually encrypted data containing the new BE configuration file just as it was obtained using ‘normal’\r\nC\u0026C communication.  It is encrypted with RC4, just like the embedded dstr drivers. But unlike to the ‘typical’\r\nRC4 BE decryption scheme that uses RC4 once, here it uses RC4 three times: once with hardcoded key found in\r\nthe grc binary, the second time using the key extracted from the previous decrypted result, and the third time using\r\nthe ‘id’ machine’s identifier that is normally served as the encryption key during the C\u0026C communication.\r\nUniversal serial bus data collection plugin, usb\r\nName usb.dll\r\nMD5 0d4de21a2140f0ca3670e406c4a3b6a9\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 6 of 11\n\nType Win32 DLL\r\nSize 34,816 bytes\r\nCompiledOn 2014.03.21 07:02:48\r\nThe usb plugin collects all available information on connected USB drives, and writes out all of these details to a\r\ntext file, packs it, provides to the main BlackEnergy code, which communicates to a c2.\r\nIt uses multiple api calls to collect information on multiple types of connected usb storage devices. It enumerates\r\nall usb storage devices connected to the system and retrieves data from all, including SCSI mass storage devices.\r\nAnd, most interestingly, it may be the first implementation of BadUSB-related techniques in APT re-purposed\r\nCOTS malware that we have seen in the wild.\r\nThe code queries scsi devices directly and sends them two types of SCSI commands. The first command with the\r\nopcode 0x1A which corresponds to MODE SENSE may result just in the logging of the failed call\r\n(‘SendSCSICommand return false’ message).\r\nThe second type of SCSI command remains mysterious. It uses undefined opcode 0xf0 and there is no direct\r\nevidence of its purpose as it is stated to be vendor specific. This mysterious opcode is referenced around the same\r\ntime frame of the plugin development in BadUSB offensive research\r\nhttp://algorithmics.bu.edu/twiki/bin/view/EC521/SectionA1/Group5FinalReport. Here, it is noticed in the USB\r\ntraffic generated by an SMI controller tool. To be specific, there are two calls with the opcode 0xf0 in the code,\r\neach passed its own parameters. One of the parameters, 0x2A, is mentioned in the paper to return the string\r\ncontaining the firmware version, NAND flash ID, and controller part number. But this returned information is not\r\nlogged anywhere.\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 7 of 11\n\nAlso the code loops to retrieve detailed physical data about every attached storage device:\r\nnumber of cylinders\r\nmedia type (floppy, fixed hard drive, removable media, etc)\r\nnumber of tracks per cylinder\r\nsectors per track\r\nnumber of bytes per sector\r\nphysical disk size in bytes\r\nDevice Instance ID\r\nMotherboard and firmware data collection plugin, bios\r\nName bs.dll\r\nMD5 4747376b00a5dd2a787ba4e926f901f4\r\nType Win32 DLL\r\nSize 210,432 bytes\r\nCompiledOn 2014.07.29 00:40:53\r\nThe bios plugin gathers low level host system information:\r\nBIOS\r\nmotherboard\r\nprocessor\r\nOS\r\nIt uses several techniques to gather this information:\r\nWMI\r\nCPUID\r\nwin32 api\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 8 of 11\n\nAs a Windows Management Instrumentation (WMI) client application, it initializes COM and connects to the\r\n\\\\root\\cimv2 namespace to use the IWbemServices pointer and make WMI requests. The code executes wql\r\nqueries (“wql” is “sql for wmi”, a subset of sql) to gather victim host details, like the query “SELECT Description,\r\nManufacturer, Name, ProcessorId FROM Win32_Processor”. Here are several queries from the BlackEnergy2\r\nplugin code:\r\nSELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor\r\nSELECT Product, Manufacturer, Version FROM Win32_BaseBoard\r\nSELECT Name, OSArchitecture, Version, BuildNumber FROM Win32_OperatingSystem\r\nSELECT SerialNumber, Description, Manufacturer, SMBIOSBIOSVersion FROM Win32_BIOS\r\nThese wql calls provide the attacker with the data like the lines below:\r\nDescription=Intel64 Family 6 Model 60 Stepping 3\r\nManufacturer=GenuineIntel\r\nName=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz\r\nProcessorId=1FEAFBCF000116A9\r\nProduct=7MPXM1\r\nManufacturer=AsusTek\r\nVersion=??\r\nName=Microsoft Windows 8.1 Pro\r\nOSArchitecture=64-bit\r\nVersion=6.3.9600\r\nBuildNumber=9600\r\nSerialNumber=7DTLG45\r\nDescription=A12\r\nManufacturer=AsusTek\r\nSMBIOSBIOSVersion=A12\r\nThis selectivity is fairly usual. And the plugin does not modify its own behavior based the collected values. What\r\ncan we infer about the selection of only these values, as they are only being collected and sent back to the\r\nattackers? Here are some possibilities:\r\nthe attackers want to evade sandbox and honeypot/decoy environments, and use this collected data to id the\r\nhost system.\r\nthe attackers have prior knowledge of the environment they are attempting to penetrate, down to the\r\nequipment make. Or, they have an idea of the types of hardware they would expect or want to see. In ICS\r\nand SCADA environments, these details could be very valuable for an attacker setting up shop. These\r\ndetails could aid in establishing persistence, evaluating true resource capacity and capabilities, tracking\r\ndown the source of the equipment, or aiding further lateral movement\r\nthe attackers know nothing about the network they are penetrating. They are collecting this information to\r\nbetter understand where this plugin really is running in the victim environment and planning their next\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 9 of 11\n\nmoves\r\nWhen using standard win32 api, the application implements calls to retrieve information on system locales. Oddly,\r\nthere is special handling for one nordic locale in this particular plugin, “Norwegian-Nynorsk”.\r\nThe CPU data collection functionality first calls the Intel cpuid instruction directly. It also directly handles multi-cpu systems and each of their feature sets. This SMP support is hard coded into the plugin.\r\nAdditional BE2 Siemens Exploitation Details\r\nTargeting details for BE2 actor events are interesting. When focusing on research sites and energy engineering\r\nfacilities, the group remotely exploited Siemens’ Simatic WinCC systems. In these events, the attackers attempted\r\nto force the ccprojectmgr.exe process to download and execute a specific BlackEnergy2 payload. Let’s examine a\r\ncouple of example targets here. Based on the different delays for return, the attacks were possibly not automated.\r\nTarget A:\r\nThe first exploit attempt ksn recorded was March 2014. The attackers returned with a second failed attempt to\r\nexploit that same research system on April 2014, approximately 30 days, 2 hours later.\r\nTarget B:\r\nThe BE2 actor then attacked a new target system in May 2014 and failed, and returned with an exploit attempt on\r\nthat same system in July 2014.\r\nSo it looks like there may be a timing cycle to their visits, but the volumes here are too low to be significant.\r\nIn all four of these attempts on two different targets, the attackers tried to download their payload from\r\nhxxp://94.185.85(dot)122/favicon.ico. The payload changed slightly from March 2014 to the very end of July\r\n2014, presenting the following md5(s). All of these droppers are BE2 malware, modify an existing kernel driver\r\nservice like “ACPIEC” and start it to load the BE2 kernel module. Note that the attackers planned on re-using the\r\nsame c2 for the first target, but changed the callback c2 for the second target. None of these components are\r\nsigned:\r\nfda6f18cf72e479570e8205b0103a0d3 → drops df84ff928709401c8ad44f322ec91392, driver, debug\r\nstring:”xxxxxxxx.pdb”. C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)\r\nfe6295c647e40f8481a16a14c1dfb222 → drops 39835e790f8d9421d0a6279398bb76dc, driver, debug\r\nstring:”xxxxxxxx.pdb”. C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)\r\nac1a265be63be7122b94c63aabcc9a66 → drops b973daa1510b6d8e4adea3fb7af05870, driver. C2:\r\n95.143.193.131 (SE, Internetport Sweden AB, AS49770)\r\n8e42fd3f9d5aac43d69ca740feb38f97 → drops f4b9eb3ddcab6fd5d88d188bc682d21d, driver. C2: 46.165.222.6\r\n(DE, Leaseweb Germany GmbH, AS16265)\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 10 of 11\n\nSource: https://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nhttps://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://securelist.com/be2-extraordinary-plugins-siemens-targeting-dev-fails/68838/"
	],
	"report_names": [
		"68838"
	],
	"threat_actors": [],
	"ts_created_at": 1775434259,
	"ts_updated_at": 1775826694,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cb9fc523410acbb7492c93e72a6322071323ea68.pdf",
		"text": "https://archive.orkl.eu/cb9fc523410acbb7492c93e72a6322071323ea68.txt",
		"img": "https://archive.orkl.eu/cb9fc523410acbb7492c93e72a6322071323ea68.jpg"
	}
}