App Review Quick Follina test ;).

[danb]

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

It looks like they released a new version a few hours ago, and it appears they added msdt.exe as a hardwired vulnerable app. I would test more, but I am burned out for now. Sure, thank you as well!

 

[danb]

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).

I think it is pretty cut and dry. Some devs think it is okay for Winword to spawn msdt.exe elevated, and some do not.

 

[danb]

danb test v1.7 but NoVirusThanks test v1.7.1​

Yes, I tested v1.7, which was current last night, at the time of testing. Props to NVT for addressing this issue quickly.

 

[Andy Ful]

I think it is pretty cut and dry. Some devs think it is okay for Winword to spawn msdt.exe elevated, and some do not.

I do not know the devs who think so.
The msdt.exe can automatically run with high privileges only if Winword has been also executed with high privileges. On Windows 10/11 the users run Winword with medium privileges, so msdt.exe is automatically run with medium privileges. In the Follina attack, the elevation of msdt.exe would require an additional exploit (privilege escalation).
This would be a different test.

Running Winword with high privileges can happen on Windows Server. So, if you would test VS and OSA on Windows Server, then the scenario with msdt.exe running with high privileges could make sense.
Anyway, testing OSA without cooperation with the OSA developer seems to be unethical. You should avoid such tests, especially when the tested software can be a concurrency to VS.

 

[kC77]

@danb & @Andy Ful I am so appreciative of both your talents and skills x thankyou!

 

[danb]

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



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



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.



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.

Andy, I have to be honest with you, your entire post was quite deceptive. You and I have already discussed VS's last Malware Hub results. I asked the testers to test VS on AutoPilot because we already knew that if VS was ON, it was going to block 100% of the samples. So I figured it would be a good time to harden VS's AutoPilot mode with EV signed binaries, so I worked with the testers to give them hints on how we might be able to bypass AutoPilot. Guess what, that testing hardened the heck out of VS's AutoPilot mode, and we ended up creating a brand new feature that solved the EV cert issue.

I could send you the samples, or you could just download them from here: Build software better, together

Choose any sample and there is a 90% chance you will experience the same result I did. If you are not able to find the samples, and if you decide to be non-deceptive, then I will happily send you the samples.

VS does not rely on WLC or VoodooAi at all, and it has not used VT for probably close to a year or more. SRP has zero context and VS has a full Anti-Malware Contextual Engine.

 

[danb]

@danb
Can I run voodooshield along with bitdefender antivirus free?

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

Yes, VS is a great compliment to any traditional or next-gen AV. Basically, if you want to lock your computer when you are browsing the web or checking email, then VS will work great for you. Some say VS is overkill. But what good is underkill if you are not sufficiently protected? Underkill is the literal definition of Security Theater.

 

[Andy Ful]

View attachment 267459
View attachment 267460

Now I understand why you think that only VS passed the test. Spawning msdt.exe is not an exploit. The exploit is when sdiagnhost.exe is executed and a payload as a child process of sdiagnhost.exe. In most POCs the Windows Calc is executed as a payload.
Your screenshots show that H_C blocked the exploit.

 

[danb]

I do not know the devs who think so.
The msdt.exe can automatically run with high privileges only if Winword has been also executed with high privileges. On Windows 10/11 the users run Winword with medium privileges, so msdt.exe is automatically run with medium privileges. In the Follina attack, the elevation of msdt.exe would require an additional exploit (privilege escalation).
This would be a different test.

Running Winword with high privileges can happen on Windows Server. So, if you would test VS and OSA on Windows Server, then the scenario with msdt.exe running with high privileges could make sense.
Anyway, testing OSA without cooperation with the OSA developer seems to be unethical. You should avoid such tests, especially when the tested software can be a concurrency to VS.

It was obviously important enough for NVT to fix their issues within 8 or so hours of me posting the test, that alone should tell everyone what they need to know.

Please see post Video - Quick Follina test ;)..

 

[danb]

Now I understand why you think that only VS passed the test. Spawning msdt.exe is not an exploit. The exploit is when sdiagnhost.exe is executed and a payload as a child process of sdiagnhost.exe.
Your screenshots show that H_C blocked the exploit.

Absolutely not, there are no blocks in the H_C logs, except for my Uptime.exe test blocks.

 

[danb]

Now I understand why you think that only VS passed the test. Spawning msdt.exe is not an exploit. The exploit is when sdiagnhost.exe is executed and a payload as a child process of sdiagnhost.exe. In most POCs the Windows Calc is executed as a payload.
Your screenshots show that H_C blocked the exploit.

