{
	"id": "84615136-a01d-4ef1-b850-8eab70b92a74",
	"created_at": "2026-04-06T00:10:15.30364Z",
	"updated_at": "2026-04-10T03:21:44.063183Z",
	"deleted_at": null,
	"sha1_hash": "57bb75ce21eb80adb738d1ef78fcc8a92bac4084",
	"title": "Emotet Evolves With new Wi-Fi Spreader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 264121,
	"plain_text": "Emotet Evolves With new Wi-Fi Spreader\r\nBy Binary Defense\r\nArchived: 2026-04-05 23:02:25 UTC\r\nEmotet is a highly sophisticated trojan that typically also serves as a loader for other malware. A key functionality of Emotet\r\nis its ability to deliver custom modules or plugins that are suited for specific tasks, including stealing Outlook contacts, or\r\nspreading over a LAN. Recently, Binary Defense has identified a new loader type that takes advantage of the wlanAPI\r\ninterface to enumerate all Wi-Fi networks in the area, and then attempts to spread to these networks, infecting all devices\r\nthat it can access in the process (as seen in Figure 1).\r\nclass=\r\nFigure 1 Wi-Fi spreader overview\r\nEmotet’s Protocol\r\nBefore getting into the analysis, Emotet’s Protocol should be explained. The protocol is based on Google’s Protobufs to\r\nserialize data sent to and from the server. The documentation for Protobufs shows that data is defined through the use of\r\nprotocol buffer message types in a .proto file. While Emotet uses several of these “messages”, the one this analysis will be\r\nfocusing on is the Deliverable message, which is used when the server sends a response containing data to be\r\nloaded/executed. The message is as follows:\r\nmessage Deliverable {\r\n    required int32 ID = 1;\r\n     required int32 executeFlag = 2;\r\n     required bytes blob = 3;\r\n}\r\nIn the above protobuf message, ID is the module ID, blob is the binary data, and executeFlag determines how the binary\r\nloaded. The executeFlag field can be one of the following:\r\n1: Reserved for payloads and standalone executables, like Trickbot. Drops in C:ProgramData and executes.\r\n2: Like Type 1, but duplicates user's token.\r\n3: Loads the binary into memory. Typically used by modules, as they are mainly DLLs which can be easily loaded\r\ninto memory.\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 1 of 8\n\nInitial Binary\r\nThe initial binary for the Wi-Fi spreader arrives on a system with module ID: 5079 and executeFlag: 1, which means it will\r\nbe dropped into C:ProgramData before executing, like loader updates or other malware, like TrickBot. This initial binary is\r\na self-extracting RAR file which contains the 2 binaries used for Wi-Fi spreading.\r\nclass=\r\nFigure 2 RAR Extraction\r\nThe self-extracting RAR contains 2 files: service.exe and worm.exe. Worm.exe is configured as the setup file, as seen in\r\nFigure 2, for the self-extracting RAR, which means worm.exe will execute automatically once the RAR file has unpacked\r\nitself.\r\nWorm.exe\r\nWorm.exe is the main executable used for spreading. This executable has a timestamp of 04/16/2018 and was first submitted\r\nto VirusTotal on 05/04/2018. The executable with this timestamp contained a hard-coded IP address of a Command and\r\nControl (C2) server that was used by Emotet. This hints that this Wi-Fi spreading behavior has been running unnoticed for\r\nclose to two years. This may be in part due to how infrequently the binary is dropped. Based on our records, 01/23/2020 was\r\nthe first time that Binary Defense observed this file being delivered by Emotet, despite having data going back to when\r\nEmotet first came back in late August of 2019.\r\nOperation of Worm.exe\r\nUpon startup of Worm.exe, the first action it takes is to copy the service.exe string to a variable that will be used during file\r\nspreading. Next, it steps into the main loop and immediately begins profiling the wireless network using wlanAPI.dll calls in\r\norder to spread to any networks it can access, as seen in Figure 3.\r\nA screenshot of a computer Description automatically generated\r\nFigure 3 Worm.exe Start\r\nThe use of purely wlanAPI.dll calls for network profiling makes sense; it is one of the libraries used by Native Wi-Fi to\r\nmanage wireless network profiles and wireless network connections. A possibly unintended consequence of this is that\r\nresearchers running this malware in VMs/automated sandboxes will not see any of worm.exe’s spreading behavior if a Wi-Fi\r\ncard is not present. This can be bypassed partially by starting the WLAN auto config service in Windows 10; however, this\r\nonly allows opening a handle to interface with. The subsequent calls will crash the program at that point, so the bypass is not\r\nrecommended.\r\nWorm Information Gathering\r\nAs seen in Figure 3, once a handle has been obtained, WlanEnumInterfaces is called. This function enumerates all Wi-Fi\r\ndevices currently enabled on the local computer, which it returns in a series of structures. These structures contain all the\r\ninformation relating to the Wi-Fi device, including the device’s GUID and description.\r\nUsing the first available Wi-Fi device, WlanGetAvailableNetworkList is called to obtain a list of all available networks.\r\nInterestingly, this has the dwFlag parameter set to\r\nWLAN_AVAILABLE_NETWORK_INCLUDE_ALL_ADHOC_PROFILES, which is an invalid parameter on Windows\r\nXP with SP3 and Wireless LAN API for Windows XP with SP2, meaning this malware cannot properly run on Windows XP.\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 2 of 8\n\nNext, the malware begins profiling the network, saving the following information to a buffer:\r\nSSID:               %s\r\nSIGNAL:             %d\r\nSECURITY:           [WPA|WPA2|UNKNOWN|WEP|OPEN]\r\nencryption:         [UNKNOWN|WEP104|CCMP|TKIP|WEP40|NONE]\r\nNote: [Current Connecting| OR\r\n      WLAN_AVAILABLE_NETWORK_HAS_PROFILE| OR\r\n      WLAN_AVAILABLE_NETWORK_CONSOLE_USER_PROFILE]\r\nThis information is gathered for every available network in the list of networks. Then, a massive switch case used to handle\r\nconnection notifications is passed to the Wi-Fi device using WlanRegisterNotification. Finally, the network authentication\r\nmethod is obtained and encryption is parsed again. This can be one of the following:\r\nWPA2PSK\r\nWPAPSK\r\nUNKNOWN\r\nWEP\r\nOPEN\r\nThe encryption method can be one of the following:\r\nTKIP\r\nNOEN (None misspelled)\r\nWEP\r\nAES\r\nclass=\r\nFigure 4 Worm Generating Network Profile\r\nWorm Connection Brute-Forcing\r\nAs seen in Figure 4, once each the information for each network has been obtained, the malware moves into the connection,\r\nbrute-forcing loops. The first step is to zero out two important flags and then to use the data obtained to fill in the below\r\ntemplate that will be used to create the Network Profiles:\r\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\r\n     \u003cWLANProfile \u003e      \u003cname\u003e%s\u003c/name\u003e\r\n     \u003cSSIDConfig\u003e\r\n          \u003cSSID\u003e\r\n               \u003cname\u003e%s\u003c/name\u003e\r\n          \u003c/SSID\u003e\r\n     \u003c/SSIDConfig\u003e\r\n     \u003cconnectionType\u003eESS\u003c/connectionType\r\n\u003cconnectionMode\u003eauto\u003c/connectionMode\u003e\r\n     \u003cMSM\u003e\r\n          \u003csecurity\u003e\r\n               \u003cauthEncryption\u003e\r\n                     \u003cauthentication\u003e%s\u003c/authentication\u003e\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 3 of 8\n\n\u003cencryption\u003e%s\u003c/encryption\u003e\r\n                     \u003cuseOneX\u003efalse\u003c/useOneX\u003e\r\n               \u003c/authEncryption\u003e\r\n               \u003csharedKey\u003e\r\n                     \u003ckeyType\u003epassPhrase\u003c/keyType\u003e\r\n                     \u003cprotected\u003efalse\u003c/protected\u003e\r\n                     \u003ckeyMaterial\u003e%s\u003c/keyMaterial\u003e\r\n               \u003c/sharedKey\u003e\r\n          \u003c/security\u003e\r\n     \u003c/MSM\u003e\r\n\u003c/WLANProfile\u003e\r\nIn the keyMaterial field, a password obtained from one of two internal password lists is used. Next, the profile is set and a\r\nconnection is attempted.\r\nIf the connection results in “wlan_notification_acm_network_available”, NetworkAvailableFlag is set to 1.\r\nIf the connection results in “wlan_notification_msm_connected”, NetworkAvailableFlag and NetworkConnectedFlag\r\nare both set to 1.\r\nIf the connection is not successful, NetworkAvailableFlag and NetworkConnectedFlag are both set to 0, and the\r\nfunction loops after moving to the next password in the password list.\r\nIf the connection is successful, the malware sleeps for 14 seconds before sending an HTTP POST to its Command and\r\nControl (C2) server at 87.106.37[.]146 on port 8080. The resource requested is a static, hard-coded value:\r\n87.106.37[.]146:8080/230238982BSBYKDDH938473938HDUI33/index.php\r\nThe data contained in the POST is:\r\nc=\u003cWirelessNetworkConnected\u003e:\u003cPassword\u003e\r\nOnce a connection is established with the Wi-Fi network, worm.exe begins enumerating users and attempting to brute-force\r\npasswords for all users on the network.\r\nclass=\r\n            Figure 5 Enumerating all non-hidden shares\r\nWorm User Brute-Forcing\r\nWith the infected victim now connected to a new network, the malware begins enumerating all non-hidden shares on the\r\nnetwork, as seen in Figure 5. Once shares have been discovered, the malware attempts to connect to the IPC$ share for the\r\nnetwork resources. Using IPC$, it attempts to enumerate all users connected to the network resource. Using the second\r\npassword list contained in the malware, the malware attempts to then brute-force its way into all users enumerated, saving\r\neach successful attempt to 2 buffers: one for the username and one for the password.\r\nIf it is unable to guess passwords for any users, it pivots to attempting to brute-force the “Administrator” account for the\r\nnetwork resource.\r\nIf either of these brute-force attempts are successful, it then moves onto the spreader function.\r\nSpreader\r\nclass=\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 4 of 8\n\nFigure 6 Connecting and generating “my.exe”\r\nWith buffers containing either a list of all usernames successfully brute-forced and their passwords, or the Administrator\r\naccount and its password, worm.exe can now begin spreading service.exe to other systems.\r\nThe malware first attempts to gain access to the C$\\ share for the connected network resource. This gives it access to the C\r\ndrive of the specified username. From there, it drops service.exe as my.exe in C:\\, as seen in Figure 6. Additionally, it adds a\r\nnew service with the following information using the recently dropped my.exe.\r\nBinary Path Name: C:\\my.exe\r\nDesired Access: SERVICE_ALL_ACCESS\r\nDisplay Name: WinDefService\r\nService Name: Windows Defender System Service\r\nIt then starts this service, executing service.exe as my.exe on a remote system.\r\nService.exe\r\nService.exe is the infected payload installed on remote systems by worm.exe. This binary has a PE timestamp of\r\n01/23/2020, which was the date it was first found by Binary Defense. This binary is installed as a service called\r\nWinDefService by worm.exe.\r\nMain Thread\r\nService.exe’s startup is simple. It has a ServiceMain setup, which calls StartServiceCtrlDispatcher to connect the main\r\nthread of the service process to the service control manager, meaning the main thread is run when the service is executed.\r\nIn the main thread, service.exe starts a new thread, which serves two purposes:\r\n1. Communicate back to a new C2 when the service is installed.\r\n2. Drop and execute the Emotet binary embedded in service.exe.\r\nService Communication\r\nThe first action service.exe takes is to open a connection to 45.79.223[.]161:443 and send a request to\r\n/09FGR20HEU738LDF007E848F715BVE.php. Although the connection to the server uses port 443, which is normally used\r\nfor Transport Layer Security (TLS) encrypted communications, the connection is unencrypted HTTP. When opening this\r\nconnection, service.exe sets the following flags:\r\n0x80000000 - INTERNET_FLAG_RELOAD\r\n0x04000000 - INTERNET_FLAG_NO_CACHE_WRITE\r\n0x00040000 - INTERNET_FLAG_NO_AUTH\r\n0x00008000 - INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTP\r\n0x00004000 - INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTPS\r\n0x00002000 - INTERNET_FLAG_IGNORE_CERT_DATE_INVALID\r\n0x00001000 - INTERNET_FLAG_IGNORE_CERT_CN_INVALID\r\n0x00000400 - INTERNET_FLAG_HYPERLINK\r\n0x00000200 - INTERNET_FLAG_NO_UI\r\n0x00000100 - CACHE_ENTRY_ACCTIME_FC\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 5 of 8\n\nThe resource requested is hardcoded and static. This IP is currently an active Emotet Command and Control server (C2).\r\nThe data contained in the request is:\r\n“c=installed”\r\nThis notifies the server that service.exe has been properly installed. As both this request and the request sent by worm.exe\r\nare not sent over TLS/SSL, a Suricata rule is included in this analysis.\r\nFigure 7. Flags used to create the new Emotet process\r\nEmotet Process\r\nAfter service.exe has installed itself and communicated back to the C2, it begins dropping the embedded Emotet executable.\r\nFirst, it obtains the path to %TEMP%, and concatenates “setup.exe” to the end of it. Next, it enters a function which locates\r\nthe embedded executable by specifying a hard-coded buffer offset. Once the embedded executable is located, it creates a\r\nnew file at %Temp%\\setup.exe and writes the embedded executable to this file. It then calls CreateProcess in order to create\r\na new process running the Emotet Executable as seen in Figure 7.\r\nClosing\r\nWith this newly discovered loader-type used by Emotet, a new threat vector is introduced to Emotet’s capabilities.\r\nPreviously thought to only spread through malspam and infected networks, Emotet can use this loader-type to spread\r\nthrough nearby wireless networks if the networks use insecure passwords. Binary Defense’s analysts recommend using\r\nstrong passwords to secure wireless networks so that malware like Emotet cannot gain unauthorized access to the network.\r\nDetection strategies for this threat include active monitoring of endpoints for new services being installed and investigating\r\nsuspicious services or any processes running from temporary folders and user profile application data folders. Network\r\nmonitoring is also an effective detection, since the communications are unencrypted and there are recognizable patterns that\r\nidentify the malware message content.\r\nIOCs\r\nalert http $HOME_NET any \u003c\u003e 45.79.223.161 443 (msg: \"BDS BACKDOOR Emotet Wi-Fi spreader\r\nlikely\";content:\"POST\";http_method;content:\"/09FGR20HEU738LDF007E848F715BVE.php\";http_uri;classtype:backdoo\r\nactivity;sid:2;rev:1;)\r\nYara:\r\nrule Emotet_Wifi_Worm {\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 6 of 8\n\nmeta:\r\n  title = \"Emotet Wi-Fi spreader, Worm.exe\"\r\n     author = \"james.quinn@binarydefense.com\"\r\n   strings:\r\n      $string1 = \" NOTE : WLAN_AVAILABLE_NETWORK_HAS_PROFILE\"\r\n      $string2 = \"IPC$\" wide\r\n      $ParseEnc =   { 8d 04 0e ff b0 64 02 00 00 05 0c 02 00 00 50 68 ?? ?? ?? ?? e8 ?? ?? ?? ?? 83 c4 0c 68 ??\r\n?? ?? ?? e8 ?? ?? ?? ?? 8b 44 ?4 14 8b 84 06 6c 02 00 00 59 83 f8 01 74 ?? 83 f8 02 74 ?? 7e ?? 83 f8 05 7e ??\r\n83 f8 07 7f ?? 68 ?? ?? ?? ?? eb ?? 68 ?? ?? ?? ?? eb ?? 68 ?? ?? ?? ?? eb ?? 68 ?? ?? ?? ?? eb ?? 68 ?? ?? ?? ??\r\ne8 ?? ?? ?? ?? 59 68 ?? ?? ?? ?? e8 ?? ?? ?? ?? 8b 44 ?4 14 8b 84 06 70 02 00 00 2b c3 59 74 ??   }\r\n   condition:\r\n      all of them and uint16(0) == 0x5A4D\r\n}\r\nrule Emotet_Wifi_Service {\r\n   meta:\r\n      title = \"Emotet Wi-Fi Spreader, Service.exe\"\r\n      author = \"james.quinn@binarydefense.com\"\r\n   strings:\r\n      $string1 = \"WinDefService\" wide\r\n      $string2 = \"c=installed\"\r\n      $CommsFunc = { 6a 00 68 00 f7 04 84 6a 00 6a 00 68 ?? ?? ?? ?? 68 ?? ?? ?? ?? 8d 45 f4 50 56 ff 15 ?? ??\r\n?? ?? 8b d8 85 db 74 ??   }\r\n   condition:\r\n      all of them and uint16(0) == 0x5A4D\r\n}\r\nAbout the Author\r\nJames Quinn is a Threat Researcher and Malware Analyst for Binary Defense. When he is not working at\r\nBinary Defense, he works as a freelance malware analyst and participates in security intelligence sharing\r\ngroups. James is a major contributor to research of the Emotet botnet with the Cryptolaemus security\r\nresearcher group.\r\nAbout Binary Defense\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 7 of 8\n\nBinary Defense is a managed security services provider with leading cybersecurity solutions that include\r\nSOC-as-a-Service, Managed Detection \u0026 Response, Security Information \u0026 Event Management and\r\nCounterintelligence. With our human-driven, technology-assisted approach, Binary Defense is able to provide\r\ntheir clients with immediate protection and visibility, combating and stopping the next generation of attacks\r\nthat your business faces. The company isheadquartered in Stow, Ohio at 600 Alpha Parkway.\r\nSource: https://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nhttps://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.binarydefense.com/resources/blog/emotet-evolves-with-new-wi-fi-spreader/"
	],
	"report_names": [
		"emotet-evolves-with-new-wi-fi-spreader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434215,
	"ts_updated_at": 1775791304,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/57bb75ce21eb80adb738d1ef78fcc8a92bac4084.pdf",
		"text": "https://archive.orkl.eu/57bb75ce21eb80adb738d1ef78fcc8a92bac4084.txt",
		"img": "https://archive.orkl.eu/57bb75ce21eb80adb738d1ef78fcc8a92bac4084.jpg"
	}
}