{
	"id": "cacb8101-7494-4636-b1a6-f17604668f68",
	"created_at": "2026-04-06T00:12:40.909724Z",
	"updated_at": "2026-04-10T03:21:26.385492Z",
	"deleted_at": null,
	"sha1_hash": "fac33d612b753b3d965beebef877673d5d5469ff",
	"title": "Bzz.. Bzz.. Bumblebee loader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 110460,
	"plain_text": "Bzz.. Bzz.. Bumblebee loader\r\nBy jouni\r\nPublished: 2022-05-08 · Archived: 2026-04-05 17:35:36 UTC\r\nQuite recently, a new loader has been popping up. This loader is likely been developed to counter the Microsoft’s\r\nchange to the macro behavior, as the macros will be disabled on the documents that have been downloaded from\r\nthe internet. This is a very welcome change as macros have been often used by the threat actors to launch the\r\nmalicious code from the maldocs. Now that this will be harder to the threat actors they are creating new creative\r\nways to get the initial foothold after a phishing attack.\r\nOne of the new ways that has been observed in the wild is the bumblebee loader. This new loader will be delivered\r\nin format of an attachment, or a link within a phishing email. The user is then directed to a legitimate web service\r\n(for example, one drive) from which the user downloads a password-protected ZIP file, with the password in the\r\nemail body. The zip contains an ISO file, which then contains two files - .lnk and .dat files. If the lnk file is started\r\nthe bumblebee loader will be ran from the .dat file. There are several ways how this initial approach could be\r\npotentially found with Defender for Endpoint. To me it sounds like that the initial creation of the ISO file joined to\r\nthe creation of the ZIP file by a browser could be a good approach. This could be maybe joined to network\r\nconnections too, however it gets a little heavy and I leave it out for now.\r\nSo the logic of this query is explained above. I do use the time based join that I’ve used before on an earlier blog\r\npost. This is because the process that creates the ISO file is different from the process that created the archive file.\r\nDepending on the environment this could potentially need more joins to reduce noise. ISO files are relatively rare\r\nin some environments but much more common in the others. Also, this query is only looking for creations of the\r\nISO + archive files - this does not yet mean that anything was executed.\r\nlet lookupWindow = 10min;\r\nlet lookupBin = lookupWindow / 2.0;\r\nDeviceFileEvents\r\n| where FileName endswith \".iso\"\r\n| where ActionType == 'FileCreated'\r\n| extend TimeKey = bin(Timestamp, lookupBin)\r\n| project DeviceName, IsoCreationTime = Timestamp, IsoCreationFileName = FileName, IsoCreationFolderPath = Folde\r\n| join (\r\nDeviceFileEvents\r\n| extend ArchiveCreationTime = Timestamp\r\n| where FileName endswith \".zip\" or FileName endswith \".rar\" or FileName endswith \".7z\"\r\n| where InitiatingProcessFileName =~ \"chrome.exe\" or InitiatingProcessFileName =~ \"firefox.exe\" or InitiatingPro\r\n| extend TimeKey = range(bin(Timestamp-lookupWindow, lookupBin), bin(Timestamp, lookupBin), lookupBin)\r\n| mv-expand TimeKey to typeof(datetime)\r\n| project DeviceName, IsoCreationActionType= ActionType, ArchiveCreationTime = Timestamp, ArchiveCreationFileNam\r\nhttps://threathunt.blog/bzz-bzz-bumblebee-loader\r\nPage 1 of 3\n\n) on DeviceName, TimeKey\r\n| project DeviceName, IsoCreationTime, IsoCreationFileName, ArchiveCreationFileName, IsoCreationProcessName, Iso\r\nAs you can see from the query, I like to rename some of the fields. This does make it easier at least for me to\r\nunderstand the output especially when joining the data from multiple tables with different process names. I do this\r\nalmost every time on my queries and I do also suggest it to others as well. The archive creation query is not\r\nlimited to “FileCreated” events. This is because of how the modern browsers work, as they stage the files with\r\ndifferent names and then in the end renames the file to the final format. To test this out I created an empty file with\r\nthe abbreviation of .ISO. Then I archived the file to a zip file and uploaded to Onedrive - from which I\r\ndownloaded it and extracted the contents.\r\nThe query matches the iso and archive creations.\r\nThe query works. There are multiple matches as there are multiple actions taken on the archive creation query.\r\nThe default inner unique join takes one random entry from the left and joins it to all matches on right. This could\r\nbe refined further but I am quite happy with this. One way to limit the results would be to limit the ActionType to\r\n“FileRenamed” on the archive creation query. The great article by Proofpoint (already linked before, but again\r\nhere) states the process path after the malicious code is launched. It is basically cmd.exe -\u003e cmd.exe -\u003e\r\nrundll32.exe with certain switches. This should be easy enough.\r\nDeviceProcessEvents\r\n| where InitiatingProcessParentFileName =~ \"cmd.exe\"\r\n| where InitiatingProcessFileName =~ \"cmd.exe\"\r\n| where InitiatingProcessCommandLine contains \"IternalJob\"\r\n| where InitiatingProcessCommandLine contains \"rundll32\"\r\n| where FileName =~ \"rundll32.exe\"\r\n| where ProcessCommandLine contains \"IternalJob\"\r\n| project Timestamp, DeviceName, InitiatingProcessParentFileName, InitiatingProcessFileName, InitiatingProcessCo\r\nTo keep the query efficient I didn’t do any joins. Unfortunately, the cmdline of the parent process is not recorded\r\nhere so no filtering can be done based on that, unless joining the data. The query does not produce any results in\r\nmy testing environment but your mileage may vary. I haven’t tested the queries in this post in any production\r\nenvironments yet.\r\nThese queries are relatively simple and likely will catch only partial and early versions of the loader, however I\r\nthink they are a great start. Using these to start and then developing them a little further can produce nice results in\r\ncatching the new type of loader. This data could of course also be joined further to get less results and to get more\r\ninformation out of the activity.\r\nhttps://threathunt.blog/bzz-bzz-bumblebee-loader\r\nPage 2 of 3\n\nAlso - someone might have noticed that I have changed the theme of the blog. I liked the old one but I migrated to\r\nanother host as the first one was quite unresponsive at least from Europe. While doing that I changed the theme to\r\nhandle couple of things better. I think there might be little bug here and there still with this but I will fix them\r\nwhen I get a chance.\r\nEDIT: Fixed a typo in the latter query.\r\nWritten by Jouni\r\nThreat hunting nerd.\r\nSource: https://threathunt.blog/bzz-bzz-bumblebee-loader\r\nhttps://threathunt.blog/bzz-bzz-bumblebee-loader\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://threathunt.blog/bzz-bzz-bumblebee-loader"
	],
	"report_names": [
		"bzz-bzz-bumblebee-loader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434360,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fac33d612b753b3d965beebef877673d5d5469ff.pdf",
		"text": "https://archive.orkl.eu/fac33d612b753b3d965beebef877673d5d5469ff.txt",
		"img": "https://archive.orkl.eu/fac33d612b753b3d965beebef877673d5d5469ff.jpg"
	}
}