We’ve recently observed a Phishing attack which uses PowerPoint Custom Actions instead of macros to execute a malicious payload. Although using PowerPoint attachments is not new, these types of attacks are interesting as they generally bypass controls that assert on macro enabled Office attachments.
- An attacker creates a new PowerPoint presentation and inserts a malicious script/executable. The inserted file is embedded as an OLE object.
- A Custom Action is created set to trigger ‘With Previous’ with the actionfigur ‘Activate Contents’ to execute the embedded OLE object.
- The presentation is saved as a PowerPoint Show file, so that once opened it immediately opens in slide show view.
When a user opens the presentation, it opens in “show mode” displaying the first slide to the user; this triggers the custom action and executes the embedded payload. When the embedded content is executed the user will be prompted with a security warning asking if they want to open/execute the file.
In samples we’ve observed the script was named Powerpoint.vbe likely to further trick users into executing the malicious payload.
Analyzing the presentation contents, it’s evident that some steps were taken by the attacker to hide the inclusion of the script from the user. An image set to look like the presentation header is placed in the foreground covering the embedded Object icon and can easily be moved for further inspection.
By default an inserted object is stored as oleObject1.bin within the ppt/embeddings directory of the archive and will increment based on the number of inserted objects.
Using the psparser.py tool to inspect the embedded file we can view the object metadata and extract the malicious payload.
In this sample the attacker embedded a script (Powerpoint.vse) which will download and execute the file ‘updater.exe’ (c098a36309881db55709a759df895803) from the remote site hxxp://secureemail[.]bz/updater.exe.
The following script available in the Microsoft TechNet Gallery can often be used to decode these VB encoded scripts: https://gallery.technet.microsoft.com/Encode-and-Decode-a-VB-a480d74c
Detecting Malicious Presentations
Attackers looking to leverage custom actions as a delivery vector need to ensure two things:
- An action is triggered when the slide deck starts.
- The action executes an embedded payload.
Additionally, attackers will often attempt to obfuscate the payload name to lure users into allowing execution. Incident responders can use these properties to help identify malicious presentation files.
For a presentation to run automatically as a slide show, the attacker needs to save the file as a PowerPoint Show (ppsx) document, which is identified within the [Content Types].xml file as:
Note: Attackers can bypass the inclusion of this content type by renaming the file to use the legacy .pps extension. This will trigger PowerPoint to open the document in Slide View even though it’s not in the binary format. Renaming to the modern ppsx extension will cause PowerPoint to throw an error…
The attacker will also need to embed content to execute once the action is triggered and is often a script or executable file. Either of these will be embedded within the presentation as an OLE object handled by the legacy Packager server (packager.dll).
By default the embedded object will be contained in a graphicFrame and referenced by an oleObj node in the slide XML markup. Note: the oleObj tag could be contained within other objects if the attacker modifies the output and will contain the tag embed indicating and embedded object
In cases where the embedded content is a script or executable, the progId will be “Package” identifying that there is no native server to handle the content.
As seen in the past, attackers will often move to use legacy Office formats as a way to further obfuscate the content of a document. The modern Office file formats are a standardized XML markup that can be easily analyzed by incident responders and researchers. In contrast the legacy format is a binary file consisting of a number of OLE Streams that are documented within the MS-PPT Specification.
The specification is lengthy at ~650 pages, but luckily we don’t need to fully review the entire implementation. Instead we want to know how OLE Objects are referenced and stored within the format.
Analyzing samples and the specification leads to the following record types that are used to reference embedded or linked OLE objects.
The existence of the RT_ExternalOleEmbed container and the Atom types RT_ExternalOleEmbedAtom and RT_ExternalOleObjectAtom indicates that there is an embedded or linked OLE object and are strong indicators that the file should be further analyzed for malicious content.
The following primary indicators can be used to identify artifacts of the initial infection. Analysts and Incident responders can also use the included Yara rules to help identify malicious documents.
Primary Network Indicators
For existing PhishMe Triage customers these malicious documents are detected using the following rules:
This is another example demonstrating how attackers leverage existing application features to bypass security controls. Instead of relying on macros, the attackers are leveraging slide animation and a custom action to trigger the embedded payload. Additionally, unlike traditional macros the user doesn’t need to take action to enable execution of a scripting language, instead they confirm they want the payload to run. This provides attackers additional options to craft executable or script names, in an effort to trick end users.