• Software restriction policy (AppGuard, Simple Software Restriction Policy, AppLocker, Bouncer)
  • Anti-executable (NVT ERP, Voodooshield)
  • Light virtualization soft (Sandboxie, Comodo, Shadow Defender, virtual machine)
  • System rollback soft (Horizon DataSys Rollback RX, Drive Vaccine RX, Reboot Restore RX)
  • Backup and Image Restore soft (Macrium Reflect)
  • Containment soft (ReHIPS)
  • Memory Protection (AppGuard, MemProtect)
  • MBR Protection (HitmanPro.Alert, Macrium Reflect, Horizon DataSys Rollback RX, Drive Vaccine RX, Reboot Restore RX, Shadow Defender)
Notice all - except for Comodo and Voodooshield - are essentially signature-less solutions; they all essentially do it Soviet style: "Trust nothing and suspect everything." Well, I guess Macrium Reflect doesn't do it like that but...

For example, Macrium Reflect is just a backup soft - it needs to know nothing about whether a file is malicious or safe. It restores damaged systems and always works in my experience.

VS uses automated file reputation lookup - as does NVT ERP if the user does the lookup manually. Plus, VS has AI. File reputation lookup is a hash-based, quasi-signature detection method. AI analyzes file attributes and returns a "probabilistic" indication of potentially malicious capabilities.

COMODO has an AV component and relies heavily upon its file reputation lookup. However, Comodo has auto-sandbox - which actually works quite well.
Last edited by a moderator:


Sandbox, it's the best way (and if you ask me, the only way).
What happens when FUD smashes the sandbox ?

It won't happen ? Ohhhh yes, it most certainly does happen... but, I will admit, it is rare.

Need more than just plain, vanilla sandbox. Need limited privileges for running processes in sandbox and ability to block network access from within sandbox.

Also, data can still be stolen in improperly configured sandbox...
Sandbox, definitely tight. It will stop an infection from harming the system, but will not stop it from gathering info and phoning right out the front door to its house with it ;) I find its better to stop it from executing in the first place. :)
No it doesn't, if you have the Windows Firewall enabled, if you use Comodo you can set it to block the network access (sandboxie can do that too).

Lucent Warrior

No it doesn't, if you have the Windows Firewall enabled, if you use Comodo you can set it to block the network access (sandboxie can do that too).
If you have CIS sure you can set custom rules and control outbound connections, windows firewall by default, yeah, well, let one loose on your system like that and get back with me on the results. I have seen outbounds established through very decent two way firewalls.


You prevent it in the first place and use CommonSense AV. If you are sceptical about a file, upload it onto VirusTotal so that the file is distributed which in turn will ruin the malware creators FUD. Also Shadow Defender or Faronics Deep Freeze will come in handy.


Blocking all unknown\untrusted code execution on the system in the first place will always be the best physical system protection (but you still have to cover network vulnerabilities):

This protection model goes a long way (but not 100 % completely) in eliminating:

1. Bypasses
2. Cleanup -whatever that entails from simple cleanup to complete clean install of OS, image restore, recovering lost data, etc - after 1 happens

For best protections vulnerable processes need to be:

1. disabled; or
2. run with limited privileges; and
3. inter-process memory protection
Last edited by a moderator:


How would you protect yourself from a fud?
I'm afraid there is no absolute answer to this question since each FUD sample will work differently and thus will be FUD for different reasons. (e.g. statically FUD or dynamically FUD to specific scanning techniques, or all of them).

When it comes to AV/IS software they tend to have many different scanning stages for both static and dynamic protection. If you are not familiar with the differences between static/dynamic analysis I will explain it now: static analysis is the practise of performing analysis on the target file (e.g. Portable Executable) without the sample being executed, however dynamic analysis is the practise of performing analysis whilst the target file is active in memory (e.g. the PE is running in memory).

An example of static analysis technique would be via the standard SHA-256 signature detection (which will rely on a huge virus definitions database full of these SHA-256 hashes - the AV will compute the SHA-256 hash of the target file using an algorithm and will then compare this to the DB to check if there is an entry in the DB for the computed hash of the target file, if the hash is found in the database then the product will flag the scanned file as malicious (with the detection name from the database)). (other hash check sums can be used for this method such as MD5 and SHA-1 also however SHA-256 is more commonly used since the collision chances are much lower and it is more secure).

Another example of a static analysis technique would be byte detection which can work via HEX. For example, the AV product may have a database filled with HEX entries which represent bytes to make up malicious instructions and then the product can scan through the bytes in the target file and check if it contains any entries from the HEX signatures in the database. This is an example of generic detection since via this method you can detect multiple samples of the same (or different) malware variant just based off of one signature entry, however you must be careful when implementing this technique since if it's done incorrectly and without delicate care it can cause a huge amount of false positives.

