It's also possible that the online part of the cold storage was hacked.
When doing a payment from cold storage you need another PC with internet access where the TX is created on and broadcasted after it has been signed. it's possible that the online PC was hacked and that the hacker replaced the address BTER wanted to send funds to with one of his own, and that the employee didn't notice the change when signing the TX on the cold wallet.
Possibly but this would just be another form of gross incompetence. A cold wallet is only as secure as its txn data but in this case the cold wallet is only used to fill a hot wallet which makes hardening it against attacks very simple compared to other business models.
The cold wallet can contain the public key of the hot wallet. The easiest way would be to use a single address for loading the hot wallet but HD wallets make it easier to preserve privacy without a loss of security. If the hot wallet is using an HD wallet then the ExtendedPublicKey of the hot wallet is kept on the cold wallet machine and it only signs transactions sending an amount to the hot wallet and change back to itself. This moves all the critical transaction information to the secure offline machine and makes a compromise of the online machine ineffective*. This only applies in a situation where the cold wallet can be restricted to only send funds to a set of secure addresses. A general use cold wallet may not have that luxury but an exchange does and everything should be done to harden the company wallet.
ExampleFor brevity the example uses a single key scenario but this can be done the same way using HD wallet extendedkeys and funds can be sent to ScriptHash (multisig address) instead of PubKeyHash (single key 'normal' address).
Cold Wallet Machine contains:
* Encrypted cold wallet private key
* Hot Wallet Public Key
Online Full node contains:
* Blockchain
* Bitcoind w/ connectivity to bitcoin network peers
* Cold wallet Public Key
* Hot wallet Public Key
STEP 1) Online Machine - use bitcoind and cold wallet public key to locate unspent outputs. Create unsigned transaction sending funds from Cold Wallet to Hot Wallet with change back to cold wallet.
STEP 2) Online Machine -> Cold Wallet Machine - Transfer unsigned transaction* using offline method
STEP 3) Cold Wallet Machine -
Independently verify the txn meets business rules (send acceptable value to hot wallet PubKeyHash and change back to Cold Wallet)
STEP 4) Cold Wallet Machine - Unlock private key and sign transaction.
STEP 5) Cold Wallet Machine -> Online Machine - Transfer signed transaction* using offline method
STEP 6) Online Machine - broadcast transaction to bitcoin network using bitcoind.
*There is another attack vector but it is difficult to exploit and complicates the explanation so it didn't cover it in the example but anyone designing a cold wallet should be aware of it. A transaction input doesn't specify its value so an attacker could infect a user's online computer to provide false input information to the cold wallet. The cold wallet may sign a txn thinking the inputs are worth 100 BTC when in reality they are worth 7,000 BTC. Now if the cold wallet is only sending funds to known secure addresses this doesn't allow the attacker to send funds to any arbitrary address but they could cause the cold wallet to send the difference as a huge fee to miners. If the attacker then prevented the broadcast of this transaction and mined it into a block he could steal funds this way. To prevent this today requires giving the cold wallet not just the transaction but also the prior outputs it is spending so it can independently verify their value. This is secure but greatly increases the complexity and the amount of data to be transferred. If the txn format was updated so that the value of an input was specified this wouldn't be needed. To change that however would require a soft fork or hard fork depending on how it was done.