Vulnerable App / Sponsor Test

Forums Networking & Cybersecurity General Cybersecurity Discussions Vulnerable App / Sponsor Test

  • Post
    Dan
    Keymaster
    US
    I created a quick and dirty test app that will help me better explain my point about the handling of vulnerable processes.  There are several false positives on VirusTotal for this file, but I promise this is a clean app.  All it does is execute a command line that lists the files in the current directory.  The file is currently named msbuild.exe, but you can rename it to whatever your favorite vulnerable process is… firefox.exe, chrome.exe, outlook.exe, etc.

    Anyway, when you run this file against VS, the initial executable will be blocked.  If you instruct VS to allow the file, then click the Test button, it will simulate a command line executing from a vulnerable app, so VS will block the command line.

    Please test your favorite deny-by-default software with this app, and feel free to move the file to different locations around the hard drive to see what happens.

    Keep in mind…

    1. If you click the Test button and the command line is not blocked, it might be a good idea to verify with your deny-by-default dev that the command lines associated with vulnerable processes are being handled correctly.
    2. If the file is named “msbuild.exe” and the initial executable is blocked simply because it is named “msbuild.exe”, this is almost as bad as not blocking the sponsor at all. The goal in correctly handling vulnerable processes / sponsors is not to block the entire sponsor itself for all behaviors (including benign).  The goal is to block the sponsor from malicious behaviors.  In doing so, you let the OS perform every single necessary and benign task, while blocking all of the malicious tasks.  There is a reason Microsoft does not disable these vulnerable items by default… they are necessary components that are commonly utilized by devs.

     

    This is why VS considers the entire chain of events / behaviors that include the parent process, command line and other elements.  I might write more about this soon… I really need to take the time to explain better how VS works.

    Anyway, if you take the time to test, I am certain you will find this intriguing and will probably lead to lengthy discussions, and ultimately everyone will be more protected no matter what security software you use.  And if anyone has any suggestions on how I can improve VS, I am all ears and I would greatly appreciate it.

    http://www.voodooshield.com/Download/msbuild.exe

    Have a great weekend!

    • This topic was modified 8 months, 3 weeks ago by Dan.
    0
    0
Viewing 3 replies - 1 through 3 (of 3 total)
  • Replies
    Dan
    Keymaster
    US
    I forgot to mention that the other reason to not just blindly and lazily block the initial sponsor (#2 from above post) is so the vulnerable process “anti-exploit” mechanism can be applied to pretty much all Windows processes. In a nutshell, the OS does exactly what it is supposed to do, and nothing else (based on the event chain)… which happens to work seamlessly with our snapshot / toggling. Once you realize that VS applies this mechanism to all but a small handful of Windows processes, you will realize how advanced and secure it is.

    In other words, if you want to harden Windows, blindly and lazily disabling key components is one way to do it. Or you can develop something more sophisticated that intelligently hardens windows by carefully monitoring the entire chain of events. VS is not a traditional, standard or simply anti-exe / application whitelisting utility… and it cracks me up when people suggest that it is. As I have said many times, even though it appears deceptively simple on the surface, under the hood VS is far more advanced then what anyone would guess. Part of that is my fault for not explaining how it works and educating people on VS.

    Do you guys remember a couple / few years ago when the VS betas had a lot of strange blocks? Well, this is what we were developing and refining. It took a very long time to work out the kinks and was a major PITA for the beta testers and myself, but it was certainly worth it.

    BTW, when testing VS with the test app, be sure to delete the command line if you move the file to a different location on the hard drive. I did this a couple of times and wondered why VS seemingly allowed something it should not have ;).

    0
    0
    simmerskool
    Participant
    none
    I just downloaded the msbuild.exe file after quick reading of your 2 posts.  I’m sure I need to read them both again.

    Meanwhile, I did not run or try to open msbuild, but it got a malware popup by WiseVectorX 2.09 real time which is a Korean Ai AV I’m running alongside Windows Defender and VS 5.64. Heur.ML.PE.C

    WV is giving me 2 options exclude or quarantine.  I’m sure that’s not the point of the test.  But gee I almost never get any malware alerts, “exciting.”  Running win10 in a vm.

    0
    0
    Dan
    Keymaster
    US
    Oops, I should have figured that would happen ;).  It is no problem, it really is a clean file / false positive.  It is an intriguing test that sheds some light on protection capabilities.
    0
    0
Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.