I've done some testing recently with my BT4 R2 live CD in my home lab and checked encoding of meterpreter payloads by using several passes through one encoder or sequential passes through several encoders. I was disappointed to see that my AVG and Kaspersky picked up all encoded payloads. Google confirmed what I had found.

I did some research and found shellcodeexec which might be of help. Has anyone played around with this?

As far as I can understand, in section 3 of the "how to", the alphanumeric-encoded shellcode is uploaded to the victim PC and run with this tool. I'm confused though about how I would upload the tool and encoded shellcode post-exploitation if I can't get a meterpreter session. I wondered if it might be possible to wrap the shellcodeexec executable and encoded shellcode in another executable (maybe using something like a bat2exe utility) then have the victim browse to a website to download and run it. If this is feasible, it's mighty complicated and I just wonder if there's an easier way.

I'd be grateful for tips and guidance from experienced folks. I just wonder if the Metasploit/Meterpreter/SET folks will work upon new encoding techniques that will avoid AV.

As soon as Metasploit adds something, the AV vendors quickly create a definition for it. Here is a article that speaks to exactly what you're asking by scriptjunkie. I worked with him to create a completely undetectable payload. This will clear it up for you.

Thank you for the prompt reply. So, it seems that the AV picks up the executable the Metasploit creates, rather than the shellcode of the payload?

I'm interested in learning more about putting the shellcode into an executable. I suppose my first step would be to use C code of a Windows "Hello World" executable, ideally compile it on BT4 using gcc and run it on a variety of Windows PCs to test that the code and compilation process work. If my thought process is correct, I might have to have a long think about the second part though which is beyond me (at present) - adding some function calls to get RWX memory and run encoded shellcode. Do you think I'm on the right track? Do you have any more tips? I'm quite happy to hit google.

It strikes me though that I'd still have to work on getting the executable to be run on the victim computer. I don't know any way of uploading such an obfuscated payload or executable via Meterpreter to gain a Meterpreter session.

Finally, I saw a video of Muts running through the process of creating a code cave to hide code and bypass AV. I think it was called something like "I'll piss on your AV" (no offense intended to anyone!). He used ncx99.exe, as demonstrated in your second link.

Last edited by Ignatius on Sat Jun 11, 2011 4:36 pm, edited 1 time in total.

I'm interested in learning more about putting the shellcode into an executable. I suppose my first step would be to use C code of a Windows "Hello World" executable, ideally compile it on BT4 using gcc and run it on a variety of Windows PCs to test that the code and compilation process work. If my thought process is correct, I might have to have a long think about the second part though which is beyond me (at present) - adding some function calls to get RWX memory and run encoded shellcode. Do you think I'm on the right track? Do you have any more tips? I'm quite happy to hit google

You're on the right track. Mine is done in C++.

It strikes me though that I'd still have to work on getting the executable to be run on the victim computer. I don't know any way of uploading such an obfuscated payload or executable via Meterpreter to gain a Meterpreter session.

Yep, but social engineering isnt as hard as you think

Finally, I saw a video of Muts running through the process of creating a code cave to hide code and bypass AV. I think it was called something like "I'll piss on your AV" (no offense intended to anyone!). He used ncx99.exe, as demonstrated in your second link.

They actually incorporated that into the OSCE course... The problem with the code cave is that a lot of the AV vendors will pick up the "stub" but there are ways around that too!

Finally, I saw a video of Muts running through the process of creating a code cave to hide code and bypass AV. I think it was called something like "I'll piss on your AV" (no offense intended to anyone!). He used ncx99.exe, as demonstrated in your second link.

They actually incorporated that into the OSCE course... The problem with the code cave is that a lot of the AV vendors will pick up the "stub" but there are ways around that too!

Just use your own implementation of the code cave and the "stub", don't use exactly the same as shown during the CTP course. Also, creating a new section within an exectuable / PE file, can has it ups and downs.

Try adding your stub to already existing space within e.g., the main segment if possible, and make damn sure you change the flags to what you require as well. (If you add executable code, into a segment that does not contain executable code, you need to make that segment executable, which could have some strange outcome as well, but it can work.)

