Global security desk · updated coverage of threats, exploits & breaches
Twitter Sitemap
Circular security news icon in navy and blue tones with a shield-like mark SecNews24.com Read Latest News

How Adversaries Hide Command and Control Inside Trusted Cloud Platforms

Threat actors have spent years refining how they stay invisible once inside a target network. One of the most effective shifts in tradecraft involves routing command traffic through services that already sit inside nearly every enterprise. By hiding command-and-control channels inside Slack, GitHub, Microsoft 365, AWS S3 buckets and similar trusted platforms, attackers reduce the noise that defenders rely on to spot anomalies. Security teams that blocklist unknown IP ranges now face traffic that looks identical to ordinary employee behaviour.

The trend has accelerated as more Australian organisations move workloads into public cloud environments. With hybrid work still the default in Sydney, Brisbane and Melbourne offices, traffic to cloud platforms like Slack, Teams and SharePoint has become background noise. Adversaries understand this normalisation and exploit it deliberately. The result is a category of attack that bends traditional detection assumptions, and which the industry now labels cloud-aged delivery or trusted-platform command and control.

Why Threat Actors Favour Legitimate Cloud Infrastructure

The appeal of abusing legitimate services is partly operational and partly psychological. Operators no longer need to rent dedicated servers, patch VPN appliances or register fresh domains that might trigger reputation filters. Instead, they ride the reputation of household-name platforms. A connection to *.slack.com or *.amazonaws.com rarely raises a flag, particularly during business days when those domains are hammered by ordinary users.

There is also a cost calculus at work. Free-tier accounts for storage, code repositories and messaging tools give attackers nearly unlimited bandwidth without drawing the kind of billing anomalies that dedicated infrastructure would generate. Many groups have shifted to encrypted blobs inside cloud object stores, using rotating signed URLs to fetch tasking instructions. This makes command traffic indistinguishable from routine API calls.

The longer an adversary hides inside trusted infrastructure, the higher the value of their access. That is why initial access brokers, ransomware affiliates and state-aligned operators alike have adopted these methods. The shift is documented in detail across mainstream hacking coverage, where researchers describe how a single misconfigured token or stolen refresh token turns a cloud account into a covert relay.

Cloud Platforms Commonly Weaponised for C2 Operations

Several categories of cloud service show up repeatedly in incident reports. Collaboration tools are particularly attractive because they support bot automation, webhook callbacks and persistent tokens. Slack and Microsoft Teams have both been weaponised by groups who hide commands in channel descriptions, slash-command responses or adaptive card payloads that the user never sees.

Developer platforms form another abused category. GitHub repositories, GitLab projects and even public Gists can host staged PowerShell, Python or Bash loaders. Attackers commit encoded blobs, then poll the repository for fresh instructions every few minutes. Because the implant only performs outbound HTTPS to a trusted domain, even strict egress allowlists struggle to catch it.

Object storage services such as AWS S3, Azure Blob Storage and Google Cloud Storage round out the top tier. Each supports static website hosting, signed URLs and server-side encryption, giving adversaries a flexible toolkit. Some groups stage entire toolchains in encrypted archives and fetch them on demand. Others use cloud functions or serverless triggers to relay commands, ensuring no dedicated server is ever registered to the attacker.

Comparing Abuse Techniques Across Cloud Platforms

Platform Abuse Method Detection Difficulty Typical C2 Technique
AWS S3 Staging payloads and exfiltration High due to TLS and volume Encrypted blobs in buckets
Azure Blob Hosting implant configurations High Static website hosting with SAS URLs
Google Cloud Storage Payload drop and C2 callbacks High Signed URLs and lifecycle abuse
Slack and Teams Real-time messaging channel Medium Bot commands via API tokens
Dropbox Encrypted file sharing High Modified documents as task carriers
GitHub and GitLab Code-based stagers Medium Repo commit polling for next stage
Microsoft 365 OneDrive sync abuse High Cloud relay through shared links

