App Review Quick Follina test ;).

[Andy Ful]

I second that as well. There is absolutely nothing wrong with a spirited conversation, as long as it does not become personal or shady.

Discussions are actually a great way to learn, and there was definitely some good that came out of it.

The funny thing is that if HC would have logged the powershell "block", it never would have been included in the video. Maybe Andy will test HC and find out why the powershell event was not logged. In all fairness, as far as testing goes, if an event is not logged, then it didn't happen.

https://malwaretips.com/threads/simple-windows-hardening.102265/post-992985

BTW, make sure to watch Leo's new video on Follina, it is one of his best videos yet.

Yes. It also correctly shows that the exploit really worked (calc is executed). If the exploit is prepared to run calc and the calc is not run, then the exploit is prevented/blocked. The exploit can be blocked at several stages:

1. Winword cannot make outbound connections (like in FirewallHardening included in H_C).
2. Winword cannot update the content (like in DocumentsAntiexploit tool included in H_C).
3. MSDT is blocked (like in VS or ConfigureDefender HIGH settings).
4. PowerShell is restricted/blocked (like in the SWH/H_C; OSA non-default config).
5. Suspicious PowerShell CmdLines - detected when the code is executed (OSA default settings, probably also VS).

Edit.
My test related to OSA was on the older free version. It may be that the newest version has got additional features.

 

[danb]

Andy, first, thank you for taking the time to test for yourself, I truly appreciate it when people spend the time to test instead of simply reading about and researching attacks. But I have to say, it is ironic that during the DP/EB debate, you insisted that the only thing that mattered was that the initial exploit succeeded. What is even funnier is the DP/EB attack was a kernel mode attack where the initial DP exploit could not have been prevented either way on day zero with mitigations at the time, so blocking in later stages was actually better than not blocking anything at all. The difference with Follina is that the initial exploit can be prevented in its earliest stages. Andy, you can’t have your cake and eat it too.

Second, this attack can either be 1) blocked in its earliest stages by blocking msdt.exe with a monolithic kernel mode blocking mechanism, or 2) you can try to block it with a hodgepodge collection of tools that might possibly block future similar attacks, assuming PS is included in the attack chain.

Third, calc did pop on OSA 1.7, but it is completely irrelevant. You can search all my posts on MT and you will see on multiple occasions I have discussed how I always thought that popping calc is a ridiculous test that demonstrates absolutely nothing. If you think that popping calc is a true indication of this or any other attack succeeding, then you are sadly mistaken, which is why I did not care in the video if calc popped or not.

Forth, you claimed at the link below "The attack is fully blocked by SWH default settings and can be separately blocked by the DocumentsAntiExploit tool (delivered with SWH)." This is patently false.

New Update - Simple Windows Hardening

Will protecting WSH against this attack help? Windows MSDT zero-day now exploited by Chinese APT hackers

malwaretips.com

You clearly did not actually test Follina, you simply read about it on Cybereasons's website and published the info as your own, without taking the time to test. There was a lot of discussion about which products block Follina and which ones do not. I asked over a week ago if anyone had tested Follina yet, and no one had, so once again, I stepped up and spent the time to test.

Andy, you really should test more, I think you will be amazed what you will find. Besides, it is actually really fun.

Fifth, I really am done discussing this. I apologize if this post sounded harsh, but it is what it is. Thank you!

 

[Gandalf_The_Grey]

And Follina is patched now...

Microsoft patches actively exploited Follina Windows zero-day

Microsoft has released security updates with the June 2022 cumulative Windows Updates to address a critical Windows zero-day vulnerability known as Follina and actively exploited in ongoing attacks.

www.bleepingcomputer.com

 

[Andy Ful]

Forth, you claimed at the link below "The attack is fully blocked by SWH default settings and can be separately blocked by the DocumentsAntiExploit tool (delivered with SWH)." This is patently false.

Why do you think so?

New Update - Simple Windows Hardening

Will protecting WSH against this attack help? Windows MSDT zero-day now exploited by Chinese APT hackers

malwaretips.com

You clearly did not actually test Follina, you simply read about it on Cybereasons's website and published the info as your own, without taking the time to test.

Your words are unacceptable and mean. I reported your post to MT staff. You do not have the right to say such things only because you do not understand much from my explanations. If someone wants (except you) to repeat my test I can post the DOCX, HTML script, and detailed instructions on how to do the proper test. I used the XAMPP server for HTML scripts. You can find in my post some details that cannot be found anywhere on the web:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-992985
For example, the fact that the PowerShell blocks via ID=4100 are not logged when sdiagnhost.exe is used.

Furthermore, the insight about what should be monitored did not come from the Cyberreason article but from another article:
https://www.paloaltonetworks.com/bl...d-playbooks-for-msdt-zero-day-cve-2022-30190/

This article was mentioned on the Wilderssecurity forum. It helped me to prove in some other tests that msdt.exe does not run PowerShell in the Follina exploit, but only passes the code further. The PowerShell is executed only by sdiagnhost.exe - that is why the final payload is a child process of sdiagnhost.exe.

In my test, OSA free did not block the exploit too (this means nothing because it is outdated). But in your test, it detected the suspicious code in two HTML scripts, so it is very probable that it could block some exploit samples if you would make your test properly. Opening the HTML scripts in the web browser is not harmful, because everything is executed in the web browser sandbox.

 

[danb]

Why do you think so?


Your words are unacceptable and mean. I reported your post to MT staff. You do not have the right to say such things only because you do not understand much from my explanations. If someone wants (except you) to repeat my test I can post the DOCX, HTML script, and detailed instructions on how to do the proper test. I used the XAMPP server for HTML scripts. You can find in my post some details that cannot be found anywhere on the web:
https://malwaretips.com/threads/simple-windows-hardening.102265/post-992985
For example, the fact that the PowerShell blocks via ID=4100 are not logged when sdiagnhost.exe is used.

Furthermore, the insight about what should be monitored did not come from the Cyberreason article but from another article:
https://www.paloaltonetworks.com/bl...d-playbooks-for-msdt-zero-day-cve-2022-30190/

This article was mentioned on the Wilderssecurity forum. It helped me to prove in some other tests that msdt.exe does not run PowerShell in the Follina exploit, but only passes the code further. The PowerShell is executed only by sdiagnhost.exe - that is why the final payload is a child process of sdiagnhost.exe.

In my test, OSA free did not block the exploit too (this means nothing because it is outdated). But in your test, it detected the suspicious code in two HTML scripts, so it is very probable that it could block some exploit samples if you would make your test properly. Opening the HTML scripts in the web browser is not harmful, because everything is executed in the web browser sandbox.

Everyone is able to search your name for the term VoodooShield. They can also search mine.

That was the reason I ran plain html tests. It was to show that blocking by suspicious command line works sometimes, but it fails sometimes too. That was what I actually publicly guessed a week prior to testing.

 

[Andy Ful]

Everyone is able to search your name for the term VoodooShield. They can also search mine.

That was the reason I ran plain html tests. It was to show that blocking by suspicious command line works sometimes, but it fails sometimes too. That was what I actually publicly guessed a week prior to testing.

OK, that makes sense for OSA. You made a flaw by testing the exploit when OSA and H_C were both enabled. You cannot be sure which protection blocked the exploit if both were enabled.

 

[Soulbound]

This is the actual thread that needed to be locked, not the other thread.

Please discuss in private further about this thread if need be.