Worth adding old ProcessHacker driver as provider?

[hfiref0x]

Worth adding old ProcessHacker driver as provider?

[hfiref0x]

Resurrecting this issue as this driver shows potential due to it hack-o-rama nature. Plus it already widely used by malware so why not.

[hfiref0x]

It has been added as provider number 18 in commit (a81c4d1).

[hfiref0x]

// General
#define KPH_GETFEATURES KPH_CTL_CODE(0)

// Processes
#define KPH_OPENPROCESS KPH_CTL_CODE(50)
#define KPH_OPENPROCESSTOKEN KPH_CTL_CODE(51)
#define KPH_OPENPROCESSJOB KPH_CTL_CODE(52)
#define KPH_SUSPENDPROCESS KPH_CTL_CODE(53)
#define KPH_RESUMEPROCESS KPH_CTL_CODE(54)
#define KPH_TERMINATEPROCESS KPH_CTL_CODE(55)
#define KPH_READVIRTUALMEMORY KPH_CTL_CODE(56)
#define KPH_WRITEVIRTUALMEMORY KPH_CTL_CODE(57)
#define KPH_READVIRTUALMEMORYUNSAFE KPH_CTL_CODE(58)
#define KPH_QUERYINFORMATIONPROCESS KPH_CTL_CODE(59)
#define KPH_SETINFORMATIONPROCESS KPH_CTL_CODE(60)

// Threads
#define KPH_OPENTHREAD KPH_CTL_CODE(100)
#define KPH_OPENTHREADPROCESS KPH_CTL_CODE(101)
#define KPH_TERMINATETHREAD KPH_CTL_CODE(102)
#define KPH_TERMINATETHREADUNSAFE KPH_CTL_CODE(103)
#define KPH_GETCONTEXTTHREAD KPH_CTL_CODE(104)
#define KPH_SETCONTEXTTHREAD KPH_CTL_CODE(105)
#define KPH_CAPTURESTACKBACKTRACETHREAD KPH_CTL_CODE(106)
#define KPH_QUERYINFORMATIONTHREAD KPH_CTL_CODE(107)
#define KPH_SETINFORMATIONTHREAD KPH_CTL_CODE(108)

// Handles
#define KPH_ENUMERATEPROCESSHANDLES KPH_CTL_CODE(150)
#define KPH_QUERYINFORMATIONOBJECT KPH_CTL_CODE(151)
#define KPH_SETINFORMATIONOBJECT KPH_CTL_CODE(152)
#define KPH_DUPLICATEOBJECT KPH_CTL_CODE(153)

// Misc.
#define KPH_OPENDRIVER KPH_CTL_CODE(200)
#define KPH_QUERYINFORMATIONDRIVER KPH_CTL_CODE(201)

Hello,

Nothing from this looks helpful for driver mapping purposes or DKOM. In fact this set of features are only good for some malware usage. Correct me if I wrong.

[mgeeky]

I was thinking specifically on memory read/write IOCTLs.
Having kernel memory I/O primitives could facilitate implementation of reflective module loading (driver mapping), isn't it?

[hfiref0x]

From what I see in IOCTL list it allows virtual memory write/read not physical memory access. Most of this is just reimplemented Win API to get rid of it restrictions.

[mgeeky]

Ah, fair enough - didn't look at source code more closely. If that's the case - I'm good to close that issue.

Thanks!

[PatchByte]

would love it!

[hfiref0x]

Btw, current PH seems also has a security flaws, as reported by crowdstrike, however inventing into this method doesn't seems look practicable (it will be complicated due to over-engineered PH nature, with extensive PH exe file (2+mb size) required for driver hijack etc), PH in HVCI banlist, and finally this won't serve any practical purpose except piss-off PH authors. Tbh there are plenty of other WHQL drivers that can be abused same way with much less effort.

[mgeeky]

I agree, abusing exposed flaws doesn't bring any more value to KDU despite of purely presentational effect. I guess what you introduced so far is just enough for the provider's role.