AppGuard 4.x 32/64 Bit - Releases

Discussion in 'other anti-malware software' started by Jryder54, Oct 29, 2013.

Thread Status:
Not open for further replies.
  1. petok

    petok Registered Member

    Joined:
    Jan 11, 2015
    Posts:
    35
    Ok thanks for information.
     
  2. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    ************IMPORTANT****************I have a little information for all AppGuard users. AG does not mitigate threats originating from .JAR files with it's default settings. You will need to guard javaw.exe if you want to block threats that are contained within .JAR files. I have already informed BRN about this, and I have been informed that they may start guarding javaw.exe with default settings in the next stable release. I have already been guarding java.exe, javaw.exe, and javaws.exe for a while now to see if it would cause any problems. I have not experienced any problems during the time I have been guarding these java components. Java.exe, javaw.exe, and javaws.exe can be found at the following path on Windows 7X64 C:\Program Files (x86)\Java\jre1.8.0_40\bin It should no be hard to find on other versions of Windows. Javaw.exe is the only one that must be guarded to mitigate threats from .JAR files.
     
    Last edited: Mar 31, 2015
  3. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Ok, i'm glad I have not been using an old beta all this time. Thanks!
     
  4. rdsu

    rdsu Registered Member

    Joined:
    Jun 28, 2003
    Posts:
    4,537
  5. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
  6. hjlbx

    hjlbx Guest

    Malware1's bypass was reported to Blue Ridge Networks and has been fixed in build 4.2.8.1.

    I tested it extensively, using different techniques, and could not manage to by-pass AppGuard.

    So I can absolutely confirm that specific by-pass method has been fixed for both "Medium" mode; "Lock-Down" mode was never by-passed.

    That door has been shut.
     
    Last edited by a moderator: Mar 31, 2015
  7. hjlbx

    hjlbx Guest

    All Windows OS interpreters should be guarded by default: cmd.exe, powershell.exe, powershell_ISE, wscript.exe, cscript.exe, java as Cutting_Edge points out... for both the System32 and SysWOW64 paths.
     
  8. rdsu

    rdsu Registered Member

    Joined:
    Jun 28, 2003
    Posts:
    4,537
    Done!

    Hopefully these will be guarded by default on next stable version...

    Thanks ;)
     
  9. hjlbx

    hjlbx Guest

    Just a suggestion...

    AppGuard, properly used, handily smacks-down scripts, but just in case... (Through human error... forget to re-enable protection, most likely).

    if you have a firewall that can be configured to "Ask\Prompt" for interpreters, then I would do so.

    I have tested malicious scripts that will use various interpreters to perform hidden downloads to data\temp folders; cmd.exe legitimately needs network access when using various built-in Windows command-line utilities, such as ipconfig, net, ping, etc. Powershell legitimately needs network access when downloading and updating its help files and also the same Windows utilities as cmd.exe. Other than that, none of them should connect to the internet "out-of-the-blue"...

    Sorry, this thread is about AppGuard. Just a quick tip.
     
  10. bberkey1

    bberkey1 Registered Member

    Joined:
    Mar 23, 2013
    Posts:
    244
    Location:
    United States
    I think this is as simple as it sounds, but just in case, you would simply add cmd, powersell and all others in your post from both the System32 and SysWOW64 simply into the guarded Apps tab?
     
  11. hjlbx

    hjlbx Guest

    cmd.exe is already protected by default (System32 only; add SysWOW64).

    Yes. You just add those file paths to AppGuard's "Guard List."

    Use the Browse to Add below Guard List to get the file paths.
     
    Last edited by a moderator: Mar 31, 2015
  12. bberkey1

    bberkey1 Registered Member

    Joined:
    Mar 23, 2013
    Posts:
    244
    Location:
    United States
    Great, figured as much. Thanks for the reply
     
  13. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I have wondered if cmd, and/or rundll32 should also be guarded from the SysWOW64 folder. They are currently only guarded from the System32 folder. I'm not a system's expert so i'm not sure if it would be beneficial, or if it may even cause problems. I think 64bit applications should be more secure by design, but still I wonder if adding them would increase security, or risk stability problems. I'm using Windows 7X64.
     
  14. hjlbx

    hjlbx Guest

    There are malicious scripts that check for both - and will use either...

    Cutting_Edge - good of you to point out rundll32.

    I guard both paths...

    I have had no problems... but on certain systems a tweak or two might be required. All anyone can do is try...
     
  15. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    I missed this post some how. I guess that would answer my previous post. Have you been guarding rundll32, and cmd.exe from SysWOW64 folder without problems?
     
  16. hjlbx

    hjlbx Guest

    The only thing I have had to do is to allow rundll32 to write to a few protected folders... some of which are temp folders... which, by the way, aren't necessary\won't break any apps as far as I have seen.

    However, if you beta test like me, writes to certain file types, e.g. .log, .dmp, .tmp, etc are needed just-in-case for problem-solving. Also, back-ups may write to certain protected folders - I allow those, especially bootbcd files. Check your Activity Report for blocks and add to exclusion folders. Some of files will not exist when you navigate to them - as they do not exist because AppGuard blocked a write, and therefore they are not created... so you will have to copy-paste the file path from the Activity Report "About this message infos."

    I use the * wild-card as the last line item for those temp files whose name changes... although I will generally try the specific file first... if additional blocks show up (because rundll32 is writing to a new tmp file) in the Activity Report, then I will use the wild-card.

    It's a bit of a rigmarole, but your efforts are rewarded with enhanced security.

    It's trial-and-error configuration... there's no other way as AppGuard adamantly protects "protected folders." No pun intended.
     
    Last edited by a moderator: Mar 31, 2015
  17. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    Ok, thank you! I will add rundll32, and cmd from SysWOW64 folder to see if I encounter any problems. Also, I use to guard powershell.exe, and other components of power shell. I stopped after reading something that lead me to believe that it would not help to mitigate malicious shell code from exploits. I could be wrong though. If guarding it can block non exploit attacks, or exploit attacks it should definitely be guarded. I was just reading about powershell_Ise.exe, and it says it can be used to open a file in Powershell. It sounds like it should be guarded. I should probably ask pbust (the developer of Malwarebytes Anti-Exploit about powershell.
     
  18. hjlbx

    hjlbx Guest

    AppGuard does not protect against software vulnerability exploits - in and of themselves.
     
  19. Cutting_Edgetech

    Cutting_Edgetech Registered Member

    Joined:
    Mar 30, 2006
    Posts:
    5,694
    Location:
    USA
    AG will not block the exploit, but it should block any binary payload from the exploit. If the exploit only infects the memory then AG might contain it to one process so it cannot spread though out the system.
     
  20. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,868
    Location:
    Outer space
    If I add an exe from \SysWOW64 to Guarded Apps, and then hover over it, it shows the file path as \System32, not SysWOW64.(I'm on v3.5 btw, not sure if this is the same on 4.x)
    I think @Barb_C once posted that AG treats System32 and SysWOW64 as the same, but I can't find the post anymore.
     
  21. hjlbx

    hjlbx Guest

    I had suggested someone ask the developer...

    So, if it does, then just the System32 path will suffice.
     
  22. BoerenkoolMetWorst

    BoerenkoolMetWorst Registered Member

    Joined:
    Dec 22, 2009
    Posts:
    4,868
    Location:
    Outer space
    I confirmed it works this way(at least for v3.5)
    When Powershell etc are added from System32, and run from SysWOW64, AG shows it running as Guarded. I also added notepad.exe from System32, and ran both the one in System32 and the one in SysWOW64 and tried with both to save a .txt file in Program Files, AG blocked them both.(I ran notepad as Admin of course so it would have access, when AG was suspended they could save into Program Files).
     
  23. hjlbx

    hjlbx Guest

    Thanks for confirming it.
     
  24. Circuit

    Circuit Registered Member

    Joined:
    Oct 7, 2014
    Posts:
    939
    Location:
    Land o fruits and nuts, and more crime.
    Now I am confused. What beta should we be using (most up to date) 4.2.9.1 or 4.2.8.1?
     
  25. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,796
    Location:
    .
    Just read a few following post next to mine and you'll figure it out.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.