If your stub is trying to decode a segment, which does not have write permission but only read and execute, then it should not be possible either, and you will most likely get an access violation error. Easy to fix, make that segment writeable

It's a few common mistakes. Another important thing is to make sure that all instructions you overwrite, are re-introduced later on and that the stack appears to the same as it was to begin with. Better safe than sorry in the long run if you're modifying a file heavily.

If you use some sort of encryption scheme where you ship the encryption key with the file, some AV's will not detect the file until you run it, and that's where heuristic detection comes into play, which is a bit harder to bypass.

How could you bypass an AV-scanner, that looks for certain calls in memory? Fool the AV to believe it's a legit file, perhaps a Windows file. That is one way

OK, I fired up my Borland on Windows and used the code that I found here. He'd pulled some shellcode from the Windows Metasploit installation to have windows/exec run sol.exe. I compiled it and everything worked like a charm on my Windows XP. I repeated the experiment myself, pulling the shellcode for the same process from my BT4 R2 live CD. The shellcode was different but it still compiled and did what it was supposed to do.

Then I started to get smart (so I thought!) and repeated the process with windows/meterpreter/reverse_tcp. I examined the shellcode and there were two elements, one small and the other enormous. I guess that's because it's a 2-stage process? I put the first shellcode into my C++ code and it compiled fine. I ran it, but it didn't do anything. I repeated the process with the second chunk of shellcode and it didn't do anything either. I checked netstat but, needless to say, there was no mention of port 4444.

I think (hope!) I'm on the right track. I had hoped that running the shellcode in my compiled C++ code would connect to my BT R2 from where I could get a meterpreter shell, but that's eluding me at present.

Any further tips? Am I wasting my time?

EDIT: I just ran the two executables in sequence, containing the small then the massive shellcode, whilst monitoring netstat -a 1. Great, an entry looking for my BT laptop on port 4444 appeared with state = SYN_SENT! I just need to figure out how to connect to it now from my BT laptop and create a meterpreter session.

They actually incorporated that into the OSCE course... The problem with the code cave is that a lot of the AV vendors will pick up the "stub" but there are ways around that too!

Having seen what Muts did with Olly etc., it seemed a long-winded process. I see that you've thrown a bit of a tantaliser at me there ... so there are ways of preventing the stub being "caught"! I'll persist with my initial thoughts but might revisit this second idea after a bit of googling.

Thanks again for the clues!

Last edited by Ignatius on Sun Jun 12, 2011 10:34 am, edited 1 time in total.

Ignatius wrote:OK, I fired up my Borland on Windows and used the code that I found here. He'd pulled some shellcode from the Windows Metasploit installation to have windows/exec run sol.exe. I compiled it and everything worked like a charm on my Windows XP. I repeated the experiment myself, pulling the shellcode for the same process from my BT4 R2 live CD. The shellcode was different but it still compiled and did what it was supposed to do.

The reason why the Metasploit shellcode was different, is because it is frequently updated and therefore, from version 3.0 to 3.4 and so forth, the shellcode differs. As time goes, more bypassing techniques / methods are implemented into the payloads, so they are up to date and usable.

It also depends on what kind of payload you're using. Check out Metasploit Unleashed on the Offensive Security website. There's a good amount of information, where some should describe the different types of payloads as well.

Ignatius wrote:Then I started to get smart (so I thought!) and repeated the process with windows/meterpreter/reverse_tcp. I examined the shellcode and there were two elements, one small and the other enormous. I guess that's because it's a 2-stage process? I put the first shellcode into my C++ code and it compiled fine. I ran it, but it didn't do anything. I repeated the process with the second chunk of shellcode and it didn't do anything either. I checked netstat but, needless to say, there was no mention of port 4444.

When there's 2 parts of the shellcode, it's a 2-stage payload. The first stage is meant to be executed on the target computer. The 2nd stage is meant to be sent from your computer, as soon as the target computer requests it.

