What would be a good approach for testing malware or bad url's from things picked up from my SIEM to validate them? I was told to setup a VM for these tests but don't want it to hit the internal network.
VirusTotal.com can be helpful to verify badness, plus, they have a free API for low volume automation.
If you use a VM then be sure to isolate it per the vendor instructions. If transferring bad binaries to the VM with a thumb drive or CD then I prefer to mismatch my host and VM OS, so there is no way the host OS could even run the malware in question. VMs are nice because they can enforce isolation and segmentation.
Manual malware analysis can be extremely effective with the right tools and training. I highly recommend SANs FOR508 training which uses the free SIFT workstation. “The SIFT workstation is a group of incident response and forensic tools designed to perform detailed digital forensic examinations in a variety of settings. It can match any current incident response and forensic tool suite.”
If you're trying to put together tools yourself, you'll need to know what forensic things you need to do, then find the tools to do it. If you're going to build a house, you'll need to know what tools can do what, and if/when you need them. Personally, I'm totally happy to have different VMs with different toolkits built by really smart people. Then I can just "strap on" whatever I need that day and go to work. If I need a new tool, I find or build it, then I add it to my growing toolkits. You can always add more to it, so why start with less?
- Training. No substitute for knowing normal.
- VirtualBox SIFT install instructions
- SIFT docs, manual, and list of tools
- REMnux Distro: A Linux Toolkit for Reverse-Engineering and Analyzing Malware
- How to Install SIFT Workstation and REMnux on the Same Forensics System
- FLARE VM by FireEye Windows malware analysis distro
- So many more... to many to list...
A little Google fu in this direction should get you closer... Though it sounds like you will have more specific questions as you refine your needs. Feel free to comment to start a conversation as you do.
Sandboxes are "a virtual space in which new or untested software or coding can be run securely". Cuckoo Sandbox is a great example of this technology being used to triage malicious files.
As far as a "good approach" - this would depend on your SIEM, and how you are looking to implement it. Are you looking to automatically detonate files which you receive over e-mail? All files downloaded? Depending on the scale of the effort, it would be worth looking at some of the commercial solutions.
Always dump the full-system memory before processing malware. If you can't, then, worse, you'll have to use Scylla via x64dbg toolchains in order to do a full program analysis of the PE/ELF/Mach-O malware, or perhaps ViperMonkey if it's VBA code. There's a lot of types of code, so this may get even worse from here. The problem is that if you don't dump, you're going to have to unpack which means reading and practicing all of the techniques laid out in the books Practical Malware Analysis, as well as the newer Packt Pub books, Learning Malware Analysis, and, Mastering Reverse Engineering. Sometimes these techniques are useful for uncovering other issues such as identifying environmentally-keyed payloads or context-aware malware, even if the malware doesn't do sandbox evasion. I suggest running all of this on bare metal that is blown away and recreated by CloneZilla or FogProject after each project. Running a significantly out-of date AV program with running web browsers and attached to a Windows Domain (not your actual production domain but a mocked-up one) might be overkill, but it doesn't hurt. Don't log in as John Smith either. Malware knows you're up to something.
If the dumped/unpacked malware can't be matched by Malpedia Yara rules, or by writing and organizing your own Yara rules (especially iterations of the Malpedia rules) with YaraGuardian, then you will probably need to go back to those x64dbg/Scylla and/or ViperMonkey methods. Running Yara first often informs a malware analyst about how to proceed next. For a pipeline, check out cse-assemblyline.
For bad URLs, connect to them through an Algo VPN hosted on some virtualized providers that can't be connected to you or your org, and be sure to try different providers, User Agents, et al -- and match it up with what was logged in your SIEM data to ensure that the webapp response isn't a relay or lying to you. This may require mocking up a realistic browser scenario, testing timing conditions, and other timing or order-of operations problems. If the app response is code, analyze the code (going back to the principles above). You may also want to analyze the surrounding infrastructure. Often this is true more for C2 then for doors (i.e., malicious URIs), but Maltrail supplies a lot of interesting starting and connecting dots for your puzzle-solving initiatives.
I do not recommending using VirusTotal (or anything where you submit something to some unknown online web service or similar), or running malware in a VM or Sandbox -- especially not an appliance. It's best to store all of the malware you receive and tag them appropriately, preferably in both Viper and MISP.
If malicious logic actually did execute or install in any of your production (including and especially laptops, servers, desktops, IoT devices, etc) environments, then you may want to add DFIR capabilities, such as SkadiVM, Splunk TA-Volatility, or Volexity. It's good to know everything that happened, especially if the malicious logic included an implant-level component, such as Remote Access Trojans (RATs) do.
Then, if you're really good, you'll be sharing malware intelligence via MISP with other groups that do so.