{
	"id": "8cc674a0-9dcc-4037-8688-d431650fc34c",
	"created_at": "2026-04-06T00:22:19.468459Z",
	"updated_at": "2026-04-10T03:21:13.543458Z",
	"deleted_at": null,
	"sha1_hash": "cb9f809040ce5fa50762fe37d45230ca8ab5aa5a",
	"title": "Formbook Research Hints Large Data Theft Attack Brewing",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 109190,
	"plain_text": "Formbook Research Hints Large Data Theft Attack Brewing\r\nBy sharon\r\nPublished: 2019-06-12 · Archived: 2026-04-05 17:28:16 UTC\r\nIn this blog post we will present the latest droppers of Formbook data stealing malware – an advanced malware\r\nthat uses diverse and innovative techniques to evade security products. We will reverse engineer all the different\r\ndroppers and suggest ways to detect them. We also show how Cyberbit EDR detects the latest Formbook dropper.\r\nFormbook is a data stealing malware which is capable of stealing data from web browsers and many other\r\napplications. Formbook has been for sale on underground hacking forums since early 2016.\r\nFormbook data stealing malware capabilities include:\r\n• Keystroke logging\r\n• Clipboard monitoring\r\n• HTTP/HTTPS/SPDY/HTTP2 form and network request grabbing\r\n• Browser and email client password grabbing\r\n• Capturing screenshots\r\n• Bot updating\r\n• Downloading and executing files\r\n• Bot removing\r\n• Launching commands via ShellExecute\r\n• Clear browser cookies\r\n• Reboot the system\r\n• Shutdown the system\r\n• Download and unpack ZIP archive\r\nRecently, we came across a new sample of Formbook and dissected it. We noticed that its dropper was different\r\nfrom other Formbook samples we encountered.\r\nWe dived deeper into the Formbook samples and in particularly – their droppers.\r\nA dropper is a malware file whose purpose is to install malware on the system. It may also achieve persistence for\r\nmalware or perform other malicious activities.\r\nThe dropper is used in the initial infection stage and is not usually involved in the final damage inflicting stage of\r\nthe malware.\r\nTo hide the malware within them, the droppers usually use packers, encryptions and obfuscations on the\r\nmalware’s final payload. The final payload might come as PE or shellcode.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 1 of 16\n\nWe discovered substantial variation among the new Formbook droppers. They are written in several programming\r\nlanguages and use numerous packers and anti-analysis techniques. This is done to avoid signature based anti-malware products from detecting it. The final, non-encrypted and non-obfuscated payload of Formbook data\r\nstealing malware never resides on the disk, only in the memory and therefore makes detection much more\r\ndifficult.\r\nLet’s reverse engineer the new Formbook droppers and share meaningful insights about them.\r\nAt the end of this post, you will find a summary and suggestions for detecting the droppers. You will also see how\r\nCyberbit EDR detects the latest dropper.\r\nWe analyzed the samples uploaded to Malpedia, along with a new sample we found in the Cyberbit Malware Lab.\r\nFormbook Data Stealing Malware Research Summary\r\nSample\r\n#\r\nLanguage Packed Anti-Analysis\r\n1\r\nVisual\r\nBasic\r\nNo Encryptions, Obfuscations\r\n2\r\nVisual\r\nBasic\r\nNo Encryptions\r\n3\r\nVisual\r\nBasic\r\nNo\r\nAnti-Debug, Encryptions, Anti-Sandbox, Anti-Memory\r\nAnalysis\r\n4\r\nVisual\r\nBasic\r\nNo\r\nAnti-Debug, Encryptions, Anti-Sandbox, Anti-Memory\r\nAnalysis\r\n5 c++ NSIS installer Encryptions, Anti-Sandbox\r\n6 C# Yes\r\nEncryptions, Obfuscations, Anti-Sandbox, Anti-Debug,\r\nRunning processes/Loaded modules checks\r\n7 C# yes,with Confuser Encryptions, Obfuscations\r\n8 AutoIt\r\nHeavily obfuscated\r\nAutoIt Script\r\nEncryptions, Obfuscations, Running processes checks\r\n9 Delphi No\r\nEncryptions, Filename checks, Running processes\r\nchecks, Anti-Debug, Anti-Sandbox\r\n10 Delphi Yes, with ASProtect Encryptions, Anti-Sandbox\r\nFormbook samples analysis – droppers\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 2 of 16\n\nMost Formbook droppers operate in a typical way: when executed, they perform process hollowing. The\r\nfile chosen for the hollowed process is usually the sample itself. The code unpacked in the hollowed\r\nprocess is the final Formbook payload.\r\nWhen stating that a sample is packed, we mean the first PE file is packed with some packer (e.g:\r\nASProtect, Confuser, etc…). Of course, during execution more code may be unpacked in memory.\r\nWe analyze each sample until the point that the final Formbook malware payload is unpacked.\r\nLearn more about Cyberbit EDR Kernel-Based Endpoint Detection vs. Whitelisting\r\nFormbook Sample 1\r\nSHA256: 2b78b42a1f3c58cabd984935a76b0e9c57934adf80b719eb499f4dd328c09f69\r\nAnti-Analysis: Encryptions, Obfuscations\r\nPacked: No\r\nProcess Hollowing: No\r\nProgramming language: Visual Basic\r\nHighlight: Use of mshta.exe to execute vbscript for persistence\r\nThis is the newest Formbook sample we found.\r\nIn contrary to many other samples of Formbook, the main sample doesn’t unpack itself to another process.\r\nInstead, it drops a file called “Rhododendrons8.exe” and creates two processes: one is mshta.exe running this\r\nvisual basic script:\r\nFormbook-script-capture\r\nFormbook-1\r\nFigure 1 – ShellExecuteA with mshta.exe and the vbscript (truncated)\r\nmshta.exe (Microsoft HTML Application Host) is a Windows utility for executing HTML application files. It can\r\nalso run Visual Basic scripts.\r\nThe script is simple and adds the dropped copy of the malware to registry autorun key, so it will execute as\r\nWindows starts.\r\n Notice the simple obfuscation: Instead of writing “CreateObject”, “CrXXteObject” is written and “XX” is later\r\nreplaced with “ea”. This is done to prevent signature-based tools from detecting this method being in this script.\r\n It is the first and currently only sample of Formbook data stealing malware we observed that achieves persistency\r\nvia this method.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 3 of 16\n\nThe second process created is the dropped “Rhododendrons8.exe.”   This file unpacks the Formbook payload in its\r\nmemory.\r\nRhododendron is a genus of 1,024  species of woody plants in the heath family (Ericaceae). Quite an unusual\r\nname for a malware!\r\nFormbook Malware Rhododendron\r\nFigure 2 – A Rhododendron\r\nFormbook’s payload lies encrypted at address 0x00402c34 within the code section of Rhododendrons8.exe and is\r\ndecrypted using two algorithms. The first algorithm is proprietary, the second is RC4 with a 256-bytes key.\r\nRC4 is a symmetric stream cipher that is a favorite among malware authors. It is simple to implement, doesn’t\r\nrequire any external libraries, and can be written easily even in x86 assembly.\r\nThere are 3 stages for generating the stream cipher that is used encrypt or decrypt the data:\r\n1. Initialize the S-box (256 bytes array with values 0x00-0xFF)\r\n2. Scramble the S-box (byte-swapping)\r\n3. Generate the key stream using the S-box and decrypt/encrypt the data\r\n The three stages can be seen in Figure 5. You can read here in detail about this algorithm and its implementation\r\nin malware.\r\nBelow are screenshots of the decryption process:\r\n3-Encrypted-Formbook\r\nFigure 3 – Encrypted Formbook payload before first round decryption\r\nFormbook decryption algorithm using XOR operations with other data\r\nFigure 4 – First decryption algorithm using XOR operations with other data\r\nFormbook Payload after 1st round of decryption\r\nFigure 5 – Payload after 1st round of decryption\r\n6-Formbook-RC4-algorithm-is-used-to-decrypt-the-code-after-the-1st-algorithm-was-executed\r\nFigure 6 – RC4 algorithm is used to decrypt the code after the 1st algorithm was executed\r\n7-Formbook-1\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 4 of 16\n\nFigure 7 – Things looks better after RC4. The MZ header will be copied later.\r\nThe final Formbook payload performs injection to explorer.exe. Formbook’s injection is rather sophisticated and\r\nuses direct system calls to patch Explorer’s memory in an elegant way. It was researched in depth by Remi Jullian.\r\nThe payload unpacked by the dropper has only a .text section (code) and looks like this in an initial analysis with\r\nPE-Bear:\r\n8\r\nFigure 8 – Formbook’s unpacked payload\r\nThis is the actual Formbook payload, and we will see this payload in all the following samples as well.\r\nFormbook Sample 2\r\nSHA256: 5c0b2944e674ce0e31c7d119e922fdc3dfb1b5c98ec660234369469bb3bbaa19\r\nAnti-Analysis: Encryptions\r\nPacked: No\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: Visual Basic\r\nHighlight: Unlike sample 1, it doesn’t drop another executable\r\nThis sample performs process hollowing with the chosen file as the sample itself and unpacks the final Formbook\r\npayload in the hollowed process. The decryption is similar to sample 1 (same algorithm + RC4). Unlike sample 1,\r\nthe main sample doesn’t drop another executable.\r\nAs usual, the final payload contains a .text (code) section only. Compare figures 9 and 8 to see how similar they\r\nlook.\r\n9\r\nFigure 9 – Formbook’s unpacked payload – similar to figure 8\r\nFormbook Sample 3\r\nSHA256: 11ded4e6d3d40463109a935d00da53627b47b01ff323c206e7f715ce97509ccc\r\n(Similar to: 578e7858d8587fe251790e2386d334862ed8b5b5aaa6520a22b5da9bf7f3d3fb)\r\nAnti-Analysis: Encryptions, Anti-Debug (PEB checks) Anti-Sandbox (User Interaction, Time acceleration, API\r\nchecks), Anti-Memory analysis, Anti-VM (MMX check)\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 5 of 16\n\nPacked: No\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: Visual Basic\r\nHighlight: A technique for evading detection of reflectively-loaded modules\r\nThis sample performs process hollowing with the chosen file as the sample itself and unpacks the final Formbook\r\npayload in the hollowed process.\r\nAnti-Debug techniques\r\nThis sample checks for the presence of debugger using two different checks. If one of the checks returns true – it\r\njumps to address 0x1342EB5 (see explanation later)\r\nCheck the second byte of the PEB structure (BeingDebugged)\r\n10\r\nFigure 10 – Checking the 2nd byte of the PEB structure (eax = 0)\r\nCheck the NtGlobalFlag of the PEB structure. If the process is being debugged, this byte is set to 0x70\r\n11\r\nFigure 11 – Check the NtGlobalFlag in the PEB structure\r\nAnti-Sandbox \u0026 Anti-VM Techniques\r\nThis sample has a User-Interaction check that checks the position of the mouse cursor using the GetCursorPos\r\nmethod. If the mouse cursor doesn’t change its position during an interval of 1 millisecond, the malware will keep\r\nrunning in a loop.\r\n12\r\nFigure 12 – Call GetCursorPo to get the mouse cursor position, sleep for 1 millisecond and check it\r\nagain. If eax = 0, the positions are equal and the malware will jump back to the sleep instruction.  It\r\nwill repeat this process until the mouse position changes.\r\nThis sample uses an Anti-VM trick – it checks if the CPU of the machine is able to run MMX instructions – that\r\nare usually not supported in virtual machines.\r\nTo retrieve the information about the CPU features, such as MMX instructions capabilities. The malware executes\r\nthe following code:\r\n13\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 6 of 16\n\nFigure 13 – Check if the CPU has MMX instructions set\r\n1. It calls the cpuid instruction with the value “1” in the EAX register. Executing cpuid this way will fill the\r\nEDX register with features information about the processor.\r\n2. It moves the data in the EDX register to the EAX register\r\n3. It shifts the EAX register to the right 0x17 (23 in decimal) times, so the 23 bit (counting from the right)\r\nwill be the LSB (least significant bit) in EAX\r\n4. It performs “AND” operation on the EAX register with the value “1”\r\n5. If the MMX bit is not set, EAX will be 0 and the program will jump address 0x1342EB5 – the same as in\r\nthe Anti-Debug checks.\r\nAnother nasty trick in this Formbook dropper can actually defeat plugins such as ScyllaHide. Let’s have a look at\r\nit:\r\n14\r\nFigure 14 – Check for time acceleration\r\nIt calls GetTickCount – which returns the milliseconds elapsed since the system was started. let’s call this result X.\r\nIt sleeps for 2 seconds and then calls it again – let’s call this result Y. Then, it calculates Y-X and check if it’s \u003c 1.5\r\nseconds. We would expect Y – X to be around 2 seconds. This way, the malware “kills two birds with one stone.”\r\nHere is why: Sandboxes usually hook the Sleep function for time acceleration. For example: if a malware tries to\r\ncall sleep with 30 seconds, it can be reduced to 1 second by the hooked function.\r\nGetTickCount may also be hooked by sandboxes.  Virtual machines have naturally lower GetTickCount result,\r\nbecause they were started a few minutes earlier. The sandbox may hook GetTickCount and return a result\r\nreasonable for a normal PC: a few hours or few days.\r\nThe problem however, is that if the sandbox hooks GetTickCount or Sleep, you can still compare the time\r\ndifferences and know if the time was accelerated or slowed down.\r\nNot only sandboxes hook these functions – also plugins such as ScyllaHide.\r\nNaturally, we apply Anti-Anti-Debug plugins when debugging malware, but in this case, it will only ruin our\r\ndebugging process. Let’s see how:\r\nWhen applying ScylleHide plugin with “GetTickCount” hook, we got X = 0x010A0B3D = 17435453\r\nmilliseconds which is about 4.84 hours. A reasonable time for a machine to be up.\r\nOn the second call to GetTickCount, we got Y = 0x010A0B3E = 17435454 – Just 1 millisecond longer, and that’s\r\nafter 2 seconds of sleep! Of course, this doesn’t make sense and the malware is “smart” enough to detect it.\r\nNow, look what happens if this test fails, assuming ScyllaHide’s GetTickCount hook is on: it jumps to address\r\n0x134022E (see figure 14). In the earlier Anti-Analysis checks (MMX, Anti-Debug) we saw it jumps to\r\n0x1342EB5. So, we a have different address this time. First, let’s look at 0x1342EB5:\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 7 of 16\n\n15\r\nFigure 15 – This is where the dropper jumps if it detected a debugger was being used or the CPU\r\nhas no MMX instruction set\r\nIt looks like junk code. The first instruction, stosb, already causes an exception, because it tries to copy the value\r\nat EAX to the address at the EDI register, but the address at the EDI register is located within a range of pages that\r\ndoesn’t have write permissions. So, in this case we were directly stopped from being able to debug the program.\r\nLet’s look at 0x134022E, specifically at its first instruction. We know EAX = 1 because the difference between the\r\ntwo GetTickCounts calls is 1 millisecond.\r\n16\r\nFigure 16  – ss:[ebp+C] = EAX = 1. This will revenge us later\r\nThe execution continues as usual, but we will be punished later!\r\n17\r\nFigure 17 – if ss:[ebp+C] = 1, the rep movsb instruction will fail\r\nLater in the execution, the value at ss:[ebp+C] is moved to the EDI register. Then, 0x400 is added and “rep\r\nmovsb” (copy ECX number of bytes from the address at ESI to the address at EDI) instruction is executed, but\r\nsince 0x401 is not a valid address, it will fail.\r\nLastly, as an Anti-Sandbox technique, it checks if the SetErrorMode and SetLastError APIs work as expected:\r\nIt calls SetErrorMode(0x800) and then SetErrorMode(0x0), then it checks the return value of the latter call.\r\nIt should be 0x800 because the return value of SetErrorMode is the value of the older error mode. If it\r\ndoesn’t, it jumps to address 0x134022E (see figure 16).\r\n18\r\nFigure 18 – Check if SetErrorMode API works as expected\r\nIt calls SetLastError(5) and checks in the TEB that the Last error number (located at (fs:[34]) is indeed 5\r\n19\r\nFigure 19 – Check if SetLastError API works as expected\r\nWe didn’t witness the RC4 algorithm like in the previous VB samples, only proprietary decryption algorithms.\r\nThis sample has another nice trick to avoid memory analysis – it first writes the Formbook payload to the\r\nsuspended process without the “M” of its “MZ” header. It writes the “M” in a separate call.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 8 of 16\n\nThis trick is employed to avoid detection of reflective loading – since detection of newly loaded executables\r\nmodules can be done by their magic number – “MZ” at their beginning offset in memory.\r\nWhen scanning this memory region for the first time, the scanner will not identify this is a reflective loaded\r\nmodule – because it misses the “M”.\r\n20\r\nFigure 20 – Where is ‘M’?\r\nThe unpacked payload looks similar to the one in samples 1 \u0026 2 – and will be similar in all the following samples\r\nas well.\r\nFormbook Sample 4\r\nSHA256:\r\nca4b45af726967f5199f60c15cf518eeba09991164b95cc171ecfea3cb0d6f5b\r\nAnti-Analysis: Same as in sample 3\r\nPacked: No\r\nProcess Hollowing: Injection – with the chosen file as the sample itself, but without hollowing.\r\nProgramming language: Visual Basic\r\nHighlight: Code injection without hollowing\r\nThis sample is similar to sample 3 in its Anti-Analysis techniques.\r\nIt performs injection to a remote process with the chosen file as the sample itself. In this case, the dropper does not\r\nhollow the original content of the file from the remote process (which means it doesn’t call\r\nNtUnmapViewOfSection on the main executable module) – but overwrites its code section.\r\nThe fewer API calls used for injection – the better – as anti-malware products rely heavily on hooks to detect\r\nsuspicious activities.\r\nSince the original dropper module is not unmapped from the targeted process and Formbook’s final payload is\r\nsmaller than the dropper’s code – We can see part of the code of the original dropper still present in the unpacked\r\npayload:\r\n21\r\nFigure 21 – On the left side – the dropper’s code section. On the right – the unpacked code replaced\r\nit on the injected process\r\n22\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 9 of 16\n\nFigure 22 – The smaller unpacked code didn’t overwrite the rest of the dropper, hence the rest of the\r\ncode remains the same (left file – original sample, the dropper. right file – dump of the injected\r\nprocess)\r\nFormbook Sample 5\r\nSHA256:\r\n2ad57fe2d71e246028891018476dd3d0ddbbd7d39db8056b17d2b2aaf69bfd45\r\nAnti-Analysis: Encryptions, Anti-Sandbox (User-Interaction)\r\nPacked: NSIS installer\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: C++\r\nHighlight: Leveraging NSIS installer to execute the dropper\r\nThis sample comes packed in an NSIS (Nullsoft Scriptable Install System) installer and is written in C++.\r\nUnzipping the .exe with 7-zip, reveals 2 folders: $PLUGINSDIR and $TEMP. $PLUGINSDIR contains a file\r\ncalled System.dll which is a plugin for NSIS used to call functions inside third-party DLLs. $TEMP contains some\r\nimages, probably to disguise the real intent of the executable, a .css file and two other files – Pym.dll (written in\r\nC++) and Marestail.bin. Marestail.bin contains Formbook’sfinal payload – and it is encrypted.\r\n23\r\nFigure 23 – Pym.dll and Marestail.bin in $TEMP\r\nWhen the sample is executed, System.dll is loaded and its “Call” function is used to load and execute the\r\nDLLMain of Pym.dll\r\n24\r\nFigure 24 – The call to System.dll “Call”. The value 2ad5.40B858 contains a pointer to an address\r\nthat has the path to Pym.dll\r\nOnce Pym.dll is executed – it reads and decrypts Marestail.bin to unveil Formbook’s payload. Then, the decrypted\r\npayload is injected to a hollowed process. Again, the file chosen for hollowing is the sample itself.\r\n25\r\nFigure 25 – Part of the decryption code from Pym.dll that decrypts Marestail.bin, using XOR\r\noperation.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 10 of 16\n\n26\r\nFigure 26 – After the code above is executed, the MZ header of Formbook’s payload can be easily\r\nspotted\r\nPym.dll uses a simple Anti-Sandbox technique (User Interaction). It checks if the mouse cursor had moved during\r\na short time interval (50 milliseconds) or if 6 minutes and 30 seconds had passed without any mouse movement; a\r\ntime interval long enough to evade most sandbox timeouts. Only if at least one of these conditions is met – it\r\ncontinues its execution.\r\n27\r\nFigure 27 – The Anti-Sandbox technique used in Pym.dll\r\nFormbook Sample 6\r\nSHA256:\r\n8c6f2ebfffd5afdc10e18e13b579ed5dd3ffb8bfc3362062465fa36f60954dd8\r\nAnti-Analysis: Encryptions, Obfuscations, Anti-Debug, Running processes checks, Loaded modules check, Anti-Emulation\r\nPacked: Yes\r\nProcess Hollowing: Yes – with chosen file as Microsoft’s svchost.exe\r\nProgramming language: C#\r\nHighlight: Anti-Emulation (check for time acceleration), file chosen for process hollowing is Microsoft’s\r\nsvchost.exe\r\nThis sample is written in C#. It is obfuscated and contains a lot of functions with random looking names. It has an\r\nencrypted resource that is decrypted and then executed.\r\n28\r\nFigure 28 – A resource is decrypted using the “fukam” function\r\nThe decrypted resource is another C# program. It has some Anti-Analysis checks. It checks the following\r\nconditions and if at least one of them is true, it terminates the process.\r\nWireshark is running – by checking all Windows titles for a window with the title “The Wireshark\r\nNetwork Analyze”\r\nThe process is being debugged – by calling IsDebuggerPresent\r\nCheck for time acceleration – Call GetTickCount, sleep for 500 milliseconds, call GetTickCount again\r\nand check if the difference between the GetTickCount calls is smaller than 500 milliseconds. This can\r\nindicate hooking of Sleep/GetTickCount APIs (See sample 3)\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 11 of 16\n\nSandboxie (sandbox product) module is loaded – By checking if GetModuleHandle(“SbieDll.dll”)\r\nreturns a non-null value\r\nIf none of the checks above return true, it decrypts a DLL from its resource that achieves persistence for the\r\nsample:\r\nIts drops the original sample to:\r\n%USERPROFILE%\\AppData\\Roaming\\SYRPSVT\\SYRPSVT.exe\r\nAnd an .xml file to:\r\n%USERPROFILE%\\AppData\\Roaming\\SYRPSVT\\$X.xml\r\nAnd creates a scheduled task using this command:\r\n“C:\\Windows\\System32\\schtasks.exe” /Create /TN “SYRPSVT\\SYRPSVT” /XML\r\n“%USERPROFILE%\\AppData\\Roaming\\SYRPSVT\\$X.xml”\r\nWhere $X = ‘a’ + five times the same random_char, where random_char in A-Z,a-z,_,0-9 (e.g: abbbbb.xml)\r\nThis DLL also injects the final Formbook payload (also lies encrypted in the resource section) into a hollowed\r\nMicrosoft svchost.exe process.\r\n29\r\nFigure 29- the ecrypted resource. The array “bytes” contain both a DLL (named RunLib) and\r\nFormbook payload. “okapise” is the function responsible for maintaining persistence. “Inj” is the\r\nfunction responsible for injecting into the hollowed svchost.exe\r\nFormbook Sample 7\r\nSHA256:\r\n148b7cae0915f50537cf6752b45ac117a92a9d59aaff46518965e56e4f4de542\r\nAnti-Analysis: Encryptions, Obfuscations\r\nPacked: With “Confuser” packer\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: C#\r\nHighlight: Usage of a less-common API in process hollowing (NtAlertResumeThread)\r\nAnother sample written in C#. This one is packed with Confuser 1.9.0.0.\r\nUnpacking and looking at the unpacked sample – reveals the injection method, which is slightly different than in\r\nother samples.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 12 of 16\n\nOne of the stages in process hollowing technique is resuming the main thread of the suspended process, after it\r\nhas been filled with a new code. The usual API call which is used for this operation is ResumeThread.\r\nIn this case, the malware chooses a less common API –NtAlertResumeThread.  This API performs same operation\r\nas ResumeThread but also alerts the thread so that is returns immediately from the wait with status\r\nSTATUS_ALERTED\r\n30-Formbook\r\nFigure 29 – A snippet from the unpacked C# code shows which APIs are used for the injection\r\nThis was probably done to avoid being detected by a hook on the more common ResumeThread. The file chosen\r\nfor hollowing is again the sample itself.\r\nFormbook Sample 8\r\nSHA256: ce87c1d3d6c13090f1ff62725338786d6b7df1423f01e35f78ccb69ed2abd965\r\nAnti-Analysis: Encryptions, Obfuscations\r\nPacked: Compiled obfuscated AutoIt script\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: AutoIt scripting language\r\nHighlight: Scanning for presence of specific anti-malware products\r\nThis is a compiled AutoIt script which is heavily obfuscated that contains Formbook’s encrypted payload. It\r\nchecks for the existence of processes Anti-Virus vendor processes (figure 32) – avastui.exe (Avast), ekrn.exe\r\n(ESET NOD32) and seccenter.exe (BitDefender). However – it doesn’t try to terminate them. It nevertheless\r\nperforms process hollowing with the upper level APIs (VirtualAllocEx, WriteProcessMemory…) and again the\r\nchosen file for the hollowing is the sample itself.\r\n31-Formbook\r\nFigure 30 – Snippet of the AutoIt script\r\n32-Formbook\r\nFigure 31 – Checking if avastui.exe is running\r\nFormbook Sample 9\r\nSHA256:\r\ne2385a399f96a24f98bdeaee0c4a9f6b3e11a61c64d52f55c80ae37a171eac3b\r\nAnti-Analysis: Encryptions, Anti-Sandbox (User interaction), Check for suspicious file names and running\r\nprocesses, Anti-Debug\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 13 of 16\n\nPacked: No\r\nProcess Hollowing: Yes – with chosen file as the sample itself\r\nProgramming language: Delphi\r\nHighlight: Check the file path for specific names as part of anti-analysis\r\nThis sample copies itself to a file named “essentialize.exe” and executes it.\r\nThe newly executed process “essentialize.exe” performs process hollowing with the chosen file as itself to unpack\r\nFormbook’s payload. Its injection technique to the hollowed process is slightly different. Instead of using\r\nVirtualAllocEx + WriteProcessMemory, it uses NtCreateSection + NtMapViewOfSection to the remote process.\r\nThis sample also has a lot Anti-Analysis techniques – it won’t execute essentialize.exe if one of them returns true:\r\nCheck if the cursor was moved during a time interval using GetCursorPos (appeared in previous samples as\r\nwell)\r\nCheck if the file path contains one of these strings: self. , virus, sample, malware, sandbox\r\n33-Formbook\r\nFigure 33 – Anti-Analysis checks by file name\r\nCheck if one of the following processes is running: windbg.exe, procexp.exe, ollydbg.exe, procmon.exe,\r\nprocmon64.exe, procexp64.exe (favorite programs among malware researchers)\r\n34-Formbook\r\nFigure 34 – Anti-Analysis check of selected processes\r\nThree Anti-Debug checks:\r\nChecking for the BeingDebugged flag in the PEB (assembly equivalent of IsDebuggerPresent)\r\nFormbook second byte of PEB is being checked\r\nFigure 35 – ecx = 0x30, the second byte of the PEB is being checked (BeingDebugged)\r\nCalling NtQueryInformationProcess with ProcessInformationClass = 0x1F (ProcessDebugFlags)\r\nCalling NtQueryInformationProcess with ProcessInformationClass = 0x1E (ProcessDebugObjectHandle)\r\nHave a look here If you are interested  to learn more about the last two Anti-Debug techniques, which are a bit less\r\ncommon than the first one.\r\nThe Anti-Analysis checks are performed both in the original sample and the executed “essentialize.exe” process\r\nFormbook Sample 10\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 14 of 16\n\nSHA256:\r\nec74927626eb9a06871380633fbcd296994c9975847826211165225376005e41\r\nAnti-Analysis: Encryptions, Sleep\r\nPacked: Yes – with ASProtect\r\nProcess Hollowing: No\r\nProgramming language: Delphi\r\nHighlight: No use of process hollowing\r\nThis sample is packed with ASProtect. Unpacking reveals that like Formbook sample 9, it was also written in\r\nDelphi.\r\nContrary to the other droppers, it doesn’t perform process hollowing or drop another executable. It simply\r\ndecrypts Formbook’s payload from its resource section and executes it. Removing the ASProtect protection, the\r\nresource section is revealed to us, it is encoded in base64:\r\n36-Formbook\r\nFigure 36 – A base64-encoded resource “DVCLAL” is extracted and contains Formbook’s final\r\npayload\r\nIt also delays execution by calling Sleep, but only for 25 seconds, which is not enough to evade sandboxes.\r\nSummary of Formbook Analysis\r\nWe analyzed 10 different samples and discovered lots of tricks used by the latest Formbook variants droppers to\r\nevade analysis:\r\nAnti-Sandbox (User interaction, Delayed execution, Check for loaded modules, Time acceleration checks)\r\nSearch for research tools/anti-malware products/suspicious sample names\r\nChange of the API calls (e.g: use of NtMapViewOfSection instead of WriteProcessMemory, use of\r\nNtAlertResumeThread instead of ResumeThread), Not using NtUnmapViewOfSection\r\nAnti-Debug\r\nUse of several programming languages (Visual Basic, Delphi, C#, C++, AutoIt)\r\nWide usage of different encryption algorithms, both proprietary and known ones (RC4)\r\nObfuscations\r\nAnti-Memory analysis to avoid detection of reflective loading\r\nVarious packers\r\nThe use of so many techniques suggests detecting the Formbook’s payload on the disk by signatures is impossible.\r\nBehavioral analysis is the only way to fully detect Formbook data-stealing malware and its droppers’ malicious\r\nactivities.\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 15 of 16\n\nIt is unknown to us who is writing and selling Formbook malware combined with these droppers. It might be sold\r\nseparately or combined. What is certain, a lot of work has been invested in developing these droppers, as they\r\ndiffer so much and employ a lot of different techniques.\r\nFormbook Detection Suggestions\r\nFollowing the techniques/IOCs we found, here are our suggested way to detect them. It should be taken into\r\nconsideration that false-positives are also possible.\r\nUse the hashes (SHA256) we mentioned and blacklist them\r\nSuspicious file names: essentialize.exe, Rhododendrons8.exe\r\nSearch for execution of mshta.exe – look which script was used to execute it.\r\nLooks for suspicious command line that has string manipulation (replace method)\r\nMonitor usage of AutoIt compiled scripts and Delphi compiled files\r\nSearch for processes that create themselves as suspended, then inject PE/shellcode into them and resume –\r\nthis is very common among malware in general and especially among Formbook’s droppers.\r\nAll of the droppers were unsigned – always check if the executable is unsigned\r\nKeep an eye on the autorun key – especially if it contains executables to run from a temporary folder\r\nExample of formbook detection by Cyberbit’s EDR of sample 1\r\nAfter execution, the following graph will be generated:\r\n37-Formbook-Sample-Cyberbit-EDR\r\nFigure 37 – Graph of the first sample on Cyberbit’s EDR\r\nFormbook.exe is the dropper as mentioned in the first sample analysis. It drops and executes rhododendrons8.exe\r\nand also executes mshta.exe to gain persistency (registry – executable added).\r\nIf we look at the event details of mshta.exe, we can see the full script:\r\n38-Formbook-VB-Script-executed\r\nFigure 38 – the VBScript executed can be clearly seen\r\nHod Gavriel is a malware analyst at Cyberbit.\r\nLearn more about Cyberbit EDR Kernel-Based Endpoint Detection vs. Whitelisting\r\nSource: https://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nhttps://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.cyberbit.com/blog/endpoint-security/formbook-research-hints-large-data-theft-attack-brewing/"
	],
	"report_names": [
		"formbook-research-hints-large-data-theft-attack-brewing"
	],
	"threat_actors": [],
	"ts_created_at": 1775434939,
	"ts_updated_at": 1775791273,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cb9f809040ce5fa50762fe37d45230ca8ab5aa5a.pdf",
		"text": "https://archive.orkl.eu/cb9f809040ce5fa50762fe37d45230ca8ab5aa5a.txt",
		"img": "https://archive.orkl.eu/cb9f809040ce5fa50762fe37d45230ca8ab5aa5a.jpg"
	}
}