- Feb 4, 2016
- 2,520
BazarBackdoor now abuses Windows 10 app feature in 'call me back' attack
- Thread starter LASER_oneXM
- Start date
- Dec 23, 2014
- 8,513
So far, it is a rare attack vector. But, this can change in the future. If one does not need to install MS Store Apps via the web browser then there is a simple tweak to disassociate URL:ms-appinstaller protocol via the reg tweak:
I simply renamed the original "URL Protocol" to "!!!URL Protocol".
This tweak does not impact installing Apps via MS Store.
The full functionality can be reverted by deleting the !!! before URL Protocol. This will restore the default registry data:
The tweak can be tested by using a simple HTML file:
Normally it contains the link to the App installer (.appx, .msix, etc.). I used a fake and incomplete link "https://" to avoid unnecessary installation.
Edit
Please be very careful with Registry editing and always use the Export feature to save the original keys.
Code:
[HKEY_CLASSES_ROOT\ms-appinstaller]
@="URL:ms-appinstaller"
"!!!URL Protocol"=""I simply renamed the original "URL Protocol" to "!!!URL Protocol".
This tweak does not impact installing Apps via MS Store.
The full functionality can be reverted by deleting the !!! before URL Protocol. This will restore the default registry data:
Code:
[HKEY_CLASSES_ROOT\ms-appinstaller]
@="URL:ms-appinstaller"
"URL Protocol"=""The tweak can be tested by using a simple HTML file:
Normally it contains the link to the App installer (.appx, .msix, etc.). I used a fake and incomplete link "https://" to avoid unnecessary installation.
Edit
Please be very careful with Registry editing and always use the Export feature to save the original keys.
Last edited:
- Apr 5, 2021
- 620
From the link to the article, I see two opportunities for a reasonably educated end user on Internet and email security to avoid and prevent the execution of the malicious payload:
The hovering of the mouse pointer can reveal suspicious looking links. This could be one of, if not the first, of red flags to the targeted user.
This should be another, maybe more obvious, red flag.
The hovering of the mouse pointer can reveal suspicious looking links. This could be one of, if not the first, of red flags to the targeted user.
This should be another, maybe more obvious, red flag.
- Dec 23, 2014
- 8,513
The problem is similar to macros in MS Office. If the user is a happy clicker or the attacker can convince the user that everything is OK, then the attack will be successful. For now, macros are very popular because the attacker does not have to use digitally signed files.
If the user can see that the file is trusted then the social engineering trick may work. Here is an example of legal trusted application:
In the attack from the article, there was no "Trusted App" note.
If the user can see that the file is trusted then the social engineering trick may work. Here is an example of legal trusted application:
In the attack from the article, there was no "Trusted App" note.
Last edited:
- Apr 5, 2021
- 620
Interesting! Are trusted applications sometimes used in phishing campaigns?
There is a two part article with a detailed technical analysis on this backdoor here:
https://www.fortinet.com/blog/threat-research/new-bazar-trojan-variant-is-being-spread-in-recent-phishing-campaign-part-I
The malicious payload is a PE. I would think that the final line of defense, failing the victim's ability to spot suspicious message content, would be SRP rules in a utility like H_C for example
Last edited:
- Dec 23, 2014
- 8,513
Yes (EXE, MSI files in highly targeted attacks), but I did not see UWP app installers.
- Apr 5, 2021
- 620
Regardless, in my case at least, my suspicion would be aroused if I was required to "install" something - trusted or not - in order to view a message attachment or link. But you brought up a good point about happy clickers
- Dec 23, 2014
- 8,513
SRP (H_C) would block opening this malware (EXE file with PDF icon)....
There is a two part article with a detailed technical analysis on this backdoor here:
https://www.fortinet.com/blog/threat-research/new-bazar-trojan-variant-is-being-spread-in-recent-phishing-campaign-part-I
The malicious payload is a PE. I would think that the final line of defense, failing the victim's ability to spot suspicious message content, would be SRP rules in a utility like H_C for example
- Apr 24, 2016
- 7,264
And Simple Windows Hardening?
- Dec 23, 2014
- 8,513
In such attacks, SWH relies on SmartScreen Application Reputation and AV protection. This is sufficient in the home environment. The targeted attacks (against Enterprises) would require additional protection layers, for example, the Defender ASR rules, Edge Application Guard, etc.
Last edited:
- Apr 24, 2016
- 7,264
That's a no
H_C will not block opening this malware (EXE file with PDF icon) on basic recommended settings (+/- the same as SWH)?
- Dec 23, 2014
- 8,513
H_C on Recommended Settings can block it. SWH can mitigate several Bazar variants which use shortcuts in the Windows Start menu Startup folder. Anyway, the attacks we talk about are not used against home users.That's a no
H_C will not block opening this malware (EXE file with PDF icon) on basic recommended settings (+/- the same as SWH)?
Last edited:
- Aug 23, 2012
- 293
On OSArmor v1.6.2 we added a new option "Block installation of Windows Apps via AppInstaller" that can be used to mitigate this attack:
Tested on Windows 10 and Windows 11 and works fine.
It can also be used to block installation of Windows Apps via *.appinstaller files:
May be useful to some users that want to restrict this Windows feature.
Tested on Windows 10 and Windows 11 and works fine.
It can also be used to block installation of Windows Apps via *.appinstaller files:
May be useful to some users that want to restrict this Windows feature.
- Dec 23, 2014
- 8,513
On Windows 10 one can block the AppInstaller installations via the ExploitProtection feature by applying the "Disable Win32k system calls" mitigation to the executable Appinstaller.exe (choose " Add by program name").
The mitigation must be applied for the file name because the full path to the Appinstaller.exe changes after the update.
This method will also prevent another attack vector when the malicious file (App Package file: .appx, .appxbundle, .msix, .msixbundle) is an email attachment downloaded & opened by the user.
The installations/updates via Microsoft Store can run as usual.
Last edited:
- Dec 23, 2014
- 8,513
I found this note interesting:
Such attacks are a hybrid between strictly targeted attacks and widespread attacks. The initial part is widespread, but the second is targeted.
Such attacks are a hybrid between strictly targeted attacks and widespread attacks. The initial part is widespread, but the second is targeted.
- Dec 23, 2014
- 8,513
This can be done by blocking by SRP the directory:
c:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller*
The path with a wildcard is required because the path contains the version of AppInstaller and will be changed after the update.
When SRP blocks AppInstaller by path, then installing/updating applications via Microsoft Store is not blocked. The same is true if one blocks the Appinstaller.exe via Exploit Protection.
Yes, if one does not use SRP.
- Dec 23, 2014
- 8,513
Most desktop applications run by default with a Medium Integrity Level. The UWP apps can run with a Medium Integrity Lever or lower levels (like AppContainer).
In most cases, both desktop and UWP applications that run with Medium Integrity Level can be forced to "run as administrator" (High Integrity Level).
Last edited:
Similar threads
