CloudThinker × Wazuh: From Alerts to Investigation

An SSH brute-force alert arrives. Seventeen minutes later, the same source logs in successfully. Then an AWS console login and a new access key appear. The analyst's job is to work out whether those events belong together, what evidence is missing, and whether anyone needs to act.

CloudThinker adds an investigation step between Wazuh and your SOAR: query relevant evidence, test explanations, and prepare a case for review. Wazuh remains the system of record. Your response tools carry out the actions your team authorizes.

This walkthrough describes a reference workflow to configure with your team. The incident, counts, and interface mockups are illustrative, not customer results. Available integrations and deployment settings determine which steps you can enable.

One incident, across two environments

In this example, Wazuh holds four groups of events from an on-premises bastion and AWS:

Illustrative evidence trail

02:14
SSH brute force
bastion-01
Rule 5712 · source 203.0.113.45
02:31
Successful login
ops.deploy
Rule 5715 · same source IP
02:40
AWS console login
ConsoleLogin
Nine minutes later · identity to verify
02:43
New access key
CreateAccessKey
Check the session and owner approval

Separate activity: internal scanner 10.0.4.12 and scheduled backup. Validate their approval before suppressing alerts.

Illustrative evidence from two environments. The sequence supports a compromise hypothesis; identity and session checks are still needed.

Rule 5712 raises an SSH brute-force alert on bastion-01. Rule 5715 records a successful login as ops.deploy. Nine minutes later, CloudTrail records a console login from the same IP, followed by an access-key creation.

Together, these events justify investigation. They don't prove compromise. A shared IP may belong to a VPN or NAT gateway, a login may be legitimate, and matching usernames don't establish that two accounts belong to the same person. The investigation needs identity mapping, session context, and confirmation from the account owner.

The same caution applies to noise. A scanner or backup job should be set aside only when its owner, expected behavior, and approval are known. A familiar source can still behave unexpectedly.

Where CloudThinker fits

01Log sources

Already in Wazuh

AWSCloudTrail, GuardDuty, VPC Flow Logs
Second cloudLocal cloud tenant, syslog and agents
On-premiseLinux and Windows agents, firewalls, AD
KubernetesAPI server audit logs

No change to collection

02SIEM, your network

Wazuh managerDecoders, rules, MITRE mapping
Wazuh indexerSearchable alerts and evidence
Server APIAgents, rules, active response

System of record

03Investigation

CloudThinker

Follow the evidenceRead-only queries around each alert
EnrichReputation, asset owner, change log
Clean and learnDedupe, correlate, tune rules from verdicts

Scoped query results

04SOAR and response

Cases, not alerts

SOAR platformShuffle, TheHive, XSOAR, or webhook
OnCall war roomEscalate through configured routing
JiraTicket with evidence attached
PagerDutyPage according to escalation policy

Playbooks run on signal

Reference architecture. Wazuh holds the source records; selected query results support investigation. Processing and retention depend on the approved deployment.

The workflow has three responsibilities:

Wazuh collects and detects. Existing agents, decoders, rules, and storage continue to operate. Its indexer provides alert evidence; its server API provides agent inventory and rule information.
CloudThinker investigates. Scoped, read-only queries gather the context needed to test a hypothesis. The case records the evidence, uncertainty, and proposed next steps.
Your SOAR coordinates response. Configured integrations route the case to the right workflow, such as enrichment, analyst review, or an approved containment action.

The intended handoff is one evolving case per incident. Correlation still needs review: an IP address alone is not enough to merge unrelated users or sessions.

Targeted queries and data boundaries

This design avoids a second bulk log-ingestion pipeline. It does not mean that no data leaves your network. Query results can contain log fields, identities, and other sensitive information. Case summaries and chat messages also carry information derived from those records.

In CloudThinker's self-hosted Worker model, local file and shell work runs on the Worker, while the agent runs in CloudThinker Cloud and receives results. A local Worker or a private network connection alone does not make model processing local.

Before connecting Wazuh, agree which fields may be returned, where those results will be processed, and how long sessions, cases, and learned context may be retained. Apply the same review to external reputation lookups and any Slack, Teams, or SOAR destination. If all log-derived information must remain on premises, that requirement needs a validated deployment design before this workflow is enabled.

Use private connectivity where required. It controls the network path; processing location and retention remain separate decisions.

Follow the evidence, then decide

01Signal

Alert

