{
	"id": "1e1e2269-75d6-4164-8752-3a5abfb99f15",
	"created_at": "2026-04-06T00:10:03.286546Z",
	"updated_at": "2026-04-10T03:20:39.373383Z",
	"deleted_at": null,
	"sha1_hash": "f0b086a523a16220dd30b19de829eb7311cfb79f",
	"title": "Less SmartScreen More Caffeine: (Ab)Using ClickOnce for Trusted Code Execution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5454872,
	"plain_text": "Less SmartScreen More Caffeine: (Ab)Using ClickOnce for\r\nTrusted Code Execution\r\nBy Nick Powers\r\nPublished: 2023-06-07 · Archived: 2026-04-05 15:25:09 UTC\r\nThe contents of this blogpost was written by Nick Powers (@zyn3rgy) and Steven Flores (@0xthirteen), and is a\r\nwritten version of the content presented at Defcon30.\r\nWith the barrier to entry for initial access ever increasing, we spent some time digging into potentially lesser-known weaponization options for ClickOnce deployments. A few of the hurdles we’d like to overcome by\r\nimplementing these weaponization options include:\r\nInstall / execute application without administrative privileges\r\nReputable, known-good file(s) used during execution\r\nStreamlined, minimal user interaction required\r\nEase of rerolling execution implementations\r\nUltimately, we want to take a relatively common initial access technique known as ClickOnce and extend its value\r\nfor the offensive use case by abusing the trust of third-party applications.\r\nClickOnce Overview and Current Weaponizations\r\n“ClickOnce is a deployment technology that enables you to create self-updating Windows-based\r\napplications that can be installed and run with minimal user interaction” –MSDN\r\nClickOnce is a vehicle for installing and updating .NET applications. Deployments can be published through a\r\nvariety of options (e.g. network file shares, legacy media [CD-ROM], and web pages). We will be focusing on the\r\nweb page method of publishing deployments. Legitimate applications exist and make use of ClickOnce\r\ndeployments for installation or updating software such as Chrome (previously), Fidelity, and others.\r\nClickOnce deployments rely on manifests which are formatted in a very specific way. Just like .NET applications,\r\nthere will be different types of manifests that need to be accounted for. There are three types of manifest to\r\nbecome familiar with when discussing ClickOnce deployments:\r\n\u003e ClickOnce deployment manifests\r\n*.application is the file extension for these\r\nReferences the ClickOnce application manifest to deploy\r\nAPPREF-MS file will point to this (if used)\r\n\u003e ClickOnce application manifests\r\n*.exe.manifest is the file extension for these\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 1 of 19\n\nSpecifies dependencies for the deployment (states version of .NET that will be utilized)\r\nConducts integrity check of deployment manifest\r\nReferences to dependencies and other files for delivery\r\n\u003e Embedded application and assembly manifests\r\nApplication manifest can also be called unmanaged or fusion manifest\r\nAssembly manifest can also be called managed manifest\r\nAt runtime, ClickOnce makes comparisons against these\r\nEmbedded Assembly Manifest\r\nEmbedded Application Manifest\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 2 of 19\n\nClickOnce Deployment Manifest, Executable, and Application Manifest\r\nClickOnce applications can be deployed to a client by visiting the *.application deployment manifest using a\r\nbrowser. The download and execution process of a standard ClickOnce deployment requires the end user to be\r\nusing a Microsoft Edge or Internet Explorer browser. An alternative to requiring the target user to access your\r\ndeployment manifest from either Edge or Internet Explorer would be to leverage APPREF-MS. When creating an\r\n*.appref-ms file, UTF-16 LE encoding is required. An appref-ms file would be used if the end user is using\r\nsomething like Chrome or Firefox to access the application.\r\nNOTE: A simple user-agent check can be done prior to reaching the landing page to determine whether\r\nthe incoming request should be pointed towards the standard deployment manifest or an appref-ms file.\r\nThe host assembly, specified in the manifest, will spawn as a child process of ‘dfsvc.exe’, which handles the\r\nClickOnce deployment functionality that is imported from ‘System.Deployment.dll’. The contents of the\r\nClickOnce application manifest will specify what dependencies and other resources will be delivered during the\r\ndeployment process. The contents of the deployment will ultimately be saved to:\r\nC:Users%USERNAME%AppDataLocalApps2.0\u003crandomstring\u003e\r\nOnce a user has accepted to run the application, the deployment manifest will look to the ClickOnce application\r\nmanifest for all the files that need to be downloaded.\r\nClickOnce Deployment Manifest Example\r\nThere will be different pieces of information located throughout the manifest that look very similar to .NET\r\napplication manifests. This will contain all of the files and dependencies the deployment will need to execute\r\nproperly.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 3 of 19\n\nClickOnce Application Manifest Example\r\nThe dfsvc process will make a series of HTTP requests for the downloads and save in the %LocalAppData%\r\nlocation mentioned above.\r\nHTTP Requests While Downloading a ClickOnce Application\r\nIn some scenarios users may want to interact with ClickOnce applications but are not using Microsoft Edge or\r\nInternet Explorer. An appref-ms file can be created that will act similar to an LNK or shortcut file that will contain\r\nthe URL of the deployment manifest and some other pieces of information.\r\nAPPREF-MS Example\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 4 of 19\n\nDuring the process before all the downloading happens, the System.Deployment DLL will be utilized to run\r\nthrough various checks and ensure the ClickOnce application can properly execute. One important check to note is\r\nthe .NET application and ClickOnce deployment identities that are configured in the assembly and the deployment\r\nmanifests.\r\nSystem.Deployment.dll Logic to Parse Manifests\r\nCommonly, when crafting an initial access payload and using ClickOnce, you’d go through the process of writing\r\nit up in an IDE like Visual Studio and building the ClickOnce application. So what does standard ClickOnce\r\ndeployment execution look like, using a newly created .NET application?\r\nhttps://medium.com/media/89e79bb1f51bfbfbf9b2401ae678f980/href\r\nCurrent ClickOnce Weaponization Pressure Points\r\nAs seen in the first demo, we experience a few issues. For instance, Microsoft SmartScreen was triggered. This is\r\nbecause the assembly that ultimately executed with our arbitrary code was compiled recently and had never been\r\nseen by SmartScreen before. The reputation for Microsoft SmartScreen can be based on a number of factors such\r\nas the hash of the host assembly or the certificate used to sign the assembly.\r\nBloodHound Slack Discussion on ClickOnce\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 5 of 19\n\nAchieving arbitrary code execution within the context of an application seen and otherwise trusted by Microsoft\r\nSmartScreen or EDR products can decrease likelihood of prevention. Solutions such as application control or\r\nwhitelisting prevention can be noteworthy when considering how we want to conduct our code execution,\r\nespecially during initial access attempts. An Extended Validation (EV) code signing certificate can be used to\r\nobtain immediate SmartScreen reputation, but the vetting process and price point increase the barrier to entry.\r\nWhen code-signing certificates are used, there are also additional attribution concerns.\r\nGenerally, a ClickOnce deployment can be tedious to make sure “all the stars align” for a successful deployment.\r\nOftentimes people view ClickOnce as tedious to deploy successfully and having many configuration\r\nrequirements. We hope the next couple sections outline the important fields within ClickOnce manifests to focus\r\non, to assist in reproducing these techniques.\r\nAlleviation of ClickOnce Weaponization Pressure Points\r\nIf legitimate .NET applications make use of ClickOnce, and we can reliably sideload or hijack those .NET\r\napplications, why not just backdoor an existing deployment? An existing deployment that already has, lets say, a\r\nvalid EV code signature and SmartScreen reputation?\r\nNOTE: We will backdoor a dependency of a ClickOnce deployment, not the host assembly itself. We\r\nmaintain the valid signature associated with that host assembly.\r\nIdentifying existing ClickOnce deployments can be as easy as leveraging a couple search engine dorking\r\ntechniques (or using the ClickonceHunter tool which will be covered later). Several tools can be used throughout\r\nthis process (e.g. dnSpy, reshacker, mage, sigcheck, etc).\r\nDownload of ClickOnce Application Discovered from Google\r\nWe will want to identify sideloading opportunities for dependencies of the target .NET assembly that the\r\nClickOnce deployment will execute. Any way for us to hijack the flow of execution shortly after the application\r\nentry point is what we are looking for. Oftentimes this process consists of using dnSpy to decompile the\r\ntarget .NET assembly to understand the execution flow enough to identify a sideload opportunity.\r\nOnce an ideal DLL to backdoor has been identified, use dnSpy to add your code to the target DLL. At this point,\r\nthe ClickOnce manifests of the deployment you’ve chosen will need to be tweaked to pass their integrity checks.\r\nIf you cannot identify an ideal sideload opportunity in the existing codepath(s), techniques such as\r\nAppDomainManager injection or .NET deserialization abuse can be helpful here.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 6 of 19\n\nThe image below is a quick example of what sideloading an existing, signed ClickOnce deployment would look\r\nlike. First, we find a ClickOnce deployment published online, download it, and verify the assembly that the\r\ndeployment executes meets our needs (valid code signature, SmartScreen reputation, etc):\r\nExample of Signed ClickOnce Application\r\nNext we take a look at the references within the signed .NET assembly we want to sideload. A few of the DLLs\r\nthe assembly uses are not strongly named, which can be helpful in certain situations:\r\nDependencies of Target Assembly\r\nUsing DnSpy to begin at the target .NET assembly’s entry point, we follow the code to the first method call of\r\n“SetDpiAwareness()”. This function exists within on the the Dlls previously identified:\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 7 of 19\n\nFollowing the Code Path\r\nWe observe the code within this method and verify it exists within a DLL dependency (not the host .NET\r\nassembly):\r\nIdentified Location to Place Additional Code\r\nThe additional code we’d like to sideload the ClickOnce deployment with can be added here. For proof-of-concept\r\nsake, we will just spawn notepad and prompt with a MessageBox:\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 8 of 19\n\nAdding Code to Target Dependency\r\nAt this point, dnSpy can add your changes to intermediary language (IL) and you will have your backdoored\r\ndependency of the target ClickOnce application. Now is a good time to test and make sure the additional code\r\nyou’ve added properly executes when running the host .NET assembly.\r\nNOTE: We previously thought a prerequisite was targeting only non-strongly named DLLs. We\r\ndiscovered this is not a requirement because modifying a DLL does not modify the PublickeyToken\r\nvalue of the DLL. The PublickeyToken value is in reference to the hash of the assembly’s embedded\r\nmanifest rather than the code itself. If the manifest is not modified, the PublickeyToken value remains\r\nthe same and will still be loaded successfully.\r\nNow that we have our sideload of a signed .NET application that is part of an existing ClickOnce deployment, our\r\nlast step to have a functioning deployment is to tweak the two ClickOnce manifests such that the integrity checks\r\nthat occur during deployment do not fail. Here’s a few tips that will hopefully speed the process up:\r\npublicKeyToken — this value is required, but can be nulled out by replacing the value with 16 zeros\r\n\u003chash\u003e — this block is optional and can be removed or recalculated (EX: openssl -dgst -binary -sha1\r\nProgram.exe.manifest |openssl enc -base64)\r\n\u003cpublisherIdentity\u003e — included if the manifests have been signed, but is optional and can be removed\r\nA noteworthy mention regarding modification of an existing ClickOnce manifest is that if the manifest was signed\r\nwith a valid certificate, then making these modifications will break that integrity. The difference to the end user is\r\nminimal and many legitimate ClickOnce deployments do not sign their manifests at all. We still have control of\r\nthe prompt observed by the target user, such as “Name” and “From”. A signed vs unsigned look similar to the\r\nimage below:\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 9 of 19\n\nDifference Between Signed and Unsigned Deployment Manifest\r\nSo the question posed is this: Do we really need a code signing certificate to effectively weaponize ClickOnce\r\ndeployments?\r\nhttps://medium.com/media/26e9d9500edcdde52bfda392ef95832a/href\r\nExtending Past Existing ClickOnce Deployments\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 10 of 19\n\nThe number of published ClickOnce deployments easily identifiable through dorking is finite. It’s not a new\r\ntechnology, nor is it the most popular to deploy and update .NET applications. We foresaw this as a potential issue\r\nand sought to find a way to take any ideal .NET assembly, identify a sideload opportunity, and wrap it up as a new\r\nClickOnce deployment. As it turns out, this was possible, with a few prerequisites.\r\n1. The \u003cassemblyIdentity\u003e field within the embedded application manifest must not exist, or the entire\r\nembedded application manifest must not exist (more on this in a bit)\r\n2. The UAC settings cannot be set to ‘requireAdministrator’ or ‘highestAvailable’\r\n.NET assemblies that meet these prerequisites can be weaponized as backdoored ClickOnce deployments\r\nrelatively easily. The System.Deployment DLL has code that checks the assembly identity which is found in the\r\nembedded application manifest. This check cross-references the application manifest’s identity to ensure the\r\nidentity values are the same. The image below shows what the embedded assembly manifest default identity will\r\nbe if it is present.\r\nExample of Default “assemblyIdentity” Field\r\nAs you can see the identity contains two pieces of information, the version and the name. The figure below shows\r\nwhat is in the deployment manifest for the identity value. If you look at the difference there is a value of\r\nprocessorArchitecture.\r\nClickOnce Deployment “assemblyIdentity”\r\nThe ‘processorArchitecture’ value is a required value to be present for the assembly identity in the deployment\r\nmanifest.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 11 of 19\n\nMSDN Documentation Showing Required Values\r\nThese two values are checked against each other to validate assembly identities are the same. If the default\r\nidentity value is present in the assembly’s embedded manifest it will fail because there is no\r\n‘processorArchitecture’ value present. Therefore, this type of assembly is not possible to use as a ClickOnce\r\napplication for our purposes. Modifying this value would require modifying the host assembly of our code\r\nexecution, losing any benefit of a valid code-signature or reputations with Microsoft SmartScreen.\r\nSystem.Deployment dll Checking Identities\r\nFortunately there are a lot of assemblies that exist which do not have an identity in the application’s manifest. In\r\nthe next section we will show how to identify these assemblies, but in the meantime, the figure below shows what\r\nan embedded manifest looks like when the default identity is not set, and a non-default manifest was used during\r\nthe build process instead.\r\n\u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\r\n\u003casmv1:assembly manifestVersion=\"1.0\" xmlns=\"urn:schemas-microsoft-com:asm.v1\" xmlns:asmv1=\"urn:schem\r\n \u003ctrustInfo xmlns=\"urn:schemas-microsoft-com:asm.v2\"\u003e\r\n \u003csecurity\u003e\r\n \u003crequestedPrivileges xmlns=\"urn:schemas-microsoft-com:asm.v3\"\u003e\r\n \u003c!-- UAC Manifest Options\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 12 of 19\n\nIf you want to change the Windows User Account Control level replace the\n requestedExecutionLevel node with one of the following. Specifying requestedExecutionLevel node will disable file and registry virtualization.\n If you want to utilize File and Registry Virtualization for backward\n compatibility then delete the requestedExecutionLevel node.\n --\u003e The second condition that is required is for the UAC settings to not be requiredAdministrator or highestAvailable.\nAnother check by the System.Deployment DLL is it will look for the UAC settings and return errors if the\ndisallowed values are set.\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\nPage 13 of 19\n\nUAC Check in System.Deployment DLL\r\nIf UAC information exists, or it is set to ‘asInvoker’ the assembly will work as a ClickOnce deployment.\r\nAssembly with No UAC Information\r\nSince we are creating ClickOnce applications from scratch, we will have to create new manifests as opposed to\r\nour previous weaponization of modifying existing ClickOnce manifests. Microsoft has a utility that is used for this\r\nspecific task which is called the Manifest Generation and Editing Tool (Mage). Microsoft makes two different\r\ntools that can be used, MageUI and Mage. Mage is a command line tool that comes part of the Windows SDK and\r\nfor the purpose of this blog will be the one we cover.\r\nOnce you have gone through the process of identifying a .NET assembly that can be wrapped up as a ClickOnce\r\ndeployment, you will want to create the directory structure of the assembly, dependencies, and extra files. As\r\npreviously mentioned, there are two manifests that will need to be created with Mage — the deployment manifest\r\nand the application manifest. The application manifest can be created with the following command:\r\n\"C:Program Files (x86)Microsoft SDKsWindowsv10.0AbinNETFX 4.8 Toolsmage.exe\" -New Application -Proces\r\nNext you will need to create the deployment manifest. This can be done with the following command:\r\n\"C:Program Files (x86)Microsoft SDKsWindowsv10.0AbinNETFX 4.8 Toolsmage.exe\" -New Deployment -Process\r\nThe ProviderUrl argument is the location where the deployment manifest will be hosted since the primary method\r\nwe’re covering is web-based applications. Once the manifests are created, you will see there are some signature\r\nvalues that are created with Mage. Just like what was covered when editing existing manifests, these values are\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 14 of 19\n\nnot always required and can be removed. If any changes are made to the overall deployment, the signatures will be\r\ninvalidated and will have to be regenerated which can lead to unnecessary troubleshooting. As mentioned\r\npreviously, these values are:\r\n\u003cpublicKeyToken\u003e, required but can be nulled with 16 zeros\r\n\u003chash\u003e block can be removed altogether and not required\r\nPublisher identity block can be removed altogether\r\nNow that we have identified an existing signed .NET assembly that can be deployed as a ClickOnce application,\r\nwe can go through the same backdoor steps as the other technique. We will follow the code paths, identify called\r\nDLLs, and place our code inside of those DLLs. Finally, we can create the manifests with Mage and are ready for\r\ndeployment.\r\nhttps://medium.com/media/69c4555ae96ea40ccee7e867e36c16e9/href\r\nIdentification of .NET Assemblies and ClickOnce Applications\r\nSo far, we’ve covered the types of applications that can be weaponized, and now we want to discover potential\r\ntargets. We have released two tools that will aid in the discovery of existing ClickOnce applications and .NET\r\nassemblies that can be weaponized for ClickOnce.\r\n\u003e ClickonceHunter\r\nsearches online for existing ClickOnce published code\r\nGoogle dorks, Github and others\r\n\u003e AssemblyHunter\r\nSearches file paths or files and looks for given criteria (signed, identity info, arch, UAC, etc.)\r\nHelps identify target applications to weaponize\r\nClickonceHunter will automate what can be done manually with Google or other related searches.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 15 of 19\n\nDorking to Discover Third-Party ClickOnce Deployments\r\nGithub Searches for ClickOnce Projects (maybe with signed releases?)\r\nWhile ClickonceHunter will go look through the internet for existing applications, AssemblyHunter will\r\nrecursively search local file systems for assemblies that meet the criteria for a regular .NET assembly to be\r\ndeployed as a ClickOnce application.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 16 of 19\n\nUsage for AssemblyHunter\r\nAssemblyHunter Discovering .NET Assembly\r\nUsing AssemblyHunter, we can quickly identify assemblies across a host’s filesystem and look for values that will\r\nbe useful to us.\r\nAssemblyHunter Showing Assemblies that can be Weaponized\r\nAssemblyHunter will also show us assemblies that are not useful to us if we would like to see them.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 17 of 19\n\nExample of anAssembly that Cannot be Weaponized\r\nDetection and Prevention Opportunities\r\nA major benefit to defenders who want to identify malicious ClickOnce deployments is that ClickOnce is not\r\ncommonly used in many corporate environments. Defenders can baseline their environments to look for how\r\nprevalent they are and make detection or prevention decisions. Things we would consider looking for when\r\nidentifying or preventing malicious ClickOnce use is:\r\n\u003e Monitoring dfsvc.exe process activity\r\nMonitoring child process activity (e.g. child processes with unsigned module loads)\r\nBaseline required ClickOnce activity to whitelist applications with valid business use-cases\r\nMonitoring activity associated with dfshim.dll (can also be used for launching ClickOnce deployments)\r\n\u003e Evaluate ETW telemetry associated with ClickOnce deployment execution\r\nKeep in mind ETW bypasses or \u003cetwEnable\u003e .NET config value\r\n\u003e Baseline the default ClickOnce installation directories\r\n%LOCALAPPDATA%Apps2.0\u003cstring\u003e\r\n\u003e Baseline of application that have never been seen making connections to the internet\r\n\u003e Disable all ClickOnce installations from the internet, while still allowing from other trust zones\r\nOptions include: Enabled, AuthenticodeRequired, and Disabled\r\nZones include: MyComputer, LocalIntranet, TrustedSites, Internet, UntrustedSites\r\nTo disable installation from internet:\r\nHKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkSecurityTrustManagerPromptingLevel \r\n— Internet:Disabled\r\n\u003e If an Application Control solution is deployed\r\nPrevent unreputable DLLs from being loaded\r\nIf ClickOnce application execution from the internet is disabled using the registry key(s) mentioned above, a user\r\nwill recieve a prompt that does not give them the option to run the application.\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 18 of 19\n\nPrevention of ClickOnce Installation from Internet Trust Zone\r\nClosing\r\nBased on all that was covered, we see ClickOnce as one of the best opportunities for initial access. There are still\r\nplenty of areas to dig into and additional potential for offensive use-cases. A few people we want to give thanks to\r\nand who paved the way for the work done are Lee Christensen (@tifkin_), whose exploration of this technique\r\nwouldn’t have been possible without him, Casey Smith (@subTee) for previous .NET research, and William\r\nBurke (@0xF4B0) for previous ClickOnce research.\r\nLess SmartScreen More Caffeine: (Ab)Using ClickOnce for Trusted Code Execution was originally published in\r\nPosts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting\r\nand responding to this story.\r\nPost Views: 2,671\r\nSource: https://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nhttps://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://posts.specterops.io/less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5"
	],
	"report_names": [
		"less-smartscreen-more-caffeine-ab-using-clickonce-for-trusted-code-execution-1446ea8051c5"
	],
	"threat_actors": [],
	"ts_created_at": 1775434203,
	"ts_updated_at": 1775791239,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f0b086a523a16220dd30b19de829eb7311cfb79f.pdf",
		"text": "https://archive.orkl.eu/f0b086a523a16220dd30b19de829eb7311cfb79f.txt",
		"img": "https://archive.orkl.eu/f0b086a523a16220dd30b19de829eb7311cfb79f.jpg"
	}
}