No, that particular test sometimes spawns calc and sometimes does not, but either way H_C did not block it. Test and you will see.

I am done talking about this. If you are comfy with Winword spawning msdt.exe eleveated, then I will never be able to convince you otherwise. Just keep in mind, NVT that it was important enough to block msdt.exe asap.

 

[danb]

Anyway, testing OSA without cooperation with the OSA developer seems to be unethical. You should avoid such tests, especially when the tested software can be a concurrency to VS.

Andy, users can search for VoodooShield on MT for your user name, and find multiple instances of you falsely claiming that you bypassed VS, so you are the last person that should be giving me advice on this subject. I posted several of them here: Video - Quick Follina test ;).

 

[danb]

Well I had some problems getting the command to find Python, but finally got it resoled. After I ran the command I got this:

View attachment 267451

...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:

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

EDIT

Actually that remote IP address belongs to Microsoft Not what I expected but I guess that's normal for MS apps when they open they connect to mothership MS.

Yeah, the PoC's are not quite as reliable as we would like them to be for some reason. It took me a while to find PoC's that worked, which is why I will only share them with people who are civil to me .

 

[wat0114]

Yeah, the PoC's are not quite as reliable as we would like them to be for some reason.

Okay I guess that might be the case with my poc. Thanks again!

 

[Sunshine-boy]

It is true that VS is more context-aware compared to H_C, but only a little bit

Hello, what about WDAC? is it more contextual than SRP?

 

[danb]

Okay I guess that might be the case with my poc. Thanks again!

Sure, thank you as well. There will probably be much better and more reliable samples in the next few days, so I will keep an eye out for a really great one that spawns calc every time. To me it didn't matter if it spawned calc or not. The only thing that mattered to me was if Winword was able to spawn msdt.exe elevated or not. After a few days break from testing I will look for some better samples and send them to whoever wants them.

 

[danb]

Hello, what about WDAC? is it more contextual than SRP?

WDAC has slightly more context than SRP, but nothing too significant. The only way you are going to get the context you really need is with a kernel mode driver. And even then, it takes several years of development to make sense of all of the context, to be able to craft effective rules and algos that blocks what needs to be blocked, and allows what needs to be allowed.

 

[Andy Ful]

Absolutely not, there are no blocks in the H_C logs, except for my Uptime.exe test blocks.

Finally, I watched your video:



There is no sign in this video that something was exploited. As it can be seen in the beginning, you prepared the POC which should execute Calc as a final payload.

You opened the weaponized document (clickme.docx) and nothing happened - the calc payload was not executed. Anyway, you concluded from the video that something was exploited, and this is evidence that you did not understand this exploit at all. Another evidence is opening the HTML scripts in the web browser which has nothing to do with this exploit - these scripts should be downloaded by the weaponized document (in MS Word) to do any harm. When opened in the web browser they are not harmful.

I noticed that you enabled the H_C protection during the test, so it is understandable why the calc payload could not be executed (H_C and OSA could block the payload).
The same follows from the screenshots in your previous post:
https://malwaretips.com/threads/quick-follina-test.114277/post-992745

Please remove this video. It is only the evidence of your limited knowledge about this exploit and will not serve you well. You should not test the software of other people without the permission of the vendors - your tests make more harm than help. You should be also ashamed of what you did (I mean your posts).

Edit.
Here is how the successful exploit should look when using the POC:
https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e

"I’ve tested this on various rigs and it works more common than not. For example, here is Windows 10, not local admin, with macros fully disabled, with Defender, with Office 365 Semi-Annual Channel, casually popping calc on open of a Word document:"

 

[danb]

I am not going to waste any more time on this. I have already demonstrated that HC and SWH allow msdt.exe to run elevated. If you are comfy with this, then more power to you. You are focusing only on the initial Follina PoC, there are others.

Again, you have falsely claimed on multiple occasions on MT that you have bypassed VS, so you are the last person that should be giving me advice on this subject. Besides, look what happened, one of the products was improved literally overnight. That is not a bad thing. That is a good thing.

 

[danb]

I tested a little more, and it appears that HC (and probably SWH) blocks the powershell call in the document attack, even though it was not logged by HC. But my point is that msdt.exe (or any Windows process) should never be allowed to run from any vulnerable app, because at that point you are just taking chances. I would not be comfy at all if VS allowed any vulnerable app to spawn msdt.exe. If you block attacks at the earliest stage, the likelihood they will succeed are dramatically lower. On a side note, I found out that elevation is not required to pop calc.