ESET discovered a self-defending no evidence leaving troj spread over USB flash drives targeting air gapped environments (nuclear, military)
Thanks for the update Rolf. Luckily most sensible corporations having ownership of their own devices have USB port blocking (unlocked by local administrator) and IT network policy blocking (unlocked by central IT Dept.). Will be interesting to see how BYOD devices fair with this one.
BTW I sent you an email.
Greg
ESET discovered a self-defending no evidence leaving troj spread over USB flash drives targeting air gapped environments (nuclear, military)
ESET welivesecurity.com
Very interesting, thanks ) .
Though I wonder how the practical use of such a tool would work ? .
Besides the (rather obvious) fact that a "nuclear", "military" system should besides being air-gapped have a very limited access (physical) and a set of added precautions, like as Trewmte stated a strict no-run-from-USB set of policies implemented), there are so many "conditions" to have it working that one would need to
1) find someone that has physical access to the machine
2) identify a USB stick this guy has
3) steal the original USB stick of the guy replacing it with an identical looking one containing the trojan
4) make sure that the guy uses the stick on the "target" machine AND that runs from it Truecrypt (possible), Firefox (makes little sense on an air gapped machine wink ) or Notepad++ (improbable).
So, basically, every night the attacker should
a. re-steal the "trojan injected" stick
b. verify that it has gathered the relevant data
c. if it has, replace it with the original stick (or do nothing, but next morning the user will not find the stick and an alarm may be triggered)
d. if it has not, put back the "trojan injected stick" and loop to a. next day until data is found.
All in all it seems to me like improbable that it is targeting high security air-gapped machines, it sounds like it is only an evolved version of an "ordinary" data stealing trojan aimed at "generic use on unsecured machines".
The alternative use could be, still on a poorly secured machine, by an unloyal employee that intentionally wants to steal data and instead of simply copying them on the stick uses this elaborate trick to have - in case he/she is caught - an excuse blaming the infection.
jaclaz
I read about it earlier and ESET makes some pretty bold claims about this particular malwares uniqueness.
As a coder i have writing my own projects earlier to see how well you can hide, then investigate to see if there are artifacts - and there are always artifacts to be found, even if the code runs as a portable app from a stick that wipes its unencrypted executables on termination.
The fact that they were able to analyse the binaries shows that the malware did not protect itself enough, it should have used more entropy for it self decrypting key, making a bruteforce way harder, but maby the malware developers were unable to find more information about the targets and just went with the device ID + stick entropy, which i find odd since the attackers apparently had an insider or some sort of access to the systems in question.
My take on the thing is that AV analytics people are not forensicators, Ask yourself, if it were so advanced - how was the malware detected it in the first place?
Besides the (rather obvious) fact that a "nuclear", "military" system should besides being air-gapped have a very limited access (physical) and a set of added precautions, like as Trewmte stated a strict no-run-from-USB set of policies implemented), there are so many "conditions" to have it working
This is true, you cannot just put an USB stick into a Top Secret system and expect it to run, there are plenty of protection layers that limits its access, and in some organisations with lot of money we are talking about custom code to specifically protect against these kinds of attacks by not making the file system available to removable devices.
However, there are exceptions - we know because of Manning that SIPRNET was one network that did not have these kinds of protections, it had a security model based upon trust and an incident was bound to happen sooner or later.
And btw, there are ways around the "no-run-from-USB" policy, you can simulate a USB keyboard using the USB driver to make it run an executable, regardless of what policy you set, there was a demo of this on Blackhat a few years ago.
However, there are exceptions - we know because of Manning that SIPRNET was one network that did not have these kinds of protections, it had a security model based upon trust and an incident was bound to happen sooner or later.
And btw, there are ways around the "no-run-from-USB" policy, you can simulate a USB keyboard using the USB driver to make it run an executable, regardless of what policy you set, there was a demo of this on Blackhat a few years ago.
Sure ) , and most probably many more ways, I was only highlighting how this particular trojan (and not any other technique) seems like impractical for military/nuclear targets or more simply that stating that it is targeted as such system is a completely gratuitous assumption.
If you think a bit about it, IF that thing was actually targeted at military/nuclear/high security air gapped machines AND IF it was that "good" (or dangerous if you prefer)
1) it won't have been detected at all
2) IF it was detected, the guys that detected it (presumably military/nuclear/high security) would NOT have uploaded it to ESET
3) IF they would have given it to a ESET, they surely would have done so under a pretty tight and enforceable NDA
jaclaz