{
	"id": "a7649c64-c989-4f43-889b-ef46269cab52",
	"created_at": "2026-04-06T00:14:31.457401Z",
	"updated_at": "2026-04-10T03:21:00.575512Z",
	"deleted_at": null,
	"sha1_hash": "0d40b40df6f3da56d0546de675ee900a7f67dafa",
	"title": "Threat Spotlight: Astaroth — Maze of obfuscation and evasion reveals dark stealer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4273135,
	"plain_text": "Threat Spotlight: Astaroth — Maze of obfuscation and evasion\r\nreveals dark stealer\r\nBy Edmund Brumaghin\r\nPublished: 2020-05-11 · Archived: 2026-04-05 16:03:16 UTC\r\nBy Nick Biasini, Edmund Brumaghin and Nick Lister.\r\nCisco Talos is detailing an information stealer, Astaroth, that has been targeting Brazil with a variety of\r\nlures, including COVID-19 for the past nine to 12 months.\r\nComplex maze of obfuscation and anti-analysis/evasion techniques implemented by Astaroth inhibit both\r\ndetection and analysis of the malware family.\r\nCreative use of YouTube channel descriptions for encoded and encrypted command and control\r\ncommunications (C2) implemented by Astaroth.\r\nWhat's new?\r\nAstaroth implements a robust series of anti-analysis/evasion techniques, among the most thorough we've\r\nseen recently.\r\nAstaroth is effective at evading detection and ensuring, with reasonable certainty, that it is only being\r\ninstalled on systems in Brazil and not on sandboxes and researchers systems.\r\nNovel use of YouTube channels for C2 helps evade detection, by leveraging a commonly used service on\r\ncommonly used ports.\r\nHow did it work?\r\nThe user receives an email message that has an effective lure, in this campaign all emails were in\r\nPortuguese and targeted Brazilian users.\r\nThe user clicks a link in the email, which directs the user to an actor owned server\r\nInitial payload (ZIP file with LNK file) downloaded from Google infrastructure.\r\nMultiple tiers of obfuscation implemented before LoLBins (ExtExport/Bitsadmin) used to further infection.\r\nExtensive anti-analysis/evasion checks done before Astaroth payload delivered.\r\nEncoded and encrypted C2 domains pulled from YouTube channel descriptions.\r\nSo what?\r\nAstaroth is another example of the level of sophistication crimeware is consistently achieving.\r\nThis level of anti-analysis/evasion should be noted, as the likelihood of this spreading beyond just Brazil is\r\nhigh.\r\nOrganizations need to be prepared for these evasive and effective information stealers and prepared to\r\ndefend against the sophisticated attack.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 1 of 28\n\nAnother example of how most adversaries are using COVID-19 themed campaigns to increase\r\neffectiveness.\r\nExecutive summary\r\nThe threat landscape is littered with various malware families being delivered in a\r\nconstant wave to enterprises and individuals alike. The majority of these threats\r\nhave one thing in common: money. Many of these threats generate revenue for\r\nfinancially motivated adversaries by granting access to data stored on end systems\r\nthat can be monetized in various ways. To maximize profits, some malware authors\r\nand/or malware distributors go to extreme lengths to evade detection, specifically\r\nto avoid automated analysis environments and malware analysts that may be\r\ndebugging them. The Astaroth campaigns we are detailing today are a textbook\r\nexample of these sorts of evasion techniques in practice.\r\nThe threat actors behind these campaigns were so concerned with evasion they didn't include just one or two anti-analysis checks, but dozens of checks, including those rarely seen in most commodity malware. This type of\r\ncampaign highlights the level of sophistication that some financially motivated actors have achieved in the past\r\nfew years. This campaign exclusively targeted Brazil, and featured lures designed specifically to tailor to Brazilian\r\ncitizens, including COVID-19 and Cadastro de Pessoas Físicas status. Beyond that, the dropper used sophisticated\r\ntechniques and many layers of obfuscation and evasion before even delivering the final malicious payload. There's\r\nanother series of checks once the payload is delivered to ensure, with reasonable certainty, that the payload was\r\nonly executed on systems located in Brazil and not that of a researcher or some other piece of security technology,\r\nmost notably sandboxes. Beyond that, this malware uses novel techniques for command and control updates via\r\nYouTube, and a plethora of other techniques and methods, both new and old.\r\nThis blog will provide our deep analysis of the Astaroth malware family and detail a series of campaigns we've\r\nobserved over the past nine to 12 months. This will include a detailed walkthrough of deobfuscating the attack\r\nfrom the initial spam message, to the dropper mechanisms, and finally to all the evasion techniques astaroth has\r\nimplemented. The goal is to give researchers the tools and knowledge to be able to analyze this in their own\r\nenvironments. This malware is as elusive as it gets and will likely continue to be a headache for both users and\r\ndefenders for the foreseeable future. This will be especially true if its targeting moves outside of South America\r\nand Brazil.\r\nTechnical details\r\nAstaroth features a multi-stage infection process that is used to retrieve and\r\nexecute the malware. At a high level, the infection process is as follows. We will\r\ndescribe each step of the process in greater detail in later sections.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 2 of 28\n\nDelivery stage These campaigns typically start with a malicious email. This is a common tactic\r\nwhere the emails are designed to look like legitimate email from a familiar brand in an attempt to\r\ntrick users into clicking on malicious links or attachments that may have been included by the\r\nattacker. During our analysis, we have observed thousands of emails associated with campaigns\r\nattempting to spread Astaroth starting in mid-2019. The overwhelming majority of these email\r\ncampaigns appear to be specifically targeting Brazil, and as such are written in Portuguese. Over\r\nthe last six to eight months, these actors have leveraged a variety of different campaigns touching\r\non several different topics. One of the more common examples of malicious actors sending emails\r\npurporting to be associated with a well-known brand in Brazil is seen below.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 3 of 28\n\nThis particular campaign was trying to get users to click a link purporting to be an overdue invoice — a common\r\ntactic for adversaries. The hyperlink in the email actually points to a different URL than what's shown to the user.\r\nThe user may think they are clicking a link to a car rental website local to Brazil, however, the link the user is\r\nactually clicking is below:\r\nhxxp://wer371ioy8[.]winningeleven3[.]re/CSVS00A1V53I0QH9KUH87UNC03A1S/Arquivo.2809.PDF\r\nOne characteristic of the early campaigns was the use of actor owned domains along with subdomains (i.e.\r\nwer371ioy8 from above). We have seen a high volume of unique subdomains and URLs indicating with a high\r\nlikelihood that the URL is generated randomly and the server is designed to respond accordingly.\r\nWhen we began to trace the infection, we saw where the malware actually resides. When a user clicks the link,\r\nthey are redirected to Google Drive to download the actual malicious ZIP file that will be analyzed in later\r\nsections. There are lots of ways that adversaries are doing web redirection and we see techniques like 302-\r\ncushioning commonly. However, these actors instead used a tactic we used to see in the past — iframes.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 4 of 28\n\nNotice that this iframe makes use of relative positioning and renders the iframe above and to the left of the screen,\r\nsomething we commonly observed with exploit kits. This initial redirection into Google infrastructure also\r\nintroduces SSL into the infection path, encrypting the intermediary requests. This traffic results in a clear-text\r\nrequest to a ZIP file hosted by Google, as shown below.\r\nThere were a couple of other interesting lures that these actors have leveraged during these campaigns, including\r\nCOVID-19. In the email shown below the actors sent messages masquerading to be the Ministry of Health for\r\nBrazil. This is the group that provides updates to citizens regarding what's being done to combat the COVID-19\r\noutbreak.\r\nThis announcement is related to the distribution of respirators — a necessary piece of medical equipment used to\r\ntreat COVID patients — inside Brazil and offers a series of recommendations that can be downloaded as a PDF,\r\nwhich is linked. However, the link points to the actors owned servers and the process outlined above begins again.\r\nThis is yet another example of the ways that attackers will continue to leverage COVID-19 to push malware onto\r\nend systems.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 5 of 28\n\nRecently, we have noticed an evolution in the ways that these attackers have been delivering malware. They are\r\nstill using lures associated with invoices and bills, but have changed the formatting and removed some\r\ninfrastructure.\r\nAs you can see, this email is still trying to lure Brazilian users to click links based on documents associated with\r\ndebt collection but has also added another lure, threatening the CPF status of recipients. The CPF or Cadastro de\r\nPessoas Físicas is a vital document in Brazil similar to Social Security Numbers (SSN) in the United States. This\r\ndocument is given to all citizens and visitors that pay taxes and is used for everything from getting a driver's\r\nlicense, to opening a bank account or even getting a cell phone plan. If a citizen has this document suspended, it\r\ncan upend their lives, is costly, and could be an effective lure.\r\nThe authors appear to be removing some tiers of infrastructure as the underlying URLs point directly to the ZIP\r\nfile being hosted by Google, an example of which you will find below:\r\nhxxp://48.173.95[.]34.bc[.]googleusercontent[.]com/assets/vendor/aos/download.php\r\nThese are similar to the URLs previously mentioned, but removes the need for the traffic to interact with an actor\r\nowned server. We see both varieties of campaigns launched in parallel now, so both are still being leveraged today.\r\nOnce the initial dropper gets onto the system, the LNK files kick off the complex infection process.\r\nInfection Stage 1\r\nThe aforementioned ZIP archives contain malicious Microsoft Windows shortcut (LNK) files that\r\nare used to execute stage one of the infection process. They are used to perform an initial\r\ndownload of additional malicious content and effectively initiate the infection process.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 6 of 28\n\nThey have been obfuscated in an attempt to evade rudimentary strings-based analysis. An example of one of these\r\nLNK files is below.\r\nWhen executed, the batch commands embedded in the LNK are responsible for creating a JScript file which is\r\nstored in \"C:\\Users\\Public\\Documents\\\" and then executing it.\r\nThis JScript is responsible for making an HTTP GET request to an attacker-controlled web server for the purposes\r\nof retrieving the next stage of the infection process.\r\nThe response data received from the attacker-controlled server contains an additional stage of obfuscated JScript\r\nwhich is directly executed by the process running on the infected system and never written to the filesystem. The\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 7 of 28\n\nURL structure used to retrieve additional instructions from the first tier of attack-controlled distribution servers\r\nvaries across campaigns but is consistent with the following examples:\r\nAn example of one of these scripts that were obtained from a network traffic capture below.\r\nThe execution of the JScript that is obtained initiates the next stage of the infection process.\r\nInfection Stage 2\r\nThe JScript that was delivered as part of the earlier stage of the infection process features the use\r\nof various types of obfuscation to make analysis more difficult. CharCode replacement is used\r\nthroughout the script where ASCII characters have been replaced with their decimal\r\nrepresentations. As an example, a subset of the obfuscated JScript is below:\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 8 of 28\n\nThe script is effectively taking the decimal representation of ASCII characters, converting them, and\r\nconcatenating the result to create a string containing the command-line syntax necessary for the Windows\r\nCommand Processor to execute them.\r\nTaking these numeric values and cross-referencing them with text converters like this, we can convert the data\r\nback to a human-readable format:\r\nIn addition to the CharCode conversion, variable declarations are used to break the command-line syntax up in a\r\nway that makes it more difficult to read and interpret what is taking place.\r\nTaking the variable declaration in the previous example a step further, once we have converted the decimal back to\r\nASCII, we can then take the contents of the variables being declared and replace them to rebuild the command-line syntax being invoked.\r\nThe fully deobfuscated JScript reveals a robust downloader that the malware uses to attempt to retrieve a Stage 3\r\nmalware payload and execute it. The downloader is responsible for performing the following process:\r\n1. It first attempts to determine if the Stage 3 malware payload is already present on the system.\r\n2. If it is not, it creates a randomly generated directory structure that will be used to store the Stage 3 payload\r\nonce it has been retrieved.\r\n3. It then randomly selects a distribution server domain and URL structure and uses the bitsadmin Windows\r\nutility to attempt to retrieve the stage 3 malware payloads.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 9 of 28\n\n4. If successful, the resultant Dynamic Link Library (DLL) is then stored and the loader attempts to use the\r\nExtExport LoLbin to load the DLL and execute the Stage 3 malware payloads.\r\nAnalysis of the Stage 2 downloader The downloader used in these distribution campaigns featured\r\ninteresting functionality that was likely included to make the distribution infrastructure being\r\nused more resilient to URL and domain-based blocking that many organizations might employ.\r\nNote: During our analysis of the obfuscated downloader, variable names, function names, and parameter names\r\nwere changed from their original randomly generated values to improve readability and make the analysis process\r\nmore efficient.\r\nThe downloader first checks for the existence of a file located at the following directory location as a way to\r\ndetermine if the system has already been delivered a Stage 3 malware payload.\r\nC:\\Users\\Public\\h\r\nIf the file exists, its contents are read as it contains the directory location of the Stage 3 payload.\r\nIn the case that the file containing the location of the Stage 3 payload is not present on the infected system, the\r\ndownloader generates and creates the directory structure where the Stage 3 payload will be stored following\r\nretrieval from the attacker-controlled distribution servers. The directory structure the malware uses is stored in a\r\nsubdirectory of %APPDATA%\r\nWhile the aforementioned code has been slightly modified ([A-Z] added for readability), a randomization function\r\npresent in the JScript is invoked with a randomly selected CharCode value between the range of 65 and 90, which\r\nare then converted back to ASCII. This CharCode range represents the CharCodes for all ASCII characters\r\nranging from \"A\" to \"Z.\"\r\nIt is then written to the file that was initially queried, presumably so that the malware can locate it during\r\nsubsequent execution attempts. This directory structure is then created to facilitate the rest of the loading process.\r\nNext, the malware checks for the presence of a Stage 3 malware payload called \"sqlite3.dll\" in this directory\r\nlocation. If it already exists, it checks the size of the file, and if it is less than 10 bytes, the file is deleted and the\r\nloading process continues.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 10 of 28\n\nIf the DLL is successfully located and larger than 10 bytes, the loader attempts to load it, first by attempting to\r\nlocate and invoke the ExtExport.exe LoLbin, and failing back to regsvr32 if the ExtExport.exe binary cannot be\r\nlocated.\r\nIn the case that the Stage 3 DLL is unable to be located, the loader will proceed to initiate HTTP communications\r\nto a set of distribution servers to retrieve and execute it. To facilitate this process, the loader first generates a URL\r\npath to use for subsequent web requests to retrieve the DLL. It does this by breaking the URL into several parts,\r\nusing the randomization function to generate values for each part, then concatenating them to form the full URL\r\npattern.\r\nThe distribution server domain to use is generated by calling an additional function. This function selects a\r\nrandom number between \"0\" and \"19\" and then performs a comparison against a list of distribution server\r\ndomains. The matching value is then stored in a variable that is used in the previous screenshot.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 11 of 28\n\nOnce all of this information has been generated, it is then assembled and passed to a function that uses the\r\nBitsadmin Windows utility to retrieve the payload and store it in the malware's working directory.\r\nOnce the payload has been successfully retrieved, the same previously described process is used to attempt to\r\nlocate ExtExport.exe or if unsuccessful, regsvr32 is used to load the DLL and initiate the execution of the malware\r\npayload itself.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 12 of 28\n\nA 4,000-second (or 66-minute) timeout counter is also present, after which time it exits.\r\nThe downloader retrieves additional binary content from two other distribution servers which is directly executed\r\nas part of Stage 3.\r\nThe resultant HTTP GET requests can be observed in the screenshot below.\r\nThe payloads being delivered in these campaigns are the main Astaroth DLL. Astaroth is a modular malware\r\nfamily that is used to steal sensitive information from various applications running on infected systems.\r\nAstaroth analysis\r\nThe three payloads that are retrieved during Stage 2 are binary components that are combined to\r\nreconstruct the Astaroth DLL. Once they are combined, the DLL is then executed to initiate the\r\nfinal stage of the infection process. We performed detailed analysis of the functionality present\r\nwithin these DLLs and identified several interesting characteristics associated with its operations.\r\nThese are described in the sections below.\r\nAnti-analysis/Anti-sandbox mechanisms\r\nAstaroth features a robust series of anti-analysis and anti-sandbox mechanisms that it uses to\r\ndetermine whether or not to continue the infection process. The diagram below provides a high\r\nlevel depiction of these checks, which will be described in more detail in this section.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 13 of 28\n\nThe Astaroth samples associated with these campaigns feature an extensive set of environmental checks that are\r\nperformed in an attempt to identify if the malware is being executed in a virtual or analysis environment. If any of\r\nthe checks fails, the malware forcibly reboots the system using the following command-line syntax:\r\n\"cmd.exe /c shutdown -r -t 3 -f\"\r\nBelow is a high-level view of the code execution flow associated with these anti-analysis mechanisms.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 14 of 28\n\nThe malware leverages CreateToolhelp32Snapshot to identify virtual machine guest additions that may be\r\ninstalled on the system, looking for those associated with both VirtualBox and VMware.\r\nIt also looks for the presence of hardware devices that are commonly seen on virtual machines.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 15 of 28\n\nIt also checks the value of the SystemBiosDate which is stored in the Windows registry\r\n(HKLM\\HARDWARE\\DESCRIPTIONS\\System\\SystemBios\\Date) to determine if the value matches \"06/23/99,\"\r\nwhich is the default value for virtual machines within VirtualBox.\r\nThe malware then checks the running programs on the infected system using EnumChildWindows to identify\r\ncommon analysis, debugging and sandboxing tools that may be running on the infected system.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 16 of 28\n\nIt attempts to identify the following applications which are commonly used for malware analysis:\r\nOllyDbg\r\nImmunityDebugger\r\nWinDbg\r\nIDA Pro\r\nProcess Explorer\r\nProcess Monitor\r\nRegMon\r\nFileMon\r\nTCPView\r\nAutoruns\r\nWireshark\r\nDumpcap\r\nProcess Hacker\r\nSysAnalyzer\r\nHookExplorer\r\nSysInspector\r\nImportREC\r\nPETools\r\nLordPE\r\nJoebox\r\nSandbox\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 17 of 28\n\nx32dbg It also checks for the presence of Sandboxie on the system using GetModuleHandleA on\r\nSbieDll.dll.\r\nSimilar to the check for Sandboxie, the malware also checks for the existence of \"dbghelp.dll,\" which is part of\r\nMicrosoft's freely available Debugging Tools for Windows.\r\nIt then checks the value stored in Windows registry at the following location:\r\nHKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\ProductId\r\nThe malware is specifically looking for the following values:\r\n76487-644-3177037-23510\r\n55274-640-2673064-23950 If those values are present, it indicates that the host environment is\r\nCWSandbox or JoeBox, respectively.\r\nThe malware then enumerates the username associated with the account the malware is running under. It checks to\r\nsee if the username matches the value \"CURRENTUSER.\"\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 18 of 28\n\nNext, the malware attempts to open the virtual devices \"\\\\\\.\\\\SICE\" and \"\\\\\\.\\\\NTICE\" which are associated with\r\nSoftICE, a \"kernel mode debugger for DOS and Windows.\"\r\nIt also leverages a call to IsDebuggerPresent to attempt to determine if the sample is being executed in a debugger.\r\nRather than importing the function the standard way, the malware dynamically loads it to hide the fact that this\r\nwill take place during static analysis of the sample.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 19 of 28\n\nIt follows this up by also manually checking the Process Environment Block (PEB) as an additional way to check\r\nfor the presence of a debugger.\r\nNext, the malware attempts to identify if it is being executed in a WINE environment. This is accomplished by\r\nloading ntdll.dll and checking for the existence of the functions \"wine_get_version\" and\r\n\"wine_net_to_unix_file_name.\"\r\nThe malware also leverages calls to GetModuleHandleA to check for the existence of several additional DLLs that\r\nare common within sandbox environments. It attempts to locate the following DLLs:\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 20 of 28\n\ndbghelp.dll\r\napi_log.dll\r\ndir_watch.dll\r\npstorec.dll\r\nvmcheck.dll\r\nwpespy.dll These DLLs are associated with a variety of different sandbox platforms including VMware,\r\nSunBelt Sandbox, VirtualPC and WPE Pro.\r\nFinally, the malware attempts to determine if it is being executed in an emulated environment using QEMU. It\r\ndoes this by checking for \"qemu-ga.exe,\" which is associated with the QEMU Guest Agent.\r\nAs previously mentioned, if any of these checks fail, the malware will terminate execution and force the system to\r\nrestart. This demonstrates the effort that Astaroth makes to avoid analysis and evade a variety of different\r\nplatforms that are commonly used to analyze malware samples.\r\nThe malware also leverages GetSystemDefaultLangID followed by VerLanguageNameA to determine the\r\nlanguage set of the infected system. The language name value is then compared to the substring \"portu\" to\r\ndetermine if the system is configured to use Portuguese. If the language set is not a Portuguese one, the malware\r\nterminates via ExitProcess.\r\nNext the DLL begins a loop, checking for the presence of an open window with a title matching the value\r\n\"pazuzupan0155.\" If the window does not exist, the malware calls WSAStartup, then proceeds to download an\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 21 of 28\n\nadditional malicious payload from an attacker-controlled server using a URL pattern similar to the following\r\nexample:\r\nhxxp[:]//15uaer[.]coragem[.]cf/?17475461717677867\r\nThis time, the payload that is retrieved is a PE EXE rather than a DLL. This EXE is then executed using a\r\ntechnique referred to as \"process hollowing.\" In this case, the process hollowing is targeting the process\r\n\"userinit.exe\" and uses the same process that is described here.\r\nIf an open window with a title matching \"pazuzupan0155\" does exist, the DLL calls a sleep function and,\r\neventually, the loop repeats. This approach may have been taken to provide a means to ensure that the malware is\r\npersistently executing on infected systems. In the case that the executable is removed, the DLL will simply replace\r\nit the next time the loop executes. This also serves as a means to ensure that the latest version of the malware can\r\nbe retrieved from the distribution servers as versions are updated by the attackers.\r\nModule analysis\r\nAstaroth versions are typically tracked using the string value present in the function names used\r\nthroughout the samples. The version associated with these latest campaigns is called\r\n\"gomorytrol.\" Consistent with previous versions of Astaroth, this is also a demonology reference,\r\nin this case to the demon \"Gomory.\"\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 22 of 28\n\nThese functions are used by various timers, forms, and threads, consistent with previously published analysis. The\r\n\"gomorytrol\" version of Astaroth is internally referred to as version 157, with other recent versions listed below.\r\n\"masihaddajjal\" (version 152)\r\n\"forneus\" (version 153)\r\n\"mammonsys\" (version 154)\r\n\"pazuzupan\" (version 155)\r\n\"lechiesxkw\" (Version 156)\r\n\"gomorytrol\" (Version 157)\r\nIt is important to note that the version number changed repeatedly during our analysis of Astaroth, indicative of\r\nthe rapid evolution of this specific threat.\r\nOnce the main Astaroth payload has been executed, it checks for the presence of a file stored using Alternate Data\r\nStreams (ADS) in the following location:\r\nsqlite3.dll:MllkguwbwyshtY6767TGuddhyfyoomrifk\r\nIf the file is not found, the malware will download an additional payload and store it via ADS.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 23 of 28\n\nThis additional payload is then decrypted, loaded into memory, and executed. It performs the same set of anti-analysis checks that were described in previous stages of the infection process. In addition, the malware creates a\r\nlist of strings related to various analysis and sandbox environments, then uses GetModuleFilenameA and\r\nGetComputerNameA to check the system's hostname and process file path and terminates execution if the string\r\nvalues match.\r\nThe malware also performs additional checks to determine the language configuration of the system. In addition to\r\nthe methodology used in previous stages of the infection, the malware checks for the presence of an English\r\nlanguage set and terminates execution if it encounters it.\r\nThe malware currently leverages a new working directory:\r\n\"%USERPROFILE%\\Public\\Libraries\\jakator\"\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 24 of 28\n\nMuch of the core information-stealing functionality performed by the malware has not changed since previous\r\nanalysis was published here. Samples associated with recent campaigns show a particular focus on obtaining\r\nbanking information for customers of Banco de Brasil.\r\nCommand and control (C2)\r\nConsistent with the previous analysis, the malware features a redundant C2 mechanism with both\r\nprimary and secondary C2 infrastructure. The primary way that the malware communicates with\r\nC2 servers is through the retrieval of C2 domains using Youtube channel descriptions. The\r\nattackers have established a series of YouTube channels and are leveraging the channel\r\ndescriptions to establish and communicate a list of C2 domains the nodes in the botnet should\r\ncommunicate with to obtain additional instructions and updates.\r\nA few examples of these Youtube channels that are associated with Astaroth are:\r\nhxxps://www.youtube[.]com/channel/UC48obBfnUnI8i9bH2BmDGBg/about\r\nhxxps://www.youtube[.]com/channel/UC1XqzXRrROkMrIUbSxhATcQ/about\r\nhxxps://www.youtube[.]com/channel/UC2N4Ej53G7pKYJlA7lOj0SQ/about\r\nhxxps://www.youtube[.]com/channel/UC3YzBxaeuGNBFQRS4bfV8XA/about\r\nhxxps://www.youtube[.]com/channel/UCfgh5rFgl267MHRxkFttVLg/about\r\nhxxps://www.youtube[.]com/channel/UC96ziVgeQrKVPp1hofl1dsA/about\r\nhxxps://www.youtube[.]com/channel/UCbbq2Jm2Swj95AVFoHPMdRg/about\r\nhxxps://www.youtube[.]com/channel/UC76P-6J1BP39fjNGkudw1Jw/about\r\nhxxps://www.youtube[.]com/channel/UC-XIp1YC9eZPnNO9VBJTCLw/about\r\nhxxps://www.youtube[.]com/channel/UCA87kfgVEB8yshwYxUdSYLA/about\r\nhxxps://www.youtube[.]com/channel/UCbnDU85fizL0EWdZiwTYonA/about\r\nhxxps://www.youtube[.]com/channel/UCc2nVj0SBkr99-lFO1LCV-A/about\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 25 of 28\n\nAs in previous versions of Astaroth, the information inside of the \"|||\" delimiters contains a list of C2 domains\r\nwhich have been encrypted and base64 encoded. An example of this is below:\r\nWe observed the channel description data change periodically during our analysis. This provides an interesting\r\nway to rotate C2 infrastructure as needed leveraging a platform that is commonly allowed in corporate\r\nenvironments.\r\nThe malware also features a failback C2 mechanism for situations where the YouTube communications may fail.\r\nIn the sample analyzed, the malware was configured to use the following URL as the failback C2 channel.\r\nhxxps://sombrio[.]xxapocalipsexx[.]space/amem//dir1/?4481829444804=184448294448\u00261=\u003cBase64 encoded C2 message\u003e\r\nInitial beaconing from infected systems contains various information about the environment and uses the\r\nfollowing format:\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 26 of 28\n\nAnalysis of the C2 domains used by the malware shows that DNS resolution activity appears to be occurring\r\nalmost exclusively in Brazil, as is consistent with the distribution campaigns, comprehensive checks performed by\r\nthe malware, and financial institutions whose customers are being targeted by the malware.\r\nOverall, Astaroth takes an unusual approach to the implementation of their Domain Generation Algorithm (DGA)\r\nand the communication of C2 updates to infected systems. The use of multiple redundant C2 mechanisms makes it\r\nparticularly resilient to infrastructure takedowns.\r\nBeyond that, this malware family is being updated and modified at an alarming rate, implying its development is\r\nstill actively being improved. These adversaries are also quickly moving and pivoting through infrastructure,\r\nswapping out nearly weekly, to stay agile and ahead of defenders. When this malware widens its net of victim\r\ncountries, more and more defenders will need to be prepared to step through this complex threat.\r\nThese financially motivated threats are continuing to grow in sophistication, as adversaries are finding more ways\r\nto generate large sums of money and profits. Astaroth is just another example of this and evasion/anti-analysis are\r\ngoing to be paramount to malware families success in the future. Organizations need to have multiple layers of\r\ntechnology and controls in place to try and minimize its impacts, or at the least facilitate fast detection and\r\nremediation. This would include security technologies covering endpoint, domain, web, and network. By layering\r\nthese types of technologies organizations will increase the likelihood that evasive, complex malware like Astaroth,\r\ncan and will be detected.\r\nCoverage\r\nWays our customers can detect and block this threat are listed below.\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 27 of 28\n\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors. Exploit Prevention present within AMP is designed to protect customers from unknown attacks such\r\nas this automatically.\r\nCisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious\r\nwebsites and detects malware used in these attacks.\r\nCisco AMP users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected\r\nwith this specific threat. For specific OSqueries on this threat, click here.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign.\r\nNetwork Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention\r\nSystem (NGIPS), Cisco ISR, and Meraki MX.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\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. The following SIDs have been released to detect this threat: 53861.\r\nDomains A list of the domains being used can be found here. Note that subdomains are generated\r\nrandomly, only core domains are listed here.\r\nLNK Hashes (SHA256) A list of hashes associated with the LNK files used in these campaigns can\r\nbe found here.\r\nJScript Hashes (SHA256) A list of hashes associated with the JScript files used in these campaigns\r\ncan be found here.\r\nBinary Hashes (SHA256) A list of hashes associated with the malicious payloads associated with\r\nthese campaigns can be found here.\r\nSource: https://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nhttps://blog.talosintelligence.com/2020/05/astaroth-analysis.html\r\nPage 28 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.talosintelligence.com/2020/05/astaroth-analysis.html"
	],
	"report_names": [
		"astaroth-analysis.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434471,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0d40b40df6f3da56d0546de675ee900a7f67dafa.pdf",
		"text": "https://archive.orkl.eu/0d40b40df6f3da56d0546de675ee900a7f67dafa.txt",
		"img": "https://archive.orkl.eu/0d40b40df6f3da56d0546de675ee900a7f67dafa.jpg"
	}
}