Skip to content
Naked Security Naked Security

Outlook on the web bans a further 38 file types

Microsoft is about to put another 38 file extensions on its 'too risky to receive' blocklist.

News for Outlook on the web users who regularly email attachments: Microsoft is about to put another 38 file extensions on its too risky to receive blocklist.

Once there – implemented through Outlook’s BlockedFileTypes filter – Outlook for the web recipients will no longer be able to receive attachments using these extensions.

Microsoft already restricts 104 file extensions and, in truth, the 38 added to this list aren’t ones most Outlook for the web users will have need to send often, assuming they’ve heard of some of them at all.

The better-known extensions on the latest list are:

Python.py, .pyc, .pyo, .pyw, .pyz, .pyzw

PowerShell.ps1, .ps1xml, .ps2, .ps2xml, .psc1, .psc2, .psd1, .psdm1, .psd1, .psdm1, .cdxml, .pssc

Java.jar, .jnlp

Digital certificates.cer, .crt, .der

And some less well-known ones:

Windows ClickOnce.appref-ms

Microsoft Data Access Components (MDAC).udl

Windows sandbox.wsb

Vulnerable legacy applications.appcontent-ms, .settingcontent-ms, .cnt, .hpj, .website, .webpnp, .mcf, .printerexport, .pl, .theme, .vbp, .xbap, .xll, .xnk, .msu, .diagcab, .grp

The reason for the move is security.  Attachments, including obscure ones, have long been a popular technique for sneaking malware past inbox security checks when widely used extensions such .docx and .pdf became too obvious.

Outlook’s 142-strong blocklist opens even more clear water between itself and Google whose current Gmail GSuite blocklist contains only the following 44 extensions:

.ade, .adp, .apk, .appx, .appxbundle, .bat, .cab, .chm, .cmd, .com, .cpl, .dll, .dmg, .exe, .hta, .ins, .isp, .iso, .jar, .js, .jse, .lib, .lnk, .mde, .msc, .msi, .msix, .msixbundle, .msp, .mst, .nsh, .pif, .ps1, .scr, .sct, .shb, .sys, .vb, .vbe, .vbs, .vxd, .wsc, .wsf, .wsh

The restriction on Java .js and .jse having been implemented as recently as February 2017.

Bypassing blocking

What happens if there is a genuine need to receive files with a banned extension?

Assuming the sender and recipient aren’t able to use a different email system, the easiest way is for Office 365, Exchange Server, or Exchange Online admins to allowlist specific extensions.

In a strange anomaly, one file extension not on the blocklist is .ace, a compressed WinRAR file format which earlier this year was discovered to have a 19-year-old flaw (CVE-2018-20250) cybercriminals had started exploiting.

Although not discovered by Microsoft, the company was prominent in warning users about the threat posed by malicious files using this file extension.

It’s true that admins can configure Exchange/Outlook to block this extension, but wouldn’t it have been easier to do it by default?

7 Comments

.js is a JavaScript file not a Java file.

Honestly the easiest way to get around the filter is to either create a zip file with the file you are trying to send or just changing the extension.

Password protected zips are pretty common for getting by file scanners… Or legitimately transporting malware for study.

This is only useful if tools introspect the files with banned extensions, In the past a simple as adding a ‘.dat’ extension to the filename subverted the banning process.

Outlook, brought to you by Microsoft, the company who oh-so-brilliantly decided that file extensions should be hidden by default!

I bet there would be significantly fewer exes masquerading as pdfs if those extensions were visable.

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?