List: potential insecure file types

[Florian]

hello choombas

 

i just want to ask what are the filetypes you would recommend to block. current best list i know is the one from https://www.govcert.ch/

 

additional i would add .doc, .xls, ... all these legacy office types.

what would you add?

should be create a repo where we can gather all these file types for further use in a SIEM?

# Archive files (if possible, block .zip and .rar as well)
.001
.7z
.ace
.arj
.bin
.bz
.bz2
.bzip
.bzip2
.cab
.cpio
.deb
.dmg
.fat
.gz
.gzip
.hfs
.img
.iso
.lha
.lzma
.lz
.lzh
.mht
.mime
.ntfs
.r00
.r01
.r02
.r03
.r04
.r05
.r06
.r07
.r08
.r09
.r10
.r11
.r12
.r13
.r14
.r15
.r16
.r17
.r18
.r19
.r20
.r21
.r22
.r23
.r24
.r25
.r26
.r27
.r28
.r29
.rev
.rpm
.smi
.squashfs
.swm
.tar
.taz
.tbz
.tbz2
.tgz
.tnef
.tpz
.txz
.uu
.uue
.uuencode
.vhd
.webarchive
.wim
.xar
.xxe
.xz
.z

# Code files
.asax
.ashx
.asp
.bas
.btm
.cla
.class
.csh
.ksh
.mhtm
.mhtml
.pl
.plg
.ps1
.ps1xml
.ps2
.ps2xml
.psc1
.psc2
.sh
.vb
.wml
.xbap
.xdp

# Executables
.app
.bat
.cmd
.com
.dll
.exe
.jar
.jnlp
.js
.jse
.lnk
.msi
.msp
.mst
.ocx
.pif
.scr
.tlb
.url
.vbe
.vbs
.ws
.wsc
.wsf
.wsh

# Media files (.wav & .mp3 files are not on the list, as they are commonly used for voice messages)
.aac
.acm
.aif
.asf
.asx
.avb
.avi
.dib
.f4v
.fcs
.flv
.gms
.its
.m3u
.m4v
.mcf
.mic
.mov
.mp2
.mp4
.mpeg
.mpg
.ogg
.otrkey
.pcd
.ra
.ram
.rm
.rmj
.rv
.tsp
.vdo
.viv
.vob
.vr_ie5
.wax
.wma
.wmf
.wmv

# Office files
.accde
.ade
.adp
.cnv
.dochtml
.docm
.docxml
.dot
.dothtml
.dotm
.dotx
.dqy
.fxp
.iqy
.mad
.maf
.mag
.mam
.maq
.mar
.mas
.mat
.mau
.mav
.maw
.mda
.mdb
.mde
.mdt
.mdw
.mdz
.mpd
.one
.ops
.osd
.pot
.potm
.ppa
.ppam
.pps
.ppsm
.ppsx
.pptm
.pst
.pub
.pwz
.sldm
.slk
.vbp
.vsmacros
.vss
.vst
.vsto
.vsw
.wbk
.wiz
.xla
.xlam
.xld
.xlk
.xll
.xlm
.xlsb
.xlsm
.xlt
.xltm
.xlw
.xmls
.xmlx
.xnk

# System files
.386
.3gr
.ani
.application
.appref-ms
.appx
.appxbundle
.appxmanifest
.blg
.camp
.cdmp
.cer
.chm
.cnt
.compositefont
.cpl
.crl
.crt
.der
.drv
.fon
.gadget
.grp
.hlp
.hpj
.ht
.hta
.htt
.hxs
.igp
.inf
.ini
.ins
.isp
.job
.key
.msc
.msh
.msh1
.msh1xml
.msh2
.msh2xml
.mshxml
.pnf
.prf
.prg
.reg
.scf
.sct
.settingcontent-ms
.shb
.shs
.sys
.tmp
.ttf
.vxd
.wbt

[karlyeurl]

It's unclear to me in which context you want to block file types, but I'm not sure what is achieved by blocking common extensions such as archives and multimedia files.

 

In my (admittedly limited) experience, blocking files causes more confusion and inconvenience than not. "I sent you that email" "No you did not" "Yes, yes I did, it had a .zip attachment", and unfortunate time is wasted. Modern AV engines (such as the one shipped in Windows, I am sure) scan files before doing anything fancy with them, and their detection mechanisms are fare more advanced than extension/mime-type matching.

[Florian]

from my point of view is this just a basic layer of course but still. 

there is stuff which should not be used in a company environment. e.g. there is no need to run .vbs scripts. event modern AV check that kind of stuff, this things have to be configured. -> remap filetypes to other applications, block in email etc.

 

it's for cases like follina etc.

[j91321]

5 hours ago, Florian said:

there is stuff which should not be used in a company environment. e.g. there is no need to run .vbs scripts

Yeah this may work on paper, but not in reality. Context is needed. If for example you are looking at email attachments you can consider using allow-listing not deny-listing, but this has to be implemented as a policy, the users have to be aware of it and ideally have a possibility to retrieve blocked attachments. Even something simple sounding as this may end up being unusable depending on your environment needs size and technology available.

[munin]

n.b. malware's going to show up disguised as something 'allowed' like a docx or what have you. Blocking files by ostensible 'type' is honestly only going to annoy people who will then proceed to use encrypted .zips or whatever as the normal means of interchange, which loses you even the minuscule bit of metadata you might otherwise get about the file.

If you -do- have a genuine need to block files for some compliance jackass or other, I'd recommend auditing to find out which ones are used by the organization's choice of applications and allowlist those instead. There's new kinds of file types coming out all the time, and doing this with a blocklist is just asking for constant and unending pain.

Also, can you perhaps condense those very long lists into a table or something in the future?

[v0ltage]

At the gateway level we block some of these file types, but not all as people do send files, archives etc.  We do tag some of these messages in rules to alert the user for example if an archive is password protected.  We are doing some work next year with DMARC/DKIM to identify our trusted third parties and types of files they send.  So in theory we could do something like this but I'd be skeptical on the practicalities of implementing it as such without thorough testing.

At the endpoint level it's more tricky, I'd be more focused about behavior and identifying TTP's of the attack then a specific file type.  Particularly for emerging threats and the IOC's / intelligence you gather to help tune your endpoint solution (if you have such a capability).  You have to account for business processes & requirements (rightly or wrongly) and how these teams interact or work through these processes/requirements.    For the most part we have removed admin rights from our users now, solution isn't perfect but affords us some protection and monitoring.