NtlmrelayX Multirelay inconsistent behavior/issues

[alexisbalbachan]

Configuration

impacket version: 0.11.0 Python version: 3.11.4 Target OS: Kali Linux 2023.3

Behavior Description

• When multirelay is disabled the target selection mechanism is pretty straightforward:

  • The relay keeps a global list of target candidates (which initially contains all the targets specified in the target file).
  • When a client connects to the corresponding relay server, a candidate will be retrieved (and removed) from the list.
  • If the relay was successful for that target, said target will be stored in another list (finishedAttacks), otherwise nothing else happens.
  • If at any point the candidate list ends up empty that list will be re-populated with any of the targets that weren't successful.
  • In short: Single target relay will cycle through every non-successful target, one for each client connection.

• Multirelay behavior is different depending on the relay server:

  • On SMB (relaying to any protocol):
    • If every relay attempt is successful: When a client connects, the entire target list will be consumed.
    • If any of the relay attempts fail for whatever reason: The relaying process stops at that target, any new client connection will start consuming targets from the next target in line:
      • Example: initial candidates = [targetA, targetB, targetC, targetD], received connection, targetA works, targetB fails => relay stops until it receives a new client connection, candidates = [targetC, targetD]
  • On HTTP (relaying to any protocol):
    • Same behavior if every relay attempt is successful.
    • If any of the relay attempts fail it'll keep consuming targets, the entire list will be consumed, and re-populated with all the failed targets, this loop will not end until all the targets are marked as successful.

• The multirelay behavior should be consistent across all of the relay servers

• IMO: If we expanded the single relay behavior to the multirelay case, when receiving a client connection the relay should consume ALL of the non-successful candidates (instead of stopping on the first failed attempt, like in SMB) and it should do this ONLY ONCE (instead of entering an endless loop if any target fails, repopulating the candidate list, and consuming it forever, like in HTTP).

Additional context

Space for additional context, investigative results, suspected issue.

[anadrianmanrique]

linked with #1620

[anadrianmanrique]

linked with #1620