30 August 2021

Mixed Blessings

By admin@labtinker.net

I recently wanted to find a reliable way of testing the sandboxing facility on a particular security device in a safe and controlled fashion. To test anti-virus systems you can you use an eicar file but this won’t trigger a sandbox. Someone recommended the site 7blessings.co.uk which creates dummy malware with a unique hash which, the theory goes, your AV won’t recognise and bat along to your sandboxing facility which should then attempt to detonate said malware, allowing you to confirm its efficacy.

I had no access to a non-prod environment for the sandboxing system I was trying to test and it doesn’t have an easily accessible virtual equivalent so I decided to see if 7blessings would trigger Palo Alto’s sandboxing offering, Wildfire.

The lab was the simple set up below with the Windows 2019 host browsing out through a Palo Alto (PAN OS 10.0.7)

The firewall rule allowing internet traffic out had the following profile set up. I only enabled the Anti-Virus part of the NG abilities of the firewall (though it is set up to SSL intercept – we’ve got to give it chance!)

For the Lab-AV Anti-Virus Profile I copied the default profile but turned off the associated Wildfire Machine Learning capability to avoid confusion (not altogether successfully!)

So I expected to block an Eicar file which triggers ‘traditional’ hash-based anti-virus but not 7blessings’ sandbox malware test file (http://7blessings.co.uk/malware.php#pafish) which in the site’s own words is:

So trying with the EICAR files (https://www.eicar.org/?page_id=3950):

From the left the first, third and fourth links got blocked with standard warnings….

The third one sailed through which I didn’t expect.

I didn’t have all shields up in having a cut down security profile so I parked this and move on to trying to download the sandbox testing malware file (http://7blessings.co.uk/pafish.php). This got blocked by standard AV…

And I could see this in the Palo’s Threat log…

We were possibly been defeated by a payload based signature. (https://www.paloaltonetworks.com/cyberpedia/what-is-a-payload-based-signature) Kudos to Palo

I didn’t actually set out to test the Palo itself but just find a reliable generic sandbox testing website which I could use with another product.

This is actually moot for a Palo as they provide their own way of testing their sandbox: (https://docs.paloaltonetworks.com/wildfire/8-1/wildfire-admin/submit-files-for-wildfire-analysis/verify-wildfire-submissions/test-a-sample-malware-file)

Returning to the eicar sample that sailed through earlier, I decided to raise all the Palo’s shield and try again…

…and this time it was blocked…

I then decided to go back to my first set up with just the Lab-AV anti-virus profile enabled in the security profile and found that now the file was still being successfully blocked.

The firewall’s AV signatures had not been updated and the cache had been cleared on the browser. Could the device itself be keeping a cache of elements it had previously blocked? (irrespective of which anti-malware component had done the blocking). I rebooted the firewall but the file remained resolutely blocked. There may have been human error involved somewhere but I cannot fathom it; in the initial test the eicar files were opened on adjacent tabs on the same machine: three were blocked, one wasn’t. I will perhaps try and repeat this exercise another day.

Often a lab can raise more questions than it answers… these feels like one of those!