Worth adding old ProcessHacker driver as provider?
mgeeky opened this issue · 9 comments
Hi hfiref0x!
Ever considered adding support for an old ProcessHacker driver and repurposing it as a provider?
https://github.com/RedSection/OffensivePH
Or its way to long shot?
Regards,
M.
// 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.
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?
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.
Ah, fair enough - didn't look at source code more closely. If that's the case - I'm good to close that issue.
Thanks!
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.
would love it!
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.
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.