No Keyboard access upon Wakeup

[cptfubar]

I found this bug when deploying it on a target PC, when they came out of sleep, the keyboard wasn't working. Had to quickly remove the device and plug the keyboard in myself before they found the key crock. Tried it out on my PC and when I came came back from it going to sleep the keyboard was unresponsive. LEDs still worked on the keyboard but no input, when I replugged the keyboard into the KC, I had no input and no LEDs, and when I replugged the KC into my PC it took it's boot time to become useful. Any way to avoid this so that it won't be found on a target PC? 

[brish]

I have had this same issue testing today. This is not a solutions, but I am including some more details and troubleshooting. Using a Microsoft Surface 7 running Windows 10 with standard Lenovo US keyboard. Once the computer locked and went to sleep, the keyboard was no longer responsive. It would not wake the computer as usual. I woke it with the mouse. I then tested typing with no response. I also checked the NumLock and Caps Lock LEDs. They functioned. I checked my streaming to C2. The keystrokes were still being picked up by the KeyCroc and being sent to C2. They just were not passing to the computer. When I unplugged the keyboard from the KeyCroc (leaving the KeyCroc plugged into the computer), it still would not work. My issue also required me to remove the KeyCroc from the computer to allow it to reboot before it would work again.

To further test, I tried to duplicate the issue. Once connected and functioning correctly, I tried removing the keyboard from the KeyCroc and reconnecting. It continued to function once reconnected. I also checked the Device Manager to see if there was a power saving option that was causing it to disconect or sleep in some way like a network adapter. This was not the case. I did find if the computer was locked, but did not yet have time to go to sleep, the keyboard would continue to function after unlocking. Manually causing the sleep would duplicate the issue. I did notice that the HID Keyboard Device (on USB input device) continued to remain in the Device Manager when the keyboard was not passing input to the computer.

I am not sure if it is relevent, intended, or a separate issue, but ever time the KeyCroc boots, the USB keyboard (showing as a HID Keyboard Device) resinstalls. It is quite noticeable because it connects, disconnects, and reconnects a time or two with an audible alert each time. This could be an issue in deployment.

[Darren Kitchen]

Thanks for the detailed reports. Since the keystrokes are still passing through to Cloud C2 - just not the target - after waking from sleep it gives us a good lead to follow. We'll investigate. Any information you can provide on the USB ports (C with A adapter, hub, powered hub, etc) would be helpful. 

[brish]

On 5/30/2020 at 11:52 AM, Darren Kitchen said:

Thanks for the detailed reports. Since the keystrokes are still passing through to Cloud C2 - just not the target - after waking from sleep it gives us a good lead to follow. We'll investigate. Any information you can provide on the USB ports (C with A adapter, hub, powered hub, etc) would be helpful. 

Initially, this was passing through a basic USB-A hub connecting to a Microsoft Surface Dock connected with the dock connector to the Microsoft Surface. Realizing this, I tested again with the Key Croc connected directly to the USB-A port on the Surface with the same Lenovo keyboard. When I put the Surface to sleep, I had the same result. There was still activity with the LEDs (NumLock, CAPS Lock) on the keyboard and key strokes were picked up by the Key Croc passing to C2, but nothing passing to the PC. One additional oddity that may or may not be relevant was that the NumLock LED remained lit on the keyboard after the Surface went to sleep while connected to the Key Croc. Without the Key Croc, the NumLock turns off within about 10 seconds of being put to sleep.

[Darren Kitchen]

Interesting observations. I'm testing on my end with a Microsoft Surface Book machine with the Key Croc connected directly to its USB-A port. I've found that when the system enters sleep, the Key Croc stays awake and I can SSH into it without issue. However, while the target is in sleep mode the Key Croc is unable to inject keystrokes to wake the target (QUACK returns errors). That said, I am unable to reproduce the issue with keystrokes from the attached keyboard not passing through to the target. In my case, pressing keys on the attached keyboard both woke the target and were recorded.

The keyboards numlock light turning off while directly attached to the target in sleep mode, but not turning off while in sleep mode when attached to the Key Croc, is likely due to the DefaultIdleState being zero.

Edit:

Upon further investigation, it would seem that in my first test the target had entered S0. After leaving the target idle for longer, it entered S1and I was able to reproduce what you are describing.

By running the following command on the Windows target with the Key Croc both connected and disconnected, I was able to determine its device ID.

powercfg /devicequery all_devices | findstr "Keyboard"

Then, with the Key Croc attached running the two following commands leads to me believe that Windows believes the Key Croc is able to enter S1 sleep, while the Surface Book's onboard keyboard is only able to enter S4 sleep.

powercfg /devicequery S1_supported | findsrt "Keyboard"
powercfg /devicequery S4_supported | findsrt "Keyboard"

I believe that by adding the PDCAP_WAKE_FROM_D3_SUPPORTED setting and removing the PDCAP_D2_SUPPORTED setting will resolve this issue. I'm investigating configurations outside keyboard.inf, or if a power state may be cloned by spoofing another device. I'll keep you posted.

[X00Gendo]

I have the same issue with mac. When the mac sleeps, it the keycroc will not deliver keystrokes. Even after unplugging the keyboard from the croc and plugging back in, it doesn't take input. However, unplugging the croc and plugging back in sorted it. 

This needs a patch. This makes the keycroc practically useless for any serious pentest engagement.

 

 

[X00Gendo]

Let me caveat that by sying this is still a great product. But if it stops working when a computer sleeps, that makes a long-term engagement more difficult. 

 

Is there more guidance on how I can do this: "adding the PDCAP_WAKE_FROM_D3_SUPPORTED setting and removing the PDCAP_D2_SUPPORTED"?

 

Thanks!

[Darren Kitchen]

We're testing a patch now and will make an update as soon as possible. 

[X00Gendo]

Another issue, unrelated to this topic, but worth flagging, is that once you SSH in and view croc_char under loot, the croc will stop recording keystrokes. 

Is this intended behaviour? Is there a way to get it to resume recording keystrokes after viewing the log?

[Darren Kitchen]

6 hours ago, X00Gendo said:

Another issue, unrelated to this topic, but worth flagging, is that once you SSH in and view croc_char under loot, the croc will stop recording keystrokes. 

Is this intended behaviour? Is there a way to get it to resume recording keystrokes after viewing the log?

How are you viewing the log? I tend to cat the file here and there in payload development and have yet to have that cause issues. Are you viewing it with an editor like vim or nano? Also, is this with 1.2 or 1.3 beta? In the new version, the file is written more frequently. 

[X00Gendo]

Apologies, this was a mistake on my part. Working as expected now!

[jimcola99]

I am having a similar issue on reboot.  

Plug the keycoc into the pc and keyboard.  No problems.   When I reboot.  The keyboard doesn't work.  Stuck flashing blue LED.

[Darren Kitchen]

This has now been addressed in firmware 1.3 – see the post at 

 

[X00Gendo]

Nice! Thanks!

[X00Gendo]

Tested the fix on Mac pro Catalina 10.15.3 and the fix works flawlessly.