Malware Download Test

[Basa Benejan]

Iam trying to learn about malware and how it infects computers and how to disinfect a computer if one gets attacked. I've seen several people use virtual machines to test malware in (I've been using VirtualBox for a few years now) and I've contemplated on doing it too, but I fear that the malware might "leak out" of the VM and ruin my host computer and all of the computers on my network.

Since I will also be 'pranking' some of those cliche Windows scammers (well, not really pranking, just testing ways that they can get in and do damage), would it be safe to use a VM, or can I even use that junky Dell of mine?

1/3/4/7-Access to the Internet? Not a good idea as depending on what it does, your VM could release it "into the wild". Running it in a VM should be perfectly fine if it is not connected to the internet.This answer from The Bear will go into a lot more detail regarding the malware escaping a VM. Here

As for your question in the comments...-Yes it is. You shouldnt have any issues with just formatting. There is extremely sophisticated malware that can reside if MBR, bios, firmware, but this would be above everyday malware. UNLESS you have peripherals attached (USB drive for example).

You wouldn't want to. Suppose the malware you are analyzing is deisgned to immediately target say a bank or government machine. You could set yourself up for huge liabilities. On the one side of the equation, not having connectivity limits your results. For example, when dealing with a C&C based strain of malware you would never see any new droppers, or C&C base commands.

The fix for this would be to insert a proxy between you and the rest of the world. To do this properly, what you would need to do is watch the connections, immediate STOP the connections, validate your system is not making a maliciousconnection, then create an allow to malicious machine fw rule, while blocking other connections. Would look like this:

This enables your system to ONLY talk to the malicious system. If it tries to launch attacks from your machine, the fw rules would block it. Optimally, you would want to create fake routes. E.g.:

Why not just create and store a ghost image, analyze, restore your ghost image. Bios based malware is rare however to be on the safe side you could password protect your bios, or run something like "regshot" to track commands being performed. Maybe even flytrap from HB Gary (if still available)

Your 5) Since I will also be 'pranking' some of those cliche Windows scammers (well, not really pranking, just testing ways that they can get in and do damage), would it be safe to use a VM, or can I even use that junky Dell of mine?

Define "pranking." Many malware authors are very technically savvy, and common malware can determine if they are on a honeypot, running in a VM, or if something is amiss. Aside from that, many malware authors are often embedded with organized crime, so it could be a very dangerous game to play.

Unclear about this statement. Define masking IP. If/when you connect to a host, you need to come from somewhere. The only solution to get proper results (what is the malware doing) the machine needs to respond to you. You could use a VPN proxy, but there is no method to spoof anything.

The problem you will actually have, when using a VM, is that most malware will refuse to open its payload so you won't get a lot of research done. Researchers using VMs to dissect malware are all too common, and most malware nowadays actively prevents it by looking for clues that it's running in a VM, and staying dormant if it finds them. Keep that in mind if you pursue the virtualized method, you will probably get different results than someone doing the same tests on a bare metal system.

That being said, you should be OK using your desktop with the same precautions: limit all network access, never attach it to your local net and never provide internet access, unless you are directly watching what it is doing with a traffic sniffer and can kill it if it starts to do something malicious like fire up a DoS attack or portscan the NSA. Also, don't share any media (thumb drives, etc) on the system after the malware is deployed. If you do want to save files for later use, put a ring of red tape on the drive to make sure you don't mix it up with others.

It depends which malware - if you've got a good idea of the behaviour of the particular strain of malware that you're testing, then internet access shouldn't be a problem. Of course you have to have confidence that running it won't attack any internet hosts, for example, from other reputable reports on the malware analysis.

There will always be VM breakouts possible, whether these bugs have been discovered or not is another issue though. Generally you would be safe, especially if you are only testing malware known not to have any VM exploits contained.

I recently setup a VMware Fusion network for Malware testing. Depending on the malware strain, I could setup Iptables to either block internet access (apart from DNS and other whitelisted hosts), or to allow public internet access. Access to private addresses was always prohibited - this will protect your local network from malware traversal.

