{
	"id": "efa6e292-45f4-4a06-b2ef-de0a737ed592",
	"created_at": "2026-04-06T00:13:14.663278Z",
	"updated_at": "2026-04-10T03:37:08.927249Z",
	"deleted_at": null,
	"sha1_hash": "ea341f61269591b688038f2be760babc606e15e3",
	"title": "Stealc: A new stealer emerges in 2023",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1309635,
	"plain_text": "Stealc: A new stealer emerges in 2023\r\nBy VMRay Labs\r\nPublished: 2023-05-05 · Archived: 2026-04-05 23:42:50 UTC\r\nOverview\r\nA new malware family called Stealc was released recently, which is a Spyware designed to copy files, credentials\r\nand other sensitive information from the victim’s hard drive and make them available to the attacker. It also\r\nemploys a variety of techniques to evade detection, including one technique based on remotely storing a hard\r\ndisk-based hardware ID, which prevents the sample from infecting the same machine twice, and thus avoids\r\nrevealing malicious behavior in any future analysis runs.\r\nIn this blog post, we want to highlight how Stealc, which has been shown to have parallels to other known\r\nmalware families (such as Vidar, Raccoon, Mars and RedLine), steals sensitive data from its victims and how it\r\ntries to evade detection. We have aided our analysis with an in-depth research into how this malware and it’s\r\ntechniques have been implemented.\r\nMalicious Behavior of Stealc\r\nVMRay Platform uses a dynamic analysis method, which means that the malware is actually executed in a virtual\r\nenvironment, where the actions of the malware are recorded and later analyzed to detect malicious behavior.\r\nThese detection rules are known as VMRay Threat Identifiers (VTIs). In our case, they reveal plenty of malicious\r\nbehavior, ranging from capturing screenshots, reading sensitive e-mail and web browser data, to searching for\r\ncryptocurrency wallets (see Figure 1).\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 1 of 12\n\nThe VTIs also provide additional information on what exactly the malware is trying to do if you open one of the\r\nlistings (see Figure 2).\r\nIn this case, the malware tried to find cryptocurrency wallets for Bitcoin, Ethereum and Electrum Bitcoin Wallet.\r\nAdditionally, one of our triggers suggests that large amounts of data are uploaded to a remote server – a good\r\nindicator that some of the information is likely copied to the attacker (see Figure 3).\r\nAll of this behavior leads VMRay Platform to correctly conclude that this must be a malicious executable,\r\nclassified as Spyware.\r\nNow we have a better understanding what kind of information the stealer is collecting, but it is still unclear how\r\nthe information is sent to the attacker.\r\nLet us look into the Network tab, which displays all the recorded network traffic mapped to the associated\r\nWindows API calls that were used to send or receive the data. This is a powerful tool to analyze network traffic –\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 2 of 12\n\ndue to our unique and extensive monitoring approach, we can sometimes even capture communication data before\r\nit becomes encrypted.\r\nStealc network activity\r\nThe Network tab shows some interesting behavior (see Figure 4). We can see that the malicious sample tries to\r\ndownload a set of DLL files.\r\nThese libraries are used by benign popular applications such as web browsers to access and, if required, decrypt\r\nconfidential information belonging to the application itself – Stealc abuses these libraries to collect the same\r\nconfidential information, but with malicious intent (see Table below).\r\nAs an example, let’s take “sqlite3.dll” as shown in Figure 4 above. This library allows Stealc to access a local\r\ndatabase created in the SQLite database engine, which is also the method employed by Mozilla Firefox for storing\r\nuser session cookies. When an attacker obtains a session cookie, they can potentially use it to access the victim’s\r\naccount without needing the second factor of authentication (e.g., a one-time password or a biometric). In essence,\r\nthe attacker bypasses the 2FA mechanism by piggybacking on the authenticated session established by the victim.\r\nAnother use-case for these libraries is decrypting all saved login information, such as usernames, e-mail addresses\r\nand passwords.\r\nStealc does not just use the network connection to download additional DLLs, but also to communicate to a\r\nremote server about what its intended purpose is. The server then responds, for example, with specific filenames\r\nto search for. Analyzing this network behavior becomes easier thanks to one of the best features of our platform\r\nfor malware researchers: the function log (or “flog” for short). This file contains all observed calls to the Windows\r\nAPI chronologically with human-readable function and parameter names. There is a reason why we internally see\r\nthe flog as the malware analysts Swiss Army knife.\r\nIn this case, we find the base64 encoded network communication string in the function log, as well as the decoded\r\nversion, which allows us analyze the communication more in-depth (see Figure 5). In one of the exchanges, for\r\nexample, the C2 server asks our sample to collect information regarding the MetaMask crypto wallet and other\r\nweb browser extensions, mostly related to crypto wallets and password managers.\r\nStealc’s Encrypted Strings\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 3 of 12\n\nNow that we have gathered all behavior-based information, we take a closer look into how the malware is\r\nimplemented. A look at the code gives us a sense that this malware is likely written in C/C++. However, there are\r\nnearly no sensible human-readable strings present.\r\nAs we already know by now that this malware tries to find certain sensitive files, it needs to store file paths and\r\nsearch terms, but the strings associated with that process are nowhere to be found (see Figure 6).\r\nMalware often uses obfuscation and encryption to try and hide important information, for example to evade static\r\nanalysis tools such as antivirus signatures. In the case of Stealc, the strings are stored in an encrypted manner and\r\nare decrypted at runtime during the initialization step of the malware.\r\nWe have analyzed the sample to identify how the encryption takes place – this not only helps us to better\r\nunderstand the inner workings of the malware but also to develop a config extractor later on. Config extractors are\r\ntremendously helpful addition to the VMRay Platform which provides our customers with a malware family\r\nclassification as well as high-quality IOCs by automatically extracting the configuration such as C2 URLs,\r\nencryption keys etc., without requiring manual reverse engineering.\r\nWe have identified the encryption algorithm to be RC4, which matches earlier reports about Stealc, however, we\r\nalso found an issue involving randomly placed null bytes during decryption that all current Stealc decryptors seem\r\nto suffer from. A closer inspection reveals a key difference between how RC4 is usually implemented and how it\r\nis implemented in Stealc, namely that the ciphertext is not XORed with the keystream if it results in a null-byte,\r\ndemonstrated in pseudo-code in Figure 7.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 4 of 12\n\nOne powerful feature is VMRay’s Function Strings, which is a collection of all strings that were passed as an\r\nargument to API calls during the analysis of a process. You can access this log file by going to the Behavior tab,\r\nselecting the relevant process and opening up “Extracted Function Strings” to download the file (see Figure 8).\r\nYARA \u0026 Detection Engineering Tips\r\nAnother use of the function strings, other than helping malware researchers to extract useful information even for\r\npacked samples, is the possibility of writing YARA rules based on these runtime strings.\r\nThis opens up a robust way for detection engineers to identify certain malware families that is more resistant to\r\ncode changes while threat actors continually evolve their software, often evading existing YARA rules. Basing\r\nrules on runtime function strings allows us to write more robust rules.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 5 of 12\n\nAdditionally, obfuscated scripts are challenging to detect as they can change widely from version to version or\r\ndepending on the packer, but runtime strings often reveal unique identifiers or sometimes even the unobfuscated\r\nversion of the script, which allows us to write YARA rules in these difficult cases as well. For Stealc, the function\r\nstrings log indeed reveals the decrypted strings, which were harder to extract before (see Figure 9). Here, we see\r\nthe decrypted configuration, including the expiration date and the URL to the C2 server.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 6 of 12\n\nEvasion and Obfuscation Techniques used by Stealc\r\nWe have been able to observe a number of evasion techniques that Stealc employs to avoid detection by antivirus\r\nand sandboxing technologies. One interesting technique uses a unique hardware identifier to limit a machine to\r\njust a single infection, which could be intended as a evasion techniques on platforms where the hardware ID does\r\nnot change in-between analysis runs. This would limit the detonation to the very first run and avoid revealing\r\nmalicious behavior in future runs.\r\nAdditionally, we have identified common evasion techniques like checking for the size of RAM or refusing to run\r\non machines with certain language settings. In summary, we have found the following evasion and obfuscation\r\ntechniques.\r\nHardware ID check\r\nStealc uses the serial number of the volume on the main hard disk to generate a unique identifier (see Figure 10).\r\nThis hardware ID is sent to the C2 server (see Figure 11), which likely checks if this ID has ever been seen before\r\n(and thus has been infected before already), in which case the sample is terminated.\r\nWhile we do not have access to the server-side code where this logic is implemented, we think there are two likely\r\nexplanations for this behavior, (1) to avoid reinfecting the same machine and collecting duplicate data, and (2), as\r\nan evasion technique for dynamic, behavior based analyzers.\r\nIn the latter case, the first analysis would reveal malicious behavior while any analysis runs in the future on the\r\nsame virtual machine would force the sample to terminate itself – if the volume serial number remained identical\r\nin-between runs and was thus banned.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 7 of 12\n\nSize of RAM\r\nIf the RAM size is smaller than 1GB, the execution is aborted as this is the case for some virtualized environments\r\n(see Figure 12).\r\nLimit to certain languages\r\nStealc does not run on machines where the user language is set to Russian, Ukrainian, Belarusian, Kazakh or\r\nUzbek – as this is hard-coded and does not seem to be up for configuration, this is a choice made by the\r\ndevelopers (Figure 13).\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 8 of 12\n\nAvoid antivirus emulators\r\nThe execution is aborted if the computer name is set to “HAL9TH” and the user name is “JohnDoe”, which is an\r\nindicator that the sample is emulated by the Windows Defender (see Figure 14).\r\nAnother check for antivirus sandboxing is implemented through a call to VirtualAllocExNuma, which is often not\r\nimplemented in emulated environments..\r\nIndirect loading of DLL functions\r\nInstead of importing functions statically, Stealc dynamically traverses the Process Environment Block to import\r\nDLL functions (see Figure 15), which is a well-known technique of dynamically resolving imports to avoid AV\r\ndetection.\r\nEncrypted strings / function names\r\nAs already mentioned earlier, most strings, including function names, are base64 encoded and RC4 encrypted,\r\nwhich are only decrypted at runtime.\r\nAnti-disassembly\r\nStealc uses random bytes and jumps to confuse disassemblers and decompilers, thus impeding manual analysis by\r\nthreat researchers. See the following code snippet where a random byte was placed in the middle of the code,\r\nsurrounded by a jump instruction that would skip this random byte when executed.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 9 of 12\n\nDuring static analysis this would require the disassembler to have a deeper understanding of the code to avoid\r\nbeing fooled, which most static analysis tools do not posses and thus generate invalid code (see Figure 16). We fix\r\nthese by defining the random byte as data and exclude it from being parsed as code, which reveals the correct\r\ndisassembly.\r\nNote that the behavior-based monitoring approach utilized by VMRay Platform is not confused by this as static\r\nanalysis via disassembly is not necessary to detect malicious behavior on our end.\r\nDetecting the new versions of Stealc\r\nWhile researching this malware family, we found a few versions very similar to Stealc but with key differences,\r\nsuggesting that these are likely updated versions. In these cases, the developers removed some of the evasion\r\ntechniques, namely the check for the RAM size (see Figure 12), as well as the detections designed for antivirus\r\nemulators (see Figure 14). Notably, they have also decided to encrypt those few strings that had remained\r\nunencrypted in the original version, probably to avoid strictly YARA based detection methods.\r\nThis also demonstrates our robustness against these kinds of changes as our behavior-based VMRay Platform still\r\nidentifies Stealc as malicious in the newest version.\r\nConfig Extractor\r\nBased on this analysis, we have developed a config extractor which allows customers to peek into the\r\nconfiguration built into the executable by the attacker.\r\nThis enables our customers to upload a sample and get a listing of all the important configuration parameters, such\r\nas remote servers the malware communicates with, the expiration date and the encryption key (see Figure 17). In\r\naddition, the config extractor provides access to high-quality IOCs which can be used to proactively secure\r\nenvironments.\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 10 of 12\n\nConclusion\r\nHere at VMRay, we are always on the look out for malware families that have the potential to become a prominent\r\ntool among threat actors. Detecting these threats early allows us to investigate their behavior and be prepared to\r\nprotect the assets of our customers.\r\nOne of the strength of VMRay Platform is it’s ability to detect new attacks before malware families are known to\r\nresearchers. In this regard, VMRay Platform reveals itself to be a helpful tool: our behavior-based analysis at the\r\ncore of the detection engine can detect malicious behavior before static detection signatures are developed by\r\nthreat researchers – in fact, threat researchers can further benefit from the detailed report on the behavior of the\r\nmalware our product generates, which can be used as a strong, detailed basis to assist additional in-depth manual\r\nanalysis efforts.\r\nIn malware research, one wants to quickly understand what a piece of malware does and how it is accomplished.\r\nIn this post, we have seen how different features of VMRay Platform, such as the VTI’s, the function log, and the\r\nfunction strings allow a very quick but still deep overview of what the core mechanism of the malware is in just a\r\nfew minutes of analysis time.\r\nReferences\r\nhttps://blog.sekoia.io/stealc-a-copycat-of-vidar-and-raccoon-infostealers-gaining-in-popularity-part-1/\r\nhttps://blog.sekoia.io/stealc-a-copycat-of-vidar-and-raccoon-infostealers-gaining-in-popularity-part-2/\r\nhttps://www.bleepingcomputer.com/news/security/new-stealc-malware-emerges-with-a-wide-set-of-stealing-capabilities/\r\nIOCs\r\nHashes:\r\nSample (Jan/Feb 2023)\r\n1e09d04c793205661d88d6993cb3e0ef5e5a37a8660f504c1d36b0d8562e63a2\r\n87f18bd70353e44aa74d3c2fda27a2ae5dd6e7d238c3d875f6240283bc909ba6\r\n77d6f1914af6caf909fa2a246fcec05f500f79dd56e5d0d466d55924695c702d\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 11 of 12\n\nHashes\r\nSample (Mar 2023)\r\ncde2e36ae1fef4bce98792daf14064a5e5027e5e152d653284601a698d98ef3b\r\n464f57bb810e30c1be3765ec17bd268cfa1b4019e9ba9625329669f8385e52ab\r\n4314a53c2c41eb8a57a933a4d1d2e3f29f9b5417074c7a12d081411418928f89\r\nHashes\r\nSample (April 2023)\r\n660f62a2f0eb7ccae6170ec09629ade73d1874486027f22dddd92326a8e0b18e\r\nEmre Güler\r\nThreat Researcher\r\nSource: https://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nhttps://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.vmray.com/cyber-security-blog/stealc-a-new-stealer-emerges-in-2023/"
	],
	"report_names": [
		"stealc-a-new-stealer-emerges-in-2023"
	],
	"threat_actors": [
		{
			"id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df",
			"created_at": "2023-01-06T13:46:38.402513Z",
			"updated_at": "2026-04-10T02:00:02.959797Z",
			"deleted_at": null,
			"main_name": "Sandworm",
			"aliases": [
				"IRIDIUM",
				"Blue Echidna",
				"VOODOO BEAR",
				"FROZENBARENTS",
				"UAC-0113",
				"Seashell Blizzard",
				"UAC-0082",
				"APT44",
				"Quedagh",
				"TEMP.Noble",
				"IRON VIKING",
				"G0034",
				"ELECTRUM",
				"TeleBots"
			],
			"source_name": "MISPGALAXY:Sandworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3a0be4ff-9074-4efd-98e4-47c6a62b14ad",
			"created_at": "2022-10-25T16:07:23.590051Z",
			"updated_at": "2026-04-10T02:00:04.679488Z",
			"deleted_at": null,
			"main_name": "Energetic Bear",
			"aliases": [
				"ATK 6",
				"Blue Kraken",
				"Crouching Yeti",
				"Dragonfly",
				"Electrum",
				"Energetic Bear",
				"G0035",
				"Ghost Blizzard",
				"Group 24",
				"ITG15",
				"Iron Liberty",
				"Koala Team",
				"TG-4192"
			],
			"source_name": "ETDA:Energetic Bear",
			"tools": [
				"Backdoor.Oldrea",
				"CRASHOVERRIDE",
				"Commix",
				"CrackMapExec",
				"CrashOverride",
				"Dirsearch",
				"Dorshel",
				"Fertger",
				"Fuerboos",
				"Goodor",
				"Havex",
				"Havex RAT",
				"Hello EK",
				"Heriplor",
				"Impacket",
				"Industroyer",
				"Karagany",
				"Karagny",
				"LightsOut 2.0",
				"LightsOut EK",
				"Listrix",
				"Oldrea",
				"PEACEPIPE",
				"PHPMailer",
				"PsExec",
				"SMBTrap",
				"Subbrute",
				"Sublist3r",
				"Sysmain",
				"Trojan.Karagany",
				"WSO",
				"Webshell by Orb",
				"Win32/Industroyer",
				"Wpscan",
				"nmap",
				"sqlmap",
				"xFrost"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa",
			"created_at": "2022-10-25T16:47:55.919702Z",
			"updated_at": "2026-04-10T02:00:03.618194Z",
			"deleted_at": null,
			"main_name": "IRON VIKING",
			"aliases": [
				"APT44 ",
				"ATK14 ",
				"BlackEnergy Group",
				"Blue Echidna ",
				"CTG-7263 ",
				"ELECTRUM ",
				"FROZENBARENTS ",
				"Hades/OlympicDestroyer ",
				"IRIDIUM ",
				"Qudedagh ",
				"Sandworm Team ",
				"Seashell Blizzard ",
				"TEMP.Noble ",
				"Telebots ",
				"Voodoo Bear "
			],
			"source_name": "Secureworks:IRON VIKING",
			"tools": [
				"BadRabbit",
				"BlackEnergy",
				"GCat",
				"NotPetya",
				"PSCrypt",
				"TeleBot",
				"TeleDoor",
				"xData"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6",
			"created_at": "2022-10-25T15:50:23.339976Z",
			"updated_at": "2026-04-10T02:00:05.27483Z",
			"deleted_at": null,
			"main_name": "Sandworm Team",
			"aliases": [
				"Sandworm Team",
				"ELECTRUM",
				"Telebots",
				"IRON VIKING",
				"BlackEnergy (Group)",
				"Quedagh",
				"Voodoo Bear",
				"IRIDIUM",
				"Seashell Blizzard",
				"FROZENBARENTS",
				"APT44"
			],
			"source_name": "MITRE:Sandworm Team",
			"tools": [
				"Bad Rabbit",
				"Mimikatz",
				"Exaramel for Linux",
				"Exaramel for Windows",
				"GreyEnergy",
				"PsExec",
				"Prestige",
				"P.A.S. Webshell",
				"AcidPour",
				"VPNFilter",
				"Neo-reGeorg",
				"Cyclops Blink",
				"SDelete",
				"Kapeka",
				"AcidRain",
				"Industroyer",
				"Industroyer2",
				"BlackEnergy",
				"Cobalt Strike",
				"NotPetya",
				"KillDisk",
				"PoshC2",
				"Impacket",
				"Invoke-PSImage",
				"Olympic Destroyer"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434394,
	"ts_updated_at": 1775792228,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea341f61269591b688038f2be760babc606e15e3.pdf",
		"text": "https://archive.orkl.eu/ea341f61269591b688038f2be760babc606e15e3.txt",
		"img": "https://archive.orkl.eu/ea341f61269591b688038f2be760babc606e15e3.jpg"
	}
}