{
	"id": "0f95a59b-1c2f-405b-bb72-9695625698ee",
	"created_at": "2026-04-06T00:17:02.539214Z",
	"updated_at": "2026-04-10T13:12:59.918137Z",
	"deleted_at": null,
	"sha1_hash": "891ff0bdcfaa85d8458a72837596030f2442f7ef",
	"title": "OilRig Actors Provide a Glimpse into Development and Testing Efforts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3472777,
	"plain_text": "OilRig Actors Provide a Glimpse into Development and Testing\r\nEfforts\r\nBy Robert Falcone\r\nPublished: 2017-04-27 · Archived: 2026-04-05 20:21:24 UTC\r\nThroughout an attack campaign, actors will continue to develop their tools in an attempt to remain undetected and\r\nto carry out multiple attacks without having to completely retool. In regard to the attack lifecycle, development of\r\ntools occurs in the weaponization/staging phase that precedes the delivery phase, of which is typically the first\r\nopportunity we see the actors’ activities as they interact directly with their target. We have been presented with a\r\nrare opportunity to see some development activities from the actors associated with the OilRig attack campaign, a\r\ncampaign Unit 42 has been following since May 2016. Recently we were able to observe these actors making\r\nmodifications to their ClaySlide delivery documents in an attempt to evade antivirus detection.\r\nWe have identified two separate testing efforts carried out by the OilRig actors, one occurring in June and one in\r\nNovember of 2016. The sample set associated with each of these testing activities is rather small, but the changes\r\nmade to each of the files give us a chance to understand what modifications the actor performs in an attempt to\r\nevade detection. This testing activity also suggests that the threat group responsible for the OilRig attack\r\ncampaign have an organized, professional operations model that includes a testing component to the development\r\nof their tools.\r\nTesting Activity, Analysis, and Methodology\r\nWe collected two sets of ClaySlide samples that appear to be created during the OilRig actor’s development phase\r\nof their attack lifecycle. The threat actor uploaded each of these files to a popular antivirus testing website to find\r\nout which vendors detected the file. The actor then made subtle modifications to the file and uploaded the newly\r\ncreated file to the same popular antivirus testing website in order to determine how to evade detection. The\r\nflowchart in Figure 1explains the process in which the threat actors followed during their testing activities.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 1 of 23\n\nFigure 1 Flowchart describing the testing process carried out by OilRig actor\r\nLucky for us, the threat actors do not modify the metadata within their delivery documents, which allows us to\r\ndetermine when the actor last modified each Word document. These untainted timestamps allow us to create a\r\ntimeline that we can use to order the files as they were created by the actor. Our analysis methodology involves\r\niteratively comparing each file with the next file in the timeline to determine the changes the actor made to the\r\nfirst file that resulted in the creation of the second file.\r\nThe first testing activity we observed began with an initial sample created on June 13, 2016 with 17 subsequent\r\nfiles created for testing purposes that the actor created in a two-hour period on June 15, 2016. Table 1shows the\r\nsamples we observed associated with the June 2016 testing activity, including the iteration, the last modified\r\ntimestamp, the hash, the filename, and the antivirus detection rate of the newly created file. The first “ttt.xls” file\r\nand the files with incrementing filenames have the same decoy contents, which is the reason we initially included\r\nthis sample with this group despite the difference in naming. Also, the filename “ttt.xls” contains the acronym for\r\n“to the top”, which is common usage in Internet forums and could depict the actor starting testing activities.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 2 of 23\n\nIteration Modified SHA256 Filename AV\r\nBase 2016:06:13 05:28:32 742a52084162d3789e19... ttt.xls 4\r\n1 2016:06:15 05:24:25 f1de7b941817438da2a4... 1.xls 6\r\n2 2016:06:15 05:28:11 b142265bb4b902837d83... 2.xls 0\r\n3 2016:06:15 05:30:45 2e226a0210a123ad8288... 3.xls 2\r\n4 2016:06:15 05:33:11 299bc738d7b0292820d9... 4.xls 4\r\n5 2016:06:15 05:39:55 6e62308b94455569b8a1... 5.xls 2\r\n6 2016:06:15 05:42:20 d64b46cf42ea4a7bf291... 6.xls 1\r\n7 2016:06:15 05:47:09 77f8a267357a8d237e0b... 8.xls 1\r\n8 2016:06:15 05:52:50 92f429b6f9b8031b5fc6... 9.xls 3\r\n9 2016:06:15 05:55:01 c2a386723d8f203e1228... 10.xls 2\r\n10 2016:06:15 05:57:50 2fb6bce8fc2f531de183... 11.xls 2\r\n11 2016:06:15 06:00:24 75b033a40a756e2536d0... 12.xls 2\r\n12 2016:06:15 06:10:46 8bb8f2bada27d14be021... 13.xls 1\r\n13 2016:06:15 06:13:30 3af6dfa4cebd82f48b66... 14.xls 2\r\n14 2016:06:15 06:16:27 82239a4e18a67f7b2ba0... 15.xls 2\r\n15 2016:06:15 06:19:45 938101a1a336ce0fff57... 16.xls 2\r\n16 2016:06:15 07:02:49 5e9ddb25bde3719c392d... ttt.xls 4\r\n17 2016:06:15 07:39:53 4190a8b8e6fa7bc37712... ttt.xls 0\r\nTable 1 Samples associated with the June 2016 testing activities\r\nThe second testing activity of ClaySlide delivery documents began with the actor creating a base sample on\r\nNovember 14, 2016, followed by six subsequent test files created within a 30-minute window on the following\r\nday. Table 2 shows the pertinent information related to the ClaySlide testing activity that occurred in November\r\n2016. Again, there was an obvious difference in filenames at the beginning of this activity, but we included the\r\nfirst two samples in with this group based on the first two files initially sharing decoy contents, but more\r\nimportantly sharing the same macro code and payload scripts as the initial testing sample with the filename of\r\n“weak.xls”.\r\nIteration Modified SHA256 Filename AV\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 3 of 23\n\nBase 2016:11:14 04:15:57 ae40262d5fad4bc48066... Tables[Update].xls 5\r\n1 2016:11:15 07:53:50 16880db37c35d4b28e68... 33.xls 5\r\n2 2016:11:15 07:56:09 47054a8d380c197a7f32... weak.xls 5\r\n3 2016:11:15 08:05:52 e9ccf7a3c1e24f173ae9... weak.xls 3\r\n4 2016:11:15 08:12:11 e3c6f13dc3079a828386... weak.xls 3\r\n5 2016:11:15 08:14:35 427ce6b04d4319eeb84d... weak.xls 2\r\n6 2016:11:15 08:19:55 18b603495f8344c02468... weak.xls 2\r\nTable 2 Samples associated with the November 2016 testing activity\r\nBy analyzing the changes made to the ClaySlide delivery document during these two separate testing activities we\r\nwere able to gain insight into the techniques used by the actors during the testing. Before reviewing the activities\r\nperformed in the two testing sessions, the following high level observations can be made:\r\nPatterns in filenames emerge, with testing files having the same word or incrementing numbers for the\r\nfilenames, or a set of testing files sharing the same exact filename\r\nVery structured approach, using a baseline test sample followed by small iterative changes\r\nActor may also revert back to the baseline test sample and continue testing\r\nChanges made only a few minutes apart and can involve:\r\nRemoval or location change of payload\r\nModified decoy contents and sheet names\r\nChanges to function and variable names\r\nRemoval of entire lines of code\r\nObfuscating strings via concatenation or an alternate encoding (base64 or hexadecimal)\r\nReordering of functions in the code\r\nIn many cases, testing files are no longer functional due to:\r\nRemoval of a required component(s)\r\nReplacement of variables with nonsensical values\r\nUse of encoded strings without ability to decode\r\nTesting activities ceases with a very low antivirus detection rate\r\nThe number of vendors detecting the samples increases and decrease throughout the testing as the actor\r\nattempts to determine what the detection signatures are triggering on\r\nJune 2016 Testing Activity\r\nIn June 2016, an actor related to the OilRig campaign began a series of testing activities in an attempt to determine\r\nthe portions of the ClaySlide macro code that antivirus vendors were using for detection purposes. These activities\r\nresulted in 17 different iterations of the ClaySlide delivery document, many of which no longer run properly due\r\nto the changes made within the files. We have included an exhaustive analysis of the June 2016 testing activity in\r\nAppendix A.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 4 of 23\n\nIn the June testing, the actor started by removing the malicious payload from the Excel delivery document to focus\r\ntheir testing on the malicious macro. The actor made many iterative changes during their testing of the macro,\r\nhowever, the actor began these changes by completely removing a block of the code that was responsible for\r\nsaving the payload to the system and for creating the scheduled task to run the payload. The removal of this code\r\nbrought the detection rate to 0, which told the actor that the antivirus detection rules were detecting these files\r\nbased on these lines of code. The actor spent most of their subsequent efforts modifying portions of this code.\r\nNow that the actor knew the portion of the code that caused antivirus detection, the actor added that portion of the\r\ncode back to the macro and made changes in attempt to determine the exact line of code that was detected. This\r\nprocess involved changing the commands used to create the payload and the scheduled task. The changes made to\r\nthese two commands involved their complete removal, their replacement with non-functioning strings such as\r\nkeyboard mashing and their equivalent strings in a variety of different encodings, including base64 and\r\nhexadecimal representation. The actor also changed the way these commands were executed as well, specifically\r\nby either using the WScript.Shell object directly or the object stored in a variable. The actor also uses intentional\r\nmisspelling of commands, such as “poawearshell” and “scshtassks”, as well as variations to the filenames for the\r\npayloads, such as “firaeeye.vbs” instead of “fireeye.vbs”.\r\nAfter making changes to the commands above, the actor shifted their focus onto changing the function names\r\nwithin the macro, which did not result in any change in the detection rate. After a 40-minute break, it appears the\r\nactor reverts to the base macro instead of modifying the previously created test file. Again, the actor modifies the\r\ncode in the base macro responsible for saving and running the payload, but this time the actor changes the folder\r\nnames it creates for the payload to store its generated files. Also, the two files generated during these activities that\r\noccurred after the actor reverted back to the base macro had keyboard-mashed strings for their decoy contents,\r\nwhich differed dramatically from the previous test files. During the entirety of this testing activity, the antivirus\r\ndetection rate reached a high of 6 but ended with a zero vendors detecting the sample when the actor ceased\r\ntesting activities, which suggests that the actor was satisfied with this result. However, we do not see conclusive\r\nevidence to suggest that the actor was attempting to evade a specific antivirus vendor.\r\nNovember 2016 Testing Activity\r\nOn November 15, 2016, an actor related to the OilRig campaign began testing the ClaySlide delivery documents.\r\nWhile the testing activities in June began with the removal of the payloads from the delivery document, the files\r\ngenerated during the November testing all retained their Helminth payloads, all of which were the same payload\r\nthat use the C2 domain of “updateorg[.]com”. We have included an exhaustive analysis of the November 2016\r\ntesting activity in Appendix B.\r\nIn the November testing, the actor appears to initially focus on making modifications to the Excel worksheet that\r\ncontains the decoy contents. The changes made to the worksheet involved adding random strings to cells within\r\nthe decoy, to changing the names of the worksheets themselves. Eventually, the actor completely changes the\r\ncontents of the decoy to a different theme entirely, from a decoy containing routing settings to a list of weak\r\npasswords.\r\nIn addition to making changes to the Excel worksheets that contain the decoy content, the actor also made changes\r\nto the worksheet that is initially displayed to the user. Taking a step back, as discussed in the Appendix in our\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 5 of 23\n\ninitial OilRig blog, ClaySlide delivery documents initially open with a worksheet named “Incompatible” that\r\ndisplays content that instructs the user to “Enable Content” to see the contents of the document, which in fact runs\r\nthe malicious macro and compromises the system. When the macro runs, it hides the “Incompatible” worksheet\r\nand displays the worksheet that contains the decoy document. The actor modified the “Incompatible” worksheet to\r\ninclude random strings, which appears to be an attempt to see if detection rules are using the hash of this sheet for\r\ndetection purposes.\r\nMeanwhile, during these changes to the “Incompatible” worksheet, the actor is also making changes to the\r\nmalicious macro as well. The actor began changing the function names in the malicious macro from “Doom_Init”\r\nand “Doom_ShowHideSheets” to “Doon_Init” and “Doon_SHSheet” to “Ini” and “SHSheet”. At one point, the\r\nactor changed the order of the functions in the macro to see if it was the cause of detection. The actor also changed\r\nthe variable name used to store the VB script used to run the Helminth payload from “BackupVbs” to\r\n“Backup_Vbs”.\r\nAnother change made during these testing activities involved the actor splitting the command needed to create the\r\nscheduled task in several strings and concatenating them back together. This technique is interesting, as the\r\nresulting command is still functional which differs dramatically from the modifications seen in the June testing\r\nwhere the commands were changed to a point where they were no longer operational.\r\nThe last change made to the malicious macro is the locations in which the macro obtains the payload. In all\r\nClaySlide delivery documents, the macro obtains scripts related to the Helminth Trojan from specific cells within\r\nthe “Incompatible” worksheet. By changing the cells containing the scripts, the actor is checking to see if\r\ndetection rules are looking for scripts at these specific locations. By the time the threat actor ceased this testing\r\nactivity, the actor had lowered the detection rate of the ClaySlide delivery document to 2, suggesting this was a\r\nsatisfactory result. Like the June testing activity, we do not see conclusive evidence of the threat actor attempting\r\nto evade a specific antivirus vendor in the November testing.\r\nConclusion\r\nThe threat actors involved with the OilRig attack campaign have shown part of their playbook that involves\r\ntesting and modifying their delivery documents prior to use in attacks. The purpose of these modifications is to\r\nevade detection from security products to extend the usage of their ClaySlide delivery documents. By analyzing\r\nthese testing activities, we gain some helpful insight into the OilRig actors, specifically that this threat group is\r\nfairly mature from an operational standpoint and the fact that they hope to use their delivery documents as long as\r\npossible.\r\nWe were already aware of this threat group making modifications to their ClaySlide delivery document that we\r\ndiscussed in our previous blog. Now we know that there is an organized process involved that results in these\r\nchanges, rather than the threat actor arbitrarily making changes to parts of the delivery documents, such as\r\nfilenames and payload behavior. This realization suggests that the OilRig threat group will continue to use their\r\ndelivery documents for extended periods with subtle modifications to remain effective.\r\nAppendix A\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 6 of 23\n\nThis appendix contains an in-depth analysis of each iteration of testing activity carried out by the OilRig actors in\r\nJune 2016. We provide screenshots and diffs between files (when available) to visualize the modifications made\r\nduring the iteration.\r\nIteration 1\r\nThe actor removed all but three bytes from the VBS and PowerShell scripts, while the macro itself remains\r\nunchanged. This suggests that the delivery document no longer contains the malicious payload (Helminth scripts)\r\nused to infect the system. By removing the payload from the delivery document, the actor can isolate antivirus\r\ndetection results based on the delivery document itself. Also, without the payload the samples no longer have\r\nsome attributes and entities that security researchers typically use to correlate samples to a specific threat group,\r\nsuch as the C2 server of “update-kernal[.]net” that was in the payload in the base sample.\r\nWith the payload removed, the actor focuses their efforts in subsequent iterations on modifying the macro within\r\nthe delivery document.\r\nIteration 2\r\nThe actor completely removed code that is responsible for a majority of the functionality within the macro. The\r\ncode removed, as seen in Figure 2, is responsible for the following:\r\n1. Creating folders\r\n1. \\Libraries\\up\r\n2. \\Libraries\\dn\r\n3. \\Libraries\\tp\r\n2. Running a PowerShell command to create\r\n1. PowerShell script\r\n2. VB script\r\n3. Running a command to create a scheduled task to run the VB script\r\nFigure 2 Changes made in Iteration 2\r\nIteration 3\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 7 of 23\n\nThe actor adds the content removed in the previous iteration. However, the line of code responsible for running\r\nthe command to create the scheduled task to run the VB script was omitted. This suggests the threat actor was\r\ntesting to see if vendors were detecting ClaySlide samples based on this line within the macro.\r\nFigure 3 Changes made in Iteration 3\r\nIteration 4\r\nThe actor adds the line of code omitted from the previous iteration, suggesting this specific code was not used for\r\ndetection purposes. The actor also changed the method in which it calls the PowerShell script in the “cmd”\r\nvariable, by using a “WScript.Shell” object stored in the “wss” variable instead of creating a new “WScript.Shell”\r\nobject.\r\nFigure 4 Changes made in Iteration 4\r\nIteration 5\r\nThe actor base64 encoded the contents of the ‘cmd’ variable that stored a command to invoke a PowerShell script\r\nthat would save the payload to the filesystem. Also, the actor changed the command to create the scheduled task to\r\nbe base64 encoded as well. These alterations do not come with a base64 decoding routine, suggesting that the\r\nsample generated in this iteration would result in an error. The lack of a decoding routine suggests that the actor\r\ndoes not waste time making sure the code actually works, as they could add code to support these changes.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 8 of 23\n\nFigure 5 Changes made in Iteration 5\r\nIteration 6\r\nThe actor tests to see if the base64 encoded strings added in the previous iteration were detected by removing\r\nthese strings and leaving the two command strings empty.\r\nFigure 6 Changes made in Iteration 6\r\nIteration 7\r\nThe actor adds the base64 encoded string for “powershell.exe” within the ‘cmd’ variable and in place of the\r\ncommand to create the scheduled task.\r\nFigure 7 Changes made in Iteration 7\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 9 of 23\n\nIteration 8\r\nThe actor replaces the first base64 for “powershell.exe” with the base64 encoded string to run the PowerShell\r\ncommand, but replaces the second “powershell.exe” with the cleartext string to create the scheduled task. The\r\nbase64 encoded PowerShell command is similar to those seen in previous iterations. However, the actor changed\r\none of the filenames used to save the payload to “firaeeye.vbs” (from “fireeye.vbs”) and references a variable\r\nnamed “FireeayeVbs” (from “FireeyeVbs”) that does not appear in the code.\r\nFigure 8 Changes made in Iteration 8\r\nIteration 9\r\nThe actor replaces the cleartext string to create the scheduled task with the base64 encoded version of the string.\r\nHowever, the base64 encoded string changes the name of the created task from “GoogleUpdatesTaskMachineUI”\r\nto “GoosgleUpdatesTaskMachineUI” and the script name from “fireeye.vbs” to \"fireeyse.vbs\".\r\nFigure 9 Changes made in Iteration 9\r\nIteration 10\r\nThe actor makes changes to the base64 encoded strings that used as a command to use PowerShell to install the\r\npayload and to schedule a task to run the payload. The base64 encoded PowerShell command reintroduces the\r\nfilename “fireeye.vbs” and the variable name “FireeyeVbs”, both of which were changed in iteration 8; however,\r\nthe base64 encoded command uses the string “poawearshell” instead of “powershell”.\r\nAs for the base64 string used to create the scheduled task, the actor reintroduced the scheduled task name of\r\n“GoogleUpdatesTaskMachineUI” and script filename of “fireeye.vbs”, which were changed in iteration 9.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 10 of 23\n\nHowever, the actor uses the string “scshtassks” to see if the “schtasks” string was being detected.\r\nFigure 10 Changes made in Iteration 10\r\nIteration 11\r\nThe actor changed the base64 encoded strings within the ‘cmd’ variable and the string used to create the scheduled\r\ntask. Instead of including the base64 encoded string of the PowerShell and create task command, the actor\r\nreplaced these strings with the base64 encoded representation of the following string:\r\nsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource\r\ncode from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.htmlsource code from https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.html\r\nThe string above contains a link to a FireEye blog that provided an analysis of this delivery document. It should be\r\nnoted that the following non-encoded string was included in previous samples as a comment within the macro:\r\n'source code from https://www.fireeye.com/blog/threat-research/2016/05/tareted_attacksaga.html\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 11 of 23\n\nFigure 11 Changes made in Iteration 11\r\nIteration 12\r\nThe actor replaced the base64 strings within the ‘cmd’ variable and the string to create the scheduled task with\r\nrandomly typed letters. It appears the actor performed two-handed keyboard mashing to generate the strings used\r\nin these variables.\r\nFigure 12 Changes made in Iteration 12\r\nIteration 13\r\nThe actor changed the randomly typed keys in the ‘cmd’ and the string for creating the scheduled task with the\r\nbase64 strings from two iterations back. However, the base64 strings were added between opening and closing\r\nbrackets.\r\nFigure 13 Changes made in Iteration 13\r\nIteration 14\r\nThe actor changed the base64 encoded strings used for the PowerShell command and the command to create a\r\nscheduled task from the last iteration to a hexadecimal string. The string contains the hexadecimal representation\r\nof the characters that make up the command to create the scheduled task, which was last seen in Iteration 4. Again,\r\nthe script does not contain decoding functions to decode the hexadecimal values to the correct characters,\r\ntherefore this script is not functional.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 12 of 23\n\nFigure 14 Changes made in Iteration 14\r\nIteration 15\r\nThe actor changed the two function names that are run when the Excel document is opened. In all prior iterations,\r\nthese function names were “fireeye_Init” and “fireeye_ShowHideSheets”, which are responsible for installing the\r\nTrojan and displaying the decoy contents within the Excel spreadsheet, respectively. The actor changed these two\r\nfunction names to “fireeye_Init2” and “fireeye_ShowHideSheets3” to determine if the function names were being\r\ndetected by antivirus products.\r\nFigure 15 Changes made in Iteration 15\r\nIteration 16\r\nThis iteration is very interesting, as we believe the actor reverts back to the base document instead of making\r\nchanges to the document created in the previous iteration.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 13 of 23\n\nThe filename changed from an incrementing number to “ttt.xls”, which is the same filename as the base document.\r\nAlso, when we compared the sample from the previous iteration, there were a number of changes seen here:\r\nFigure 16 Changes made in Iteration 16 if compared with the file in Iteration 15\r\nHowever, if you compare the file created in this iteration with the base file, the number of and type of changes\r\nseem to align closer to the modifications performed in previous iterations. If the actor reverted to the base\r\ndocument as we suspect, then modifications were made to the script filename, the folder names that store files\r\ngenerated by the payload, as well as the method the script invokes the PowerShell script. The actor changed the\r\nscript filename from “fireeye.vbs” to “fireueye.vbs”, changed the “up”, “dn” and “tp” folder names to “uup”,\r\n“dgn” and “tup” and uses the “WScript.Shell” object stored in the “wss” variable instead of creating a new\r\n“WScript.Shell” object to run the command.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 14 of 23\n\nFigure 17 Changes made in Iteration 16 if actor reverted to the base file\r\nIteration 17\r\nIn the last iteration of this testing activity, the actor changed some of the modifications made in the previous\r\niteration back to the values used in the base document, specifically the filenames and folder names. However, the\r\nactor also adds a new variable to store the “%PUBLIC%” environment variable that the script uses as the path to\r\nstore the “fireeye.vbs” script and the folders that the payload would use. This iteration also includes a modified\r\nPowerShell command that attempts to run a command stored in the “fireeye.vbs” file, but does not include the\r\nportion of the command that would write the script to that file. The actor also removed the line that would run the\r\ncommand to create the scheduled task to run the VB script.\r\nFigure 18 Changes made in Iteration 17\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 15 of 23\n\nAppendix B\r\nThis appendix contains an in-depth analysis of each iteration of testing activity carried out by the OilRig actors in\r\nNovember 2016. We provide screenshots and diffs between files (when available) to visualize the modifications\r\nmade during the iteration.\r\nIteration 1\r\nIn the first iteration of this testing, the actor changed the decoy content from the base sample. At a high level, the\r\ndecoy contents contained commands to configure a Cisco router with static routes and other settings. Originally,\r\nthe base test file used in this testing activity contained just these configuration settings in an Excel worksheet\r\nnamed “Sheet1”, as seen in Figure 19.\r\nFigure 19 Original decoy contents found in the base test file\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 16 of 23\n\nIn the first iteration of testing, the actor changed the worksheet name that contains the decoy content from\r\n“Sheet1” to “hgvc” and added a string to the worksheet “jgvchhctf”, as seen in Figure 20. We believe the threat\r\nactor is attempting to determine if the worksheet name or the hash of the decoy worksheet were causing antivirus\r\ndetection.\r\nFigure 20 Changes made to the decoy contents in Iteration 1\r\nIteration 2\r\nThe actor then changed the name of the worksheet that contains the decoy content from “hgcv” to “table” and\r\ncompletely changed the decoy content from the Cisco routing settings to a list of weak passwords, as seen in\r\nFigure 21. We believe this is the threat actor testing the new decoy content that they will use in an upcoming\r\nattack.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 17 of 23\n\nFigure 21 New decoy contents introduced in Iteration 2\r\nIteration 3\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 18 of 23\n\nFollowing the lead of previous iterations, the actor made modifications to the content in the Excel worksheet;\r\nhowever, in this iteration the changes were not made to the decoy worksheet, rather the change was made to the\r\ninitial worksheet called “Incompatible” that displays the message to instruct the user to enable content to run the\r\nmacro. As seen in Figure 22, the actor adds the string “yy” to this worksheet to determine whether antivirus\r\nvendors were detecting Clayslide documents based on this worksheet.\r\nFigure 22 Changes made to the Incompatible worksheet in Iteration 3\r\nThe actor also made modifications to the macro in this iteration, specifically by changing function names and by\r\nsplitting up strings and concatenating them back together. The function names in the macro “Doom_Init” and\r\n“Doom_ShowHideSheets” were changed to “Doon_Init” and “Doon_SHSheet” to determine if these function\r\nnames were causing detection. Also, the actor split the word “powershell” in the commands within the macro and\r\nconcatenated them together to retain functionality.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 19 of 23\n\nFigure 23 Changes made to the macro in Iteration 3\r\nIteration 4\r\nMuch like the previous iteration, the threat actor makes changes to the Incompatible worksheet and the code\r\nwithin the macro. First, the threat actor added the string “hi” to two cells within the initially displayed\r\nIncompatible worksheet, as seen in Figure 24.\r\nFigure 24 Changes made to the Incompatible worksheet in Iteration 4\r\nThe actor also made modifications to the macro in this iteration, as seen in Figure 25. The actor changed the two\r\nfunction names from “Doon_Ini” and “Doon_SHSheet” to “Ini” and “SHSheet” respectively. Also, the actor\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 20 of 23\n\nchanged the variable name that stores the VB script obtained from the spreadsheet from “BackupVbs” to\r\n“Backup_Vbs”, and modified the PowerShell command to use this new variable as well. Lastly, the actor further\r\nsplit the name of the created task using concatenation to retain functionality.\r\nFigure 25 Changes made to the macro in Iteration 4\r\nIteration 5\r\nIn this iteration, the actor rearranges the order of the functions in the script, specifically putting the “Ini” function\r\nbefore the “SHSheet” function. Figure 26 shows this function reordering.\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 21 of 23\n\nFigure 26 Changes made to the macro within Iteration 5\r\nIteration 6\r\nIn the final iteration of testing, the actor moves the base64 encoded VB Script and the two base64 encoded\r\nPowerShell scripts to three different cells within the Incompatible worksheet. The actor also changes the macro to\r\naccess the base64 encoded strings from these new locations, which retains the functionality of this document.\r\nFigure 27 Changes made to the macro in Iteration 6\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 22 of 23\n\nSource: http://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nhttp://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://researchcenter.paloaltonetworks.com/2017/04/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/"
	],
	"report_names": [
		"unit42-oilrig-actors-provide-glimpse-development-testing-efforts"
	],
	"threat_actors": [
		{
			"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": "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": 1775434622,
	"ts_updated_at": 1775826779,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/891ff0bdcfaa85d8458a72837596030f2442f7ef.pdf",
		"text": "https://archive.orkl.eu/891ff0bdcfaa85d8458a72837596030f2442f7ef.txt",
		"img": "https://archive.orkl.eu/891ff0bdcfaa85d8458a72837596030f2442f7ef.jpg"
	}
}