A Wazuh rule fires at or above the level you choose.

02In place

Investigate

Queries Wazuh for the same IP, user and host.

03Noise out

Clean

Folds duplicates, sets aside known-benign, scores the rest.

04To SOAR

Case

Evidence, uncertainty, and next steps for review.

05Learn

Tune

Proposes a Wazuh rule change as a merge request.

Reference workflow. Analyst feedback informs future investigations; each case still needs fresh evidence.

1. Choose a starting signal. A rule level can help prioritize which alerts start investigations. For example, start at level 7 while still allowing evidence queries to include lower-level events. A level 3 successful login may be essential context for a higher-level brute-force alert.

2. Keep competing explanations open. The activity might be failed internet noise, an approved test, or unauthorized access. Ask what evidence would support or contradict each explanation before assigning a verdict.

3. Query across the relevant sources. Search for the source IP, host, identity, and time window in Wazuh. SSH and CloudTrail use different field names, so map entities explicitly and check the account and session context. Review every result page needed for the investigation; a truncated search is incomplete evidence.

Alert search is also limited by what Wazuh actually stores. Events that never produced an alert may require another approved evidence source or separately configured archives. An empty result does not establish that an action never happened.

4. Add operational context. Check asset criticality, change windows, approved scanners, and the identity owner's explanation. Use reputation providers only for indicators permitted by your data policy. Reputation is supporting evidence, not a verdict by itself.

5. Record the conclusion and the gaps. The case should distinguish a confirmed incident, benign activity, and an unresolved hypothesis. Include the searched time window, evidence references, logging gaps, and the reason for escalation or closure. Uncertainty should reach the analyst with the case.

For this example, the successful login strengthens the compromise hypothesis. It takes additional evidence, such as the owner confirming that the session and new key were unauthorized, to support a confirmed verdict.

From alert stream to a reviewable case

01Raw Wazuh alerts

Every rule hit across AWS, cloud and on-prem.

02After dedupe

Same rule, same source, same window becomes one.

03After known-benign

Approved scanners, backup jobs, change windows.

04After correlation

Related identity, session, host, and time evidence.

05Cases in the SOAR

Each with a verdict, evidence and next action.

Illustrative workflow, not measured results. Bar lengths do not represent a customer reduction rate. Preserve the reason for each grouping or suppression.

Grouping makes the queue useful when each step remains explainable:

Deduplicate repeated rule hits for the same source and target within a defined window. Preserve the count and original references.
Review known-benign activity against approved entries with an owner and review date. Recheck behavior when the context changes.
Correlate related evidence using identity, host, session, and time, with shared IPs treated cautiously.
Prioritize using asset impact and evidence quality alongside the Wazuh rule level.

The case below illustrates the handoff while the compromise hypothesis is still awaiting analyst confirmation. The counts demonstrate grouping, not a measured reduction in customer alert volume.

Case SEC-2481Needs reviewSeverity highsource

Potential credential compromise: SSH brute force on bastion-01, then an AWS console login and a new access key from the same IP.

Illustrative grouping: 41 Wazuh alerts in one case, with 2 separate alerts awaiting a known-benign review.

T1110.001 Password GuessingT1078 Valid AccountsT1098.001 Additional Cloud Credentials

01Evidence

02:14rule 5712, sshd brute force on bastion-01 (38 alerts)
02:31rule 5715, sshd login success, user ops.deploy
02:40CloudTrail ConsoleLogin, ops.deploy, no MFA
02:43CloudTrail CreateAccessKey for ops.deploy
intelReputation not checked in this example. The IP is a documentation placeholder.

02Proposed response

Deactivate the new access key for ops.deploy (AWS IAM)Pending
Block 203.0.113.45 on bastion-01 (Wazuh active response, firewall-drop)Pending
Force password reset for ops.deploy and open SEC ticket in JiraPending

Illustrative case · Original evidence referenced in Wazuh

Illustrative interface and synthetic evidence, not a customer result or a live product screenshot.

A SOAR handoff should include a stable case identifier, verdict, severity, affected entities, evidence references, and proposed actions. Send updates to the existing case as evidence arrives. Make retries idempotent so they don't create duplicate incidents.

Keep references to the original records in Wazuh. The case may also contain selected event fields and summaries, so give it an explicit access and retention policy rather than assuming it contains only links.

Serious cases need a shared timeline

