AWS & Kubernetes / Detection validation

Find the attacks your detections miss.

For cloud security and detection teams: rehearse adversary techniques in disposable labs in your test account, inspect the alerts your SIEM sends back, and improve your detections through retesting.

Book a demo See an example

Start with a conversation. No cloud connection needed for the demo.

Inside an emulation

One technique. A concrete detection question.

Can your team distinguish routine Windows administration from a burst of credential-hunting requests?

Credential hunting through EC2 password requests

Retrieve EC2 Windows Password Data / AWS atomic emulation

SCENARIO WALKTHROUGH

Attack behavior

30 API requests.
No target instances required.

The emulation calls ec2:GetPasswordData against generated fake instance IDs. It reproduces credential-hunting behavior without provisioning Windows instances or retrieving real administrator passwords.

The expected API response is InvalidInstanceID.NotFound. The detection question is whether repeated failed requests from one principal are recognized as suspicious activity.

Scenario configuration

API         ec2:GetPasswordData
Requests    30
Targets     Generated fake instance IDs
Resources   No target infrastructure required
Response    Scenario-specific IR playbook
Content     Sigma detections and KQL detections

Configuration of the shipped emulation. Detection results depend on the telemetry, rules and alert integration in the environment being tested.

01 / EMULATE

Reproduce the burst

Execute the atomic technique through MayaTrail and inspect the API responses in the execution output.

FOCUSED ATTACK BEHAVIOR
02 / VALIDATE

See what your SIEM caught

Your SIEM runs the detection rules and forwards fired alerts to MayaTrail. We match those alerts to the emulation, highlight techniques with no matching alert, and suggest detection content for you to review and deploy in your SIEM.

ALERT EVIDENCE + DETECTION GAPS
03 / INVESTIGATE

Follow the evidence

Use the playbook to inspect the caller, request rate, error codes and target instances. Establish whether any target was real before treating credentials as exposed.

SCENARIO-SPECIFIC GUIDANCE
04 / IMPROVE

Tune and retest

Review telemetry and alert delivery, adjust the detection for your environment, then repeat the exercise and compare the supporting alert evidence.

REPEATABLE VALIDATION
Where does detection happen?

Your SIEM evaluates the telemetry and runs the detection logic, including any correlation rules. MayaTrail receives the fired alerts you forward; it does not run those rules against your raw logs. It matches received alerts to the exercised techniques and shows the supporting evidence and detection gaps.

A technique with no matching alert needs investigation: the cause could be a missing rule, missing telemetry or an alert-delivery problem. MayaTrail provides suggested detection content and response guidance. Your team reviews and applies changes in the SIEM, then repeats the exercise to validate the result.

Detection gaps

The gap is the finding. Everything else supports it.

For each exercised technique, inspect the matching alerts, any detection gaps and anything left unmeasured.

Fired

Your detection saw it

Inspect the matching alert and whether it identifies an exact rule or supports detection of the technique. Keep the rule, and retest it later.

Detection gap

No matching alert observed

The technique ran, but MayaTrail received no matching alert. Investigate the detection rule, telemetry and alert delivery to establish the cause.

What MayaTrail provides
  • Suggested detection content with supported SIEM exports
  • Relevant preventive policies for your team to review
  • A response playbook to guide investigation
Unmeasured

Not enough evidence

Missing integration or insufficient evidence leaves the outcome unknown. Untested rules are kept separate from failed detections.

Apply changes in your detection stack, then repeat the exercise. Compare alert evidence across equivalent exercises to validate improvements and investigate possible regressions.

Start with an atomic technique. Build toward a campaign.

Two examples from a growing catalog: a focused logging-control exercise, and a longer campaign across multiple cloud services.

One of many atomic scenarios

Stop CloudTrail logging

The catalog describes stopping a lab trail, then restoring logging after 30 seconds. It is a focused exercise for investigating audit-logging tampering.

One of many campaigns

AMBERSQUID

The catalog combines malicious-container execution, persistence, multi-service mining behavior and defense evasion into a longer campaign. Documented and simulated phases are identified in the product.

One exercise. A repeatable loop.

  1. 1
    Deploy a lab

    Provision a disposable vulnerable stack in a dedicated test account.

  2. 2
    Run the emulation

    Replay a real adversary technique, step by step.

  3. 3
    Find the detection gaps

    Forward detection alerts from your SIEM. Inspect matching evidence and separate missing alerts from unvalidated results.

  4. 4
    Close the gap

    Use supported detection rules, preventive policies and response playbooks to address findings. Retest, then verify lab cleanup.

