Adversaries may explicitly employ a known encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Despite the use of a secure algorithm, these implementations may be vulnerable to reverse engineering if necessary secret keys are encoded and/or generated within malware samples/configuration files.
| ID | Name | Description |
|---|---|---|
| S0529 | CarbonSteal |
CarbonSteal has performed rudimentary SSL certificate validation to verify C2 server authenticity before establishing a SSL connection.[1] |
| S0555 | CHEMISTGAMES |
CHEMISTGAMES has used HTTPS for C2 communication.[2] |
| S0507 | eSurv |
eSurv’s Android version has used public key encryption and certificate pinning for C2 communication.[3] |
| S0478 | EventBot |
EventBot has encrypted base64-encoded payload data using RC4 and Curve25519.[4] |
| S0411 | Rotexy | |
| S0549 | SilkBean | |
| S0302 | Twitoor | |
| G0112 | Windshift |
Windshift has encrypted C2 communications using AES in CBC mode during Operation BULL and Operation ROCK.[7] |
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Since data encryption is a common practice in many legitimate applications and uses standard programming language-specific APIs, encrypting data for command and control communication is undetectable to the user.