Full Report
On 2020-01-16, a campaign was reported, involving Kinsing operator, gaining initial access via Software misconfig, 1-day vulnerability, while using Vulnerability exploitation, Misconfigured Docker abuse, targeting Redis, Confluence Server, Docker, Apache Hadoop, Solr, ThinkPHP to achieve Resource hijacking. The following tools were observed: Kinsing.
Analysis Summary
# Incident Report: Kinsing Cryptojacking Campaign targeting Misconfigured Cloud Services
## Executive Summary
On January 16, 2020, security researchers reported a widespread campaign orchestrated by the Kinsing threat actor group. The attackers exploited 1-day vulnerabilities and misconfigured Docker/Redis instances to achieve initial access, ultimately deploying the Kinsing malware for resource hijacking. The primary impact was significant unauthorized CPU consumption for cryptocurrency mining across diverse server environments.
## Incident Details
- **Discovery Date:** 2020-01-16
- **Incident Date:** Circa January 2020
- **Affected Organization:** Multiple (Global)
- **Sector:** Technology, Cloud Services, Enterprise Software
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** Reported 2020-01-16
- **Vector:** Exploitation of 1-day vulnerabilities and software misconfigurations.
- **Details:** The attacker targeted unprotected Docker API ports and misconfigured Redis instances, as well as unpatched instances of Confluence, Apache Hadoop, Solr, and ThinkPHP.
### Lateral Movement
- **Details:** Once a container or server was compromised, the Kinsing malware attempted to spread within the local network by scanning for additional misconfigured services or utilizing ssh keys found on the compromised host to access adjacent systems.
### Data Exfiltration/Impact
- **Details:** The primary impact was **Resource Hijacking**. The Kinsing malware deployed a persistent cryptocurrency miner, consuming high levels of CPU and memory, leading to service degradation for legitimate applications.
### Detection & Response
- **How it was discovered:** Security researchers and cloud monitoring tools flagged unauthorized API access and unusual CPU spikes.
- **Response actions taken:** Community reporting led to the identification of the Kinsing toolkit and the blacklisting of associated C2 infrastructure.
## Attack Methodology
- **Initial Access:** Vulnerability exploitation (N-day) and Misconfigured Docker/Redis API abuse.
- **Persistence:** Implementation of crontabs and persistent scripts to relaunch the malware.
- **Privilege Escalation:** Exploiting container escape vulnerabilities or misconfigured sudo permissions (where applicable).
- **Defense Evasion:** Use of shell scripts to kill competing miners and security monitoring processes.
- **Credential Access:** Scraping local files for SSH keys and environment variables.
- **Discovery:** Network scanning for common ports (Redis: 6379, Docker: 2375).
- **Lateral Movement:** SSH-based movement and internal network scanning.
- **Collection:** N/A (Focus was on compute resources).
- **Exfiltration:** N/A.
- **Impact:** Resource Hijacking (Cryptomining).
## Impact Assessment
- **Financial:** Increased cloud infrastructure costs due to unauthorized resource consumption.
- **Data Breach:** None reported; data theft was not the primary objective.
- **Operational:** System performance degradation and potential downtime of business-critical applications (Confluence, Hadoop).
- **Reputational:** Potential loss of trust if customer-facing instances were used to propagate the malware.
## Indicators of Compromise
- **Network indicators:**
- Communications with known malicious C2 IPs (e.g., `193[.]33[.]87[.]219`)
- Outbound connections to mining pools on non-standard ports.
- **File indicators:**
- Presence of `kinsing` binary.
- Presence of `d.sh` or `kdevtmpfsi` files in `/tmp` or `/var/tmp`.
- **Behavioral indicators:**
- Unexplained 100% CPU utilization.
- Crontab entries pointing to unfamiliar shell scripts.
## Response Actions
- **Containment:** Terminated malicious processes (`kinsing`, `kdevtmpfsi`) and deleted associated temporary files.
- **Eradication:** Patched vulnerable software (Confluence, ThinkPHP) and secured Docker/Redis APIs with authentication and firewalls.
- **Recovery:** Restored services from known-good backups and rotated SSH keys found on compromised hosts.
## Lessons Learned
- **Key takeaways:** Misconfigured APIs (Docker/Redis) remain a primary entry point for automated "drive-by" botnets.
- **What could have been done better:** Implementing the principle of least privilege for Docker containers and ensuring that administrative APIs are never exposed to the public internet without robust authentication.
## Recommendations
- **Patch Management:** Maintain a rigorous patching schedule for 1-day vulnerabilities in enterprise apps like Confluence and Solr.
- **Network Hardening:** Restrict Docker and Redis access to internal networks only; use TLS for Docker API authentication.
- **Monitoring:** Implement runtime security tools (e.g., Falco, Sysdig) to detect unusual process execution in containerized environments.
- **Resource Quotas:** Set CPU and memory limits on containers to mitigate the financial impact of cryptojacking.