For a high-priority case, an OnCall war room brings the investigation and response decisions into one place. With the relevant integrations configured, use the case severity to trigger escalation and route it to the on-call team and asset owners.

War room SEC-2481ContainingSeverity highfrom SOAR, source

01Timeline

02:14Wazuh rule 5712, brute force on bastion-01
02:31Wazuh rule 5715, login as ops.deploy
02:40CloudTrail ConsoleLogin from the same IP, no MFA
02:43CloudTrail CreateAccessKey for ops.deploy
02:44Case SEC-2481 in SOAR, severity high, room opened
02:46SecOps on-call paged, IAM and infra owners added
02:49IAM owner confirms the session and new key were unauthorized
02:51Access key deactivated, approved by SecOps on-call
02:53firewall-drop on bastion-01, approved by infra owner

02In the room

SOSecOps on-callpaged, joined 02:47
IACloud IAM ownerfrom asset map
INInfra owner, bastion-01from asset map
CloudThinkerinvestigating

03Asked in the room

SecOps on-call

Did ops.deploy touch anything else in the last 24 hours?

CloudThinker

The available records show an S3 ListBuckets call at 02:47. Object-level logging coverage is unverified, so object reads or writes cannot be ruled out.

Mirrored to #inc-sec-2481SOAR case in sync

Jira SEC-2481 in sync

Illustrative continuation after owner confirmation. Routing and synchronization require configured integrations.

In this illustrative continuation, the account owner confirms the activity was unauthorized before containment is approved. The timeline records the decision, approver, action, and result.

Questions asked in the room need the same evidence discipline as the initial investigation. “Did this identity access any S3 objects?” requires object-level logging coverage. CloudTrail does not log data events by default, so management events alone cannot rule out object reads or writes. AWS documents the distinction here.

Configure which updates should reach chat, the SOAR, and Jira, and define which system owns each status. At closure, use the timeline to draft the postmortem, then have the incident owner review the findings and remaining gaps.

How this complements existing playbooks

Wazuh already supports rule-based correlation. SOAR platforms can enrich, branch, loop, and deduplicate. Cortex XSOAR, for example, documents both conditional playbook tasks and a deduplication playbook.

CloudThinker's role is to help choose and pursue follow-up questions as evidence changes. That can reduce the work of maintaining a separate investigation branch for every scenario. Existing playbooks remain useful for repeatable procedures and controlled execution.

Responsibility	Existing SIEM and SOAR	CloudThinker's role in this workflow
Detection	Rules and configured correlations	Investigate the evidence around a detection
Investigation	Enrichment, conditions, scripts, and analyst work	Propose and test follow-up questions
Case handling	Grouping, deduplication, and routing	Prepare an evidence-linked case with uncertainty recorded
Response	Execute configured procedures	Propose actions within the approval policy

Learn without creating blind spots

Analyst feedback is useful context for the next investigation. It should not become a permanent verdict for every superficially similar alert. Recheck the asset, identity, timing, and approval whenever a pattern returns.

For recurring benign activity, use that evidence to propose a reviewed Wazuh rule change. Include the supporting cases, affected scope, expected impact, owner, and review date. Test the change against representative malicious and benign events before deployment.

An expiry written in an XML comment does not enforce itself. Track review dates in the rule-management workflow and define how overdue exceptions are removed or reapproved. Keep rule deployment under the detection team's control.

Start with a measured pilot

1. Establish the data boundary. Confirm permitted result fields, processing locations, retention, and external destinations. Configure scoped read-only access through Connections, with separate permissions for Wazuh alert searches and server inventory. Verify the required events are collected and searchable.

2. Review a historical sample. Use a fixed period and compare proposed cases with an analyst-reviewed set. Include benign events, confirmed incidents, and ambiguous cases. A useful starting prompt is:

“Review last week's Wazuh alerts for this environment. Group related activity, explain each proposed case, and identify missing evidence. Include lower-level events when they provide context.”

3. Start with propose-only. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval. During the pilot, create cases for review while leaving containment to people. Measure duplicate cases, incorrect benign verdicts, missed incidents, and analyst review time. A shorter queue alone is not evidence of better detection.

4. Add response one action at a time. Validate escalation routing and owner lookup. Introduce approved actions only after checking permissions, audit records, and failure handling. Keep Wazuh investigation access read-only; response execution needs separately authorized permissions.

Book a discovery call to map this workflow to your Wazuh deployment, confirm integration support, and agree what a successful pilot should demonstrate.