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.