Jump to content











Photo

Backdoors - The easy way

backdoor malware infection metasploit warez

  • Please log in to reply
41 replies to this topic

#26 ericgl

ericgl

    Frequent Member

  • Expert
  • 314 posts
  •  
    Israel

Posted 05 March 2012 - 08:52 AM

joakim,
Does that mean that your version 4 of your PoC can not be detected by any of the 43 Anti-Viruses?

#27 joakim

joakim

    Silver Member

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

Posted 05 March 2012 - 04:36 PM

It seems impossible to get 0/43 as long as you have an autoit compiled exe (because certain lame AV just discriminate against a product). It is no secret that Antiy-AVL is the discriminator. My PoC v4 has a detection of 1/43 because of Antiy-AVL, and the detection has no relation to the backdoor whatsoever! Take the AutoItSC.bin file from the AutoIt package. It is the script loader, that by itself is an exe does absolutely nothing. Still Antity-AVL detects it (or anything from AutoIt) as "Trojan/Win32.Chifrax.gen". It is like saying that all executables should be flagged as trojans because it is possible to make one. :poke: Certainly retarded yes!!

#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13749 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 March 2012 - 05:42 PM

Antiy-AVL
.....
Certainly retarded yes!!

A good question being HOW the HECK they managed to get listed between the 43?
http://blog.hispasec.com/virustotal/42

I mean Antiy-AVL WHO? :w00t:


In several years in the field (admittedly as a hobbyist) I NEVER saw one single PC with that AV installed to it, nor heard/read about one. :dubbio:
Maybe it has a wide diffusion in it's country of origin (China)? :unsure:

:cheers:
Wonko

#29 joakim

joakim

    Silver Member

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

Posted 05 March 2012 - 06:23 PM

I never heard of it either. According to the web page, there was an update (to their product/av definition??) in 2008..

#30 joakim

joakim

    Silver Member

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

Posted 07 March 2012 - 10:26 PM

DigSigExec; http://www.mediafire...8s9ee49qrnoyms0

This is just another PoC for how to execute payload/machinecode. This time it is with a twist so that it will ripp out and execute payloads obfuscated and hidden inside digital signatures of executables. Most of the code is actually from my DigitalSignatureTweaker. So before testing, you must hide a payload inside an Authenticode digital signature. For that you use the already mentioned tool. Now to execute it start DigSigExec, and locate the executable with the hidden data, and choose compression/encryption. Pressing "Execute code", will attempt execute the payload. Not foolproof, but good enough as a PoC.

Regarding the method of executing the code, there exist many different ones. In this particular sample, I am using a function called CreateThread which is found in kernel32.dll.
The source works on both 32-bit and 64-bit (XP - Windows 7), but needs to be compiled for the right arch in order to work.

Next time I might give a try with other known methods like;

CreateRemoteThread

CallWindowProc

NtCreateThread

RtlCreateUserThread


(for which most is known for use with dll injection)

#31 joakim

joakim

    Silver Member

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

Posted 10 March 2012 - 01:33 PM

Made another little tool called Payload2CallWindowProc; http://www.mediafire...5624160mxc6apg8

Another PoC of how to execute a binary payload (pure machinecode). This time it is about the use of CallWindowProc. It will take payload encoded with base64 as input. Supply the filepath to a base64 encoded file. Can use the included base64encoder utility for that. The raw payload before encoding can be anything. I mean, it can be obfuscated with the metasploit's encoder, like shikata_ga_nai (polymorphic) and several iterations, making the final file after base64 even harder to spot. Tested on 32-bit XP and 64-bit Windows 7.

#32 joakim

joakim

    Silver Member

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

Posted 11 March 2012 - 11:28 PM

Have been playing with CreateRemoteThread which seems to be working quite nice when called properly. Downside is the session/user separation in nt6.x which this function abide to, and that puts certain limitations on its usage. For that reason the undocumented NtCreateThreadEx can be used, which supposedly will let you create threads inside processes in session0 (LocalSystem). Then it would be interesting to create a gui for WinExec, effectively creating a cmd gui to run commands under the system account (unless I missed something).. But right now I am facing a very annoying ntstatus code 0xc0000005 (STATUS_ACCESS_VIOLATION). Anybody familiar with NtCreateThreadEx and this issue?

(my current testmachine is Windows 7 x64), btw going slightly OT now..

#33 joakim

joakim

    Silver Member

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

Posted 14 March 2012 - 10:23 PM

I did some playing with this remote thread stuff and put together something called RemoteWinExec; http://www.mediafire...wsrsdzd2qdacp5k

Posted Image

Injecting threads into processes:

In this sample I'm using the function CreateRemoteThread inside kernel32.dll. It works similarly to the function CreateThread, but works for other processes than the current/running process. Injecting a thread is almost the same as dllinjection (injecting a dll into a process), as the same technique is used. A thread by the way, can also become a process. This is done by executing the function WinExec (has been popular choice with MetaSploit payload generation). Some explanation of the procedure:
  • Create an empty structure of a given size that we will fill with data later on (in this case the size in bytes of the binary form of the commands used)
  • Get a pointer to the target PID by using the function OpenProcess.
  • Get the module handle of kernel32.dll and the the memory address of the function WinExec (GetModuleHandle and GetProcAddress).
  • Call the VirtualAllocEx function to reserve and mark a region inside the virtual address space of target process, in order to execute code there. By letting lpAddress be empty, the reserved address is dynamically generated.
  • We encode our commands to binary and put it into the structure we created in step 1.
  • Call the WriteProcessMemory function and write our code in the structure into the reserved region in the virtual address space inside target process.
  • Now that everything is set up, we call the function CreateRemoteThread which will open a remote thread. The lpStartAddress is a pointer to the address of WinExec. WinExec's parameter (the commands) are put into lpParameter, given by a pointer to the code placed where VirtualAllocEx decided to reserve memory.
  • The thread is now immediately opened and code hopefully executed.
  • Optionally clean up the memory modified with WriteProcessMemory, by calling VirtualFreeEx.
  • That's it.

