{
	"id": "02bacbfa-72f0-499b-badb-760ced1925bc",
	"created_at": "2026-04-06T00:14:46.977698Z",
	"updated_at": "2026-04-10T03:22:01.318048Z",
	"deleted_at": null,
	"sha1_hash": "72b828343b11cc110ace7d60de81e41e6867b542",
	"title": "Slicing and Dicing CVE-2018-5002 Payloads: New CHAINSHOT Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1954449,
	"plain_text": "Slicing and Dicing CVE-2018-5002 Payloads: New CHAINSHOT\r\nMalware\r\nBy Dominik Reichel, Esmid Idrizovic\r\nPublished: 2018-09-06 · Archived: 2026-04-05 16:07:35 UTC\r\nThis story begins with one of our blog authors, who, following the discovery of a new Adobe Flash 0-day, found several\r\ndocuments using the same exploit that were used in targeted attacks. We were also able to collect network captures including\r\nthe encrypted malware payload. Armed with these initial weaponized documents, we uncovered additional attacker network\r\ninfrastructure, were able to crack the 512-bit RSA keys, and decrypt the exploit and malware payloads. We have dubbed the\r\nmalware ‘CHAINSHOT’, because it is a targeted attack with several stages and every stage depends on the input of the\r\nprevious one.\r\nThis blog describes the process we took to analyze the malware, how we managed to decrypt the payloads, and then how we\r\nfound parts of a new attack framework. We also found additional network infrastructure which indicates similar attacks were\r\nconducted against a wide range of targets with disparate interests. This attack chain is designed in a way that makes it very\r\ndifficult to execute a single part on its own, be it the exploit or payload. To make our analysis easier, we reproduced the\r\nserver-side infrastructure, by doing so we were able to conduct dynamic analysis and get a better understanding how the\r\nexploit and payload work together.\r\nThis serves as a follow-up of Icebrg’s article which describes the initial findings.\r\nCracking a RSA Key\r\nFirst, let’s recap how the overall attack chain works to understand at which point the RSA key is needed. The malicious\r\nMicrosoft Excel document contains a tiny Shockwave Flash ActiveX object with the following properties:\r\nFigure 1. Malicious Shockwave Flash ActiveX object properties\r\nThe “Movie” property contains a URL to a Flash application which is downloaded in cleartext and then executed. The\r\n“FlashVars” property contains a long string with 4 URLs which are passed to the downloaded Flash application. The Flash\r\napplication is an obfuscated downloader which creates a random 512-bit RSA key pair in memory of the process. While the\r\nprivate key remains only in memory, the public keys’ modulus n is sent to the attacker’s server. On the server side, the\r\nmodulus is used together with the hardcoded exponent e 0x10001 to encrypt the 128-bit AES key which was used previously\r\nto encrypt the exploit and shellcode payload. The encrypted exploit or payload is sent back to the downloader which uses the\r\nin-memory private key to decrypt the AES key and the exploit or payload.\r\nAs the modulus is sent to the server of the attacker, it’s also in our network capture. Together with the hardcoded exponent\r\nwe have the public key which we can use to get the private key. Keep in mind that this was only possible because the\r\nattacker chose a key length of 512-bit which is known to be insecure. In order to do so, we have to factorize the modulus n\r\ninto its two prime numbers p and q. Luckily this problem has already been solved previously, by an awesome public project\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 1 of 11\n\n‘Factoring as a Service‘. The project uses Amazon EC2’s high computing power and can factorize large integers in just a\r\nmatter of hours.\r\nFollowing this logic, let’s take the following modulus of the public key sent to the attacker’s server to get the shellcode\r\npayload.\r\nFigure 2. HTTP POST request for the encrypted shellcode payload with the modulus n in hexadecimal\r\nAfter removing the first 2 bytes which are used in this case to retrieve the 32-bit version of the shellcode payload, we have\r\nthe following modulus in hexadecimal:\r\n0x7df305d5bcc659e5497e482bd0b507c44808deee8525f24b2712dc4a29f5c44e1e08c889a64521bbc67136ced11ace55b9bc2c1c7c96630aa515896b2\r\nAfter we have factorized the integer, we get the following two prime numbers in decimal:\r\nP\r\n58243340170108004196473690380684093596548916771782361843168584750033311384553\r\nQ\r\n113257592704268871468251608331599268987586668983037892662393533567233998824693\r\nWith the help of p and q we can calculate the private key. We used a small public tool to create it in Privacy Enhanced Mail\r\n(PEM) format:\r\n-----BEGIN RSA PRIVATE KEY-----\r\nMIIBOgIBAAJAffMF1bzGWeVJfkgr0LUHxEgI3u6FJfJLJxLcSin1xE4eCMiJpkUh\r\nu8ZxNs7RGs5VubwsHHyWYwqlFYlrL3NB/QIDAQABAkBog3SxE1AJItIkn2D0dHR4\r\ndUofLBCDF5czWlxAkqcleG6im1BptrNWdJyC5102H/bMA9rhgQEDHx42hfyQiyTh\r\nAiEA+mWGmrUOSLL3TXGrPCJcrTsR3m5XHzPrh9vPinSNpPUCIQCAxI/z9Jf10ufN\r\nPLE2JeDnGRULDPn9oCAqwsU0DWxD6QIhAPdiyRseWI9w6a5E6IXP+TpZSu00nLTC\r\nSih+/kxvnOXlAiBZMc7VGVQ5f0H5tFS8QTisW39sDC0ONeCSPiADkliwIQIhAMDu\r\n3Dkj2yt7zz04/H7KUV9WH+rdrhUmoGhA5UL2PzfP\r\n-----END RSA PRIVATE KEY-----\r\nWith the help of the private key we could now decrypt the 128-bit AES key. We used OpenSSL to do this:\r\nopenssl rsautl -decrypt -in enc_aes.bin -out dec_aes.bin -inkey private_key.pem\r\nThe encrypted AES key is extracted from the encrypted binary blob as described by Icebrg. It's at offset 0x4 and has the\r\nlength of 0x40 bytes. Encrypted AES key:\r\n0x5BC64C5DC7EC96750CCB466935ED2183FE90212CB1BF6305F0B79B4B9D9261A4AC8A3E06F3E07D4037A40F4E221BB12E05B4DE268\r\nDecrypted AES key:\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 2 of 11\n\n0xE4DF3353FD6D213E7400EEDA8B164FC0\r\nNow that we have the decrypted AES key, we can decrypt the actual payload. The Flash downloader uses a custom\r\ninitialization vector (IV) for the AES algorithm which can be found at offset 0x44 in the encrypted blob and is 16 bytes long:\r\n0xCC6FC77B877584121AEBCBFD4C23B67C\r\nFor the final decryption we used OpenSSL again:\r\nopenssl enc -nosalt -aes-128-cbc -d -in payload.bin -out decrypted_payload -K\r\nE4DF3353FD6D213E7400EEDA8B164FC0 -iv CC6FC77B877584121AEBCBFD4C23B67C\r\nThe decrypted shellcode payload is additionally compressed with zlib which can be seen by looking at the first 2 magic\r\nbytes 0x789C. We decompressed it with Offzip. Finally, we have the decrypted shellcode payload. The same procedure can\r\nbe used to decrypt the Flash exploit which isn’t additionally zlib compressed.\r\nServer-side Reproduction\r\nAfter we had the decrypted Flash exploit and shellcode payloads, we started to do a static analysis which turned out to be a\r\nquite tedious task. This is due to the obfuscation in the exploit and the complexity of shellcode payload which contains its\r\nown two PE payloads. Next, we attempted to do a dynamic analysis which quickly turned out to be impossible, because\r\nevery stage relies on data passed from the previous. The shellcode payload does not execute properly without the data\r\npassed to it from the exploit. The exploit does not execute on its own without the variables passed from the downloader and\r\nso on.\r\nDue to the difficulties of analyzing the code statically, we decided to reproduce a simplified version of the server-side PHP\r\nscripts in order to make a full dynamic analysis possible. As we had the decrypted exploit, shellcode payload and the PCAP,\r\nwe had all the information required to do so. Specifically, we created the following setup:\r\nLocal Apache server with XAMPP, with the domain used in the attack configured to resolve to localhost\r\nA directory structure which mirrored that on the attackers’ servers (as specified in the PCAPs)\r\nSetting of custom HTTP headers as per the PCAPs’ responses.\r\nAll of the requested files are sent back gzip encoded, otherwise the attack chain doesn’t work. We have uploaded the PHP\r\nscripts to our GitHub account, so you can also play with the different stages and see how it works.\r\nAdditional Details of the Flash Exploit\r\nWhile the exploit has been already described, we want to give some additional details surrounding it that we found during\r\nour analysis. In particular, we were interested in the part which transfers execution to the shellcode payload. While most\r\nparts of the decompiled ActionScript exploit code are obfuscated, luckily some method names were left in cleartext.\r\nBecause the decrypted shellcode payload doesn’t run on its own when transformed into an executable, we have to figure out\r\nhow execution works and if one or more parameters are passed. Therefore, the most interesting method for us is\r\n“executeShellcodeWithCfg32” which indicates we can find the passed data in it. It creates a small shellcode template and\r\nfills some placeholder values at runtime. The disassembled template looks as follows:\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 3 of 11\n\nFigure 3. Shellcode template with placeholders (red) in the Flash exploit to pass execution to the shellcode payload\r\nWhile the final prepared shellcode looks as follows:\r\nFigure 4. Runtime version of the shellcode template with filled placeholders\r\nLet’s take a look at what values are set to the placeholders (0x11111111, 0x22222222, …). The address 0xA543000 in\r\nFigure 4 is the entrypoint of the decrypted shellcode payload which has a small NOP sled in front of the actual code:\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 4 of 11\n\nFigure 5. Entrypoint of the shellcode template in memory\r\nThe address 0x771A1239 in Figure 4 is in the middle of the function NtPrivilegedServiceAuditAlarm in ntdll.dll:\r\nFigure 6. Windows API function NtPrivilegedServiceAuditAlarm\r\nHowever, we can also see in Figure 4 that before calling the API function via “call edx”, the value 0x4D is moved into eax\r\nwhich is the ID of the API function NtProtectVirtualMemory. By doing so, the function NtProtectVirtualMemory is executed\r\nwithout calling it directly. This trick is likely used to bypass AVs/sandboxes/anti-exploit software which hook\r\nNtProtectVirtualMemory and the attacker probably chose NtPrivilegedServiceAuditAlarm as a trampoline as it’s unlikely to\r\nbe ever be monitored.\r\nThe data at this address 0x9DD200C in Figure 4 looks like a structure into which the last NTSTATUS return value of\r\nNtProtectVirtualMemory is copied. The address of this structure seems to be passed to the shellcode payload in ebx,\r\nhowever we haven’t figured out what’s its purpose is. Finally, shellcode payload is executed via “call edi”\r\nTo sum up, the memory access rights of the shellcode payload are changed in 0x1000 byte blocks to RWE via\r\nNtProtectVirtualMemory. The last NTSTATUS code is saved into memory pointed to by ebx and the shellcode payload is\r\nexecuted.\r\nAnother interesting aspect of the exploit code is that it sends status messages when something goes wrong at every stage of\r\nthe exploitation. These status messages are very similar to those send by the initial Flash downloader and are sent to the\r\nattacker’s server via fake PNG files (see Icebrg). They also contain the “/stab/” directory in the URL and the actual message\r\nis also sent encoded via custom digit combinations. However, the status message of the exploitation code contains additional\r\ninformation in the form of abbreviations of the appropriate stage. By looking at those messages, we can get a better\r\nunderstanding how the exploit works. The following messages are possible:\r\nStatus message\r\ncode\r\n Description\r\n2-0-9-vp Short for VirtualProtect\r\n2-0-9-g3 Short for something like gadget3 (ROP gadget) cause a byte array is created\r\n0x5A5941584159C3 which disassembles to:\r\npop edx\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 5 of 11\n\npop ecx\r\ninc ecx\r\npop eax\r\ninc ecx\r\npop ecx\r\nretn\r\n2-0-9-\r\nRtlAllocateHeap\r\nSelf-explaining\r\n2-0-9-DeleteDC Self-explaining\r\n2-0-9-GetDC Self-explaining\r\n2-0-9-sprintf Self-explaining\r\n2-0-9-VP Short for VirtualProtect\r\n2-0-9-RU Short for RtlUnwind\r\n2-0-9-NVP Short for NtProtectVirtualMemory\r\n2-0-9-NPSAA Short for NtPrivilegedServiceAuditAlarm\r\n2-0-9-G Probably short for Gadget\r\n2-0-9-SRP\r\nShort for something like StackReturnProcedure because two-byte arrays 0x81C4D8000000C3\r\nand 0x81C4D0000000C3 are created which disassemble to:\r\nadd esp, 0D8h\r\nretn\r\n- and -\r\nadd esp, 0D0h\r\nretn\r\n2-0-9-PAX\r\nShort for something like PopEAX as a byte array 0x58C3 is created before which disassembles\r\nto:\r\npop eax\r\nretn\r\nTable 1. Status messages used in the Flash exploit code\r\nThe Shellcode Payload\r\nAfter the exploit successfully gains RWE permissions, execution is passed to the shellcode payload. The shellcode loads an\r\nembedded DLL internally named FirstStageDropper.dll, which we call CHAINSHOT, into memory and runs it by calling its\r\nexport function “__xjwz97”. The DLL contains two resources, the first is x64 DLL internally named\r\nSecondStageDropper.dll and the second is a x64 kernelmode shellcode.\r\nFirstStageDropper.dll is responsible for injecting SecondStageDropper.dll into another process to execute it. While the\r\nshellcode payload only contains code to search for and bypass EMET, FirstStageDropper.dll also contains code for\r\nKaspersky and Bitdefender. In case of EMET, it searches the loaded modules for emet.dll and emet64.dll, for Kaspersky it\r\nsearches for klsihk.dll, and for Bitdefender it searches for avcuf32.dll and avcuf64.dll. It also collects and sends encrypted\r\nuser system and process information data together with a unique hardcoded ID to the attacker's server. The data is sent to\r\nURLs that contain “/home/” and “/log/” directories and for encryption it uses the Rijndael algorithm. As the attacker server\r\ndid not respond at the time of our analysis, we guess a command is sent back to execute the SecondStageDropper.dll.\r\nWhile the samples we obtained inject SecondStageDropper.dll in usermode via thread injection, the x64 shellcode seems to\r\nhave an option to inject it from kernelmode. However, we haven’t figured out what the exact purpose of it is, since it’s never\r\nexecuted; it also searches for an additional resource which wasn’t present in the samples we analyzed.\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 6 of 11\n\nThe kernelmode shellcode contains parts of Blackbone, an open source library for Windows memory hacking. The following\r\nfunctions are taken from its code:\r\nFindOrMapModule\r\nBBQueueUserApc\r\nBBCallRoutine\r\nBBExecuteInNewThread\r\nIt also contains code from TitanHide, using identical code to lookup SSDT in Win7 and Win10 as described by the author.\r\nSecondStageDropper.dll acts as a downloader for the final payload. It collects various information from the victim system,\r\nencrypts it, and sends it to the attacker’s server. It also scans for the following processes and skips execution if found:\r\nProcess name Security Solution\r\nadawareservice.exe\r\nadawareservicetray.exe\r\nAdaware\r\nmbam.exe Malwarebytes\r\nbdagent.exe\r\nbdwtxag.exe\r\nseccecenter.exe (contains a typo, should be seccenter.exe)\r\nvsserv.exe\r\nupdatesrv.exe\r\nodscanui.exe\r\nodsw.exe\r\nBitdefender\r\nefainst.exe\r\nelaminst.exe\r\ninstca.exe\r\nmcui32.exe\r\nnavw32.exe\r\nncolow.exe\r\nnsbu.exe\r\nsrtsp_ca.exe\r\nsymdgnhc.exe\r\nsymerr.exe\r\ntuih.exe\r\nwfpunins.exe\r\nwscstub.exe\r\nSymantec / Norton\r\navp.exe Kaspersky\r\nHitmanPro.exe Sophos / HitmanPro\r\nabcde.exe ?\r\nTable 2. Process name lookup list\r\nUnfortunately, at the time of the analysis we were unable to obtain additional files, so we were unable to figure out what the\r\nfinal stage is. However, CHAINSHOT contacts the following domains via HTTPS to get the final payload:\r\ncontact.planturidea[.]net\r\ndl.nmcyclingexperience[.]com\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 7 of 11\n\ntools.conductorstech[.]com\r\nIn both samples we analyzed the final domains used were the same. We have obtained two x86 versions of the shellcode\r\npayload with its embedded PE files and the kernelmode shellcode. While the shellcode payload, FirstStageDropper.dll and\r\nkernel shellcode do not differ, the SecondStageDropper.dll contains a couple of different strings. The following strings are\r\ndifferent, possibly indicating they are changed for every victim, with the final payload directory being an MD5\r\nrepresentation of the “project name” or something similar.\r\n  Sample 1 Sample 2\r\nUser-agent\r\nMozilla/5.0 (Windows NT 6.4; WOW64)\r\nAppleWebKit/537.36 (KHTML, like Gecko)\r\nChrome/36.0.1985.143 Safari/537.36 Edge/12.0\r\nMozilla/5.0 (Windows NT 6.3; Win64; x64;\r\nrv:10.0) Gecko/20100101 Firefox/10.0\r\nQueried final\r\npayload\r\ndirectories\r\n/0cd173cf1caa2aa03a52b80d7521cc75e\r\n/1cd173cf1caa2aa03a52b80d7521cc75e\r\n/0fa0a5fc0d2e28cc3786e5d6eb273f1fa\r\n/1fa0a5fc0d2e28cc3786e5d6eb273f1fa\r\nUnique string used\r\nin network\r\ncommunication\r\n148a028d-57c6-4094-b07d-720df09246dd 3784113f-b04e-4c1e-b3be-6b0a22464921\r\nTable 3. String differences in SecondStageDropper.dll\r\nThe shellcode payload and PE files partly contain the same code indicating a framework was used to create them. For\r\nexample, both the shellcode and CHAINSHOT itself make extensive use of the same exception handling with custom error\r\ncodes. They also both use the same code to scan for and bypass EMET. Furthermore, other parts such as the OS version\r\nrecognition are identical in all samples and the PE files’ compilation timestamps are zeroed out. Another interesting fact is\r\nthat FirstStageDropper.dll also sends status messages back to the attacker starting with digit “9”. For example, the following\r\nnetwork capture from our local tests show a successful network communication up to the point where the attacker\r\npresumably sends back the command to execute SecondStageDropper.dll:\r\nFigure 7. Network capture of a successful attack reproduced locally in a VM\r\nAdditional Infrastructure\r\nOne of the domains reported by IceBrg had an associated SSL certificate which was documented in their write up. By\r\nsearching for other IP addresses using the same certificate we were able to find a large number of associated domains that\r\nwere likely also used in similar attack campaigns. Just like the domain contacted within the Excel documents analyzed, the\r\nadditional domain names are created in a similar way using similar hosting providers and registrars and used names which\r\nare very similar to official websites to avoid suspicion. The list of domains can be found in the IOC section.\r\nConclusion\r\nWe uncovered part of a new toolkit which was used as a downloader alongside Adobe Flash exploit CVE-2018-5002 to\r\ntarget victims in the Middle East. This was possible because the attacker made a mistake in using insecure 512-bit RSA\r\nencryption. The malware sends user information encrypted to the attacker server and attempts to download a final stage\r\nimplant. It was allegedly developed with the help of an unknown framework and makes extensive use of custom error\r\nhandling. Because the attacker made another mistake in using the same SSL certificate for similar attacks, we were able to\r\nuncover additional infrastructure indicating a larger campaign.\r\nPalo Alto Networks customers are protected from this threat in the following ways:\r\nWildFire detects all malicious Excel documents, the Flash downloader and exploit and all CHAINSHOT samples\r\nwith malicious verdicts\r\nAutoFocus customers can track the samples with the CVE-2018-5002 exploit and CHAINSHOT malware tags\r\nTraps detects and blocks the malicious Excel documents with the Flash exploit\r\nFinally, we’d like to thank Tom Lancaster for his assistance in this investigation.\r\nIndicators of Compromise\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 8 of 11\n\nAdobe Flash Downloader\r\n189f707cecff924bc2324e91653d68829ea55069bc4590f497e3a34fa15e155c\r\nAdobe Flash Exploit (CVE-2018-5002)\r\n3e8cc2b30ece9adc96b0a9f626aefa4a88017b2f6b916146a3bbd0f99ce1e497\r\nCHAINSHOT Samples\r\nX86 Shellcode Payloads:\r\nd75de8f7a132e0eb922d4b57f1ce8db47dfcae4477817d9f737762e486283795\r\n2d7cb5ff4a449fa284721f83e352098c2fdea125f756322c90a40ad3ebc5e40d\r\nFirstStageDropper.dll:\r\na260d222dfc94b91a09485647c21acfa4a26469528ec4b1b49469db3b283eb9a\r\na09273b4cc08c39afe0c964f14cef98e532ae530eb60b93aec669731c185ea23\r\nSecondStageDropper.dll:\r\n43f7ae58e8e5471917178430f3425061d333b736974f4b2784ca543e3093204b\r\n3485c9b79dfd3e00aef9347326b9ccfee588018a608f89ecd6597da552e3872f\r\nInfrastructure\r\nftp[.]oceasndata[.]com\r\ndl[.]beanfile[.]com\r\neukaznews[.]com\r\nexclusivesstregis[.]com\r\nfishing-uae[.]com\r\napi[.]usecisco[.]info\r\ngulfnews[.]uae-travel-advisories[.]com\r\nqatar[.]eng-theguardian[.]com\r\nmalomatiaa[.]com\r\nnews[.]theqatarpeninsula[.]com\r\npeople[.]dohabayt[.]com\r\nqatar[.]doharotanatimes[.]com\r\nsites[.]oceasndata[.]com\r\nqatar[.]smallwarjournal[.]com\r\nqatarembassies[.]com\r\nsa[.]eukaznews[.]com\r\nsec[.]oceasndata[.]com\r\nrss[.]beanfile[.]com\r\nusecisco[.]info\r\nsmallwarjournal[.]com\r\nawareness-qcert[.]net\r\nspecials[.]fishing-uae[.]com\r\ntheqatarpeninsula[.]com\r\nuae-travel-advisories[.]com\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 9 of 11\n\neng-theguardian[.]com\r\nsecurityandpolicing[.]me\r\napi[.]qcybersecurity[.]org\r\nqatar-sse[.]com\r\napi[.]motc-gov[.]info\r\nyouraccount-security-check[.]com\r\napi[.]exclusivesstregis[.]com\r\nnewhorizonsdoha[.]com\r\nsandp2018[.]securityandpolicing[.]me\r\nicoinico[.]one\r\napi[.]dohabayt[.]com\r\nthelres[.]com\r\nnews[.]gulf-updates[.]com\r\nqatarconferences[.]thelres[.]com\r\napi[.]smallwarjournal[.]com\r\nqcybersecurity[.]org\r\nikhwan-portal[.]com\r\ngulf-updates[.]com\r\napi[.]qatar-sse[.]com\r\ninfo[.]awareness-qcert[.]net\r\napi[.]newhorizonsdoha[.]com\r\ninternationsplanet[.]com\r\nwww[.]winword[.]co\r\nwww[.]oceasndata[.]com\r\npeople[.]dohabayt[.]com\r\neng-defenseadvisers[.]com\r\nmotc-gov[.]info\r\nbeanfile[.]com\r\nnews[.]eng-defenseadvisers[.]com\r\nwinword[.]co\r\ndocuments[.]malomatiaa[.]com\r\nbern[.]qatarembassies[.]com\r\nsurveydoha[.]com\r\ndocuments[.]malomatiaa[.]com\r\ndohabayt[.]com\r\ndoharotanatimes[.]com\r\nactivity[.]youraccount-security-check[.]com\r\npoll[.]surveydoha[.]com\r\napi[.]thelres[.]com\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 10 of 11\n\nq-miles[.]com\r\nrewards[.]q-miles[.]com\r\noceasndata[.]com\r\napi[.]people[.]dohabayt[.]com\r\nbangkok[.]exclusivesstregis[.]com\r\nevents[.]ikhwan-portal[.]com\r\ncontact[.]planturidea[.]net\r\ndl[.]nmcyclingexperience[.]com\r\ntools[.]conductorstech[.]com\r\nSource: https://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nhttps://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/\r\nPage 11 of 11\n\nWhile the final prepared Figure 4. Runtime shellcode looks as version of the shellcode follows: template with filled placeholders   \nLet’s take a look at what values are set to the placeholders (0x11111111, 0x22222222, …). The address 0xA543000 in\nFigure 4 is the entrypoint of the decrypted shellcode payload which has a small NOP sled in front of the actual code:\n  Page 4 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://researchcenter.paloaltonetworks.com/2018/09/unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware/"
	],
	"report_names": [
		"unit42-slicing-dicing-cve-2018-5002-payloads-new-chainshot-malware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434486,
	"ts_updated_at": 1775791321,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/72b828343b11cc110ace7d60de81e41e6867b542.pdf",
		"text": "https://archive.orkl.eu/72b828343b11cc110ace7d60de81e41e6867b542.txt",
		"img": "https://archive.orkl.eu/72b828343b11cc110ace7d60de81e41e6867b542.jpg"
	}
}