Recently during an ATD team Hackathon, we split our team into groups and attacked different problems. The challenge that @webyeti and I took on, was write a quick POC to prove the ability to pass URL parameters to a ClickOnce Application.
This has the advantage of customizing the implant at the time the user clicks to install the application. For background on ClickOnce as a phishing payload, see the following:
Justin Warner - http://www.sixdub.net/?p=555
One of the challenges with ClickOnce is having to use Visual Studio to compile each payload for the target. By leveraging URL Parameters, you can build a base download cradle that contains custom logic based on the actual request that was made. This means you can easily customize payloads without having to recompile them.
The ability to pass input to the ClickOnce Deployment is well-documented here:
So let’s look at an example. In this example, we will download and execute an encrypted version of Mimikatz. This is just a basic example to highlight the capabilities of this tactic. Passing a key in the URL parameter is a bad idea, since a well-trained defender could extract the key from a proxy log or the registry. But I think this technique provides enough opportunity for unique key material per payload.
First, you will need to create the Visual Studio Application and configure the app to be Published as a ClickOnce Application.
Second, when you host the application on a web server, you will need to setup the correct MIME types to trigger the ClickOnce App.
Setting up the right MIME types is well-documented here:
.application –> application/x-ms-application
.manifest –> application/x-ms-manifest
.deploy –> application/octet-stream
The code to parse and process the URL Parameters is really simple.
Then your app can call:
string queryString = ApplicationDeployment.CurrentDeployment.ActivationUri.Query;
This will retrieve the Query string.
There are numerous examples of being able to customize your delivery based on inputs from the URL parameters. I leave it to you to experiment with other ways to leverage this tactic.
Here is a brief Demo:
From a Defensive perspective. There will be a number of artifacts stored in the registry.
Each ClickOnce application leaves a tattoo in the registry of the settings including the initial URL requested. HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
With a per app dynamic key generated.
Defenders should also consider blocking .application extension and the other MIME types mentioned above. Seriously...how often will apps be deployed from the outside of your network from arbitrary urls?
That’s all for today. Hope this was helpful.