If it's a 2-staged shellcode, make sure as cd1zz said, to use the multi/handler.

Metasploit> use multi/handlerMetasploit> set payload YOURPAYLOADMetasploit> set lport LISTENINGPORTMetasploit> run

Especially the "LISTENINGPORT" is important to set. If your listening port is below 1024 on Linux, and you're not running Metasploit as root, then the listening process will fail as you will need root privileges to bind to (listen on) a port lower than 1024.

cd1zz wrote:If you're using a reverse_tcp, make sure you have your multi handler setup correctly on your bt box....

I'm grateful for your further guidance. I did some experimenting yesterday and post my results:

@MaXe: I'm grateful for your help. I spent most of yesterday playing around because, when I'd seen the SYN_SENT from my victim, I knew I had to do something in my BT to accept the incoming connection. My reading eventually led me to the solution that you'd posted. It was reassuring to see that I'd done it correctly, rather than fudge some solution that just happened to work! My persistence was rewarded with a meterpreter session.

@Both: My next challenge over then next day or two is to amalgamate the two chunks of shellcode into one executable. I figure have it run shellcode(1) then pause for 1000ms before executing shellcode(2). It wouldn't be easy to get someone to launch the two compiled executables in quick succession

Another thing that I noticed is when I tried to create a persistent meterpreter (using metsvc), the AV on my victim PC whinged. I think I've seen that the source code is on Alexander Sotirov's site so I'll have take a look to see if there's anything I can change to alter the signature, but not result in it becoming ineffective. I'll also look into other ways of creating persistence.

It's been an interesting weekend that's made me want to learn more and that's down to you, having prodded me in the right direction rather than saying "don't waste my time, go away and hit google"!

Ignatius wrote:I'm grateful for your further guidance. I did some experimenting yesterday and post my results:

@MaXe: I'm grateful for your help. I spent most of yesterday playing around because, when I'd seen the SYN_SENT from my victim, I knew I had to do something in my BT to accept the incoming connection. My reading eventually led me to the solution that you'd posted. It was reassuring to see that I'd done it correctly, rather than fudge some solution that just happened to work! My persistence was rewarded with a meterpreter session.

@Both: My next challenge over then next day or two is to amalgamate the two chunks of shellcode into one executable. I figure have it run shellcode(1) then pause for 1000ms before executing shellcode(2). It wouldn't be easy to get someone to launch the two compiled executables in quick succession

There should be single-staged Payloads available within Metasploit, which doesn't need additional shellcode to be sent to the target machine, from the attacking machine. There's also a cool "xbackdoor", which you may want to play with: http://www.ja-psi.fr/tools/xbackdoor/

I haven't really used it, but the concept behind it simply awesome in my humble opinion. Even though it doesn't seem cross-platform compatible, and to some even "outdated".

That's interesting reading, MaXe, thank you. I'll have a look into this a little later this week. I'll also check out other material on the forum to which you linked me.

I'm also looking into the possibility of a bespoke encoder for the code that Metasploit churns out. I know that they exist (one was mentioned in a post somewhere here) but I suppose the best solution would be to code one myself, probably by tweaking someone else's code.

Hey, that's brilliant - thank you. I have minimal experience with Python and had never heard of PyInstaller. I guess I have my project for later this week.

If my understanding of Dave's post is correct, it will create an executable that I must SE to have run at the other end. I realise that there are a few options for what I do at my end. I've been thinking laterally and wouldn't it be great if the executable could be used as a payload following use of an exploit against the OS or an application? I saw a script that looked like it might be useful for this. I haven't been able to fire up my lab for a few days and just did the research from my mobile between other things (non-IT!) that I've been doing.

That is one way to use it but his tool SET has a payload called the SET Interactive Shell that uses this. He's already built all the SE tools to make this all work nicely. It's very slick and if you have never played with SET go get a copy at secmaniac.com

I see that SET v1.5 has been released today. I managed to follow the instructions in his previous post. The file was, indeed, massive (>3MB) but I realise that there's a facility in PyInstaller to pack it.