What is causing my computer to BSOD at random times?

Hello vivs_lunchtime,

I agree that there is nothing more that we can do to help the people who have been impacted by this problem. All sorts of other malware may have entered the systems via the same door that let this kernel mode malware in. Running a full scan of whatever anti-malware software that is in use might be a useful thing to do.

If a larger dump type was available, then I would be interested in looking at it but the results of that (if any) would not be of any practical use - the best that I could hope for would be some solid information to report to Microsoft or other anti-malware vendors (or perhaps identify the code as being a known malware type).

Gary

Very strange indeed. And these both outputs are really from the same system? Wow, polymorphic code?

The list of crimes is now:

* nonpaged rwx heap kernelmode shellcode, caught in flagranti.

* Trying to remove CR0 Write Protection (in said shellcode), caught in flagranti.

* Code modification of MS core kernel driver, caught in flagranti by patchguard patrol.

* polymorphic shellcode, caught in flagranti.

How much more evil to look for until admitting it's plain evil?

It looks like a kernelmode rootkit, it behaves like a kernelmode rootkits, then perhaps let's call it a rootkit. Motivation is unknown.

With an automatic kernelmode dump, we could also locate it. (I guess that's the end of story.)

I think there isn't much more we can scrape from the minidumps.
And me would call this thing "evil" by now. ;-)

Hello vivs_lunchtime,

Some things suggest that the malware is poor quality (e.g. not checking CR4.CET before trying to modify CR0.WP, not disabling PatchGuard), but other things suggest that it is of better quality (not detected by malware defence software (as far as we know), appears to be polymorphic (see below)).

Here are code extracts from two crashes on the same system (with the first few differences highlighted):

mov r12,cr0

mov rax,r12

btr rax,10h

mov cr0,rax

mov r9d,dword ptr [rdi+0AA0h]

lea r8,[rdi+0AA8h]

shl r9,4

xor r10d,r10d

add r9,r8

mov rdx,r9

cmp dword ptr [rdi+0AA4h],r10d

jbe ffffd10b`64b1cace

lea r13d,[r10+1]

mov rcx,qword ptr [rdx]

mov rax,qword ptr [rdx+8]

mov qword ptr [rcx],rax

mov rcx,cr4

test rcx,20080h

je ffffd10b`64b1cab0

mov rax,rcx

btc rax,7

mov cr4,rax

mov cr4,rcx

jmp ffffd10b`64b1cab6

mov r12,cr0

mov rax,r12

btr rax,10h

mov cr0,rax

mov eax,dword ptr [r9+0AA0h]

lea r14,[r9+0AA8h]

shl rax,4

lea r10,[r9+0AA8h]

add r14,rax

mov r8d,r11d

mov rdx,r14

cmp dword ptr [r9+0AA4h],r11d

jbe ffffcc8f`a6a8f08e

mov r11d,1

lea r13d,[r11+0Fh]

mov rcx,qword ptr [rdx]

mov rax,qword ptr [rdx+8]

mov qword ptr [rcx],rax

mov rcx,cr4

test rcx,20080h

je ffffcc8f`a6a8f06f

mov rax,rcx

btc rax,7

mov cr4,rax

mov cr4,rcx

jmp ffffcc8f`a6a8f075

If anyone has this problem then their system is compromised - a complete reinstall from reliable sources might be the only option.

Gary

The CRITICAL_STRUCTURE_CORRUPTION bsods have a different cause.

Something (that's a fact) successfully edited critical kernel structures with success in these, which eventually, after non-deterministic (usually long) time, was randomly detected by a patchguard patrol in both CRITICAL_STRUCTURE_CORRUPTION minidumps. (In contrast to modifying non-guarded structures, which would remain undetected, we would never learn about that.)

Technically, this is a security breach. :-D CRITICAL_STRUCTURE_CORRUPTION is essentially a patchguard alarm, which technically is a security breach. I didn't realize this yet, I just thought of the limited practical use.

@edit: it was type 1 code modification, not pdata. That's an interesting turn.

With the type 1 modification patchguard alert, (which indicates pdata *or* code modification), I earlier thought I could safely exclude type code modification, since the cr0 manipulating shellcode failed, ...so I thought. I was wrong.

The patchguard alert is about ndis!ndisOidPreAddWakeUpPattern, because the read-only rx data has been changed right in the middle, beginning in one dump at precisely

ndis!ndisOidPreAddWakeUpPattern+0x6b (relative syntax)

That means it had another and working method at disposal (und used it) to remove the read-only protection. You cannot write to read-only code unless you removed the read-protection successfully before.

The BSODs with critical corruption are late-stage type 1 patchguard alert, code modification, reason unknown. (Ok, but I will really stop here with analysis, sorry.)

No idea to get the thing in flagranti. I don't think I can further help for now, thanks to shellcode.

@edit: don't get too much paranoia, even if it's technically a security breach, chances are that it's just very poorly written software resorting to ring0 code in extremely inproper way.

And to the person suffering from BSODs, if you can manage turning on Core Isolation Memory Integrity in control panel applet you will get rid of the shellcode (entirely), but only if you survive. Normally turning on Core Isolation is harmless, but now it isn't since something producing rwx kernelmode shellcode is lurking.