@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.