{
	"id": "5923577d-a9db-4c18-a30d-9de003a46ced",
	"created_at": "2026-04-06T00:16:06.521067Z",
	"updated_at": "2026-04-10T13:12:55.107914Z",
	"deleted_at": null,
	"sha1_hash": "8c81438bf9d998c941bf3fab5efc3735c81138b5",
	"title": "The Formidable FormBook Form Grabber | NETSCOUT",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 416850,
	"plain_text": "The Formidable FormBook Form Grabber | NETSCOUT\r\nArchived: 2026-04-05 16:19:58 UTC\r\nMore and more we’ve been seeing references to a malware family known as FormBook. Per its advertisements it\r\nis an infostealer that steals form data from various web browsers and other applications. It is also a keylogger and\r\ncan take screenshots. The malware code is complicated, busy, and fairly obfuscated--there are no Windows API\r\ncalls or obvious strings. This post will start to explore some of these obfuscations to get a better understanding of\r\nhow FormBook works.\r\nSamples\r\nThe main sample used for this analysis is available on the KernelMode.info forum or on VirusTotal. It is version\r\n2.9 of FormBook. Two other samples are referenced as well:\r\nFormBook 3.0\r\nFormBook 2.6\r\nBuilding Blocks\r\nLet us start with three building blocks that will be used in later sections. First, most of FormBook’s data is stored\r\nencrypted in various locations--we’ll call these “encbufs”. Encbufs vary in size and are referenced with functions\r\nsimilar to this: This is a\r\nshellcoding technique to determine which address a piece of code is running at. In this example, the function will\r\nreturn 0x3380FAC. The encbuf will start two bytes after the returned address—jumping over the pop and retn\r\ninstructions. Every encbuf starts with what looks like a normal x86 function prologue—push ebp; mov ebp, esp—\r\nbut this is trickery. If you continue to disassemble this code, it quickly becomes gibberish: The second and third\r\nbuilding blocks are decryption functions—decrypt_func1 and decrypt_func2 respectively. Decrypt_func1 iterates\r\nthrough the encrypted data and depending on the byte value copies a certain amount of data from certain offsets of\r\nthe encrypted data to the plaintext data. Note: the length value passed to this function is the length of the plaintext.\r\nThe length of the encrypted data isn’t explicitly stated. The other decryption function, decrypt_func2, can be\r\nbroken up into three rounds: subtractions, RC4, and then additions. We’ve implemented both of these functions in\r\na Python class, which can be found on GitHub.\r\nWindows API Calls\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 1 of 8\n\nAll calls to the Windows API are done at run time via function name hashing. The hashing algorithm is CRC32,\r\nthough it is not the CRC32B version as implemented in Python’s binascii.crc32 function. We used the Crc32Bzip2\r\nfunction from the Python module crccheck to generate the correct values. Function names are converted to\r\nlowercase before hashing. For some of the API calls, the hashes are hardcoded into the code. An example would\r\nbe 0xf5d02cd8, which resolves to ExitProcess. A listing of a bunch of Windows API function names and their\r\ncorresponding hashes is available on GitHub. For other calls, the API hash is fetched from an encbuf using a\r\nconvoluted mechanism that can be separated into two steps. First, the encbuf containing the hashes is decrypted.\r\nThis requires two other encbufs, the decryption functions from above, and some SHA1 hashing:\r\nThe second step is specifying an index into the decrypted encbuf and decrypting the hash:\r\nA listing of indexes, hashes, and their corresponding functions is available on GitHub. There are six additional\r\nAPI calls where the hashes are stored in a separate encbuf. We’ll point this encbuf out in another section, but they\r\nmap to the following network related functions:\r\nsocket (0x46a9bfc5)\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 2 of 8\n\nhtons (0xe9cef9bb)\r\nWSAStartup (0xa83c6f74)\r\nsend (0x6e3cd283)\r\nconnect (0x8c9cf4aa)\r\nclosesocket (0x4194fdf)\r\nStrings Strings are obfuscated in two ways. Some of them are built a DWORD at a time on the stack:\r\nThe rest are stored in an encbuf. The strings encbuf is first decrypted using decrypt_func1. The decrypted encbuf\r\ncontains an array of variable length encrypted strings, which can be represented like:\r\nstruct {\r\n BYTE size;\r\n BYTE *encrypted_string[size];\r\n}\r\nA particular string is referenced by an index number and is decrypted using decrypt_func2: A listing of the\r\ndecrypted strings and their indexes are available on GitHub. Command and Control (C2) URLs The C2 URLs\r\nare stored in a “config” encbuf and the mechanism to get at them are convoluted and spread out over multiple\r\nfunctions. The first step of the mechanism is to figure out what process the injected FormBook code is running in.\r\nDepending on the injected process, a C2 index is saved and a 20-byte key is extracted from an encbuf and\r\ndecrypted. Here is the snippet of code for when FormBook is running in explorer.exe:\r\nNext, the config encbuf goes through a series of decryption steps:\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 3 of 8\n\nNote: in the “Windows API Calls” section above we mentioned that six of the hashes were stored in a separate\r\nencbuf. In the screenshot above, we’ve made a comment where this encbuf comes from. The “decrypt_s205”\r\nfunction contains more decryption:\r\nAt this point, the config encbuf is decrypted, but the C2s are still obfuscated. Note that up to six C2s can be\r\nreferenced depending on which process FormBook is running in. The final step is one more round of decryption\r\nusing the process specific key from the first step:\r\nIterating through the possible C2 offsets and keys for the analyzed sample we get:\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 4 of 8\n\nInitially we thought there would be up to six different C2s encrypted with different keys, but it’s just the same C2.\r\nThis was the case for all the other samples we spot-checked as well. Decoy C2 URLs? While reviewing a\r\nsandbox run of a FormBook 3.0 sample, we noticed phone home traffic to multiple C2s:\r\nBut when we extracted the C2s from its config encbuf we got a completely different C2:\r\nDigging further into this, we noticed that starting in this version there were additional encrypted strings. These can\r\nbe seen in this listing on GitHub. In particular starting at index 78 there are 64 seemly random domains (including\r\nthe ones seen in our sandbox run). Tracing these strings in the code we see that 15 of these are randomly selected\r\ninto an array and then one of them is randomly replaced with the C2 from the config encbuf. At a quick glance\r\nthere doesn’t seem to be any overlap of these domains from sample to sample. They all seem to be registered, but\r\nby different entities. Some of them show up in search engines with benign looking data, but most return HTTP\r\n“page not found”s. For now, our theory is that these are randomly chosen decoy C2s. C2 Communications\r\nFormBook uses HTTP—both GETs and POSTs—for C2. An example of the initial phone home looks like this:\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 5 of 8\n\nThe query parameter “id” contains data encrypted with the following process: Unlike other parts of FormBook,\r\nthe generation of the “comms_key” is easy—it boils down to the SHA1 digest of the C2. Using a Python snippet,\r\nthe communications key for the analyzed sample can be generated like this: The “transform_b64_chars” function\r\ndoes the following character transformation:\r\n+ -\u003e -\r\n/ -\u003e _\r\n= -\u003e .\r\nThe encrypted data from above looks like this once decrypted:\r\nFBNG:DDE857B32.9:Microsoft Windows XP x86:QWRtaW4=\r\nIt is mostly “:” delimited and consists of the following fields:\r\nMessage type (FBNG)\r\nBot ID and bot version (missing “:”) (DDE857B3 and 2.9)\r\nWindows version\r\nBase64 encoded username\r\nBased on the leaked C2 panel code (see this KernelMode.info forum thread) there are a few types of phone home\r\nmessages:\r\nKNOCK_POST – the initial phone home as shown above\r\nRESULT_POST – results of a task\r\nIMAGE_POST – screenshot\r\nKEY_POST – key logger logs\r\nForm logger logs\r\nAn example of an IMAGE_POST from another sample (version 2.6) looks like this:\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 6 of 8\n\nThere are three POST parameters:\r\ndat – encrypted data\r\nun – base64 encoded username\r\nbr – web browser identifier\r\nThe encrypted data is decrypted as above (using www[.]wowtracking[.]info/list/hx47/ as the C2 key component)\r\nand the first 100 decrypted bytes look like this:\r\nHere we can see:\r\nMessage type (FBIMG)\r\nBot ID (DDE857B3)\r\nAnd the start of a JPEG file\r\nThe JPEG file shows a screenshot of one of ASERT’s finest sandboxen:\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 7 of 8\n\nConclusion\r\nFormBook is an infostealing malware that we’ve been seeing more and more of recently. This post has been an\r\nanalysis of some of the obfuscations used in the FormBook malware to start getting an understanding of how it\r\nworks. Based on samples in our malware zoo and search engine results, it seems to have gotten its start sometime\r\nin early 2016. With a cheap price tag (a few hundred dollars), general availability (for sale on Hack Forums), and\r\na supposed release of a “cracked builder” there are quite a few FormBook samples and campaigns in the wild and\r\nwe only expect to see more.\r\nSource: https://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nhttps://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.arbornetworks.com/blog/asert/formidable-formbook-form-grabber/"
	],
	"report_names": [
		"formidable-formbook-form-grabber"
	],
	"threat_actors": [],
	"ts_created_at": 1775434566,
	"ts_updated_at": 1775826775,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8c81438bf9d998c941bf3fab5efc3735c81138b5.pdf",
		"text": "https://archive.orkl.eu/8c81438bf9d998c941bf3fab5efc3735c81138b5.txt",
		"img": "https://archive.orkl.eu/8c81438bf9d998c941bf3fab5efc3735c81138b5.jpg"
	}
}