VoodooShield/Cyberlock

Discussion in 'other anti-malware software' started by CloneRanger, Dec 7, 2011.

  1. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    I have posted 5,711 times on wilders in the last 5-6 years. And if you ask me, this will be the most important post so far.

    I posted the initial EB/DP test video 9-10 days ago, and had it not been for a small group of individuals (3 or so) from here and MT, consistently picking on VS for the last few years, no one would have ever questioned my intentions. But because these individuals felt it necessary to continuously pick on VS, some people incorrectly assumed that I was exacting my revenge.

    We can do better than that... just be nice to each other.
     
    Last edited: Jun 6, 2017
  2. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    Oops, I totally misunderstood you, sorry. Can you please send me your DeveloperLog.log from the C:\programdata\voodooshield folder? It might even help if you reproduce the crash first, then send the log right after... please email it to support at voodooshield.com.
     
  3. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    FYI, RS just called me, and they are aware that this is a BFD too. They are going to have one of their techs call me in a day or two, to see if they are able and willing to run a quick test or not.
     
  4. guest

    guest Guest

    Dan, i believe that will change nothing , as far as i know (and what i kept saying since the beginning...):

    1- VS like others will surely block the initial container if any (an executable from outside which will deliver EB-DP in the network).
    This point is not shown on any videos; because they focus on the exploit itself propagating inside the network, not by what means it penetrate the said network and infect the Patient Zero machine. (the most important point to me, and totally neglected).

    2- VS like any anti-exe/SRP can't block the EB-DP kernel exploit, the part where lsass.exe is successfully injected. it was shown on your videos. (attached image 1)

    3- However, VS like ERP due to their command line parser , will block the reverse connection, rundll32.exe trying to connect to the attacker platform and make a interactive session (attached image 2 shows tcpview window where we see rundll32.exe connecting to kali) which, when failed, generate the "no session was created" in the attacker framework (attached image 3).

    Do we agree Dan?

    (im not here to bash VS, like some people try to make it sounds, i'm here trying to explain the attack correctly and in a simple understandable way)
     

    Attached Files:

    • 1.jpg
      1.jpg
      File size:
      149.6 KB
      Views:
      14
    • 2 (2).png
      2 (2).png
      File size:
      64.5 KB
      Views:
      14
    • 3.jpg
      3.jpg
      File size:
      156.7 KB
      Views:
      13
    Last edited by a moderator: Jun 7, 2017
  5. _CyberGhosT_

    _CyberGhosT_ Registered Member

    Joined:
    Mar 2, 2015
    Posts:
    457
    Location:
    MalwareTips "Your Security Advisor"
    +1 :thumb:
     
  6. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    Here is what I know so far, and I should know even more tomorrow after I read the report that RS released completely and talk with them tomorrow.

    I am by no means an expert on exploits, but as far as I have always understood, they essentially always drop and execute a malicious payload. From what I understand, the reason they do this is because the initial exploit stage only has a very small amount of memory that it can utilize, so it simply does not have enough space to include all of the necessary code to perform their malicious tasks. So the whole purpose of this initial exploitation stage is to execute a payload like DP, so then they will have plenty of memory available to them to be able to do whatever they want. I read somewhere that there are "ways around this", and I am hoping that what they mean is that they simply execute a payload.

    So I never knew exactly why exploits always seem to execute a payload, but it is starting to all make sense now. But since this was the case, I was not concerned about the exploit, I just wanted to block the payload, because VS is not a specialized anti-exploit... I just want to block the payload.

    1. The problem is that the "initial container" is the exploit... it is not a malicious payload. None of the 4 application control products in my initial test will block the exploit EB. The ONLY 2 things that will block the exploit is patching the system, or possibly a specialized anti-exploit product. The problem is that these 2 protections are not generic (like how simply blocking the malicious payload is), and in at least some cases (probably many), do very little to protect against zero days.

    2. I agree

    3. In general, I agree, but since a rundll32.exe command line was not blocked, I am still not sure what happened in this part of the attack.

    You are assuming that this type of attack will originate as a malicious payload, and this simply is not the case... it originates as an exploit, which none of the 4 products block.

    This is the reason that the actual attack vector has very little to do with this type of attack, simply because the blackhats could package this type of attack into many different attack vectors... for example a web exploit.

    So this is the nightmare scenario that MRG was concerned about, except it is actually a little worse than that. What RS is suggesting is to skip the backdoor completely and just run the malicious payload directly at the kernel level. Which, if you ask MRG, they would probably say something like "yeah, of course, you could do that too". Really, it does not matter either way... if you need a backdoor too, then do both... if not, just run the malicious payload at the kernel level directly.

    When the attack moves from the kernel space to the user space, it can drop a new payload, for example, WannaCry, but at that point, the damage is already done if the malicious payload dropped from the exploit is not blocked.

    The other question is, does the exploit itself have enough memory available to it to include all of the malicious code required to perform the attack in its entirety. I mean, it is bad enough that an exploit succeeds, but if can do everything it needs to do without even executing a malicious payload, well, none of the 4 products can block this. The only hope here is patching or trying to block the exploit altogether with a specialty anti-exploit product. Thankfully, from what I can tell, this does not appear to be the case... it looks like the exploit is required to execute a payload.

    Apparently, there are only a handful of people that are able to develop an attack this sophisticated, and the problem is that with the NSA leaks, everyone now has all of the code and tools they need to do much, much worse. I was not joking when I said the genie is out of the bottle. You are probably aware that this attack has already been adapted to work on Windows 10.

    I have been talking about how now all someone needs to do is to adapt this attack into something more malicious, but I was shocked how quickly the whitehats were able to do so, and the blackhat are certainly working on it as well. I guess we will see.
     
    Last edited: Jun 7, 2017
  7. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    Think of it this way. The exploit / payload is basically a bomb with a fuse.

    The fuse is the exploit.

    The bomb is the payload.

    The attack vector is how the bomb is delivered.

    Do not worry about how the bomb is going to get to its destination, it is surely going to get there one way or another.

    What is vital is that the fuse is cut while it is burning, before the bomb explodes.

    If you can stop the fuse from being lit with a Windows patch or a specialty anti-exploit product, then that is even better. But the problem is that neither of these two mitigations are effective against some or most zero days.
     
  8. guest

    guest Guest

    1- Yes, the initial container is the exploit because it came from another compromised machine in the network (aka Patient Zero).
    EB need the machine IP to detect if SMB is present then infect it , it can't do it from outside the network.
    2- Great ! it was my main point since the beginning.
    3- in fact VS/ERP disrupt the reverse connection attempt that have to be made by rundll32.exe.
    To be simple, once the backdoor is created, EB-DP try to connect to the attacker framework/platform (in our case it is Kali); so the attacker can have full access to the target (upload other malware, try to infect another machine in the network, etc...)

    1-if it is already inside the networks. if not EB-DP, need a vector to penetrate the network from outside ; like you said it can be delivered by a webexploit, or a misconfigured port left open, etc...
    The attack doesn't pop-up by magic in a system out-of-nowhere , it come from "somewhere" . somewhere can be many things but attacks always come from outside the targeted network.
    2-Yes indeed , i agree, I choose an executable as initial container because it is the classic vector in most infections, (people click on something, could be a mail attachment, a downloaded exe , etc...)

    Exact , it is the worst part of this exploit, some already work on that trying to remove the backdoor part...

    Yes it is what i said from the start. Anti-exe/SRP should block Wannacry part but not EB-DP.

    it is a very light exploit with few functions, so i believe it has all it need to create the shell to the attacker framework (from where other attacks would be launched); at this point it seems to act as a classic RAT.

    Yes or block port 445 to prevent EB to spread (i read this somewhere). but this is not the job of anti-exe/SRP
     
    Last edited by a moderator: Jun 7, 2017
  9. _CyberGhosT_

    _CyberGhosT_ Registered Member

    Joined:
    Mar 2, 2015
    Posts:
    457
    Location:
    MalwareTips "Your Security Advisor"
    Nice, I like the analogy used there, and all that reading just before it made perfect sense.
    Thanks Dan for taking the time to educate us even though you didn't have to.
    That means a lot to those of us that have the ability to see this for what it is.
    You RoCk Brother. :thumb:
     
  10. Telos

    Telos Registered Member

    Joined:
    Jul 26, 2016
    Posts:
    171
    Location:
    Frezhnacz
    +1 , and guest too... Very helpful for us lay peoples
     
  11. ichito

    ichito Registered Member

    Joined:
    Jan 14, 2011
    Posts:
    1,997
    Location:
    Poland - Cracow
    @VoodooShield
    @guest
    Guys...you are the "giants" ;)
    Thanks for very instructive and helpful dialog :thumb:
     
  12. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    This is why I love virtualization. Block any access to ksecdd.sys (Kernel Security Support Provider Interface) and you will have no issues on the kernel level (malware can't exploit what they can't ever see).
     
    Last edited: Jun 7, 2017
  13. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    1. No, there are other attack vectors... we just do not know enough about the attack vector that was used in the initial WannaCry outbreak, to be able to discuss it intelligently, or to use it an an example. Either way, the fuse and the bomb are going to get there... no question.

    Here is one possible scenario (same basic link, just scroll down):

    https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-300#post-2682130

    https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-300#post-2682138

    2. I must have misread your second point, but when you add “DP”, it makes the statement untrue. Besides, if you can block the exploit’s main job from delivering and igniting the malicious payload, you have effectively blocked the exploit as well.

    3. I think I agree, but I fail to see your point. Either the payload was blocked or it was not.

    It really is as simple as this…

    The main job of application control solutions (SRP / AE) is to block malicious payloads, correct?
     
  14. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    Hey CS, how are you? Do you mean CF with your settings? I am not familiar enough with CF to know how its virtualization feature works, but one can assume that if the attack ran outside of the scope of virtualization from the beginning, that this could be an issue. For example, if the exploit was packaged as a web based exploit, CF would have no issue protecting the computer... but what if a different attack vector is utilized? I honestly do not know (and would not know for sure unless we tested), but I have my guesses, and I would bet you a file that I have a point ;).

    Ok, really, that is the last time I joke about your pic... I just think it is funny ;).
     
  15. guest

    guest Guest

    2- if lsass.exe is exploited (whatever the product) it is game over, the attack is successful so the products failed to protect the system. There is no doubts about it, it was reported, explained in details in many articles. Now which module did it is irrelevant, what matters is the result (and the result is lsass.exe being exploited).
    3- rundll32.exe is the consequence of lsass.exe being exploited. It create the reverse connection and allow the attacker to continue his attack. but the system is already exploited.

    I put screenshots to show the effects and consequence of lsass.exe being exploited, there is no denial possible, those are proven facts.

    define malicious payload? if blocking an exe/dll/drivers to execute and load a payload, yes. if it is via another vector? then no.
    The understanding of the mechanism used by the soft to protect is essential, it is not because one soft do it in a certain way, that others do it the same way.
    Devs prioritize a method they deem more efficient, it doesn't mean other methods are weak.

    - The common point of SRP and anti-exe is that executables (and some other interpreters) are blocked to run.
    Now some products have additional features: Appguard have memory protection and prevent a process to read/modify another. Others like VS or ERP have command line parser and monitor Parent/Child relations.
    - The difference is that anti-exe prompt the users for a decision; SRP doesn't, it just block (or not) based on policy.
     
    Last edited by a moderator: Jun 7, 2017
  16. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    DP is the malicious payload that VS blocked. This demonstrates that in this attack EB failed to do its main job.

    If you want to try to block EB before hand, that is cool, but that is going to be difficult for true zero days.

    The main job of application control solutions (SRP / AE) are to block malicious payloads, correct?

    YES OR NO (PLEASE ONLY USE 2-3 LETTERS IN YOUR NEXT REPLY)
     
  17. VoodooShield

    VoodooShield Registered Member

    Joined:
    Dec 9, 2011
    Posts:
    5,881
    Location:
    United States
    I just thought of another analogy that might be helpful.

    Take antispam mechanisms… they are HIGHLY effective in blocking a lot of the phishing emails that have malwareware links.

    But they obviously cannot catch every single attack, and when they miss one, it is the job of the application control mechanism to stop the attack. If the application control mechanism does not stop the attack and says “well, the antispam mechanism should have blocked the attack”, then that is simply passing the buck… like “it’s not my job!”.

    Either way, the application control utility (SRP / AE) has one very simple job, and it either works or it does not.

    Or if you wanted to put it another way: www.youhadonejob.org

    You had one job.
     
  18. guest

    guest Guest

    VS and the others didn't bock EB, your own video show it ! lsass.exe was exploited ! VS just blocked rundll32.exe which create a Reverse Connection !
    i even put screenshots to ease the understanding. can't you read?!

    The exploit you are talking about attacks SYSTEM. When that happens, even if you have AppGuard and VS and other softs the system is compromised. If you are blocking at rundll32 or wannacry.exe part then the system has been compromised.

    there is no shame to admit than VS was bypassed like all others in that case, but if you want live on denial, so be it...

    payload:

    https://heimdalsecurity.com/glossary/payload

    so there is no "yes or no" ! it depend of the container the soft is supposed to block, do you understand that ?

    ERP block exe only
    AG Consumer block by default exe/dll/drivers launched from user-space
    SoB block exe/dll/drivers.
     
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    What the heck, are you guys still discussing? Like I said, it seems like Dan and people like guest and myself seem to know for (almost) sure that they are right, so let it now be tested by experts from MRG, no point to keep repeating the same stuff again and again. I'm sure that MRG won't charge for it, because it's not an official test.

    And the discussion is very simple, Dan says that VS blocked DP. Others say that it didn't block DP itself, but it blocked DP from running the payload, which in real life would have been the WannaCry ransomware. And why do I believe that VS didn't block DP? Because it's an in-memory payload triggered directly by the EB exploit. So no need to continue this discussion because there is really not much left to be said, do we all agree on this?
     
  20. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590

    AMEN!!!!
     
  21. ghodgson

    ghodgson Registered Member

    Joined:
    Dec 20, 2003
    Posts:
    835
    Location:
    UK
    Yes please !
     
  22. guest

    guest Guest

  23. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Honestly, I was a bit surprised to see that they continued the discussion, I promised Peter2150 via PM to stop trying to explain my point of view, unless new details about this attack may arise. But it's clear that Dan sees things differently, so no point to continue. :D
     
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    BTW, not to ignite things, but I've just read on the Avast blog that no user interaction was required for this attack. So this means if security tools couldn't block systems from being exploited and couldn't block the payload (DP or WannaCry), the system was owned. This means that this "Patient Zero" argument is irrelevant, I really doubt that a tool like AG would have blocked this attack, but I may be wrong.

    Thanks for the link, they really took a swipe at Cylance.
     
  25. zarzenz

    zarzenz Registered Member

    Joined:
    May 19, 2002
    Posts:
    502
    Location:
    UK
    Well... having followed this thread for a long time since installing VS... all I need to know is one thing.

    VS is protecting my system from all these exploits or whatever you want to call them.

    I don't need anything else to do that if I have understood all these discussions correctly. I liked the analogy with the fuse being cut best as that said everything I needed to know because that tells me it doesn't matter that much what is going on behind the scenes because VS actually prevented the nasty end product from running.

    That's good enough for me.

    Thanks Dan.
     
  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.