Skip to content

Latest commit

 

History

History
176 lines (127 loc) · 13.6 KB

README.md

File metadata and controls

176 lines (127 loc) · 13.6 KB
Raw

DareDevil

A stealthy Loader-cum-dropper/stage-1/stager targeting Windows10 (FUD till now, according to antiscan.me)

Technology behind Insider:

Insider

Ability:

Apart from the above shown diagram other abilties are:

  1. Sensitive string Obfuscation using Environmental Keying TTP ID: T1480.00. I became aware of this concept from SANS Offensive WorkShop: 'From zero to hero: Creating a reflective loader in C#' by @Jean_Maes_1994 and from FalconStrike by @winterknife.
  2. All function calls are Obfuscated using delegate, except LoadLibrary() and GetProcAddress().
    Tried using DInvoke to Obfuscate LoadLibrary() and GetProcAddress() but instead, it got detected by 5 more AV engines ;(
  3. Ability to Detect and Detach from debugger by using, NtQueryInformationProcess() and NtRemoveProcessDebug() respectively.
  4. Ability to Determine by checking whether the targeted machine is the intended/valid target machine (i.e. within the engagement contract domain) or not.

Tools: Usage

  • Obfuscator/encrypt.cs:
  1. [For shellcode extraction and encryption]: place it in the directory in which .bin file is present.
  2. [For url and string encryption]: Nothing! Just paste and run.

Example:

It can encrypt 'shellcode', 'url' and string:

// Creating .bin file and Extracting shellcode from .bin file:
// Creating: https://ivanitlearning.wordpress.com/2018/10/14/shellcoding-with-msfvenom/
// Extract: 
cmd> encrypt.exe /file:file.bin /xor_key:<usernameoftarget> /out:xor_b64

// paste the output b64 bytes into a .txt file and upload it to payload server.
// cmd: "mv .\obfuscator\"
cmd> encrypt.exe /shellcodeurl:<url> /xor_key:<usernameoftarget> /out:xor_b64

cmd> encrypt.exe /mscorliburl:<url> /xor_key:<usernameoftarget> /out:xor_b64

// For Sending/ exfiltrating Victim process name and Ids to Operator Gmail via SMTP server
cmd> encrypt.exe /remotewriteurl:<url> /xor_key:<usernameoftarget> /out:xor_b64

// For reading pid from pid.txt from payload server/ remote c2 server
cmd>  encrypt.exe /remotereadurl:<url> /xor_key:<usernameoftarget> /out:xor_b64

// Sensitive strings Obfuscation
cmd> encrypt.exe /string:<string1,string2,...,stringn> /xor_key:<usernameoftarget> /out:xor_b64
  • stage2/remotewrite.cs:
    Why I made RemoteWrite.cs?
1. If I wanted to make this loader_cum_dropper invisible (compilation: csc.exe /target:winexe /platform:x64 /out:Insider.exe  .\Insider.cs), the enumerated process name and process id, made by it, can't be seen by me.
2. I also can't create a file on disk, it will not be OPSEC safe.
3. So, I exfiltrate those enumerated process names and ids via Gmail's SMTP server, by sending a string (full of process names and process ids, all appended together).
4. After getting the gmail, the operator will choose the pid, he/she want to victimise.
5. Then he/she will create a `pid.txt` file with target pid written in it and then host it in payload server/ C2 server of his/her choice.
6. Until our loader_cum_dropper gets pid from url containing pid.txt, it will keep on retrying.
7. From there, our dropper will read those pid and perform injection.

In this way, I made un-interactive program, interactive.

1. I have used Developer Powershell/cmd for VS 2019
2. cmd> git clone https://github.com/reveng007/DareDevil
3. Compile: Obfuscator/encrypt.cs with compile.bat, stage2/remotewrite.cs with compile_remotewrite.bat (but at first write the credentials of sender's and receiver's/Operator's gmail) and stage2/mscorlib.cs with compile_mscorlib.bat.
4. Now upload/ host those two stage2 in payload server/ github(github: because it will not be considered as malicious as it is considered to be a legitimate website. So, malware traffic from github will not be considered as creepy stuff, instead of that, it would be considered as legitimate).
5. Encrypt those two urls using "Obfuscator/encrypt.exe" file with the previously mentioned flags and use those in "stage1/Insider.cs".
6. Encrypt your shellcode, by following my previously mentioned flags in "Obfuscator/encrypt.exe" section and paste the encrypted shellcode in a text file. Host it in payload server/ github. Then again encrypt that url with "Obfuscator/encrypt.exe" and paste that in "stage1/Insider.cs".
7. Now, compile the "stage1/Insider.cs" with compile.bat and put it in an antivirus enabled windows 10 and test it.

NOTE:

I have named AMSI&ETW bypass .NET Assembly as "mscorlib" because if by chance, it is seen by a Blue Teamer and if that particular member is less experienced, the name "mscorlib" can bamboozle, making them think, "Hey, yes!! a .NET binary always loads up something called, mscorlib. It contains the core implementation of the .NET framework." Though there is a very little chance of our "mscorlib.exe" of getting caught running as a process in memory, as it is visible only a very little amount of time (probably in ms) in our dropper process memory, unless our dropper is getting debugged ;(.
BTW, this bamboozle thing was also told by Jean Maes 😄.

Ability to recognise target by checking username in the form of xor key:

As discussed before in Ability section, utilizing environmental keying factor, I hardcoded a test string encrypted with xor key (username of target) and then decrypted the teststring using the username of the target machine retrieved in run time, then compared the decrypted text with the original one. If the condition is true then, our dropper is allowed to run else it turns off.

image

Video:

DareDevil_in_action.mp4

Internal Noticing:

ProcessHacker (only):

No_RX_from_outside.mp4

I saw that even after providing Read-Execute permission to the allocated shellcode memory region, it wasn't shown as RX in ProcessHacker. Strangely enough, the bool value for VirtualProtectEx was also True while protecting target process memory with 0x20 PAGE_EXECUTE_READ. I think this is happening because we applied page RW memory protection with VirtualAllocEx(). Then before creating the remote thread, we are allocating RX memory protection with VirtualProtectEx(). Not that sure of. If anybody seeing this, know about this, please correct me ;(

Moneta:

But with moneta, we can see it.

moneta

But without knowing the actual address, it is not getting shown by Process Hacker. It is only not be visible from outside. It can bypass BlueTeam, until the BlueTeamer isn't aware of this particular process memory address.

processHacker

Floss:

Yes, encrypted strings are getting tracked by Floss but that doesn't matter as long as they don't have the xor key (for decryption ofc!), which they don't. I am able to bypass more or less all sensitive strings except, Kernel32.dll as it is getting used by unobfuscated function call named, LoadLibrary() and GetProcAddress(). Other strings which caught my eyes were, PROCESS_BASIC_INFORMATION and PROCESSSINFOCLASS, but I don't really think those things matter. But if those do, please do correct me.
As again, I'm learning :)

WireShark Capture:

SMTP_wireshark

We can see that the text(process infos) sent out are all encrypted by Gmail's TLS encryption. On top of that, the ip address (marked) isn't suspicious at all, or in other words are OPSEC safe.

MailServer_iplookup

Quick Scan:

  1. Using @matterpreter's DefenderCheck

image

  1. Using Antiscan.me:

Yupp! A clean sheet! After a long period of TrialnError
I did it...
Eset NOD32!
No matter what I do, this was flagging me 😟.

When I commented out Loader code part, I got this: loader
When I commented out Dropper code part, I got this: dropper
When I used the whole binary, I got the above detection stats same as loader portion 🥴.
According to mathematics, I should have got 4 detections, why one ? and why that particular AV only?
I was really not getting it.
But when I used Environmental keying, for some reason or other I bypassed their stored signatures 😄!

UPDATE: I found out that in the case of Evasion of Signatured Based AV, concept of normal mathematics fails. In here, to De-Signature signaturized malicious pattern, we have to change the Entropy of the already signatured malicious pattern. De-signaturization does not work like normal addition and substraction.

To-Do list 👨‍🔧:

  1. Try using DInvoke to Obfuscate LoadLibrary() and GetProcAddress() WinApi, taking reference from SharpSploit, to hide them from getting detected from static analysis. [Change the name of the functions taken from SharpSploit project]
  2. Adding PPID Spoofing
  3. Adding other Process Injection Types into it.
  4. Try Creating a shellcode/PIC blob, which talks to server via smtp, imap, or other protocols which are not that much highlighted as suspicious IOC, like socket creation alert!

NOTE:

  1. If anyone viewing this find out something wrong or if you think, I haven't credited your or work of someone else, please contact me via my socials. I didn't intensionally mean to do that but sometimes I simply forget, sorry! 😅

  2. Please don't submit the samples to VirusTotal 😢

DISCLAIMER: This Project Only performs Signature based Evasion. Heuristics and behaviourial based Detection evasion is not Implemented in this Project.

Resources and Credits:

  1. I learned Reflective loader implementation from watching the SANS Offensive WorkShop: 'From zero to hero: Creating a reflective loader in C#' by @Jean_Maes_1994. Also thanks to him, for answering my questions in DM, so patiently 😄!
  2. Other basics and offensive side of C# by following offensive tradecraft basics from DEFCON 29 Adversary Village: 'Tradecraft Development in Adversary Simulations` by @fozavci.
  3. PInvoke:
  4. delegate: YT:Tech69. He is also a amaizing dude!
  5. Obviously, the infamous RTO:MalwareDevelopmentEssentials course by @SEKTOR7net.
  6. @winterknife: For clearly making me understand the difference between stage-0, stage-1, stage-2, stage-3, etc payloads.
  7. Took reference from FalconStrike by @winterknife.
  8. @SoumyadeepBas12: For helping me out when I got stuck doing this project 👍.

Author: @reveng007 (Soumyanil Biswas)