Built to help you act on the findings.

Incidents & security research

Campaigns and research scenarios

Rehearse attack chains based on documented incidents and security research. Research-based scenarios such as ECScape sit alongside incident-based campaigns, with their origin and scope identified in the product.

AWS and Kubernetes emulations

Focused technique emulations

Test a specific behavior across cloud and Kubernetes. Choose an atomic technique, inspect its ATT&CK mapping and supporting content, and repeat the exercise when your controls change.

Sigma · KQL · Splunk · OpenSearch

Detection content that ships

Review shipped Sigma and KQL content, author your own rules, and test them against synthetic events. Export supported rules to Splunk SPL or OpenSearch for use in your detection stack.

Signed webhook

Evidence for your own detections

Match forwarded alerts to a shipped rule or an exercised technique. Inspect the evidence and match confidence; an alert that only shares the observation window is never counted as a pass.

Tracked run after run

Coverage history

Compare exercises to see detections that started or stopped firing, with supporting alert evidence. Keep unmeasured rules separate from observed detection gaps.

Read only

Attack graph

Explore privilege-escalation paths through existing cloud identities and permissions. Link a discovered path to the emulation that rehearses it.

Policies

Guardrails

Review SCPs, RCPs and other preventive policies relevant to your findings, from restricting encryption-key deletion to blocking unapproved regions. Assess scope before enforcing a control.

Playbooks

Incident response, written down

Give analysts investigation and response guidance across identity, storage, databases, Kubernetes and more. Review and adapt the documented steps for your environment.

TTL · scoped role · audit log

Scoped access and lab lifecycle controls

Temporary access through a scoped cross-account role, pre-run cost estimates, scheduled cleanup and lifecycle audit entries. Review permissions before connecting and verify that cleanup completes.

For the security teams that own cloud.

From the engineer tuning a rule to the security lead deciding what to improve next.

Validate and improve

Detection and cloud security engineers

Rehearse supported techniques, inspect alert evidence and retest detection changes. Pair findings with relevant preventive controls.

SOC analysts and responders

Use exercises and response playbooks to practice investigation. Detection evidence is one input; human response readiness needs its own assessment.

Decide with evidence

Security leads, CTOs and CISOs

See what was tested, the evidence observed, remaining uncertainty and what changed after remediation.

A complement to your security program

Repeatable lab exercises complement posture reviews and penetration testing. Results apply to the exercised environment and techniques, not every path through your production estate.

Start with one useful exercise

See the workflow. Then choose your next step.

Tell us what you want to validate. We will walk through the platform and agree a practical evaluation with your team.

  1. 01 / Discuss your setup

    Share your cloud platform, detection stack and the problem you want to investigate.

  2. 02 / Take a guided demo

    Explore the emulations, detection content and evidence workflow. You do not need to connect AWS for this conversation.

  3. 03 / Agree an evaluation

    Discuss exploratory access, lab availability and one guided exercise. Validate your own detections when your test account and SIEM integration are ready.

Email us for a demo

Prefer to write directly? admin@mayatrail.tech
Include your cloud, SIEM and evaluation goal.

Services

Need help beyond the platform?

Cloud assessments, red teaming, response exercises and hands-on training are separately scoped engagements. Platform onboarding and ongoing product support are included in the annual subscription.

Explore security services

Pricing

Pricing is set with you. Write to us and we will scope it.

Every engagement and plan depends on your cloud accounts and your detection stack, so the quickest way to a number is to ask. Write to admin@mayatrail.tech and tell us what you want to run.

Start with a demo and decide whether a scoped assessment or an annual platform subscription fits your needs. We agree the evaluation scope, access requirements and deliverables with you first.

Cloud detection assessment
Contact us one-off · scope and timing agreed with you
  • Our engineers run the engagement. It is consulting work, scoped to one cloud account of yours and reached through a scoped cross-account role. No long-lived keys, ever.
  • We review your posture, identity and logging coverage.
  • You get supported detection content and recommendations for the findings, with available SIEM export formats agreed in scope.
  • Scope, deliverables, access and procurement requirements agreed before work begins.
