AppGuard 4.x 32/64 Bit - Releases

I have exluded it from protection, so all sandboxed processes can run nearly freely within the sandbox (ERP is still monitoring files)

 

i just tested , none of sandboxie's processes needs to be in Power Apps.

 

So to be clear: Excluded from protection = C:\Sandbox, User Space = No? ... and Guarded Apps>Settings>Excepion (Read/Write) ... ?

 

Correct.

 

OK thanks for the info. I just wanted to verify that AG can indeed block the payload delivered by DoublePulsar. This means it should block the malicious process spawned by lsass.exe I suppose.

 

From what i see on videos/articles and what i asked Dan to test, (i didn't have the exploit to test it myself.):
AG Consumer (by default setting) will not block those sapwned processes because those are ran at System level.
Also, AG doesn't have a command line parsing feature like VS/ERP to monitor execution of vulnerable processes (because it SRP not Anti-exe), it will just block the execution of further malicious files uploaded to the target system via the shell spawn by lsass.exe.
However AG Business will block lsass.exe to spawn children.

Note that if lsass.exe is compromised it is already game over, whatever item you block after. The goal is to block any container to execute DP in the network in the first place, AG will surely do it.

Better stop the gangsters to enter the bank than let them in and deprive them of their guns.

 

Well apparently it's not game over, if you can block payloads executed by DoublePulsar. So let's say that DP is executing WannaCry via lsass.exe, then you should be able to block it. But you say that AG wouldn't do it because it's a system process, so it wouldn't have blocked WannaCry. No offense, but you sometimes contradict yourself, which makes it confusing.

 

From my researches, DoublePulsar can inject DLLs into a process (by default lsass.exe, which runs as SYSTEM). Many believe without dropping anything on the disk, all is made in memory using Reflective Injection.

lsass.exe doesn't execute Wannacry, it create only a backdoor , it spawn rundll32.exe which connect to the attacker platform and create a shell (cmd.exe) for him to manipulate the compromised system.
AG consumer doesn't have a command line parser so rundll32.exe isn't blocked (i don't have the sample so i can't say if AG via some tweaks can block this step)

https://en.wikipedia.org/wiki/WannaCry_ransomware_attack

About wanacry:

https://www.endgame.com/blog/technical-blog/wcrywanacry-ransomware-technical-analysis

So from my understanding, AG or any decent anti-exe/HIPS/BB will block the initial dropper on the Patient Zero machine (the malware that will compromise the network), that is all that matter.
However if Patient Zero is exploited, then you are doomed, EB will propagate DP in all the machines in the network, and nothing (except maybe a full anti-exploit) will stop it to exploit lsass.exe.

 

The recommended best practice is to not use SMBv1 - which Microsoft itself has advised for over a decade that SMBv1 is vulnerable - and apply the Microsoft security updates that patch Windows against both the EternalBlue and DoublePulsar exploits.

Here are some facts about susceptibility to EternalBlue and DoublePulsar:

A. DoublePulsar is non-persistent; a system reboot is enough to defeat it. However, in all honesty, most users on systems that meet the conditions below will not even be aware of it until it is too late - but it is not something that is discussed except for a few places online and here.
B. The system must be using a version of Windows that is susceptible to the exploits
C. The susceptible system must be unpatched
D. The system must have SMBv1 enabled
E. The system must be configured for a server-client share using the SMBv1 protocol
F. Microsoft has put out advisories regarding these exploits and has pushed security updates that prevent the exploits themselves

The percentage of home systems that meet conditions B, C, D, and F is a comparatively small percentage of all systems in active use. And there are more requirements if the system sits behind a NAT router.

Unless the exploit is fully mitigated itself, even if the user clean installs the OS and re-applies the same protections - the system can be re-exploited if the unpatched version of Windows is configured as before or, if unpatched, an anti-exploit that mitigates the EternalBlue-DoublePulsar exploits themselves is not used.

AppGuard will block the post-exploit malware payload as intended as a software restriction policy software; AppGuard is not an anti-exploit product. So we recommend that the user take steps to completely prevent the exploit in the first place. We have always recommended that AppGuard be used as part of a layered security configuration.

SRP and anti-executables are not anti-exploit products, but instead post-exploit security solutions. Blocking an exploit itself, and blocking a post-exploit attack are two completely different things.

We recommend adhering to Microsoft best practices. Any system should be completely up-to-date at all times and properly configured. It is recommended, at a bare minimum, to use an antivirus and firewall. Disinfection alone is not sufficient to ensure that the system is fully protected; a recommended post-infection best practice is to review the system configuration to make a determination of what went wrong as well as clean install the OS and apply all security updates.

We recommend that users research all the facts - as it is not a simple case of black-and-white "Use AppGuard or product X, Y and\or Z" for that matter and all your IT security problems will be solved. Facts must be considered in their totality.

This is plain enough and we consider this matter closed. There is to be no further discussion about it.

 

Off topic. Thanks again Lockdown for your thoughts about choosisng VPN's. Hope Mullvad lives up to your standards.

Admins (Mike) changed my username to be how I intended it to be. Thanks.

Robert I.Y.

 

If the user is running as Admin I think it may be possible to drop the payload in the system space. I don't rule out that this can be done under an SUA also since it's a kernel exploit. If it is possible then AG would not block the payload then since AG only blocks Guarded Apps from writing to the System Space, and lsass.exe is not Guarded. Once the payload is dropped in the System Space it's game over. I think Blue Planet-works needs to implement additional mitigation policies for cases such as this.

 

Hey Peter2150, still using NordVPN?

Robert

 

Yep. I only have 1 account,and it is Admin.

Robert

 

My understanding is that the goal of AG is to block any droppers (executables, etc...) to load any payload (exploit, etc...) into system space, not to block the exploit itself.
Since you use AG on one machine, you are supposed to use it on all machines of the network, so the dropper shouldn't be able to executed at all on any machines.
The first breached machine (Patient Zero) is the one that doomed all others.

AG disarm the guy with a gun , not dodge/stop the bullet

 

What's to keep the payload from being dropped in the System Space? The exploited process is a System Process, and is running from the System Space (lsass.exe). The exploit already has access to the System Space. AG only blocks Guarded Apps from writing to the System Space, and lsass.exe is not Guarded, and on top of that it's already running from the System Space. Like I already said, if it drops the payload in the System Space it's game over.

 

AG only blocks payloads if they attempt to run from the User-Space. AG protects System Space by not allowing Guarded Apps to write to the System Space. AG also does not allow Guarded Apps to write to Program Files.

Edited 6/4/17 @ 1:38

 

The exploited process = SYSTEM. The exploit = escalation of privileges and remote code execution. The code injection = (default) lsass.exe.

Hmmmm... let me see... I use AppGuard so what is best way to fix this ?

What is the best practice no matter what security solution that I use ? ... hmmm... let me think about this...

OK, OK... I got it... update Windows with MS17-010 and other patches or upgrade Windows to 10-1703.

But I never use SMBv1, or any other SMB for that matter, as I am typical home user and therefore was never at-risk in the first place... ...............

So what do you think about assertions being made by others now ?

 

Sorry!

Robert

 

Hmm.. let me see, the user updates Windows (patches) for this exploit until another exploit comes along that also exploits another System Process. That exploit could go undetected for years, and during that entire time the user is unprotected because no new measures have been taken to protect against these kind of attacks.

 

Just pm'd you.

 

AppGuard is SRP; it is an not anti-exploit.

If people cannot understand this simple fact, and the reasons why SRP cannot prevent exploit themselves, then there isn't anything that we can do about that.

We are going to stick to the core concept of SRP which has proven itself over decades to very reliably prevent infection against a wide spectrum of infection types.

Undetected vulnerabilities have always existed and shall continue to exist - that is why it is recommended to use a multi-layered defense that includes always keeping Windows up-to-date among other best practices.

If there were a single push-button set-it-and-forget-it way to prevent any and all exploits, then it would have been accomplished long ago.

There is so much ignorance, mis- and disinformation regarding exploits that any time we try to educate people about them, it invariably is a fruitless endeavor.

 

I'm not misunderstanding anything. I simply pointed out that if an exploit is able to drop a payload to the System Space then AG will not block the payload. Some users in thread seem to believe that AG will block payloads that execute from the System Space. I never spoke once about AG blocking the actual Exploit.

Your response in post 7468 seems snide, whether you meant it or not. It was also not on topic with what I was talking about. I will state the same thing once again so users understand the limitation of AG. AG will not block a payload that executes from the System Space. If the exploited process, or dropper is able to successfully write the payload to the System Space then AG will not block it. I have read recent post here that seem to be suggesting that AG will block the payload not matter where it executes from.

Edited 6/4/17 @ 3:57