PCPJack: Cloud Credential Theft & TeamPCP Artifact Removal
Has anyone taken a deep dive into the PCPJack framework disclosed today? It’s targeting exposed cloud infrastructure, but the standout feature is how it aggressively removes TeamPCP artifacts. It’s rare to see this level of "competitor elimination" in cloud credential theft operations.
The researchers noted it uses 5 CVEs to propagate worm-like through cloud systems. The toolset is specifically looking for cloud, container, and dev tools to scrape credentials. Given the prevalence of exposed cloud APIs, the blast radius could be massive if this gets automated in a botnet.
Detection needs to focus on the CLI abuse. Since it harvests from productivity and financial services, we need to flag when core cloud SDKs are accessed by unusual parent processes. Here is a basic KQL query to start hunting for suspicious AWS CLI usage often associated with this framework:
DeviceProcessEvents
| where FileName in~ ("aws.exe", "az.exe", "gcloud.cmd")
| where ProcessCommandLine has_any ("get-authorization-token", "container-list-images", "sql instances list")
| where InitiatingProcessFileName !in~ ("explorer.exe", "powershell.exe", "cmd.exe", "python.exe")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
Also, check your logs for the specific removal patterns. If you see rm -rf commands targeting directories associated with TeamPCP right before a spike in network traffic to unknown IPs, that’s a huge indicator.
Are we seeing any concrete IOCs for the C2 infrastructure yet, or is it still mostly domain generation algorithms (DGA)?
Good catch on the process lineage. In our SOC lab, we noticed PCPJack tries to mask itself as a legitimate update service. We added a Sigma rule looking for unsigned binaries spawning from svchost.exe that immediately call aws or kubectl. The exfiltration part is tricky because it uses HTTP/3, so you need deep packet inspection to catch the payload, otherwise it just looks like standard web traffic.
The 'TeamPCP removal' behavior is fascinating. It suggests the threat actor wants exclusive access to the environment. We've updated our CSPM policies to scan for unauthenticated APIs. If your cloud instances have public IPs, you're effectively open to the 5 CVEs mentioned. Ensure you're using specific firewall rules to restrict access strictly to internal bastion hosts or IAP.
I'm more concerned about the persistence mechanism. It installs itself as a systemd service named cloud-monitor or similar. If you suspect infection, check the unit file location:
systemctl status cloud-monitor
If it's running and the binary is located in `/tmp/` or `/var/tmp/`, kill it immediately. The artifact removal also deletes logs, so forensic analysis might be limited to RAM dumps.
Excellent points. To add to this, monitoring the actual file access behavior is crucial since PCPJack targets dev tool configurations. We've had success using auditd to alert on non-standard processes reading sensitive paths like .aws/credentials. You can deploy a rule like this to catch the theft phase early:
auditctl -w /root/.aws/credentials -p r -a always,exit -k cloud_creds_access
It’s a good layer of defense if they manage to bypass the API controls mentioned earlier.
To complement the host-level insights, remember that the end goal is data exfiltration via those stolen keys. We implemented a Sentinel rule to flag anomalous GetSecretValue or ListAccessKeys calls originating from unexpected IP ranges. This often catches the actor using the credentials even if the initial worm bypassed endpoint defenses. You can try this query to spot immediate post-exploitation activity:
AWSCloudTrail
| where EventName in ('GetSecretValue', 'ListAccessKeys')
| summarize Count = count() by SourceIPAddress, UserAgentIdentity
| where Count > 3
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access