So many calculations…
1. A BOF a day, keeps the doctor away
This blogpost is a collection of some of my findings when I tested Interceptor against various EDR/AV products this week. It also covers some bugfixes and design issues I encountered during my tests. But first, let me recall my previous post and quickly showcase the Intercept Beacon Object File (BOF).
The Intercept BOF is a full conversion of the original InterceptCLI client, enhanced with direct syscalls and integrated in my CobaltWhispers framework.
2. Testing against Kaspersky Anti-Virus
Due to configuration issues with Wazuh and Comodo, I moved on to testing against Kaspersky Anti-Virus and Microsoft Defender ATP. My main testing goal is the Interceptor driver itself and its ability to hinder the EDR/AV. The method of delivering and installing the driver is less relevant.
Initially, after patching all the callbacks associated with Kaspersky AV, my EarlyBird injector spawned process would crash resulting in no Beacon callback. The cause of the crash is klflt.sys, which I assume is Kaspersky’s filesystem minifilter or at least part of it. I haven’t pinpointed the exact reason of the crash, but I suspect it is related to handle access rights.
When restoring klflt.sys callbacks, EarlyBird is executed and Beacon calls back successfully, however after a notable delay, Beacon is detected and removed. Apart from detection upon execution, my EarlyBird injector is also flagged when scanned. I’ve used the same compiled version of my injector for several weeks against several different vendors, combined with other monitoring software like ProcessHacker2, it’s possible samples have been submitted and analyzed by different sandboxes.
In an attempt to get around klflt.sys, I decided to try a different injection approach and stick to my own process.
void main()
{
const unsigned char shellcode[] = "";
PVOID shellcode_exec = VirtualAlloc(0, sizeof shellcode, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
RtlCopyMemory(shellcode_exec, shellcode, sizeof shellcode);
DWORD threadID;
HANDLE hThread = CreateThread(NULL, 0, (PTHREAD_START_ROUTINE)shellcode_exec, NULL, 0, &threadID);
WaitForSingleObject(hThread, INFINITE);
}
These 6 lines of primitive shellcode injection were successfull in bypassing klflt.sys and executing Beacon.
3. Rookie mistakes
When I started my tests against ATP, the first thing that happened wasn’t alarms and sirens going off, it was a good old bluescreen. During my kernel callbacks patching journey, I never considered the possibility of faulty offset calculations. The code responsible for calculating offsets just happily adds up the addresses with the located offset and returns the result without any verification. This had worked fine on my Windows 10 build 19042 test machine, but failed on the ATP machine which is a Windows 10 build 18362.
for (ULONG64 instructionAddr = funcAddr; instructionAddr < funcAddr + 0xff; instructionAddr++) {
if (*(PUCHAR)instructionAddr == OPCODE_LEA_R13_1[g_WindowsIndex] &&
*(PUCHAR)(instructionAddr + 1) == OPCODE_LEA_R13_2[g_WindowsIndex] &&
*(PUCHAR)(instructionAddr + 2) == OPCODE_LEA_R13_3[g_WindowsIndex]) {
OffsetAddr = 0;
memcpy(&OffsetAddr, (PUCHAR)(instructionAddr + 3), 4);
return OffsetAddr + 7 + instructionAddr;
}
}
If we look at the kernel base address 0xfffff807'81400000, we can expect the address of the kernel callback arrays to be in the same range as the first 8 most significant bits (0xfffff807).
However, comparing the debug output to the expected address, we can note that the return address (callback array address) 0xfffff808'81903ba0 differs from the expected return address 0xfffff807'81903ba0 by a value of 0x100000000 or compared to the kernel base address 0x100503ba0. The 8 most significant bits don’t match up.
The calculated offset we’re working with in this case is 0xffdab4f7. Following the original code, we add 0xffdab4f7 + 0x7 + 0xfffff80781b586a2 which yields the callback array address. This is where the issue resides. OffsetAddr is a ULONG64, in other words “unsigned long long” which comes down to 0x00000000'00000000 when initialized to 0; When the memcpy() instruction copies over the offset address bytes, the result becomes 0x00000000'ffdab4f7. To quickly solve this problem, I changed OffsetAddr to a LONG and added a function to verify the address calculation against the kernel base address.
ULONG64 VerifyOffsets(LONG OffsetAddr, ULONG64 InstructionAddr) {
ULONG64 ReturnAddr = OffsetAddr + 7 + InstructionAddr;
ULONG64 KernelBaseAddr = GetKernelBaseAddress();
if (KernelBaseAddr != 0) {
if (ReturnAddr - KernelBaseAddr > 0x1000000) {
KdPrint((DRIVER_PREFIX "Mismatch between kernel base address and expected return address: %llx\n", ReturnAddr - KernelBaseAddr));
return 0;
}
return ReturnAddr;
}
else {
KdPrint((DRIVER_PREFIX "Unable to get kernel base address\n"));
return 0;
}
}
4. Conclusion
Thus far, I’ve been semi-successful in bypassing two consumer Anti-Virus products. In my final week I hope to continue my tests with success against Microsoft Defender ATP. Apart from the offset calculation bug, I also addressed an issue with post object process and thread callbacks not being patched and an issue with vendor data being transfered between driver and client resulting in more bluescreens.