{
	"id": "ab8210d2-ad6f-4f4d-84b9-6907d926628c",
	"created_at": "2026-04-06T00:10:41.390633Z",
	"updated_at": "2026-04-10T03:37:37.058606Z",
	"deleted_at": null,
	"sha1_hash": "15be840df470c4e48a8970474f1ec5728495f82e",
	"title": "Analyzing OilRig's Ops Tempo from Testing to Weaponization to Delivery",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4822488,
	"plain_text": "Analyzing OilRig's Ops Tempo from Testing to Weaponization to\r\nDelivery\r\nBy Robert Falcone, Kyle Wilhoit\r\nPublished: 2018-11-16 · Archived: 2026-04-02 11:27:27 UTC\r\nGaining insight into an adversary’s operational tempo in the early phases of the attack lifecycle can be very difficult.\r\nTypically, there are far fewer data points available to analyze in the reconnaissance and weaponization phases for a\r\nresearcher to use to determine how quickly an adversary operates prior to direct interaction with a target in the delivery\r\nphase. While continuing research on the August 2018 attacks on a middle eastern government that  delivered\r\nBONDUPDATER, Unit 42 researchers observed OilRig’s testing activities and with high confidence links this testing to the\r\ncreation of the weaponized delivery document used in this attack.\r\nClearly, OilRig incorporates a testing component within their development process, as we have previously observed OilRig\r\nperforming testing activities on their delivery documents and their TwoFace webshells. This testing component often\r\ninvolves making small modifications to their delivery documents and submitting these files to online public anti-virus\r\nscanning tools to determine the maliciousness of a submitted file and to figure out how to evade these detections. Providing\r\na free and quick anti-virus testing service, using these online scanners aids an attacker in understanding which anti-virus\r\nengine detects their malware, thus giving the attacker a metaphorical “quality assurance service.”\r\nTo determine OilRig’s operational tempo, we compared the creation times of the files created during testing, the creation\r\ntime of the delivery document and the time in which the spear-phishing email was sent in the attack. We found that OilRig\r\nbegan its testing activities just under 6 days prior to the targeted attack and performed three waves of testing attempts on\r\nAugust 20th, 21st, and 26th. The tester created the final test file less than 8 hours before the creation time of a delivery\r\ndocument, which was then delivered via a spear-phishing email 20 minutes later.\r\nOilRig’s Testing Activities \r\nWhile investigating recent attacks performed by the threat actor group OilRig using their new Bondupdater version, Unit 42\r\nresearchers searched for additional Microsoft Office documents used by OilRig hoping to locate additional malware being\r\nused in other attacks during the same time period. We focused on the functionality and pivoting off the original OilRig\r\nMicrosoft documents found during our recent investigation.\r\nUnit 42 researchers found 11 additional samples that were submitted across several public anti-virus testing sites, as seen in\r\nTable 1. These samples appeared to have been created by OilRig during their development and testing activities, all of which\r\nshare many similarities with the delivery document used in the recent OilRig attack against a Middle Eastern government,\r\nN56.15.doc (7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00) that we have also included in\r\nTable 1. During this testing, we saw document filenames that contain the C2 we witnessed in the targeted attack above,\r\nspecifically the filenames XLS-withyourface.xls and XLS-withyourface – test.xls.  The similarities in metadata, macro code,\r\nand the filenames containing the C2 domain name leads us to believe these files were in fact OilRig testing their code prior\r\nto use in the targeted attack that happened on August 26th. It is interesting to note that while all the testing files were\r\nMicrosoft Excel documents, the actual file used in the targeted attack was a Microsoft Word document.\r\nHash Last\r\nModified/Save\r\nDate\r\nAverage\r\nDetection\r\nCount on\r\nFirst\r\nFilename\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 1 of 14\n\nPublic\r\nSubmission\r\n6f522b1be1f2b6642c292bb3fb57f523ebedeb04f0d18efa2a283e79f3689a9f\r\n8/20/2018\r\n19:30:13\r\n22\r\nXLS-withyourface.x\r\n9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce\r\n8/20/2018\r\n19:31:54\r\n16\r\nXLS-withyourface.x\r\na5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e\r\n8/20/2018\r\n19:38:51\r\n6\r\nXLS-withyourface.x\r\n6719e80361950cdb10c4a4fcccc389c2a26eaab761c202870353fe65e8f954a3\r\n8/21/2018\r\n6:24:52\r\n4\r\nXLS-withyourface -\r\ntest.xls\r\n056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa\r\n8/21/2018\r\n7:58:16\r\n18 sss.xls\r\n216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576\r\n8/21/2018\r\n8:03:22\r\n5 sss.xls\r\n687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3\r\n8/21/2018\r\n8:08:36\r\n17 sss.xls\r\n364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56\r\n8/21/2018\r\n8:18:36\r\n9 sss.xls\r\n66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633\r\n8/26/2018\r\n5:43:07\r\n11 sss - Copy.xls\r\n70ff20f2e5c7fd90c6bfe92e28df585f711ee4090fc7669b3a9bd024c4e11702\r\n8/26/2018\r\n5:45:04\r\n7 sss - Copy.xls\r\n7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00\r\n8/26/2018\r\n13:34:00\r\n38 N56.15.doc\r\nTable 1 Files generated during testing activities and the document delivered in the related targeted attack\r\nThe metadata within the Microsoft Excel spreadsheets seen in Table 1 shows the OilRig developer began creating these\r\ntesting documents on August 20, six days prior to the related targeted attack. All of the testing activity performed by OilRig\r\noccurred prior to their attack on August 26th.  When cross referencing the ‘Last Modified Date’ dates across the testing and\r\nattack activity, it is easy to draw a timeline of activity, as seen in the timeline in Figure 1.\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 2 of 14\n\nFigure 1 Timeline of Testing and Attack Activity\r\nOn August 20, 22 anti-virus engines detected the first iteration of XLS-withyourface.xls as malicious, as seen in the chart in\r\nFigure 2. Over the next seven minutes, the tester created two more samples whose detections lowered from 16 detections to\r\nsix, respectively. Ultimately, the detection count was lowest early on August 21, still five days prior to the targeted attack.\r\nThe timeline in Figure 1 shows a gap in testing activity between August 21st and August 26th, when the tester stopped their\r\nactivities. However, they later continued by making modifications to the Excel document just prior to the attack on August\r\n26th. The last iteration of testing occurring less than 8 hours before the creation time of the Word delivery document used in\r\nthe targeted attack.\r\nFigure 2 Detection rate compared to the insertions and deletions that were performed in each iteration of testing\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 3 of 14\n\nThe chart in Figure 2 shows the detection rate of the file fell or rose as the tester modified the spreadsheet during each\r\niteration of testing. These changes in detection rates allow the tester to determine if the modified portion of the file was\r\ncausing detection. When analyzing this testing activity, we compared the number of changes performed in each iteration,\r\nspecifically the number of lines inserted and deleted based on the GitHub file diff, to the number of detections to determine\r\nif the amount of changes had an obvious effect on the detection rate. Figure 2 shows that iterations 1 and 2, with only\r\nminimal changes, resulted in a massive drop in detections, whereas iterations 3 and 4, with a large number of changes,\r\nresulted in a small drop and large increase in detections.\r\nAt a high level, the quantity of changes is not necessarily important to the tester, rather the quality of the changes helps the\r\ntester lower the detection rate while providing information on how to evade these detections. An example of a quality\r\nchange was the removal of the line of code that runs the dropped VBScript using “wscript” in Iteration 2, which lowered the\r\ndetection rate from 16 to 6. Ultimately, the tester used the knowledge gained from these testing iterations to create a delivery\r\ndocument that was more difficult to detect and likely to result in a successful attack. For details on the changes made in each\r\niteration, please reference the analysis in the Appendix.\r\nWhat Did OilRig Learn?\r\nDuring OilRig’s development efforts, the actors were clearly learning and adapting their development techniques. We\r\ncontinually witnessed the attackers submit their files to testing services only to make changes and resubmit to determine the\r\nspecific contents of the file that cause anti-virus detections. The OilRig actors used the knowledge learned in this process to\r\ndevelop a delivery document that would evade detection, thus increasing the chances of a successful attack.\r\nDoing a differential comparison between each of the documents, allowed Unit 42 researchers to watch each iteration of\r\ncode, giving a unique perspective into not only how OilRig performed their testing, but also what the actors may have\r\nlearned during their efforts to lower the detection of their delivery documents. While it’s impossible for us to say for certain\r\nwhat OilRig learned ,we can make some assumptions as to what they likely learned:\r\nSeveral detections of the macro hinged on the generic call to the built-in Shell function to run a dropped VBScript.\r\nRunning commands in a hidden window (vbHide flag) using the Shell function results in additional detections than\r\nwhen using a visible window (vbNormalFocus flag).\r\nIncluding the string “powershell” within the VBScript that the macro would write to the system caused several\r\ndetections.\r\nUsing string obfuscation on the “powershell” string and the “wscript” string within the command run using the Shell\r\nfunction would result in fewer detections.\r\nWhat Did We Learn?\r\nSimilar to the way OilRig learned to better circumvent detections, we as researchers also learned as we looked at each of the\r\niterations. Providing us with learning opportunities helps us understand the threat actor’s techniques and capabilities, as well\r\nas better pro-actively build protection mechanisms.\r\nWe learned that OilRig:\r\nMade changes to documents and quickly uploaded the file for testing, with an average of 33 seconds between the file\r\ncreation times and the testing time.\r\nWas not concerned about maintaining the macro’s functionality during testing efforts, as the changes made by the\r\ntester in many iterations made the macro no longer work as intended.\r\nWill change the functions to run dropped VBScripts, specifically in this case from the Shell object to the built-in\r\nShell function.\r\nWill add sleep functionality in an attempt to evade sandboxes, specifically in this case using the Wait function.\r\nHas a preferred string obfuscation technique, which involves replacing a string with each character in hexadecimal\r\nform that are concatenated together.\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 4 of 14\n\nAfter performing this analysis, we believe the OilRig actors used the macro from the malicious Excel document as the basis\r\nfor the malicious Word document we discussed in our blog. We believe with high confidence that this macro was used to\r\ncreate the delivery document based on the following similarities:\r\nUsed the same string obfuscation technique that represents a string by its individual hex values concatenated together,\r\nas this technique is present in both the testing Excel documents and the Word document used in OilRig’s recent attack\r\nfrom our previous blog.\r\nObfuscated the “powershell” and “cmd.exe” strings within the embedded VBScript using this string obfuscation\r\ntechnique, which was tested in Iteration 4 of these testing activities.\r\nObfuscated the command run by the built-in Shell function using this string obfuscation technique, which was tested\r\nin Iteration 8 of these testing activities.\r\nIt appears that OilRig actors modified the macro used in the testing activity to create the weaponized delivery document.\r\nThe modifications involved adding a function named “HGHG” to save the obfuscated BONDUPDATER PowerShell script\r\nto a file. OilRig also changed the variable used to store the VBScript to a variable named “A” in the weaponized Word\r\ndocument instead of “DDDD” as witnessed in the testing Excel documents. Lastly, the actors removed the function “AA”\r\nfrom the macro, as this function displays a hidden spreadsheet that would contain the decoy content, which is specific to\r\nExcel and not needed for the Word document.\r\nConclusion\r\nAttackers and groups routinely use file and URL scanning services to help develop and modify their malware to evade\r\ndetections. We were already familiar with OilRig’s testing and development efforts as discussed in our previous blog, and\r\nwe continually watch for changes to OilRig’s development techniques to give us insight into their methods. Gaining this\r\ndevelopmental insight sheds light on OilRig’s advanced capabilities, giving us a more complete threat actor profile.\r\nClosely examining the development methodologies of attack groups gives researchers unique opportunities to develop an\r\nunderstanding of actor tools, tactics, and procedures. Comparison between what malware is eventually used in active\r\ncampaigns versus in-development malware allows us to understand what adaptations and modifications were made to each\r\niteration of malware. Additionally, witnessing specific functionality changes within the malware itself, we attempt to make\r\ncorrelations between the new and old functionality. We were also able to gain insight into OilRig’s operational tempo by\r\ncomparing the timestamps of files created during testing and the file delivered in an actual attack. We determined that OilRig\r\nbegan their testing activities 6 days prior to an attack, which ended 8 hours before the creation of the document that the\r\nactors delivered via a spear-phish email 20 minutes later.\r\nWhile OilRig remains active, Palo Alto Networks customers are protected from this threat in the following ways:\r\nAutoFocus customers can track these samples with the Bondupdater_Docs\r\nWildFire detects all current OilRig Bondupdater_Docs files with malicious verdicts.\r\nTraps blocks all of the files currently associated with Bondupdater_Docs\r\nAppendix\r\nThis appendix contains the analysis we performed on each iteration of testing. Before the analysis of each iteration, we have\r\nincluded some additional information about the files and the detection rate, as seen and described in Table 1.\r\nField Description\r\nFiles The SHA256 hashes of the two files we compared to determine the changes made\r\nFilenames The filenames of the two files compared\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 5 of 14\n\nDelta The time difference between the “Modified” timestamp found within the metadata of each file\r\nPositives\r\nThe detection rate of the two files compared together, which provides an idea of how the changes in that\r\ntesting iteration effected the overall detection\r\nTable 1 Additional data provided for each Iteration of testing\r\nThe analysis portion of each iteration includes a description of the changes made to the macro in the delivery document.\r\nThese changes are also visualized in screenshots of diffs between the two files compared in that iteration. When looking at\r\nthe diff screenshots, lines with a red background were removed from a file, while lines with a green background were added\r\nto the file.\r\nIteration 0\r\nThe first known file associated with this testing activity does not appear to be the original document created by the actor. We\r\nbelieve this is the case because this Excel spreadsheet contains a stream named __SRP_0 that appears to have artifacts from\r\na previous version of this delivery document. The  __SRP_0  stream contains artifacts, specifically a series of base64\r\nencoded strings that when decoded are almost an exact copy of the BONDUPDATER PowerShell payload named\r\n“AppPool.ps1” that was dropped by 7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00 discussed\r\nin our blog discussing OilRig’s attack on a middle eastern government in August 2018. In Figure 2 below, we compared the\r\ndecoded base64 strings from __SRP_0   to the “AppPool.ps1” file that was discussed in our previous blog, which shows the\r\nexact same content (including “withyourface[.]com” C2) with the only differences being newlines and spaces.\r\nFigure 2 Comparison of previous BONDUPDATER payload with payload extracted from cached stream\r\nWhen we analyzed this specific sample, we noticed that the tester has changed the method in which the PowerShell payload\r\nis dropped to the system from the malicious Word document discussed in our blog. Instead of writing the AppPool.ps1 file\r\nfrom the macro, the macro in this malicious Excel document only writes the AppPool.vbs, which the macro will run using\r\n“wscript”. The VBScript is then responsible for writing AppPool.ps1 to the system, which is the main difference from the\r\nWord document’s method discussed in our previously mentioned blog.\r\nAlso, it appears the tester removed the BONDUPDATER payload from the sample altogether, as the AppPool.vbs script uses\r\nan empty variable named “mysrc” that it would have used to store the base64 encoded payload, which it would decode and\r\nsave to the AppPool.ps1 file.\r\nAs mentioned earlier, we believe this testing activity preceded the attack that used the Word delivery document discussed in\r\nour blog. We also believe that this was not the only round of testing performed by the threat group, as the BONDUPDATER\r\ntool existing in the __SRP_0  stream suggests that the tester had created a prior document that contained the payload that\r\nwas removed from this testing activity. It is possible that the tester had previously performed testing activities on the\r\nPowerShell payload and removed it to isolate their current testing activities on the macro portion of the delivery document.\r\nIteration 1\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 6 of 14\n\nFiles\r\n6f522b1be1f2b6642c292bb3fb57f523ebedeb04f0d18efa2a283e79f3689a9f ..\r\n9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce\r\nFilenames XLS-withyourface.xls -\u003e XLS-withyourface.xls\r\nDelta 1 minute 41 seconds\r\nPositives 22 -\u003e 16\r\nIn this iteration, the tester made one simple change, which involved removing the string “powershell.exe” from being\r\nwritten to the AppPool.vbs file. This change essentially breaks the installation process, as the VBScript would no longer be\r\nable to run the AppPool.ps1 run correctly; however, the tester made this change to determine if detection stemmed from this\r\nstring. The diff in the screenshot in Figure 3 does not make the missing “powershell.exe” string immediately apparent,\r\nhowever, if you look for “Shell0” on line 24 you can see “powershell.exe -exec bypass” in the left (red) text and “ -exec\r\nbypass” in the right (green) text.\r\nFigure 3 Screenshot of diff between files related to Iteration 1\r\nIteration 2\r\nFiles\r\n9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce ..\r\na5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e\r\nFilenames XLS-withyourface.xls -\u003e XLS-withyourface.xls\r\nDelta 6 minutes 57 seconds\r\nPositives 16 -\u003e 6\r\nIn this iteration, the tester removed the line responsible for running the AppPool.vbs script using the wscript application. As\r\nyou can see in Figure 4, the tester just removed the entire line of code and replaced it with a new line.\r\nFigure 4 Screenshot of diff between files related to Iteration 2\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 7 of 14\n\nIteration 3\r\nFiles\r\na5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e ..\r\na5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e\r\nFilenames XLS-withyourface.xls -\u003e XLS-withyourface.xls\r\nDelta 10 hours 46 minutes 1 second\r\nPositives 6 -\u003e 4\r\nIn this iteration, the tester made fairly significant changes to the macro. First, the tester introduced a line of code that would\r\nsleep for 10 seconds after creating the “C:\\ProgramData\\WindowsAppPool” folder and before writing the AppPool.vbs file\r\nto this folder, which can be seen in Figure 5 at line 12. The bottom of Figure 5 and continued into Figure 6 shows that the\r\ntester also added the base64 encoded BONDUPDATER PowerShell payload to the DDDD variable instead of the VBScript\r\nseen in previous versions of this macro. The base64 encoded BONDUPDATER included here is the exact same payload in\r\nthe first testing sample’s cached __SRP_0 stream mentioned in Iteration 0. Figure 7 also shows that the tester removed the\r\nline that set the Shell0 variable to contain the “wscript.shell” object that it would theoretically use to run the VBScript.\r\nFigure 5 Screenshot of diff between files related to Iteration 3 showing sleep code and other objects added\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 8 of 14\n\nFigure 6 Screenshot of diff between files related to Iteration 3 showing changes to variable used to store VBScript\r\nFigure 7 Screenshot of diff between files related to Iteration 3 showing removal of the ‘wscript.shell’ object\r\nIteration 4\r\nFiles\r\n6719e80361950cdb10c4a4fcccc389c2a26eaab761c202870353fe65e8f954a3 ..\r\n056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa\r\nFilenames XLS-withyourface.xls -\u003e sss.xls\r\nDelta 1 hour 33 minutes 24 seconds\r\nPositives 4 -\u003e 18\r\nIn this iteration, the tester replaces the base64 encoded PowerShell script in the macro with the VBScript that it replaced in\r\nthe previous iteration. The tester also removed some lines of code that instantiated the “Scripting.FileSystemObject” and\r\n“Wscript.Shell” objects (line 17 and 18 in Figure 8).\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 9 of 14\n\nFigure 8 Screenshot of diff between files related to Iteration 4 showing VBScript added back to the macro\r\nIt appears that the tester reintroduced the VBScript to the macro, albeit with slight modification. The two modifications to\r\nthe VBScript stored in the DDDD variable come in the form of obfuscating two of the strings within the script, specifically\r\nthe “powershell” (line 24 in Figure 9) and “cmd.exe” (line 25 in Figure 9) strings. Instead, both of these strings were\r\nconstructed one character at a time using the hexadecimal value for each character and concatenated together. For instance,\r\nthe  “powershell” string was replaced with the following:\r\nChr(CLng(\"\u0026H70\")) \u0026 Chr(CLng(\"\u0026H6f\")) \u0026 Chr(CLng(\"\u0026H77\")) \u0026\r\nChr(CLng(\"\u0026H65\")) \u0026 Chr(CLng(\"\u0026H72\")) \u0026 Chr(CLng(\"\u0026H73\")) \u0026\r\nChr(CLng(\"\u0026H68\")) \u0026 Chr(CLng(\"\u0026H65\")) \u0026 Chr(CLng(\"\u0026H6c\")) \u0026\r\nChr(CLng(\"\u0026H6c\"))\r\nThe tester also added a line (line 29 in Figure 9) that uses the built-in Shell function to run the “AppPool.vbs” script using\r\nthe wscript application. The tester used the “vbHide” flag in the call to the Shell function, which will run the command in a\r\nhidden window.\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 10 of 14\n\nFigure 9 Screenshot of diff between files related to Iteration 4 showing string obfuscation and use of the built-in Shell\r\nfunction\r\nIteration 5\r\nFiles\r\n056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa -\u003e\r\n 216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576\r\nFilenames sss.xls -\u003e sss.xls\r\nDelta 5 minutes 6 seconds\r\nPositives 18 -\u003e 5\r\nIn this iteration, the tester removes the call to the built-in Shell function that runs the “AppPool.vbs” script using wscript that\r\nthey introduced in the previous iteration. Figure 10 shows that the tester removed the code on line 29 by replacing it with an\r\nempty line.\r\nFigure 10 Screenshot of diff between files related to Iteration 5 showing removal the call to the Shell function\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 11 of 14\n\nIteration 6\r\nFiles\r\n216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576 -\u003e\r\n687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3\r\nFilenames sss.xls -\u003e sss.xls\r\nDelta 5 minutes 14 seconds\r\nPositives 5 -\u003e 17\r\nIn this iteration, the tester reintroduces the call to the built-in Shell function that they removed in the prior iteration.\r\nHowever, the tester did not include the command to run by omitting the string to run the “AppPool.vbs” script using wscript.\r\nFigure 11 shows that the call to the Shell function has a blank command parameter. The detection rate increased\r\nconsiderably, which suggests that the detection rate was not based on the command itself, rather detection stemmed on the\r\ngeneric call to the built-in Shell function.\r\nFigure 11 Screenshot of diff between files related to Iteration 6 showing the use of an empty command in the Shell function\r\nIteration\r\nFiles\r\n687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3  -\u003e\r\n364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56\r\nFilenames sss.xls -\u003e sss.xls\r\nDelta 10 minutes\r\nPositives 17 -\u003e 9\r\nIn this iteration, the tester reintroduces the command to run the “AppPool.vbs” script using wscript to the call to the built-in\r\nShell function, as seen in Figure 12. However, this time the tester uses the “vbNormalFocus” flag instead of the “vbHide”\r\nflag, which runs the command in a visible command prompt window. This change lowers the detection rate by 8, which\r\nsuggests that the use of the “vbHide” flag within the Shell function was considered malicious by several vendors.\r\nFigure 12 Screenshot of diff between files related to Iteration 7 showing use of a visible window when running command\r\nIteration 8\r\nFiles\r\n364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56  -\u003e\r\n66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633\r\nFilenames sss.xls -\u003e sss - Copy.xls\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 12 of 14\n\nDelta 4 days 21 hours 24 minutes 31 seconds\r\nPositives 9 -\u003e 11\r\nThis iteration of testing was performed well after the previous iteration with the newly generated file being created almost 5\r\ndays after its predecessor. This large delta in file creation times could suggest a new round of testing activities; however, the\r\nfilename for this newly generated file is “sss - Copy.xls” while the previous file was named “sss.xls”. Comparing these two\r\nfilenames suggests that the tester may have copied the file generated in the previous iteration to use as a basis for this current\r\niteration of testing. Due to the filenames and the changes made to the macros in these two documents, we are treating this\r\nactivity as part of the ongoing testing efforts.\r\nIn this iteration, the tester made a few changes to multiple portions of the macro. First, the tester removed the line of code\r\nthat would have the macro sleep for 10 seconds, which was first introduced in iteration 3. Figure 13 shows the removal of\r\nthis line of code, which uses the “Application.Wait” function to sleep for 10 seconds.\r\nFigure 13 Screenshot of diff between files related to Iteration 8 showing removal of the sleep functionality\r\nThe next modification made by the tester involved obfuscating the string “wscript “ within the command run within the\r\nShell function. The tester uses the same string obfuscation technique used in previous iterations by replacing the string with\r\neach character in hexadecimal form concatenated together. Figure 14 shows  the obfuscated string “Chr(CLng(\"\u0026H77\")) \u0026\r\nChr(CLng(\"\u0026H73\")) \u0026 Chr(CLng(\"\u0026H63\")) \u0026 Chr(CLng(\"\u0026H72\")) \u0026 Chr(CLng(\"\u0026H69\")) \u0026 Chr(CLng(\"\u0026H70\")) \u0026\r\nChr(CLng(\"\u0026H74\")) \u0026 Chr(CLng(\"\u0026H20\"))” used to represent “wscript “.\r\nFigure 14 also shows the tester changed the variable name used to store the ActiveSheet object that represents the current\r\nExcel worksheet. The tester changed this variable name from “sh” to “Sh” (line 41), which the tester also changed in each\r\npreceding line (lines 43, 45 and 47) when using the object.\r\nFigure 14 Screenshot of diff between files related to Iteration 8 showing use of string obfuscation on command and modified\r\nvariable name\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 13 of 14\n\nIteration 9\r\nFiles\r\n66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633  -\u003e\r\n70ff20f2e5c7fd90c6bfe92e28df585f711ee4090fc7669b3a9bd024c4e11702\r\nFilenames sss - Copy.xls -\u003e sss - Copy.xls\r\nDelta 1 minute 57 seconds\r\nPositives 11 -\u003e 7\r\nIn the last iteration of testing, the tester removes the entire line of code used to call the Shell function used to call the\r\n“AppPool.vbs” script that included the obfuscated “wscript” string. Figure 15 shows that the tester merely removed the\r\nentire line and did not replace it with any code, which suggests that the macro would never run the VBScript file that it saves\r\nto the system.\r\nFigure 15 Screenshot of diff between files related to Iteration 9 showing removal of the Shell command\r\nSource: https://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nhttps://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MISPGALAXY",
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/"
	],
	"report_names": [
		"unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery"
	],
	"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": 1775434241,
	"ts_updated_at": 1775792257,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/15be840df470c4e48a8970474f1ec5728495f82e.pdf",
		"text": "https://archive.orkl.eu/15be840df470c4e48a8970474f1ec5728495f82e.txt",
		"img": "https://archive.orkl.eu/15be840df470c4e48a8970474f1ec5728495f82e.jpg"
	}
}