So to end it all, we're going to end with a great talk with two first-timers, and we're
going to give them a big hand.
And their name is Steven and Nick, and the talk is called Let's Smart Screen More Caffeine,
which is the best thing ever, more coffee.
Click once, abuse for trusted co-execution.
So actually, cheers for these guys and cheers for everybody who are having a great con.
And let's kick it off with you guys.
So since this is our first time at the con, we have a tradition of doing some shots to basically cool them down.
So here we are.
Steve, Nick, Dushan.
Because everyone is nervous.
You know, it's only live streamed and all that fun stuff.
There you go.
Cheers.
Cheers.
Cheers.
Thank you, everybody.
Appreciate it.
Hey, so, yeah, we'll be talking about some click once techniques.
We'll start off with some intros.
My name is Nick Powers.
I'm currently a senior consultant at Spector Ops.
I just include Windows stuff, initial access, some relay attacks, and my handle on Twitter is Zenergy.
My name is Steven.
I'm also a senior consultant on the ads team at Spector Ops.
You can follow me at 0x13 if you want to see more.
So what we look to accomplish today, we want to take a relatively common initial access technique
and extend its value for offensive use by abusing the trust of third-party applications.
So a little overview of what we're going to cover today.
Give a little background of click once.
I'm not sure if everyone knows exactly click once or how it works.
But we'll cover that.
We'll talk about pressure points of building click once applications for weaponization of initial or offensive operations.
How we can alleviate those pressure points actually showing weaponization.
And then we'll close it off with some detection and response overviews.
So a little bit of background.
Initial access techniques are decreasing.
Recently Microsoft came out and said by default in Office macros they're going to start disabling them when it's downloaded from the Internet.
It's reversed.
Then it got reversed back.
So at this point, we're not quite sure where that is.
But there is a lot of scrutiny that's applied to Office macros, whether it be applied for phishing campaigns or seated access, what have you.
So this is just a way for more techniques to be leveraged.
For initial access campaigns.
Some of the things that we have to worry about for initial access campaigns, obviously we've got smart screen, application control, EDR, things like that that run on endpoints.
Definitely things that increased our barrier to entry for initial access.
Some things that we need to overcome.
So we need to make sure that we can install or execute code that does not require any sort of privileges or administrative privileges.
Reputable, known good files during execution.
Definitely helps us during this.
Process.
Streamlined, minimal user interaction.
The more things that people have to do during phishing campaigns or initial access operations definitely decrease our chances of being successful.
And then we want ease of rerolling our techniques over and over.
So click once, again, click once is a deployment technology that enables you to create self-updating Windows-based applications that can be installed and run with minimal user interaction.
So this is a vehicle.
This is a vehicle for installing or executing .NET applications on endpoints.
And so there's multiple different ways that click once can be deployed, can be installed on endpoints.
The main thing that we'll be focusing on today are web applications or websites that we can get these installed.
But the main thing that we'll need to focus on and will be important throughout this talk are manifests.
Now, anyone that's done any sort of manifest or .NET stuff or .NET work might be familiar with manifest.
And so we'll be focusing on that.
We'll be talking about that throughout this entire slide deck.
But plenty of legitimate applications use click once for their vehicles of deploying their code.
So Chrome historically used to use click once.
Fidelity, the bank, uses click once.
And tons of other ones you probably have never heard of.
But they also use click once.
So, again, as I said, manifests are very important.
And so we'll talk about the different types of manifests that come into play with click once and what their roles are with them.
So the first one that we need to think about.
Is a deployment manifest.
And so this is going to be named a .application file.
So when you go to a website, the first thing that you interact with the click once application is going to be a .application file.
Which, again, is the deployment manifest.
Now, this is going to reference the actual application manifest.
And inside of this, we have some identity information.
And things along those lines.
In addition to interacting with deployment manifest, we also have app ref MS files.
Which we won't talk about today.
There's not too much in this talk.
But they are usable for click once applications.
The second manifest that I just mentioned, application manifest, is the second manifest that we have to deal with when dealing with click once applications.
And this is a .manifest file.
And so this will specify dependencies.
Again, as I said, identities inside the files.
And everything that needs to be downloaded and deployed alongside that click once application.
The identity information is going to come into play as a very important role.
At the end of this presentation.
But something to keep in mind in the back of your head right now.
Everything that we put inside of the actual application manifest will have integrity checks.
But we can have some work arounds with those that we'll cover later on as well.
Then inside of the actual .net applications themselves, we also have embedded application manifest.
And embedded assembly manifest.
And so these are different.
But they look somewhat similar to how a click once application works.
But this is just something that's just a component of .net itself.
But again, these have various factors that are important.
So this is what a click once application looks like.
We have our deployment manifest.
Our application manifest.
And then our actual .net .exe .deploy.
They can be named .deploy for the extension.
But they don't have to be.
But typically in like legitimate click once applications, we'll see they are named .deploy.
Oops.
Sorry.
Okay.
So click once applications are deployed, as I said, visiting the deployment manifest.
So if you visit click once or deployment manifest in something like edge or Internet Explorer,
you'll see a little popup show up that says, oh, do you want to run this and get the execution that happens along with that.
Which we'll show in the demo later on.
Alternatively, as I said, there is an app ref MS file which can be used when you're dealing with Firefox or Chrome browsers.
This serves content based on whatever the application manifest specifies.
And it will be downloaded via HTTP or HTTPS to the host system.
And will be saved in the app data local directory in a randomized directory.
But all in the same naming convention of apps 2.0 and stuff like that.
The process that will launch everything, handle the download, the execution and the launching of everything is called DFSVC.
Which is a part of the .net framework.
And so the main thing that DFSVC is doing is going to be loading the system.deployment DLL.
Again, part of the .net framework that will be handling pretty much every component of click once.
So we have here our HTML.
This is just an example of what the download looks like.
We have our deployment manifest.
And it's going to hit all of our dependencies in the main click once application and download everything and get it on to the host.
This is just a simple example of what our app rough MS file looks like.
This just shows the location of where the click once application is.
Calls the click once protocol handler.
And then specifies some additional .net information that's necessary.
This is what an example of a deployment manifest looks like.
We're referencing the application manifest, as I said, part of here.
And this will determine where to download all the rest of the dependencies and the actual click once application itself.
And then also we have the assembly identity as well, which is important later on.
Example of what the application manifest of click once looks like.
We just have UAC information, identity information.
We have some dependency information.
Everything that needs to be downloaded as well.
And everything that comes along with the entire package.
This is an example of what the embedded application manifest looks like.
And so we have, again, more identity information.
This is actually just .net applications themselves.
So this is what they will be built with.
And this is contained in almost all applications.
Example of what an assembly manifest looks like.
This will reference mainly the dependencies that go along with a click once application.
This is what it looks like in DNSpy.
A little bit cleaner than the last screenshot from ILDASM.
But that's just showing the difference of what is shown there.
So the reason that we'll be covering through this talk of why these are important.
Is that they are going to be parsed by the system deployment DLL functionality.
And they're going to make some comparison checks for the actual execution.
But this is just kind of showing an example of where that is like essentially being applied and parsed and handled.
So we're going to show a demo that's going to show what if you were to build a click once application right now.
And it's not signed.
You don't have the code signing served.
And what this would look like from execution standard.
So we'll go to our site.
Index.html for the site.
We have our download.
Which is going to be where our deployment manifest is located.
Click download.
A little pop up that says do you want to run this?
Say yes.
We have our little run dialogue.
Click run.
Downloads.
And we have our smart screen pop up show up.
So from a phishing campaign or initial access operation.
This is not what we want to see.
We have hurdles to come through here now that we have this application that is not trusted.
No reputation.
Nothing behind it.
Go and look at it.
Look at the application.
Open it up.
We'll see.
Look at the signature.
This is just self signed.
Nothing special here.
But there was something that we had to some hoops that we had to jump through.
Awesome.
So Steven just gave us a really good overview of what click once looks like in its current state.
When we want to weaponize that for something.
Some sort of initial access phishing or otherwise.
So to start working towards some of the problems that we want to address.
We got a screen shot here.
This is from the bloodhound gang slack.
Specifically the red team channel.
And there's a long message here at the top.
The summary is someone is asking about using click once for initial access.
And if you look at the response second from the bottom.
It reads.
If you have a cert.
Then I would 100% recommend looking into click once.
One of the best initial access techniques.
But you really need a cert for this to be effective.
And it's in its current state.
How people currently use this for initial access for example.
We definitely agreed with that sentiment.
So what are some of these pressure points with the way click once deployment currently works.
Well the first one is smart screen.
You saw in the demo that Steven just did for us.
That there was a big somewhat obnoxious blue box that popped up.
You have to click more info.
To even be given the option to run anyways.
And then we get our code execution.
To give a little background on what smart screen actually consists of.
It's a reputation based protection.
It first appeared in Windows 8.1 and above.
That reputation is based on either the file hash.
So like the file that you're sending for your initial access attempt.
There'll be a hash like the checksum associated with that.
It could be associated with the signature that signed the assembly.
It could also be associated with the URL.
That your potential victim.
Grabbed the assembly from.
One thing that I like to note.
And I'll say this a couple more times during the presentation.
Just to kind of compare and contrast what we're presenting with alternatives.
Is an EV code signing certificate for example.
Would also get rid of the smart screen prompt.
But there's a lot of pros and cons associated with this as well.
But there are two separate types of code signing certs.
I'll talk about it here in the next slide.
There's authentic code.
But EV code signing is the only one that will give that immediate smart screen reputation.
Without code signing certificates.
Like Steven just showed us.
Ultimately what we'll end up executing.
Is an unsigned assembly for this click once deployment.
What does that mean?
We'll trigger smart screen like we just saw.
It means things like mark of the web will be associated with the assembly that we've downloaded.
That's what ends up triggering smart screen.
This could also be a reason for EDR products or AV to pay closer attention to the assembly being downloaded.
As well as you could fall victim to.
Solutions like app control or white listing prevention.
Because the assembly that would be downloaded is unsigned.
It might not execute for those reasons.
So continuing on with some of these pressure points.
Generally click once is less used we think than for example office documents.
Our assumption for that is that the internals have been less explored up to this point generally.
People might assume that it's harder to.
To put together one of these deployments.
To deliver like an initial access payload during a phishing campaign.
The manifest information has to be accurate for deployment to work.
Which can be another kind of pain.
Steven mentioned a lot of manifests.
We'll dig in a little bit more here in a second.
But he already mentioned and I'll kind of reiterate now.
That all of these manifest values need to match up for this deployment to be successful.
And we'll step through that in a little bit.
The code signature is needed.
Potentially needed for higher success rates during things like phishing campaigns.
Again the EV signature can guarantee that.
But EV code signing certs are really, really tough to get.
Alternatively you could sign with an authentic code certificate.
And that certificate won't give you the immediate reputation.
But it could itself build up reputation over time.
And then once that authentic code certificate has built up reputation.
Everything you sign with it will have reputation with SmartScreen.
Also if you're going to code sign to get around things like SmartScreen.
There's considerations such as attribution for your payloads.
So like the assessments that we're doing.
If we start signing our payloads.
We could sign a payload for an assessment we did two years ago for a customer.
And then somebody in the threat intel community could tweet that.
And then VirusTotal would just show you all of the payloads that we've been developing over the last two years.
So that's a concern for us on the offensive side.
As well as it's just complicated to obtain.
It can be complicated to obtain something like an EV cert.
There's a strict vetting process.
They cost a lot of money.
So there's a lot of pros and cons to consider.
So the question that we pose at this point is.
So like what can we do to alleviate these pressure points.
And not have to obtain one of these code signing certs.
So we're kind of going to approach this with two somewhat unique techniques.
But the first one is going to be.
There's all these click once deployments out there that are already signed.
So why wouldn't we just find a way to sideline.
And sideload one of those existing and trusted click once deployments.
So the way that we'll approach this in the upcoming slides.
Is that we'll search around through dorks and other methods for other people's signed trusted.
And already published on the internet click once deployments.
So we can use those as a method of sideloading.
And ultimately end up with trusted code execution.
So we're going to.
One thing that we want to note.
Before we start talking about.
Backdooring existing click once deployments.
Is that when we backdoor these existing deployments.
We're not backdooring like the assembly that's going to ultimately run our malicious code.
We're going to backdoor a dependency.
So like a DLL.
Or there's a bunch of other techniques that we can use.
But the point that we want to stress is that.
The deployment that we're backdooring.
We're going to backdoor a dependency.
Therefore we will not break the signature of that host assembly.
So we'll still have the reputation in regards to smart screen.
The potential benefit when it comes to EDR.
Etc.
There's a lot of useful tools that we can use to do this.
Dnspy.
Reshacker.
Mage.
Sigchecker.
We'll talk about several of these throughout the presentation.
So the first step that we want to go through is identify an existing and signed click once deployment.
So this is an example of what downloading a fully signed and usable click once deployment looks like.
On the right here.
We have.
We're actually going through Google.
Looking through a dork to identify published click once applications.
So once we've gone through that process of doing our Googling.
Looking around.
We've identified signed click once applications.
So what do we do now?
Well now we're going to hijack the execution flow of that click once application.
So we're going to download that signed application.
Decompile it.
Since it is .net.
It's very easy to do when you use something like Dnspy.
Understand the execution flow.
Of where all the components are.
And how it works.
Find a dependency that is not strongly named.
And then go into that dependency or that DLL.
Back door it.
So we'll put our code.
Whatever malicious code that we want to write.
Put it inside of that .net.
We can also do traditional DLL search order hijacking here as well.
But once we've put our code into that DLL.
We'll go ahead and build a manifest that reflect the changes that we've made.
And then recompile everything.
And host it.
And have it ready to be deployed.
I'll talk a little bit more about that in a second.
Alternatively.
If we don't want to back door a dependency.
We can do apt domain injection.
Which will allow us to load a DLL based on config file for .net.
We also can get creative with that, too.
If we want to do any sort of node jade weaponization or .net desedialization.
We can so that we're not just running straight up shell code and calling commonly abused
apis.
So going through the process.
We identify.
Our application.
We download it.
We look at it.
It has a valid signature.
So this is a prime example or a prime opportunity for us to weaponize this.
We look through the actual references, dependencies that this would use.
Look for anything that has the public key token of null.
Which means it's not strongly named.
Go through the code.
So we want to find somewhere that we can get our code typically executed early on.
And then we'll go pretty much what's going to happen at the entry point.
Look through.
Kind of where everything happens.
We find something here.
The DPI settings has a method called set DPI awareness.
So we'll go into that.
Look into there.
Not strongly named.
So this is a prime location for us to put our code inside of it.
And get our execution in a signed process.
So we have our notepad.exe we're calling and then a pop up box that we're going to
execute.
Thanks.
Okay.
So.
So.
So we covered, Steven gave us a quick overview of what click once currently looks like to
weaponize and we've started getting into backdooring existing click once deployments.
But Steven's made several references to manifests.
And manipulating these manifests will be relevant to us being able to weaponize what we're talking
about in terms of like backdooring other people's click once deployments.
So Steven just walked us through putting some of our potentially malicious code inside of,
you know, adding that to a DLL, a dependency of the deployment.
And then executing to get that code execution.
The last thing we'll have to do to make this deployment work is, like you said, change
some of these values in the manifest so the deployment will execute successfully.
So the first thing to note here is that there are several fields within the click once manifest
that are optional.
The things that will very likely prevent successful execution of a click once deployment would
be, for example, the public key token values.
The hash block.
These are all things that when you're executing the click once deployment, they're like integrity
checks.
And you can probably imagine because we've modified at least one of the dependencies,
we've changed the ultimate checksum or the hash associated with that DLL.
It's changed so we need to either change or remove these values from the manifest.
And thankfully, a lot of these values that are checking that integrity of the deployment
are optional.
So we can just remove them or we can replace them with all zeros and null them out and
it won't be checked.
And also, additionally, if we wanted to do things like app domain manager injection,
we could use the file XML block to add more dependencies to this click once deployment.
One thing that we wanted to note because we're talking a lot about integrity checking
and signatures here is that you can imagine if we're modifying someone else's existing
click once deployment to get the benefit of their signed executable, then when we modify
the manifest, the manifests are also signed.
So when we have to change these values, we will break the signature of the manifest.
That's something that we wanted to note.
But ultimately, we think this is okay in our opinion because we'll show on the next slide
here in a second what the difference in the popup boxes are.
And it's in our opinion significantly less intrusive than like the smart screen, big
obnoxious, click the more info, click run anyways thing.
So this is the difference if we break the signatures.
This is associated with a manifest.
Just to kind of reiterate, a lot of very popular click once deployments out there don't even
have signed manifests.
So it's going to be the box on the left anyways, the little red X in the right.
Even if it is signed with a trusted code signing certificate, the only difference is that
kind of like yellow explanation point and not a huge difference when we break the manifest
associated with a click once deployment here.
So some of the code signing implications associated with click once deployment abuse.
The question we're posing here is do we really need a code signing cert to effectively weaponize
click once?
Like we just showed, the difference in the prompt here is relatively minimal, especially
when we compare that to how kind of intrusive the smart screen prompt could be.
Again, we have the option of going out and paying a lot of money and going through a
relatively strict vetting process.
Okay.
We wanted to pursue an EV code signing cert, for example, or maybe even authentic code.
But there's pros and cons associated with that as well.
The vetting process is strict, like we said.
But there's no need when sideloading a signed reputable assembly with the code signing certificates.
So yeah, kind of like we said, we see a lot more benefit in just abusing some sort of
sideloading technique than going through that long ‑‑ somewhat intrusive vetting process.
For an EV code signing cert and paying a lot of money.
So we'll have another quick demo here to ‑‑ the first demo was Steven showing what click
once looked like initially.
And this will show what the process looks like when we execute a click once deployment,
but we've sideloaded somebody else's signed code.
We go back to our ‑‑ the same website here.
You'll see, again, a very similar deployment manifest.
The same prompt here.
We're just going to say open.
And then that prompt, but you'll notice when all of our dependencies download here, now
there's no smart screen prompt.
We just get our code execution.
And just to kind of prove why that's the case, we'll go over to the assembly that we ‑‑ or
the deployment that we decided to sideload, and we'll show that it is, in fact, signed.
It is signed by legitimate code signing certificate.
Okay.
So just to kind of recap, we've covered what click once deployments look like in their
current state, and we kind of posed the question of why not just sideload other people's existing
and potentially trusted click once deployments, but the other technique that we kind of wanted
to go over was if we could take that a step further.
And the reason we wanted to do this in the first place is if you go out looking on, like,
using Google dorks or other resources, there's a finite number of existing click once deployments
published on the Internet.
It's not necessarily the most popular vehicle for installing .NET, so there's only a specific
number of those available, and so we wanted to take it a step further and be able to take
arbitrary .NET assemblies that are signed and trusted and be able to create our own
click once deployments.
Okay.
So we wanted to go around those trusted ‑‑ around those signed .NET assemblies, mostly
because that would vastly increase the amount of assemblies that we could sideload and use
for initial access or whatever we wanted.
So we'll take the regular .NET assembly, but we can't just take any .NET assembly to abuse
for this use case.
There's a couple prerequisites that we found that you have to meet ‑‑ that the assembly
itself has to meet.
One of which is that the default embedded application management.
Manifest identity needs to not exist.
We'll show exactly what that looks like in a second, but Steven mentioned earlier there's
the concept of embedded manifests, the manifest that is embedded within the assembly itself.
There's a line in all the XML that you saw earlier.
One of them says assembly identity.
That line needs to not exist for this to work.
The requested privileges line needs to be set to as invoker or it needs to not exist.
So basically the requested privileges line in that embedded manifest.
It's going to say do you need to run as admin, can you run as a regular user.
If it's set to require administrator or there's one more that's higher than that that we'll
show in a second, it won't work with this technique.
If it's set to as invoker or it doesn't exist, it will work for this technique.
So other than those prerequisite checks, everything else is going to be the same to what we just
went through.
We're just going to sideload assigned .NET assembly and end up with more trusted codex.
Execution.
So this is something that we wanted to note just like with a lot of other things, there
are potentially some inaccuracies associated with like MSDN documentation.
This is one that we found while we were reversing one of the DLLs associated with click once
that Steven will talk about in a second.
But this particularly says basically if a .NET assembly has an embedded manifest, you need
to recompile it.
To not include an embedded manifest for it to work with click once.
We actually found that that wasn't the case.
It can include UAC information as long as it's set to as invoker.
It just can't require admin.
So this is when we were digging through the system deployment DLL, which is where again
most of the click once deployment functionality exists.
You can see here this is just us dropping that DLL in Dnspy and you'll see maybe like
five or six lines down.
It might be hard to see.
But you can see, I'm sorry, actually the if statement here, you'll see the keyword
require administrator.
The DLL is just doing some checks against that manifest that we just talked about.
And if it requires administrator, it says for this deployment to fail.
So a couple inaccuracies in the MSDN documentation that we found.
So this is a comparison of a default .NET assembly you'll see at the top.
And a second ago I mentioned the assembly identity line.
That's also very important for what we're talking about here.
That needs to not exist.
So just as reference, that top box that is an embedded manifest that will not work for
what we're talking about.
The bottom one you'll notice is a nonstandard embedded manifest that we found.
And this is actually assigned Microsoft assembly.
Signed by Microsoft trusted assembly.
And it does not include that assembly identity line.
So it will work with this technique.
So we spent a lot of time going through the system deployment DLL to figure out, like,
why deployments would fail or why they would work.
And Steven actually did a lot of the heavy lifting on that.
So I'll let him talk about some of this reversing.
Yeah.
So in this top screenshot here, we have the assembly identity that is part of the application
deployment or like the click once application manifest.
Yeah.
And what we see in there is going to be the process architecture, which is something that
is required for us to have inside of the assembly identity for the deployment.
In the bottom screenshot, we have the comparison.
If that assembly identity is in the embedded application manifest, then typically by default
it was not built with or is not compiled with that information.
So it does a check between these two values, and the ultimate reason is that there is no
process architecture.
But it has to be specified inside of the embedded application manifest.
So while we can try to get it to match, it will never match.
So it essentially prevents us from being able to load just any .NET assembly that we want
in a click once application.
It's only limited to any that meet this particular reason.
But at the bottom, you'll see the bottom line is going to be the click once application
manifest, and top line is going to be the embedded application manifest.
Okay.
And here's just some documentation to back it up.
It shows that in the manifest that we're talking about, the processor architecture
field of that particular block will be required.
And that's why this particular prereq exists for the technique that we're discussing.
So just to kind of recap about the difference between the techniques that we're talking
about, first we talked about sideloading somebody else's click once deployment.
Find it online, download it, sideload a dependency.
Now we've just gone over the fact that.
Okay.
There is a way to actually use an arbitrary .NET assembly that's signed and wrap a click
once deployment around it and use that for what we're talking about.
But if we decide to do that, we'll need to create our manifests from scratch because
we don't have somebody else's to just go off and tweak and then redeploy.
So this is actually super easy because in the Windows 10 SDK, there's an assembly called
mage.exe.
And what mage.exe is, it's defined as the manifest.
Generation and editing tool, command line tool that supports the creation and editing
of application and deployment manifests.
So I included some one-liners here.
Like Steven mentioned a couple times, we'll need our application and our deployment manifests.
And that's essentially it.
We run two one-liners with mage.exe.
We've created our two manifests that we need for this click once deployment.
And then we should have what we need to create a weaponized click once deployment.
And again, we noted earlier.
But it's probably worth noting again.
When you create these manifests with mage.exe, it will automatically calculate some of those
like integrity check like hash values.
Several of those are optional.
The public key token value can be nulled out with 16 zeros.
The hash blocks associated with all of the files and their dependencies can just be removed.
They're optional.
So if you don't remove those or recalculate them, it can cause a deployment to fail.
So that's why we like to reiterate.
And so now we'll do a demo of us instead of sideloading somebody else's existing deployment,
we took an arbitrary Microsoft signed .NET assembly.
We wrapped it with some manifests that we created.
And because it meets ‑‑ because it is ‑‑ it checks off these boxes, it meets these prerequisites
that we found, we can weaponize it using click once.
So you see we start off here.
Same way we started in the other demos.
We go to our website.
We reference our deployment manifest.
We start the download process.
We click run.
Again, you'll notice here we were not prompted with smart screen.
That's because we're using signed .NET assembly in this context.
You can see the notepad prompt in the code that Steven referenced earlier.
So this shows that our code successfully executed.
But the interesting part here is that before you saw we were just running in the context
of some ‑‑ some code.
Some person signed assembly.
This time you'll notice that this is signed by Microsoft.
An assembly that we found of theirs.
It's a part of the Azure SDK to be a little more specific.
But now we were able to, like we just said, create our own click once manifests using
mage.exe, wrap it around this assembly that we found that meets these prereqs and ultimately
sideload it and execute our malicious code in the context of this Microsoft signed assembly.
And then lastly, just like before, we'll go to the folder to show what was actually
downloaded.
Click properties.
We'll check the signatures.
And it shows that it's signed with a ‑‑ with a valid Microsoft code signing certificate.
Okay.
So we've gone over two techniques that we can use to ultimately achieve more trusted
code execution using click once.
But we wanted to help expedite this process.
So we will be releasing two tools.
One is assembly hunter that Steven will talk about in a second.
The other is click once hunter.
So click once hunter, essentially what it does is it's just going to help expedite
some of the dorking process that I mentioned earlier.
So you can use your favorite search engine.
You can use GitHub.
We'll reference a few in a second.
But click once hunter specifically will use like Chrome headless, Chrome dev tools and
also incorporate some API gateway functionality to rotate your source IP address, get around
some of that rate limiting and speed up the dorking process so you can find some of these
existing click once deployments to sideload yourself.
Steven will also be releasing click hunter very soon.
That's going to do a lot of ‑‑ I'm sorry.
Assembly hunter very soon.
Okay.
So it will do a lot of really cool things.
It will triage the local file system and do a lot of these pre‑rec checks for you so
you can search a local file system and find if any assemblies that are there locally would
work for some of the techniques that we talked about.
So this is just a quick example of using Shodan.
You can use this particular keyword.
There's a huge list of other dorks that you could use as well, but this shows some existing, potentially, sites.
Signed and trusted click once deployments that exist.
Here's another example of using some Bing‑specific dorks that you can see like 11,000 results
so there's a lot out there for people to find and potentially weaponize.
Here's using GitHub with some specific keywords again and this time we were searching the values
in the embedded manifest to see if it would meet some of these prerequisites that we've
talked about.
And here's another project on GitHub.
That shows a manifest that will be embedded that will very likely meet our prerequisites
to sideload this as a weaponized click once deployment.
And this is what the output of the tool will look like.
It's just going to give a list to the deployments online that you can go, download the deployment
and start to sideload with whatever you want to sideload with.
So this is an example of what assembly hunter looks like.
You can see we can triage entire paths.
Single files, collections, services, tasks.
Clearly I think anyone ‑‑ you look at this and it can do a lot more than just look
at click once abusable techniques.
I'll let you figure that out if you so please.
Or if you want to ask me about it, I'll tell you.
But we can get a lot of information based on everything that we triage across the entire
host OS if you so please.
So this is an example of that one that Nick just showed from GitHub, share X, pretty big
project.
It does not have the assembly identity line inside of it so this is an abusable project.
It can be deployed.
So this was just showing that we can find it also with assembly hunter if it's installed
on an end point.
Another one that we found, the one that we demoed, our third demo, DF monitor.
This is essentially how we discovered it.
We ran this across a host.
We came across this one that has no application manifest in it.
So that means that it is abusable for us to take advantage of.
Here we have chocolatey.
It's a free one if you want to go and use it if you so please.
Typically people download projects or packages, repos for Windows.
Some more assembly hunter usage.
So this is just looking through the .NET framework directory and so this highlights things that
are important for us to take note of when looking into .NET assemblies.
So the UAC setting, make sure it's as invoker or nonexistent.
The assembly manifest doesn't really make a difference because we can tell all this information
there.
And then the no application manifest identity needs to be either null or have no identity.
So these are all just, again, abusable things from .NET framework that we can also deploy
as well.
At the bottom we have CAS pool which is also part of .NET and not abusable because you
can see the application identity is existent there.
So we cannot use that as a deployment for ClickOnce.
So we'll talk about some detection opportunities.
So ClickOnce applications, luckily, are not super common.
And this is going to be dependent on an environment.
We've seen enterprise environments where they have 20,000 executions of ClickOnce a day
based on DFSVC.
And we've also seen other environments that have zero executions a day.
So it's important to baseline here of ClickOnce deployments inside of an environment to determine
if it's actually something that's pretty commonly executed or not.
As we said before, DFSVC is going to be the process that spawns the entire ‑‑ or
the handling of the entire deployment.
So from everything from downloading, checking management, all that kind of stuff.
And whatever we are running, our application will be a trial process of DFSVC.
So any sort of non‑common or non‑expected trial process of that is something that can
be keyed on.
We can potentially whitelist certain applications if we use them in the environment.
That's an opportunity for us.
If we see DFSVC having a trial process with an unsigned module load, that is a pretty
high indicator.
Now, we know and understand that this is not going to be inside of everything.
This type of telemetry is going to be leveraged or can be looked into.
But for this technique, at least, is pretty good way to catch this.
In addition to that, DFSHIM.dll can also be used to launch deployments or downloads
of a ClickOnce deployment.
Something we want to look into too, ETW monitoring, become increasingly used by endpoint products
and EDRs and such.
So if we look at any sort of ETW information, we can potentially find malicious stuff.
code execution.
Something to keep in mind, part of .NET configs we can put an ETW enable flag in there and
just call it ‑‑ make it false, meaning that ETW will not be used in that particular
.NET applications process.
So there is that and there's also public bypasses that exist for ETW as well.
So something to keep in mind that just because we're looking for ETW doesn't mean that there's
not blind spots in that.
As I said before, there's going to be ‑‑ or every click once deployment is downloaded
to the local app data directory.
So if we baseline that directory, look for anything that is an outlier or not uncommon,
something that we could find that was potentially executed that we don't want.
And then uncommon application signatures, making Internet connections.
So if we ‑‑ our first technique that we showed of backdooring existing .NET applications
or click once deployments, a lot of them are not companies that you've probably ever heard
of.
And so executing this in an environment, you probably have an uncommon signature of an
application that is now, you know, establishing C2 or doing something nefarious.
Some prevention opportunities.
So we can deploy registry settings across enterprise via GPO.
We have this one that's at the ‑‑ for prompting trust levels with click once.
A few options that we can set it to and zones.
So we have my computer, local Internet, trusted sites, Internet, and untrusted sites.
And so we can decide to ‑‑ if we want to enable them, make sure that authentic code
is required or completely just outright disable it.
If we do have any sort of application control deployed throughout the enterprise, then we
also could look for unsigned applications attempting to be loaded, too.
So this is just an example of what it would look like if we disabled ‑‑ or had the
registry key that says disable Internet.
So anything that comes from the Internet, the users won't even have an opportunity to
run it.
It's just close and that's it.
All right.
So yeah, in closing, there's a lot of folks that helped us work towards kind of working
through some of the technical details of finding these techniques.
So the first one that we wanted to give a shout out was our coworker, Lee Christensen.
He's done a lot of incredible work.
He's done a lot of incredible, like, offensive.net work in general and what we did would not
have been possible without his prior work.
Another shout out we wanted to give was Casey Smith.
He's done also probably too much incredible work to name.
One specifically that's relevant to a couple of the techniques we named, App Domain Manager
Injection.
He gave a phenomenal DerbyCon talk that helped us a lot working towards these techniques.
Another one would be William Burke gave a presentation on specifically the API.
He gave that presentation at Black Hat maybe two or three years ago and it really helped
us.
And lastly, kind of in closing, there's still a gigantic attack surface associated with
.NET in general but even more specifically ClickOnce.
There's plenty of areas to continue looking into and a lot of potential for more capability
development.
So thank you guys so much for coming.
Thank you.
.
.
.