Open MalwareTips from your Home Screen or desktop. Follow discussions, find answers and pick up where you left off.
If you cannot find an install option, update your browser or use its bookmark option to keep MalwareTips close.
After installation, open the app and sign in. Enable push notifications in Preferences if you want alerts. On iPhone and iPad, push requires a Home Screen web app and iOS or iPadOS 16.4 or later.
Sign in to manage notificationsInstallation is optional. Your notification settings stay under your control.
Ooops, I forgot to explain that, thank you for prompting me. OSA blocked 2 of the 5 PoC's via suspicious command line, so these were legitimate Follina blocks. Blocking by suspicious command line is great, as long as you have every possible suspicious string covered. But as you can see in the test, not all suspicious strings were covered, so there were bypasses on 3 out of 5 PoC's. In other words, it is better to block with the anti-exploit mechanism, simply because it is pretty much guaranteed to block the attack. I also included these blocks, not only to be fair to OSA, but also to further demonstrate the validity of the test.Dan,
thank you for sharing your test results. OSArmor generated some msdt.exe alerts with parent process MS Edge, but it still failed? Sorry if I missed something obvious, but what happened there?
BTW, most devs appreciate other devs testing their software for them. I hope other devs test VS and find something that needs to be fixed, it only makes the product stronger.I think it's good marketing to show the strength of your product. And I don't have any doubts about the excellence of Voodooshield. But it's not good practice to show what you perceive as the weaknesses or failures of your fellow developers and competitors. You're biased, it helps hackers, and it doesn't enhance the ethical reputation of your company.
Ooops, I forgot to explain that, thank you for prompting me. OSA blocked 2 of the 5 PoC's via suspicious command line, so these were legitimate Follina blocks. Blocking by suspicious command line is great, as long as you have every possible suspicious string covered. But as you can see in the test, not all suspicious strings were covered, so there were bypasses on 3 out of 5 PoC's. In other words, it is better to block with the anti-exploit mechanism, simply because it is pretty much guaranteed to block the attack. I also included these blocks, not only to be fair to OSA, but also to further demonstrate the validity of the test.
Thank you very much, I have no doubt that VS would be this effective.I tested every (and I mean every) zero-trust / deny-by-default product against Follina, and they all failed, except VS.
Andy, here are two very simple questions...Please, show us the test details for SWH (or H_C) and I will explain to you where you made a mistake. This is probably a similar mistake like on your "test" when you "proved" that Microsoft policies and MS Office settings could not block macros (although they block macros all around the world). I tested Follina by myself here:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-992545
Each infection stage was controlled by me via Event log, Process Explorer, and similar tools.
I did not exploit VS when "Always ON", but it can be done in "Auto Pilot" settings. Normally it would not be an exploit, because it used a method that was not covered by the VS design. It can be considered an exploit only in your particular case, because you consequently refused to accept that such a well-known attack could be successful. If you want I can publish this "exploit" - I found it on your clear request.
Absolutely, let's get Harlan and the boys on this statGreat test. In order to not be questionable in any circumstance it would've been better if it'd been done by some independent testers here in MalwareTips to not arise any dispute. It is also difficult to be done by us separately as we don't have the time and the requirements to do it.
If you let me know what the enhancements are, I would be happy to test. Please do not tell me the enhancement is adding msdt.exe as a vulnerable processThank you Dan for clarifying. I and others are using OSA and/or H_C, SWH with settings enhanced above the defaults, so it would be interesting to see how they would perform against the test with those enhancements in place. I see that @Andy Ful has commentedMaybe @NoVirusThanks will as well.
EDIT
I just discovered that Andy did test the Follina exploitI saw that post yesterday but did not realize it was his own testing.
If you let me know what the enhancements are, I would be happy to test. Please do not tell me the enhancement is adding msdt.exe as a vulnerable process. Because 3 months from now it will be a different vulnerable Windows process. In other words they ALL need to be covered out of the box.
Wow, you do have a lot of the protections enabledWell I do have msdt.exe as an SRP Blocked Sponsor in H_C, so I will not bother with that utility, and then Andy tested it as well with better results, so I don't want to potentially trigger any "conflict of interest". As for OSArmor, I have uploaded my Settings with several additional Protections enabled from the Defaults, thus the enhancements. You just have to rename the extension to .ini then import it. Thank you in advance!
Wow, you do have a lot of the protections enabled. It appears to be the same result. One of the exploits quit working for some reason (I tested both protected and unprotected), but the other 4 are definitely the same result. I would look into the one that quit working, but I have to be somewhere soon. It is time to relax and have fun
.
A tweet from NoVirusThanks who conducted a test of his own. What do you all think? This was just posted to Twitter like a little over an hour ago.
Definitely not cut-and-dried, which makes it more interesting (in my opinion).
Andy, here are two very simple questions...
1) Are you comfy with HC or SWH allowing Winword to automatically spawn msdt.exe elevated?
2) Would you be equally comfy with HC or SWH allowing Winword to automatically spawn bcdedit.exe elevated?
However, if you answer "no" to both, then please let me know what test details you would like, I would be happy to provide them. Better yet, go to github and test until your heart is content. Who knows, you might even find a VS bypass.
Anyway, this is the entire reason I am not a fan of SRP, and I have been preaching this for a very long time now, but now that we have a concrete, in-the-wild, real-world example, users can finally understand what I have been preaching about. The problem with SRP is that it does not have any context. At all. So sure, it can blindly block anything you want it to with zero context, but that is of little use. In order to block something correctly, you have to know certain elements of the attack chain, like the parent process, and the command line. The only real element that SRP sees is the process path. If SRP were so great, trust me, I would have created a SRP version of VS a long time ago. 10-20 years ago you probably could have gotten by with SRP and not knowing certain elements of an attack chain, but the problem is that in order to detect modern malware, you absolutely need to know these attack chain elements.
Andy, you should not take it personally that SRP is unable to block modern threats.
You may.Can I run voodooshield along with bitdefender antivirus free?
Free by itself is excellent. Use it with VS if you're paranoid.Do you think it is redundant to have voodooshield along with bitdefender antivirus free?

!!! Blocked Windows Firewall outbound connections !!!
Event[1]:
Local Time: 2022/06/12 14:14:48
ProcessID: 10644
Application: C:\program files\microsoft office\root\office16\winword.exe
Direction: Outbound
SourceAddress: 192.168.1.72
SourcePort: 52495
DestAddress: 52.168.117.169
DestPort: 443
Protocol: 6
FilterRTID: 78701
LayerName: %%14611
LayerRTID: 48
RemoteUserID: S-1-0-0
RemoteMachineID: S-1-0-0
Members who viewed this thread in the last 5 minutes