Discuss an assessment
What you walk away with
  • A written report on your posture, identity and logging coverage, and where the gaps are
  • Relevant Sigma rules with supported Splunk SPL or OpenSearch exports
  • Relevant incident-response playbooks and remediation guidance
  • The evidence behind every finding, so you can check our working
  • A list of what the review did not cover, stated plainly

An assessment is optional. Any follow-on subscription is scoped and quoted separately.

Then keep it running

Logging and detection changes can affect rules that worked before. Repeat and schedule exercises with your annual plan, then compare received alert evidence to investigate possible regressions.

Team

A security team that wants repeatable exercises, with onboarding and product support.

Contact usannual subscription · account scope agreed
  • Hosted, with the full campaign and single-technique library
  • Scheduled emulations, queued for the date and time you choose
  • Regression detection: rules that used to fire and stopped
  • Evidence reports, exportable
  • Detection exports in supported SIEM formats
  • Onboarding and ongoing product support included
  • Re-run allowances and connected-account scope agreed in your plan
Talk to us

Enterprise

Several accounts, several teams, and someone who has to sign off on the evidence.

Contact usannual subscription · multiple teams and accounts
  • Everything in Team
  • Multiple connected accounts
  • Custom campaigns built for your environment
  • Named engineer, quarterly review
  • Security review and procurement support
Talk to us

How the billing actually works

We agree the subscription scope before you commit. Cloud infrastructure costs are separate from the platform subscription.

Validate the environment you actually exercise

Customer validation uses a disposable lab in your test account, with telemetry routed to your detection stack. A demonstration lab explains the workflow; it does not establish coverage in your environment. Agree the account, permissions and logging configuration before connecting.

Account scope is part of your quote

Tell us which accounts and teams need access. Your quote will state the included scope, support and terms for adding accounts.

Retesting belongs in the evaluation

Agree an exercise you can repeat after a detection change. Platform usage terms are set in your plan, and each exercise can incur cloud infrastructure costs.

Review cloud costs before provisioning

Infrastructure in your account appears on your cloud bill. Costs depend on the scenario, region, services and duration. Review the estimate before deployment, use scheduled cleanup and verify resources were removed.

We never hold long-lived keys

Access is a scoped cross-account role, assumed at run time with short-lived credentials. You can revoke the role trust to stop new sessions. Review active-session revocation separately with your AWS administrator.

Fair questions

Including the ones that are awkward for us.

What data does the alert integration use?

The validation workflow receives detection alerts forwarded by your SIEM, rather than bulk raw logs. Alerts can still contain sensitive fields. Before connecting, agree which fields are sent, who can access them, retention and deletion requirements, and the permissions used for the exercise.

Do we need a working SIEM to get started?

No SIEM is needed for a conversation or guided product walkthrough. To validate your own detections, you need the relevant telemetry in your SIEM and a verified alert-forwarding integration. An emulation without that integration can demonstrate execution, but cannot prove that your detections fired.

Is there a free hosted tier?

There is no public free hosted tier. Start with a guided demo, then discuss exploratory access and lab availability. Customer-connected exercises require agreed cloud access and SIEM setup; browsing and the initial demo do not.

Which clouds and platforms does it cover?

We started with AWS and Kubernetes, and went deep on both. For AWS that includes incident-based campaigns, research-based scenarios and single-technique emulations. For Kubernetes it is emulations of cluster-level attacks. Azure and GCP are next on the roadmap. Emulations package the attack behavior and supporting content, with infrastructure where the scenario requires it. Scope and prerequisites are stated in the product.

Do you do anything destructive to our environment?

Emulations act on disposable resources provisioned for the exercise, and some scenarios intentionally change or destroy those resources. Use a dedicated test account and review the scenario permissions, boundaries and costs first. Cleanup is scheduled; confirm that it completes and investigate any remaining resources.

What if the assessment shows our coverage is fine?

Then you have evidence for the techniques and environment assessed. Decide whether recurring exercises, detection changes or response practice justify a subscription. A successful exercise does not establish complete coverage.

What can you not test for?

Each campaign declares its techniques and scope. Lab evidence cannot establish coverage for untested techniques, every production attack path or the quality of a human investigation. Without a working alert integration, detection outcomes remain unvalidated. Review unsupported and unmeasured items alongside the findings.

Find out what your stack misses

Tell us what you run for cloud security and detection. We will discuss a useful first exercise, the evidence it could produce and what it would leave untested.

Discuss an assessment Inspect the scenario