- Jun 9, 2013
- 6,720
The links will become available to after you have made 100 posts here at MT.
- Jul 22, 2014
- 2,525
Guys, I still don't understand... How do I isolate VM from the real system? I want to perform several dynamic tests, but I keep 6TB of my data on my HDDs
If you have valuable data don't risk, use a dedicated test PC.
(In the theory the VM should separate the host from the VM...In reality it is not 100%sure, even less if you use VM extension, share folder, etc..).
- Feb 13, 2017
- 1,486
How many virtualization systems you want to use? Double virtualisation doesn't brings benefits, VBox is more than enough if you use NAT + VPN and you do not enable shared folders.
Also SD is a good choice but keep in mind that any personal data is virtualized, but accessible to malware and possibly stolen.
Better not to have data or encrypt them.
- Apr 28, 2015
- 8,948
I think You need at least 100 posts on the forum...
The rules are in place for a good reason.
You're a member since yesterday and already you want to criticize these rules?
This...is funny.
Eeach tester reached 100 posts. You will reach them too. Please respect the rules.
Handling malware requires experience/precaution because if you do not do it correctly then you can end up infecting your system (or others), and while MalwareTips itself and/or other members are not responsible for damages caused by people handling malware submitted into the virus exchange, they like to take precautions to reduce the chances of something like this happening (by not providing someone access unless they have been at the community for a certain period of time and show an understanding to use the submissions responsibly).
The above is just a personal thought of why the restriction could be in place, however another valid potential reason could be to prevent people who are not trusted from going near the samples, generally-speaking.
If you would like to test malware then feel free to do so, there are many free online sources to obtain malware samples, or alternatively you could start hunting and find zero-day samples on your own and then if one day you reach the 100 post requirement and are permitted access then you could also submit samples to help the testers here and AV vendors (SUD samples) - make sure that you don't aimlessly post to reach the requirement.
Rules are rules and everyone is treated the same; if you follow the rules then all will be good, and if you don't then it causes problems for other members and the forum itself. They are in place for good reasons.
As to the question how to isolate a VM. I use VMware Workstation Pro 12.5 But to further isolate it I run Appguard, and all my VMware processes are Guarded. Why? Because Appguard has memguard, and all guarded apps have memory protection against memory read/write. So the vmware processes can't be abused for memory transfere.
Oracle VM VirtualBox
Kaspersky Small Office Security17.0.0.611
Shadow Defender
Use a personal device in a fake environment with a freezer program
Sometimes I can try the Avira program
I use a program avast_secureline vpn
Kaspersky Small Office Security17.0.0.611
Shadow Defender
Use a personal device in a fake environment with a freezer program
Sometimes I can try the Avira program
I use a program avast_secureline vpn
@tiktoshi I recommend you make sure you perform all your malware testing under the Virtual Machine, because data theft can still occur in the environment and thus by using Shadow Defender for malware testing on your Host environment, you leave your passwords (for web-browser), chat logs from IM software, personal documents and any other sensitive content at risk. You also leave the risk of a potential modification which Shadow Defender may not yet cover/even know about not being reverted after the reboot to auto-clean what happened in the environment during malware testing.
Avast SecureLine is a good VPN, make sure it's running from the Host environment so malware cannot activate a kill-switch under the analysis environment. If you're using Shadow Defender/freezing software under the Virtual Machine itself, this is unnecessary and a waste of resources; make sure you disable shared folders and clipboard sharing as these are two high-value targets for potential exploitation considering they do end up sharing a direct link between the virtual environment and the host environment (If I was trying to develop Guest - Host exploitation, I'd probably try targeting ROP chain exploitation after replicating the functionality from those features via Reverse Engineering).
Some malware will identify a Virtual Machine environment. You can try to hide identifiers (e.g. from registry) and similar, and also place dummy but genuine-looking documents around the environment. You can do a lot more but unless you're a reverse engineer then the other options won't be applicable.
Avast SecureLine is a good VPN, make sure it's running from the Host environment so malware cannot activate a kill-switch under the analysis environment. If you're using Shadow Defender/freezing software under the Virtual Machine itself, this is unnecessary and a waste of resources; make sure you disable shared folders and clipboard sharing as these are two high-value targets for potential exploitation considering they do end up sharing a direct link between the virtual environment and the host environment (If I was trying to develop Guest - Host exploitation, I'd probably try targeting ROP chain exploitation after replicating the functionality from those features via Reverse Engineering).
Some malware will identify a Virtual Machine environment. You can try to hide identifiers (e.g. from registry) and similar, and also place dummy but genuine-looking documents around the environment. You can do a lot more but unless you're a reverse engineer then the other options won't be applicable.
Drod PCGeek
New Member
- Dec 7, 2017
- 1
You could also use a paid VPN since it will secure you connection and hide your IP address (obviously).
My favorites: NordVPN and Hide.me
@Drod PCGeek The advice about the router from @SloppyMcFloppy was very good, because with or without a Virtual Private Network, a local infection can still attempt to attack the local-host. A Virtual Private Network re-routes the connections which are out-going to third-party external sources by forwarding through the VPN server's instead of allowing your router to pass through to your Internet Service Provider (ISP) which then connects to the target destination; the process of execution is changed to connect to the VPN provider's server destination via your ISP, and the results are sent back to the client after the VPN server has connected to the original target destination.
However, destinations such as the local host, those won't be re-routed. They'll maintain their position, and thus even if your router is "secure", an attacker could deploy a known exploit for the router in use, or attempt to brute-force through the password protection; if they can successfully deploy such attacks and get results from it, they can compromise your router without you even knowing, unless you reverse-engineered the threat to understand what it was doing and how it managed to do it, or someone else did and notified you of such. I've had ransomware samples in my analysis environment which have tried local-host brute-force attacks like this, of course they weren't successful though. Other ones I've seen which are local-host attack based will attempt to connect to 192.168.0.X until it finds the correct one, and then tries to attack further.
Therefore, the separate router advice from @SloppyMcFloppy was actually sound advice. Even the separate machine for testing, which will aid in preventing Anti-VM techniques from catching you out without you noticing. You can use a Virtual Environment which appears just like an average one to running malware but this comes with great modifications... If you have a kernel debugger remotely attached (which you may do if you have a custom driver for file-system mini-filter monitoring and alike) you must patch so NtQuerySystemInformation cannot detect the genuine results when queried with the SystemInformationClass for querying such details, you must hide up process/registry/file-system GUIDs, etc. It is a bit of work but it can be done. You can also use recovery software on a dedicated machine to replicate snapshots in a Virtual Machine to make things a lot easier. A dedicated machine for analysis of malware is a very good bonus, especially if you'll have more hardware resources than in a VM.
Moving back to VPN discussions, ensure that the VPN is on the Host environment, or hardware-based. This will prevent the malicious software from performing a kill-switch. VPN software doesn't tend to have "self-defence" mechanisms, and thus by ending the services (actually, targeting something like OpenVPN which is likely being used will do the job in itself) will be a valid kill-switch. You don't actually have to specifically exploit the VPN software, and an elevated attack will have access to such elevated Session 0 services used by the VPN provider, and will have the ability to unload any drivers used by VPN software. Free VPN software will do just fine as well though in a lot of cases. E.g. CyberGhost Free will work fine on the Host environment, and it won't automatically disconnect until the time period ends. As long as you keep track of the disconnection time period then you'll be fine.
The reason you don't want an attacker to gain your IP address is because:
a). Your IP address will be linked to a malicious operation. This can raise questions about why your IP address was found linked to a malicious server and actually cause an investigation into yourself as a tester of malicious software.
b). An attacker can deploy a botnet attack targeting your IP address for whatever reason, or a normal DDoS attack. A botnet attack targeting your and others IP addresses would typically be for a DDoS attack.
c). Other types of attacks using someone's IP address can include attacks such as Port scanning. If open ports are found, this can lead to further attacking. Such scans can lead to the finding of an exploitable vulnerability.
For the record, DDoS is a Denial of Service type attack, and it evolves around using up the resources of the destination target's network (as well as the attackers for that matter) by sending useless packets constantly at a spammed rate. Eventually, once all the resources cannot take anymore, a crash happens. This will then leave the destination even more vulnerable if the security crashed due to the circumstances of lack of resources, or just completely take the target destination (network) down. DDoS attacks can lead to a lot of harm sometimes, and an unexpected crash on a network which is very important in a enterprise environment can lead to other things, like data corruption (data-loss) of sensitive, critical and very expensive content.
It is actually not uncommon for professional malware analysts to spoof the network, and trick a sample into believing it is connected to a network. This is a trick I especially like to do because it prevents me from actually assisting in a malicious operation while performing analysis accidentally, in the case of the malware carrying out a Botnet attack, or similar. After doing this, I can take my analysis notes and perform more investigation with network activity allowed (but monitoring and control over it), or on specific targets the sample attempted to query too while it believed the network was available when it really wasn't.
Routers actually tend to be a lot easier to exploit than some may think, and many vulnerabilities are found all the time. Of course, exploitation of the Router will be dependent on many factors. For example, an exploit for a specific manufacturer's Router, and a specific Model build, won't be valid across all Routers which can be used by someone. But the attack vector still exists, and the potential for attack for this should not be ignored. Anything can happen, you never know what is waiting for you around the corner... Better be safe than sorry.
I believe @tim one uses a dedicated router for testing of malicious software. I have a spare one which I've used before, but I don't always use it because it usually isn't necessary for me to do so. Separate system though? Well that is a massive benefit, I take advantage of it often and it is very nice. So if you can, do make use of such. At the end of the day, if you have more resources to have a better, and better-protected analysis environment, do make use of them.
Another sound tip would be to use a Firewall on your Host environment (at a minimum). This can help you control connections from within the Virtual Environment because the connections occurring in the Virtual Environment will still pass through to the Host environment - and thus will pass through the Windows Kernel on the Host environment, allowing the Firewall software installed to intercept the activity. This is why security software tends to be able to block malicious URLs within a Virtual Environment, despite being installed on the Host environment, and why we know Firewalls can intervene as well sometimes depending on how they were built.
However, destinations such as the local host, those won't be re-routed. They'll maintain their position, and thus even if your router is "secure", an attacker could deploy a known exploit for the router in use, or attempt to brute-force through the password protection; if they can successfully deploy such attacks and get results from it, they can compromise your router without you even knowing, unless you reverse-engineered the threat to understand what it was doing and how it managed to do it, or someone else did and notified you of such. I've had ransomware samples in my analysis environment which have tried local-host brute-force attacks like this, of course they weren't successful though. Other ones I've seen which are local-host attack based will attempt to connect to 192.168.0.X until it finds the correct one, and then tries to attack further.
Therefore, the separate router advice from @SloppyMcFloppy was actually sound advice. Even the separate machine for testing, which will aid in preventing Anti-VM techniques from catching you out without you noticing. You can use a Virtual Environment which appears just like an average one to running malware but this comes with great modifications... If you have a kernel debugger remotely attached (which you may do if you have a custom driver for file-system mini-filter monitoring and alike) you must patch so NtQuerySystemInformation cannot detect the genuine results when queried with the SystemInformationClass for querying such details, you must hide up process/registry/file-system GUIDs, etc. It is a bit of work but it can be done. You can also use recovery software on a dedicated machine to replicate snapshots in a Virtual Machine to make things a lot easier. A dedicated machine for analysis of malware is a very good bonus, especially if you'll have more hardware resources than in a VM.
Moving back to VPN discussions, ensure that the VPN is on the Host environment, or hardware-based. This will prevent the malicious software from performing a kill-switch. VPN software doesn't tend to have "self-defence" mechanisms, and thus by ending the services (actually, targeting something like OpenVPN which is likely being used will do the job in itself) will be a valid kill-switch. You don't actually have to specifically exploit the VPN software, and an elevated attack will have access to such elevated Session 0 services used by the VPN provider, and will have the ability to unload any drivers used by VPN software. Free VPN software will do just fine as well though in a lot of cases. E.g. CyberGhost Free will work fine on the Host environment, and it won't automatically disconnect until the time period ends. As long as you keep track of the disconnection time period then you'll be fine.
The reason you don't want an attacker to gain your IP address is because:
a). Your IP address will be linked to a malicious operation. This can raise questions about why your IP address was found linked to a malicious server and actually cause an investigation into yourself as a tester of malicious software.
b). An attacker can deploy a botnet attack targeting your IP address for whatever reason, or a normal DDoS attack. A botnet attack targeting your and others IP addresses would typically be for a DDoS attack.
c). Other types of attacks using someone's IP address can include attacks such as Port scanning. If open ports are found, this can lead to further attacking. Such scans can lead to the finding of an exploitable vulnerability.
For the record, DDoS is a Denial of Service type attack, and it evolves around using up the resources of the destination target's network (as well as the attackers for that matter) by sending useless packets constantly at a spammed rate. Eventually, once all the resources cannot take anymore, a crash happens. This will then leave the destination even more vulnerable if the security crashed due to the circumstances of lack of resources, or just completely take the target destination (network) down. DDoS attacks can lead to a lot of harm sometimes, and an unexpected crash on a network which is very important in a enterprise environment can lead to other things, like data corruption (data-loss) of sensitive, critical and very expensive content.
It is actually not uncommon for professional malware analysts to spoof the network, and trick a sample into believing it is connected to a network. This is a trick I especially like to do because it prevents me from actually assisting in a malicious operation while performing analysis accidentally, in the case of the malware carrying out a Botnet attack, or similar. After doing this, I can take my analysis notes and perform more investigation with network activity allowed (but monitoring and control over it), or on specific targets the sample attempted to query too while it believed the network was available when it really wasn't.
Routers actually tend to be a lot easier to exploit than some may think, and many vulnerabilities are found all the time. Of course, exploitation of the Router will be dependent on many factors. For example, an exploit for a specific manufacturer's Router, and a specific Model build, won't be valid across all Routers which can be used by someone. But the attack vector still exists, and the potential for attack for this should not be ignored. Anything can happen, you never know what is waiting for you around the corner... Better be safe than sorry.
I believe @tim one uses a dedicated router for testing of malicious software. I have a spare one which I've used before, but I don't always use it because it usually isn't necessary for me to do so. Separate system though? Well that is a massive benefit, I take advantage of it often and it is very nice. So if you can, do make use of such. At the end of the day, if you have more resources to have a better, and better-protected analysis environment, do make use of them.
Another sound tip would be to use a Firewall on your Host environment (at a minimum). This can help you control connections from within the Virtual Environment because the connections occurring in the Virtual Environment will still pass through to the Host environment - and thus will pass through the Windows Kernel on the Host environment, allowing the Firewall software installed to intercept the activity. This is why security software tends to be able to block malicious URLs within a Virtual Environment, despite being installed on the Host environment, and why we know Firewalls can intervene as well sometimes depending on how they were built.
Last edited by a moderator:
There's a pretty good article here on DDoS attacks: Digital Attack Map - it likely will provide a better understanding than my explanation due to being more in-depth, and written by someone who will actually have a lot of experience with network security/analysis.
What is distributed denial of service (DDoS) attack? - Definition from WhatIs.com - another good article.
You should be able to find a lot of online resources for understanding different types of network attacks from reputable sources.
What is distributed denial of service (DDoS) attack? - Definition from WhatIs.com - another good article.
You should be able to find a lot of online resources for understanding different types of network attacks from reputable sources.
- Jul 5, 2016
- 416
To download the malware posted here, I think you have to sign up for another site. Could be wrong but that is how it looks to me.
The way I was testing malware was first I would startup Shadow Defender on the host, then open win 10 in Virtual Box. Now that my current insider build broke Shadow Defender, I am waiting for a fix or I will just go back a build on my host if I get the urge to test again. Like Peter, I also run Appguard but with VB's files protected instead of VMWare
The way I was testing malware was first I would startup Shadow Defender on the host, then open win 10 in Virtual Box. Now that my current insider build broke Shadow Defender, I am waiting for a fix or I will just go back a build on my host if I get the urge to test again. Like Peter, I also run Appguard but with VB's files protected instead of VMWare
- Jul 5, 2016
- 416
Shadow Defender on the Host environment is a good idea but if you're using a Virtual Machine then the benefit is minimal as long as the Virtual Machine is secure. If you have clipboard sharing/shared folders enabled, disable it before performing dynamic malware testing. Ensure your IP address is protected from the router (e.g. hardware firewall)/Host environment and then you'll be fine.
No malware uploaded to the hub on this forum, or malware aimed at Home users in the wild, will deploy a VM -> Guest exploit anyway. It would be rare for even Microsoft to receive a malicious attachment with the ability to escape from VirtualBox/VMWare environment which is secure. And the attack vectors like clipboard sharing/shared folders are likely the biggest for potential attacking even if it did happen in my opinion, since they are obvious no-brainers to look into given they provide Host -> Guest and back-ward communication.
So it's a good addition but probably a waste of system resource while doing malware testing 9/10 times. The 10th time occurring with a 0.1/10000% chance as long as the VM is safe and a silly thing isn't done to make it insecure.
- Jul 5, 2016
- 416
Would enabling drag and drop from host to guest be a bad idea? I do that but disable the option before testing. I also have 16 gigs a RAM so I don't worry much about resources. The VM runs pretty fast.
Similar threads
