{
	"id": "54769473-cab6-4b8a-a2ac-d240ae44573b",
	"created_at": "2026-04-06T00:13:54.415317Z",
	"updated_at": "2026-04-10T03:21:27.494679Z",
	"deleted_at": null,
	"sha1_hash": "9f3f55d939c980c437ae2b66c03baabb117ca65c",
	"title": "Valak: More than Meets the Eye",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5054905,
	"plain_text": "Valak: More than Meets the Eye\r\nBy Cybereason Nocturnus\r\nArchived: 2026-04-05 17:33:54 UTC\r\nResearch by: Eli Salem, Lior Rochberger and Assaf Dahan\r\nCheck out a condensed, high level version of this report on our threat alerts page.\r\nKey Findings\r\nThe Valak Malware: The Valak Malware is a sophisticated malware previously classified as a malware\r\nloader. Though it was first observed in late 2019, the Cybereason Nocturnus team has investigated a series\r\nof dramatic changes, an evolution of over 30 different versions in less than six months. This research\r\nshows that Valak is more than just a loader for other malware, and can also be used independently as an\r\ninformation stealer to target individuals and enterprises. \r\nTargeting Enterprises: More recent versions of Valak target Microsoft Exchange servers to steal\r\nenterprise mailing information and passwords along with the enterprise certificate. This has the potential to\r\naccess critical enterprise accounts, causing damage to organizations, brand degradation, and ultimately a\r\nloss of consumer trust. \r\nTargets US and Germany: This campaign is specifically targeting enterprises in the US and Germany. \r\nWith a Rich Modular Architecture: Valak’s basic capabilities are extended with a number of plugin\r\ncomponents for reconnaissance and information stealing. \r\nUsing Fast Development Cycles: Valak has evolved from a loader to a sophisticated, multi-stage modular\r\nmalware that collects plugins from its C2 server to expand its capabilities. The Cybereason Nocturnus team\r\nhas observed over 30 different versions in about 6 months.\r\nDesigned for Stealth: Valak is a stealthy malware that uses advanced evasive techniques like ADS and\r\nhiding components in the registry. In addition, over time the developers of Valak chose to abandon using\r\nPowerShell, which can be detected and prevented by modern security products.  \r\ntable of contents\r\nKey Findings\r\nIntroduction\r\nThreat Analysis\r\nMulti-stage Attack: Step-by-step Analysis of Valak\r\nSecond Stage: Fetching and Executing Secondary Payloads\r\nSecond Stage JS - Project.aspx\r\nPluginHost - a.aspx\r\nManagedPlugin - Plugins Suite for Enhanced Capabilities\r\nManagedPlugin: Systeminfo, the Reconnaissance Module\r\nManagedPlugin: Exchgrabber - Stealer Targeting Enterprises\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 1 of 27\n\nValak’s Evolution Over Time\r\nValak's Infrastructure\r\nValak’s Relationship With Other Malware\r\nValak’s Evolution as an Independent Malware\r\nConclusion\r\nIndicators of Compromise\r\nMITRE ATT\u0026CK Breakdown\r\nIntroduction\r\nWhen Valak was first discovered in late 2019, it was classified as a loader and used in multiple campaigns\r\nprimarily targeting the US. It was often paired with Ursnif (aka. Gozi) and IcedID. Upon investigation by\r\nCybereason Nocturnus in April 2020, Valak was identified as being used in campaigns mainly targeting the US\r\nand Germany. The campaigns involved new versions, revealing that the malware authors have been working on a\r\nbetter, improved version of the malware quickly. Over thirty different versions of the malware were found,\r\nrevealing tremendous improvements in a very short period of time. Valak’s key features include:\r\nFileless stage: Valak’s contains a fileless stage in which it uses the registry to store different components \r\nReconnaissance: It collects user, machine, and network information from infected hosts \r\nGeolocation Aware: It checks the geo-location of the victim’s machine \r\nScreenCapture: It takes screenshots of the infected machine\r\nDownload Secondary Payloads: It downloads additional plugins and other malware\r\nEnterprise-aware: It targets administrators and enterprises networks\r\nInfiltrates the Exchange Server: It collects and steal sensitive information from the Microsoft Exchange\r\nmail system, including credentials and the domain certificate\r\nAmong it’s improvements, the most important and interesting addition to the newer versions of Valak is a\r\ncomponent called “PluginHost”. PluginHost provides communication with the C2 server and downloads\r\nadditional plugins under the name “ManagedPlugin”. Among the plugins observed are “Systeminfo” and\r\n“Exchgrabber”, both of which appear to specifically target enterprises.\r\nIn this research, we evaluate the differences between the old and new versions of Valak and elaborate on the\r\nmalware capabilities, its infrastructure, and its connection to other malware.\r\nThreat Analysis\r\nInitial infection\r\nIn these campaigns, the most common infection vector is via Microsoft Word documents embedded with\r\nmalicious macro code. The contents of the documents are in English and German depending on the target.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 2 of 27\n\nThe content of the phishing documents.\r\nMalicious macro code is used to download a DLL file with .cab extension named “U.tmp” and saved  into the\r\ntemp folder.\r\nDLL file download address: “hxxp://v0rzpbu[.]com/we201o85/aio0i32p.php?l=hopo4.cab”\r\nAfter downloading the DLL, the code launches the malicious DLL using “regsvr32.exe”.\r\nInitial infection as shown in the Cybereason Defense Platform.\r\nWhen executed, the DLL drops and launches using a WinExec API call. This stage of the Valak malware uses a\r\nmalicious JavaScript file with a random name that changes per execution. In the example below the name of the\r\nJavaScript file is “sly4.0”.\r\nThe DLL dropping the JavaScript file.\r\nMulti-stage Attack: Step-by-step Analysis of Valak\r\nFirst Stage: Gaining Initial Foothold\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 3 of 27\n\nAttack flow for the first stage of Valak.\r\nThe downloaded JavaScript code, “sly4.0”, contains a variable called “PRIMARY_C2” that holds multiple fake\r\nand legitimate domains, including Google, Gmail, Avast, and Microsoft. The domain list varies between samples.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 4 of 27\n\nMalware configuration in the script sly4.0.\r\nValak creates connections to the different C2 servers in the list with two predefined URIs:\r\nOne URI is used to download an encoded file named “project.aspx” [saved as project[1].htm].\r\n*in version 30, the file was renamed to “rpx.aspx”.\r\nURI embedded in the script.\r\nOne URI is used to download an encoded file named “a.aspx” [saved as a[1].htm].\r\n*in version 30, the file was renamed to “go.aspx”.\r\nURI embedded in the script.\r\nBoth files are decoded by the malware using Base64 and an XOR cipher. The key is a combination of a predefined\r\nstring and information collected from memory during runtime.\r\nFunction “rot13_str” decodes a string using XOR.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 5 of 27\n\nThe code for downloading the encoded file and decoding it with the first function (rot13_str) and Base64.\r\nThe “GetID” functions used to create the XOR key and collect information about the user.\r\nThe malware sets information like the C2 server, ID, the downloaded payload, and the decoded project.aspx in a\r\nregistry key under “HKCU\\Software\\ApplicationContainer\\Appsw64”. These keys will be used in the second\r\nstage.\r\nFiles and registry keys written by Valak.\r\nAfter downloading the payloads and setting the registry keys and values, Valak sets it’s persistence via a scheduled\r\ntask.\r\nCreation of the scheduled task to establish persistence.\r\nThe scheduled task is set to launch wscript that executes JavaScript stored as an Alternative Data Stream named\r\n“Default2.ini” in the file “Classic2Application.bz”.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 6 of 27\n\nThe execution of the\r\nscheduled task as shown in the Cybereason Defense Platform.\r\nThe script in the ADS (“Default2.ini”) executes the content of the registry key,\r\n“HKCU\\Software\\ApplicationContainer\\Appsw64\\ServerUrl”, which holds the contents of “project.aspx”, the\r\nsecond stage JavaScript file.\r\nRegistry modifications done by Valak.\r\nSecond Stage: Fetching and Executing Secondary Payloads\r\nIn the first stage, Valak laid the foundation for the attack. In the second stage, it downloads additional modules for\r\nreconnaissance activity and to steal sensitive information.\r\nThe two payloads (“project.aspx” and “a.aspx”) and the configuration in the registry keys are used in the second\r\nstage to perform malicious activities.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 7 of 27\n\nAttackflow for the second stage.\r\nSecond Stage JS - Project.aspx\r\nThe “project.aspx”, or as we refer to it, the second stage JS, is a JavaScript file that looks very similar to the first\r\nstage JavaScript (“sly4.0”). However, on closer inspection it contains additional functions. \r\nThe script is executed by the scheduled task used to maintain persistence, with its  main goal being: \r\nExecute Pluginhost.exe, the plugin management component.\r\nDownload and parse additional payloads from the C2. \r\nSave the payloads as Alternate Data Streams and set scheduled tasks to run them.\r\nConfiguration section of the second stage JS.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 8 of 27\n\nIn the second stage, the configuration file has been altered to contain a unique “Client_ID” and a different file that\r\nit will try to download called “bounce.aspx”.\r\nStage 2 also contains three unique functions,  “CreateExecJob”, “CreateOleExecJob” and “LaunchPlugin”.\r\nThese functions are called from the “ParseTask” function, and receive the parsed tasks from the C2.\r\nThe “ParseTask” function checks the payload.\r\nIf the malware downloads a payload that starts with the word “ODTASK”, it calls “CreateOleExecJob”, which\r\nwrites the payload as an ADS of the file “C:\\\\Users\\\\Public\\\\PowerManagerSpm.jar” and creates a scheduled task\r\n“PerfWatson_%taskname%” to run it.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 9 of 27\n\nThe “CreateOleExecJob” function.\r\nIf the malware receives a content start with the word “PLUGIN”, it calls “LaunchPlugin”, which executes the\r\nPluginHost.exe file using WMI with the content as an argument.\r\nThe “LaunchPlugin” function.\r\nIf the malware receives a content starting with the word “TASK”, it calls “CreateExecJob”, which writes the\r\ncontent as an ADS of the file “C:\\\\Users\\\\Public\\\\PowerManagerSpm.jar” and creates a scheduled task\r\n“PowerUtility_%taskname%W” to run it.\r\nThe “CreateExecJob” function.\r\nOur analysis reveals that this time, the payload downloaded by Valak was IcedID. However, the payload can vary,\r\nas the attackers can download other payloads to the infected system. \r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 10 of 27\n\nIn previous infections, Valak downloaded different remote administration tools like putty.exe and NetSupport\r\nManager.\r\nThe process tree to establish persistence as seen in the Cybereason Defense Platform.\r\nPluginHost - a.aspx\r\nThe decoded “a.aspx” is saved in the temporary folder as %TEMP%\\\u003cID\u003e.bin. This file, internally named\r\n“PluginHost.exe”, is an executable file, and will be used to manage additional components.\r\nValak’s Modular Plugin Architecture\r\nPluginHost - Plugin Management Component\r\nThe functionality of the executable “PluginHost.exe” is divided into four classes: Bot, HTTPClient, Program and\r\nUtils, which will allow it to perform its main goal of downloading and loading additional components of the\r\nmalware.\r\nThe Bot Class:\r\nThe bot class is responsible for reading from several registry entries set by the first stage.\r\nGetID() reads from the registry entry “SetupServiceKey”, which holds the ID.\r\nGetC2() reads from the registry entry  “ShimV4”, which holds the C2 domain.\r\nBoth functions use the Utils class to read registry entries.\r\nGetID() andGetC2() reading from the registry.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 11 of 27\n\nThe  RegistryReadInfo() function in the Utils class.\r\nThe HTTPClient Class: \r\nThe HTTPClient class contains two functions, post and GetPluginBytes.\r\nThe GetPluginBytes() function gets the C2 domain using GetC2() and adds an embedded URI. The URL is used\r\nto download an additional module for the plugin.\r\nGetPluginBytes function used to download the plugin.\r\nThe Program Class: \r\nThe Program class contains the main function of the file main(). This function executes the function\r\nGetPluginBytes() to download the module components with type “ManagedPlugin”. These components will be\r\nloaded reflectively to the executable’s memory and expand the plugin capabilities.\r\nPluginHost’s main function downloads the ManagedPlugin module.\r\nThe Utils Class: \r\nThe Utils class contains several maintenance functions used by the other classes.\r\nManagedPlugin - Plugins Suite for Enhanced Capabilities\r\nWhen referring to additional plugins, it is worth noting that in early versions of Valak the plugins were\r\ndownloaded by the second stage JS via PowerShell. More recent versions of Valak abandoned the popular yet\r\neasily detectable PowerShell downloader approach and transitioned to PluginHost as a means of managing and\r\ndownloading additional payloads. This transition indicates that the Valak authors are looking for stealthier\r\napproaches and ways to improve their evasion techniques.\r\nDuring this analysis, we discovered several different modules with the same internal name, “ManagedPlugin.dll”.\r\nThese modules are downloaded and loaded by “PluginHost.exe”.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 12 of 27\n\nSysteminfo:  responsible for extensive reconnaissance; targets local and domain admins\r\nExchgrabber: aims to steal Microsoft Exchange data and infiltrates the enterprises mail system\r\nIPGeo: verifies the geolocation of the target\r\nProcinfo: collects information about the infected machine’s running processes\r\nNetrecon: performs network reconnaissance\r\nScreencap: captures screenshots from the infected machine\r\nAmong these components, some focus on one single, specific activity to achieve their goal and are relatively less\r\nrobust than others when it comes to capability and potential impact. This includes ipgeo, procinfo, netrecon and\r\nscreencap. \r\nThe Ipogeo module, which collects information using an IP discovery service.\r\nThe Procinfo module, which collects information about the running processes.\r\nThe Netrecon module, which collects network information.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 13 of 27\n\nThe Screencap module, which takes screenshots of the infected machine.\r\nBelow is a deep dive of “systeminfo” and “exchgrabber”, which are more advanced and complex than the\r\naforementioned plugin components.\r\nManagedPlugin: Systeminfo, the Reconnaissance Module\r\n“Systeminfo” shares many similarities to “PluginHost.exe” when it comes to class names. However, unlike\r\n“PluginHost”, it contains several reconnaissance functions that focus on gathering information about the user, the\r\nmachine, and existing AV products.\r\nThe plugin components in Valak.\r\nThe module gathers information about the user and attempts to verify whether this is a local admin or a domain\r\nadmin. This shows that after infecting the machine, Valak chooses to target mainly administrators and domain\r\nadmins. This indicates a propensity to target higher profile accounts such as enterprise admins.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 14 of 27\n\nThe ManagedPlugin (SystemInfo), which determines if the user is a local or domain admin.\r\nThe module attempts to find whether the infected machine has any security products installed using the\r\nAntivirusSoftware() function. The information collected about installed AV programs is gathered using the WMI\r\nquery “SELECT * FROM AntiVirusProduct”.\r\nManagedPlugin (SystemInfo) checks for antivirus products.\r\nThe module also collects the physical address (MAC) and the IP address of the infected machine.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 15 of 27\n\nThe ManagedPlugin (SystemInfo) collects the machine’s physical address.\r\nAdditional reconnaissance activity occurs with several other functions, including:\r\nNetUser - provides more information about the user\r\nSystemUpTime - records the amount of time the machine is running\r\nWindowsVersion - determines the Windows version \r\nManagedPlugin (SystemInfo)\r\nreconnaissance functions.\r\nIn order to exfiltrate data, the plugin uses the function “post” in the HTTPClient class. “Post” gives the plugin the\r\nability to upload content and exfiltrate data to the remote C2 whose domain is stored in the registry.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 16 of 27\n\nManagedPlugin (SystemInfo) data exfiltration function post.\r\nSimilar to “PluginHost”, “SystemInfo” uses another function called GetQuery() that builds the URL to send the\r\ninformation to the remote C2. The URL is encoded using Base64 and some char replacements.\r\nExample of the final URL created by the GetQuery function.\r\nThe core functionality of the “ManagedPlugin” module is in the “ManagedPlugin” class. The function loops\r\nendlessly and continues to execute the reconnaissance activity and send it to the attacker.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 17 of 27\n\nManagedPlugin execution activity.\r\nManagedPlugin: Exchgrabber - Stealer Targeting Enterprises\r\nExchgrabber, similar to systeminfo, shares some similarities with PluginHost when it comes to several function\r\nnames like Bot, HTTPClient, and Utils; however, it has its own differentiated capabilities.\r\nAt first glance, the module appears to solely be used to steal credentials, which can be seen in several classes and\r\ndata arguments with clear names like “Credential” and “CredentialType”.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 18 of 27\n\nExchgrabber classes.\r\nThe module handles its credential management in the class “Credential”, which includes several functions that\r\nhandle the credential management activity and data types that will hold these credentials.\r\nOne of the most interesting functions in this class is “Credential” which receives four arguments: username,\r\npassword, target, and CredentialType. It inserts these credentials into the respective module variable.\r\nThe “target” variable is used in the core ManagedPlugin function to store strings related to Microsoft Office\r\napplications.\r\nThe ManagedPlugin (Exchgrabber) Credential function.\r\nAnother interesting argument in the “credential” function is “CredentialType”. The type of credentials is\r\ndetermined by another part of the enum variable called “CredentialType”, which contains each of the credentials\r\nthat the module will attempt to extract.\r\nThe credential types are sensitive information that can be extracted from the enterprise Microsoft\r\nExchange server data, including Domain Password \u0026 Domain Certificate.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 19 of 27\n\nExtracting this sensitive data allows the attacker access to an inside domain user for the internal mail services of\r\nan enterprise along with  access to the domain certificate of an enterprise. With systeminfo, the attacker can\r\nidentify which user is a domain administrator. This creates a very dangerous combination of sensitive data leakage\r\nand potentially large scale cyber spying or infostealing. It also shows that the intended target of this malware is\r\nfirst and foremost enterprises. \r\nManagedPlugin (Exchgrabber)\r\ncredential types.\r\nWhen inspecting  the core logic behind the class MainPlugin, it’s clear how each class collaborates with others to\r\nextract data from Microsoft Exchange and Outlook.\r\nThe module attempts to check if the extracted data is related to Microsoft Office or MS.Outlook. If so, it attempts\r\nto access the file “Autodiscover.xml” using the function GetFiles. “Autodiscover.xml” is a dynamically generated\r\nfile that contains the data Microsoft Outlook needs to access the mailbox entered in the configuration wizard. The\r\nprimary purpose of the Exchange Autodiscover service is to establish initial connections to Exchange user\r\nmailboxes. It then attempts to collect the AutoDiscover SMTP address of the dedicated exchange forest, and\r\neventually puts all the extracted data in a variable called “text” .\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 20 of 27\n\nMicrosoft exchange data extraction.\r\nAfter collecting the sensitive data, the module compresses it using Base64. This is a new feature of this specific\r\nmodule within the “Utils” class. Then, it sends the sensitive data to the attacker’s C2 with the POST function and\r\nan embedded URI.\r\nManagedPlugin (Exchgrabber) used for data exfiltration using a predefined URI.\r\nValak’s Evolution Over Time\r\nAs of writing this report, we have seen Valak change tremendously. It is currently on version number 24.\r\nThis section highlights the major differences between the previous versions and newer versions of Valak by\r\nanalyzing version 6, version 9, version 23, and version 24.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 21 of 27\n\nImprovements to Payload Obfuscation\r\nIn older versions, Valak downloads the second stage JS and uses only one obfuscation technique: Base64. The\r\nnewer versions use XOR in addition to Base64.\r\nCode from older versions of Valak that only uses Base64 decryption.\r\nCode from a newer version of Valak that uses a more complex decryption function.\r\nPlugin Management Component\r\nThe newer versions of Valak download two payloads in the first stage. The first payload is Valak’s plugin\r\nmanagement component (“pluginhost.exe”), and the second is the second stage JavaScript payload of Valak. In\r\nearlier versions, Valak did not include the “pluginhost” payload. \r\nPowerShell Activity:\r\nIn older versions of Valak, the second stage JS downloads additional content just like the newer versions,\r\nincluding“TASK” / ”ODTASK” / ”PLUGIN”. In the newer versions, Valak also downloads “PluginHost” in stage\r\none and executes it once receiving the task “PLUGIN” in stage two, which then downloads ManagedPlugin.dll. In\r\nthe older versions, Valak uses the task “PLUGIN” in stage two to leverage PowerShell and download\r\n“ManagedPlugin.dll” as a Base64 binary. \r\nAs mentioned previously, later versions of Valak abandon the popular yet easily detectable PowerShell\r\ndownloader approach and transition to “PluginHost” to manage and download additional payloads. This transition\r\nmay indicate that Valak authors are looking to leverage stealthier approaches and improve their evasion\r\ntechniques.\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 22 of 27\n\nRaw data downloaded from the C2.\r\nDecoded content of the “PLUGIN” task.\r\nValak’s Infrastructure\r\nAnalyzing the different samples reveals a repetitive pattern of URIs used to connect to a “bucket” of domains, all\r\nof which are embedded in the code. \r\nFor example, the URI used to download the “PluginHost” (a.aspx) is always built off: “a.aspx?\r\nredir=1\u0026clientUuid=91\u0026r_ctplGuid=” +\u003cthe encoded_ID\u003e+ “\u0026TS2=” +\u003crandom string\u003e\r\nCreation of the URI in Valak’s source code. \r\nThis URI is not the only similarity across samples; Valak has several URIs that match this behavior across\r\ncomponents. \r\nValak’s Observed URI Patterns:\r\nDLL Download: the DLL URI always includes “aio0i32p”\r\nSecond Stage: the second stage (project.aspx) always includes “?cwdTelemetry=2\u0026regclid=”\r\nTask Fetching: Tasks fetching from the C2 server always include “?dx11diag=”\r\nAdditional Plugins Download: “PluginHost” downloads additional plugins that always include\r\n“db.aspx?llid=”\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 23 of 27\n\nExchgrabber plugin data: the URI to exfiltrate data from the plugin includes “class4.aspx?\r\ninternalService”\r\nAnother interesting aspect of the Valak malware is that it has a shared infrastructure among almost all of it’s\r\ndifferent versions.  As the graph below shows, most of the known domains have a connection between them,\r\nwhether it be the URIs similarities, downloaded files, or connected files.\r\nVirusTotal graph showing the connection between the different Valak domains.\r\nValak’s Relationship With Other Malware\r\nValak infections were initially characterized as rather unilateral, where Valak mainly downloaded other known\r\nmalware like Ursnif or IcedID. However, over the course of this investigation, it became clear that Valak’s\r\nrelationship with other malware is actually multilateral. \r\nFor example, the following network traffic recording provided by malware-traffic-analysis illustrates an infection\r\nchain that is initiated by Ursnif, which downloads IcedID and Valak, both from the same C2 server. \r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 24 of 27\n\nTraffic - Ursnif downloading IcedID and Valak.\r\nWhile the nature of the partnership between each of these specific malware is not fully understood, we suspect it is\r\nbased on personal ties and mutual trust from underground communities. Given the fact that both Ursnif and\r\nIcedID are considered to be part of the Russian-speaking E-Crime ecosystem, it is possible that the authors of\r\nValak are also part of that Russian-speaking underground community. This community is known to keep rather\r\nclose ties based on trust and reputation. \r\nAnother clue that may tie the authors behind Valak to a Russian-speaking community are traces of both Russian\r\nand Arabic (Saudi Arabia) language settings left in the phishing documents. These language traces appear in all\r\nthe samples we analyzed, an example of which is shown below:  \r\nRussian and Arabic keyboard traces found in a Valak phishing\r\ndocument.\r\nIt is important to mention that the above mentioned language traces can be easily manipulated and put there on\r\npurpose by the threat actors, and therefore, it is not enough to determine with certainty the origin of the threat\r\nactors. \r\nValak’s Evolution as an Independent Malware\r\nAlthough initially downloaded as a payload of other malware, in more recent appearances of Valak, the malware\r\nappears to come as a standalone unit in traditional phishing campaigns. \r\nRecent campaigns target two specific geographic locations, including the US and Germany, where the content and\r\nthe name of the files were written in English and German with files masquerading as legitimate. \r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 25 of 27\n\nVirusTotal screenshot with the file names used in the recent campaigns.\r\nContent of the document targeting Germany.\r\nContent of the document targeting the US.\r\nEven though Valak appears to have evolved over time and has infostealer capabilities, it is clear that the threat\r\nactors behind Valak continue to collaborate with other malware like IcedID and and Ursnif to maximize their\r\nrevenue.\r\nConclusion\r\nIn this research, the Cybereason Nocturnus team analyzed the emerging malware Valak. Though Valak first made\r\nits appearance at the end of 2019 and was classified as a malware loader by several security analysts, our\r\ninvestigation shows that Valak is more than a simple loader of malware. It is a sophisticated modular malware\r\npacked with a myriad of reconnaissance and information stealing features. \r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 26 of 27\n\nOver the course of roughly six months, Valak’s developers made tremendous progress and released more than 30\r\ndifferent versions. Each version extended the malware’s capabilities and added evasive techniques to improve its\r\nstealth. Valak has at least six plugin components that enable attackers to obtain sensitive information from its\r\nvictims. \r\nThe extended malware capabilities suggest that Valak can be used independently with or without teaming up with\r\nother malware. That being said, it seems as though the threat actor behind Valak is collaborating with other threat\r\nactors across the E-Crime ecosystem to create an even more dangerous piece of malware.\r\nThese malware campaigns seem to focus on targets in the US and Germany. The Cybereason Nocturnus team will\r\ncontinue to monitor Valak’s progress to determine whether Valak infections will spread to other regions as the\r\nmalware continues to evolve and grow popular among cybercriminals. \r\nIndicators of Compromise\r\nClick here to download this campaign's IOCs (PDF)\r\nClick here to download the threat alert (PDF)\r\nMITRE ATT\u0026CK BREAKDOWN\r\nSource: https://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nhttps://www.cybereason.com/blog/valak-more-than-meets-the-eye\r\nPage 27 of 27\n\nAs of writing This section this report, we have highlights the major seen Valak change differences between tremendously. It is the previous versions currently on version and newer versions number of Valak 24. by\nanalyzing version 6, version 9, version 23, and version 24.\n   Page 21 of 27",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA",
		"MITRE"
	],
	"references": [
		"https://www.cybereason.com/blog/valak-more-than-meets-the-eye"
	],
	"report_names": [
		"valak-more-than-meets-the-eye"
	],
	"threat_actors": [],
	"ts_created_at": 1775434434,
	"ts_updated_at": 1775791287,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9f3f55d939c980c437ae2b66c03baabb117ca65c.pdf",
		"text": "https://archive.orkl.eu/9f3f55d939c980c437ae2b66c03baabb117ca65c.txt",
		"img": "https://archive.orkl.eu/9f3f55d939c980c437ae2b66c03baabb117ca65c.jpg"
	}
}