Impacket KeyError when running WMI after Zerologon

[mssalvatore]

Describe the bug

If the Zerologon exploiter is run before the WMI exploiter, errors occur in the the WMI exploiter when attempting to connect/disconnect to the victim using impacket. This doesn't appear to affect functionality, as the WMI exploiter is still able to authenticate to the victim when the correct credentials are used.

To Reproduce

Steps to reproduce the behavior:

1. Configure a machine to be exploitable with Zerologon and WMI
2. Configure Infection Monkey to use the Zerologon and WMI exploiters
3. Run the monkey agent
4. View errors in the logs.

Screenshots

Code that triggers errors

https://github.com/guardicore/monkey/blob/dd2168e8383edaab3b8b436437338f0f08b2368e/monkey/infection_monkey/exploit/tools/wmi_tools.py#L52-L75

[mssalvatore]

This might be fixed if we resolve https://github.com/guardicore/monkey/issues/1852

[mssalvatore]

It [threaded plugin prototype] appears to allow the plugins to run in parallel -- the log statements are all interleaved for all exploiter threads. I did see a manifestation of this error, with the following observations:

• It does not need zerologon to run at all in order to occur
• It only occurs when attempting to exploit the zerologon machines using WMI
• It only occurs when using a username other than "user"

Goals

Investigate the possibility that this error has nothing to do with running plugins concurrently. Is this related to some configuration on the zerologon target machine?

Configure two agents on two different machines to attack the zerologon target simultaneously. One can use WMI and the other can use zerologon. Does either agent produce the error?

[cakekoa]

Notes:

• Summary:

  • When running the Zerologon and WMI exploiters, Zerologon will run before WMI. Zerologon will succeed, and WMI will attempt to brute force username/password combinations. For me, this error occurred on every attempt. I tried all of the tests listed below, and it seems that:

    • Attempting to exploit from two different machines does not reproduce the error
    • Attempting to run the same exploiter twice in series (zerologon or WMI) does not reproduce the error
    • Changing the usernames based on which accounts on the target machine are Administrator accounts or which usernames are invalid does not affect when the error appears

    Therefore it may be something to do with zerologon not cleaning up after itself, since they both use impacket for connections. Note that zerologon is able to run without issue when run twice in a row, however

• Reproduce:
  • Run the Zerologon and WMI exploiters
  • Only need a single machine
  • ~~Use large number of passwords and accounts~~ Appears to happen on every WMI attempt
  • Run the agent and island and observe the agent logs
  • Note: Can’t use both linux island machines, as they have the same hardware ID
• Observations:
  • ~~The problem seems to be two threads running dcerpc requests simultaneously~~
  • This problem seems to have something to do with zerologon not cleaning up after itself
• Tests:
  • [x] Investigate if it is related to configuration on the zerologon machine
  • [x] Investigate if it can be reproduced running two agents against the zerologon target simultaneously
• Procedure:
  • [x] Generate a configuration file
  • [x] Verify that we can reproduce the original issue
  • [x] Verify that it doesn’t happen serially
  • [x] Try running two agents simultaneously (different machines because of singleton)
    • [x] Using WMI
      • Result: No issues
    • [x] Using Zerologon
      • Result: No issues
  • [x] Try fiddling with zerologon machine configuration
    • [x] Try RDPing into the zerologon machine
    • [x] Check which accounts are on the machine
      • Administrator and m0nk3y are valid accounts. Both are in Administrators group. m0nk3y is also in Users group
      • user is not a valid account
    • [x] Fiddle with he registry setting
  • [x] Check if the issue can be reproduced without the user user
    • Yes, it happens a LOT
  • [x] Check if the issue can be reproduced with only the user user
    • Yes, it happens a LOT
  • [x] Check the impacket version
    • 0.10.0
  • [x] Check if running zerologon in series causes the issue to occur (I.e., does zerologon not cleanup after itself?)
    • [x] Configure the system for zerologon
    • [ ] ~~Update the propagator _exploit_hosts() to run the exploiter twice~~ this would run them in separate threads
    • [x] Update exploiter _run_all_exploiters() to run each exploiter twice
    • Result: No issues
  • [x] Run zerologon, WMI from two separate machines (hard-code the exploiters). Modify exploitation_config passed into infection_monkey/master/exploiter.py:exploit_hosts()
    • [x] For zerologon: set .vulnerability to (PluginConfiguration(name=“ZerologonExploiter”, options={}),)
    • [x] For WMI, set .brute_force to (PluginConfiguration(name=“WmiExploiter”, options= {'smb_download_timeout': 30}))
    • Result: No issues

[ilija-lazoroski]

I have run as explained in the issue and didn't see the issue after moving to plugins. The logs from the Agent from the Island and zerologon machine: 2023-05-04T08.50.22.010Z-island-linux-250.log 2023-05-04T08.51.06.746Z-smb-20.log

[mssalvatore]

As expected, it seems that the move to plugins resolves this issue.