emulating encrypted office documents

[cstueckrath]

Hi,

I'm wondering, if TX will emulate office documents, which were encrypted using the hard coded "VelvetSweatshop" password.

See: Encrypted Office Documents - SANS Internet Storm Center 

I cannot test this from here, as I'm not on-site at the moment...

[Thomas_Werner]

Hi Christian,

currently we only support password protected/encrypted archives - Threat Emulation blade support for password protected archives 

To cope with the attack vector of encrypted files (whoch cannot be done on the network) you might take a look at SandBlast Agent: https://www.checkpoint.com/products/sandblast-agent/ 

Regards Thomas 

[cstueckrath]

Thanks for the answer, Thomas.

This case differs from usual encrypted files, though, as the file can be opened in Excel without entering the password.

This means, that any Excel documents encrypted using "VelvetSweatshop" as password won't be emulated and could be opened without entering a password at all?

[Thomas_Werner · Accepted solution]

Hi Christian,

but as far as I understood from the link you provided the file will open and execute perfectly in Excel.

For compatibility reasons, the latest versions of Excel still support this password. Spreadsheets encrypted with this password, will be opened by Excel without prompting the user for a decryption password.

This means that you can evade static analysis with this trick but not our dynamic analysis in the sandbox. Remember we open the file the same way a user opens it and check what´s happening afterwards. If this is malicious we will convict the file as malicious, catch and block it.

Regards Thomas

[cstueckrath]

This means that you can evade static analysis with this trick but not our dynamic analysis in the sandbox. Remember we open the file the same way a user opens it and check what´s happening afterwards. If this is malicious we will convict the file as malicious, catch and block it.

That's what I was looking for.

Thanks - solved!

Best Regards,

Christian

[Charris_Lappas]

Dear Thomas and Christian,

Unfortunately I disagree, see below example:

An email with a password protected office document is received.  It will be passed through the MTA to the Threat Emulation appliance. Since the file is password protected the file will be considered benign. Then the email will be passed as clean to the recipient. The recipient with a Sandblast Agent installed on his PC will open this email and attachment and will enter the password. SBA agent will send this file for emulation again BUT the file is still in password protected state and again won't be recognised as malicious!

Unfortunately to add to this, even that the malicious document calls cmd.exe or powershell.exe the behaviour of this file (normally this should trigger on SBA that something is wrong) is not recognised. 

This is a tested scenario that is waiting for a solution.

Thanks,

Charris

[Thomas_Werner]

Hi Charris,

Charris Lappas wrote:

[...]Since the file is password protected the file will be considered benign.[...]

Not sure where you took this from ?

I have tested it in my lab and the file is perfectly emulated:

1) Created a XLSX with VelvetSweatshop password:

2) Verified that XLSX is really encrypted:

3) Sent it via mail through a SandBlast MTA and looked at VM:

4) Result

   

It´s benign because we saw no malicious behavior in emulation. Not because we missed emulation.

[Charris_Lappas]

You are absolutely right, this applies only to this specific scenario where the password is "VelvetSweatshop". Any other password and the verdict is benign.

Thanks,

Charris

[Thomas_Werner]

Hi Charris,

I´ll try to explain the difficulties with this scenario for any sandbox vendor:

We could identify a password protected office document before emulating it and log this as "non-emulatable".

This could lead to an attacker using this as an "evasion" technique by creating a doc that looks like encrypted but opens without a password protection (like the VelvetSweatshop we discussed earlier).

So we decided for now to try to open all these documents.

Because we are now looking for malicious behavior after execution the challenge now is -> How do you determine that a file has successfully opened/run ?

To my limited programming knowledge there is no API in Windows that you can query which tells you that the password was entered correctly and the document successfully executed all of its payload.

So how do you know that there is a password challenge at all when opening the document ?

Btw, same goes for malicious files that require multiple user inputs to start the malicious behavior ...

As I said before this is a challenge for any sandbox vendor. But remember that all of these attacks require user input to execute.

Also you could easily protect your self in a first step by using Threat Extraction.

This will remove all active content from any document and for encrypted content you have the following option to fail-close:

We are currently working on providing much more detailed "failed emulation" information and also granular fail-close mechanisms.

Also we already gradually improved the emulation when files need user interaction.

Regards Thomas