Last assessment I was on I was on the "remote" end of the shell. We had people in another state doing the on site and sending shells back so we could simulate remote and local attackers.
interesting things come up when you have people looking for your outbound shell, mostly WTF do you do when your connect back domain name is poisoned or your IP blocked and how do you hide that traffic. maybe in some cases that 3am hack sessions ISNT a good idea better to blend in with that morning checking email traffic.
at BH D.C. Sinan Eren gave his IO Immunity Style talk, it was a good talk and interesting considering they were able to take all the time they needed and 0day was ok. But most importantly was their backdoor PINK. PINK help solve some of the C&C problems with botnets or even backdoors, namely how do I keep tabs on the boxes even though i dont necessarily want them to do anything. PINK had a pretty cool way of doing that where you put commands on a blog (signed and encrypted...booyah) and the backdoor would go out and query that page for what to do next, pretty cool way of doing it. It would also wait and only do those queries if there was activity on the box i dont remember if it was network activity or just keyboard/mouse activity either way it was a good idea. only sending web traffic when someone was actually logged in is definitely a better way to blend in.
Tom Liston also talked about some malware at last year's ChicagoCon that would query some website and get its command from comments in the HTML code, again pretty slick.
so what's the point, i guess the point is cover your ass and have multiple ways of keeping that communication going or really know your target's monitoring capabilities to see what method will best keep your shell.
useful links:
http://ha.ckers.org/blog/20080127/process-doubling/
not so much the post but the comments are good
http://www.immunityinc.com/downloads/BeyondFastFlux.odp
mention's PINK
http://www.blackhat.com/presentations/
IO Immunityinc style talk
2 comments:
Couple other issues to mention. What happens when SSL gets protocol checked on the way out and when they start proxying 443. Many current RAT's...at least the ones I've used on the teams I've been on and many commercial ones are not proxy aware. So problem is not getting the RAT there but getting that little guy to call out to you, 80 already proxied so can't use that channel without a smarter RAT. 443 inspected so can't encrypt data inside 443 headers cus of protocol mis-match, when 443 proxy gets implemented...again need smarter RAT to be able to utilize that proxy. So if proxy is set for users in the browser and can't be changed without AD creds due to GPO, you need a RAT that can use that channel somehow. Anyway reading some of these "pentesting" blogs and such like the ones you talked about on insecure.org, it seems like commercial side guys have it much easier. Guys just sending trojan emails etc. and everything is allowed outbound...dang sounds easy. Blah, Blah, Blah I'm guess I'm just salty cus I did not learn how to write proxy aware SSL Remote Access Trojans in my CEH class :)
good points on the proxy recognition and usage and yes the .com guys have it easier right now
Post a Comment