The Debian system had two network interfaces, this enables the network to the right to be configured with no access to the host machine, nor any external network access at all. The network to the left was configured with internet access only, and no host access.

You don't need to worry about MACs being exposed, as these are a level two network entity, so don't have any bearing on the internet connectivity of devices, only the local network. Of course, if the malware contacts any internet based services, your IP will be exposed to this, unless you configure the Debian system to VPN or Tor these connections.

The elephant in the room is that even with "trusted malware behaviour", the malware in question might download arbitrary executables from its controller host, therefore it might do anything such as attacking banking websites or trying to break out of the VM. Therefore if this is a concern, you would have to mimic the controller host using another VM if you were to truly analyse the malware's behaviour, and disallow internet access totally.

It feels like I'm missing something and so would appreciate of someone could explain to me why the XDR agent on Windows (latest 8.2.1 with block policy) is not reacting to EICAR malware test file (X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H)? I tried malware scan on the file but the agent reported it clean. I fully realise it's a dummy file but thought XDR still had it in its database for testing purposes.

Hope you are doing well. And thank you for reaching out to the Live Community. I understand that you are trying to test Cortex XDR with EICAR file, however, please note that Cortex does not detect this file as a malware for legitimate reasons. I do understand that EICAR file is used for testing universally, but the fact that it is a dummy file remains constant.

If you would like to test Cortex XDR you can use our Malware test file using Wildfire APIs and each time you get a new different malicious hash, which could be used for testing. Please find the link below, thank you:

It's all good, I figured as much. I suppose it'd be good to have that referenced somewhere in official Palo Alto resources regarding XDR, so one could easily point their clients to it in case there's questions like that. Cheers.

Yesterday I started some hacking tutorials on by curiosity. I used the Android app to read the different articles about different ways of "hacking". The author clearly stated that some of them shouldn't be reproduce because they would basically harm the computer, such as the famous Zip bomb and Fork bomb or even Folder blaster.

So, I'm wondering what would be the best way for me to reproduces these "malwares" without doing harm to my own computer. But I'm also interested of finding a way that I could use for many different kind of malware/virus testing/development.

The first solution that comes to my mind is to use a Virtual Machine, so I could take a snapshot of the VM once installed and do whatever on it without harming the real OS. But I don't know for sure if this is the best solution and even if it's gonna work or not. I guess it would, but that's a guess.

Almost all malware, if not all, works by obscurity. Once you understand how it works, and you have the appropriate skill-set, you can defeat it quite easily. If it's your own malware and viruses, then it's really quite simple: you know exactly what your malware does, and how to defeat it, correct? After all, you programmed it.

While yes, I agree in general with the use of a Virtual Machine, it isn't 100%. Nothing is 100%. You can infect your own machines, whether they're online or offline, and do interesting things with them.

While others talk about malware "possibly escaping" the Virtual Machine, it isn't very likely, though it is possible. Even if the malware could detect that it's running inside a virtual machine, that doesn't help much unless the malware self-destructs upon detecting a virtual environment.

Even if a VM isn't detected, a piece of malware could simply try to escape it by assuming it may be there. So methods to prevent the malware from detecting it's inside a VM may not work, unless it's the type that self-destructs when detecting it.

Better yet, if you have a virtual testing environment, you can delete these automatically by saving the state of a virtual machine before the infection, and restoring it after you're done studying the output. This is the easiest, most efficient method by far.

Depending on how the malware works, virtualization might be a sufficient way to contain it. By running the malware in a virtual machine, it can only cause damage inside the virtual machine and only use up those resources which are assigned to it.

Some malware has the ability to recognize when its virtualized and attempt to "think outside the box" using the most interesting of tactics I've seen...sometimes even trying to control the keyboard. The only way to truly test them is to set up an airgapped laptop or desktop and run it on that, then reinstall all the OS when you're done...time consuming but the only "safest" bet.

3a8082e126