Ensure Windows x64 Meterpreter HTTP/S Payloads Include the User Agent Header

[pczinser]

This code addresses an issue in the Windows x64 meterpreter staged reverse http, and by extension https, payload. These payloads do not make use of the HttpUserAgent option when it makes it's request to a listener e.g msf's exploit multi/handler. I have put a simple check in the inline assembly to include the User Agent if it is set. There is a default user agent for the payload so the default behavior of this payload will be to make requests with a user agent of Mozilla/5.0 (Windows NT 10 .0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0 if no User Agent is desired simply set HttpUserAgent "" and the payload will not include a User Agent.

I encountered this issue organically but it seems to have been identified in #15886

Verification

List the steps needed to make sure this thing works

• Start msfconsole
• use payload/windows/x64/meterpreter/reverse_http
• set LHOST 127.0.0.1
• set LPORT 8080
• set HttpUserAgent verified123
• generate -f exe -o payload.exe
• if applicable, copy payload to a windows target
• launch Burp suite and ensure the proxy is listening on 127.0.0.1:8080 and is configured to forward to 127.0.0.1:8081 (don't actually need anything listening)
• ensure Burp is intercepting requests
• execute the payload
• observe a GET request with the the user agent header set properly 'User Agent: verified123'

below are some screenshots of my testing,

current behavior:

fixed behavior:

[msutovsky-r7]

Thanks pczinser! From initial look, everything seems okay. Not sure why reverse_http is not the same for x86 and x64. I'll check bit further to see if some issue will not arrive, otherwise will close PR today.

[msutovsky-r7]

Removed default behavior of setting lpszAgent to 0x00, setting lpszAgent based on HTTPUserAgent parameter from payload module

[msutovsky-r7]

Release Notes

The reverse HTTP and HTTPS Meterpreter x64 payloads now correctly set the User-Agent HTTP header when connecting back to Metasploit. Before this fix, the HttpUserAgent option was not used properly. You can now use this option to customize the User-Agent HTTP header when using these payloads