{
	"id": "b854683c-dc02-4b3d-bc2a-e22beaada3f1",
	"created_at": "2026-04-06T00:07:27.500977Z",
	"updated_at": "2026-04-10T13:12:32.099811Z",
	"deleted_at": null,
	"sha1_hash": "ddcd71b66df5be530b8be70cc086ac939e581081",
	"title": "RedEnergy Stealer | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3700392,
	"plain_text": "RedEnergy Stealer | ThreatLabz\r\nBy Shatak Jain, Gurkirat Singh\r\nPublished: 2023-06-21 · Archived: 2026-04-05 22:02:52 UTC\r\nTechnical Analysis\r\nThe RedEnergy malware under investigation exhibits a dual functionality, acting both as a stealer and a\r\nransomware. This .NET file, intentionally obfuscated by its author, possesses advanced capabilities to evade\r\ndetection and hinder analysis. To establish communication with its command and control servers, the malware\r\nutilizes HTTPS, adding an additional layer of encryption and obfuscation.\r\nFig 6. - Infection chain\r\nThe execution of this malware unfolds in three distinct stages, each serving a specific purpose. Each stage is\r\noutlined in the sections below.\r\nStage 1: Initial Startup\r\nUpon execution, the malicious RedEnergy executable masquerades as part of a legitimate browser update,\r\ndepicted in Fig. 7 below. It cleverly disguises itself with a legitimate update from one of the various popular\r\nbrowsers, including Google Chrome, Microsoft Edge, Firefox, and Opera, to deceive the user. Notably, looking at\r\nthe properties of the malicious executable reveals the presence of an invalid certificate, however at surface level\r\nthis attack hides behind a genuine signed certificate from the user’s browser as shown by the Google example\r\nexamined in Fig. 8 below. This deceptive tactic aims to instill trust and convince the victim of the authenticity of\r\nthe update.\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 1 of 9\n\nFig 7. - Google updater executing the malicious RedEnergy binary\r\nFig 8. - Fake certificate\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 2 of 9\n\nStage 2: Dropping Files, Persistence, Outgoing Requests, Encrypted Files\r\nDropping Files:\r\nIn this stage, the malware drops four files onto the victim's system, shown in Fig. 9 below, precisely within the\r\npath %USERPROFILE%\\AppData\\Local\\Temp. These dropped files consist of two temporary files and two\r\nexecutables, all following a similar pattern with filenames beginning with \"tmp\" and four randomly generated\r\nhexadecimal characters, followed by the \".exe\" extension: tmp[4 random hex characters].exe. Among the\r\nexecutable files, one serves as the malicious payload, while the other disguises itself as the legitimate, digitally\r\nsigned Google Update. The benign executable possesses the hash value 8911b376a5cd494b1ac5b84545ed2eb2\r\nand is responsible for performing the actual update of Google Chrome, thereby further deceiving the victim.\r\nSimultaneously, the malware executes another background process, identified by the MD5 hash\r\ncb533957f70b4a7ebb4e8b896b7b656c, which represents the true malicious payload. During execution, this\r\npayload displays an inappropriate message on the victim's screen, displayed in Fig. 10 below, most likely as part\r\nof the threat actor's intent to cause distress or confusion.\r\nFig 9. - Dropping malicious file in temp directory\r\nFig 10. - Display message after executing the binary\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 3 of 9\n\nPersistence:\r\nPersistence is a critical aspect of malware, enabling it to maintain its presence on an infected system even after\r\nrebooting or shutting down. To achieve persistence, the malicious executable stores files in the Windows startup\r\ndirectory. It creates an entry within the start menu (Start Menu\\Programs\\Startup) and initiates an immediate\r\nreboot, ensuring that the malware is executed once the system is up and running again. This persistence\r\nmechanism guarantees that the malware remains active and continues its malicious operations even after system\r\nrestarts.\r\nOutgoing Requests:\r\nDuring the analysis of the malware, researchers utilized Fakenet, a Windows malware analysis tool that simulates\r\nnetwork activity, to gain insights into its behavior. Through Fakenet, they discovered that the malicious tmp.exe\r\nfile established communication with the DNS server 2no.co, depicted in Fig. 11 below. To delve deeper into the\r\nnetwork interactions, the widely used packet analysis tool, Wireshark, was employed. This allowed researchers to\r\nidentify the specific DNS query made by the malicious tmp.exe file, providing crucial information for further\r\ninvestigation, as shown in Fig. 12 below. It was observed that upon establishing a connection with the DNS server,\r\ntmp.exe was expected to initiate the download of an executable file from cdn.discord. Unfortunately, during this\r\nparticular analysis, the Command and Control (CnC) server was unavailable, making it impossible to obtain a\r\nsample. However, another sample resembling the final payload was discovered, which had been hosted on the\r\nsame domain just two days prior to the current analysis.\r\nFig 11. - Malicious binary communication with CnC server\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 4 of 9\n\nFig 12. - Network communication seen via Wireshark\r\nAdditionally, suspicious activity involving File Transfer Protocol (FTP) was uncovered during the investigation. A\r\nuser with the username \"alulogrofp\" successfully accessed a private system hosted by OVH, a renowned cloud\r\ncomputing company and one of the largest hosting providers globally. The user's credentials were authenticated,\r\ngranting them access to a restricted directory, which was identified as the root directory (\"/\"). Notably, UTF-8\r\nencoding was enabled for file transfers, indicating support for international character sets.\r\nFig 13. - FTP interaction on OVH private system\r\nWithin the FTP session, the user navigated to the \"/assets/bootstrap/css\" directory, following standard directory\r\ntraversal practices. To ensure efficient and accurate file transfers, the transfer mode was set to binary (8-bit).\r\nSubsequently, the server entered passive mode and provided an IP address and port number, indicated by the\r\nmessage \"Entering Passive Mode (51,68,11,192,115,132)\". By combining the extracted data, the IP address\r\n51.68.11[.]192 was obtained. Further interactions revealed that the user requested a file list using the \"NLST\"\r\ncommand, resulting in the retrieval of six matching files.\r\nIn another session, the client initiated a file retrieval operation using the \"RETR\" command, specifying the file\r\npath as \"assets/bootstrap/css/SPP\". The server acknowledged the data connection and confirmed the acceptance of\r\nthe file transfer.\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 5 of 9\n\nThese FTP interactions raised concerns regarding potential data exfiltration, as well as the possibility of uploading\r\nfiles using the same method.\r\nEncrypted Files:\r\nWith ransomware modules integrated into the payload, the malware proceeded to encrypt the user's data,\r\nappending the \".FACKOFF!\" extension to each encrypted file, as shown in Fig. 14 below. This malicious software\r\nis specifically designed to lock the user's files, rendering them inaccessible until a ransom is paid. After the\r\nencryption process is completed, the user receives a ransom message, demanding payment in exchange for\r\nrestoring access to their files. Failure to comply with the ransom demands results in the permanent loss of access\r\nto the compromised data.\r\nFurthermore, the malicious executable alters the desktop.ini file, which contains configuration settings for the file\r\nsystem folders. By modifying this file, the malware can manipulate how the file system folders are displayed,\r\npotentially further concealing its presence and activities on the infected system. This alteration serves as an\r\nattempt to mislead the user and impede the detection of the malware's impact on the file system.\r\nFig 14. - Encrypted files with .FACKOFF! extension\r\nStage 3: Decryption Routine\r\nThe final stage payload is responsible for various actions, including dropping the ransom note and executing\r\nmultiple commands and stealer functionalities, and for encryption it uses the RijndaelManaged algorithm. Within\r\nthe payload, numerous functions are named RedEnergy, giving rise to its namesake.\r\nIn the second stage, the malware downloads the executable SystemPropertiesProtection.exe via the discord cdn.\r\nThis leads to the third stage, where the malware executes a series of actions typically associated with ransomware.\r\nIt begins by deleting data from the shadow drive, effectively removing any potential backups. The malware also\r\ntargets Windows backup plans, further hindering the user's ability to recover their data. Additionally, a batch file is\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 6 of 9\n\nexecuted, and a ransom note is dropped, indicating the user's files have been encrypted. Furthermore, the malware\r\npossesses stealer capabilities, allowing it to exfiltrate the user's data.\r\nNotably, the Config method, shown in Fig. 15 below, plays a crucial role in decrypting key information. It stores\r\nimportant strings related to the stealer functionality in a dictionary, depicted in Fig. 16, which is used to construct\r\ncommand lines for further operations.\r\nFig 15. - Config decryption function\r\nFig 16. - Malware showcasing stealer capabilities\r\nOne such decrypted command line, shown in Figure 17, modifies the boot configuration to ignore failures and\r\ndisables the automatic recovery options in Windows. The payload also drops specific files in the Temp directory,\r\nas seen in Figure 18, using it as a camouflage to conceal its malicious intent. Among the files dropped, C.bin\r\nserves as a payload, while a batch file contains commands to terminate processes and perform cleanup tasks\r\nassociated with the payload. Figure 19 illustrates the instructions executed by the batch file.\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 7 of 9\n\nFig 17. - Command line executed post decryption\r\nFig 18. - Dropping supporting files in temp directory\r\nFig 19. - Content inside batch file\r\nFurthermore, the payload is programmed to delete all volume shadow copies (VSS), the backup catalog, and\r\nshadow copies using the Windows Management Instrumentation Command-line (WMIC). The following\r\ncommand lines exemplify this process:\r\nC:\\Windows\\System32\\cmd.exe /C vssadmin delete shadows /all /quiet \u0026 wmic shadowcopy delete\r\nC:\\Windows\\System32\\cmd.exe /C wbadmin delete catalog -quiet\r\nAdditionally, the payload undergoes a three-stage process to gather antivirus (AV) information. Based on this\r\ninformation, it generates a string that it sends to the Command and Control (CnC) server as a User Agent, as\r\ndepicted in Figure 20 below. During the analysis, it was observed that the AV detected is Windows Defender.\r\nSTM, RSM, and RZ likely provide additional information related to Windows Defender.\r\nLastly, the payload is responsible for dropping the final ransom note, read_it.txt, shown in Figure 21. This note is\r\nplaced in all the folders where file encryption occurs, serving as a notification to the user that their files have been\r\nencrypted and demanding a ransom for their release.\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 8 of 9\n\nFig 20. - User Agent built from malicious code storing AV information\r\nFig 21. - Screenshot of the ransom note\r\nSource: https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nhttps://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks\r\nPage 9 of 9\n\n https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks   \nFig 20.-User Agent built from malicious code storing AV information\nFig 21.-Screenshot of the ransom note  \nSource: https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks    \n   Page 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/ransomware-redefined-redenergy-stealer-ransomware-attacks"
	],
	"report_names": [
		"ransomware-redefined-redenergy-stealer-ransomware-attacks"
	],
	"threat_actors": [],
	"ts_created_at": 1775434047,
	"ts_updated_at": 1775826752,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ddcd71b66df5be530b8be70cc086ac939e581081.pdf",
		"text": "https://archive.orkl.eu/ddcd71b66df5be530b8be70cc086ac939e581081.txt",
		"img": "https://archive.orkl.eu/ddcd71b66df5be530b8be70cc086ac939e581081.jpg"
	}
}