A third example of static analysis would be based off the Portable Executable information (e.g. code signing authentication checks and then checking if it's validated, comparing the strings put in place for the Copyright/Company information, scanning of the PE header for signs of packing/obfuscation, and so on).

However for dynamic analysis the target file will need to be active in memory (e.g. the PE will be running) and therefore different techniques are applied. An example of dynamic analysis in security products would be: dynamic heuristic analysis, Behaviour Blocker/HIPS, sandbox isolation or behavioural cloud analysis. Those are just some examples and I will further explain them.

Dynamic heuristic analysis can work multiple ways and there is no one right way to implement this feature however a standard approach would be for the security product to execute it's own code from within the address space of the newly executed program and monitor it at the start for any suspicious activity it can flag. Usually it will work with a scoring system and once it reaches a specific score it will flag the sample as suspicious/malicious and then quarantine it (or do something else depending on the settings configuration). It works a bit like a Behaviour Blocker/Host Intrusion Prevention System in the way it is implemented (e.g. the techniques it uses to monitor the behaviour) however the difference is that it will not provide the same functionality as a BB/HIPS feature since it will not alert you to allow/block AutoRun modifications or if a process is attempting to perform injection attacks for Process Hollowing - it will just flag when it reaches a specific score on the scoring recording data or when it feels it has sufficient evidence to believe the program is indeed malicious in one way or another. A different approach for dynamic heuristics would be similar to DeepScreen in Avast where the target program is executed in the background within an isolated environment for a short period of time (e.g. Avast DeepScreen utilises the VirtualBox engine if I recall correctly) and then the results are reported back from the isolated environment and these are then used to determine whether it will flag the program as malicious or allow execution on the main system.

Behaviour Blocker/HIPS is a great feature when it comes to zero-day protection and it can really be useful if it is configured correctly and is developed properly. If a BB/HIPS system is not implemented correctly then it can end up being relatively easy for malware to bypass it (thus becoming FUD to the BB/HIPS of the product even whilst performing actions which should be monitored and watched out for by the product based on the current config). Usually BB/HIPS is implemented via the security product injecting into all running processes (and of course any newly executed processes become injected into also) and then it uses this code injection as an advantage to execute code to alter the execution flow of the program so it can intercept when the target program attempts to execute specific functions to perform monitored actions on the system. For example, it can alter the execution flow to intercept when the target program is attempting to use functions which can perform registry modifications and then it can intercept this to show alerts to allow/block this behaviour, or to intercept when functions are being used with obvious malicious intent to inject into an external process (and then the BB can block this behaviour or ask the user if the behaviour should be granted). Depending on how secure the BB/HIPS has been implemented will depend on how easy malware can become FUD to the BB/HIPS modules in a specific product however if malware can bypass one BB/HIPS system it doesn't necessarily guarantee it will be FUD for other security product's BB/HIPS too, since all of them may work differently and monitor different behaviour via different techniques.

Sandbox/virtualisation isolation is by far one of the most secure options when it comes to dynamic zero-day protection in security products (if it is implemented properly of course since some sandboxing methods can be escaped more easily than others). Of course, one of the best bets would be separate isolation (e.g. via a Virtual Machine) however if this cannot be an option then the typical sandbox is one of the next bets to virtualisation (in case you were wondering/confused - virtualisation and sandboxing are actually not the same thing - virtualisation is completely separate instead of just redirection techniques whereas a sandbox works by redirecting or just blocking actions being carried out by the target program (and a lot of the time the "sand-boxed" program is running under a container process with limited rights).

Now I have finished explaining some static/dynamic protection techniques, we can talk a bit about how malware may make itself FUD to specific features so we can make a conclusion on your best bets to staying safe against FUD threats overall:

We will start with the standard hashing/byte (via HEX) detection techniques: a sample may be detected by all AV products via either standard check-sum signatures or HEX detection (generic) until it applies some cryptography techniques (runs the sample through a crypter/packer) and then the outcome of this can leave it fully undetected. When this newly transformed sample is executed the packer usually de-crypts it in memory, and therefore if the product you are using has a good memory scanner it can still potentially scan the decrypted contents and detect the sample. However, not all security products have good live real-time memory scanners which go as deep as just monitoring process execution and performing the normal scan engine methods against the target binary being executed and therefore a lot of packed samples succeed in becoming FUD from the static analysis scanning methods in traditional AV software.

The second static analysis method regarding code signing authentication and company name information can avoid suspicion via either stealing a code signing certificate or just by obtaining one genuinely (for an individual developer if no company is registered - it's really easy for malware authors to obtain a digital signature and it isn't too expensive either if you think about it...). Regarding the company name information, if nothing bait is put there such as "Adobe" or "Avast" then it probably won't be picked up as suspicious. If malware is trying to imitate itself as being published by a trusted vendor it is not from then chances are it'll be picked up (especially if the digital signature doesn't match the company name information).

Regarding dynamic heuristics, BB/HIPS and sandboxing, surprisingly the same methods can be used by malware to bypass them usually. Why? Because most of the time the same techniques are applied to implement these features, except they are slightly changed to perform different functionality reporting back to the user (e.g. dynamic heuristics tends to keep the user not involved in the action decisions for allowing/blocking whereas the BB/HIPS provides more user-interaction, and the sandbox just runs the program and redirects all the actions if possible). Usually all three of these features evolve around techniques such as API hooking and therefore more sophisticated methods such as system calls can be used to bypass these user-mode hooks...

Let's take Sandboxie as a pure example, it is heavily involved when it comes to API hooking. However if someone who is developing malware is experienced with hooking then they can work on unhooking the hooked functions (and of course prior to this detecting it the functions are even hooked with all sort of methods: byte comparisons from memory, full function prologue comparisons depending on the OS version (since function structures can change at any time in future OS versions/updates but normally the Ex prefix is added and a new function is added for the modified version), etc)... Once the function which Sandboxie had hooked is unhooked then it can be called normally without Sandboxie being able to further monitor/redirect execution flow with the usage of that specific function and the same can happen to all functions the malware will try to use which is hooked by Sandboxie. However, Sandboxie should most likely try to repair any hooks which are set, but it's not guaranteed and by then it can already be too late. Another example to a sandbox bypass would be a system call usage or direct implementation of the function prologue via inline Assembly, therefore it never goes through the IAT/EAT to reach the address of the Win32/NTAPI function stub since it either uses it's own implementation or just uses the system call to evade all the hooks.

(however I should note that this stuff cannot just be learnt overnight and therefore I wouldn't worry about running into a sample which will escape the sandbox because it's more rare than common).

Whereas if we take a look at software such as Shadow Defender which utilises virtualisation as opposed to the standard sandboxing techniques, you'll find that a bypass is much more difficult to do and cannot just be done as it can with products like Sandboxie. As for Virtual Machines, it is very hard to exploit these (and usually it occurs due to Buffer Overflow attacks or the exploiting of the additional features which are left enabled such as the Shared Folders, Copy to Clipboard features (e.g. Buffer Overflow attacks on these features also can be attempted)).

Now I have finished with explaining all of this... Let's talk about how YOU can protect yourself against FUD ("Fully Undetected") samples (since no AV product can fully protect you and at the end of the day it is entirely up to you to apply standard safety checks to prevent yourself from ending up infected - I will bullet point some useful tips to help you stay safe):

  • Do not be click-happy whilst browsing on the internet/download from un-trusted sources. Regardless of if you are using an ad-blocker or web blocker, there is always the chance of some sites/downloads slipping through and these unknown websites can contain malicious elements (e.g. malvertising via malicious advertisements) and malicious downloads. In fact, all it takes is for you to visit one un-trusted website and it could exploit the browser and lead to infection... Just don't risk it even if the chances are slim! Make sure you only visit trusted websites and do not aimlessly click links to any old site. REMEMBER: just because a website is listed on a trusted search engine like Google or Bing, it does not guarantee that the listed site is actually safe...
  • Make sure you are using an ad-blocker to help protect yourself from malicious advertisements - you never know if a trusted website has been compromised by an attacker and the advertisements from that website have been tragically hijacked with malicious copies, therefore it's best to stay safe and use an ad-blocker. Anyway, why wouldn't you want to use one? Not only does it enhance your security and reduce your risk for infection but also improves your browsing experience since it speeds up your browsing and makes it more pleasant (block connections to ad-provider hosts so the page loads quicker).
  • Always scan new downloads at online anti-virus/anti-malware scanning engine services such as VirusTotal (Google)/MetaScan (OPSWAT).
  • If you are suspicious of a new download regardless of getting clean results from online scanning engine services then you can run a test via online-sandboxing services: Hybrid Analysis, Malwr (you can then assess the report yourself and make a decision on if you want to run the program on your main system or not) - you can also run the download within a Virtual Machine to see if it will work within that environment yourself, however if it presents back an error message or just does not open correctly then I would avoid running it on your host machine because chances are it checked if it was within a virtualisation environment and then altered it's behaviour.
  • Do not open e-mails from unknown/un-trusted senders (or reply back to them in fact - since replying back can potentially leak some of your own information if you are not careful and if they receive the response then they know that there is someone active on the other end of the target e-mail address).
  • Use an Anti-Executable software to prevent any non-whitelisted software becoming executed on the system (for additional protection).
  • Make sure to run regular scans every week with an on-demand scanner to check if it can pickup anything which your primary security may have accidentally missed - after all, on-demand scanning from Anti-Malware products it meant to be there to help catch what your primary protection is unable to find!
If you are a fan of Linux then a good idea would be to use Linux as your host OS and then use a Virtual Machine from within Linux to access Windows, therefore if you become infected you can just revert the actions with a Virtual Machine snapshot to get rid of the infection. NOTE: Data theft can still occur from within sandboxing/virtualisation in general.

Honestly, if you use the above tips and just apply some brain.exe knowledge when browsing online and handling downloads, chances are you won't become infected even if you were running no security software. You cannot leave your security software to do all the work because if someone is click-happy, downloads anything for no reason or is not careful with their downloads and doesn't assess what they are doing properly and think, they will become infected no matter what security they have in place... (technically the chances would be much higher at least).

If you apply safe practises then you won't end up giving malware a chance to bypass all your protection in the first place - even if you run a sample in a product like Sandboxie you'd still be giving it a chance. The best bet is to not run it on your host system unless you are certain it is safe and trust it, and if you don't trust it then the answer is simple: don't run it and let it have a chance!

Stay safe and I hope this helped,
Wave. ;)