3 ms·

If I'm mistaken, then just point out why. I'd rather know. It might be worth considering why it might have been suggested, and what local virtualization offers

If I'm mistaken, then just point out why. I'd rather know. It might be worth considering why it might have been suggested, and what local virtualization offers that AWS or DigitalOcean might not. What does local virtualization offer that AWS or DO don't? For my own part, I've engineered services that offer precisely the featureset you've described. We found compelling reasons to not do so on AWS or similar. While your conclusions may obviously differ substantially, it may be wise to arrive at them with full knowledge of why others made their decisions. Such as? I'm not doubting you, so please don't take it as such. On the other hand, if you don't have time to describe your findings then no worries. I'll likely rediscover the wisdom independently.

Kalium 9y ago
Please accept my apologies. I was under the mistaken impression that I had outlined some of the difficulties previously upthread. Allow me to remedy this error. Having control over the virtualization as the host offers a lot of power to protect yourself, contain your infected virtual machines, and perform analysis. Using EC2 instances as your victims means giving up much of that. For example, I don't know of a way offhand to perform a full memory dump of a running EC2 instance without its cooperation. Memory dumps can be very useful forensic data, but Volatility cannot be run against an EC2 instance. Other items that come to mind include the ability to falsify clock behavior, more or less arbitrary simulated hardware, and the ability to pause execution. All of these can be very useful in malware analysis. Also, needless to say, running live malware so you can passively watch its live behavior without isolating it from the world is perhaps not ideal behavior. No responsible engineer wants to see their analysis machine involved in an attack. Such things have happened when insufficiently cautious engineers, with the purest and greatest of intentions, hooked up live malware to the internet. I hope these points have helped you understand. Please don't hesitate to ask if you have further questions.
FreakLegion 9y ago
I led the team for WildFire (the most widely used commercial sandbox and, I believe, the first one in the cloud) at Palo Alto Networks. If anyone from FireEye or Lastline is around, maybe they'll chime in as well. The design of the analysis system itself determines your deployment constraints. For example, will you give the malware an open line to the Internet? If not, you'll miss out on most of its activity[1], but won't be limited in terms of hosting. If, on the other hand, you give the malware free reign, AWS wants no part of that (we tried it). 1. See the (speculated) anti-analysis kill switch in WannaCry. This sort of thing is common. But more fundamentally, malware also tends to work in stages, and often won't do much if it can't phone home.

Kalium 9y ago

Please accept my apologies. I was under the mistaken impression that I had outlined some of the difficulties previously upthread. Allow me to remedy this error. Having control over the virtualization as the host offers a lot of power to protect yourself, contain your infected virtual machines, and perform analysis. Using EC2 instances as your victims means giving up much of that. For example, I don't know of a way offhand to perform a full memory dump of a running EC2 instance without its cooperation. Memory dumps can be very useful forensic data, but Volatility cannot be run against an EC2 instance. Other items that come to mind include the ability to falsify clock behavior, more or less arbitrary simulated hardware, and the ability to pause execution. All of these can be very useful in malware analysis. Also, needless to say, running live malware so you can passively watch its live behavior without isolating it from the world is perhaps not ideal behavior. No responsible engineer wants to see their analysis machine involved in an attack. Such things have happened when insufficiently cautious engineers, with the purest and greatest of intentions, hooked up live malware to the internet. I hope these points have helped you understand. Please don't hesitate to ask if you have further questions.

FreakLegion 9y ago

I led the team for WildFire (the most widely used commercial sandbox and, I believe, the first one in the cloud) at Palo Alto Networks. If anyone from FireEye or Lastline is around, maybe they'll chime in as well. The design of the analysis system itself determines your deployment constraints. For example, will you give the malware an open line to the Internet? If not, you'll miss out on most of its activity[1], but won't be limited in terms of hosting. If, on the other hand, you give the malware free reign, AWS wants no part of that (we tried it). 1. See the (speculated) anti-analysis kill switch in WannaCry. This sort of thing is common. But more fundamentally, malware also tends to work in stages, and often won't do much if it can't phone home.