beacons exit abnormally when the teamserver restarts

[HellooTiger]

It's really wired to find out beacons exit abnormally when the corresponding teamserver restarts. The version of CrossC2 is v2.2.4 and v2.2.2, and beacons exited abnormally both on CS 4.2 and CS 4.3. For some reasons, the teamserver need to be restarted frequently, for example, the teamserver hangs out when the beacon-get URI is accessed intensively by Internet scan traffic, or the teamserver is put into a VM and the VM only starts when it's time to control beacons. It was observed that beacons exited abnormally, when the teamserver restarts several times. It cannot tell how many times the teamserver restarts before the beacon will exit unexpectedly, maybe two or three. Usually the beacon exits silently after two or three hours after the teamserver restarts. Moreover, the phenomenon of beacon exit unexpectedly are quite often.

Please tell us why this happens, thanks

[gloxec]

There are two scenarios for beacon exit, one is the normal exit of the internal settings, and the other is the abnormal exit of the network connection error.

1. When the beacon cannot connect to the teamserver, it will try to sleep for a period of time and try to connect again, or if the domain name or domain name list is configured, it will re-analyze the available C2 IP. Each time it tries to reconnect, it will sleep for 1 minute to 4 minutes. When the number of single reconnection failures reaches 20 times, it will take the initiative to exit. Whenever the reconnection is successful, the statistics of the number of reconnection failures will be cleared.
2. When the beacon is communicating with the teamserver, if there is a problem with the network, for example, a 1000bytes packet is being sent, and the network is interrupted when sending to 300bytes, this behavior may cause the beacon to crash.

[HellooTiger]

For scenario 1, is there any way not to let the beacon exit even it fails to reconnect after trying 20 times, such as a configuration or rebind? For some cases, the teamserver needs to be restarted for several times or put into offline for a period of time.

[gloxec]

The v2.2.5 version that has been pushed will try to ensure that abnormal network connections will not affect the beacon process, and its sessions will be guaranteed to survive for 48 hours in a disconnected state.
However, the connection attempt time will go to sleep within the range of 1h, 2h, 2h, 1h, etc. due to the increase in the number of connection failure errors.
According to the situation you encounter, the next version considers to reserve the beacon sleep processing function, and this part of the function is left to the user to customize.

[HellooTiger]

The v2.2.5 version that has been pushed will try to ensure that abnormal network connections will not affect the beacon process, and its sessions will be guaranteed to survive for 48 hours in a disconnected state.

That's a thoughtful consideration.

According to the situation you encounter, the next version considers to reserve the beacon sleep processing function, and this part of the function is left to the user to customize.

That sounds great. From my view of design philosophy for RAT, the beacon should never choose to proactively exit without a command from the control side. The control side may encounter network connection failure, or power down, or even intentionally hiding for a while. Usually it requires such amount of effort to put a beacon onto a victim, that is also Initial Access, which may result from a vulnerability worth thousands of dollars, or a sophisticate phishing mail. However, if the installed beacon choose to exit itself without a order from the control side due to a period of unreachable network , that makes the previous effort of initiative access meaningless. In that case, the beacon should just sleep, and wake up to connect control side on a period time infinitely, and then sleep, and wake, and so on.

[gloxec]

From my view of design philosophy for RAT, the beacon should never choose to proactively exit without a command from the control side.

The design idea of RAT not voluntarily withdrawing is correct, but the project is used for legal exercises.
Because many people often encounter excessive assets, too many sessions, incomplete removal after the end of the final action, and inability to control the target due to the network policy temporarily adjusted by the administrator, which may cause the beacon process to remain.
In order to ensure that the network robustness of the target user will not be affected by the beacon, the design will take the initiative to exit after a certain period of time cannot be controlled.

Usually it requires such amount of effort to put a beacon onto a victim, that is also Initial Access, which may result from a vulnerability worth thousands of dollars, or a sophisticate phishing mail.However, if the installed beacon choose to exit itself without a order from the control side due to a period of unreachable network , that makes the previous effort of initiative access meaningless.

In response to this problem, the user-customizable beacon version will be pushed as soon as possible.
Including the initial check of beacon, and the realization of abnormal state sleep.