{
	"id": "4422a2ca-22c1-4476-874a-fecfc9acd89a",
	"created_at": "2026-04-06T00:11:07.175751Z",
	"updated_at": "2026-04-10T03:21:06.680326Z",
	"deleted_at": null,
	"sha1_hash": "1d209b9615a4164ca5e145ec63cced7d41dd71dd",
	"title": "Threat Spotlight: Solarmarker",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6429953,
	"plain_text": "Threat Spotlight: Solarmarker\r\nBy Chris Neal\r\nPublished: 2021-07-29 · Archived: 2026-04-05 18:01:18 UTC\r\nThursday, July 29, 2021 13:00\r\nBy Andrew Windsor, with contributions from Chris Neal.\r\nExecutive summary\r\nCisco Talos has observed new activity from Solarmarker, a highly modular .NET-based information stealer\r\nand keylogger.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 1 of 17\n\nA previous staging module, \"d.m,\" used with this malware has been replaced by a new module dubbed\r\n\"Mars.\"\r\nAnother previously unreported module named \"Uranus\" has been identified.\r\nThe threat actor behind Solarmarker continues to evolve while remaining relatively undetected.\r\nCisco Talos has created full coverage in response to this evolving threat, protecting Cisco customersTalos\r\nis actively tracking a malware campaign with the Solarmarker information-stealer dating back to\r\nSeptember 2020. Some DNS telemetry and related activity even point back to April 2020. At the time, we\r\ndiscovered three primary DLL components and multiple variants utilizing similar behavior.\r\nFirst, the initial malicious executable injects the primary component, typically named \"d.m.\" This serves as a\r\nstager on the victim host for command and control (C2) communications and further malicious actions. The\r\nsecond component, commonly referred to as \"Jupyter,\" was observed being injected by the stager and possesses\r\nbrowser form and other information-stealing capabilities. Another secondary module, named \"Uran\" (likely in\r\nreference to Uranus), is a keylogger and was discovered on some of the older campaign infrastructure. Uran was\r\npreviously undiscovered despite deep analysis on Solarmarker and the Jupyter module.\r\nModules\r\nTo provide a more comprehensive description of Solarmarker, we'll break down known and\r\nunreported modules. Information regarding coverage and defense are detailed at the end of this\r\nblog post.\r\nStaging module \"d.m\"\r\nThe staging component of Solarmarker serves as the central execution hub, facilitating initial\r\ncommunications with the C2 servers and enabling other malicious modules to be dropped onto the victim\r\nhost. Within our observed data, the stager is deployed as a .NET assembly named \"d\" and a single\r\nexecuting class named \"m\" (referred to jointly in this analysis as \"d.m\"). The malware extracts a number\r\nof files to the victim host's \"AppData\\Local\\Temp\" directory on execution, including a TMP file with the\r\nsame name as the original downloaded file, and a PowerShell script file (PS1), from which the rest of the\r\nexecution chain spawns. The TMP file executing process issues a PowerShell command that loads the\r\ncontent of the dropped PS1 script and runs it before deleting the loaded file. The resulting binary blob is\r\nthen decoded by XORing its byte array with a hardcoded key and injected into memory through reflective\r\nassembly loading. The \"run\" method of the contained module \"d.m\" is then called to complete the initial\r\ninfection.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 2 of 17\n\nReconstructing the malicious DLL \"d.m\" and invoking it through reflection. The module \"d.m\" acts as a system\r\nprofiler and staging ground for additional action by the actor. One particularly interesting operation (as well as the\r\nnamesake of the campaign) is the file write of \"AppData\\Roaming\\solarmarker.dat,\" which serves as a victim host\r\nidentification tag. When the class method \"GetHWID\" is called, the sample checks if \"solarmarker.dat\" exists\r\nalready on the host. If it does not, a randomly generated 32-character string will be written to the file\r\n\"solarmarker.dat\" at that path. It should be noted that some of the older variants of Solarmarker don't actually use\r\nthis file for storing the victim ID and instead use varying forms of concatenating and encoding the collected\r\nsystem information strings.\r\nThe newly created or existing string is then returned back as the value for the \"hwid\" field in a JSON object also\r\ncontaining fields for collected system information. This object is subsequently encoded by XORing the byte array\r\nwith a hardcoded key, similar to how the first stage PowerShell script constructed the malicious DLL. This new\r\nbyte array is then further encoded in base64 in preparation for transmission to a hardcoded C2 IP address —\r\n45.135.232[.]131 at the time in many of our samples — through HTTP POST requests.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 3 of 17\n\nHTTP POST communications with the C2 using encoded JSON.\r\nThe stager also possesses the ability to remotely receive execution commands by dropping new PS1 or PE files\r\nonto the victim system at \"\\AppData\\Local\\Temp\\\" directory with a filename of 24 randomly generated\r\nalphanumeric characters and executing them either through PowerShell or process hollowing, or through directly\r\nreceiving PowerShell text commands.\r\nJupyter information-stealing module\r\nThe Jupyter information stealer is Solarmarker's second most-dropped module. During the execution of\r\nmany of the Solarmarker samples, we observed the C2 sending an additional PS1 payload to the victim\r\nhost. Responses from the C2 are encoded in the same manner as the JSON object containing the victim's\r\nsystem information. After reversing the base64 and XOR encoding, it writes this byte stream to a PS1 file\r\non disk, runs it, and subsequently deletes the file. This new PowerShell script contains a base64-encoded\r\n.NET DLL, which was also injected through .NET's reflective assembly loading. Analysis of the DLL\r\nmodule, named \"Jupyter,\" shows that it contains capabilities to steal personal information, credentials, and\r\nform submission values from the victim's Firefox and Chrome installation and user directories.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 4 of 17\n\nDecompiled source of one version of the Jupyter DLLs.\r\nLike the \"d.m\" DLL, this module sends information to its C2 server through HTTP POST requests, using a\r\nsimilarly encoded JSON stream containing additional system information and stolen data. However, the previous\r\nversion of the Jupyter DLL we analyzed opts to use a hardcoded domain, \"vincentolife[.]com\" in one case, rather\r\nthan use the same hardcoded IP address as the stager component. The Jupyter module also adds a POST request at\r\nthe end of its execution loop, which queries the C2 domain for additional information and/or commands that could\r\nadd to the data gathered from its primary execution loop.\r\nUnlike the \"d.m\" DLL, rather than use a similar XOR encoding scheme, the versions of Jupyter we analyzed use\r\nthe .NET \"ProtectedData\" class to encrypt the data being sent to Solarmarker's C2 servers. This keeps the\r\nencoding scheme less exposed to static and manual analysis by using .NET's native APIs, in contrast to the hard-coded key values and custom encoding logic in the PowerShell scripts and \"d.m\" DLL. Additionally, by including\r\nthe \"CurrentUser\" flag for the data protection scope argument in the \"Unprotect\" method call, the encryption key\r\nis effectively binded to a specific user. This complicates any attempts at outside decryption and analysis of the raw\r\ndata being communicated between the victim host and the C2 server, even with possession of the \"Jupyter\" DLL\r\nitself.\r\nPreviously Unreported Module: Uran/Uranus\r\nFurther research into the actor's infrastructure revealed a previously unreported second potential payload,\r\n\"Uranus,\" keeping in line with Solarmarker's penchant for space-themed names. It is derived from the file\r\n\"Uran.PS1\" (Uran is the Russian word for Uranus) hosted on Solarmarker's infrastructure at \"on-offtrack[.]biz/get/uran.ps1.\" Like our observed instances of the Jupyter module being dropped, Uranus\r\nstarts off as a PS1 file served through the staging DLL. Similar to the other components, the PS1 file was\r\nencoded through a simple bitwise XOR of each byte in the file. Going back through some of the encode-decode class methods found in both the variants of the staging component and Jupyter module allowed us\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 5 of 17\n\nto match Uranus with the correct decoding method. Upon execution, the PowerShell script reflectively loads\r\nthe DLL class, \"Uran,\" on the victim host and initiates its \"Run\" method.\r\nAnalysis of the Uranus module reveals it to be a form of keylogging malware. When the \"Run\" method is\r\nexecuted, the malware instantiates a \"LogCollector\" class object. Its functionality is relatively straightforward, but\r\nmakes impressive use of a variety of tools within the .NET runtime API. The \"LogCollector\" makes use of other\r\nutility classes contained within the Uranus DLL to capture the user's keystrokes and relevant metadata in order to\r\ncontextualize and sort the actions better. For example, it will look for available input languages and keyboard\r\nlayouts installed on the victim host and attach their two letter ISO codes as additional attributes to the keylogging\r\ndata collected. Interestingly, in this case, the actor checks specifically for German and Russian character sets,\r\nbefore defaulting to an English label. The current foreground window titles are also used as sorting keys in the\r\ndictionary object that the \"LogCollector\" class uses to store its captured input text.\r\nDecompiled source of the Uranus keylogger DLL.\r\nExtraction is set to occur every 10,000 seconds using a thread sleep call to delay Uranus' event loop. This module\r\nalso uses HTTP POST requests as its primary method of communications with Solarmarker's C2 infrastructure.\r\nThis version of the DLL has the hostname \"hxxp://spacetruck[.]biz:82/postk?q=\" hard-coded as the destination for\r\nthe data held by \"LogCollector.\" The query string consists of two components. First, a grouping of system\r\nmetadata, such as the victim ID, version string, and computer name are constructed as a JSON object and\r\nconverted to base64. Unlike the variants that used the \"solarmarker.dat\" file filled with random characters as a\r\nvictim identifier, this version of the module instead uses a combined string of the victim host's username,\r\ncomputer name and hard drive serial number. The byte representation of this string is then run through a byte-shift\r\nand XOR algorithm to produce the victim identification string. Secondly, the dictionary object containing the\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 6 of 17\n\nkeylogging data created by \"LogCollector\" is also converted to base64 and appended to the query string text.\r\nFinally, the POST request is sent and the event loop begins again.\r\nPreviously unreported activity\r\nSolarmarker's general execution flow hasn't significantly changed between versions, updates and\r\nvariants. The actor wants to install a backdoor in memory on the victim host so that it may be\r\nused as a staging ground for further payloads, such as Jupyter. However, around the end of May\r\nand beginning of June 2021, Talos began observing surges of new Solarmarker activity in our\r\ntelemetry. In these recent iterations, the actor tweaked the download method of the initial parent\r\ndropper and has made noticeable upgrades to the staging component, now called \"Mars.\"\r\nDuring our research on earlier campaign activity, Talos initially believed that victims were downloading\r\nSolarmarker's parent malicious PE files through generic-looking, fake file-sharing pages hosted across free site\r\nservices, but many of the dummy accounts had become inactive between the time we found the filenames used by\r\nSolarmarker's droppers in our telemetry and attempting to find their download URLs. This method of delivery was\r\nlater corroborated by malware analysts at CrowdStrike in their own reporting on Solarmarker. For example, we\r\nsaw several download pages being hosted under suspicious accounts on Google Sites. In these cases, the URL for\r\na given file took the form of: hxxps://sites[.]google[.]com/view/{random characters}/{file name}\r\nThese links direct the victim to a page offering the ability to download the file as either a PDF or Microsoft Word\r\nfile. Following the download link sends the victim through multiple redirects across varying domains before\r\nlanding on a final download page.\r\nThis general methodology hasn't changed, many of the parent file names found in our telemetry can be found on\r\nsuspicious web pages hosted on Google Sites, although the actor has changed their final lure pages a bit.\r\nExample of one of the initial landing pages hosted on Google Sites.\r\nPreviously, the Solarmarker samples from our telemetry would be downloaded from a final page with an overly\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 7 of 17\n\ngeneric header name, \"PdfDocDownloadsPanel.\" In this more recent campaign, Solarmarker's operators have put\r\nsome additional effort into making their final download page more legitimate looking, as well as differentiating it\r\nfrom the older pages exposed in public reporting. The final download page now attempts to mimic a download file\r\nrequest from Google Drive, although the page is hosted under a rotating actor-controlled domain.\r\nExample of a final lure page meant to mimic Google Drive.\r\nMars staging module\r\nUpdated Solarmarker variants possessing the newly observed Mars DLL, which took the place of the\r\noriginal stager component \"d.m,\" infect a victim host through two currently known execution chains. The\r\nfirst uses a second-stage dropper after initial execution of the parent file that contains a decoy program\r\nPDFSam as well as the Mars DLL bytes and subsequently executed PowerShell to complete Solarmarker's\r\nlater stages and persistence measures. The second version has the same overall execution chain as the first,\r\nbut hardcodes all of the data and instructions from the second-stage dropper into the parent file itself,\r\ncutting out the need to write an additional file to disk and execute it. These are based on observations\r\nwithin available telemetry. Given the actor's penchant for deploying many different versions of\r\nSolarmarker and its modules, it is likely that the adversary added variations on the execution chain and\r\ndifferent paths and names for the dropped files.\r\nUsing the version with the second-stage dropper as an example, the main file drops a second stage PE, named\r\n\"pk.exe,\" which acts as the springboard for the rest of this Solarmarker variant's execution chain. It writes a copy\r\nof the utility program PDFSam to \"\\AppData\\Local\\Temp\\gkNjg0918jkd.exe.\" This program is executed in\r\ntandem with the rest of Solarmarker's initialization to act as misdirection for the victim by attempting to look like\r\na legitimate document. The main PowerShell script that will serve as the next execution stage is also written to\r\ndisk at \"\\AppData\\Local\\Temp\\tskAjbflM1jj.\" The PE then opens a shell and executes a PowerShell constructed\r\nfrom inside the binary).\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 8 of 17\n\nPowershell embedded in pk.exe used in the next stage of execution.\r\nThe PowerShell command executed will read in the base64-encoded text from the \"tskAjbflM1jj\" file and\r\nsubsequently delete this file from the victim's hard drive. Next, it will XOR the decoded bytes using a hardcoded\r\nalphanumeric key string, in this case:\r\nxk='ovRsNQkSWZXFaYUDHPAdmlhGfrjOenBtbzEqpwIxMycTCgiuKJLV.'\r\nAfter the bytes are XOR'd, the resulting string is another PowerShell script, which is then executed through the\r\nInvoke-Expression cmdlet.\r\nThis second PowerShell script contains the Mars DLL hardcoded within it, along with the final stages of\r\nSolarmarker's initial execution. The DLL file is written to disk at:\r\n\"%USER%\\APPDATA\\ROAMING\\MiCrOSofT\\\u003cRandom string of 5-20 characters\u003e\\\u003cRandom string of 10-20\r\ncharacters\u003e\"\r\nThe actual file write is done by looping through the Mars DLL byte array while injecting random bytes into the\r\nfile so that the actual malicious DLL doesn't sit on the victim's disk. The script will then construct a PowerShell\r\ncommand that reads the newly written file and reverses the byte manipulation, as well as performing byte XORing\r\nwith another hardcoded key, similar to the previous PowerShell command. The result is the actual Mars DLL,\r\nwhich is loaded through assembly reflection and executed by calling the \"Interact\" method from the\r\n\"Mars.Deimos\" class. Finally, the script sets up persistence measures by creating a startup task that copies the final\r\nPowerShell command and re-runs the execution of the Mars DLL. It will try to create this through the PowerShell\r\nRegister-ScheduledTask cmdlet, and upon that action failing, will instead create a WScript object containing the\r\nPowerShell command to load and execute the Mars DLL and write it to a shortcut file in the victim's startup folder\r\nnamed \"a8a85b041dc4c2bfc00abf64d546d.LnK\".\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 9 of 17\n\nPowerShell script setting up persistence measures and invoking the Mars DLL.\r\nAfter the dropper's intermediate stages of execution are completed, the Mars module is reconstructed from a file\r\nwritten to disk after being run through an XOR algorithm in PowerShell, similar to the campaign's previous\r\nexecution chains. The resulting malicious DLL file is loaded through .NET's assembly reflection using PowerShell\r\nand invoked by calling the \"Interact\" method of the \"Mars.Deimos\" class.\r\nAs mentioned above, the second version of the execution chain forgoes the secondary dropper file and instead has\r\nthe information contained in \"pk.exe\" encoded in the parent PE file. In these samples, the decoy program PDFSam\r\nwas written to the hardcoded location of \"%USER%\\AppData\\Local\\Temp\\CMmnnjAi1984unbd.exe,\" while the\r\nencoded PS1 file is written to disk at \"%USER%\\AppData\\Local\\Temp\\FkJB11kdJJhbdDl.\" The remainder of the\r\nexecution is similar to the one stemming from \"pk.exe.\"\r\nSecond stage PowerShell code now embedded in the parent PE file.\r\nDecompilation of the DLL shows that it first gathers some initial system information about the victim host, such\r\nas the Workgroup name, is the user a system administrator, system name, current user, and Windows version. This\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 10 of 17\n\ninformation is collected through execution calls to different methods inside of the Deimos class and the results are\r\ncollected into a JSON text string and sent to Solarmarker's C2 server through HTTP POST requests. Previous\r\ncomponents would alternate between using hostnames and IP addresses to contact the C2 server. In this case, these\r\nversions of the Mars module use a hardcoded IP value: 46[.]102[.]152[.]102. This C2 host had not been observed\r\nin older versions of Solarmarker's components previously analyzed.\r\nDecompiled code from a non-obfuscated Mars DLL.\r\nLike the previous stager, the Mars module also remotely receives execution commands by dropping new files onto\r\nthe victim system and spawning processes to run them, or through direct PowerShell text commands. During the\r\nexecution of the DLL's \"Begin\" method, if the \"flag\" boolean variable is set to \"false,\" the malware on the victim\r\nhost is set to receive a file or command response from the C2. For file responses, the sample expects either a PS1\r\nor PE file based on the values associated with the \"status,\" \"task_id\" and \"type\" keys in the JSON object. The\r\nreceived bytes are written to the \"\\AppData\\Local\\Temp\\\" directory with a filename of 24 randomly generated\r\nalphanumeric characters. If Mars receives a PowerShell command string, the command is executed directly\r\nwithout writing anything to disk. These files are then subsequently deleted from the victim's hard drive. In\r\ninspecting network communication from the earlier Solarmarker campaign, we observed the Jupyter module\r\ndropping through a PS1 file.\r\nThe Mars module also uses a more complex encryption scheme than its predecessor to better obfuscate the data\r\nsent to and from the C2 server. Previously, Solarmarker would use a combination of base-64 encoding and a\r\nbitwise XOR algorithm, or a simple implementation of .NET's default encryption scheme, to encode the JSON\r\nbeing sent back and forth in the HTTP POST traffic. The actor now uses a 16 byte, randomly generated AES\r\nsymmetric key to encrypt the data sent to and from the C2 host, which is created during the Mars DLL's initial\r\nexecution. This key is sent with the victim identification string back to the actor's C2 in the first HTTP request,\r\nwhich is itself encrypted using an RSA asymmetric key pair. The public key is hardcoded within the Mars DLL,\r\nmaking the symmetric key, and thus, a readable version of the POST JSON data much more difficult to obtain in\r\ngeneral practice.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 11 of 17\n\nLike the \"d.m\" and Jupyter modules, the Mars DLL has a few different versions. At the time of writing, five\r\ndifferent variants are seen in our telemetry and VirusTotal data. These possessed the identifiers: \"IN-1,\" \"IN-2,\"\r\n\"IN-3,\" \"IN-9\" and \"IN-10.\" Most of Solarmarker's variants have left the \"solarmarker.dat\" artifact on disk that\r\nmakes it easy to identify the actor's activity. As previously mentioned, some of the older variants of Solarmarker\r\ndon't actually use this file for storing the victim ID and instead use varying forms of concatenating and encoding\r\nthe collected system information strings, but for most of the observed instances between October 2020 and June\r\n2021 this file is present. However, Solarmarker's operators appear to have noticed this and have attempted to\r\nfurther obfuscate their modules, making it more difficult for defensive measures to detect specifically on the\r\n\"solarmarker.dat\" file.\r\nThe higher versioned variants of Mars, \"IN-9'' and \"IN-10,\" no longer use the \"solarmarker.dat\" file to house the\r\nvictim's identification string. Instead, they use the randomly generated 32-character string as the text file name and\r\nthe file's contents. The check to see if \"solarmarker.dat\" already exists on a victim has also been changed to cycle\r\nthrough all the file names in the path \"%USER%\\APPDATA\\ROAMING\" and look for a file whose name is\r\nequivalent to the extracted text within it. These versions also attempt to obfuscate the C# code itself by using the\r\nDotfuscator packer, thereby frustrating efforts at analyzing its decompiled form.\r\nMars DLL that has been obfuscated through Dotfuscator.\r\nTargets\r\nAt its core, the Solarmarker campaign appears to be conducted by a fairly sophisticated actor\r\nlargely focused on credential and residual information theft. The specific extraction of browser\r\nforum captures, cookie data, and credential database files in the Jupyter module, along with the\r\nkeylogging component of the Uranus module lends further credence to a specific interest in\r\ncredential harvesting. The targeted language component of the keylogger suggests that the actor\r\ncould have a heightened geographical interest in Europe, or it does not have the ability to process\r\ntext in languages outside of English, German or Russian. During initialization, the class object\r\nresponsible for monitoring the victim's keypresses checks specifically whether the current host's\r\nkeyset language code is one of those three languages. If the returned language code is none of\r\nthese, it defaults to labeling its captured text as English. This really only attaches specificity to\r\nGerman or Russian-speaking victims, as it indiscriminately mixes other language sets that use\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 12 of 17\n\nvariants of the Latin script and non-Latin languages, such as the CJK group, all under the\r\numbrella of \"English.\" Regardless, they are not particular or overly careful as to which victims\r\nare infected with their malware. This is evidenced by the large variety of composition for the\r\nparent file names and the absence of similar geographical checks on the victim systems before\r\ndropping and executing any of the later-stage modules.\r\nDuring this recent surge in the campaign, Talos observed the health care, education, and municipal governments\r\nverticals being targeted the most often. These sectors were followed by a smaller grouping of manufacturing\r\norganizations, along with a few individual organizations in religious institutions, financial services and\r\nconstruction/engineering. Despite what appears to be a concentration of victimology among a few verticals, we\r\nassess with moderate confidence that this campaign is not targeting any specific industries, at least not\r\nintentionally. The variety of naming in Solarmarker's lure files is too great to be of any specific relevance to a\r\ntargeted industry. To this point, we originally suspected that the actor may have been scraping document file\r\nnames across the web to use as file names for its dropper. Researchers at Microsoft have also stated they believe\r\nthe Solarmarker campaign is using SEO poisoning in order to make their dropper files highly visible in search\r\nengine results. This could also potentially skew what types of organizations are likely to come across the\r\nmalicious files depending on what is topically popular at the time.\r\nOrganizations should be particularly concerned about the modular nature and information stealing capabilities of\r\nthis malware family. Solarmarker has so far shown to split, not only its staging activity, but also final payloads of\r\nvarying functionality into separate DLL components. Using the staging DLL, the malware can then execute\r\nwhichever payload module they choose, some of which may be previously undiscovered. The modules already\r\nobserved make potential victims vulnerable to having sensitive information stolen, including sensitive browser\r\nusage, such as if they enter their credit card number or other personal information. These attackers may also look\r\nto steal login credentials, which could then be used for lateral movement into other systems or to access and steal\r\neven more enticing data, such as a customer or patient medical information database.\r\nThreat actor\r\nThere are indicators and evidence suggesting that Russian language speakers created\r\nSolarmarker, or the creators at least designed it to look that way. Static and dynamic analysis of\r\nSolarmarker's droppers revealed attributes in the executables' resource section that indicate the\r\nfiles were created on a system with Russian language support. The keylogging module's name,\r\n\"Uran,\" is a transliteration of the Russian word for Uranus, \"Уран,\" and Russian was listed as a\r\ntargeted language in the module itself. The name of the browser credential and information\r\nstealer, \"Jupyter,\" could also be an attempted transliteration or translation of the Russian\r\nequivalent for Jupiter, \"Юпитер,\" albeit an odd one. A more commonly accepted transliteration\r\nfor a native Russian speaker would be \"Yupiter.\" The names for the \"Mars\" module and its class\r\nobject \"Deimos\" work both as direct English words and possible transliterations of their Russian\r\nequivalents, \"Марс\" and \"Деймос.\"\r\nCharacter use and substitution doesn't have universally applied rules in Russian when using the Latin alphabet.\r\nTherefore, the naming scheme is not all that odd within the given context. Security researchers from Morphisec, in\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 13 of 17\n\ntheir analysis of the Jupyter module, also pointed out similar indicators of the actor potentially being Russia-based, such as possibly misspelling the English \"Jupiter\" and the hardcoded IP addresses being hosted on\r\n\"SELECTEL,\" a Russian ASN, which was also true for IP addresses found in other modules and Solarmarker\r\nvariants during earlier stages of the campaign. While it is interesting to highlight this pattern, and other\r\ncircumstantial evidence, it is important to note that this is not sufficient to assign any high-confidence attribution.\r\nAll of these components are fairly easy to manipulate into arbitrary values by the actor, and thus, without\r\nadditional evidence, could just as well be false flags.\r\nConclusion\r\nThe actor behind the Solarmarker campaign possesses moderate to advanced capabilities.\r\nMaintaining the amount of interconnected and rotating infrastructure and generating a seemingly\r\nlimitless amount of differently named initial dropper files requires substantial effort. The actor\r\nalso exhibits determination in ensuring the continuation of their campaign, such as updating the\r\nencryption methods for the C2 communication in the Mars DLL after researchers had publicly\r\npicked apart previous components of the malware, in addition to the more typical strategy of\r\ncycling out the C2 infrastructure hosts.\r\nThere are several proactive and remedial actions to mitigate the risk of infection, data theft, and potential further\r\naction post-infection by Solarmarker. Initial execution of Solarmarker is seemingly reliant on the user willingly\r\ndownloading and opening its parent file. Organizations need to educate users on the risks of downloading and\r\nexecuting files from unvetted or suspicious sources on the internet.\r\nThere are other aspects to the malware that are more susceptible to active defense measures. Restricting the use of\r\nadministrative tools, in this case PowerShell, can help prevent any of Solarmarker's numerous scripts from\r\nexecuting. Solarmarker's observed C2 components are hardcoded into their respective DLLs. Monitoring for any\r\ntraffic to either the IP address or domain name can reveal which endpoints have been affected on a network and\r\nhow far the infection has progressed. Blocking traffic to and from both of these indicators effectively hamstrings\r\nSolarmarker's ability to receive further instructions from its operators and to exfiltrate any collected data from the\r\nvictim host. Using multi-factor authentication can help prevent immediate account compromise if a victim\r\nbelieves their information and credentials have already been stolen. This also provides cover time to cycle out the\r\ncredentials for any affected accounts. Finally, ensuring that sensitive systems are properly segmented, have correct\r\nprivilege requirements, and are not unnecessarily facing the internet can prevent lateral movement by the actor\r\nusing stolen credentials and data exfiltration to their C2 server.\r\nSolarmarker's ongoing campaign and associated family of malware are concerning. It was initially able to operate\r\nand evolve over a significant amount of time while remaining relatively undetected. Its ability to receive and drop\r\nadditional files, in addition to executing PowerShell commands from the actor's C2, opens up the possibility of\r\nfuture updates and evolutions of Solarmarker's child modules, as well as additional functionalities through new\r\nmalicious components being developed by the actor. We expect the actor behind Solarmarker to continue to refine\r\ntheir malware and tools, as well as alternate their C2 infrastructure, in order to prolong their campaign for the\r\nforeseeable future. As stated above, Solarmarker's operators have already shown a willingness and ability to\r\nupdate their tactics, techniques, and procedures (TTPs) based on points of exposure in previous iterations.\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 14 of 17\n\nCoverage\r\nWays our customers can detect and block this threat are listed below.\r\nCisco Secure Endpoint is ideally suited to prevent the execution of the malware detailed in this post. New users\r\ncan try Cisco Secure Endpoint for free here.\r\nCisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in\r\nthese attacks.\r\nCisco Secure Firewall and Meraki MX can detect malicious activity associated with this threat.\r\nCisco Secure Malware Analytics helps identify malicious binaries and build protection into all Cisco Security\r\nproducts.\r\nCisco Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and\r\nURLs, whether users are on or off the corporate network.\r\nAdditional protections with context to your specific environment and threat data are available from the Cisco\r\nSecure Firewall Management Center.\r\nOpen Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase on Snort.org.\r\nThe following ClamAV signatures have been released to detect this threat as well as tools and malware related to\r\nthese campaigns:\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 15 of 17\n\nWin.Trojan.Solarmarker-9832983-0\r\nWin.Dropper.SolarMarker-9867952-0\r\nWin.Trojan.Jupiter-9858780-0\r\nOpen Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase on Snort.org.\r\nThe following SIDs have been released to detect this threat: 57973-57974\r\nCisco Secure Endpoint (AMP) users can use Orbital Advanced Search to run complex OSqueries to see if their\r\nendpoints are infected with this specific threat. For specific OSqueries on this threat, click here\r\nIOCs IPs:\r\n45.135.232[.]131\r\n46.102.152[.]102\r\nHostnames:\r\nhxxp://on-offtrack[.]biz/get/uran.ps1\r\nhxxp://spacetruck[.]biz:82\r\nhxxp://vincentolife[.]com\r\nSHA256:\r\n99e5a83a5f8e9fb7850922aed9a44bbc2b2a03f5fdda215db4d375bd1952536d - parent dropper\r\n3b79aab07b9461a9d4f3c579555ee024888abcda4f5cc23eac5236a56bf740c7 - parent dropper\r\n77fa1b6fc7f192b0c983d1f8ecc73effae4f688a49439a7df27e76cfba870d23 - parent dropper\r\n032b09bbf1c63afc06afb011d69bafc096d7d925d99e24e3785db5a2957358ec - parent dropper\r\na871b7708b7dc1eb6fd959946a882a5af7dafc5ac135ac840cfbb60816024933 - parent dropper\r\n187e204c5c30b9b56ccc82df510c4c215cdfd37b475d1edba9a0631a4d82ae2e - parent dropper\r\n1252f2bf3817714a8303f7e448930d6d4f797a70ec7effc80f2b1db5e49b9077 - parent dropper\r\n7240e51c027e498e71da4006e261409fcf3a5cf5b912d493a9da91199c840059 - parent dropper\r\n3039dddbcfb26326ba2e8692316ca674753fa6e1d141c887dc1e9f1ae546ca17 - \"pk.exe\" second stage dropper\r\n056f373077ca5b6a070975b22839d6f427cbcaeaec4dc31df86231cd3757f7e3 - Mars DLL\r\n10fc8f8cf1b45a6a6b2b929414a84fc513f80d31b988c3d70f9a21968e943bf2 - Mars DLL\r\n1bd39e3ee0d59ac691cc644c026b6c5bb3d0713f6e4e2136b94f161558a4444f - Mars DLL\r\ne7d165f3728b96921b43984733a92a51148ec87aec900c519a547c470e2a12d9 - Mars DLL\r\neebaec0f28addac39549ebf9be659e105046b1c9801381d4c4dd07cfc74d25d6 - Mars DLL\r\n870f691ec9a83e9c4acce142e0acbf110260e6c8e707410c23c02076244f3973 - Mars DLL\r\n573631c92d34e7ca2dfc1a590606bd66194d517f8d97dd319169262ac46b3e2e - Mars DLL construction PS1 script\r\nb29e6b570a96224c874b9fae36b65db9e9b8c6e1081f18cf87e56bd996470c22 - Mars DLL construction PS1 script\r\n0a11002a0f390fb6e4933fead0521032f8a9ede7ced27f75011d8a30c5772376 - Uran DLL\r\n721bb4554f8e6615dd9e10e28765cf42882c00e1d04f808d8f766b51fdf4d7e6 - Uran construction PS1 script\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 16 of 17\n\n83b50b18ebfa4402b2c0d2d166565ee90202f080d903fd15cccd1312446a636e - \"CMmnnjAi1984unbd.exe\" and\r\n\"gkNjg0918jkd.exe\" decoy program \"PDFSam\"\r\nSource: https://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nhttps://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.talosintelligence.com/2021/07/threat-spotlight-solarmarker.html#more"
	],
	"report_names": [
		"threat-spotlight-solarmarker.html#more"
	],
	"threat_actors": [],
	"ts_created_at": 1775434267,
	"ts_updated_at": 1775791266,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1d209b9615a4164ca5e145ec63cced7d41dd71dd.pdf",
		"text": "https://archive.orkl.eu/1d209b9615a4164ca5e145ec63cced7d41dd71dd.txt",
		"img": "https://archive.orkl.eu/1d209b9615a4164ca5e145ec63cced7d41dd71dd.jpg"
	}
}