{
	"id": "2b59eab3-c45c-4732-ac68-e2460fd5c783",
	"created_at": "2026-04-06T00:06:06.709605Z",
	"updated_at": "2026-04-10T13:13:04.082114Z",
	"deleted_at": null,
	"sha1_hash": "b66785e3843a705173032f89cbf15bb6a885e81c",
	"title": "Threat Analysis: MSI - Masquerading as a Software Installer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2112123,
	"plain_text": "Threat Analysis: MSI - Masquerading as a Software Installer\r\nBy Cybereason Global SOC Team\r\nArchived: 2026-04-05 23:35:11 UTC\r\nThe Cybereason Global Security Operations Center (GSOC) issues a Purple Team Series of its Threat Analysis\r\nreports to provide a technical overview of the technologies and techniques threat actors use to compromise\r\nvictims’ machines. \r\nIn this Threat Analysis report, the Cybereason GSOC team analyzes a technique that utilizes Microsoft’s Windows\r\nInstallation file (.msi) to compromise victims’ machines.  \r\nThis report is divided into four sections: \r\n1. 1. 1. 1. Introduction: An overview of the MSI file format.\r\n2. Red Team: Offensive approach leveraging MSI files for attacking purposes.\r\n3. Blue Team: Defenders' perspective, studying how MSI files are exploited by threat\r\nactors. \r\n4. Purple Team: Detection proposals for possible malicious MSI files and analysis tools. \r\nKEY POINTS\r\nMasquerade as legitimate installer: Malicious MSI files are sometimes difficult to distinguish from\r\nlegitimate installers. Threat actors will often masquerade as well-known software updates and manipulate\r\nvictims into “updating” the software on their machines.  \r\nExecute with elevated privilege: MSI allows execution with a LocalSystem account (NT\r\nAuthority\\System). The unauthorized access via LocalSystem privilege can lead to compromise of the\r\nsystem and to further network compromise. \r\nNumerous ways to exploit MSI: MSI is based on COM Structure Storage, which allows threat actors to\r\nstore malicious files in a MSI file and to control stored files with custom actions. This technology gives\r\nthreat actors a variety of options for execution patterns they can use to infect victims’ machines. \r\nINTRODUCTION\r\nThis chapter explains the fundamentals of Windows Installer packages (MSI).\r\nOverview\r\nMSI, formerly known as Microsoft Installer, is a Windows installer package format. MSI allows for the\r\ninstallation and deployment of necessary Windows applications or packages to end-users’ machines. MSI is a\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 1 of 32\n\nstandardized installation method that simplifies the installation process for users. The installation process with\r\nMSI files is simple and often does not require much user interaction. Usually, the installation process with MSI is\r\nsimilar to running an executable. \r\nMSI utilizes Microsoft’s technology COM Structured Storage, which allows an MSI file to have a file system\r\nstructure. This technology is also referred to as OLE documents, components often used by Microsoft Office. This\r\ntechnology is constructed with two types of objects called storage and streams, which are conceptually similar to\r\ndirectories and files. This structure allows MSI components to store multiple files to allow for easy access.\r\nThe ability to store and deploy necessary files with minimal user action makes this technology similar to self-extracting zip files, which are often in the form of executables.  \r\nThe installation procedure also allows execution with a LocalSystem account (NT Authority\\System). The\r\nelevated privilege behavior as well as the COM Structure makes MSI an attractive malware deployment method\r\nfor threat actors.  \r\nStructure\r\nMSI contains a main stream called a Database stream. This section provides an overview of the Database stream\r\nand its relevant components. \r\nDatabase\r\nThe Database stream consists of tables that form a relational database. These tables are linked with primary and\r\nforeign key values. This structure allows MSI to maintain relationships between the different tables and contain\r\nbasic information required to perform the installation.  \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 2 of 32\n\nDatabase stream, representing primary/foreign key relationships\r\nThe information within each table has important roles for the installation, such as tables storing information on\r\ninstalling software applications. \r\nFile: Metadata of installing application files. \r\nRegistry: Registry key values of installing applications. \r\nShortcut: Shortcuts of relevant installing applications.\r\nOther tables include information about package executions of the installation and execution sequences. These\r\ntables are crucial for MSI to determine the execution flow, as well as the exact actions needed for the installation.\r\nThe tables allow developers to manipulate the installation process and allow installation to have complex logic.\r\nThe installation logic is often manipulated with Actions and Sequences. \r\nActions\r\nThe MSI contains a set of subroutines to execute the installation. These routines are divided into two types: \r\nStandard Actions: These are built-in actions that allow developers to perform the installation. Some notable\r\nactions include the following–\r\nInitialize installation directories\r\nDrop files to the installation directories\r\nAdd a registry value for the installing softwares \r\nCustom Actions: Standard Actions may not be enough for developers to execute the installation logic.\r\nCustom actions allow developers to embed logic outside of Standard Actions by executing specific binary\r\nor scripts during the installation. Some notable custom actions include the following–\r\nExecute executables stored within the MSI file\r\nExecute specific exported functions from DLLs \r\nExecute JavaScript or Visual Basic scripts\r\nThe above actions can be manipulated by utilizing Properties, which are similar to environment variables.\r\nProperties often contain various data and control parameters required to execute certain actions, including: \r\nA flag which identifies if reboot is needed\r\nInstallation directory\r\nSystem information\r\nControl information on installation\r\nThe Property table exists within the Database Stream. However, note that not all properties are stored in the\r\nProperty table. Since some Properties are set during the installation in specific actions, Properties that are set\r\ndynamically may not be in the Property table. \r\nSequences\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 3 of 32\n\nDevelopers can set the order in which Standard Actions and Custom Actions are executed in the Sequence table.\r\nWithin the Sequence table, they can assign conditions to control the actions’ behavior. \r\nThere are two main types of sequences:\r\nInstall UI Sequence - This refers to the sequence of actions for installation UI, which includes user\r\ninteractions with the dialog.\r\nInstall Execute Sequence - This refers to the sequence of actions for actual installation execution, such as\r\ndropping files and creating registry entries. When conducting silent installation, the Install UI Sequence is\r\nignored and only the Install Execute Sequence is used.\r\nFor this report, the focus will be on the Install Execute Sequence, since this table is most relevant to the actual\r\ninstallation behavior. \r\nExample MSI database tables layout and its relations\r\nRed Team\r\nThis section describes how to reproduce the staging of a malicious MSI file, in order to analyze it and build\r\ndetections for it. Similar to archived files, an MSI file can contain various malicious binaries or scripts to conduct\r\nits malicious actions. \r\nIn this section, the MSI file will reference the MSFVenom template with minor updates. However the section will\r\nfocus more on the inner workings of MSI file format. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 4 of 32\n\nMalicious MSI execution flow\r\nMSI files can allow attackers to embed malicious binaries or scripts and take over the machine with elevated\r\nprivileges. To demonstrate this, a malicious stager binary is embedded into an MSI file, which later fetches and\r\nexecutes the payload from the C2 server. \r\nThe overall flow is as follows: \r\n1. Execute the MSI file.\r\n2. Execute the embedded binary. \r\n3. Execute the stager shellcode. \r\n4. Fetch and execute the payload from a C2 server. \r\n5. Terminate installation. \r\nThe main usage here is to execute any relevant binary within memory without dropping any files to the disk. \r\nPreparation\r\nIn this section, we show how MSI files can be created using the Windows Installer XML(WiX) toolset. This is\r\nfree software for building Windows Installer packages from XML files.\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 5 of 32\n\nWXS file content, showing Stager and ExitInstallation Custom Actions\r\nThe executable needs to be stored in a table where it can be accessed by the CustomAction element prior to its\r\nexecution. The Binary table is often used to place animations, bitmaps, and icons; however it also allows the MSI\r\nto store relevant binary data needed for CustomAction, even malicious PE files and scripts.\r\nId assigns unique identifiers to the elements, which developers can call and utilize for specific actions. The\r\nMyStager id is assigned to the malicious executable stager.exe. This executable will allocate and execute stager\r\nshellcode.\r\nBinary and CustomAction elements\r\nThe MyStager binary element is followed by a CustomAction element with Id Stager. This is the key element that\r\nwill decide the behavior of the MyStager. \r\nEach attribute from the configuration of CustomAction is described below:\r\nBinaryKey: Attribute which specifies Binary element ID.\r\nImpersonate: Attribute which specifies if the installer impersonates the installing user’s context. If attribute\r\nis no, then the installer will be executed with elevated privileges (LocalSystem). \r\nExecute: Attribute which specifies the scheduling of the CustomAction. The parameter “deferred” will\r\ndelay the execution and allow the developer to control the specific CustomAction. This is the only value\r\nthat allows the execution to run in elevated privileges. \r\nReturn: Attribute which specifies the return behavior of CustomAction. asyncNoWait value allows the\r\nCustomAction to be executed asynchronously from the installer. \r\nExeCommand: Attribute which specifies arguments for the executable. \r\nThe CustomAction Stager is set up to execute the malicious executable stored in the Binary table with elevated\r\nprivileges and to continue executing even after installation is terminated.\r\nCustomAction ExitInstallation\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 6 of 32\n\nAfter the MyStager setup, another CustomAction ExitInstallation is set to attempt executing VBScript. However,\r\nthis execution will purposely fail and exit since this installation will not contain relevant VBScript. This\r\nCustomAction has another purpose which will be explained in the next paragraph. \r\nOnce the CustomActions are set, the element InstallExecuteSequence, an Install Execute Sequence table, is set.\r\nFor its first action, ResolveSource sets the source location and sourcedir property. This is needed to initialize the\r\ninstallation process. Once initialization is complete, the relevant CustomActions Stager and ExitInstallation will\r\nbe set for the execution in this order respectively. \r\nExitInstallation plays an important role in this execution, which will force the installation to purposely fail and\r\nexit. This then forces the MSI to exit with a failure. However, the malicious binary will continue executing since it\r\nis set up to run asynchronously. The victim may disregard this error and may not take into account that malicious\r\nactivities are running in the background. \r\nExecution\r\nThe execution in this section assumes the victim retrieves the MSI file via phishing email. Once the file is\r\ndeployed onto the victim’s machine, the victim executes the MSI file by simply double-clicking. The execution\r\nprompts with a UAC warning, as execution is performed by a high-privilege user. Once the UAC warning is\r\naccepted by the user, the execution will proceed with the usual installation process. \r\nMSI process tree\r\nAfter MSI execution, the installation fails and exits with the following message: \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 7 of 32\n\nError message due to CustomAction ExitInstallation\r\nThe MSI terminates itself; however, since the Stager is set to execute asynchronously, the malicious binary will\r\ncontinue executing. \r\nAttack Tree of MSI execution \r\nAs soon as MSI starts executing itself, the execution flow enters the malicious executable in the Custom Action,\r\nwhich is msia8a.tmp. \r\nMsia8a.tmp (the name will vary) proceeds to retrieve the payload from the C2 server and deploy it onto the\r\nvictim's machine. Once the payload is successfully deployed, the stager continues executing the payload.\r\nSuccessful payload execution leads to successful connection to the C2 server, and it is also evident that the\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 8 of 32\n\npayload is being executed with an elevated privilege account. At this point, the attacker has remote control over\r\nthe machine. \r\nAttacker’s terminal, which is a Metasploit listener\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 9 of 32\n\nExecution Flow Chart\r\nBlue Team\r\nThis section focuses on an analysis of malware that abused MSI files in the past. Technical Analysis dives into\r\nMSI file usage by three different malware families seen in the wild. The section ends with Comparative Charts for\r\neach sample's MSI file execution.\r\nTechnical Analysis\r\nThis section analyzes three different malware families. The analysis focuses on the following Secure Hash\r\nAlgorithm (SHA)-256 samples. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 10 of 32\n\nMalware Family SHA-256\r\nMagniber Ransomware 0e65657740d7f06acda53b7d3190f9728801b984d5bd6ccb0b865d218ae71f66\r\nMatanBuchus Loader face46e6593206867da39e47001f134a00385898a36b8142a21ad54954682666\r\nQbot / Qakbot c0beb47f629a5debe0e99790d16a4d04afe786d6fb42c5ab6dfcaed84d86e7ad\r\nMagniber Ransomware\r\nMagniber Ransomware is known to utilize infection methods such as exploiting vulnerabilities and masquerading\r\nas a legitimate software update to infect a victim’s machine. The following are known infection methods seen in\r\nthe past:\r\nExploiting the PrintNightmare vulnerability.\r\nMasquerading as a legitimate Google Chrome or Microsoft Edge update by abusing Windows Application\r\nPackage (.appx) files. \r\nMasquerading as legitimate Windows 10 upgrades by abusing MSI.  \r\nMSI Analysis\r\nAccording to file metadata, the MSI file is built with the WiX toolset. \r\nMSI file metadata\r\nThe presence of CustomAction in the table below provides a better idea of potentially malicious behavior: \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 11 of 32\n\nSample’s CustomAction table, as seen from the Orca tool\r\nThe CustomAction table has two actions configured: \r\n1. 1. 1. SetProgramFilesFolder: Set Program Files folder to local appdata folder\r\n(C:\\Users\\UserName\\AppData\\Local).\r\n2. h54pstl1: Fetch binary m21iivix0ds.\r\nSetProgramFilesFolder has Custom Action type 51, which indicates the action will configure the property's value.\r\nThe Custom Action SetProgramFilesFolder configures the source ProgramFilesFolder property, which is a\r\nplaceholder for the Program Files folder. ProgramFilesFolder is set to a value specified by the target\r\nLocalAppDataFolder property, which is a local appdata folder (e.g. C:\\Users\\UserName\\AppData\\Local). \r\nSample’s Directory table, as seen from the Orca tool\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 12 of 32\n\nThe Directory table includes information on the installation’s directory location. As shown in the image,\r\nProgramFilesFolder is seen to have Directory_Parent as the TARGETDIR property, which is the root installation\r\ndirectory. Based on the Directory and CustomAction tables, the installation directory will be placed under the\r\nlocal appdata directory.\r\nThe Custom Action h54pstl1 has Type 65, which indicates combinations of the type and relevant options. \r\nType 1: Indicates the DLL file is stored within the Binary Table. \r\nOptional Constant +64: Indicates that the execution will continue regardless of CustomAction failure.\r\nAccording to the Custom Action Type, m21iivix0ds is a DLL file stored in the Binary Table and is expected to\r\nexecute the exported function t5thamku.\r\nSample’s Binary Table, as seen from the Orca tool\r\nIn order to identify at which point in the installation process the Custom Actions are executed, the\r\nInstallExecuteSequence table must be analyzed. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 13 of 32\n\nSample’s InstallExecuteSequence table, as seen from the Orca tool\r\nThe actions with sequence number 800 to 1000 are related to costing of the installation, which is an action to\r\ncalculate the amount of disk space in which relevant files are to be installed or removed. Since the cost of\r\ninstallation files are also related to the installation directory, the relevant directory needs to be configured. As a\r\nresult, the SetProgramFilesFolder (Sequence number 999) action is within the costing process and the directory\r\nresolution configured in the Directory table is configured in the CostFinalize action.\r\nCustom Action h54pstl1 is executed right after InstallInitialize, which is a sequence for actual installation\r\nexecution. Anything between InstallInitialize and InstallFinalize is part of the installation activities that will\r\nupdate and change the target system. At this point, the Custom Action h54pstl1 executes the exported function\r\nt5thamku with elevated privileges. \r\nInstallFiles is an action that places the relevant files in the destination location, which in this case is the\r\ndestination set up by Custom Action SetProgramFilesFolder. This file information is often stored in the Media\r\ntable, the File table, and the Component table. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 14 of 32\n\nSample’s File table, as seen from the Orca tool\r\nReviewing the Media table, the MSI includes the cabinet file Product.cab. However, in the File Table, the file\r\nv514749 has a file size of 0. This indicates a cabinet file exists, but it does not drop any files during the\r\ninstallation. Even though the directory was configured via CustomAction and Directory tables, since no files will\r\nbe dropped, the installation directory becomes irrelevant. \r\nMagniber MSI execution snippet, as seen from the Cybereason platform\r\nMagniber MSI infection flow\r\nMatanBuchus Loader\r\nMSI Analysis\r\nMatanBuchus is a Malware-as-a-Service (MaaS) platform developed by the threat actor BelialDemon and\r\nidentified on Russian cybercrime forums in early 2021. Operating as a second-stage malware loader,\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 15 of 32\n\nMatanBuchus contains functionality to download and execute malicious payloads, run arbitrary PowerShell\r\ncommands, and conduct stealthy C2 server communications.\r\nThe malware itself has been observed being spread as a ZIP file in phishing emails. This file contains an HTML\r\nfile which drops another ZIP file when accessed. This second ZIP file contains the MSI file that loads the\r\nMatanBuchus payload and initiates downloads from its C2 server.\r\nThe loader for MatanBuchus payload is confirmed as an MSI file created using WiX through file metadata\r\nanalysis. The file itself appears with the subject “Adobe Font Pack 3.0.12.9” and is signed by “Westeast Tech\r\nConsulting, Corp.” in an attempt to masquerade as a legitimate Adobe file. However, it is notable that the\r\ncertificate has been invalidated. \r\nMatanBuchus MSI File Metadata, through the file Unix utility\r\nMatanBuchus MSI file digital signature information\r\nAs with Magniber, investigating the file's CustomAction values can give a better understanding of how the file\r\nexecutes. The CustomAction table below contains two actions with the value 226, which is of type 34 with option\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 16 of 32\n\n192. Custom Action Type 34 executes executables with the command line, and option 192 allows this execution to\r\nrun asynchronously. These values indicate that the files can be executed even if MSI Installer itself fails.\r\nRegardless of whether MSI Installer fails or runs, the following Custom Actions will occur:\r\nregsvr32.exe will install main_dll.\r\nwscript.exe will execute notify_vbs.\r\nMatanBuchus MSI file digital signature information, as seen from the Orca tool\r\nThe source is defined as INSTALLLOCATION, which is confirmed through investigation into the Directory to be\r\nthe LocalAppDataFolder. \r\nDirectory Information, as seen from the Orca tool\r\nAccording to the File table below, two files main.dll and notify.vbs will be dropped into the INSTALLLOCATION\r\ndirectory. As shown in CustomAction table, the command line will execute each of these files, which replace\r\nformatted data types [#main_dll] and [#notify_vbs] with the actual file path.\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 17 of 32\n\nFile metadata Information, as seen from the Orca tool\r\nThe [#main_dll] and [#notify_vbs] will not be replaced with an actual file path unless the Custom Actions are\r\nsequenced after CostInitialize, FileCost, and CostFinalize. The files also need to be dumped to the directory before\r\nexecuting via Custom Actions. Thus, the actions need to be executed after InstallInitialize, InstallFiles, and\r\nInstallFinalize actions. Consequently, both RunApplicationQQQ and RunApplicationNotifyVBS are sequenced at\r\nthe very end of InstallExecuteSequence. \r\nCustom Actions placed in the very end of InstallExecuteSequence, as seen from the Orca tool\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 18 of 32\n\nSince MSI files are COM Structured Storage constructs, it is possible to dump the file’s data streams via OLE in\r\norder to investigate the file further. While the output for initial analysis is unreadable, several data streams\r\ncontaining significant amounts of data can be observed.\r\nMatanbuchus MSI file OLE streams\r\nInvestigating the fourth data stream reveals that it begins with the ASCII characters (MSCF), indicating that this\r\nstream is a Cabinet Archive (CAB) file. \r\nFourth OLE stream data\r\nBy dumping this stream and opening the archive, the files (in this case, main.dll and notify.vbs) are dropped. The\r\nfile notify.vbs is notable because it contains an error message that appears related to Adobe Acrobat; this is an\r\nattempt to fool the user into believing that a legitimate Adobe Acrobat file did not run. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 19 of 32\n\nIn reality, while this message is displayed to the user once the MSI file is run, MatanBuchus executes the main.dll\r\nfile via regsvr32.exe in the background.\r\nContents of notify.vbs\r\nFake error message displayed by notify.vbs\r\nThe file main.dll is used by MatanBuchus to load the payload, create C2 connections, and establish persistence in\r\nthe exploited system. \r\nMatanbuchus Attack Tree, as seen from the Cybereason platform\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 20 of 32\n\nMatanBuchus MSI infection flow\r\nQbot / Qakbot\r\nQbot (also known as Qakbot, Quakbot, and Pinkslipbot) is a modular Trojan that has been in circulation for over a\r\ndecade. Its most prevalent campaigns consist of phishing attacks that attach malicious macros in Office\r\ndocuments, in particular Excel 4.0 macros, to evade detection. \r\nThe MSI variants of Qbot started circulating in late April 2022, which coincidentally occurred around the time\r\nMicrosoft implemented the VBA macro auto block feature, which made it harder for threat actors to launch\r\nsuccessful attacks via macro-enabled malicious documents.\r\nMSI Analysis\r\nAccording to the file metadata, the file is signed and verified by P.REGO, s.r.o. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 21 of 32\n\nFile Signature\r\nWithin the Property Table, there were multiple references to VSDNET* properties, which are .NET components\r\nutilized by Visual Studio. \r\nMSI is known to organize an installation around the concepts of components, which is essentially an installing\r\napplication or software. The malware is seen to have two components. \r\nComponent Table, as seen from the Orca tool\r\nC__FEAF4022223844D1906F79DF588CDB8A: This component has a value\r\n_FEAF4022223844D1906F79DF588CDB8A in KeyPath, which is a primary key into the Registry,\r\nODBCDataSource or File Table. The KeyPath _FEAF4022223844D1906F79DF588CDB8A appears to be\r\na primary key of File (1.dll); this indicates the malware is going to drop a module 1.dll during installation.\r\nFile Table, as seen from the Orca tool\r\nC__653B5566E1394F029FA3A18ACFFE5CC8: Unlike the\r\nC__FEAF4022223844D1906F79DF588CDB8A, this component does not have a KeyPath value. When the\r\nKeyPath value is NULL, then by default the Directory_ value will be utilized as the KeyPath value, which\r\nin this case is TARGETDIR. This component is for CreateFolder, and it contains references to a directory\r\nthat needs to be created explicitly for a particular component. Once emptied during the installation, any\r\ndirectories created during the installation are removed. This component ensures that the directory set in\r\nTARGETDIR exists during and after the installation. \r\nCreateFolder Table, as seen from the Orca tool\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 22 of 32\n\nTo understand the behavior of this MSI, inspecting Custom Action is necessary. The CustomAction table contains\r\nfour actions; however, the main actions of this malware are _9BED75AC_30E3_4BB1_9F26_1A4F247F32EF\r\nand DIRCA_TARGETDIR. \r\n1. _9BED75AC_30E3_4BB1_9F26_1A4F247F32EF: Fetch and execute binary\r\n_C212458FE5F810E2D8287472A14C2665\r\n2. DIRCA_TARGETDIR: Sets a target directory (TARGETDIR) to a local appdata directory\r\n(LocalAppDataFolder\\ProductName)\r\nCustom Action Table\r\nThe first action (_9BED75AC_30E3_4BB1_9F26_1A4F247F32EF) refers to the source\r\n(_C212458FE5F810E2D8287472A14C2665), which is found under the Binary table. \r\nBinary Table, as seen from the Orca tool\r\nThe Custom Action _9BED75AC_30E3_4BB1_9F26_1A4F247F32EF has Type 3590, which indicates\r\ncombinations of the type and relevant option. \r\nType 6: Indicates VBScript stored within the Binary Table. \r\nOptional Term +3584: Indicates a scheduled execution after the successful completion of InstallFinalize\r\naction.\r\nWith further investigation on Custom Action _C212458FE5F810E2D8287472A14C2665, the VBScript appears to\r\nexecute dropped module (1.dll) from Component C__FEAF4022223844D1906F79DF588CDB8A via\r\nregsvr32.exe. \r\nVBScript _C212458FE5F810E2D8287472A14C2665\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 23 of 32\n\nThe second Custom Action DIRCA_TARGETDIR configures the installation directory in the designated\r\nsubdirectory (ProductName) of the local AppData directory (LocalAppDataFolder). The Product Name in this\r\ncase has been named (SetupTest) as designated in the Property Table. As a result, DIRCA_TARGETDIR action\r\nconfigures the installation directory as  (C:\\Users\\\u003cUserName\u003e\\AppData\\Local\\SetupTest).\r\nOutput folder path for installed file(s)\r\nFrom inspecting the MSI, it is evident that the malware drops a module (1.dll) onto the subdirectory (SetupTest) of\r\nthe local appdata directory, which executes it by calling the VBScript embedded in the Binary table. \r\nQBot Attack Tree, as seen from the Cybereason platform\r\nQbot MSI infection flow\r\nComparative Chart\r\nThe following chart identifies key points seen in each malware’s MSI behavior introduced in this chapter. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 24 of 32\n\nTechniques in-use\r\nMagniber\r\nRansomware\r\nMatanBuchus\r\nLoader\r\nQbot\r\nSet installation directory to LocalAppDataFolder ✔️ ✔️ ✔️\r\nDump files to installation directory  \r\n \r\n✔️\r\n✔️\r\nCustom Action: Execute executable via specified\r\ncommand line \r\n  ✔️  \r\nCustom Action: Execute PE/script stored in Binary\r\nTable ✔️   ✔️\r\nExecute dumped file in the installation directory   ✔️ ✔️\r\nFake error message   ✔️  \r\nContinuous malicious execution regardless of MSI\r\nfailure.\r\n✔️ ✔️  \r\nComparative Chart\r\nPurple Team\r\nThis chapter focuses on key points for possibly identifying a malicious MSI, as well as a tool which can assist\r\ndefenders to analyze the MSI files, which has already been leveraged in the Blue Team section.  \r\nSuspicious Indicators \r\nThere are three malicious indicators that can identify suspicious MSI files: \r\n1. Mismatch between file detail and digital signature \r\n2. Misleading errors\r\n3. Suspicious installation path \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 25 of 32\n\nCheckpoints\r\nMismatch in File Detail and Digital Signature\r\nMSI files often masquerade as legitimate installation software of well known applications. However, the digital\r\nsignature for the MSI file does not match with the issuing author, as shown in the images below. Mismatches\r\nbetween the description or origin of an MSI file and the digital signature can indicate the file is actually malicious,\r\nespecially when it purports to be from a well-known software vendor. \r\nMagniber Ransomware\r\nMismatch between the file information and the digital signature\r\nMatanBuchus Loader\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 26 of 32\n\nMismatch between the file information and the digital signature\r\nMisleading Errors\r\nMany different types of malware are known to trick victims in various ways. For malware that utilizes MSI, it is\r\nseen to output false error messages either by embedding a script or crashing the installation. The error message is\r\ndesigned to trick victims into thinking the software installation was not successful because the installer or their\r\nenvironment was not configured properly. The false error outputs can indicate malicious activity. \r\nPossible error messages\r\nSuspicious Installation Path\r\nOften, the purpose of an MSI is to install software and drop relevant applications onto a disk. However, when the\r\nroot destination directory for the installation is set to the local AppData folder, this can indicate malicious\r\nbehavior. Legitimate installations usually drop necessary files under C:\\Program Files or C:\\Program Files (x86).\r\nInstallation directory configuration\r\nIn the above image, the malware drops “installation” files into the subfolder (ProductName) of the local AppData\r\nfolder (LocalAppDataFolder). \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 27 of 32\n\nTools \r\nThere are tools defenders can use to analyze MSI files. This section introduces some of the tools and demonstrates\r\ntheir usage. \r\nMsitools\r\nMsitools are a set of tools that allow developers to create and inspect MSI files. However, the tools can be also\r\nused by defenders to analyze malicious MSI files. There are three main Msitools that defenders can use: msiinfo,\r\nmsidump, and msidiff. These tools are command-line-based, which makes them easier to automate and include in\r\na malware analysis pipeline.\r\nMsiinfo\r\nMsiinfo is a command-line tool that allows users to list and extract streams or tables stored in the MSI file.\r\nAs an example, an analyst investigates the relevant MSI file 15f4cfd.msi (Qbot) by executing the streams\r\ncommand-line option and identifies a binary stored in the Binary Table. In order to investigate\r\nBinary._C212458FE5F810E2D8287472A14C2665, the analyst can dump this binary stream by utilizing the\r\nextract command-line option. \r\nOutput streams with msiinfo \r\nMsidump\r\nMsidump is also another command-line tool that dumps relevant tables as idt text and streams stored in an MSI\r\nfile. The investigative method and use is similar to msiinfo. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 28 of 32\n\nOutput streams with msidump\r\nMsidiff\r\nMsidiff is a command-line tool that compares two MSI files by diffing each sample. For example, an analyst may\r\ncompare two different installers for its validity using msidiff. To verify if the two installers are installing and\r\ndumping the same files, the analyst can use command-line option -l to list and compare the files likely to be\r\ndumped. \r\nList of files from msidiff, from the QBot example\r\nOledump.py\r\nOledump.py is a python script created by Didier Stevens that’s mainly utilized to analyze OLE documents. Since\r\nOLE documents are COM Structured Storage, this Python script allows defenders to analyze the MSI file as well. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 29 of 32\n\nOledump.py showing streams from 15f4cfd.msi\r\nEach row consists of the following three columns: \r\n1. Stream Number \r\n2. Stream Size\r\n3. Stream Name\r\nIn most cases, when utilizing MSI file with oledump.py, the stream name is usually incomprehensible, as shown in\r\nthe image above.\r\nOledump.py showing stream 4 detail\r\nBy specifying the stream number with “-s” option, the oledump.py dumps the content of the stream. In the image\r\nabove, the stream 4 has file header MSCF, which is a header for a CAB file. \r\nORCA\r\nORCA is a GUI-based Windows SDK component that allows users to edit and view MSI database tables. An\r\nanalyst can open the MSI file in question and navigate to each table to investigate. The GUI makes the process of\r\ninvestigation simpler since it is visually easier to follow. \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 30 of 32\n\nOrca showing CustomAction table\r\nRecommendations\r\nThe Cybereason GSOC recommends the following actions to detect and respond to malicious MSI attacks:\r\nIn the Cybereason platform, enable both the Signature and Artificial Intelligence modes on the Cybereason\r\nNGAV, and enable the Detect and Prevent modes of these features.\r\nHandle files originating from external sources (email, web browsing) with caution.\r\nContact a Cybereason Defender. The Cybereason MDR team provides custom hunting queries for detecting\r\nspecific threats. To find out more about threat hunting and managed detection and response with the\r\nCybereason Defense Platform, see Managed Detection and Response.\r\nIf you are a Cybereason customer, see the NEST for more information, including custom hunting queries\r\nfor detecting this threat.\r\nCybereason is dedicated to teaming with Defenders to end cyber attacks from endpoints to the enterprise to\r\neverywhere. Learn more about Cybereason XDR, check out our Extended Detection and Response (XDR) Toolkit,\r\nor schedule a demo today to learn how your organization can benefit from an operation-centric approach to\r\nsecurity.\r\nAbout The Researchers \r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 31 of 32\n\nKotaro Ogino, Principal Security Analyst, Cybereason Global SOC\r\nKotaro Ogino is a Principal Security Analyst with the Cybereason Global SOC team. He is involved in threat\r\nhunting, administration of Security Orchestration, Automation, and Response (SOAR) systems, and Extended\r\nDetection and Response (XDR). Kotaro holds a bachelor of science degree in information and computer science.\r\nRalph Villanueva, Senior Security Analyst, Cybereason Global SOC\r\nRalph Villanueva is a Senior Security Analyst with the Cybereason Global SOC team. He works hunting and\r\ncombating emerging threats in the cybersecurity space. His interests include malware reverse engineering, digital\r\nforensics, and studying APTs. He earned his Master’s Degree in Network Security from Florida International\r\nUniversity. \r\nRobin Plumer, Security Analyst, Cybereason Global SOC\r\nRobin Plumer is a Security Analyst with the Cybereason Global SOC team. He analyzes and triages malware\r\noperations and researches new and emerging threats. He earned his Bachelor’s degree in cybersecurity\r\nmanagement from Bournemouth University, UK.\r\nSource: https://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nhttps://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer\r\nPage 32 of 32",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cybereason.com/blog/threat-analysis-msi-masquerading-as-software-installer"
	],
	"report_names": [
		"threat-analysis-msi-masquerading-as-software-installer"
	],
	"threat_actors": [
		{
			"id": "d9b39228-0d9d-4c1e-8e39-2de986120060",
			"created_at": "2023-01-06T13:46:39.293127Z",
			"updated_at": "2026-04-10T02:00:03.277123Z",
			"deleted_at": null,
			"main_name": "BelialDemon",
			"aliases": [
				"Matanbuchus"
			],
			"source_name": "MISPGALAXY:BelialDemon",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775433966,
	"ts_updated_at": 1775826784,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b66785e3843a705173032f89cbf15bb6a885e81c.pdf",
		"text": "https://archive.orkl.eu/b66785e3843a705173032f89cbf15bb6a885e81c.txt",
		"img": "https://archive.orkl.eu/b66785e3843a705173032f89cbf15bb6a885e81c.jpg"
	}
}