{
	"id": "f2ae3994-830d-47a8-9589-2a60e52ee589",
	"created_at": "2026-04-06T00:11:11.770054Z",
	"updated_at": "2026-04-10T13:11:19.03463Z",
	"deleted_at": null,
	"sha1_hash": "505326c2819ae627a88306ef2932cabecff36cb7",
	"title": "Shamoon 2012 Full Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 16118284,
	"plain_text": "Shamoon 2012 Full Analysis\r\nBy Myrtus 0x0\r\nPublished: 2019-12-21 · Archived: 2026-04-05 19:15:45 UTC\r\nThe whole inspiration of this blog began when I saw the above picture.\r\nFor those that don't know, this was ASCII art embedded within a .NET dropper that supposedly dropped a version\r\nof Shamoon back in December of 2018. This immediately peaked my interest and I began my reversing of the\r\nsample. Initially I was looking for resources around this specific sample but quickly found that Shamoon has a\r\nrich history and has been utilized in some very interesting campaigns. So I decided I would start at its beginning\r\nand work my way through its history. At this point I have almost 40 samples for the various campaigns and have\r\nreverse engineered all of them to various degrees. These samples were relatively unorganized and I needed a way\r\nto fix that. I wrote a tool that could categorize the samples based on various traits. The samples broke down into a\r\ncouple of groups and after looking into a sample from each group, I identified the following campaigns:  \r\nShamoon 2012\r\nShamoon 2016\r\nShamoon 2017\r\nShamoon 2018 v1\r\nShamoon 2018 v2\r\nShamoon 2018 v3\r\nI will try to make a post describing the capabilities of a sample in each campaign if time permits. So without\r\nfurther ado, lets get into Shamoon 2012.\r\nResearch Process\r\nFor this series, I decided to focus on the following goals:\r\n1. Educate users on the timeline and history of Shamoon\r\n2. Share IOCs and detection mechanisms\r\n3. Release tools that can be used to help researchers analyze samples in the future\r\nWith these goals I decided the best plan of attack was to gather as many Shamoon samples that I could find, read\r\nall the blog posts/reports that I could find and listen to podcasts about the campaigns. I got my samples from\r\nvarious sources such as Hybrid Analysis, VirusTotal, Malware.one, VirusShare, TheZoo, and other malware\r\nresearchers in the field.\r\nWith a decent set I was keen on figuring out a way to programmatically sort the samples into their campaigns.\r\nAfter analyzing the samples I realized each sample over the years had resources that could be used to determine\r\nthe campaign it originated from. This led to the creation of a script that would group the samples based on the\r\nresources that were contained in each sample.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 1 of 69\n\nAll samples organized based on the unique resource names / IDs\r\nShamoon 2012 Overview\r\nThe first known target for the Shamoon malware was the oil company Saudi Aramco. For those that don't know\r\nSaudi Aramco is the largest petroleum and natural gas company in the world and a lot of Saudi Arabia's economy\r\nis centered around this single company. While they are a privately held company, it is estimated that the company\r\nis worth between 1-3 trillion dollars.\r\nConsidering their worth and their ties with the Saudi government, they are a prime target for cyber attacks.\r\nEspecially those that might not have the best relations with Saudi Arabia.\r\nIdeas of how Shamoon ended up on the Saudi Aramco's systems is unclear currently. Some reports say it was via\r\nthe Acunetix vulnerability scanner, a phishing email or simply even a malicious USB that an employee had\r\ninserted into their machine. Speculation is that the threat actor got into the network sometime around April or May\r\nof 2012 and spent the next couple of months moving laterally and trying to gain access to a Domain Controller.\r\nAll this effort led up to the events of August 15th 11:08 AM when over 80% of Saudi Aramco's workstations and\r\nservers had their drives wiped due to a hard coded detonation date in the Shamoon malware.  Its important to note\r\nthat this date is not random, some might know that for 2012 the night before was a holiday known as the Night of\r\nPower or Lailat al-Qadr. It is regarded as one of Islam's holiest nights of the year. Much of the Islam community\r\nshuts down to celebrate the revelation of the Quran. As tradition for Saudi Aramco and most of the country, 50,000\r\nemployees stayed home on the 15th to celebrate the holiday and spend time with their families. This of course left\r\nthe company itself and the workstations in Saudi Arabia at its most vulnerable.\r\nIn addition to having the users drives wiped, the workstations were left with an the first 1024 bytes of an image of\r\na burning American flag. Although most users weren't even able to view this picture as their master boot records\r\nhad been corrupted in the process. This could be taken as a political statement or a misdirection.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 2 of 69\n\nComplete image of snippet left on the workstations\r\nNearly 11 hours after the detonation timestamp of Shamoon, a post was shared on popular paste site pastebin.com,\r\nwhich stated the following.\r\nWe, behalf of an anti-oppression hacker group that have been fed up of crimes and atrocities taking\r\nplace in various countries around the world, especially in the neighboring countries such as Syria,\r\nBahrain, Yemen, Lebanon, Egypt and ..., and also of dual approach of the world community to these\r\nnations, want to hit the main supporters of these disasters by this action.\r\nOne of the main supporters of this disasters is Al-Saud corrupt regime that\r\nsponsors such oppressive measures by using Muslims oil resources. Al-Saud is a partner in committing\r\nthese crimes. It's hands are infected with the blood of innocent children and people.\r\nIn the first step, an action was performed against Aramco company, as the largest financial source for\r\nAl-Saud regime. In this step, we penetrated a system of Aramco company by using the hacked systems\r\nin several countries and then sended a malicious virus to destroy thirty thousand computers networked\r\nin this company. The destruction operations began on Wednesday, Aug 15, 2012 at 11:08 AM (Local\r\ntime in Saudi Arabia) and will be completed within a few hours.\r\nThis is a warning to the tyrants of this country and other countries that support such criminal disasters\r\nwith injustice and oppression. We invite all anti-tyranny hacker groups all over the world to join this\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 3 of 69\n\nmovement. We want them to support this movement by designing and performing such operations, if\r\nthey are against tyranny and oppression.\r\nCutting Sword of Justice\r\nThis post needs to be taken with a grain of salt, as there is no definitive way to tell if this is from the actor. Now\r\nthey did have the exact detonation date which to me, is a clear sign that this is from the actual actor/s behind this\r\nattack. Now if we are to assume that this post is legit there are a couple things we can infer: This TA needs public\r\nvisibility, they have ties to countries surrounding Saudi Arabia or are at least empathetic towards them, their major\r\ntarget is Al Saud which is the royal family in Saudi Arabia. Notably, this is also the first mention of the Cutting\r\nSword of Justice.\r\nNormally when we see attacks that are targeted like this, the goal tends to be data exfiltration and maintaining a\r\nlow profile to reduce the risk of detection but this attack was the complete opposite. Clearly the intent was not to\r\nsteal information, as even stranger is the impact that something like ransomware or intellectual property theft\r\ncould've been, due to the amount of raw resources the company has. This all points to the idea that this attack was\r\nmeant to damage perceptions in the public's eye as well as weaken the resulting country.\r\nOf course all of this would cause Saudi Arabia to make determinations as to who was behind such an attack,\r\nwhich they promptly implicated Iran. The Saudi government issued an official statement blaming Iran for this\r\nattack. That decision could've solely been made due to their relations with Iran or for the fact that the PDB string\r\nof Shamoon contains the following ArabianGulf which is highly contested zone which Iran has always claimed\r\nthat is it part of their country and should be properly named the Persian Gulf. Although this could also be a\r\nattempt at misdirection shifting blame towards Iran as APT groups tend to do.\r\nArabian (Persian) Gulf\r\nIn addition to making this accusation Saudi Aramco made two major actions directly after attack:\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 4 of 69\n\n1. Fly employees to computer hardware factories and purchase as many hard drives as possible (50,000 at one\r\ntime)\r\n2. Lie about the attack, saying that operations had returned to normal when in fact they hadn't\r\nSaudi Aramco made the decision to call for external help as they didn't have the capability to handle an attack of\r\nthis grandeur. Now Saudi Arabia didn't really have to many options for who they could call as they refuse to use\r\nany devices or personnel that originate from Israel, so they decided to call on Chris Kubecka and contract her to\r\ncreate a team to analyze the samples as well as setup a legitimate security program.\r\nIt turns out there wasn't much identifying information in the sample and due to Pastebin's operations, there was no\r\nway to track the paste back to a user let alone a country. So quickly things became pretty quiet as Saudi Aramco\r\nwasn't exactly making public statements nor was there new evidence about the group. This didn't sit well with The\r\nCutting Sword of Justice and they followed up with a second post on Pastebin on August 29th 2012 at at 1:37\r\nCDT.\r\nmon 29th aug, good day, SHN/AMOO/lib/pr/~/reversed\r\nWe think it's funny and weird that there are no news coming out from Saudi Aramco regarding\r\nSaturday's night. well, we expect that but just to make it more clear and prove that we're done with we\r\npromised, just read the following facts -valuable ones- about the company's systems:\r\ninternet service routers are three and their info as follows:\r\nCore router:   SA-AR-CO-1#  password (telnet): c1sc0p@ss-ar-cr-tl  / (enable): c1sc0p@ss-ar-cr-bl\r\nBackup router: SA-AR-CO-3#  password (telnet): c1sc0p@ss-ar-bk-tl  / (enable): c1sc0p@ss-ar-bk-bl\r\nMiddle router: SA-AR-CO-2#  password (telnet): c1sc0p@ss-ar-st-tl  / (enable): c1sc0p@ss-ar-st-bl\r\nKhalid A. Al-Falih, CEO, email info as follows:\r\nKhalid.falih@aramco.com      password:kal@ram@sa1960\r\nsecurity appliances used:\r\nCisco ASA    #    McAfee #   FireEye : default passwords for all!!!!!!!!!!\r\nWe think and truly believe that our mission is done and we need no more time to waste. I guess it's time\r\nfor SA to yell and release something to the public. however, silence is no solution.\r\nI hope you enjoyed that. and wait our final paste regarding SHN/AMOO/lib/pr/~\r\nangry internet lovers\r\n#SH\r\nThey decided to dump router credentials, internal security knowledge and username and password for the CEO\r\nKhalid Al-Falih (now Minister of Energy of Saudi Arabia and Chairman for Saudi Aramco).\r\nTechnical Analysis\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 5 of 69\n\nDuring my research process I discovered 4 unique samples relating to this campaign. The samples and all my\r\npublic work is shared in a GitHub repo here\r\nB14299FD4D1CBFB4CC7486D978398214\r\nB128376F2D45CFDF21035D3029EF0D6C\r\nECC2CB6ADC0F0390ADFA9936D149657B\r\nD214C717A357FE3A455610B197C390AA\r\nFor this post I will solely be talking about B128376F2D45CFDF21035D3029EF0D6C. I always start my analysis\r\nprocess with static properties as those can give some a high level overview of what the sample might be able to\r\ndo. For this, I generally use PE Studio. Looking in PE Studio we see the following information\r\nPE Studio Output\r\nImmediately the entropy of the file stands out indicating some sort of encryption or packed data. Under the\r\nresources tab we see the 3 resources along with some version information\r\nShamoon Resources\r\nWe can see 3 resources named PKCS12 PKCS7 and X509. The high entropy and percentage of file immediately\r\nstand out as a potential payload or some form of encrypted data. This is unusual for standard files executables as\r\nresources are generally used for icons or small images rather than data blobs with high entropy. When I see\r\nresources I will generally save them off for later analysis with Resource Hacker. Although these resources do\r\ncontain relatively high entropy values, they aren't 7.99 or above the 7.9 threshold, which means if they are\r\nencrypted its through some rudimentary techniques rather than a well established technique like AES of RC4.\r\nThe next thing I look at is the strings. Strings can give information about actions the malware might take or if\r\nyou're lucky, even a C2 string or raw IOCs. Immediately we see a string that we can use as an IOC due to it's\r\nhardcoded name and the fact that the file name will most likely be unique across hosts.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 6 of 69\n\nFile Location String\r\nScrolling down we see a couple more strings that can prove valuable in understanding the behavior of this\r\nmalware.\r\nInteresting strings within the sample\r\nWe can see strings pointing to hardcoded file location, potential commandline execution, hardcoded domains etc.\r\nConsidering the magnitude and impact that this attack had, I was somewhat surprised to see such low effort taken\r\nobfuscate their work.\r\nCopyright string\r\nNext I found a copyright string for the company Dinkumware. This is a hardcoded string found in a replacement\r\nfor the C++ standard library which offers some extra features. Malware authors  use libraries from Dinkumware to\r\nsimplify the difficulty of the code they have to write. The libraries they provide offer APIs to work with vectors,\r\nlists, sets, maps, bitsets and generic algorithms.\r\nAt the end of the list of strings found were the names of the resources mentioned earlier, X509, PKCS7 and\r\nPKCS12. This supports the hypothesis that Shamoon will interact with those resources during runtime. A large\r\nstring pictured below stood out to me as there shouldn't be any reason for malware to require strings of this length.\r\nThis string turned out to be a description of a service Shamoon will create.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 7 of 69\n\nUnicode strings at the end of the file. \r\nEnables the Distributed Link Tracking Client service within the same domain to provide more reliable\r\nand efficient maintenance of links within the domain. If this service is disabled, any services that\r\nexplicitly depend on it will fail to start.\r\nSo this alone gives us an IOC. One could query all of their services and check if they have a description that\r\nmatches the one above. Now that we have finished all the triage for the sample, we can get into the assembly.\r\nFollowing is a list of IOCs we can utilize for future samples\r\n- \\inf\\netft429.pnf\r\n- myimage12767\r\n- c:\\windows\\temp\\out17626867.txt\r\n- \\\\System32\\\\cmd.exe /c \\\"ping -n 30 127.0.0.1 \u003enul \u0026\u0026 sc config TrkSvr binpath= system32\\\\trksrv.exe \u0026\u0026 ping -\r\nConsidering the high entropy of the resources and the size of them I started looking for references to those\r\nresource names as they're most likely going to be used in windows API calls to interact with them further.\r\nFor my analysis of assembly I use IDA Pro but any disassembler will do.\r\nx509 reference\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 8 of 69\n\nPKCS7 reference\r\nPKCS12 reference\r\nEach resource name string turns out to only have a single reference which is always an argument to this function\r\nsub_401977. Viewing the function shows the following:\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 9 of 69\n\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 10 of 69\n\nResource decryption routine\r\nAt a high level, we can assume the following actions based on the windows API calls:\r\n1. Find a resource\r\n2. Load the resource\r\n3. Lock the resource\r\n4. Create a file\r\n5. Write to the file\r\nAfter this we can see that its going to allocate a buffer of size var_8, which gets set when the value of EAX is\r\nmoved after the SizeOfResource call.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 11 of 69\n\nWrite resource\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 12 of 69\n\nIf the buffer is successfully allocated it enters the loop loc_401A6F which implements the following pseudo code:\r\nwhile i = 0; i \u003c sizeOfResource; i++ {\r\nbuf[i] = resource[i] ^ key[i % len(key)];\r\n}\r\nThis is a very common form of encryption for malware as it's simple, and highly optimized at the hardware level.\r\nXOR is built in instruction for the x86 assembly set, so it's something that can be calculated on the CPU itself.\r\nSingle and double byte XOR keys generally aren't going to thwart AV engines but later versions of Shamoon use\r\nextremely large XOR keys for resource decryption.\r\nSince we have now recognized this as an XOR decryption loop we need to find the key. Generally keys are passed\r\nas arguments if they are created during runtime or they are referenced by static constants. There are no references\r\nto static constants in this function so taking a look at the arguments we see the following buffer being passed.\r\nResource Decryption Call for PKCS12\r\nLooking at the function call, we can see 6 arguments being passed:\r\n1. an integer\r\n2. a constant\r\n3. a resource name\r\n4. a ordinal value for the resource\r\n5. a buffer\r\n6. a filename that is generated in this current function\r\nLooking at the constant that is being passed we see the following, as I was analyzing this stood out to me\r\nimmediately and I tested it as a decryption key.\r\nPKCS12 XOR key\r\nThis turned out to be correct so I knew the signature for the ResourceDecryption function was the following.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 13 of 69\n\nResourceDecryption(sizeOfKey int, resourceOrdinal int, resourceName string, fileBuf byte[], outputFilename stri\r\nSome malware analysts will take this knowledge and create a script to dump the resources so the payload can be\r\nanalyzed. While this is a valid decision, there is still information that we can pull out from the sample.\r\nAt this point it's important to figure out how the function gets called and what path needs to be taken from the\r\nentry point to get this file dumped. Opening the function at sub_401977 and hitting the button \"xrefs to current\r\nidentifier\" shows a view of function calls that are taken to reach the DecryptResource function. This aligns with\r\nthe 3 calls to DecryptResource as there are 3 resources contained within Shamoon.\r\nControl flow of program\r\nThis graph shows the functions that must be called to reach this point in the program. So this graph would lead up\r\nto main and would show us all of the potential checks the malware might do to determine it is running on the\r\ncorrect system.\r\nConsidering that the path to the resource decryption function is relatively short, we can assume that there won't be\r\ntoo many system checks or any at all.\r\nStarting from the top with _wmain, we can see its relatively small function.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 14 of 69\n\n_wmain graph\r\nThe first function called here I have renamed CheckWindowsDirectoryAndGetCLIArgs. This function is\r\nrelatively simple in what it does. it will load a hardcoded kernel32.dll path, prepend the windows directory\r\nvariable value to it, and check the creation time of that file. It then parses the commandline arguments passed with\r\nGetCommandLineW. Considering that eacho of the paths in the callgraph below, I will explain all of the\r\nfuntionality there in each of the followin resource section.\r\nPKCS7 Drop and Execution\r\nLooking at the call graph above the closest call is sub_40335c which we can see from the picture below will\r\ninteract with the PKCS7 resource.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 15 of 69\n\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 16 of 69\n\nAssembly following PKCS12 decryption\r\nFollowing the call to ResourceDecryption we see a couple calls to sub_4010AF and sub_401050 which seem to\r\ndo some string manipulation. At the end of the sub_40335c, there is a call to  sub_40286c. Now its important note\r\nthat all of the calls happening in this picture are after we have decrypted our PKCS7 resource. So with that\r\ninformation we can assume that its going to interact with the decrypted resource.\r\nDigging into sub_40286c, we can see a virtualAlloc and if it successfully allocates memory it will continue\r\nexecuting.\r\nvirtualAlloc within sub_40286c\r\nNow in the branch to the left we can see its going to copy some memory and pass some arguments to a function\r\nsub_4026EE. This function is going to get the process address of a function in netapi32.dll and execute it as we\r\ncan see below.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 17 of 69\n\nCall function within netapi32.dll\r\nThis is a common technique for malware authors as it allows them to load functions from libraries within\r\nreferences having to exist statically within the binary. So tools like PE studio wouldn't be able to pick up on this\r\nfunction call.\r\nThe function that is being loaded here is NetScheduleJobAdd which as per MS docs:\r\nThe NetScheduleJobAdd function submits a job to run at a specified  future time and date. This\r\nfunction requires that the schedule service  be started on  the computer to which the job is submitted.\r\nSo rather than directly importing netapi32.dll the actor decided to load this library during runtime. When an actor\r\ntakes the time to do this there is generally a purpose behind it.\r\nNow looking back at sub_40286c we know that its going to copy memory into the newly allocated buffer and start\r\na thread to schedule a task via the netap32.dll. Looking at the next piece of the control flow graph\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 18 of 69\n\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 19 of 69\n\nCreateProcess for PKCS12 payload\r\nNow if this operation were successful and the thread was created Shamoon will sleep for 0x17318 milliseconds or\r\n95000. This converts to a minute and 35 seconds. So once the application is finished sleeping it will create a\r\nprocess with the API call CreateProcessW. Now taking a step back again this function sub_40286c previously has\r\ndecrypted a resource, written it to disk and done some string manipulation. So from that we can determine that this\r\nCreateProcessW will start whatever PKCS7 decrypts to.\r\nSo now that we have an understanding about how PKCS7 is dropped and executed we can quickly go over x509\r\nand PKCS12.\r\nx509 Drop and Execution\r\nLooking back on that call graph, sub_403491 is the function that interacts and executes the x509 module. Now\r\nthis is handled a little differently than the PKCS7 resource.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 20 of 69\n\nx509 resource interaction\r\nsub_403491 starts by making a call to sub_4017bb which when looking into it checks that the system has the\r\nprocess architecture AMD64 (checks via the registry). If this check fails Shamoon will not execute/drop the x509\r\nresource. This is indicative that this resource might be performing some activity that is reliant on this specific\r\narchitecture type or targeting something specific, so definitely worth looking into. Following the check, this\r\nfunction will call OpenSCManager which establishes a connection to the service manager.\r\nFor those that aren't aware, the service manager is an integral part of windows that will execute tasks at a given\r\ninterval. It is also a technique that malware authors use to gain persistence in systems.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 21 of 69\n\nIt then moves the resulting handle into EAX and checks to see if it can open a service with that handle name\r\n\"TrkSvr\". OpenService will return null if it was unable to get a handle so the \"jz loc_40361A\" instruction will\r\nonly be taken if the TrkSrv service exists.\r\nIf the service exists it will then make a call to QueryServiceConfig which returns a non-zero value if the call was\r\nsuccessful. So if the function is able to get a config for the TrkSrv service it will continue executing.\r\nAssembly following x509 decryption\r\nThe calls to sub_4010AF are just string manipulation, most likely converting from ASCII to wide due to the\r\nsystem being windows. Looking at the function sub_401D5D, we see some calls to more string manipulation\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 22 of 69\n\nfunctions then at the end of the function we see the following:\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 23 of 69\n\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 24 of 69\n\nCreateFile wrapped with Wow64FsRedirection\r\nThe end of this function will call a wrapper function for Wow64DisableWow64FsRedirection. That windows\r\nAPI call on 64 bit systems will change the way files are written to system32 directory. Per the MSDN\r\ndocumentation:\r\nThis function is useful for 32-bit applications that want to gain access to the native system32 directory.\r\nBy default, WOW64 file system redirection is enabled.\r\nSo we know that this function will disable system32 redirection. Then it will create a file on disk with the name\r\ntrksrv.exe (which is one of the strings that is manipulated in the earlier portions of the function. If the function was\r\nsuccessful it will revert the system32 redirection and pop ESI to the stack which is the newly created file handle.\r\nSo now we know sub_401D5D is going to return a newly created file handle for trksrv.exe. Looking back at the\r\ncaller sub_403491 we are at the point right before the resource decryption function is called and we have a newly\r\ncreated file handle.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 25 of 69\n\nx509 write resource to disk\r\nThis process is exactly the same as the PKCS7 resource, it will decrypt based on the resource key and write the\r\nfile to disk via the trksrv.exe file handle.\r\nAfter the payload is written to disk, sub_4020FA is called which sole purpose is to change the file access, write\r\nand create time to the times of the initial Shamoon executable. Now that the file is written to disk and Shamoon\r\nhas confirmed that there is a scheduled task for trksrv.exe it has no use for the service handle so it closes it.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 26 of 69\n\nSystem sleep and create process\r\nIf the handle was successfully closed, the above code block will be executed. As we can see it will do some string\r\nmanipulation and create a process for the cmd command above:\r\n\\\\System32\\\\cmd.exe /c \"ping -n 30 127.0.0.1 \u003enul \u0026\u0026 sc config TrkSvr binpath= system32\\\\trksrv.exe \u0026\u0026 ping -n\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 27 of 69\n\nBreaking this command down we can see a ping to localhost, changing the config value for TrkSrv, pinging\r\nlocalhost again and starting the service. These pings are a common tactic by malware authors to have their\r\napplications wait a certain period of time. Rather than calling a sleep which might be a function that is alerted on,\r\nauthors will execute a ping N number of times and wait for those pings to succeed, then execute their command.\r\nIf the process was successfully created, then the function will close the handles created by the various windows\r\nAPI calls here the malware has now successfully dropped a secondary payload via the service task TrkSvr.  \r\nPKCS12 Drop and Execution\r\nThe last resource we figure out is the PKCS12 resource. Looking back at the call graph we can see that\r\nsub_4056B2 a seemingly random hard coded string an a reference to a text file in \\windows\\temp called\r\nout17626867.txt. This file doesn't have any other references in the code nor any of the payloads. It also loads a\r\nimage called \"myimage12767\", this file would either have to be in the directory where Shamoon is running or as a\r\nresource in the file itself. As neither is true it is difficult to say what the purpose of this image and the text file are.\r\nEventually this function will create a random file name based on the time at that call, check if a process is already\r\nrunning with that filename and if there isn't one, will write the PKCS12 resource to that path and execute it.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 28 of 69\n\nWrite PKCS12 resource to disk\r\nWith that, we have covered all the payloads and its time to go into how the resources are decrypted and what their\r\nexact purposes are.\r\nCall Graph Overview\r\nWith the understanding of how all the resources are dropped we have now reversed all of the functions that lead\r\nup to each of the resources being dropped. When renaming the functions to the appropriate actions that they\r\nperform, we get a call graph like the following.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 29 of 69\n\nNamed call graph\r\nNow with all these functions being named, we have a clear picture of how these resources and executed. the x509\r\nresource is used as a newly created service, PKCS12 is executed as a randomly named file, and PKCS7 is started\r\nwith a CreateProcessW after it's written to disk.\r\nResource Decryption\r\nNow that we have covered how Shamoon executes its payloads and sets up persistence, we can take a look again\r\nat how the resources are actually decrypted. This means we will be looking at function sub_00401977 or as I have\r\nit renamed WriteResourceToDisk.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 30 of 69\n\nDecryptResource initial steps\r\nAs stated above this function will find a resource based on an ordinal, load the resource into memory, create a file,\r\ndecrypt the buffer and write it to disk. From the arguments to this function decryption becomes very trivial. I\r\ndecided to hard code the keys in my script as they're consistent across all Shamoon 2012 samples.\r\n\"\"\"\r\nWorks for 3/3 resources\r\n\"\"\"\r\nfiles = {\r\n # Comms module\r\n 'PKCS7': [\"61E8F2AF61_Resources\\PKCS7113.bin\",\r\n \"61E8F2AF61_Resources\\PKCS7113_decrypted.bin\",\r\n [0x17, 0xD4, 0xBA, 0x00]\r\n ],\r\n # x64 variant of dropper\r\n 'x509': [\"61E8F2AF61_Resources\\X509116.bin\",\r\n \"61E8F2AF61_Resources\\X509116_decrypted.bin\",\r\n [0x5C, 0xC2, 0x1A, 0xBB]\r\n ],\r\n # Wiper module\r\n 'PKCS12': [\"61E8F2AF61_Resources\\PKCS12112.bin\",\r\n \"61E8F2AF61_Resources\\PKCS12112_decrypted.bin\",\r\n [0x25, 0x7F, 0x5D, 0xFB]\r\n ]\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 31 of 69\n\n}\r\nimport os\r\ndef decrypt(data, key):\r\n keyLength = len(key)\r\n decoded = \"\"\r\n for i in range(0, len(data)):\r\n decoded += chr(data[i] ^ key[i % keyLength])\r\n return decoded\r\ndef main():\r\n for rname, file in files.items():\r\n src_resource = file[0]\r\n dst_resource = file[1]\r\n xor_key = file[2]\r\n \r\n print(\"[+] Decrypting resource {}\".format(rname))\r\n print(\"[+] Using Decryption key: {}\\n\".format(xor_key))\r\n \r\n key = bytearray(xor_key)\r\n data = bytearray(open(src_resource, 'rb').read())\r\n \r\n decryptedData = decrypt(data, key)\r\n if len(decryptedData) == 0:\r\n print(\"[!] not able to decrypt resource {}\".format(src_resource))\r\n with open(dst_resource, \"wb+\") as dst:\r\n dst.write(decryptedData)\r\nif __name__ ==\"__main__\":\r\n main()\r\nI dumped the resources with resource hacker, then hardcoded the paths. With successful decryption we get the\r\nfollowing results.\r\nSuccessful decryption output\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 32 of 69\n\nIf you kept the paths the same, you should have a folder in the CWD that contains the encrypted and decrypted\r\nresources.\r\nShamoon Payload PKCS7\r\nThe first payload we will look at is the decrypted PKCS7 resource. First thing is to look at static properties.\r\nPE Studio overview\r\nUnsurprisingly has a ton of hits on VirusTotal, has a file description of TCP/IP NetBios Information, 2 resources\r\nthat don't mean much and the following interesting strings.\r\ndel /f /a %s%s*.%s\r\nhttp://%s%s?%s=%s\u0026%s=%s\u0026state=%d\r\n/ajax_modal/modal/data.asp\r\n\\inf\\netft429.pnf\r\nCopyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED.\r\n\\inf\\netfb318.pnf\r\nInteresting strings pulled out from the payload\r\nJust judging from the strings, it's probably going to connect to a host, interact with those hard coded filepaths,\r\ndelete some files and we also see the Dinkumware copyright string we saw in the initial look at the Shamoon\r\nsample.\r\nLooking at the sample, the function we care about is main which is sub_402B90 or as I've renamed it\r\nMalwareMain.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 33 of 69\n\nArg handling\r\nThe first thing this payload does is call sub_4020F0 or as I've renamed it GetIPAddress. This function will set\r\nWideIPAddressString to 0 if the the result of GetIPAddress is 0. Otherwise it will set the value of the pointer to\r\nWideIPAddressString in the function. It then will get the windows directory in ASCII and in wide, then will check\r\nargv[1] to see what the value is. The two arguments that are processed for the payload are the ASCII \"0\" and \"1\",\r\nas seen below.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 34 of 69\n\nArgument control flow\r\nIf you pass a 0 as the first argument to the payload, it will do a subsequent check to see if there is a 2nd argument.\r\nif there is a second argument it will pass that to sub_402240, otherwise it will pass 0 to sub_402240. After\r\nsub_402240 is called the program will exit.\r\nSo to summarize, what we've seen so far:\r\npkcs7.exe 0 1 will pass 1 to sub_402240\r\npkcs7.exe 0 will pass 1 to sub_402240\r\nNow looking into sub_402240, the first thing it will do is create a internet handle that it will use for further\r\nWinINet functions.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 35 of 69\n\nSingular InternetOpen call\r\nThe first argument to InternetOpenW is the purpose of the handle or user-agent, and interestingly it sets this\r\nvalue to \"you\". As soon as the InternetOpenW call is made, there is a loop that begins.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 36 of 69\n\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 37 of 69\n\n(I understand the quality of the picture is bad but I had to zoom out in IDA to take it) but the basic idea of this\r\nloop is to iterate over the values stored at the HomePointer, which in our case is the following\r\nC2 array\r\nSo this loop will iterate twice, once with the string \"home\" and once with the hardcoded IP \"10.1.252.19\". So this\r\nloop will get the tick count, pass arguments to the format string http://%s%s?%s=%s\u0026%s=%s\u0026state=%d and\r\nmake a call to InternetOpenW then delete the buffer containing the built out format string. So our possibilities\r\nfor this loop are.\r\nhttp://10.1.252.19/ajax_modal/modal/data.asp?mydata=\u003cargToFunction\u003e\u0026uid=\u003cIPAddressAcquiredInMalwareMain\u003e\u0026state=\r\nhttp://home/ajax_modal/modal/data.asp?mydata=\u003cargToFunction\u003e\u0026uid=\u003cIPAddressAcquiredInMalwareMain\u003e\u0026state=CurrentM\r\nLooking at the IP address, it falls within private IP space so its communicating with a server that is hosted within\r\nSaudi Aramco's environment. In the second iteration it tries to communicate with a host \"home\" so either this is a\r\ninternal hostname set by Saudi Aramco or some host entry set per host where home=10.1.252.19. The use of a\r\nhardcoded private IP address is unique and means that the Cutting Sword of Justice had access to Saudi Aramco's\r\nenvironment before creating and deploying Shamoon. So that hardcoded \"home\" and 10.1.252.19 serve as a C2\r\nbetween the PKCS7 resource and the actor.\r\nConsidering this sample is 7 years old now and uses a private IP for its C2 there is no chance we will be able to\r\nproperly emulate the C2 but from the control flow we can infer what the malware will do based on the results.\r\nOnce it gets a handle to the C2, a call to InternetReadFile is made and the read buffer is stored and used to\r\ndetermine what actions should be taken next. There are 2 cases that can be taken\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 38 of 69\n\nControl flow based on response from C2\r\nResponse from\r\nC2\r\nAction Taken\r\nT\r\nCreate a file at \\inf\\netft429.pnf and write a new detonation time to be used by the other\r\nmodules\r\nE\r\nReceive a base64 encoded buffer, attempt to drop it at the following location\r\n%WINDIR%\\Temp\\filer.exe and execute it\r\nGoing down the E path there a Sprintf call is used to generate a file path to drop the decoded base64 file.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 39 of 69\n\n%s%S concatenation and usage\r\nIf you look closely you will see that its using %S in the format string which in some reports has stated to be\r\ninvalid and a bug on the actors part. This is actually incorrect, in the context of windows, this will write a wide\r\ncharacter string rather than an ASCII string. So this call will success and write a file to \\\\Temp\\\\filer and execute it.\r\nShamoon Payload PKCS7 Conclusion\r\nThis sample serves as the communications mechanism between the actor/s and the Shamoon malware. This\r\ncommunications module allows the actors to drop additional payloads, as well as report information back to the\r\nactos. The other purpose it serves is to take a new detonation from the C2 and write it into a hardcoded file path\r\nthat is then used by the main Shamoon module to start wiping the disk.\r\nShamoon Payload PKCS12\r\nThe next payload we are going to cover is the PKCS12 resource.\r\nLoading the file up into PE Studio we can see it has 2 resources being the following\r\nPKCS12 resources\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 40 of 69\n\nREADONE stands out as it has a relatively large size and a high entropy. Loading the file into a hex editor and\r\njudging from the XOR encoding scheme used in the past, its clear it's a encrypted PE file. Looking at the strings\r\nwe can see strings that are most likely going to be passed to _system and a PDB path that shows the name\r\nShamoon just as the initial dropper.\r\nCmd strings found within PKCS12\r\nWe can see the actor searching for files and putting them in f1.inf and f2.inf. Most likely these files will be\r\nexfiltrated for further analysis. Then there are strings for \"sc\" which are used to create a windows service with a\r\nhardcoded path to a drdisk.sys in System32/Drivers.\r\nDigging into the assembly starting at _wmain, the first function we care about it is sub_403720.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 41 of 69\n\nDrop drdisk.sys into Drivers\\\r\nThe beginning of the function will get the windows directory and use the format string in the screenshot to create\r\n`\u003cWINDOWS DIR\u003e\\\\System32\\\\Drivers\\drdisk.sys`. In case there is already a service called drdisk, it'll attempt\r\nto stop and remove it. Once the service is stopped it'll attempt to delete the driver drdisk.sys at the path created\r\nfrom the format string. Then a call to FindResource is made for the ReadOne resource we saw earlier in PE\r\nStudio.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 42 of 69\n\nCreate new service for drdisk.sys\r\nIf the resource was found, it will be passed to the function I've labeled DecryptAndWriteEldosDriverToDisk or\r\nsub_004037E0. Based on the result of that function, it will create and start a service of exit.\r\nWith that information I dumped the resource with Resource Hacker to decrypt the resource when we get to that\r\npoint. Now we will be looking at the decryption routine or sub_004037E0.\r\nPKCS12 internal resource decryption\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 43 of 69\n\nThe arguments to the function are a string which is the filename for to be created file and the resource handle from\r\nthe FindResource call. With those parameters the function will load the resource and lock it so that no concurrent\r\nroutines can modify it. Then get the address of the Wow64DisableWow64FsRedirection to ensure that the to be\r\ndecrypted file is dropped at the same location every time. Scrolling down we see our first XOR loop.\r\nXOR loop for decryption\r\nThis loop will iterate over each byte of the file XORing it with the key[index \u0026 3] and write one byte at a time to\r\nthe newly created decrypted file handle. As soon as the index is greater that 1024  it will continue to the next XOR\r\nloop.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 44 of 69\n\nOnce the initial KB has been written it then will allocate memory for the rest of the file, decrypt the rest of the file\r\nwith the same scheme as the previous loop and then make a single call to WriteFile when it decrypts the entire\r\nbuffer. The encryption key is a hardcoded value and for this sample is:\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 45 of 69\n\nPKCS12 internal resource decryption key\r\nOf course only the first 4 bytes are used as the and operation with the index will keep the ranges from 0-3. Below\r\nis the python script I used to re-implement the decryption.\r\nfiles = {\r\n \r\n 'PKCS12_Eldos': [\"PKCS12112_Resources\\wiper_encrypted.sys_\",\r\n \"PKCS12112_Resources\\wiper_decrypted.sys_\",\r\n [0x15, 0xAF, 0x52, 0xF0, 0xA0, 0xFF, 0xCA, 0x10]\r\n ],\r\n }\r\nimport os\r\ndef decrypt(data, key):\r\n keyLength = len(key)\r\n decoded = \"\"\r\n for i in range(0, len(data)):\r\n decoded += chr(data[i] ^ key[i \u0026 3])\r\n return decoded\r\ndef main():\r\n for rname, file in files.items():\r\n src_resource = file[0]\r\n dst_resource = file[1]\r\n xor_key = file[2]\r\n \r\n print(\"[+] Decrypting resource {}\".format(rname))\r\n print(\"[+] Using Decryption key: {}\\n\".format(xor_key))\r\n \r\n key = bytearray(xor_key)\r\n data = bytearray(open(src_resource, 'rb').read())\r\n \r\n decryptedData = decrypt(data, key)\r\n if len(decryptedData) == 0:\r\n print(\"[!] not able to decrypt resource {}\".format(src_resource))\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 46 of 69\n\nwith open(dst_resource, \"wb+\") as dst:\r\n dst.write(decryptedData)\r\nif __name__ ==\"__main__\":\r\n main()\r\nNow with the decryption function reversed, we can look back at sub_403720. If the decryption was successful it\r\nwill create the new drdisk service and start it.\r\nSo we can now move back to _wmain and we continue looking down the path of the resource successfully being\r\ndecrypted and created as a service.\r\nSystem calls to harvest host files\r\nThe call to CheckIfItsTimeToWipe is used to check if the file \"\\inf\\netfb318.pnf\" exists and if so, its used as a\r\ntrigger to continue with wiping the system. Whether or not that call was successful or not, the following cmd\r\nstatements will be executed.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 47 of 69\n\ndir \"C:\\Documents and Settings\\\" /s /b /a:-D 2\u003enul | findstr -i download 2\u003enul \u003ef1.inf\"\r\ndir \"C:\\Documents and Settings\\\" /s /b /a:-D 2\u003enul | findstr -i document 2\u003enul \u003e\u003ef1.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i download 2\u003enul \u003e\u003ef1.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i document 2\u003enul \u003e\u003ef1.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i picture 2\u003enul \u003e\u003ef1.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i video 2\u003enul \u003e\u003ef1.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i music 2\u003enul \u003e\u003ef1.inf\"\r\ndir \"C:\\Documents and Settings\\\" /s /b /a:-D 2\u003enul  | findstr -i desktop 2\u003enul \u003ef2.inf\"\r\ndir C:\\Users\\ /s /b /a:-D 2\u003enul  | findstr -i desktop 2\u003enul \u003e\u003ef2.inf\"\r\ndir C:\\Windows\\System32\\Drivers /s /b /a:-D 2\u003enul \u003e\u003ef2.inf\"\r\ndir C:\\Windows\\System32\\Config /s /b /a:-D 2\u003enul | findstr -v -i systemprofile 2\u003enul \u003e\u003ef2.inf\"\r\ndir f1.inf /s /b 2\u003enul \u003e\u003ef1.inf\"\r\ndir f2.inf /s /b 2\u003enul \u003e\u003ef1.inf\"\r\nThese commands will grab filenames in those directories with various recursion depths.\r\nOnce those commands have been executed, there are 2 major if statements that each call the same function with a\r\nargument of the f1.inf or f2.inf. This function is used to check if the file exists and check permissions as well. If\r\nthe file exists and is able to be read, then each file path contained within f1.inf and f2.inf  will be copied to a\r\nbuffer and corrupted by a following routine.\r\nf1.inf reference\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 48 of 69\n\nf2.inf reference\r\nImmediately after the payload has successfully read and processed f2.inf, it will load a hardcoded buffer into\r\nmemory.\r\nLoad picture buffer into memory\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 49 of 69\n\nThis will create a empty buffer of length 196608 bytes and copy the a hardcoded buffer I renamed DumpedPicture\r\nwith a length of 1024 into the new buffer.\r\nJPG header\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 50 of 69\n\nFor those that don't know the file header for a JPEG JFIF format is FF D8 FF E0 00 10 4A 46 49 46 00 01.\r\nOpening the extracted 1024 bytes of the JPEG we can see the following.\r\nScreenshot of dumped picture buffer\r\nSince its only a partial image we can find the original with a reverse image search.\r\nReference image from Wikipedia\r\nAlthough the entire image isn't held within the binary, it is interesting to see such a decision made by this group.\r\nIf you have taken a look yourself at _wmain you will see that its quite large and contains a lot of functionality that\r\nreally should be separated out. For that reason I decided to create a diagram of the relevant actions that occur\r\nwithin this payload.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 51 of 69\n\n_wmain function summary\r\nThe next piece we care about is the system information that needs to be acquired for the payload to successfully\r\ncorrupt drives. This payload will query the registry with the following keys, getting the disk layout for the\r\nmachine its on. The examples below are from my personal VM, but with a host that contains multiple drives these\r\nvalues would look different.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 52 of 69\n\nRegistry Key Size Value\r\nSYSTEM\\\\CurrentControlSet\\\\Control -\r\nFirmwareBootDevice\r\nREG_SZ multi(0)disk(0)rdisk(0)partition(2)\r\nSYSTEM\\\\CurrentControlSet\\\\Control -\r\nSystemBootDevice\r\nREG_SZ multi(0)disk(0)rdisk(0)partition(4)\r\nWith this information the payload will iterate over the partitions and rdisk values and add them to an array so for\r\nmy system that would result in the following array.\r\n\\\\Device\\\\Harddisk0\r\n\\\\Device\\\\Harddisk1\r\n\\\\Device\\\\Harddisk2\r\nThen once those devices are appended in an array we have a call to a function I have renamed\r\nSetSystemTimeChangeNameOfPartitionAndGetHandleToPartition or sub_4033F0.\r\nPartition iteration\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 53 of 69\n\nThe function is pretty short as its basically just a wrapper for the code that actually gets the wiper handle.\r\nHardcoded license key and system time change\r\nInterestingly, it will set the system time before it returns a handle to a device. It sets the year and month to august\r\n2012. It will pick a random value for the day and do a modulus 20 on it and add 1. So the day will be some value\r\nbetween 1 and 20. This information doesn't seem to hold much value but there is a call to\r\nChangeNameOfPartitionAndGetHandleToPartition or sub_409660. This function takes 3 arguments, a string,\r\nprivilege levels that will be passed to CreateFile and another string.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 54 of 69\n\nHANDLE ChangeNameOfPartitionAndGetHandleToPartition(char *str1, DWORD dwDesiredAccess, char *str2)\r\nWithout going into detail for this function as its relatively straight forward, the first string is a filepath that is\r\nappended to \"\\\\?\\ElRawDisk\". The only way this function executes properly is if that value starts with the\r\ncharacters \"\\\\\". The second argument is an access level and for this call is a generic read \u0026 write. The 3rd string\r\npassed is a license key that is required for the wiper to run. After the \"\\\\\"  is appended to the path, it will append a\r\n\"#\" to the filename and then the license key that is the third argument. As an example if you have the following\r\ninput string\r\n\\\\device\\\\harddisk1\\\\partiton0\r\nwe would get a file handle back from\r\n\\\\device\\\\harddisk\\\\partiton0#8F71FF7E2831A...\r\nThe driver requires a license key to run if you look at the implementation of it, and it will read from this filepath\r\nto get a valid key. For one to acquire a license key, they must register an account with Eldos. Understandably so,\r\nthe company does not seem to offer the product anymore nor the free trial that was used in this attack. If one were\r\nto have access to the registration information that was used, it could yield potentially interesting information about\r\nthe actor.\r\nOnce this function returns the handle to the specific partition with the license key appended to it we are back to\r\nlooking at _wmain.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 55 of 69\n\nThread creation for corrupting partitions with JPG buffer\r\nThe block before this gets the handle to the partition, which is held in ESI. It will write the picture buffer to the\r\nfile and create a thread with the function sub_402F40. This function is arguably the most delicate code of the\r\nsample as it deals with overwriting portions of the disk partitions that we had seen earlier.\r\nThread function pseudo C++\r\nGenerally I am not a fan of relying on the decompiled code as a lot can be missed but considering all the nested\r\nloops and byte manipulation I felt that this was a better way to display the control flow.\r\nAs you can see this function is pretty complicated but I've done my best to rename the variables to informative\r\nnames. The most important piece of this pseudo C is the section from line 76 to 86. These 7 lines are responsible\r\nfor writing the picture buffer to the path passed within this function. First it makes 2 checks to compare the path\r\npassed into the function with the DeviceString and DeviceHardDiskString. Then it will get a file handle, where the\r\nfilename for that handle has the serial key for the disk wiper appended to it after a #, and if that is successful, then\r\nthe handle is passed to SetFilePointerAndWritePicture which will write the picture buffer over spans of memory\r\nfor the handle being passed in.\r\nSo its clear that the purpose of this function is to take in a path, and start writing the image buffer to file at that\r\npath. With that I renamed Sub_402F40 to WriteImageBufToPathThread. Now that we have looked at the thread\r\nfunction, we have analyzed all the pieces required for the loop we were just looking at in _wmain\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 56 of 69\n\nComplete partition corruption loop\r\nThis loop iterates over all of the partitions gathered from the registry and will write the picture buffer to random\r\nsections in each of the partitions. So while the functions we looked at were complex, looking at the high level\r\npicture really sheds a light as to what the sample attempts to do.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 57 of 69\n\nNow at the final section of _wmain we can see a call to Sub_4034B0 or as I have renamed it\r\nDropElDosDiskWiperAndRestartMachine.\r\nCorrupt partition0 and restart machine call\r\nOnce we enter this function ,we can see a call to CorruptPartition0AndRestartMachine with the argument\r\n\\\\Device\\\\Harddisk0\\\\Partition0. If you were to look at the threads that were just generated in a debugger you can\r\nsee that it won't start a thread for corrupting Harddisk0\\\\Partition0, this is due to the fact that partition0 is a special\r\ncase and points to the entire contents of Harddisk0. Where Harddisk0 is generally where the OS is installed and\r\nhas to be corrupted last.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 58 of 69\n\nOnce the handle to Partition0 is acquired it writes the the picture buffer to the beginning of the partition and\r\npromptly closes the handle to it continuing onward. Soon after the function will acquire a file handle for the string\r\nglobal variable dword_428D2C. Generally the function used to get a file handle is OpenFile but CreateFile can\r\nalso be used to get the handle to the file passed.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 59 of 69\n\nIf the initial CreateFile call fails, it will append a string to dword_428D2C and attempt to get the file handle\r\nagain. If the handle is valid, we see a call again to SetFilePointerAndWritePicture with the newly acquired file\r\nhandle.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 60 of 69\n\nOnce the picture buffer is written to the file handle the function checks the length of the DeviceHardDisk string.\r\nWhile string length is its own  function in C wcslen, generally that function is inlined to others as its relatively\r\nsmall and removes the need to setup the function call for wcslen.\r\nThe snippet above calculates string length and checks whether the length of that DeviceHardDiskString is greater\r\nthan 1. Assuming that the string is valid and contains the information expected, then a conditional is evaluated to\r\ncheck whether DeviceHardDiskString and DeviceStringCopy are the same value.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 61 of 69\n\nJust as wcslen is inlined when the program is compiled so is wcscmp. This section loads the two strings and\r\nchecks whether they are the same values. If they are the same values, then we get into the critical portion of this\r\nfunction.\r\nSo at this point, if the length of DeviceHardDiskString is greater than 1, and it is the same as DeviceStringCopy,\r\nthen we get into the assembly blocks in the screenshot above. The filepath being passed is the\r\nDeviceHardDiskString. The file at this path will have the EldoS key license appended to the filename after a \"#\"\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 62 of 69\n\nand the handle will be returned. The file handle that is returned is then passed to SetFilePointerAndWritePicture\r\nwhere the raw hard disk device will have the picture buffer written to it at the beginning of the raw device.\r\nGet handle to partition0 \r\nSo the previous call we saw was writing the picture buffer to DeviceHardDiskString, whereas for this assembly\r\nsnippet it works with DeviceString. Once it has a valid handle to the device, it will write the picture buffer to the\r\ndevice pointed at DeviceString. Its interesting to note that instead of writing over the entirety of the disk, the\r\nactors decided to just write over the first 1024 bytes. Its much quicker than writing over the device and is still\r\nnearly impossible to repair.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 63 of 69\n\nWrite picture buffer to partition0 and send control code to device\r\nWith the valid handle, the picture buffer is written to the device. If the handle is still valid, it will pass the handle\r\nto DeviceIoControl. DeviceIoControl as described by MS does the following\r\nSends a control code directly to a specified device driver, causing the corresponding device to perform\r\nthe corresponding operation.\r\nWith some quick googling, the control code that is sent is used to gather information about the drive. A check is\r\nthen done to make sure that the result is valid and if it has a length of 144 or more.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 64 of 69\n\nReboot machine corrupting it entirely\r\nIf that check is successful, there is a final call to SetFilePointerAndWritePictureBuffer. This call takes in the\r\nhandle of the same drive that was passed to DeviceIoControl. So in this case that would be the\r\nHarddisk0\\\\Partition0. This makes sense as it's the most critical portion of the system due to it containing the\r\noperating system and boot information. These effects won't have any effect as a lot of the required pieces for\r\nwindows to run properly are held in memory while these overwrites are made to the hard disk. So this will require\r\na full reboot for the corruption to take effect. As expected that call is made directly after the overwrite with a\r\n_system call to\r\nshutdown -r -f -t 2\r\nFor a breakdown of the command, the -r signifies  the machine to restart, the -f forces applications to close\r\nwithout warning users, and the -t sets the time-out period to 2 seconds before the restart starts.\r\nAt this point Shamoon has gone through its entire infection chain and has successfully corrupted all the partitions\r\nand restarted the computer leaving the machine inoperable.\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 65 of 69\n\nShamoon Payload PKCS12 Conclusion\r\nThis is the final payload in Shamoon's arsenal and once completed renders the machine inoperable. In conjunction\r\nwith the communications module, Shamoon offers a powerful toolkit that proved by time allows the actors to\r\nreuse and adapt the codebase.\r\nShamoon Payload x509 Analysis\r\nNow if you've been paying attention you might have realized that I haven't touched on the x509 resource. This is\r\ndue to the fact that the x509 resource is a product of the same exact code, just compiled for a 64 bit architecture.\r\nSo the 64 bit version only has 2 resources. 1 being the communcations module and another being the actual wiper\r\nthat contains the EldoS driver and corruption mechanism. Pictures of PE studio output can be found below but I\r\nfeel that it is out of scope to dive deep into the 64 bit module as it shares almost exactly the same behavior as the\r\n32 bit client.\r\nConclusion\r\nI hope this overview was able to help teach some about the history of the first Shamoon campaign the world has\r\nseen. This has been a work in progress for almost 6 months now and I've met a ton of great people. If there are any\r\nquestions or mistakes feel free to reach out. I am a human as well and therefore make tons of mistakes just like the\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 66 of 69\n\nrest of the world. Any feedback about the content, length of post, or format of the post would also be greatly\r\nappreciated. I think going forward I will try to keep them a tad shorter and more frequent. If there is interest I will\r\ncontinue going over the next shamoon campaigns as there are signifcant changes to how strings are obfsucated,\r\nresources encrypted, and dropping techniques. Below are a couple of high level visuals and information that might\r\nprove useful to some.\r\nShamoon 2012 Killchain\r\nIOCs\r\nIOC Value Rationale\r\n4F02A9FCD2DEB3936EDE8FF009BD08662BDB1F365C0F4A78B3757A98C2F40400\r\nKnown 2012\r\nsample\r\n61E8F2AF61F15288F2364939A30231B8915CDC57717179441468690AC32CED54\r\nKnown 2012\r\nsample\r\nA37B8D77FDBD740D7D214F88521ADEC17C0D30171EC0DEE1372CB8908390C093\r\nKnown 2012\r\nsample\r\nF9D94C5DE86AA170384F1E2E71D95EC373536899CB7985633D3ECFDB67AF0F72\r\nKnown 2012\r\nsample\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 67 of 69\n\nhttp://10.1.252.19/ajax_modal/modal/data.asp?mydata=\u0026uid=\u0026state=CurrentMilliseconds\r\nURL scheme\r\nand\r\nhardcoded IP\r\nfor internal\r\nC2\r\nhttp://home/ajax_modal/modal/data.asp?mydata=\u0026uid=\u0026state=CurrentMilliseconds\r\nURL scheme\r\nand\r\nhardcoded IP\r\nfor internal\r\nC2\r\n%windir%\\inf\\netft429.pnf\r\nHardcoded\r\nfile path for\r\nnew\r\ndetonation\r\ndate\r\n%windir%\\inf\\netfb318.pnf\r\nHardcoded\r\nfile path for\r\nwiping\r\ncompletion\r\nstatus\r\n%system32%\\drivers\\drdisk.sys\r\nHardcoded\r\nfile path for\r\nthe EldoS\r\nwiping driver\r\nto be written\r\nto\r\nc:\\windows\\temp\\out17626867.txt\r\nPath\r\ncontained\r\nwithin the\r\nShamoon\r\ndropper\r\n\\\\System32\\\\cmd.exe /c \\\"ping -n 30 127.0.0.1 \u003enul \u0026\u0026 sc config TrkSvr binpath=\r\nsystem32\\\\trksrv.exe \u0026\u0026 ping -n 10 127.0.0.1 \u003enul \u0026\u0026 sc start TrkSvr \\\"\r\nHardcoded\r\ncommand\r\nused by\r\nShamoon to\r\nstart a\r\nservice\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 68 of 69\n\ntrksrv.exe\r\nx509\r\ndropped\r\nfilename\r\n%WINDIR%\\Temp\\filer.exe\r\nFile received\r\nand executed\r\nfrom the\r\ninternal C2\r\nf2.inf\r\nData\r\ngathered\r\nfrom\r\nPKCS12\r\nresource\r\nf1.inf\r\nData\r\ngathered\r\nfrom\r\nPKCS12\r\nresource\r\nSource: https://malwareindepth.com/shamoon-2012/\r\nhttps://malwareindepth.com/shamoon-2012/\r\nPage 69 of 69\n\nIf the handle was manipulation and successfully closed, create a process the above code for the cmd command block will be above: executed. As we can see it will do some string\n\\\\System32\\\\cmd.exe /c \"ping-n 30 127.0.0.1 \u003enul \u0026\u0026 sc config TrkSvr binpath= system32\\\\trksrv.exe \u0026\u0026 ping-n\n   Page 27 of 69    \n\n   https://malwareindepth.com/shamoon-2012/    \nIf the initial CreateFile call fails, it will append a string to dword_428D2C and attempt to get the file handle\nagain. If the handle is valid, we see a call again to SetFilePointerAndWritePicture  with the newly acquired file\nhandle.       \n    Page 60 of 69",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://malwareindepth.com/shamoon-2012/"
	],
	"report_names": [
		"shamoon-2012"
	],
	"threat_actors": [
		{
			"id": "42a6a29d-6b98-4fd6-a742-a45a0306c7b0",
			"created_at": "2022-10-25T15:50:23.710403Z",
			"updated_at": "2026-04-10T02:00:05.281246Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"Whisper Spider"
			],
			"source_name": "MITRE:Silence",
			"tools": [
				"Winexe",
				"SDelete"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "eb5915d6-49a0-464d-9e4e-e1e2d3d31bc7",
			"created_at": "2025-03-29T02:05:20.764715Z",
			"updated_at": "2026-04-10T02:00:03.851829Z",
			"deleted_at": null,
			"main_name": "GOLD WYMAN",
			"aliases": [
				"Silence "
			],
			"source_name": "Secureworks:GOLD WYMAN",
			"tools": [
				"Silence"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "88e53203-891a-46f8-9ced-81d874a271c4",
			"created_at": "2022-10-25T16:07:24.191982Z",
			"updated_at": "2026-04-10T02:00:04.895327Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"ATK 86",
				"Contract Crew",
				"G0091",
				"TAG-CR8",
				"TEMP.TruthTeller",
				"Whisper Spider"
			],
			"source_name": "ETDA:Silence",
			"tools": [
				"EDA",
				"EmpireDNSAgent",
				"Farse",
				"Ivoke",
				"Kikothac",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Meterpreter",
				"ProxyBot",
				"ReconModule",
				"Silence.Downloader",
				"TiniMet",
				"TinyMet",
				"TrueBot",
				"xfs-disp.exe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434271,
	"ts_updated_at": 1775826679,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/505326c2819ae627a88306ef2932cabecff36cb7.pdf",
		"text": "https://archive.orkl.eu/505326c2819ae627a88306ef2932cabecff36cb7.txt",
		"img": "https://archive.orkl.eu/505326c2819ae627a88306ef2932cabecff36cb7.jpg"
	}
}