Testing WildFire

[JohanL]

I did some test on WildFire. I've created backdoors, link backdoor with a legitimate file, and playing around with malware, and obscure malware with the goal to bypass.

The result and scenarios can be found on my website.

Any comments or remarks are welcome

[das]

You mean this website? http://www.accessdenied.be

[JohanL]

yes, on my site I store all the documents I've tested using my box

[mikand]

I guess you agree with me that Wildfire conclusion of what is benign and what is malware is a bit off?

Could perhaps someone from PaloAlto put some light on this matter?

[Quinton]

Nice work man. Busy reading. Saw something in your file blocking profile that can be configured differently to ensure that only the correct file types are forwarded to Wildfire - I believe the correct file type for Wildfire is "PE". This of course includes .exe and .dll.

[gafrol]

PE stands for Portable Exectuble. Currently the only file types (exe and dll) supported by Wildfire. Check Point is trying to catch up with threat emulation...

I'd be happy to see Wildfire supporting office documents as well as pdf files.

Side note, it's always good to block unknown udp,tcp traffic

Roland

[mikand]

Yeah only scanning exe, dll and scr is a bit limited.

Will be more interresting the day Wildfire also supports pdf, java, flash and office-documents.

And for that matter become a bit more critic of whats malware and whats benign (I somewhat disagress with PaloAlto on whats benign and whats not in terms of that what Wildfire thinks is beningn I think should be classified as malware 🙂

[tettema]

Hi Johan,

Looks like you've had some fun taking a look at WildFire's detection logic.  I wanted to take the opportunity to address some of your findings just to clarify some of the items presented:

1.  Your first three tests use custom binaries that open reverse shells as the "malicious behavior".  Opening a reverse shell that never connects to bind to a shell is not something that can really be used to detect malware.  If you start a reverse shell without successfully binding, all it really looks like is an attempted TCP connection.  Since all we see in the sandbox is a failed TCP connection, there is nothing useful here to call the sample malware.  Furthermore, the IP address chosen by your application is in private address space.  Calling programs malware when all they do is open a TCP socket on private address space would quickly lead to problems.

2.  If your sample were to perform a reverse shell to an external IP and actually bind to a server listening for the shell, the Palo Alto Networks IPS would have caught that reverse shell and triggered a critical reverse shell alert.  If you are blocking on IPS signatures, this shell would have also been blocked, preventing the interactive session from taking place.

3.  In the final test, you take malware (which was confirmed as malware by WildFire), run it through pescrambler, and run it through WildFire again to see if we can detect it as malware.  The test comes back benign, and you'll notice that one of the behaviors observed is that the sample crashed when loaded.  This is because pescrambler corrupted the EXE making it unloadable.  In fact if you run it in your own environment, it crashes immediately.  The pescrambler tool looks like it hasn't been updated in some time, and in fact has an open issue (https://code.google.com/p/pescrambler/issues/detail?id=1) describing the fact that it corrupts EXEs.  Given that the sample doesn't successfully run, I wouldn't call this a false negative.  In fact, any static file obfuscator like pescrambler is more useful in evading AV signatures, and not in evading dynamic sandbox-based analysis tools like WildFire.  Scrambling a PE file causes the file image to change, but once it's running, WildFire doesn't care whether the file was scrambled or not.  WildFire is looking at the runtime behaviors of the sample as it runs in the sandbox, regardless of how the PE file was obfuscated.

Having said all that, WildFire will never catch 100% but it is a valuable addition to our threat prevention technology stack in catching malware that evades the other layers of defense.  If you have any other findings you would like to bring to our attention, please let us know or you can also reach out to me directly.

Thanks,

Taylor Ettema

Product Manager, Threat Prevention

[ericgearhart]

It's nice to see a point by point response from Palo Alto's Threat Prevention Product Manager here on the forums... well done sir.

[gafrol]

Excellent answer, thanks for sharing !

[JohanL]

Thanks all for the information. My goal was to embedd and executable file into a pdf file, but WF currently does not scans pdf file. Thats the reason I played around with exe's.

1. When I ran the three executables, they where able to bind to the attacker machine since I had a shell. The executable is a meterpreter shell which is fully loaded in memory. From this shell I can upload 'malicious' files and own a system. To evade AV/IPS systems, the payload is fragment in memory so that AV/IPS software is not able to detect this as malicious. I've did some test in my lab. I don't have a public IP were I can test with.

2. The next test I'll do is IPS and exploitation. This doc will be available in the coming weeks.

3.PEScrambler is just one of the examples. There are others like Themida, etc.You can use any scrambler you find on the internet. The goal is indeed to create another file (hash) to evade AV.

I have still two questions:

• Is WF vulnerable for hash collision attack ?
• How does WF internally works. Does it see how many malicious activities are executed in a certain amount of time or just scan the behaviour of the file executed?

In my examples I've used a reverse shell. But you can take whatever malware that you like. The purpose was to verify if WF was able to detect a malicious file when its linked into another exe file. If WF executes only the first exe, I was curious if its able to see my malicious file.

If WF is not able to scan PDF and DOC files it is still a threat. Because most of the malware is now embedded into these files. Imagine an excel sheet which contains some executable code. When a user open an XLS file, a reverse shell or malware can be executed.

Recommendations:

Always implement a defense in depth strategy.

• In my test I only enabled WF. But AV, threat prevention profiles should be enabled as well.
• Do not allow http(s) as service but use App-ID. This type of reverse shell is not detected by App-ID and will be denied.
• Monitor your unknown-tcp/udp traffic

It is not always easy to understand how stuff works, but we can learn a lot while playing with it. As a security professional we all try to protect our environment but against what? To better address this, we have to know how all this stuff works.

Thanks for the comments/suggestions