Enabling mimicking the client's user agent

[pyrohaz4good]

This is in reference to closed PR #4984 and Issue #4933 that I'm now re-working after code churn in that area. Although a new common list of UAs has been added, it doesn't really address the issue. Disclaimer: this is the first time I'm adding a new feature (and hopefully the first PR I land!).

Bottom line:
User-agent monitoring can be used to detect unwanted egress connections from within a network, which can bugger your otherwise well planned red team engagement. The feature I want to add adds a new listener response that echos back to the client their user agent. There's no way to reliably determine the client's user agent on its local machine, so the approach I took was for the payload (which I've incorporated into Veil) to first launch a hidden IE window, browse to the /echoua URI, and receive back the user agent. Then, the use that UA to stage and setup the reverse shell. That way, the communication will look more in line with the network's baseline.

My problem/question
After the refractering ( ) that was done on the reverse HTTP/S payloads, it's unclear exactly how I can implement this. Now info[:mode] is used to determine how to handle the request. I don't want to muddy this new elegant solution, but the only way I can see add this feature is to:

1. Add a new URI checksum in Rex:Payloads:Meterpreter:Uri_checksum for this echo response (for example, URI_CHECKSUM_ECHOUA) which would keep consistency in the reverse_http.rb case statement on info[:mode]. Then add a new condition that does the appropriate magic. This is nice because the checksum solution is a much more elegant and covert way to achieve this.

OR

2. Evaluate the request for '/echoua' from the client before the case statement that determines the mode, and make a decision if a UA echo response should be sent back to the client. This seems maybe less desirable as I'd be adding a new decision tree to the payload rather than using the existing case statement.

Other stuff
The rest of what needs to be changed is clear for me I believe (new/updated meterpreter options, sending the response back, getting the UA set in transport config...).

Your help / thoughts / expertise are greatly appreciated!

[OJ]

This is a tough one to come up with a reasonable answer for. I have pondered this myself. The thing is that user agents not only vary from browser to browser, but they can also be butchered by third party apps. So knowing the "true" user agent for a given client would best be determined by looking at a request actually made by the client.

That opens up a huge can of worms. Clearly it'd be possible to come up with something and implement it in Meterpreter itself, but there's no way that this can be worked into the stagers.

I'll think on it a bit more, but yeah I'm not sure how we can build this in nicely without causing other issues.

It scares me :)

[pyrohaz4good]

Bumping this thread again. Any chance for input?

[busterb]

I think there is some traction in this area lately. We certainly found some tricky scenarios overriding this with Java payloads.

[busterb]

This is now implemented via the HttpUserAgent parameter, and it's now even worked into the stagers if there is enough space. Just going through old issues and happy to see this is resolved. Thanks for the request!

[pyrohaz4good]

Hooray! You are very welcome!