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?

Some tools/distros:

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.

  • What if i want to build one from scratch? What is a good distro and tools? – john_zombie Jan 24 at 16:07
  • Frankly, I don't really see why you'd want to build your own toolkit from scratch, especially if you don't know what you need. Far better to stand on the solders of others who know what should be in a toolkit. I use the SIFT workstation (especially volatility tools), Sysinternals Suite, REMux distro. Could also look into FLARE by FireEye. None of these tools will compensate for knowing what to look for, and how things should behave "under the hood." updating my answer to include some more things – primohacker Jan 24 at 17:40
  • I recommend different strategies in my answer, but if you do want to build malware analysis tools and develop on them, check out -- github.com/cryps1s/DARKSURGEON – atdre Jan 24 at 22:30

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.