{
	"id": "404b6c4e-b644-4d9a-9770-60e76d3d9185",
	"created_at": "2026-04-06T00:20:08.640382Z",
	"updated_at": "2026-04-10T03:23:51.13755Z",
	"deleted_at": null,
	"sha1_hash": "280337101b33598e45dc46597df83e1900f02f90",
	"title": "Deep Analysis: New FormBook Variant Delivered in Phishing Campaign – Part I | FortiGuard Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3154235,
	"plain_text": "Deep Analysis: New FormBook Variant Delivered in Phishing Campaign\r\n– Part I | FortiGuard Labs\r\nBy Xiaopeng Zhang\r\nPublished: 2021-04-12 · Archived: 2026-04-05 15:24:44 UTC\r\nFortiGuard Labs Threat Research Report\r\nAffected platforms: Microsoft Windows \r\nImpacted parties:    Windows Users\r\nImpact:                    Collect Sensitive Information from Victim’s Device.\r\nSeverity level:          Critical\r\nFortiGuard Labs captured a phishing campaign that was sending a Microsoft PowerPoint document as an email attachment\r\nto spread the new variant of the FormBook malware. FormBook is a well-known commercial malware, so dubbed because it\r\nhas been sold “as-a-service” on hacking forums since 2016. It is designed to steal personal information from victims' devices\r\nand manipulate their devices using control commands from a C2 server. FormBook, which has been detected in the wild for\r\nover five years, is designed to steal personal information through the use of keyloggers and form grabbers to collect victim\r\ninput along with the data of some software, such as browsers, IM, Email clients, and FTP clients.\r\nI recently conducted in-depth research on the latest campaign we captured, starting with the phishing email and the attached\r\nPowerPoint document that delivers the malware. This is the first part of that analysis. In it, I will demonstrate all my\r\nfindings from the research, including but not limited to how the malicious VBA code is executed in the PowerPoint file; how\r\nthe FormBook payload file is downloaded by the PowerPoint file; as well as how the FormBook main file (module) is\r\nfinally extracted from a .Net module. In part II, I will look at what the FormBook malware does once loaded, and in\r\nparticular, the new functions and features in this latest variant.\r\nPhishing Email and PowerPoint Document\r\nThe phishing email used to deliver the FormBook malware looks like a reply to a request for a purchase order. Of course,\r\nthis is simply a crafted fake message to the victim. Figure 1.1 shows the email content. It is designed to lead the victim to\r\nopen the attached PowerPoint file to view the details of “brochures and prices” in a video.\r\nFigure 1.1 - The phishing email captured by FortiGuard Labs\r\nThe PowerPoint file is delivered with a “.pps” file extension, which tells PowerPoint to open it directly in “slide show” view\r\n(not in “edit” view, which is the default for other file extensions like “.ppt”) once the recipient double-clicks on the file.\r\nFigure 1.2 is the screenshot of the slide content once it begins. While the victim is moving their mouse around the slide\r\nshow or clicking on items, the malicious VBA code is being executed in background. Through my analysis, it sets two\r\nactions (“Mouse Click” and “Mouse Over”) to run the Macro function MRmgEG() once triggered. Figure 1.3 only shows\r\nthe “Action Settings” for the “Mouse Over” event. These are the same as the settings for the “Mouse Click” event.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 1 of 10\n\nFigure 1.2 – Beginning of the slide show after double-clicking on the PowerPoint file\r\nFigure 1.3 - The Mouse Over action is set to execute the Macro MRmgEG()\r\nOnce MRmgRE() is called, it then calls several methods and finally runs a piece of PowerShell code by calling the function\r\nRPUJob() (which is an alias of API WinExec()), as displayed in Figure 1.4. I have deobfuscated the PowerShell command at\r\nthe bottom of the Figure for you to clearly observe it.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 2 of 10\n\nFigure 1.4 - Macro executing a PowerShell code\r\nThe method Invoke-RestMethod() requests a PowerShell code from “hxxps[:]//bit[.]ly/2NDvCoG”. “bit.ly” is a website that\r\nprovides a URL shortening service. In this case, the short URL links to “hxxp[:]//kiibra[.]com/images/index.jpg”.\r\n“index.jpg” is not a real picture file, but a PowerShell file that will be executed by IEX().\r\nI manually downloaded the file “index.jpg” and my static analysis found that the PowerShell code would extract two files\r\n(“item1.gif” and “item2.png”) into the system’s temporary folder from two variables with base64 encoded data. Below is a\r\nkey piece of the PowerShell code that I copied from “index.jpg”.\r\n[IO.FIlE]::WRiTeAlLBYtES(\"$Env:TMP\\item1.gif\",\r\n             [SySTeM.ConveRT]::frOMbaSe64CHArARRay($SAKeLtXeLERX, 0,\r\n             $SAKeLtXeLERX.LENgTH));\r\n[IO.FilE]::WrItEALLByTeS(\"$Env:TMP\\item2.png\",\r\n             [SyStem.CONVErt]:: fROmbaSe64ChaRaRrAy($vVXFiQawOSBg, 0,\r\n             $vVXFiQawOSBg.LENGthh));\r\ncMd.exe /C COPy /B '%TMP%\\item1.gif' + '%TMP%\\item2.png'\r\n'%TMP%\\item3.jpg';       \r\ndel \"$Env:TMP\\item1.gif\";\r\ndeL \"$Env:TMP\\item2.png\";   \r\nCmD.eXe /c '%TMP%\\item3.jpg'\r\nThese two variables, with huge amounts of base64 encoded data, are “$SAKeLtXeLERX” (that saves to “item1.gif”) and\r\n“$vVXFiQawOSBg” (that saves to “item2.png”). The two files are actually pieces of an executable file, which then are\r\ncombined into a single file called “item3.jpg” (by executing the “Copy” command), which is eventually run by calling the\r\ncommand “cmd.exe /c %TMP%\\item3.jpg”. Figure 1.5 is a screenshot of the files residing in my testing environment’s\r\n%TEMP% folder.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 3 of 10\n\nFigure 1.5 - Generated files used to execute the PowerShell code\r\nInitial Static Analysis on item3.jpg in Phishing Campaign\r\nI then dragged the file into a PE analysis tool, as shown in Figure 2.1 below. We can see that it is a 32-bit executable file that\r\nwas developed in Microsoft Visual C#.\r\nFigure 2.1 - “item3.jpg” in PE analysis tool\r\nUsing the view provided in the .Net analysis tool “dnSpy”, shown in Figure 2.2, I noticed that the code of “item3.jpg” is\r\nfully obfuscated, including classes, methods, properties, and code flow. All the names are totally randomly generated and\r\nmeaningless so you cannot obtain any clues from them. In addition, an obfuscated code-flow can confuse the code order so\r\nyou cannot easily know where the next code goes. All of these techniques are a huge challenge for an analyst trying to\r\ncomprehend the code and trace the code-flow. Since the module name is “Li7f”, I will refer to it using the module name in\r\nfollowing content.\r\nFigure 2.2 - The obfuscated code of “item3.jpg” and its entry point function\r\nAnalyzing the “Li7f” Module in Debugger\r\nThe malware developers not only obfuscated the code, but also encrypted all constant strings. However, there is a special\r\nmethod that can be used for dynamically decrypting constant strings by their string ID from a large string array, just before\r\nthe constant string is being used. Just as you can see in Figure 3.1, it decrypts two strings: “https://www.bing.com” and\r\n“https://www.google.com”. You may have noticed that the names of class and method have been renamed to be meaningful\r\nfor better tracking and to better understand its code. The renamed method is now “cls_x2C.decrypt_string_g4J()”, while its\r\noriginal name was “x2C.g4J()”. During my analysis, I renamed many other classes, methods, and variables, which you will\r\nsee in this blog, to make them easier to track.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 4 of 10\n\nFigure 3.1 - Decrypting two Host strings\r\nTo confirm that the victim’s device is connecting to the internet, the “Li7f” module sends normal “Get” requests to the two\r\nhosts, as shown above in Figure 3.1. It then continues its task only when it can receive responses from both of the two host\r\nservers.\r\nThere are twenty-three .Net resources in “item3.jpg” that are used to save encrypted data. “Li7f” retrieves the data of\r\n“d4R.Resources” into memory, which is Dictionary data (key/value). To finish this, it creates a ResourceManager object\r\nwith a resource name and a ResourceSet object (Dictionary object). It then obtains the value of the key \"LoginDataBase\",\r\nwhich is an encrypted PE file. Figure 3.2 shows all of the .Net resources of “item3.jpg” and the encrypted PE (value of key\r\n“LoginDataBase”) in the resource “d4R.Resources”.\r\nFigure 3.2 - .Net Resources and the encrypted PE in “d4R.Resources”\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 5 of 10\n\nFigure 3.3 - The decrypted value of the key “LoginDataBase”\r\nFigure 3.3 is the decrypted PE file in the memory from the key “LoginDataBase” of the resource “d4R.Resources”. The PE\r\nfile is a .Net DLL module that is dynamically deployed by the “Li7f” module. I will refer to this .Net module as “zOAI” in\r\nthis blog, according to its project name. \r\nThe “zOAI” module’s entry method is invoked in the “Li7f” module, which defines a delegate type “Fx7” and assigns it to\r\nlink to the entry method “CaCl.aXt()“ of the “zOAI” module. So, calling a delegate method defined by “Fx7” type in the\r\n“Li7f” module is equivalent to calling “CaCl.aXt()“ in the “zOAI” module. \r\nAn “Fx7” type is defined in the class “cls_form_m3N” in the “Li7f” module as follows:\r\ninternal delegate void Fx7(); //It is similar to the function pointer in C and C++ language.\r\nIt is assigned by calling “obj = Delegate.CreateDelegate (A_0, A_1, A_2, A_3, A_4);”, where “A_0” is the type\r\n(“cls_form_m3N.Fx7”) of delegate to create; “A_1” is a target class name(“zOAI!Cacl”) that develops the target method;\r\n“A_2” is the target method “aXt”.\r\nAfter that, the variable “obj” is linked to the method “zOAI!Cacl.aXt()”.\r\nAnd finally, “Li7f” invokes the “zOAI”’s entry method “zOAI!Cacl.aXt()” using the pseudo code “((cls_form_m3N.Fx7)\r\n(delegate)obj)();”.\r\nDeep Dive into “zOAI” Module\r\nThe “zOAI” module is same as the “Li7f” module that is fully obfuscated. As you can see in Figure 4.1, the names of classes\r\nand methods are random strings, and the code-flow is also obfuscated.\r\nFigure 4.1 – The obfuscated “zOAI” module and entry method “aXt()”\r\nThe “zOAI” module retrieves the current call back frame by calling StackFrame Last\u003cStackFrame\u003e(). Through the last one\r\n(which is “Li7f!Zx4.m3N.Rt7()”—refer to Figure 2.2), “zOAI” obtains the image of the module “Li7f”. Furthermore, it\r\nproceeds to retrieve another .Net resource from “Li7f” (item3.jpg). It parses the TimeStamp value from the PE structure of\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 6 of 10\n\nitem3.jpg to generate the name (“83130d5d1439.Resources”) of the .Net resource to read, which is shown in Figure 4.2.\r\nLooking back at Figure 3.2, you will find that “83130d5d1439.Resources” is the last of the .Net resources. \r\nFigure 4.2 - Generated resource name from the TimeStamp value\r\nThe data of this resource that is also encrypted contains a dictionary data structure with many key/value pairs. Figure 4.3,\r\nbelow, is the decrypted and loaded dictionary.\r\nFigure 4.3 – The Dictionary data that is read from “83130d5d1439.Resources”\r\nIt contains many switches explaining what “aOZI” module is able to do. For example, \r\nHow to perform startup persist (%StartupPersist%)\r\nHow to show up a fake message to victim (%Message%)\r\nHow to do the anti-VM environment (%VM%) and anti-sandbox detection (%SB%) \r\nAnd so on\r\nAs shown in Figure 4.3, all of them above are set to false; hence, the “zOAI” module will bypass those operations and\r\ndetections. The most significant data is %MainFile%, which is a decrypted PE file (file size 0x2d600). It is the payload file\r\nof this variant of FormBook, which I’ll talk about later.\r\nIt then decrypts a constant string, \"AddInProcess32.exe\", with the index 2444184564U. This file belongs to the Microsoft®\r\n.NET Framework and is located in the .Net Framework installation folder. It then copies this file from\r\n\"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\AddInProcess32.exe\" (in my testing environment) to\r\n\"%Temp%\\AddInProcess32.exe\" by calling an imported native API CopyFileEx, defined below in module “zOAI”:\r\n[DllImport(\"kernel32.dll\", CharSet = CharSet.Auto, EntryPoint = \"CopyFileEx\", SetLastError = true)]\r\n[return: MarshalAs(UnmanagedType.Bool)]\r\ninternal static extern bool FO18xSYnaRX8DJ59Xlc280GJqLA([MarshalAs(UnmanagedType.VBByRefStr)] ref string, [MarshalAs(UnmanagedType.V\r\nVeQ.MAN5S2ZmxZ35Z7m3YKy0VksroQA, IntPtr, ref int, VeQ.Qs6h1EUA15Rsz9R5qN5eapIAj63);\r\nThe last thing that the “zOAI” module does is to decrypt another .Net module from a local array variable and then deploys it\r\nin the memory as well as invokes its entry method with parameters. Again, this module is fully obfuscated. Its name is\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 7 of 10\n\n“AMe8” and the entry method is “AMe8!eUI.C74()”.\r\nFigure 4.4 – Invoking the entry method of the “AMe8” module\r\nIt breaks in “Invoke()”, as shown in Figure 4.4, and is going to call method “AMe8!eUI.C74()” with parameters, which\r\ncontains the full path of the copied “AddInProcess32.exe” and a buffer address of the FormBook payload (the same data in\r\n%MainFile%, shown in Figure 4.3).\r\nLet’s move on to next section for more information about the module “AMe8”.\r\nUsing the “AMe8” Module to Run FormBook\r\nThe entry method “AMe8!eUI.C74()” parses the parameters passed from the “zOAI” module and it then runs the\r\n“AddInProcess32.exe” that has copied into the %temp% folder. As I explained earlier, “AddInProcess32.exe\" is an official\r\nprogram of the Microsoft .Net Framework. Why does “AMe8” module run it? Actually, it is a puppet program, because the\r\n“AMe8” module will inject the FormBook payload into it and then perform malicious tasks on its behalf. \r\nTo implement this, it creates the process \"%Temp%\\AddInProcess32.exe\". This is a code segment of the “AMe8” module,\r\nshown in Figure 5.1, which calls an imported native API CreateProcessAsUser() with a CreationFlag “4U” that refers\r\nto CREATE_SUSPENDED.\r\nFigure 5.1 – The API CreateProcessAsUser() used to create a suspended process\r\nAfter calling this API, the “AddInProcess32.exe” process is created and entered into a suspended state before executing any\r\ninstructions. Next, the “AMe8” module calls a group of imported native APIs, such as GetThreadContext(),\r\nReadProcessMemory(),  VirtualAllocEx(), WriteProcessMemory(), SetThreadContext(), and ResumeThread().\r\nIt also allocates memory space in the “AddInProcess32.exe” process for the FormBook payload by calling the API\r\nVirtualAllocEx() and injecting the FormBook payload into it by calling the API WriteProcessMemory() and modifying the\r\nprocess’s registers using the API SetThreadContext(), so that it runs the FormBook payload’s entry point function when it\r\nresumes to run by calling the API ResumeThread(). Figure 5.2 is a screenshot of the Process Tree, which shows the process\r\nof “AddInProcess32.exe” just after it is created.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 8 of 10\n\nFigure 5.2 - Process tree view of the newly-created “AddInProcess32.exe”\r\nConclusion on Phishing Campaign\r\nThis is the first part of my analysis of the FormBook phishing campaign. In this part, I have elaborated how the PowerPoint\r\ndocument runs its VBA code to download PowerShell code, which extracts the .Net file “item3.jpg”.\r\nIn order to execute the main file (payload) of FormBook, it is transferred through three .Net modules, ”Li7f”, “zOAI”, and\r\n“AMe8”, and is finally executed by “AMe8”. I also explained the relationship between these modules and how they connect\r\nto each other. I also displayed the anti-analysis technique they use – including the full obfuscation, which really takes a\r\nsignificant amount analyst time to defeat.\r\nWe know that the payload file of FormBook is injected into a newly-created “AddInProcess32.exe” process and is executed\r\non its behalf to secretly perform malicious tasks. In Part II of this blog, I will provide additional analysis to explain what\r\nmalicious things it is going to do and how, including what data it can steal from a victim’s device and how it controls the\r\nvictim via control commands. Please stay tuned.\r\nFortinet Protections\r\nFortinet customers are already protected from this FormBook variant with FortiGuard’s Web Filtering and AntiVirus\r\nservices, as follow:\r\nThe download URL launched from the PowerPoint sample is rated as \"Malicious Websites\" by the FortiGuard Web\r\nFiltering service.\r\nThe attached PowerPoint file is detected as “VBA/FormBook.C393!tr” and the “item3.jpg” file is detected as\r\n\"MSIL/FormBook.ZXL!tr\" and blocked by the FortiGuard AntiVirus service.\r\nThe FortiGuard AntiVirus service is supported by FortiGate, FortiMail, FortiClient, and FortiEDR. The Fortinet AntiVirus\r\nengine is a part of each of those solutions as well. As a result, customers who have these products with up-to-date\r\nprotections are protected.\r\nWe also suggest our readers to go through the free NSE training -- NSE 1 – Information Security Awareness, which has a\r\nmodule on Internet threats designed to help end users learn how to identify and protect themselves from phishing attacks.\r\nIOCs:\r\nURLs\r\nhxxp[:]//kiibra[.]com/images/index[.]jpg \r\nSample SHA-256\r\n[Video Drawing P.O.#4210020253.pps]\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 9 of 10\n\n82BE061B2BFE48EE3A9F76EE99CF6F3ED712C0C1393AD4A9F064CFC4D11CB53D\r\n[item3.jpg, module name “Li7f”]\r\nF45A363A86D38E5814D41908C0EA5A13F8A89AF2AFEA931472F9905B87FB2ADC\r\nLearn more about FortiGuard Labs threat research and the FortiGuard Security Subscriptions and Services portfolio.\r\nLearn more about Fortinet’s free cybersecurity training initiative or about the Fortinet NSE Training program, Security\r\nAcademy program, and Veterans program.\r\nSource: https://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I"
	],
	"report_names": [
		"deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434808,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/280337101b33598e45dc46597df83e1900f02f90.pdf",
		"text": "https://archive.orkl.eu/280337101b33598e45dc46597df83e1900f02f90.txt",
		"img": "https://archive.orkl.eu/280337101b33598e45dc46597df83e1900f02f90.jpg"
	}
}