App Review Quick Follina test ;).

It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
Status
Not open for further replies.
Content created by
VoodooShield

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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?
 

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
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?
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.

BTW, Andy might be able to tweak HC so that the Documents Anti-Exploit component blocks Follina and other similar attacks. I am not sure either way, I would have to look at the source code to tell you for sure. One thing that is certain is that simply blocking msdt.exe is not the correct solution because now that the cat is out of the bag, bad actors will be discovering all kinds of different Windows vulnerable processes to exploit, so it is important that all Windows processes are protected.
 

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
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.
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.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,510
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.
 
Last edited:

dinosaur07

Level 12
Verified
Top Poster
Well-known
Aug 5, 2012
577
Great 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.
 

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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 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 commented (y) Maybe @NoVirusThanks will as well.

EDIT

I just discovered that Andy did test the Follina exploit (y) I saw that post yesterday but did not realize it was his own testing.
 
Last edited:

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
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.
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?

If you answer "yes" to either of the two above questions, then there is no point in continuing this conversation.

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.

And absolutely, I would love it if you found a bypass for VS. Anything we can do to better protect our uses is sincerely appreciated.

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. And I welcome any and all VS bypasses. I would love for someone to post a video showing a valid bypass.
 

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
Great 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.
Absolutely, let's get Harlan and the boys on this stat ;).

And while they are testing, they can communicate with the devs to make sure everything was tested correctly. BTW, someone finds a error in my tests, please post it. I know when other people test VS, there are a few things they have to keep in mind in order to test properly, and pretty much all security product is like this.

With VS, here are some simple testing guidlines...

1) It is a good idea to reset the whitelist after each test
2) Depending on the test, you might want to disable the Allow by Parent feature in VS (for example if you are running a testing simulator like Ransim)
3) If you are going to be testing for a long time with no user interaction, you might was to disable VS's auto deactivation feature

That is all I can remember for now, but if I think of more I will add them to the list.
 

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
Thank 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 commented (y) Maybe @NoVirusThanks will as well.

EDIT

I just discovered that Andy did test the Follina exploit (y) I 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.
 

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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.

Well 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!
 

Attachments

  • OSA Protections20220612.txt
    6.2 KB · Views: 131
  • Like
Reactions: danb

danb

From VoodooShield
Thread author
Verified
Top Poster
Developer
Well-known
May 31, 2017
1,719
Well 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 ;).
 
  • Thanks
Reactions: wat0114

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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 ;).

Too bad, I thought it would do better, but both good and interesting to know. Thank you so much for testing!
 
  • Like
Reactions: danb

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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).

Thank you for this Plat1098 (y) Well I don't honestly know what to think :unsure: but it is very interesting. I will not call into question anyone's testing, including Dan's, because I'm not qualified to do so. If I tried these tests I'd screw them up somehow :D
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,510
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?

No. Winword does not work with high privileges and the Follina exploit cannot elevate anything when SWH settings are enabled.

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.

Simply send me the document and the HTML payload with a password-protected archive.

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.

I commented on your similar posts a few times. Your argument is simple. You do not like SRP because it is different from VS. Furthermore, we do not talk here about SRP, but about SWH (and H_C). Much of your arguments are invalid here. It is true that VS is more context-aware compared to H_C, but only a little bit. Most of the blocks rely on a similar method: VS --> WhitelistCloud + VirusTotal and H_C ---> Forced SmartScreen.

Andy, you should not take it personally that SRP is unable to block modern threats.

It is not the purpose of SWH or H_C. The purpose is preventing to deploy modern threats to the computers of home users. Everyone can check how effective it is. The H_C was tested for several months against malware on Malware Hub. Anyone can easily compare the results with the results of VS.
 

SumTingWong

Level 28
Verified
Top Poster
Well-known
Apr 2, 2018
1,782
@danb
Can I run voodooshield along with bitdefender antivirus free?

Do you think it is redundant to have voodooshield along with bitdefender antivirus free?
 

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
Well I had some problems getting the command to find Python, but finally got it resoled. After I ran the command I got this:

Follina command.png

...as expected. Then when I double-clicked the clickme.docx file (10kB file size) it opened only to a blank page then nothing else happened; no alerts from OSA, but in the H_C firewall logs I see it was blocked - as I sort of expected, because i block MS Office apps via H_C firewall settings and because I have severely limited technical skills in this area:

Code:
!!! 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

That's where I'm at now. No other testing yet. Hopefully I didn't screw up :D

EDIT

Actually that remote IP address belongs to Microsoft :rolleyes: Not what I expected but I guess that's normal for MS apps when they open they connect to mothership MS.
 
Last edited:
Status
Not open for further replies.

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top