Divin'n'phishin with executable filetypes on Windows

In order to find phishing payloads, one needs to understand how executable filetypes on Windows are handled, finding which ones can be delivered to mail clients, thus users, without being caught by mail defences in between and without requesting multiple validation steps from that user for execution once clicked on.

Other filetypes are also relevant for phishing even if they are not executable per-se, they are also mentionned in this article.

I am pretty sure all presented filetypes have been documented before but the method used below may be applicable for future Microsoft systems or constrained Windows environments to understand why certain filetypes are blocked.

Extensions and filetypes

Windows systems associate file extensions with programs, that is how it allow users to double-click a .doc document and automatically opens Microsoft Word. These associations are stored on the system and can be changed according to several criterias such as the security policy of a company or the users' favorite software.

These associations can be retreived using the assoc DOS command:

C:\> assoc .doc
C:\> assoc .exe

If we take the exefile from above, it is the file type associated with the .exe extension. The association rules are defined in the assoc manual:

The File extension is used by Windows to determine the type of information stored in the file and therefore which application(s) will be able to display the information in the file. File extensions are not case sensitive and are not limited to 3 characters.

More than one file extension can be associated with the same File Type. e.g. both the extension .JPG and the extension .JPEG can be associated with the File Type “jpegfile”

At any one time a given file extension can only be associated with one File Type.

To see what program handles the filetype, one can use the ftype command:

C:\> ftype Word.Document.8
Word.Document.8="C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE" /n "%1" /o "%u"
C:\> ftype exefile
exefile="%1" %*

Note the difference in the above:

  • Word.Document.8 is using the winword.exe program to run the file, which is given to it as a command-line parameter.
  • exefile association though could be translated by “execute the given file directly” as the .exe files do not need a specific program to run.

The former can give file-execution capability indirectly, depending on the used binary. The later would allow file execution directly via a double-click.

Note: I found out that NirSoft has an utility called FileTypesMan that displays many information on filetypes:

They also have a website on which you can look for filetypes and associated extensions: Find which Windows software can open a file with specified extension (nirsoft.net)

Directly executable filetypes

An easy way to determine what filetypes (and thus what file extensions) can run without the help of another binary is to look for the same pattern than seen above for the exefile filetype. To do that, we can run assoc without any parameter, it will give us the full list of associations for the current machine:

C:\>assoc > assoc.txt

Extract the right part of the obtained association, i-e the “File Type”:

$ cut -d '=' -f2 assoc.txt > types.txt

Resolve filetypes definitions:

C:\> for /f %l in ('type types.txt') do echo %l >> defs.txt && ftype %l >> defs.txt

And look for the pattern seen previously:

$ grep -E '="%1"' defs.txt                      
batfile="%1" %*
cmdfile="%1" %*
comfile="%1" %*
exefile="%1" %*
piffile="%1" %*
scrfile="%1" /S

Without surprise, we find back our exefile filetype. batfile and cmdfile are also associated with well-known file extensions used for shell scripts on Windows:

$ grep -E "(batfile|cmdfile)" assoc.txt
C:\> assoc batfile
batfile=Windows Batch File
C:\> assoc cmdfile
cmdfile=Windows Command Script

Redacting any command in a .bat or .cmd file will result it in execution when it is double-clicked. More uncommon though are the others filetypes:

C:\> assoc comfile
comfile=MS-DOS Application

C:\> assoc piffile
piffile=Shortcut to MS-DOS Program

C:\> assoc scrfile
scrfile=Screen saver


The first one, comfile is associated with the .com files. It is an old file extension from MS-DOS for batch files and executables:

A COM file is a type of simple executable file. On the Digital Equipment Corporation (DEC) VAX operating systems of the 1970s, .COM was used as a filename extension for text files containing commands to be issued to the operating system (similar to a batch file). With the introduction of Digital Research’s CP/M (a microcomputer operating system), the type of files commonly associated with COM extension changed to that of executable files.

We can test to make one from a small binary executing the cmd.exe /K dir command:

using System.Diagnostics;

namespace PhishingExeNet
    internal class Program
        static void Main(string[] args)
                Process.Start("C:\\Windows\\System32\\cmd.exe", "/K dir");
            catch (Exception e)

