Time (clock) issue prevents communication with C2

[securityguy]

I just spent over an hour trying to get a Shark Jack Cable to communicate with C2. It turned out to be a time issue.

Please consider adding:

/usr/sbin/ntpd -q -p 1.openwrt.pool.ntp.org

or similar to all scripts that upload to C2 to avoid this frustrating issue.

[dallaswinger]

Appreciate the feedback.

By design, it is the responsibility of the payload author to include prerequisites for individual payload functionality (including this example; NTP)

NTP is not enabled by default at the system level due to it not being a passive behavior.

You're welcome to open PRs to any payloads that you think should have the above NTP sync command and we can get them reviewed

[securityguy]

I understand that NTP isn't passive, but neither is communicating with C2. It doesn't make sense to attempt a connection that will fail every time due to the the time not being set.

[dallaswinger]

I explained why its not enabled as a service by default at the OS level (because not every payload uses Cloud C2, or requires https communication and thus requires time sync)

I did not disagree or say that it wasn't needed for Cloud C2, or claim that a payload that uses Cloud C2 was passive.

It doesn't make sense to attempt a connection that will fail every time due to the the time not being set.

I explained that it is a part of the design language for payloads for payloads to contain 100% of the configuration required to run the payload; which is why its the responsibility of the payload that uses Cloud C2 to sync NTP,

additionally not every Cloud C2 instance uses https, so its not even true that in every case someone is using Cloud C2 that it is required - however still a good practice for payload developers to include in their payloads that use Cloud C2 to ensure it will work for those who do.