If you for some reason, only wanted to execute some arbitrary machinecode instead, only minor changes are necessary. Put the machinecode into the structure. Then put the pointer to the reserved memory region into parameter lpStartAddress of CreateRemoteThread. But let lpParameter be zero as we don't have parameters. That's all.

As earler explained it is somewhat similar to use these functions this way;
CreateThread
CreateRemoteThread
CallWindowProc
NtCreateThread
RtlCreateUserThread
(and likely a few more)

Note:
NtCreateThread was introduced in nt6.x and supposedly solves the restriction on nt6.x that threads can not be started remotely across user sessions. But that function is a pain, and I'm still facing a dreaded 0xC0000005 (access violation) in my implementation, so there's some memory issues.

The included tool takes 2 parameters, PID and CmdLine. Sample command line;
"RemoteWinExec.exe 2236 "cmd /c dir c: > c:dirlisting.txt"

The tool has been successfully tested on Windows 7 x64.

Edit: I'll take this stuff and make it available in the download section too..

#34 ericgl

ericgl

    Frequent Member

  • Expert
  • 314 posts
  •  
    Israel

Posted 15 March 2012 - 07:08 AM

I'm not very savvy in this field, but your ability to do this sounds dangerous to all users.
Malicious code could be executed without being detected by any of the Anti-Virus apps out there, or Windows' DEP or Intel Execute Disable bit.

#35 joakim

joakim

    Silver Member

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

Posted 15 March 2012 - 05:02 PM

I'm not very savvy in this field, but your ability to do this sounds dangerous to all users.
Malicious code could be executed without being detected by any of the Anti-Virus apps out there, or Windows' DEP or Intel Execute Disable bit.

I don't think it's that dangerous. Of course if you have a downloaded executable, that you have run, you will always be at risk unless it is a 100% trusted executable. This was just meant to be an example of how to execute commands/programs the "alternative" way.. AV and malicious code is a discussion on its own, not necessarily in any particular relation to (remote) threads, that can of course be non-malicious too. Running programs with SYSTEM account priviliges, would only be considered bothersome if possible from a restricted account. I did not try this, but I guess it is not possible.

#36 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 15 March 2012 - 05:11 PM

I am curious about a different thing. If its so easy to hide a malicious code from AVs, why such possibility is seldom discussed, and why they still detect majority (presumable) of such code? Any dev would use similar technique to hide such code - right?

#37 joakim

joakim

    Silver Member

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

Posted 15 March 2012 - 05:28 PM

I am curious about a different thing. If its so easy to hide a malicious code from AVs, why such possibility is seldom discussed, and why they still detect majority (presumable) of such code? Any dev would use similar technique to hide such code - right?

I guess majority of malware authors don't want to discuss their tricks, because that would shorten the time until AV catch up on it, and thereby decrease the damage done by the malicious code. But a good point is of course, that no human being knows the exact extent of undetected malware worldwide, so it's impossible to say if the majority is detected as of now. At least we can say, that given todays AV, we would be able to detect something closer to the majority, if the state of malware was reversed 1 year back. I don't think it is so easy to hide such, but it's interesting to see what you can do with a little creativity. :rolleyes:

#38 joakim

joakim

    Silver Member

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

Posted 16 September 2012 - 10:20 PM

Half a year later I see that 3 engines at Virustotal (Avast, AVG, GData) detects the PoC v4 as Autoit:Injector-G or Exploit. The PoC clearly had malicious potential, so that's good... AVG's detection is just too stupid as it it is file hash based, which means you could just manipulate 1 byte anywhere in the file and thus prevent a detection. :whip: The other 2 seems to have done some more effort into their detection :clap: This is actually interesting, to see what the detection is based on, and test how resistant detection is against simpel modifications to the original.

(The PoC is in itself not malicious, as it is a reverse shell connecting to localhost)

#39 Holmes.Sherlock

Holmes.Sherlock

    Gold Member

  • Team Reboot
  • 1444 posts
  • Location:Santa Barbara, California
  •  
    United States

Posted 31 March 2013 - 06:52 PM

A good hint for them: it is not a named function that is the evilness here, it is the code inside it.. ;)

 

Means, does KIS search for a function?



#40 joakim

joakim

    Silver Member

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

Posted 31 March 2013 - 09:53 PM

Yes, at least back then when I checked it last time, they decoded the encode au3 script and checked for certain function names. Pretty retarded.



#41 grafix

grafix
  • Members
  • 1 posts
  •  
    Philippines

Posted 19 April 2013 - 05:14 AM

hello,

 

  i'm new here. just to ask what is PoC?  :cold:  ...



#42 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13749 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 April 2013 - 08:40 AM

hello,

 

  i'm new here. just to ask what is PoC?  :cold:  ...

It is an acronym for Proof of Concept, i.e. the implementation of a theory serving as a sample and demonstration that may have (or may have not) practical uses "as is" and/or represent merely a prototype with very limited use.

 

:cheers:

Wonko







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