mitre / sandcat

A CALDERA plugin
https://caldera.mitre.org/
Apache License 2.0
63 stars 36 forks source link

Sandcat network resiliency #440

Open timbrigham-oc opened 3 months ago

timbrigham-oc commented 3 months ago

Describe the bug When the sandcat agent is running on a device with Zscaler active, we can get occasional network errors, which stop later command processing, but do not result in any data returned to the console indicating a problem / apparent retries.

To Reproduce Run the sandcat agent (I'm using a slightly updated version of 5.0.0) in verbose mode. Have Zscaler ZIA enabled. I believe other tools that interfere with network traffic would have a similar impact. Execute an operation.

Some actions (I have not yet found a commonality) result in errors like the following: Failed to decode HTTP response: illegal base64 data at input byte 0 or similarly Failed to perform HTTP request: Post "https://xxxxx/beacon": read tcp 10.XX.XXX.XXX:58794->XXX.XXX.XX.X:443: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

After this occurs, we return to a status of receiving [+] Beacon (HTTP): ALIVE messages, and the agent shows as live within the Caldera UI. However the step associated with this never errors out / retries in the Caldera UI, resulting in the test 'freezing' waiting for for a status that will never come until the operation times out.

The screenshot below was taken well after 10 minutes after the last successful action listed in the operation UI.

Expected behavior The agent should either retry the failed operation, or at a minimum have some kind of status data returned denoting a failure.

Screenshots image

Desktop (please complete the following information): Latest version of Chrome / Edge in use, but not really relevant since it's impacting the sandcat agent. Sandcat agent tested on current updates for Win 10 / Win 11.

timbrigham-oc commented 3 months ago

It looks like something in the network traffic getting mangled can drive the CPU utilization to maximum, resulting in this issue.. Restarting the caldera server process corrects it. Not sure what the underlying issue is.