I am wondering if there is a way to detect if a reverse shell is blocked by egress filtering or an obligatory proxy, or the exploit just failed.
I am asking this question in the context of a SE media dropping senario.
1
-
1Heh. Answered this question, then realized that you were probably talking about THEIR firewall... I'm smart, I swear...– KnightOfNiCommented Mar 13, 2014 at 0:32
Add a comment
|
2 Answers
There's no way to tell directly from that actual test, there's no enough information. However, you could tell whether the exploit works or not by telling the target system to do something that it is allowed to do, for instance browse to a web server under your control (presuming that any outbound web connectivity is allowed). If you command it to get a webpage and you get a hit on our site, the exploit works, and then you know that the shell command isn't working for some reason.
-
@David Just to make this a bit more clear, (at least, here's what I thought of, and this answer seems very similar) you want to change the payload from the reverse handler to something that you will recognize, but won't set off AV (a good example would be visiting a webpage, which you could easily detect via a tool like Wireshark). Commented Mar 13, 2014 at 0:35
As an addition to GdD's answer, have the "payload" try several things, since you'd have no idea about finding out if your code / exploit was actually executed. A range of things could be one of the following:
- fetch a webpage using the system's browser settings' proxy
- send an email to an outside address.
If you have nearby access to the infected computer starting bluetooth and enabling visibility or setting up a WiFi peer to peer network may help. If you'd have visual access to the machine, something simple as changing a screensaver could indicate exploit success.
Usually corporations have egress filtering enabled, so having a shell break out and access an arbitrary port may not work that well.
