Add AutoVerifySessionTimeout Meterpreter advanced option #5547
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the addition of the
AutoVerifySession
setting in MSF users can control whether they want session validation to be enabled or not. This means that MSF will make sure the shell is responsive within a "reasonable" period of time, and if not, shut down the session. This prevents users from having "dead shells" and not knowing what to do with them.This PR adds another setting called
AutoVerifySessionTimeout
, which allows the user to control the period of time that those validation messages have before the session is marked as invalid, and then closed. The original value, hidden behind the scenes in code, was10
seconds. This is left as the default value. Users can modify this value in environments where latency is higher, forcing the framework to give the shell a better opportunity to get established before marking it as invalid.This PR should fix #5534.
Verification
use multi/handler
set payload
to any Meterpreter payloadAutoVerifySessionTimeout
value is present in the advanced optionsIt'd be nice to simulate a high latency environment somewhere prior to landing this so you can see it fail in one case, modify the timeout, and see it work in the second case. @sweetsoftware it'd be nice if you could also have a look at this branch to see if it helps your situation. Thanks!