 So to end it all, we're going to end with a great talk with two first timers and we guys give them a big hand. And the 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 Ones 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 these guys. I made a mistake. So since it's our first time at the con, we were a tradition of doing some shots to basically cool them down. So here we are. Steve? Because everyone's nervous. You know, it's only live streamed and all that fun stuff. There you go. 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's Nick Powers. I'm currently a senior consultant at SpectreOps. My interests include Windows stuff, initial access, some relay attacks, and my handle on Twitter is energy. My name is Steven. I'm also a senior consultant on the ads team at SpectreOps. 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 to 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 offensive operations, how we can alleviate those pressure points, actually showing weaponization, and then we'll close it off with some detection and response reviews. 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 efficient 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 end points, definitely things that increased our barrier 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 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 decreased our chances of being successful. And then we want ease of re-rolling 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 for installing or executing .NET applications on end points. And so there's multiple different ways that click once can be deployed, can be installed on end points. 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 manifests, and so 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. 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 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, which we'll cover later on toward the end of this presentation, but something just 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 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 a deployment manifest in something like Edge or Internet Explorer, you'll see a little pop-up show-ups as, oh, do you want to run this and get the execution that happens along with that, which we'll show in a 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 as well. 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 and 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 DF-SVC, which is a part of the .NET framework. So the main thing that DF-SVC is doing is going to be loading the system.deploymentDLL, 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 onto the host. This is just a simple example of what our app ref 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 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 IELDASM, 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.deploymentDLL functionality and they're going to make some comparison checks for the actual execution. But this is kind of showing example of where that is 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 you've not signed, you don't have a code signing cert 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. It's a little pop-up. Say yes. We have our little run dialog, 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's 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, 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 screenshot 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 cut 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 check sum 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. So without code signing certificates, like Steven just showed us, ultimately, what we'll end up executing is an unsigned assembly for this ClickOnce 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 whitelisting 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, ClickOnce 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 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 a 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 for time, and then once that authentic code certificate is 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 for 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 unique techniques, but the first one is going to be there's all of these click once deployments out there that are already signed, so why wouldn't we just find a way to side load 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 side loading 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 back dooring existing click once deployments is that when we back door these existing deployments we're not back dooring like the assembly that's going to ultimately run our malicious code, we're going to back door a dependency, so like a DLL or there's a bunch of other things that we want to stress is that the deployment that we're back dooring, we're going to back door 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, et cetera. 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 do is we're going to look at the uninsigned click once deployment. So this is an example of what downloading a fully signed and usable click once deployment it looks like. On the right here we're actually going through Google looking through a door 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 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 backdoor 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 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. Alternatively, if we don't want to backdoor a dependency, we can do app domain injection which will allow us to load a DLL based on a config file for .NET and we also can get creative with that too if you want to do any sort of node jade weaponization or .NET desilization we can so that we're not just going to do that, we can do that with the DLL that is commonly abused with 32 APIs. So going through the process, we identify our click-mix application, we download it, and we look at it as 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 it, and then we'll go pretty much 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 to do that and we're going to execute. So we cover, Steven gave us a quick overview of what click once currently looks like to weaponize and we started getting into back door 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 back dooring other people's click once, potentially malicious code inside 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 manifests that are optional, 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 check sum 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 things 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 the manifest and it's executable then when we modify the manifest the manifest 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 pop-up boxes are and it's in our opinion significantly less intrusive than like the manifest so this is the difference if we break the signature associated with a manifest just to kind of reiterate a lot of very popular click once deployments out there don't even have signed manifest 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 in the amount of 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 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 side loading 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 side loading technique than going through that with a lot of money so we'll have another quick demo here to the first demo with 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 side loaded 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 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 side load and we'll show that it is in fact 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 wanted to take 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 secondary .net assemblies that are signed entrusted and be able to create our own click once deployments around those signed .net assemblies because mostly because that would vastly increase the amount of assemblies that we could side load 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 the requisites that we found that you have to meet that the assembly itself has to meet. One of which is that the default embedded application manifest identity needs to not exist. We'll show exactly what that looks like in a second, but Stephen 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 manifests it's going to say like 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 side load a sign.net assembly and end up with more trusted code 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 and DN spy 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 will not work for what we're talking about. The bottom one you'll notice is a non-standard embedded manifest that we found and this is actually a signed 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 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 so one of the fields 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 is 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 that 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. And here's just some documentation to back up what Steven just said 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 side loading somebody else's click once deployment find it online download it side loaded dependency now we've just gone over the fact that there's a way to actually use an arbitrary .NET assembly that signed and wrap a click once deployment around it and use that for what we're talking about. But if we if we 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 is a 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 we'll do a demo of us instead of side loading somebody else's existing deployment we took an arbitrary Microsoft signed net assembly we wrapped wrapped it with some manifests that we created and because it meets because it is it checks off these boxes it it meets these prerequisites that we found we can weaponize it using click once so you see we start off here the 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 a signed on that assembly in this context you can see that the notepad prompt in the code that Stephen referenced earlier so this shows that our code successfully executed but the interesting part it here is that before you saw we were just running in the context of 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 prerequisites and ultimately side load 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 it 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 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 Stephen will talk about in a second the other is click once hunter so click once hunter essentially what it does is it's just gonna 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 well Stephen will also be releasing click hunter very soon that's going to do a lot of I'm sorry assembly hunter very soon and it will do a lot of really cool things some it'll triage the local file system and do a lot of these prereq 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've talked about so this is just a quick example of using show Dan 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 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 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 a hundred 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 abuseable 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 example of that one that Nick just showed from github share x pretty big project does not have the assembly identity line inside of it so this is an abuseable project can be deployed via a click once application so this was a showing that we can find it also with assembly hunter if it's installed on an endpoint 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 manifests in it so that means that it is abusable for us to take advantage of here we have chocolatey the 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 dotnet framework directory and so this highlights things that are important for us to take note of when looking into Donna 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 and so these are all just again abusable things from dotnet framework that we can also deploy as well at the bottom we have a casual which is also part of dotnet and not abusable because you can see the application identity is existent there so we cannot use that as a deployment for click once so we'll talk about some detection opportunities so click once 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 click once a day based on dfsvc and we also see in other environments that have zero executions a day so it's important to baseline here of click once 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 manifest parsing and all that and execution whatever we are running our application will be a trial process of dfsvc so any sort of non-common or non-expected trial processes of that 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 understand that this is not going to be inside of every environment this can be this type of telemetry is going to be leveraged or can be looked into but that for this technique at least is a pretty good way to catch this in addition to that dfsvc.dll can also be used to launch deployments or downloads of a click once deployment something we want to look into to ETW monitoring become increasingly used by endpoint products and EDRs and such so if you look at any sort of ETW information potentially find malicious code execution something to keep in mind for 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 it'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 download or every click once deployment is downloaded to the local updated directory so if we baseline that directory look for anything that is an outlier or non-common something that we can 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 back during existing .NET application 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 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 that we can enable so we have my computer local internet trusted sites internet and untrusted sites and so we can decide to if you 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 and we also could look for unsigned applications trying to attempting to be loaded to 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 your the users won't even have an opportunity to run it it just closed 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 co-worker Lee Christensen he's done a lot of incredible like offensive dot 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 Derby con talk that helped us a lot working towards these techniques another one would be William Burke gave a presentation on specifically the app for FMS stuff that we very briefly referenced during this presentation 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 dot net in general but even more specifically click once 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.