What is command and control over a legitimate cloud service?¶
The practical answer¶
Command and control can be routed through legitimate cloud, storage, messaging or collaboration services.
The key evidential caution¶
The dangerous assumption is that traffic to a well-known provider is automatically safe.
It may not be.
An offender may abuse:
Key points¶
- cloud storage
- webhooks
- paste services
- messaging APIs
- code repositories
- serverless functions
- content-delivery platforms
- collaboration tools
The service may be used to publish commands, retrieve configuration, receive stolen data or redirect traffic.
Evidence to preserve¶
Investigators should preserve:
Key points¶
- the service name
- account or tenant identifiers
- object or channel identifiers
- API requests
- authentication method
- timestamps
- source process
- uploaded or downloaded content
- provider-held access records
A connection to the provider alone is weak evidence because many legitimate applications use the same service.
The specific account, object, request path and process context matter.
Evidential limits¶
Do not assume the provider or account holder knowingly supported the activity.
The account may have been created with false details or compromised.
Provider-specific retention, access and logging behaviour should be checked during casework.
Legitimate cloud traffic may be extensive, so precise object and account identifiers are essential. A malicious process may use one storage object or webhook within a provider used normally by the organisation. Broadly blocking or attributing the whole service would be misleading.
Where provider-held audit records exist, obtain the account actions as well as the object content. Creation, modification and access events may identify the operational sequence even if the malicious object has been deleted.
Operational takeaway¶
Identify the exact cloud account, object, API action and source process, and do not treat traffic to a legitimate provider as benign or malicious without that context.