{
	"id": "7e1479c0-fea3-4ccd-a4ef-4410df24d265",
	"created_at": "2026-04-06T00:14:17.701058Z",
	"updated_at": "2026-04-10T03:20:32.365034Z",
	"deleted_at": null,
	"sha1_hash": "23bac8a59d12a57d84d719ffeef8092a3e9db0be",
	"title": "FormBook - Hiding in plain sight",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 85596,
	"plain_text": "FormBook - Hiding in plain sight\r\nArchived: 2026-04-05 21:29:09 UTC\r\npublished 2019-05-02\r\nIntro\r\nToday I came across the FormBook malware and had a quick look. As is tradition for malware, it uses encrypted\r\nstrings to make it harder to detect. The way FormBook stores its encrypted strings however is new to me.\r\nFormBook itself is not new and the decryption has been documented before and decryption scripts for its\r\nencrypted strings exist.\r\nArbor for example has an article here, and the decryption script which is basically a Python conversion of the code\r\nin FormBook itself can be found here.\r\nUnder the hood\r\nSo what does it look like in the binary?\r\nWhat you see here is an encrypted string blob. The lower part starting with push ebp is the actual string, while\r\nthe top part is used to fetch its address.\r\nAny string FormBook uses is stored in gibberish code blocks like above.\r\nI've analyzed the function processing those code blocks but couldn't identify it at first. I expected some\r\ndecompression/decryption but it looked like nothing I've seen before and it also seemed rather simple (just\r\ncopying memory around basically). The existing script is also just a 1:1 translation of the malware's code into\r\nPython, so that doesn't solve the riddle either.\r\nhttps://usualsuspect.re/article/formbook-hiding-in-plain-sight\r\nPage 1 of 2\n\nThen I had an idea - could it be that the processing code is actually a small disassembly engine? Turns out the\r\nanswer is yes!\r\nWhat FormBook actually is doing is disassembling these gibberish code blocks and extracts operands, which\r\nmake up the \"hidden\" encrypted blob. So the weird transformation functions are part of the disassembly engine.\r\nTo confirm that, I ripped the above blob into a file and ran it through Arbor's script and printed the data before it is\r\nbeing decrypted using RC4, and the output was:\r\n1065ba6b366a83cf14f7aa2bcab6059271710738\r\nThat is, these bytes are what are hidden in the code blob. And if you look closely, you can see the bytes in the\r\nabove disassembly as operands but reversed (little-endian of DWORDs):\r\n1065ba6b -\u003e 0x6BBA6510\r\n366a83cf -\u003e 0xCF836A36\r\n14f7aa2b -\u003e 0x2BAAF714\r\ncab60592 -\u003e 0x9205B6CA\r\n71710738 -\u003e 0x38077171\r\nSo FormBook is literally hiding the encrypted strings in plain sight - as operands for nonsense code blobs and uses\r\na small disassembly engine to retrieve them. Haven't seen this one before, that's a rather creative approach.\r\n(I couldn't find anyone else noticing what's actually going on, so if I missed it, apologies, let me know)\r\nSource: https://usualsuspect.re/article/formbook-hiding-in-plain-sight\r\nhttps://usualsuspect.re/article/formbook-hiding-in-plain-sight\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://usualsuspect.re/article/formbook-hiding-in-plain-sight"
	],
	"report_names": [
		"formbook-hiding-in-plain-sight"
	],
	"threat_actors": [],
	"ts_created_at": 1775434457,
	"ts_updated_at": 1775791232,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/23bac8a59d12a57d84d719ffeef8092a3e9db0be.pdf",
		"text": "https://archive.orkl.eu/23bac8a59d12a57d84d719ffeef8092a3e9db0be.txt",
		"img": "https://archive.orkl.eu/23bac8a59d12a57d84d719ffeef8092a3e9db0be.jpg"
	}
}