Threat Signal Report
Mortar Loader: New tool for Process Hollowing written in Pascal
Mortar Loader is a new process hollowing tool that can be leveraged by threat actors. Process Hollowing is a well-known evasion technique used by adversaries to defeat detection and prevention by security products. Mortar Loader is implemented as an open-source tool for red teamers in the Pascal programming language.
A loader is malicious code or program used for loading the actual payload on the infected machine.
What is Process Hollowing?
Process Hollowing is a method of executing arbitrary code in the address space of a separate live process. It is commonly performed by creating a process in a suspended state then unmapping its memory, which can then be replaced with malicious code.
Adversaries may inject malicious code into suspended and hollowed processes in order to evade process-based defenses.
How does Mortar Loader work?
Mortar has two components, the payload encryptor and the loader itself.
The encryptor runs on the attacker's machine to prepare the selected PE payload. It encrypts it with the blowfish symmetric encryption algorithm and encodes the ciphertext with base64.
The Loader uses memory stream objects to reverse the operations and decode and decrypt the payload using a hardcoded key. It can be compiled as a standalone executable or a DLL. The plaintext payload is executed using the vanilla Process Hollowing technique without writing it to a file on disk
What is the Status of Coverage?
FortiEDR detects and blocks payloads executed by Mortar Loader out-of-the-box as it detects Process Hollowing from the operating system's perspective.
Depending on the enabled set of policies, FortiEDR can block creation of such malicious processes (pre-execution) or malicious operations performed by the payload (post-infection).
Figure 1 - Detection of mimikatz while running disguised as cmd.exe by Mortar Loader.
Mortar Loader (GitHub)
Traffic Light Protocol
|Color||When Should it Be used?||How may it be shared?|
TLP: REDNot for disclosure, restricted to participants only.
|Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused.||Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting. In most circumstances, TLP:RED should be exchanged verbally or in person.|
TLP: AMBERLimited disclosure, restricted to participants’ organizations.
|Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved.||Recipients may only share TLP:AMBER information with members of their own organization, and with clients or customers who need to know the information to protect themselves or prevent further harm. Sources are at liberty to specify additional intended limits of the sharing: these must be adhered to.|
TLP: GREENLimited disclosure, restricted to the community.
|Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector.||Recipients may share TLP:GREEN information with peers and partner organizations within their sector or community, but not via publicly accessible channels. Information in this category can be circulated widely within a particular community. TLP:GREEN information may not be released outside of the community.|
TLP: WHITEDisclosure is not limited.
|Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release.||Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction.|