Detection difficulty is rated on the assumption that defenders do not have deep API telemetry from each platform. Where organisations have enabled unified audit logging, difficulty drops considerably. The dominant pattern across every entry is that attackers favour services with rich automation features and widely accepted TLS certificates, which together allow their traffic to blend into background enterprise activity.

Tracking the Pattern: Recent Incidents and TTPs

Mandiant, CrowdStrike and several Australian incident response firms have published case studies describing implants that beacon to OneDrive or Dropbox rather than to attacker-controlled hosts. In one widely cited engagement, a financially motivated group used Microsoft Graph API endpoints to retrieve tasking instructions every 90 seconds, blending in perfectly with normal Microsoft 365 usage patterns. The implant exfiltrated documents through shared links that looked identical to legitimate collaboration activity.

Another recurring pattern involves Slack tokens stolen through social engineering of developers on contractor marketplaces. Once inside a workspace, the adversary creates a hidden channel, invites a bot account, and uses slash commands to relay instructions to endpoints scattered across the victim's cloud footprint. Because Slack retains message history for compliance, defenders investigating after the fact can sometimes recover the entire command sequence from audit logs.

Australian responders have reported cloud-aged intrusions in the legal, retail and higher education sectors, with several incidents leading to notifications under the Notifiable Data Breaches scheme. In many of these cases, the initial entry point was a third-party contractor whose cloud account lacked multifactor authentication. From that single foothold, the actor pivoted into the broader tenant and began beaconing through trusted SaaS APIs.

The Australian Landscape: Local Impact and Reporting

Australia presents a particularly rich target surface for this style of attack. The Australian Cyber Security Centre's annual threat report consistently identifies cloud exploitation as a rising category, and the agency's alerts have repeatedly warned about adversaries abusing Microsoft 365 and AWS infrastructure. Sydney-based organisations, in particular, host significant AWS Sydney region workloads, which means a misconfigured S3 bucket or stolen IAM credential can sit undetected for months.

The local response has matured. The Australian Signals Directorate's Essential Eight framework now emphasises MFA, application control and logging maturity precisely because cloud-aged tradecraft defeats older signature-based detection. Notifiable Data Breaches reporting has forced boards to treat cloud telemetry as a compliance requirement, not an optional extra. Several large incidents, including the 2022 Optus breach and the Medibank intrusion that same year, highlighted how trusted-platform abuse turns a single compromised account into a wide-reaching exposure.

Local incident responders also point out a regional quirk: Australian organisations tend to operate thinner security teams than their North American counterparts, which makes API-level monitoring harder to maintain. Smaller managed security providers in Melbourne and Adelaide have responded by offering cloud detection and response packages that focus specifically on identity, token reuse and SaaS telemetry. The market is shifting towards continuous validation of trust relationships inside cloud tenants, rather than perimeter defence.

Why Defenders Struggle to Spot Cloud-Aged C2

The core detection challenge is signal-to-noise. A connection from an internal host to login.microsoftonline.com or api.slack.com is overwhelmingly likely to be legitimate. Traditional indicators of compromise look for odd destinations, unusual ports or low-reputation domains. None of those fire when an attacker has nestled inside a top-tier SaaS provider.

Compounding the problem, most organisations do not retain detailed logs from every cloud platform they use. Free tiers of Slack and GitHub do not always expose the right telemetry without paid plans. AWS CloudTrail, Azure Activity Log and Google Cloud Audit Logs require deliberate configuration and ongoing cost. Many Australian organisations discover, mid-incident, that logging was enabled but never actually ingested into their SIEM.

Identity-based detection helps, but only if the defender understands normal token behaviour. Stolen refresh tokens, OAuth abuse and consent grant manipulation all leave fingerprints, yet they sit outside the comfort zone of teams trained on network signatures. The result is a detection blind spot that adversaries have exploited consistently since at least 2021.

Practical Steps to Reduce Exposure