Wazuh Cloud Security Monitoring: AWS and Azure

The Wazuh Cloud Module: How It Pulls Cloud Logs

Cloud services do not run Wazuh agents. Instead Wazuh uses dedicated module integrations that poll cloud-native log sources on a schedule and feed the events into the same decoder, rule and alerting pipeline used for endpoints. This means a single Wazuh manager correlates an endpoint event with a cloud API event in the same rule engine, which is exactly where cross-domain attacks become visible.

On the manager you configure the integration block in the Wazuh configuration. For AWS the aws-s3 module reads logs that CloudTrail, GuardDuty, VPC Flow and similar services write to an S3 bucket, optionally driven by an SQS queue for near real-time delivery. For Azure the azure-logs module queries the Graph API, Log Analytics and storage, and for Microsoft 365 the office365 module reads the Unified Audit Log via the Management Activity API.

Each integration uses a scoped, least-privilege credential. For AWS that is an IAM role or user with read access to the specific log buckets and the GuardDuty and Config APIs. For Azure it is an app registration in Microsoft Entra ID with the minimum Graph and Log Analytics read permissions. Wazuh never needs write access to your cloud, which keeps the monitoring footprint safe even if the manager itself is compromised.

AWS Monitoring: CloudTrail, GuardDuty and VPC Flow

CloudTrail is the foundation of AWS detection. Every API call (console, CLI, SDK) is recorded, so CloudTrail ingestion lets Wazuh detect root account usage, IAM policy changes, disabled CloudTrail, new access keys, public S3 bucket exposure, security group changes that open ports to the internet, and unusual cross-region activity. Wazuh ships default rules for many of these, and our SOC engineers add account-specific rules for sensitive resources.

GuardDuty is AWS native threat detection. Rather than duplicate its detection logic, Wazuh ingests GuardDuty findings as enriched events, so credential exfiltration, cryptomining, anomalous API calls and reconnaissance findings land in the same console and case workflow as everything else. This turns GuardDuty from an isolated AWS panel into a correlated SOC signal.

VPC Flow Logs give network-layer visibility: connections to known-bad IPs, data exfiltration volume spikes, lateral movement between subnets, and traffic to unexpected geographies. Combined with MISP threat intelligence feeds, Wazuh flags flows to indicators of compromise. AWS Config and Inspector findings round out the posture and vulnerability picture for cloud workloads.

Azure and Microsoft 365 Monitoring

The Azure Activity Log is the control-plane equivalent of CloudTrail: it records resource creation, deletion, role assignments and policy changes across the subscription. Wazuh ingestion catches privilege escalation through role assignments, deletion of diagnostic settings (a classic anti-forensics move), and creation of unexpected resources that often signal cryptomining or persistence.

Microsoft Entra ID sign-in and audit logs are where identity attacks surface. Wazuh correlates impossible-travel sign-ins, repeated MFA failures or fatigue prompts, sign-ins from anonymising infrastructure, and changes to conditional access policies. For most Azure tenants, identity is the real perimeter, and these logs are the highest-value source you can feed a SIEM.

Delivery is typically through an Event Hub: Azure Monitor and Microsoft Defender stream logs to the Event Hub, and Wazuh consumes from it. Microsoft 365 is covered separately through the office365 module, which surfaces mailbox rule creation, mass download, suspicious OAuth grants and admin changes. Together these give a single pane over Azure infrastructure, Entra identity and the M365 productivity layer.

Container and Kubernetes Monitoring

Containers move fast and disappear, which defeats traditional agent models. Wazuh handles this two ways. First, an agent on the container host (or as a privileged DaemonSet pod on each Kubernetes node) monitors the Docker daemon, capturing container create, start, stop and exec events, image pulls and mounts. Suspicious patterns such as a shell spawned inside a running container or a container started in privileged mode generate alerts.

Second, Wazuh ingests the Kubernetes audit log, which records every API server request. This catches exec into pods, secret access, service account token misuse, creation of privileged workloads and RBAC changes. For clusters running on EKS or AKS, these audit logs flow through the same cloud integrations described above, unifying cluster activity with the rest of the cloud account.

On top of event monitoring, Wazuh runs CIS Benchmark configuration assessment against container hosts, Docker and Kubernetes, scoring them against hardening guidance. This produces the configuration evidence auditors expect for SOC 2 CC8 and ISO 27001 control objectives, and it flags drift such as an exposed Docker socket or an over-permissive cluster role.

High-Value Cloud Detection Use Cases

A practical Wazuh cloud detection set focuses on the techniques attackers actually use rather than trying to alert on everything. These map cleanly to MITRE ATT&CK for Cloud.

• Identity abuse: root or global admin login, new access keys, MFA disabled, conditional access policy weakened, impossible travel.
• Persistence: new IAM users or roles, OAuth app consent grants, scheduled tasks via cloud functions, unexpected service principals.
• Defense evasion: CloudTrail or Activity Log diagnostic settings disabled, log buckets deleted, GuardDuty or Defender suspended.
• Exfiltration: large S3 or Blob downloads, public bucket exposure, snapshot sharing to external accounts, VPC flow spikes to unknown destinations.
• Cryptomining: sudden spin-up of large compute instances, GuardDuty cryptocurrency findings, container started with mining images.
• Reconnaissance: enumeration of IAM, buckets or secrets, API error spikes indicating brute-force discovery.

Operating Cloud Monitoring in Practice

Cloud logs are voluminous and noisy. CloudTrail in an active AWS account can generate millions of events per day, most of them routine automation. The first 30 days of any cloud monitoring rollout are dominated by tuning: suppressing expected automation identities, scoping alerts to sensitive resources, and setting thresholds that separate a human attacker from a Terraform pipeline. Without this discipline analysts drown and real alerts get missed.

Retention is a deliberate decision. Hot-search retention of 30 to 90 days in the Wazuh indexer covers most investigations, while colder snapshots to S3 or Blob storage satisfy compliance retention at a fraction of the cost commercial cloud SIEM charges. Because Wazuh has no per-GB ingestion fee, you can afford to keep the full CloudTrail and Activity Log history that incident response often needs.

Codesecure deploys Wazuh cloud monitoring as part of a managed SOC engagement: we connect each cloud account with least-privilege credentials, tune the detection set to your environment, wire findings into TheHive cases and n8n response playbooks, and operate it 24x7. For teams running Wazuh themselves, we deliver the cloud integration design, rule pack and tuning as a fixed-scope project with handover.