This should not happen, aborting... about edrsandblast HOT 9 CLOSED

Hi!

No need to apologize for having a life 😄

When you tried with the —internet option, did you left the CSV file in the current directory? If so, pdb file is not downloaded and parsed, if I’m not mistaken.

Can you share the hash of your ntoskrnl file (or the file itself) so we can check on our side what’s wrong ? Maybe we’ll need to open a ticket at Microsoft, who knows 🙃

Cheers

from edrsandblast.

This a fail-safe mechanism to prevent reading, through the driver exploit primitive, at an address that is not in the kernel address space. Here it seems that the offset (0xc8) for the _OBJECT_TYPE's CallbackList is (likely) correct but the kernel base address was not successfully retrieved.

Could you please share here the full verbose output of an execution in audit + kernelmode mode (EDRSandblast.exe audit -v --kernelmode) so that we could validate that it is indeed the case?
With the name of the drivers redacted if needs be, only the offsets and actual NotifyRoutine addresses would be important.

from edrsandblast.

It actually seems that the value read at the PsProcessType offset is NULL, then added to 0xc8. It’s weird, except if the PsProcessType offset is wrong.

Did you use a CSV generated with the python script or did you use the --internet option ? By any chance, did you left an outdated ntoskrnl.pdb file in the current directory before execution ? (we have a patch for that case ready to be pushed upstream, by the way)

Thanks in advance for your answers

from edrsandblast.

Sorry for the late reply. Life issues over the weekend. :)

I get the same error message on two different EDR systems. On both systems, I actually extracted the offset by using the extract script on the actual ntoskrnl.exe file. I also ran it with the --internet option. Both ways identify the ntoskrnl.exe file as 19041-2251, but both host OS report the build as 10.0.19045.2251.

from edrsandblast.

I went back and looked and yes, I left the CSV file in the directory. I ran it again from a new folder and I get the same result. Attached is the ntoskrnl file.

ntoskrnl.zip

from edrsandblast.

I cannot explain it for the moment, but it would seem that the difference between the version printed in the "about Windows" window and the version number embedded in the ntoskrnl.exe file is normal, I get the same thing on my side :

I just checked, the offset of PsProcessType printed on your last screenshot is correct regarding the ntoskrnl.exe file you sent.

I don't know how Windows updates actually work, but I am wondering if the running kernel and the C:\windows\system32\ntoskrnl.exe file could at some point be different for this reason. Have you tried to turn it (the computer) off and on again ? :D

from edrsandblast.

Maybe you can check your AV software. I also have this problem. I took almost half day try to find whats wrong with the ReadKernelMemory and ReadMemory Functions.
at last, When I Uninstall my Kaspersky. Everything is Fine...
So, I think maybe when there is someting to protectd the kernel memory, and it'll cause this problem

from edrsandblast.

Hi !
This should be fixed by 4d414ed, do not hesitate to tell us if there still is a problem.

Cheers

from edrsandblast.

See #15 (comment) for explaination

from edrsandblast.