{
	"id": "451991ce-b75e-4f4a-ba4b-c5c6a70da076",
	"created_at": "2026-04-06T00:20:55.111023Z",
	"updated_at": "2026-04-10T03:22:09.853512Z",
	"deleted_at": null,
	"sha1_hash": "51abb513ef9daa7b898fabed00ccf4cb52203c22",
	"title": "Windows Exploitation Tricks: Exploiting Arbitrary File Writes for Local Elevation of Privilege",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 84026,
	"plain_text": "Windows Exploitation Tricks: Exploiting Arbitrary File Writes for\r\nLocal Elevation of Privilege\r\nArchived: 2026-04-02 11:23:12 UTC\r\nPosted by James Forshaw, Project Zero\r\nPreviously I presented a technique to exploit arbitrary directory creation vulnerabilities on Windows to give you\r\nread access to any file on the system. In the upcoming Spring Creators Update (RS4) the abuse of mount points to\r\nlink to files as I exploited in the previous blog post has been remediated. This is an example of a long term\r\nsecurity benefit from detailing how vulnerabilities might be exploited, giving a developer an incentive to find\r\nways of mitigating the exploitation vector.\r\nKeeping with that spirit in this blog post I’ll introduce a novel technique to exploit the more common case of\r\narbitrary file writes on Windows 10. Perhaps once again Microsoft might be able to harden the OS to make it more\r\ndifficult to exploit these types of vulnerabilities. I’ll demonstrate exploitation by describing in detail the recently\r\nfixed issue that Project Zero reported to Microsoft (issue 1428).\r\nAn arbitrary file write vulnerability is where a user can create or modify a file in a location they could not\r\nnormally access. This might be due to a privileged service incorrectly sanitizing information passed by the user or\r\ndue to a symbolic link planting attack where the user can write a link into a location which is subsequently used\r\nby the privileged service. The ideal vulnerability is one where the attacking user not only controls the location of\r\nthe file being written but also the entire contents. This is the type of vulnerability we’ll consider in this blog post.\r\nA common way of exploiting arbitrary file writes is to perform DLL hijacking. When a Windows executable\r\nbegins executing the initial loader in NTDLL will attempt to find all imported DLLs. The locations that the loader\r\nchecks for imported DLLs are more complex than you’d expect but for our purposes can be summarized as\r\nfollows:\r\n1. Check Known DLLs, which is a pre-cached list of DLLs which are known to the OS. If found, the DLL is\r\nmapped into memory from a pre-loaded section object.\r\n2. Check the application’s directory, for example if importing TEST.DLL and the application is in C:\\APP\r\nthen it will check C:\\APP\\TEST.DLL.\r\n3. Check the system locations, such as C:\\WINDOWS\\SYSTEM32 and C:\\WINDOWS.\r\n4. If all else fails search the current environment PATH.\r\nThe aim of the DLL hijack is to find an executable which runs at a high privilege which will load a DLL from a\r\nlocation that the vulnerability allows us to write to. The hijack only succeeds if the DLL hasn’t already been found\r\nin a location checked earlier.\r\nThere are two problems which make DLL hijacking annoying:\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 1 of 9\n\n1. You typically need to create a new instance of a privileged process as the majority of DLL imports are\r\nresolved when the process is first executed.\r\n2. Most system binaries, executables and DLLs that will run as a privileged user will be installed into\r\nSYSTEM32.\r\nThe second problem means that in steps 2 and 3 the loader will always look for DLLs in SYSTEM32. Assuming\r\nthat overwriting a DLL isn’t likely to be an option (at the least if the DLL is already loaded you can’t write to the\r\nfile), that makes it harder to find a suitable DLL to hijack. A typical way around these problems is to pick an\r\nexecutable that is not located in SYSTEM32 and which can be easily activated, such as by loading a COM server\r\nor running a scheduled task.\r\nEven if you find a suitable target executable to DLL hijack the implementation can be quite ugly. Sometimes you\r\nneed to implement stub exports for the original DLL, otherwise the loading of the DLL will fail. In other cases the\r\nbest place to run code is during DllMain, which introduces other problems such as running code inside the loader\r\nlock. What would be nice is a privileged service that will just load an arbitrary DLL for us, no hijacking, no\r\nneeding to spawn the “correct” privileged process. The question is, does such a service exist?\r\nIt turns out yes one does, and the service itself has been abused at least twice previously, once by Lokihardt for a\r\nsandbox escape, and once by me for user to system EoP. This service goes by the name “Microsoft (R)\r\nDiagnostics Hub Standard Collector Service,” but we’ll call it DiagHub for short.\r\nThe DiagHub service was introduced in Windows 10, although there’s a service that performs a similar task called\r\nIE ETW Collector in Windows 7 and 8.1. The purpose of the service is to collect diagnostic information using\r\nEvent Tracing for Windows (ETW) on behalf of sandboxed applications, specifically Edge and Internet Explorer.\r\nOne of its interesting features is that it can be configured to load an arbitrary DLL from the SYSTEM32 directory,\r\nwhich is the exact feature that Lokihardt and I exploited to gain elevated privileges. All the functionality for the\r\nservice is exposed over a registered DCOM object, so in order to load our DLL we’ll need to work out how to call\r\nmethods on that DCOM object. At this point you can skip to the end but if you want to understand how I would go\r\nabout finding how the DCOM object is implemented, the next section might be of interest.\r\nReverse Engineering a DCOM Object\r\nLet’s go through the steps I would take to try and find what interfaces an unknown DCOM object supports and\r\nfind the implementation so we can reverse engineer them. There are two approaches I will typically take, go\r\nstraight for RE in IDA Pro or similar, or do some on-system inspection first to narrow down the areas we have to\r\ninvestigate. Here we’ll go for the second approach as it’s more informative. I can’t say how Lokihardt found his\r\nissue; I’m going to opt for magic.\r\nFor this approach we’ll need some tools, specifically my OleViewDotNet v1.4+ (OVDN) tool from github as well\r\nas an installation of WinDBG from the SDK. The first step is to find the registration information for the DCOM\r\nobject and discover what interfaces are accessible. We know that the DCOM object is hosted in a service so once\r\nyou’ve loaded OVDN go to the menu Registry ⇒ Local Services and the tool will load a list of registered system\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 2 of 9\n\nservices which expose COM objects. If you now find the  “Microsoft (R) Diagnostics Hub Standard Collector\r\nService” service (applying a filter here is helpful) you should find the entry in the list. If you open the service tree\r\nnode you’ll see a child, “Diagnostics Hub Standard Collector Service,” which is the hosted DCOM object. If you\r\nopen that tree node the tool will create the object, then query for all remotely accessible COM interfaces to give\r\nyou a list of interfaces the object supports. I’ve shown this in the screenshot below:\r\nWhile we’re here it’s useful to inspect what security is required to access the DCOM object. If you right click the\r\nclass treenode you can select View Access Permissions or View Launch Permissions and you’ll get a window that\r\nshows the permissions. In this case it shows that this DCOM object will be accessible from IE Protected Mode as\r\nwell as Edge’s AppContainer sandbox, including LPAC.\r\nOf the list of interfaces shown we only really care about the standard interfaces. Sometimes there are interesting\r\ninterfaces in the factory but in this case there aren’t. Of these standard interfaces there are two we care about, the\r\nIStandardCollectorAuthorizationService and IStandardCollectorService. Just to cheat slightly I already know that\r\nit’s the IStandardCollectorService service we’re interested in, but as the following process is going to be the same\r\nfor each of the interfaces it doesn’t matter which one we pick first. If you right click the interface treenode and\r\nselect Properties you can see a bit of information about the registered interface.\r\nThere’s not much more information that will help us here, other than we can see there are 8 methods on this\r\ninterface. As with a lot of COM registration information, this value might be missing or erroneous, but in this case\r\nwe’ll assume it’s correct. To understand what the methods are we’ll need to track down the implementation of\r\nIStandardCollectorService inside the COM server. This knowledge will allow us to target our RE efforts to the\r\ncorrect binary and the correct methods. Doing this for an in-process COM object is relatively easy as we can query\r\nfor an object’s VTable pointer directly by dereferencing a few pointers. However, for out-of-process it’s more\r\ninvolved. This is because the actual in-process object you’d call is really a proxy for the remote object, as shown\r\nin the following diagram:\r\nAll is not lost, however; we can still find the the VTable of the OOP object by extracting the information stored\r\nabout the object in the server process. Start by right clicking the “Diagnostics Hub Standard Collector Service”\r\nobject tree node and select Create Instance. This will create a new instance of the COM object as shown below:\r\nThe instance gives you basic information such as the CLSID for the object which we’ll need later (in this case\r\n{42CBFAA7-A4A7-47BB-B422-BD10E9D02700}) as well as the list of supported interfaces. Now we need to\r\nensure we have a connection to the interface we’re interested in. For that select the IStandardCollectorService\r\ninterface in the lower list, then in the Operations menu at the bottom select Marshal ⇒ View Properties. If\r\nsuccessful you’ll now see the following new view:\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 3 of 9\n\nThere’s a lot of information in this view but the two pieces of most interest are the Process ID of the hosting\r\nservice and the Interface Pointer Identifier (IPID). In this case the Process ID should be obvious as the service is\r\nrunning in its own process, but this isn’t always the case—sometimes when you create a COM object you’ve no\r\nidea which process is actually hosting the COM server so this information is invaluable. The IPID is the unique\r\nidentifier in the hosting process for the server end of the DCOM object; we can use the Process ID and the IPID in\r\ncombination to find this server and from that find out the location of the actual VTable implementing the COM\r\nmethods. It’s worth noting that the maximum Process ID size from the IPID is 16 bits; however, modern versions\r\nof Windows can have much larger PIDs so there’s a chance that you’ll have to find the process manually or restart\r\nthe service multiple times until you get a suitable PID.\r\nNow we’ll use a feature of OVDN which allows us to reach into the memory of the server process and find the\r\nIPID information. You can access information about all processes through the main menu Object ⇒ Processes but\r\nas we know which process we’re interested in just click the View button next to the Process ID in the marshal\r\nview. You do need to be running OVDN as an administrator otherwise you’ll not be able to open the service\r\nprocess. If you’ve not done so already the tool will ask you to configure symbol support as OVDN needs public\r\nsymbols to find the correct locations in the COM DLLs to parse. You’ll want to use the version of\r\nDBGHELP.DLL which comes with WinDBG as that supports remote symbol servers. Configure the symbols\r\nsimilar to the following dialog:\r\nIf everything is correctly configured and you’re an administrator you should now see more details about the IPID,\r\nas shown below:\r\nThe two most useful pieces of information here are the Interface pointer, which is the location of the heap\r\nallocated object (in case you want to inspect its state), and the VTable pointer for the interface. The VTable\r\naddress gives us information for where exactly the COM server implementation is located. As we can see here the\r\nVTable is located in a different module (DiagnosticsHub.StandardCollector.Runtime) from the main executable\r\n(DiagnosticsHub.StandardCollector.Server). We can verify the VTable address is correct by attaching to the\r\nservice process using WinDBG and dumping the symbols at the VTable address. We also know from before we’re\r\nexpecting 8 methods so we can take that into account by using the command:\r\ndqs DiagnosticsHub_StandardCollector_Runtime+0x36C78 L8\r\nNote that WinDBG converts periods in a module name to underscores. If successful you’ll see the something\r\nsimilar to the following screenshot:\r\nExtracting out that information we now get the name of the methods (shown below) as well as the address in the\r\nbinary. We could set breakpoints and see what gets called during normal operation, or take this information and\r\nstart the RE process.\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 4 of 9\n\nATL::CComObject\u003cStandardCollectorService\u003e::QueryInterface\r\nATL::CComObjectCached\u003cStandardCollectorService\u003e::AddRef\r\nATL::CComObjectCached\u003cStandardCollectorService\u003e::Release\r\nStandardCollectorService::CreateSession\r\nStandardCollectorService::GetSession\r\nStandardCollectorService::DestroySession\r\nStandardCollectorService::DestroySessionAsync\r\nStandardCollectorService::AddLifetimeMonitorProcessIdForSession\r\nThe list of methods looks correct: they start with the 3 standard methods for a COM object, which in this case are\r\nimplemented by the ATL library. Following those methods are five implemented by the StandardCollectorService\r\nclass. Being public symbols, this doesn’t tell us what parameters we expect to pass to the COM server. Due to\r\nC++ names containing some type information, IDA Pro might be able to extract that information for you, however\r\nthat won’t necessarily tell you the format of any structures which might be passed to the function. Fortunately due\r\nto how COM proxies are implemented using the Network Data Representation (NDR) interpreter to perform\r\nmarshalling, it’s possible to reverse the NDR bytecode back into a format we can understand. In this case go back\r\nto the original service information, right click the IStandardCollectorService treenode and select View Proxy\r\nDefinition. This will get OVDN to parse the NDR proxy information and display a new view as shown below.\r\nViewing the proxy definition will also parse out any other interfaces which that proxy library implements. This is\r\nlikely to be useful for further RE work. The decompiled proxy definition is shown in a C# like pseudo code but it\r\nshould be easy to convert into working C# or C++ as necessary. Notice that the proxy definition doesn’t contain\r\nthe names of the methods but we’ve already extracted those out. So applying a bit of cleanup and the method\r\nnames we get a definition which looks like the following:\r\n[uuid(\"0d8af6b7-efd5-4f6d-a834-314740ab8caa\")]\r\nstruct IStandardCollectorService : IUnknown {\r\n   HRESULT CreateSession(_In_ struct Struct_24* p0,\r\n                         _In_ IStandardCollectorClientDelegate* p1,\r\n                         _Out_ ICollectionSession** p2);\r\n   HRESULT GetSession(_In_ GUID* p0, _Out_ ICollectionSession** p1);\r\n   HRESULT DestroySession(_In_ GUID* p0);\r\n   HRESULT DestroySessionAsync(_In_ GUID* p0);\r\n   HRESULT AddLifetimeMonitorProcessIdForSession(_In_ GUID* p0, [In] int p1);\r\n}\r\nThere’s one last piece missing; we don’t know the definition of the Struct_24 structure. It’s possible to extract this\r\nfrom the RE process but fortunately in this case we don’t have to. The NDR bytecode must know how to marshal\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 5 of 9\n\nthis structure across so OVDN just extracts the structure definition out for us automatically: select the Structures\r\ntab and find Struct_24.\r\nAs you go through the RE process you can repeat this process as necessary until you understand how everything\r\nworks. Now let’s get to actually exploiting the DiagHub service and demonstrating its use with a real world\r\nexploit.\r\nExample Exploit\r\nSo after our efforts of reverse engineering, we’ll discover that in order to to load a DLL from SYSTEM32 we need\r\nto do the following steps:\r\n1. Create a new Diagnostics Session using IStandardCollectorService::CreateSession.\r\n2. Call the ICollectionSession::AddAgent method on the new session, passing the name of the DLL to load\r\n(without any path information).\r\nThe simplified loading code for ICollectionSession::AddAgent is as follows:\r\nvoid EtwCollectionSession::AddAgent(LPWCSTR dll_path,\r\n                                   REFGUID guid) {\r\n WCHAR valid_path[MAX_PATH];\r\n if ( !GetValidAgentPath(dll_path, valid_path)) {\r\n   return E_INVALID_AGENT_PATH;\r\n HMODULE mod = LoadLibraryExW(valid_path,\r\n       nullptr, LOAD_WITH_ALTERED_SEARCH_PATH);\r\n dll_get_class_obj = GetProcAddress(hModule, \"DllGetClassObject\");\r\n return dll_get_class_obj(guid);\r\n}\r\nWe can see that it checks that the agent path is valid and returns a full path (this is where the previous EoP bugs\r\nexisted, insufficient checks). This path is loading using LoadLibraryEx, then the DLL is queried for the exported\r\nmethod DllGetClassObject which is then called. Therefore to easily get code execution all we need is to\r\nimplement that method and drop the file into SYSTEM32. The implemented DllGetClassObject will be called\r\noutside the loader lock so we can do anything we want. The following code (error handling removed) will be\r\nsufficient to load a DLL called dummy.dll.\r\nIStandardCollectorService* service;\r\nCoCreateInstance(CLSID_CollectorService, nullptr, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(\u0026service));\r\nSessionConfiguration config = {};\r\nconfig.version = 1;\r\nconfig.monitor_pid = ::GetCurrentProcessId();\r\nCoCreateGuid(\u0026config.guid);\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 6 of 9\n\nconfig.path = ::SysAllocString(L\"C:\\Dummy\");\r\nICollectionSession* session;\r\nservice-\u003eCreateSession(\u0026config, nullptr, \u0026session);\r\nGUID agent_guid;\r\nCoCreateGuid(\u0026agent_guid);\r\nsession-\u003eAddAgent(L\"dummy.dll\", agent_guid);\r\nAll we need now is the arbitrary file write so that we can drop a DLL into SYSTEM32, load it and elevate our\r\nprivileges. For this I’ll demonstrate using a vulnerability I found in the SvcMoveFileInheritSecurity RPC method\r\nin the system Storage Service. This function caught my attention due to its use in an exploit for a vulnerability in\r\nALPC discovered and presented by Clément Rouault \u0026 Thomas Imbert at PACSEC 2017. While this method was\r\njust a useful exploit primitive for the vulnerability I realized it has not one, but two actual vulnerabilities lurking\r\nin it (at least from a normal user privilege). The code prior to any fixes for SvcMoveFileInheritSecurity looked\r\nlike the following:\r\nvoid SvcMoveFileInheritSecurity(LPCWSTR lpExistingFileName,\r\n                               LPCWSTR lpNewFileName,\r\n                               DWORD dwFlags) {\r\n PACL pAcl;\r\n if (!RpcImpersonateClient()) {\r\n   // Move file while impersonating.\r\n   if (MoveFileEx(lpExistingFileName, lpNewFileName, dwFlags)) {\r\n     RpcRevertToSelf();\r\n     // Copy inherited DACL while not.\r\n     InitializeAcl(\u0026pAcl, 8, ACL_REVISION);\r\n     DWORD status = SetNamedSecurityInfo(lpNewFileName, SE_FILE_OBJECT,\r\n         UNPROTECTED_DACL_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION,\r\n         nullptr, nullptr, \u0026pAcl, nullptr);\r\n       if (status != ERROR_SUCCESS)\r\n         MoveFileEx(lpNewFileName, lpExistingFileName, dwFlags);\r\n   }\r\n   else {\r\n     // Copy file instead...\r\n     RpcRevertToSelf();\r\n   }\r\n }\r\n}\r\nThe purpose of this method seems to be to move a file then apply any inherited ACE’s to the DACL from the new\r\ndirectory location. This would be necessary as when a file is moved on the same volume, the old filename is\r\nunlinked and the file is linked to the new location. However, the new file will maintain the security assigned from\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 7 of 9\n\nits original location. Inherited ACEs are only applied when a new file is created in a directory, or as in this case,\r\nthe ACEs are explicitly applied by calling a function such as SetNamedSecurityInfo.\r\nTo ensure this method doesn’t allow anyone to move an arbitrary file while running as the service’s user, which in\r\nthis case is Local System, the RPC caller is impersonated. The trouble starts immediately after the first call to\r\nMoveFileEx, the impersonation is reverted and SetNamedSecurityInfo is called. If that call fails then the code\r\ncalls MoveFileEx again to try and revert the original move operation. This is the first vulnerability; it’s possible\r\nthat the original filename location now points somewhere else, such as through the abuse of symbolic links. It’s\r\npretty easy to cause SetNamedSecurityInfo to fail, just add a Deny ACL for Local System to the file’s ACE for\r\nWRITE_DAC and it’ll return an error which causes the revert and you get an arbitrary file creation. This was\r\nreported as issue 1427.\r\nThis is not in fact the vulnerability we’ll be exploiting, as that would be too easy. Instead we’ll exploit a second\r\nvulnerability in the same code: the fact that we can get the service to call SetNamedSecurityInfo on any file we\r\nlike while running as Local System. This can be achieved either by abusing the impersonated device map to\r\nredirect the local drive letter (such as C:) when doing the initial MoveFileEx, which then results in\r\nlpNewFileName pointing to an arbitrary location, or more interestingly abusing hard links. This was reported as\r\nissue 1428. We can exploit this using hard links as follows:\r\n1. Create a hard link to a target file in SYSTEM32 that we want to overwrite. We can do this as you don’t\r\nneed to have write privileges to a file to create a hard link to it, at least outside of a sandbox.\r\n2. Create a new directory location that has an inheritable ACE for a group such as Everyone or Authenticated\r\nUsers to allow for modification of any new file. You don’t even typically need to do this explicitly; for\r\nexample, any new directory created in the root of the C: drive has an inherited ACE for Authenticated\r\nUsers. Then a request can be made to the RPC service to move the hardlinked file to the new directory\r\nlocation. The move succeeds under impersonation as long as we have FILE_DELETE_CHILD access to\r\nthe original location and FILE_ADD_FILE in the new location, which we can arrange.\r\n3. The service will now call SetNamedSecurityInfo on the moved hardlink file. SetNamedSecurityInfo will\r\npick up the inherited ACEs from the new directory location and apply them to the hardlinked file. The\r\nreason the ACEs are applied to the hardlinked file is from the perspective of SetNamedSecurityInfo the\r\nhardlinked file is in the new location, even though the original target file we linked to was in SYSTEM32.\r\nBy exploiting this we can modify the security of any file that Local System can access for WRITE_DAC access.\r\nTherefore we can modify a file in SYSTEM32, then use the DiagHub service to load it. There is a slight problem,\r\nhowever. The majority of files in SYSTEM32 are actually owned by the TrustedInstaller group and so cannot be\r\nmodified, even by Local System. We need to find a file we can write to which isn’t owned by TrustedInstaller.\r\nAlso we’d want to pick a file that won’t cause the OS install to become corrupt. We don’t care about the file’s\r\nextension as AddAgent only checks that the file exists and loads it with LoadLibraryEx. There are a number of\r\nways we can find a suitable file, such as using the SysInternals AccessChk utility, but to be 100% certain that the\r\nStorage Service’s token can modify the file we’ll use my NtObjectManager PowerShell module (specifically its\r\nGet-AccessibleFile cmdlet, which accepts a process to do the access check from). While the module was designed\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 8 of 9\n\nfor checking accessible files from a sandbox, it also works to check for files accessible by privileged services. If\r\nyou run the following script as an administrator with the module installed the $files variable will contain a list of\r\nfiles that the Storage Service has WRITE_DAC access to.\r\nImport-Module NtObjectManager\r\nStart-Service -Name \"StorSvc\"\r\nSet-NtTokenPrivilege SeDebugPrivilege | Out-Null\r\n$files = Use-NtObject($p = Get-NtProcess -ServiceName \"StorSvc\") {\r\n   Get-AccessibleFile -Win32Path C:\\Windows\\system32 -Recurse `\r\n    -MaxDepth 1 -FormatWin32Path -AccessRights WriteDac -CheckMode FilesOnly\r\n}\r\nLooking through the list of files I decided to pick on the file license.rtf, which contains a short license statement\r\nfor Windows. The advantage of this file is it’s very likely to be not be critical to the operation of the system and so\r\noverwriting it shouldn’t cause the installation to become corrupted.\r\nSo putting it all together:\r\n1. Use the Storage Service vulnerability to change the security of the license.rtf file inside SYSTEM32.\r\n2. Copy a DLL, which implements DllGetClassObject over the license.rtf file.\r\n3. Use the DiagHub service to load our modified license file as a DLL, get code execution as Local System\r\nand do whatever we want.\r\nIf you’re interested in seeing a fully working example, I’ve uploaded a full exploit to the original issue on the\r\ntracker.\r\nWrapping Up\r\nIn this blog post I’ve described a useful exploit primitive for Windows 10, which you can even use from some\r\nsandboxed environments such as Edge LPAC. Finding these sorts of primitives makes exploitation much simpler\r\nand less error-prone. Also I’ve given you a taste of how you can go about finding your own bugs in similar\r\nDCOM implementations.\r\nSource: https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nhttps://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html"
	],
	"report_names": [
		"windows-exploitation-tricks-exploiting.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434855,
	"ts_updated_at": 1775791329,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/51abb513ef9daa7b898fabed00ccf4cb52203c22.pdf",
		"text": "https://archive.orkl.eu/51abb513ef9daa7b898fabed00ccf4cb52203c22.txt",
		"img": "https://archive.orkl.eu/51abb513ef9daa7b898fabed00ccf4cb52203c22.jpg"
	}
}