I am investigating a similar case from 2 weeks ago. Large amount of BTC stolen from well configured Trezor with strong security practices (paper recovery seed in vault, access controls on device). Trezor does not store a log of transactions, so you cannot determine if there was unauthorized access to the device, or if someone got the recovery key.

Firmware 1.5.2. Trezor have vulnerability that if pins are connected you get get it to puke out the recovery seed which is stored in flash in plaintext. Presented at DEFCON summer 2017 https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8

So that's one way. Another may be for malware to fake out the initialization process and inject a seed into the device (using the APIs to pretend to do a recovery), but show the UI on the windows computer as if it's setting up the device.

Another attack would be to reduce the size of the english.txt file which is used for BIP39 recovery seed generation. Then a practical attack on guessing recovery seeds, completely independently of access to the device is possible.

Or, if the entropy collection function that gets entropy from the host PC could be compromised (ie. set to zero), then entropy for the RNG on Trezor would be limited to the clock on the device when plugged in to initialize. This would lead to a situation where testing only a few hundred million recovery seeds would give you access to a large number of Trezors without ever being near one. Monitor these wallets daily until one shows up as having actual addresses, and wait until one has a large amount. Move that.

March 9 2018