Backdoors - The easy way
#26
Posted 05 March 2012 - 08:52 AM
Does that mean that your version 4 of your PoC can not be detected by any of the 43 Anti-Viruses?
#27
Posted 05 March 2012 - 04:36 PM
#28
Posted 05 March 2012 - 05:42 PM
A good question being HOW the HECK they managed to get listed between the 43?Antiy-AVL
.....
Certainly retarded yes!!
http://blog.hispasec.com/virustotal/42
I mean Antiy-AVL WHO?
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.
Maybe it has a wide diffusion in it's country of origin (China)?
Wonko
#29
Posted 05 March 2012 - 06:23 PM
#30
Posted 07 March 2012 - 10:26 PM
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
Posted 10 March 2012 - 01:33 PM
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
Posted 11 March 2012 - 11:28 PM
(my current testmachine is Windows 7 x64), btw going slightly OT now..
#33
Posted 14 March 2012 - 10:23 PM
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
Posted 15 March 2012 - 07:08 AM
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
Posted 15 March 2012 - 05:02 PM
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.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.
#36
Posted 15 March 2012 - 05:11 PM
#37
Posted 15 March 2012 - 05:28 PM
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.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?
#38
Posted 16 September 2012 - 10:20 PM
(The PoC is in itself not malicious, as it is a reverse shell connecting to localhost)
#39
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
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
Posted 19 April 2013 - 05:14 AM
hello,
i'm new here. just to ask what is PoC? ...
#42
Posted 19 April 2013 - 08:40 AM
hello,
i'm new here. just to ask what is PoC? ...
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.
Wonko
Also tagged with one or more of these keywords: backdoor, malware, infection, metasploit, warez
Groups →
Security →
Techware UninfectorStarted by Siginet , 13 Oct 2015 adwcleaner, registry, cleanup and 4 more... |
|
|
||
Groups →
Community forum →
Requests →
Your Website is compromised!!Started by revrepo , 13 Jan 2015 malware, compromised |
|
|
||
Groups →
Windows Extreme →
Windows 2K/XP/2003 →
TrueCrypt protects you against malware !Started by gid , 02 Dec 2014 truecrypt, ramdisk, ramdisk.sys and 3 more... |
|
|
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users