{
	"id": "d96eb857-0d51-43da-be08-aeca3cb4859d",
	"created_at": "2026-04-06T00:13:10.460257Z",
	"updated_at": "2026-04-10T03:36:25.294451Z",
	"deleted_at": null,
	"sha1_hash": "8cb1c524ea5e969e49346ba89ba0ac6acaa93332",
	"title": "Hermes ransomware distributed to South Koreans via recent Flash zero-day | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3144202,
	"plain_text": "Hermes ransomware distributed to South Koreans via recent Flash\r\nzero-day | Malwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2018-03-13 · Archived: 2026-04-05 12:47:36 UTC\r\nThis blog post was authored by @hasherezade, Jérôme Segura and Vasilios Hioureas.\r\nAt the end of January, the South Korean Emergency Response Team (KrCERT) published news of a Flash Player\r\nzero-day used in targeted attacks. The flaw, which exists in Flash Player 28.0.0.137 and below, was distributed via\r\nmalicious Office documents containing the embedded Flash exploit. Only a couple of weeks after the public\r\nannouncement, spam campaigns were already beginning to pump out malicious Word documents containing the\r\nnewly available exploit.\r\nWhile spam has been an active distribution channel for some time now, the news of a Flash exploit would most\r\ncertainly interest exploit kit authors as well. Indeed, in our previous blog post about this vulnerability (CVE-2018-\r\n4878), we showed how trivial it was to use an already available Proof-of-Concept and package it as as a drive-by\r\ndownload instead.\r\nOn March 9th, MDNC discovered that a less common, but more sophisticated exploit kit called GreenFlash\r\nSundown had started to use this recent Flash zero-day to distribute the Hermes ransomware. This payload was\r\nformerly used as part of an attack on a Taiwanese bank and suspected to be the work of a North Korean hacking\r\ngroup. According to some reports, it may be a decoy attack and “pseudo-ransomware“.\r\nBy checking on the indicators published by MDNC, we were able to identify this campaign within our telemetry\r\nand noticed that all exploit attempts were made against South Korean users. Based on our records, the first hit\r\nhappened on February 27, 2018, (01:54 UTC) via a compromised Korean website.\r\nWe replayed this attack in our lab and spent a fair amount of time looking for redirection code within the\r\nJavaScript libraries part of the self hosted OpenX server. Instead, we found that it was hiding in the main page’s\r\nsource code.\r\nWe had already pinpointed where the redirection was happening by checking the DOM on the live page, but we\r\nalso confirmed it by decoding the large malicious blurb that went through Base64 and RC4 encoding (we would\r\nlike to thank David Ledbetter for that).\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 1 of 16\n\nHermes ransomware\r\nThe payload from this attack is Hermes ransomware, version 2.1.\r\nBehavioral analysis\r\nThe ransomware copies itself into\r\n%TEMP%\r\nunder the name\r\nsvchosta.exe\r\nand redeploys itself from that location. The initial sample is then deleted.\r\nThe ransomware is not particularly stealthy—some windows pop up during its run. For example, we are asked to\r\nrun a batch script with administrator privileges:\r\nThe authors didn’t bother to deploy any UAC bypass technique, relying only on social engineering for this. The\r\npop-up is deployed in a loop, and by this way it tries to force the user into accepting it. But even if we don’t let the\r\nbatch script be deployed, the main executable proceeds with encryption.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 2 of 16\n\nThe batch script is responsible for removing the shadow copies and other possible backups:\r\nIt is dropped inside C:UsersPublic along with some other files:\r\nThe file “PUBLIC” contains a blob with RSA public key. It is worth noting that this key is unique on each run, so,\r\nthe RSA key pair is generated per victim. Example:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 3 of 16\n\nAnother file is an encrypted block of data named UNIQUE_ID_DO_NOT_REMOVE. It is a blob containing an\r\nencrypted private RSA key, unique for the victim:\r\nAnalyzing the blob header, we find the following information:\r\n0x07 –  PRIVATEKEYBLOB\r\n0x02 – CUR_BLOB_VERSION: 2\r\n0xA400 – ALG_ID: CALG_RSA_KEYX\r\nThe rest of the data is encrypted—at this moment, we can guess that it is encrypted by the RSA public key of the\r\nattackers.\r\nThe same folder also contains a ransom note. When the encryption finished, the ransom note pops up. The note is\r\nin HTML format, named DECRYPT_INFORMATION.html.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 4 of 16\n\nThe interesting fact is that, depending on the campaign, in some of the samples the authors used BitMessage to\r\ncommunicate with victims:\r\nThis method was used in the past by a few other authors, for example in Chimera ransomware, and by the author\r\nof original Petya in his affiliate programs.\r\nEncrypted files don’t have their names changed. Each file is encrypted with a new key—the same plaintext\r\nproduces various ciphertext. The entropy of the encrypted file is high, and no patterns are visible. That suggests\r\nthat some stream cipher or a cipher with chained blocks was used. (The most commonly used in such cases is AES\r\nin CBC mode, but we can be sure only after analyzing the code). Below, you can see a visualization of a BMP file\r\nbefore and after being encrypted by Hermes: \r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 5 of 16\n\nInside each file, after the encrypted content, there is a “HERMES” marker, followed by another blob:\r\nThis time the blob contains an exported session key (0x01 : SIMPLEBLOB) and the algorithm identifier is AES\r\n(0x6611: CALG_AES). We can make an educated guess that it is the AES key for the file, encrypted by the\r\nvictim’s RSA key (from the generated pair).\r\nThe ransomware achieves persistence by dropping a batch script in the Startup folder:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 6 of 16\n\nThe script is simple; its role is just to deploy the dropped ransomware: svchosta.exe.\r\nSo, on each system startup it will make a check for new, unencrypted files and try to encrypt them. That’s why, as\r\nsoon as one discovers that they have been attacked by this ransomware, they should remove the persistence entry\r\nin order to not let the attack repeat itself.\r\nInside the ransomware\r\nExecution flow\r\nAt the beginning of the execution, the ransomware creates a mutex named “tech”:\r\nThe sample is mildly obfuscated, for example, its imports are loaded at runtime. The .data section of the PE file is\r\nalso decrypted during the execution, so, at first we will not see the typical strings.\r\nFirst, the executable begins to dynamically load all its imports via a function at 4023e0:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 7 of 16\n\nIt then checks the registry key for a language code. If Russian, Belarusian, or Ukrainian are found as the system\r\nlanguage, it exits the process (0x419 being Russian, 422 Ukrainian, and 423 Belarusian).\r\nIt then creates two subprocesses – cmd.exe. One that copies itself into directory appdata/local/temp/svchost.exe,\r\nand another that executes the copied file.\r\nIt also generates crypto keys using standard CryoptAquireCOntext libraries, and saves the public key and some\r\nkind of ID into the following files:\r\nC:UsersPublicUNIQUE_ID_DO_NOT_REMOVE\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 8 of 16\n\nC:UsersPublicPUBLIC\r\nAs mentioned earlier, it writes out a script to auto run on startup with contents: start “”\r\n%TEMP%svchosta.exe into the Start menu startup folder. This is quite simple and conspicuous. Since it is\r\nalways running and keeps persistence, it makes sense that it saved out the public key into a file so that it can later\r\nfind that key and continue encrypting using a consistent key throughout all executions.\r\nBelow is the function that calls all of this functionality sequentially, labeled:\r\nIt proceeds to cycle all available drives. If it is CDRom, it will skip it. Inside the function, it goes through all files\r\nand folders on the drive, but skips a few key directories, not limited to Windows, Mozilla, and the recycling bin.\r\nInside of the function labeled recursiveSearch_Encrypt are the checks for key folders and drive type:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 9 of 16\n\nIt then continues on to enumerate netResources and encrypts those files as well. After encryption, it creates\r\nanother bat file called window.bat to delete shadow volume and backup files. Here is its content:\r\nvssadmin Delete Shadows /all /quiet vssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB vssad\r\nIt then creates and executes another bat file called svchostaaexe.bat that cycles through the entire file system\r\nagain to search for and delete all backup files. This is interesting, as we have rarely seen ransomware looking in so\r\nmuch detail for backup files.\r\nThere is no functionality that communicates a decryption key to a C2 server. This means that the\r\nfile UNIQUE_ID_DO_NOT_REMOVE, which contains the unique ID you have to send to the email address,\r\nmust be encrypted by a public key pair that the attackers have pre-generated and retained on their side.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 10 of 16\n\nWe have found that there is a heavy code reuse from the old versions of Hermes with this one. The flow of the\r\ncode looks to be a bit different, but the overall functionality is the same. This is quite clear when comparing the\r\ntwo versions in a disassembler.\r\nBelow are two screenshots: the first from the current version we are analyzing, and the second from the old\r\nversion. You can clearly see that even though the flow and arrangement are a bit different, the functionality\r\nremains mostly the same.\r\nThe new version:\r\nAnd the old version 237eee069c1df7b69cee2cc63dee24e6:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 11 of 16\n\nAttacked targets\r\nThe ransomware attacks the following extensions:\r\n tif php 1cd 7z cd 1cd dbf ai arw txt doc docm docx zip rar xlsx xls xlsb xlsm jpg jpe jpeg bmp db eql sql adp\r\nEncryption\r\nHermes, like many other ransomware, uses AES along with RSA for the encryption. AES is used to encrypt files\r\nwith a random key. RSA is used to protect the random AES key.\r\nThe ransomware uses two RSA key pairs, one being a RSA hardcoded public key for the attackers.\r\nThen, there is a keypair for the victim. It is generated at the beginning of the attack. The private key from this key\r\npair is encrypted by the attackers’ public key and stored in the file UNIQUE_ID_DO_NOT_REMOVE.\r\nWhen the victim sends this file, the attackers can recover the victim’s private key with the help of their own\r\nprivate key. The victim’s public key is stored in PUBLIC in clear text. It is later used to encrypt random AES keys,\r\ngenerated per file.\r\nCryptography is implemented with the help of Windows Crypto API. Function calls are mildly obfuscated, and\r\npointers to the functions are manually loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 12 of 16\n\nEach file processing starts from checking if it was already encrypted. The ransomware uses the saved marker\r\n“HERMES” that we already saw during the behavioral analysis. The marker is stored at the end of the file, before\r\nthe block where the AES key is saved. Its offset is 274 bytes from the end. So, first the file pointer is set at this\r\nposition to make a check of the characters.\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 13 of 16\n\nIf the marker was found, the file is skipped. Otherwise, it is processed further. As we noticed during the behavioral\r\nanalysis, each file is encrypted with a new key. Looking at the code, we can find the responsible function.\r\nUnfortunately for the victims, the authors used the secure function CryptGenKey:\r\nThe used identifier for the algorithm is 0x6610 (CALG_AES_256). That means 256-bit is using AES\r\nencryption. This key is used to encrypt the content of the file. The file is read and encrypted in chunks, with\r\n1,000,000 bytes each.\r\nAt the end, the marker “HERMES” is written and the exported AES key is saved:\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 14 of 16\n\nThe handle to the attacker’s RSA public key is passed, so the function CryptExportKey automatically takes care of\r\nprotecting the AES key. Only the owner of the RSA private key will be able to import it back.\r\nProtection\r\nMalwarebytes users are  protected against this Flash Player exploit. In addition, the ransomware payload was\r\nblocked at zero-hour strictly based on its malicious behaviour.\r\nConclusion\r\nAnother campaign that we know of targeting South Koreans specifically is carried by malvertising\r\nand uses the Magnitude exploit kit, which also delivers ransomware—namely\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 15 of 16\n\nAfter analyzing Hermes, we found it to be a fully functional ransomware. However, we cannot be sure what the\r\nreal motivations of the distributors were. Looking at the full context, we may suspect that it was politically\r\nmotivated rather than a profit-driven attack.\r\nAlthough the infection vector appeared to narrow down to South Korea, the malware itself, unlike Magniber, does\r\nnot specifically target these users. The fact that the ransomware excludes certain countries like Russia or Ukraine\r\ncould tie the development and outsourcing of the malware to these areas or be a false flag. As we know, attribution\r\nis always a complex topic.\r\nIndicators of compromise\r\nDomains involved in campaign:\r\n2018-02-27 (01:54 UTC)\r\nstaradvertsment[.\u003ecom\r\nhunting.bannerexposure[.]info\r\n2018-02-28\r\nstaradvertsment[.]com\r\naccompanied.bannerexposure[.]info\r\n2018-03-01\r\nswitzerland.innovativebanner[.]info\r\n2018-03-07\r\nname.secondadvertisements[.]com\r\n2018-03-08\r\nassessed.secondadvertisements[.]com\r\nmarketing.roadadvertisements[.]com\r\n2018-03-09\r\nbannerssale[.]com\r\naquaadvertisement[.]com\r\ntechnologies.roadadvertisements[.]com\r\nIP addresses:\r\n159.65.131[.]94\r\n207.148.104[.]5\r\nHermes 2.1 ransomware:\r\nA5A0964B1308FDB0AEB8BD5B2A0F306C99997C7C076D66EB3EBCDD68405B1DA2\r\npretty040782@gmail[.]com\r\npretty040782@keemail[.]me\r\nSource: https://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nhttps://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2018/03/hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day/"
	],
	"report_names": [
		"hermes-ransomware-distributed-to-south-koreans-via-recent-flash-zero-day"
	],
	"threat_actors": [
		{
			"id": "f88b16bc-df4b-48e7-ae35-f4117240ff24",
			"created_at": "2022-10-25T15:50:23.556699Z",
			"updated_at": "2026-04-10T02:00:05.312313Z",
			"deleted_at": null,
			"main_name": "Chimera",
			"aliases": [
				"Chimera"
			],
			"source_name": "MITRE:Chimera",
			"tools": [
				"PsExec",
				"esentutl",
				"Mimikatz",
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "3da47784-d268-47eb-9a0d-ce25fdc605c0",
			"created_at": "2025-08-07T02:03:24.692797Z",
			"updated_at": "2026-04-10T02:00:03.72967Z",
			"deleted_at": null,
			"main_name": "BRONZE VAPOR",
			"aliases": [
				"Chimera ",
				"DEV-0039 ",
				"Thorium ",
				"Tumbleweed Typhoon "
			],
			"source_name": "Secureworks:BRONZE VAPOR",
			"tools": [
				"Acehash",
				"CloudDrop",
				"Cobalt Strike",
				"Mimikatz",
				"STOCKPIPE",
				"Sharphound",
				"Watercycle"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "873a6c6f-a4d1-49b3-8142-4a147d4288ef",
			"created_at": "2022-10-25T16:07:23.455744Z",
			"updated_at": "2026-04-10T02:00:04.61281Z",
			"deleted_at": null,
			"main_name": "Chimera",
			"aliases": [
				"Bronze Vapor",
				"G0114",
				"Nuclear Taurus",
				"Operation Skeleton Key",
				"Red Charon",
				"THORIUM",
				"Tumbleweed Typhoon"
			],
			"source_name": "ETDA:Chimera",
			"tools": [
				"Agentemis",
				"Cobalt Strike",
				"CobaltStrike",
				"SkeletonKeyInjector",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434390,
	"ts_updated_at": 1775792185,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8cb1c524ea5e969e49346ba89ba0ac6acaa93332.pdf",
		"text": "https://archive.orkl.eu/8cb1c524ea5e969e49346ba89ba0ac6acaa93332.txt",
		"img": "https://archive.orkl.eu/8cb1c524ea5e969e49346ba89ba0ac6acaa93332.jpg"
	}
}