I believe Adguard and BFP (and others like Blokada) work similarly and that is blocking untrusted known servers e.g. FB, Google etc I doubt they can block anything from untrusted unknown servers e.g. a rogue individual running his own server unless you block his IP address......that comes later
A malware defeating a Sandbox, a VM and an AV - Case Study
- Thread starter HarborFront
- Start date
a good firewall should block any new connections. I use fort knox. I don't use a vm anymore but I do use shadow defender.
Sadly, a firewall, unless it has some kind of IDS/IPS/traffic analysis, won't do much if the connection is made by an abused legitimate process.
fort knox does have a IPS along with many other things, like antispoofing, can make own rules .https://www.netgate.sk/content/view/18/41/
Problem is IDS/IPS are the AVs of traffic, if the threat is new and not catalogued in the database, the effect is as limited as an AV vs a 0-day.
Claiming the malware defeated the VM in this situation, is the same as claiming a thief defeated your alarm, after you disabled it.
As for HarborFront opinion, is the same as claiming your alarm was defeated cause the thief saw it and refused to even try to enter your house.
Both ridiculous, as in both situations the alarm (VM) worked as intended.
As for HarborFront opinion, is the same as claiming your alarm was defeated cause the thief saw it and refused to even try to enter your house.
Both ridiculous, as in both situations the alarm (VM) worked as intended.
- Jan 27, 2018
- 1,415
Pff, I test malware in a VM with Sandboxie using Shadow Defender and Rollbck RX, as far as I know nothing has got past it, however I am not sure as everytime I do a test my computer blue screens and i have to reinstall Windows. But I am 10 for 10, nothing has infected me yet.
Now I understand why @Lightning_Brian 's Security Config 2020 has Sandboxie, Shadow Defender and VMWare Workstation Pro with Norton Security Premium and VS Premium
Advanced Plus Security - Lightning_Brian's 2020 Security Config
Hello Everyone at MT! Hope everyone is having a great day! Here is my 2020 build. I keep fairly current without many changes compared to my last update from Nov. 2019. I will highlight some changes in the change log section so you can see what I have changed in the last few months. Let me know...malwaretips.com
Yeah I take security to a whole new level! haha Yeah call me a little quirky or goofy, but I take things mighty seriously - that is for sure. I lock down all possible avenues when testing stuff. That is why I also have a unique and "my own" backup method using multiple backup software for various reasons. I can back out of whatever mess may be created when testing stuff fairly easily.
Thank you for understanding why @HarborFront !!
~Brian
- Jan 11, 2020
- 220
In the specific case, using all the SW together would have been useless. The malware was voluntarily executed in the Host machine because it did not "work" in the Guest.
To be honest, for testing, nothing is better than a real system. You can find refurbished machines very cheap.
About jumping to the host, there is some exit routes for the malware like memory bug corruption, TCPIP, if the host memory space is a accessing the guest one, etc...
Note that full software virtualization are more susceptible to escapes, reason I never recommended using light virtualization for malware testing.
As I pointed above, networking between host and guests is another exit route, as well as some VM tools/features made for host-guest intercommunications.
And of course, dedicated exploits are possible like the old Cloudburst.
Even if all those situations are uncommon, they still exist, hence if you are really serious about malware testing, investing some bucks in a spare machine is way more efficient than any VMs.
About jumping to the host, there is some exit routes for the malware like memory bug corruption, TCPIP, if the host memory space is a accessing the guest one, etc...
Note that full software virtualization are more susceptible to escapes, reason I never recommended using light virtualization for malware testing.
As I pointed above, networking between host and guests is another exit route, as well as some VM tools/features made for host-guest intercommunications.
And of course, dedicated exploits are possible like the old Cloudburst.
Even if all those situations are uncommon, they still exist, hence if you are really serious about malware testing, investing some bucks in a spare machine is way more efficient than any VMs.
Last edited by a moderator:
- Mar 29, 2018
- 7,625
That doesn't sound like a smooth testing procedure if you need to reinstall Windows each time!
I presume that an issue with testing using a VM, is cases like this where malware detects the VM and then doesn't do anything malicious. If the malware is not detected by signatures, then I guess the behaviour blocking will miss it as it fails to do anything suspicious. This would lead to different test results for tests done on VMs and real Windows installs.
Testing in a VM was accurate a decade ago where malware were not sophisticated, this is not the case anymore.
- Jan 11, 2020
- 220
Sophisticated malware that can detect the presence of a VM has been out there for quite a while. The initial post referred to is from 2009.
- Nov 19, 2012
- 1,121
Malware makers are very clever people, very soon they will find some loopholes in VMs and start to exploit it.
I think every kind of software can be breached, some just take lot of work to be defeated. Just my opinion.
I think every kind of software can be breached, some just take lot of work to be defeated. Just my opinion.
They already found several. But those are mostly use to target corporations.
Most companies use honeypots, not VMs, VMs weren't created to mitigate malware.
TRS-80
Level 1
- Aug 16, 2019
- 46
@Local Host
Nice to see honeypots get a mention.
To Everyone,
Excellent to see a good, robust discussion carried out in such a refined manner. It's certainly provoked some interesting lines of thought and, logic.
Back in the correct time frame(2009,) as some have mentioned, this type of infector was far less common and the flow on effects poorly understood. By today's standards, anyhow.
I am forced, by my own peculiar logic, to believe, given the above, unleashing such malware on a wide open system, somewhat reckless. For the stated time frame, in my humble opinion.
Interesting initial posting! Great discussion!
Like me, the original case is now somewhat old.
Cheers All,
@TRS-80
Nice to see honeypots get a mention.
To Everyone,
Excellent to see a good, robust discussion carried out in such a refined manner. It's certainly provoked some interesting lines of thought and, logic.
Back in the correct time frame(2009,) as some have mentioned, this type of infector was far less common and the flow on effects poorly understood. By today's standards, anyhow.
I am forced, by my own peculiar logic, to believe, given the above, unleashing such malware on a wide open system, somewhat reckless. For the stated time frame, in my humble opinion.
Interesting initial posting! Great discussion!
Like me, the original case is now somewhat old.
Cheers All,
@TRS-80
i will add:
Yes, VMs weren't created to mitigate malware, the original purpose was to permit uses of applications on incompatible devices, test applications, to reduce cost of buying new hardware, improve performances on servers, etc...
Yes, Honeypots are used to misdirect attackers from the real sensitive areas of the network to the dummy ones.
However, VMs can also be used with several security purposes:
- provide "backup" solutions in case of disaster, this is the most common use.
- providing a user's device access to network resources while protecting the datas (example: virtual desktops).
- provide mobile employees the same working environment when outside the company.
- etc.., etc...,
Usage of VMs as malware mitigation option was more a side-effect than a real purpose.
Similar threads