Once compiled, we simply change the file extension to .com and try to double-click it:

It gets executed straight away as expected.


piffile is associated with .pif file extension. PIF stands for Program Information File and according to wikipedia:

program information file (PIF) defines how a given DOS program should be run in a multi-tasking environment, especially in order to avoid giving it unnecessary resources which could remain available to other programs.

Interestingly in wikipedia’s notes there is the following section:

  • Although a file in PIF format does not contain any executable code (it lacks executable files' magic number “MZ”), Microsoft Windows handles all files with (pseudo-)executables' extensions in the same manner: all .COMs, .EXEs, and .PIFs are analyzed by the ShellExecute function and will run accordingly to their content and not extension, meaning a file with the PIF extension can be used to transmit computer viruses.

Let’s try changing our .exe example file with the .pif extension and double-click it:


SCR stands for SCReen saver. According to SCR - Windows Screensaver File (fileformat.com):

A screen saver is a computer program that fills it with animated images or patterns when no activity performs on a computer for a long time. The screensavers were introduced to prevent phosphor burn-in on plasma, Cathode Ray Tube (CRT) and OLED computer monitors. Screensavers are usually set up to apply a basic layer of security, by requiring a password to re-open the device. Screensavers are usually developed and coded using various programming languages as well as graphics interfaces. Mostly the developers of screensavers use the C or C++ programming languages, along with Graphical libraries or GDIs, such as OpenGL, which works on many platforms capable of 3D rendering. The screensavers output is saved as a portable executable file.

I-e: .scr files are PEs. Let’s try moving our .exe to the .scr file extension and double-click it:

It gets executed the same way as COM or PIF files.

Other interesting/execution-capable filetypes

The above filetypes are, on the system I have tested, the only ones that execute as-is but other filetypes are of interest for a potential attacker.

Windows Script Host (WScript.exe)

WScript.exe is used by Windows to interpret different script languages amongst which VBS and JavaScript. We can check which filetypes are associated with that binary on our assocation list:

$ grep -iE 'wscript.exe' defs.txt
JSFile=C:\Windows\System32\WScript.exe "%1" %*
JSEFile=C:\Windows\System32\WScript.exe "%1" %*
VBEFile="%SystemRoot%\System32\WScript.exe" "%1" %*
VBSFile="%SystemRoot%\System32\WScript.exe" "%1" %*
WSFFile="%SystemRoot%\System32\WScript.exe" "%1" %*
WSHFile="%SystemRoot%\System32\WScript.exe" "%1" %*
C:\>assoc JSFile
JSFile=JavaScript File

C:\>assoc JSEFile
JSEFile=JScript Encoded File

C:\>assoc VBEFile
VBEFile=VBScript Encoded File

C:\>assoc VBSFile
VBSFile=VBScript Script File

C:\>assoc WSFFile
WSFFile=Windows Script File

C:\>assoc WSHFile
WSHFile=Windows Script Host Settings File

Many of these scripting languages allow for command execution. Here is a small VBS script as an example:

Dim oShell
Set oShell = WScript.CreateObject ("WScript.Shell")
oShell.run "cmd.exe /K dir"

Save that file to .vbs extension and try to double-click it:


Java archives (JAR) files can also be opened directly on the tested Windows system:

$ grep 'javaw.exe' defs.txt                                                                                                            
jarfile="C:\Program Files\Java\jdk-19\bin\javaw.exe" -jar "%1" %*

If we make a small Java program:

import java.io.*;

public class Phishing {
        public static void main(String[] args){
                try {
                        Process process = Runtime.getRuntime().exec("cmd.exe /c dir > %temp%\\java_phishing.txt");
                } catch (Exception err) {

        public static void printResults(Process process) throws IOException {
                BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
                String line = "";
                while ((line = reader.readLine()) != null) {

Compile it, make a JAR from it and double-click it:

It run without issues but only because the tested system has the Java Runtime (JRE) installed.

Interpreted languages

More generally, any file extension automatically associated with a code interpreter is a potential vector for attackers. Thus the system I tested did not have python or perl installed, these would work the same way as the above examples.


The LOLBas project provides binaries' names that can be used for execution on Windows systems. If we cross-search that list with the file extension associations we have for a machine, we can find execution-capable filetypes.

For example, the hh.exe binary:

$ grep -E 'hh.exe' defs.txt
chm.file="%SystemRoot%\hh.exe" %1
C:\>assoc chm.file                                                                                                                           chm.file=Compiled HTML Help file  

is associated with chm.file filetype. So a CHM file (.chm) will be given as a direct argument of hh.exe. That is an “Execute” case documented by LOLBas:


Executes calc.exe with HTML Help.

HH.exe c:\windows\system32\calc.exe

This time it is not as straightforward as changing the file extension:

There are ways to create a malicious CHM file though.

One has to download the HTML Help Compiler (hhc.exe) that can be found with Microsoft’s HTML Help Workshop (found it only on the wayback machine)

The compiler needs a help project file:

C:\> & 'C:\Program Files (x86)\HTML Help Workshop\hhc.exe' /?
Usage:   hhc <filename>  
    where <filename> = an HTML Help project file
Example: hhc myfile.hhp  

We can create a minimal one:


The associated HTML file:

<OBJECT id=x classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11" width=1 height=1>
  <PARAM name="Command" value="ShortCut">
  <PARAM name="Button" value="Bitmap::shortcut">
  <PARAM name="Item1" value=',cmd.exe,/c dir > %temp%\chm_phishing.txt'>
  <PARAM name="Item2" value="273,1,1">

And compile it:

C:\> & 'C:\Program Files (x86)\HTML Help Workshop\hhc.exe' .\Project.hpp
Microsoft HTML Help Compiler 4.74.8702

Compiling c:\Project.chm

Compile time: 0 minutes, 0 seconds
1       Topic
0       Local links
0       Internet links
0       Graphics

However, double-clicking the resulting CHM gives a warning the user has to approve:

If the user clicks yes, the command gets executed:

Other phishing-relevant filetypes

There are attachments filetypes of interest for phishing mails that are not execution-capable. For example, the ones that can trick a user into giving his credentials.

Filetypes opening a browser

We can check for filetypes started with iexplore.exe:

$ grep -i 'iexplore.exe' defs.txt    
giffile="C:\Program Files\Internet Explorer\iexplore.exe" %1
htmlfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
mhtmlfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
IE.AssocFile.PARTIAL="C:\Program Files\Internet Explorer\iexplore.exe" %1
svgfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
Microsoft.Website="C:\Program Files\Internet Explorer\iexplore.exe" -w "%l" %*
xhtmlfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
MSSppLicenseFile="iexplore.exe" "%1"

They resolve to the following file extensions:


An attacker could mimick a known legit website (such as https://login.microsoft.com) in an HTML file, define the extension of this file to one of the above and send it as a mail attachment to trick users into thinking they are authenticating to that website. By clicking on the file, the user’s browser would open and he would be presented with the rogue web page.

Filetypes opening Windows Explorer

$ grep 'explorer.exe' defs.txt     

These resolve to:


SCF files can be used to gather NTLM credentials.

OSDX files are sort of descriptions to add search providers for Explorer, like this one:

<OpenSearchDescription  xmlns="http://a9.com/-/spec/opensearch/1.1/">  
  <Description>iFinder Search</Description>  
  <Url type="application/rss+xml" template="http://ml-if-ifinder/iFinder5_1/api/opensearch?sSearchTerm={searchTerms}&amp;limit={count}&amp;start={startIndex}"></Url>  

Apart from adding a new rogue provider, I do not know if this can be used by an attacker for anything else.


To prevent malicious attachments using the filetypes described above to go through one’s mail defences, I would suggest that one implements an allow list (wether it is in a mail “middlebox” or in the mail client) containing the file extensions one need for its usage. I think denylisting these filetypes is a strategy of failure as it is highly probable that not every case is included in the deny list.

For the case of indirect execution-capable filetypes that are business critical such as .doc or .xls for many companies though, I have no magic bullet but I can suggest the following questions to ask yourself if you are in that position:

  • How often do you need Office macros in your business?
  • Can I restrict it to the XML versions like docx or xlsx.
  • Can I get a software/solution to strip macros from these files from external senders?

There will always be a risk if these filetypes are allowed to go through.