{
	"id": "8c250346-6835-4dba-991c-7ceaf8db89d2",
	"created_at": "2026-04-06T00:22:37.535976Z",
	"updated_at": "2026-04-10T03:33:11.082855Z",
	"deleted_at": null,
	"sha1_hash": "08f2cfe4d4322afb4c221ba6affcffc13360d45c",
	"title": "Greenbug’s DNS-isms | NETSCOUT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 412157,
	"plain_text": "Greenbug’s DNS-isms | NETSCOUT\r\nArchived: 2026-04-05 16:30:18 UTC\r\nOver the past few months there has been a lot of research and press coverage on the Shamoon campaigns. These\r\nhave been the attacks on Saudi Arabian companies where a destructive malware known as Disttrack was deployed.\r\nThe malware, using stolen credentials, spreads throughout the targeted networks and then at a set date and time\r\nwipes the disks attached to the victim computers.\r\nA big question kept coming up about Disttrack: how were the hardcoded credentials stolen in the first place? In\r\nJanuary 2017, Symantec proposed one possible answer in their “Greenbug cyberespionage group targeting Middle\r\nEast, possible links to Shamoon” blog post. In it they discuss a threat group they call Greenbug and a custom info-stealing remote access trojan (RAT) the group uses called Ismdoor. Symantec’s possible link between Greenbug\r\nand Shamoon is summed up with: “… the group compromised at least one administrator computer within a\r\nShamoon-targeted organization’s network prior to W32.Disttrack.B being deployed on November 17, 2016. “\r\nWhile there are few details about the threat group, there are even fewer details about the Ismdoor malware.\r\nBesides the brief description in the above blog, RSA released a post in February 2017 giving an overview of its\r\nHTTP communications. Update: Shortly before publication we found an additional February  2017 analysis of\r\n“ISM RAT” by NCC Group.\r\nAlthough analysis has been slow, Ismdoor development has been quick! One major change in recent versions has\r\nbeen the replacement of the old HTTP based command and control (C2) functionality with a custom covert\r\nchannel using AAAA DNS queries for IPv6 addresses. There are a lot of moving packets to this new mechanism\r\nso this post takes a look at our analysis of it so far.\r\nSamples\r\nThe first sample used in this post is available on VirusTotal. It caught our attention due to the descriptive debug\r\nstring:\r\nC:\\Projects\\DNS BOT\\Bot\\x64\\Release\\Ism.pdb\r\nThis is version 1.0.3 and was compiled on 2016-11-11. It was first seen on VirusTotal on 2017-03-27 and was\r\nsubmitted from Saudi Arabia. The C2 domains for this sample are:\r\nwinrepp[.]com\r\nwinsecupdater[.]com\r\nThey were registered on 2016-06-09 and 2016-11-06. Since the C2s were down at the time of this research, we\r\nsearched for and found a newer sample via this tweet. This sample also has a descriptive debug string:\r\nC:\\Users\\me\\Documents\\Visual Studio 2013\\Projects\\DNS_Bot\\v 10.0.19\\x64\\Release\\Nrtscan.pdb\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 1 of 10\n\nIt is version 1.0.19 and was compiled (and first submitted to VirusTotal) on 2017-04-05. Again, it was submitted\r\nfrom Saudi Arabia. The C2 domains for this sample were registered on 2016-12-04 and will be discussed next.\r\nMalware Configuration\r\nIsmdoor has an encrypted configuration that contains a primary and secondary C2 domain, various identifiers,\r\ntimeouts, and flags. These values can be updated by later C2 commands. A substitution cipher is used to decrypt\r\nthe configuration when it is needed. The character mapping has been consistent across samples and we have made\r\navailable a Python snippet of it on Github. The initial configuration for the analyzed sample looks like this:\r\n.dnslookupdater[.]com (primary C2 domain)\r\n 30 (alive timeout)\r\n -1 (appId)\r\n 0\r\n -1\r\n 0\r\n 0\r\n .dnssecupdater[.]com (secondary C2 domain)\r\n 0\r\n 0\r\n 20000\r\n 00000000-0000-0000-0000-000000000000 (uniqueId)\r\nCommand and Control\r\nThe C2 mechanism is built on top of DNS and can be separated into three layers: DNS, transport/session, and C2\r\nmessages.\r\nDNS Layer\r\nAll data sent between the bot and the C2 is done using AAAA DNS UDP queries. Data to the C2 is via specially\r\ncrafted query names and data from the C2 is returned via IPv6 addresses. The bot side of the connection drives all\r\ncommunications. An example query and response looks like this:\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 2 of 10\n\nTransport/Session Layer\r\nThe next layer up can be thought of as a transport/session layer (think similar to UDP and TCP). Here,\r\ncommunications are divided up into sessions and most sessions consist of at least five DNS requests and replies:\r\n1. Establish session ID\r\n2. Send messages to C2\r\n3. Send message count to the C2\r\n4. Ask for count of response messages from the C2\r\n5. Receive messages from the C2\r\nAn example of this typical session looks like this:\r\nTo establish a session, the bot generates a session ID (32 uppercase hexadecimal characters) and sends it to the C2\r\nusing a query name of the following format:\r\nn.n.c.\u003csession id\u003e.c2.com\r\nHere is the example from the above screenshot:\r\nn.n.c.237735C7DCF34DE59F8E04CB852401B3.dnslookupdater[.]com\r\nThe C2 will respond with a static IPv6 address of:\r\na67d:db8:a2a1:7334:7654:4325:370:2aa3\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 3 of 10\n\nNext, the bot sends upper layer C2 messages (described in the next section) to the C2 using query names\r\nformatted like this:\r\n\u003cencoded message\u003e.\u003cmessage number\u003e.dr.\u003csession id\u003e.c2.com\r\nHere is the example from above:\r\nTTpDQz8!.0.dr.237735C7DCF34DE59F8E04CB852401B3.dnslookupdater[.]com\r\nMessage numbers start at zero and messages are base64 encoded with the following characters changed:\r\n= -\u003e !\r\n/ -\u003e \u0026\r\n+ -\u003e @\r\nThe above decodes to the following:\r\nM:CC?\r\nAgain, the C2 responds with a static but different, IPv6 address:\r\na67d:db8:85a3:4325:7654:8a2a:370:7334\r\nIn the third step the bot sends a sent message count to the C2 using the following format:\r\nn.\u003cmessage count\u003e.f.\u003csession id\u003e.c2.com\r\nFor example:\r\nn.1.f.237735C7DCF34DE59F8E04CB852401B3.dnslookupdater[.]com\r\nHere, the C2 responds with an address of hex encoded characters, namely all space characters:\r\n2020:2020:2020:2020:2020:2020:2020:2020\r\nThe fourth step has the bot asking the C2 how many messages it should expect from it. These requests are\r\nformatted liked this:\r\nn.n.fc.\u003csession id\u003e.c2.com\r\nIt looks like this for our example session:\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 4 of 10\n\nn.n.fc.237735C7DCF34DE59F8E04CB852401B3.dnslookupdater[.]com\r\nFor this exchange the C2 responds with an IPv6 address that is static except for the last eight bytes of the address,\r\nwhich are used for the message count. For example if the C2 is going to send one message to the bot it will\r\nrespond like this:\r\na67d:db8:85a3:4325:7654:8a2a::1\r\nThe final step involves the bot receiving messages from the C2. It indicates which message it wants to receive\r\nwith query names like:\r\nwww.\u003cmessage number\u003e.s.\u003csession id\u003e.c2.com\r\nMessage numbers are again zero based, so to receive the first message of this example session the bot will send:\r\nwww.0.s.237735C7DCF34DE59F8E04CB852401B3.dnslookupdater[.]com\r\nThe C2 responds with addresses containing the hex encoded messages like this:\r\n4f6b:2020:2020:2020:2020:2020:2020:2020\r\nThis decodes to “Ok             “. To help analyze these sessions we wrote a parser in Python available on Github.\r\nUsing the parser, the above session can be visualized like this:\r\nsession #0\r\nsession id: 237735C7DCF34DE59F8E04CB852401B3\r\nsend msg 0 to c2: M:CC?\r\nsent 1 msgs to c2\r\nexpecting 1 msgs from c2\r\nrecv msg 0 from c2: 4F6B2020202020202020202020202020 (Ok )\r\nWhen larger amounts of data need to be transferred (for file upload and download) a different type of session is\r\nused:\r\n1. Send file message count to the C2\r\n2. Send file messages to C2\r\n3. Periodically ask the C2 if it is missing any sent file messages\r\n4. Resend any missed file messages\r\nFor file transfers, the file message count is sent to the C2 using query names formatted like this:\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 5 of 10\n\nn.\u003cmessage count\u003e.\u003csession id\u003e.c2.com\r\nSession IDs are derived from the C2 commands that requested the file transfer. The C2 responds with a static IPv6\r\naddress:\r\na67d:db8:a2a1:7334:7654:4325:370:2aa3\r\nFile messages are then sent using the following types of query names:\r\n\u003cencoded data\u003e.\u003cmessage number\u003e.d.\u003csession id\u003e.c2.com\r\nMessage numbers start at zero and data is encoded as above. The C2 will either not respond to these data message\r\nor send a DNS “Server failure” error response. Periodically the bot asks the C2 if it has missed any file messages\r\nusing the following query:\r\nuff\u003cmessage count\u003e.\u003cmessage count\u003e.\u003csession.id\u003e.c2.com\r\nHere, the C2 responds with an address of hex encoded space characters. The bot then sends the following queries,\r\nas described above, to receive an answer from the C2:\r\nn.n.fc.\u003csession id\u003e.c2.com\r\nwww.\u003cmessage number\u003e.s.\u003csession id\u003e.c2.com\r\nThe C2 then responds with a hex encoded list of missed messages. For example if the C2 were missing message\r\nnumbers 5, 9, 15, and 16 it would send this IPv6 address:\r\n3136:2c31:352c:392c:3520:2020:2020:2020\r\nwhich decodes to: “(16,15,9,5       )”. Missing file messages are resent with query names like:\r\n\u003cencoded data\u003e.\u003cmessage number\u003e.dl.\u003csession id\u003e.c2.com\r\nAs with the send file message above, the C2 will either not respond to these replays or send an error message. A\r\nparsed example of this type of session looks like this:\r\nsession #13\r\nsession id: a1a13274c08f4730b88f1715de38068c\r\nsend file msg count (25) to c2\r\nsend file msg 0 to c2\r\nsend file msg 1 to c2\r\n...\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 6 of 10\n\nsend file msg 24 to c2\r\nask c2 for missing file msgs\r\nexpecting 1 msgs from c2\r\nrecv msg 0 from c2: 31362C31352C392C3520202020202020 (16,15,9,5 )\r\nresending file msg 16 to c2\r\n...\r\nC2 Messages\r\nThe third layer contains C2 messages and there are at least eight of them. Some messages have additional\r\nparameters. We’ll go through each message and show some examples using the above parser.\r\nM:CC?\r\n“CC” likely means “Connection Check” or “Check Connection”. This is a periodic message that checks whether\r\nthe C2 server is alive and well. An example message and response looks like this:\r\nsend msg 0 to c2: M:CC?\r\nrecv msg 0 from c2: 4F6B2020202020202020202020202020 (Ok )\r\nM:ME? “ME” likely means “Message” and these are used to send status messages back to the C2. Here is an\r\nexample:\r\nsend msg 0 to c2: M:ME?appId=-1\u0026message=Executed Successfully\r\nrecv msg 0 from c2: 20202020202020202020202020202020 ( )\r\nM:AV? “AV” may mean “AliVe” or “AVailable\". This is a periodic message that has two purposes. The first is to\r\ninitialize two identifiers (stored in the previously mentioned config) “appId” and “uniqueId”. The latter is akin to a\r\nbot ID, but it is unclear what the former represents. It changes on each malware run and tends to be a low value\r\ninteger (some examples seen: 5, 8, 11, 12). An example of this message looks like:\r\nsend msg 0 to c2: M:AV?appId=-1\u0026uniqueId=00000000-0000-0000-000\r\nsend msg 1 to c2: 0-000000000000\r\nrecv msg 0 from c2: 41707049647C7C7C38267569643D3432 (AppId|||8\u0026uid=42)\r\nrecv msg 1 from c2: 6435623934352D383062362D34336430 (d5b945-80b6-43d0)\r\nrecv msg 2 from c2: 2D396330332D33323736316233323866 (-9c03-32761b328f)\r\nrecv msg 3 from c2: 34372020202020202020202020202020 (47 )\r\nAfter the IDs have been initialized this message asks how many commands are available for the bot on the C2.\r\nThese messages look like:\r\nsend msg 0 to c2: M:AV?appId=8\u0026uniqueId=42d5b945-80b6-43d0-9c03\r\nsend msg 1 to c2: -32761b328f47\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 7 of 10\n\nrecv msg 0 from c2: 31202020202020202020202020202020 (1\r\n)\r\nM:ReId?\r\n“ReId” may mean “ReplyID” and verifies the appId with the C2 after it is initialized above:\r\nsend msg 0 to c2: M:ReId?Id=8\r\nrecv msg 0 from c2: 4F6B2020202020202020202020202020 (Ok )\r\nM:GAC?\r\n“GAC” likely means “Get A Command” and that’s what it does:\r\nsend msg 0 to c2: M:GAC?appId=8\r\nrecv msg 0 from c2: 30323064373461352D323061332D3433 (020d74a5-20a3-43)\r\nrecv msg 1 from c2: 65372D616463642D6634383631356466 (e7-adcd-f48615df)\r\nrecv msg 2 from c2: 356137347C7C7C476574436F6E666967 (5a74|||GetConfig)\r\nrecv msg 3 from c2: 3A3A3A31302020202020202020202020 (:::10 )\r\nBot commands will be discussed in a later section, but one thing to notice is that each command contains a unique\r\nGUID (020d74a5-20a3-43e7-adcd-f48615df5a74 in this example).\r\nM:CR?\r\n“CR” likely means “Command Received” and it acknowledges receipt of a command:\r\nsend msg 0 to c2: M:CR?cd=020d74a5-20a3-43e7-adcd-f48615df5a74\r\nrecv msg 0 from c2: 4F6B2020202020202020202020202020 (Ok )\r\nNotice the command GUID is returned to the C2.\r\nM:SF?\r\n“SF” likely means “Send File” and is used to send files and command results. Here is the result of the GetConfig\r\ncommand from above:\r\nsend msg 0 to c2: M:SF?commandId=CmdResult=020d74a5-20a3-43e7-a\r\nsend msg 1 to c2: dcd-f48615df5a74|||GetConfig:::.dnslookupdate\r\nsend msg 2 to c2: r[.]com^M\r\n30^M\r\n8^M\r\n1^M\r\n-1^M\r\n0^M\r\n0^M\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 8 of 10\n\n.dnssecupdater[.]com\r\nsend msg 3 to c2: ^M\r\n0^M\r\n0^M\r\n20000^M\r\n42d5b945-80b6-43d0-9c03-32761b\r\nsend msg 4 to c2: 328f47\r\nrecv msg 0 from c2: 20202020202020202020202020202020 ( )\r\nM:GF?\r\n“GF” likely means “Get File” and is similar to “Send File” To see more of what Ismdoor’s DNS C2 protocol and\r\nmessages look like, we’ve put up a parsed PCAP from an infected VM up on Github.\r\nBot Commands\r\nIsmdoor has a bunch of functionality and commands. While this post won’t go into detail on them, most are self-describing:\r\nChangeAliveSeconds – sets alive timeout in config\r\nChangeAddress – sets C2 domains in config\r\nSI – likely means “System Information” – runs a bunch of system commands and sends their output to the\r\nC2\r\nGetConfig - sends config to C2\r\nRunNewVersion - updates self\r\nrestart - restarts self\r\nremove - removes self\r\nCreateMimi1Bat - likely executes Mimikatz (executes PowerShell scripts: ccd61.ps1 and Invoke-bypassuac)\r\nRAAD – executes PowerShell scripts ivb.ps1 and Invoke-EventVwrBypass\r\nCLRAD - deletes files associated with RAAD command\r\nExecutePC - likely executes Powercat—PowerShell version of Netcat (executes PowerShell scripts dp.ps1\r\nand powercat)\r\nFastAlive - sets “FastAlive” in config. Unknown ramifications\r\nExecuteKL - likely executes a keylogger (executes Winit.exe and sends \"Start Keylog Done\" message back\r\nto the C2)\r\nRemoveKL - kills and removes keylogger associated files\r\nGetVersion - sends malware version to C2\r\nPauseUpload\r\nResumeUpload\r\nPauseDownload\r\nResumeDownload\r\nPWS - takes a screenshot\r\nImmediateResetRam - sets “ResetRam” flag in config. Unsure of the ramifications\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 9 of 10\n\nDownloadFile\r\nUploadFile\r\nIf a command doesn’t match a predefined one, it passes it to a command shell and returns the result as a file.\r\nConclusion\r\nWhile a definitive connection between Greenbug’s Ismdoor and the Shamoon campaigns is still up in the air, we\r\nwanted to highlight some notes in its favor:\r\nSymantec saw an earlier version of Ismdoor on a Shamoon targeted host shortly before a Disttrack attack\r\n(unverified by Arbor)\r\nAll the known samples of the DNS variant of Ismdoor have been originally submitted to VirusTotal from\r\nSaudi Arabia\r\nThe DNS variant of Ismdoor has explicit capabilities for stealing credentials via its CreateMimi1Bat and\r\nExecuteKL commands\r\nPivoting on the CreateMimi1Bat command’s PowerShell script name (ccd61.ps1) leads to a Shamoon\r\nrelated blog post by McAfee [9] where they trace a malicious, macro laden spearfishing email to the\r\ndownload and execution of an earlier version of Ismdoor (though they don’t name the malware they’re\r\ndescribing)\r\nWhat is definite though is that Ismdoor is active and under development. This post takes a close look at one of its\r\nmajor new features: a full featured C2 mechanism that uses DNS.\r\nSource: https://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nhttps://www.netscout.com/blog/asert/greenbugs-dns-isms\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://www.netscout.com/blog/asert/greenbugs-dns-isms"
	],
	"report_names": [
		"greenbugs-dns-isms"
	],
	"threat_actors": [
		{
			"id": "e58deb93-aff1-4be5-8deb-37fe8af0b7ed",
			"created_at": "2022-10-25T16:07:23.918534Z",
			"updated_at": "2026-04-10T02:00:04.789509Z",
			"deleted_at": null,
			"main_name": "Greenbug",
			"aliases": [
				"Greenbug",
				"Volatile Kitten"
			],
			"source_name": "ETDA:Greenbug",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "25896473-161f-411f-b76a-f11bb26c96bd",
			"created_at": "2023-01-06T13:46:38.75749Z",
			"updated_at": "2026-04-10T02:00:03.090307Z",
			"deleted_at": null,
			"main_name": "CHRYSENE",
			"aliases": [
				"Greenbug"
			],
			"source_name": "MISPGALAXY:CHRYSENE",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "6bba8e81-73af-4010-86dc-d43c408ca342",
			"created_at": "2023-01-06T13:46:38.553459Z",
			"updated_at": "2026-04-10T02:00:03.021597Z",
			"deleted_at": null,
			"main_name": "Greenbug",
			"aliases": [],
			"source_name": "MISPGALAXY:Greenbug",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434957,
	"ts_updated_at": 1775791991,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/08f2cfe4d4322afb4c221ba6affcffc13360d45c.pdf",
		"text": "https://archive.orkl.eu/08f2cfe4d4322afb4c221ba6affcffc13360d45c.txt",
		"img": "https://archive.orkl.eu/08f2cfe4d4322afb4c221ba6affcffc13360d45c.jpg"
	}
}