From https://www.groovypost.com/howto/change-default-email-app-windows-10-mailto/ we see that it is possible to choose default apps by protocol, that link showed MAILTO being changed.
Goals
https://thedeveloperspace.com/browser-selector-a-simple-windows-app-to-associate-different-urls-to-different-browsers/ Looks like someone already wrote it...
1. Write a simple C# Windows App
2. Hand re-configure HTTP & HTTPS protocol to use your app
Instead as using default browser on your own laptop. You may want to do this within a test VM, using Settings > Apps > Default Apps to change the default browser to your app as per the 1st link.
3. Programmatically configure instead of hand configure
Take a look at the tool, it has a Github repo. Port the mechanism to powershell.
*GitHub link no longer works.
Write a powershell script to achieve the equivalent configuration outcome from goal #2. Eg. rename your app, then use the script to change to your new app name.
Background & Context
If the student has reached this far, s/he would have understood that deploying a backdoor, malware, ransomware & what not isn't that hard. Even if we deny Type-1 file-based Code-Execution, there are plenty of system tools (Type-2) to abuse or deliver exploits (Type-3) for sneaky Code-Execution. All that begs the question:
is it sustainable to chase after all kinds of Code-Execution techniques?
There are no shortages of dated advices like update your Anti-Virus & the likes, but please don't depend on such outdated approach anymore. You might as well take the budget to use containment (or isolation depending on perspectives) approach:
- https://www.hysolate.com (user-friendly, freemium model, yes you can install & try it out)
- https://en.wikipedia.org/wiki/Browser_isolation (the current trend but USB storage & app-control ... are not covered, only browser-vector, there's also Email attachment containment products that is equivalent)
- https://www.qubes-os.org (very technical, not suitable for casual users)
Hysolate is really a commercial version of Windows Sandbox, both uses hyper-visor. So what's the big deal here?
Instead of being concern with all kinds of Code-Execution techniques, we reduce the problem scope to advance techniques that let attackers escape containment!
What has all these to do with this track?
Consider this: https://github.com/jymcheong/OpenEDR/wiki/Ring-Fencing-Adversaries-with-Win10-Pro , unlike a polished & user-friendly Hysolate, it does not have that convenience like automatically browsing an external URL within the Sandbox.
Once this simple app is realised, suppose a potential victim upon receiving a URL (eg. that launches a malicious HTA script that in turn run let's say VBscript, Powershell or whatever...) within the host machine that has a Windows Sandbox already fired-up, the program will mimic Hysolate's convenience of "redirecting" the URL into the Sandbox's browser, instead of running within host. It is as simple as a single Windows firewall rule to ensure that only Sandbox can get to the Internet.
How many layers of security is enough?
That really depends on how high an attack-factor you want to create for your adversaries. Last section covered some details related to the following abstract diagram:
Everything you have done so far, are related to System (Host) Observability. This particular track is related to creating convenience for "contained" use-cases (eg. browsing the web or viewing some online document or email attachments).
Windows Sandbox (FYI only)
Think of this utility that you are about to explore, running in the host machine that is also running a Sandbox. Let' say some malicious actor sends a malicious URL to the user (eg. corporate email, USB stick.. whatever). User falls for deception, double-clicks the link... instead of launch the browser like the usual use-case, the utility writes to a folder shared into the Sandbox. From within the Sandbox, there's another small program that is monitoring this folder, if it is a URL, run browser within Sandbox to view.
So imagine you are the attacker, you got a C2 session within such a sandbox. If you had perfect knowledge (ie. knowing this is a sandbox, that there's deception decoys etc etc...), you may not wanna continue to engage. But let's say the dumber adversaries, they may continue, that's where the 2nd layer of Distribute Deception is for.
YJ's Documentation
To-Do
- Manually configure HTTP & HTTPS protocol to use Browser Selector app.
- Write a PowerShell script to achieve the same outcome as task 1.
Task 1
The first task is to manually configure HTTP & HTTPS protocol to use Browser Selector app.
What is Browser Selector?
Browser Selector is an app that acts like a bootstrap to associate URLs to different browsers installed on your machine.
How does Browser Selector work?
The image below summarizes how Browser Selector works:
More information can be found in this link https://thedeveloperspace.com/browser-selector-a-simple-windows-app-to-associate-different-urls-to-different-browsers/.
Configuring HTTP & HTTPS protocol
Firstly, download Browser Selector using this link https://thedeveloperspace.com/wp-content/uploads/2017/09/BrowserSelector_bin.zip.
Go to Settings > Apps > Default Apps, scroll down, and click the “Choose default apps by protocol” link.
Next, scroll down to find the "HTTP" & "HTTPS" protocols. Change the default app from Microsoft Edge to Browser Selector.
To test that it is working,
Open Start –> Run, enter a URL e.g. http://www.google.com and click OK.
Browser Selector will open the URL in the browser that you have set. In my case, I configured mine to use Google Chrome for all URLs, meaning that it will open google.com in Google Chrome.
Task 2
The second task is to write a PowerShell script to programmatically configure HTTP & HTTPS protocol to use the app instead of manual configuration.
With reference to https://social.technet.microsoft.com/Forums/en-US/43780476-8d03-4c02-b457-c94c8c317ab7/updating-default-apps-protocol-via-powershell?forum=winserverGP, I initially tried to change the default app from Browser Selector to MS Edge using the following commands:
Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice' -name ProgId MSEdgeHTM Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice' -name ProgId MSEdgeHTM
However, upon checking to see if the changes has been made in Settings, an error message popped up:
After some research, I found out that registry changes to default apps associations in Windows 10 are verified by a hash (unique per user and app) to prevent file association tampering, hence why my PowerShell commands failed.
Â
While researching, I came across https://github.com/DanysysTeam/PS-SFTA, which is a PowerShell script that allows you to set the default application for protocols in Windows 10.
For example, to set Microsoft Edge as default app for HTTP & HTTPS protocol, run the following command:
powershell -ExecutionPolicy Bypass -command "& { . .\SFTA.ps1; Set-PTA 'MSEdgeHTM' 'http' }"powershell -ExecutionPolicy Bypass -command "& { . .\SFTA.ps1; Set-PTA 'MSEdgeHTM' 'https' }"Note: You can run the command as a normal user i.e. administrative privileges is not required.
The script worked as the changes can be seen in the Settings:
If you want to set default app back to Browser Selector, change 'MSEdgeHTM' to 'BrowserSelector' in the command.
For Chrome, it will be 'ChromeHTML'.
Taking a look into the codes, it appears that the authors reverse-engineered the hash algorithm used by Windows in order to come up with the hash value. The hash value is needed to ensure that the registry change is valid:
The PowerShell script codes can be found here https://github.com/DanysysTeam/PS-SFTA/blob/master/SFTA.ps1https://github.com/DanysysTeam/PS-SFTA/blob/master/SFTA.ps1.