Revision indexing in progress... (symbol navigation in revisions will be accurate after indexed)
Total 1 files
■ ■ ■ ■ ■ ■ ■
README.md
skipped 24 lines
25
25
1. Read shellcode's contents from file.
26
26
2. Acquire all the necessary function pointers from `dbghelp.dll`, call `SymInitialize`
27
27
3. Hook `kernel32!Sleep` pointing back to our callback.
28
-
4. Inject and launch shellcode via `VirtualAlloc` + `memcpy` + `CreateThread`
28
+
4. Inject and launch shellcode via `VirtualAlloc` + `memcpy` + `CreateThread`.Aslighttwisthereisthatourthreadstartsfromalegitimate`ntdll!RltUserThreadStart+0x21`addresstomimicotherthreads
29
29
5. As soon as Beacon attempts to sleep, our `MySleep` callback gets invoked.
30
30
6. Stack Spoofing begins.
31
31
7. Firstly we walk call stack of our current thread, utilising `ntdll!RtlCaptureContext` and `dbghelp!StackWalk64`
skipped 33 lines
65
65
This in turn, when thread stack spoofing is enabled:
66
66
67
67
68
+
69
+
Above we can see a sequence of `kernel32!CreateFileW` being implanted as return addresses. That's merely an example proving that we can manipulate return addresses.
70
+
To better enhance quality of this call stack, one could prepare a list of addresses and then use them while picking subsequent frames for overwriting.
71
+
72
+
For example, a following chain of addresses could be used:
73
+
74
+
```
75
+
KernelBase.dll!WaitForSingleObjectEx+0x8e
76
+
KernelBase.dll!WaitForSingleObject+0x52
77
+
kernel32!BaseThreadInitThunk+0x14
78
+
ntdll!RtlUserThreadStart+0x21
79
+
```
80
+
81
+
When thinking about AVs, EDRs and other automated scanners - we don't need to care about how much legitimate our thread's call stack look, since these scanners only care whether a frame points back to a `SEC_IMAGE` memory pages, meaning it was a legitimate DLL/EXE call (and whether these DLLs are trusted/signed themselves). Thus, we don't need to bother that much about these chain of `CreateFileW` frames.
Mariusz B. / mgeeky
committed
3 years ago
1 parent 8433c026