MORANI HUNTING GROUNDS.
THE CELL IS YOUR TERRAIN.
Register, get assigned a cell, and attack a system another team built against a brief you can read right now. No proposal round. Registration opens 21 September.
MORANI HUNTING GROUNDS.
Your cell is the terrain.
Attack one assigned application cell within a scheduled window and report the findings to a professional standard.
Morani is the hunting ground: register, get assigned to one application cell, and learn its terrain before the attack window opens. Morani teams do not go through the proposal round.
Nine kinds of target.
Read what they had to get right.
You will be assigned one of these. Every Blue team building it was given the same requirements you are reading now. Your job is to find where they fell short.
The customer web front door: balances, transaction history, statements, transfers and profile.
// What_You_Will_Try- Authentication bypass, session fixation and hijacking, horizontal privilege escalation between customers, business-logic abuse of the beneficiary and transfer flow, and forced browsing to unlinked endpoints.
- Server-side authorisation on every request.
- Session lifetime, invalidation and secure cookie attributes.
- A cooling-off period or step-up authentication before a newly added beneficiary can receive funds.
- Defence against injection, cross-site scripting, cross-site request forgery, insecure direct object reference and open redirect.
- Rate limiting and lockout on all authentication and money-movement paths.
- Statements generated server-side with authorisation checked at generation, not merely at link time.
- A full audit trail the customer can retrieve.
The same bank for a client that cannot be trusted to enforce anything, on a device that may be compromised.
// What_You_Will_Try- Token theft and replay across devices, refresh-token abuse, idempotency and race-condition attacks on transfers, mass assignment, and API enumeration for unprotected endpoints.
- Device registration and binding so a token issued to one device cannot be replayed from another.
- Short-lived access tokens with refresh-token rotation and reuse detection.
- Transaction signing or step-up confirmation independent of the session token.
- Idempotency keys on every state-changing endpoint.
- Strict schema validation that rejects unknown fields rather than ignoring them.
- Per-device and per-account rate limiting.
- No sensitive data in URLs, logs or error messages.
The identity provider every other cell trusts. The most security-dense brief in the catalogue.
// What_You_Will_Try- Credential stuffing, user enumeration through timing or message differences, MFA bypass through flow manipulation, token forgery and algorithm confusion, password-reset token prediction or reuse, and race conditions in enrolment.
- Credential storage using a modern memory-hard password hash with per-user salt and a breached-password check.
- Multi-factor authentication with at least two second factors, plus recovery codes issued once and stored hashed.
- Signed short-lived tokens with audience and issuer claims, key rotation, and a published JWKS endpoint.
- Token revocation and introspection so a compromised session ends enterprise-wide within seconds.
- Password reset that does not disclose account existence, uses single-use time-limited tokens and invalidates all sessions.
- Progressive lockout resistant to both targeted brute force and credential-stuffing sprays.
- Risk signals on every authentication: new device, new location, impossible travel, unusual hour: emitted even when the login is allowed.
- A tamper-evident audit log of every identity event.
The service that actually moves money: the ledger, the rules that govern a transfer, and the controls that stop money moving when it should not.
// What_You_Will_Try- Race conditions and time-of-check-to-time-of-use attacks on balance, negative and precision-abuse amounts, currency and rounding manipulation, replay of payment instructions, limit bypass through decomposition, and forging or replaying the settlement webhook.
- A double-entry ledger where balance is derived from entries and never from a mutable field.
- Atomic, isolated transfer execution provably safe under concurrent requests.
- Idempotency on every payment instruction with a defined retention window.
- Per-transaction, daily and velocity limits evaluated server-side.
- A rules-based fraud check producing allow, review or block with a recorded reason, and a reviewable queue.
- Maker-checker approval above a defined threshold where the approver may not be the initiator.
- Reversals and refunds as compensating entries, never as mutation of history.
- An append-only transaction log with independently verifiable sequence integrity.
- End-of-day reconciliation that proves the ledger balances.
Application to decision: a multi-stage workflow with document upload, automated scoring, human approval and a disbursement instruction.
// What_You_Will_Try- Workflow-stage skipping, insecure direct object reference across applicants, malicious file upload and path traversal, tampering with declared income or score inputs, and privilege escalation from applicant to assessor or approver.
- Stage transitions enforced server-side and impossible to skip by manipulating client state.
- Document upload with content-type verified by inspection rather than by extension, size limits, malware scanning, and storage in the private bucket.
- Documents served only through authorised, short-lived, single-use links with non-guessable references.
- A deterministic credit-scoring component with a recorded input snapshot so any decision can be reproduced.
- Segregation of duties between applicant, assessor and approver.
- An approval authority matrix by amount, enforced in code, with an escalation path.
- Disbursement issued only after approval, signed, idempotent, and impossible to trigger from the applicant's session.
- Defined retention and deletion for the personal and financial documents collected.
The staff-facing system where tellers, supervisors and administrators service customer accounts. The highest-privilege application in the enterprise.
// What_You_Will_Try- Privilege escalation between staff roles, forced browsing to administrative functions, maker-checker bypass through self-approval or replay, mass data extraction through search and export, and abuse of elevation flows.
- Role-based access control with at least four staff roles whose permissions genuinely differ, enforced server-side for every action and never merely hidden in the interface.
- Maker-checker on every high-impact action, with a different and more senior checker.
- Mandatory structured reason codes on every privileged action.
- Just-in-time elevation, time-boxed and automatically revoked.
- Data minimisation by role, with masked account and identity numbers and unmasking as a separately audited action.
- Administrative access restricted by network origin.
- Session controls suited to a shared workstation: short idle timeout, explicit lock, concurrent-session limits.
- A tamper-evident audit log viewable by an auditor role that cannot modify customer data.
- Detection and alerting on insider-abuse patterns: bulk record access, out-of-hours activity, repeated access to one customer, and self-servicing of an employee's own accounts.
Free text and file attachments moving between two parties at very different privilege levels, with identity verification under pressure.
// What_You_Will_Try- Stored cross-site scripting aimed at agents, insecure direct object reference across tickets, leakage of internal notes into the customer view, malicious attachments, and social-engineering flows that trick the system into treating an unverified caller as verified.
- Ticket lifecycle with an immutable conversation thread.
- Two-sided messaging where internal notes are provably invisible to the customer.
- Attachment upload from both sides with type verification by inspection, size limits, malware scanning, and rendering that cannot execute in the browser.
- Structured customer identity verification before any account-affecting action, with method and outcome recorded on the ticket.
- Output encoding everywhere customer-supplied text is rendered, including the agent interface: the higher-value cross-site scripting target.
- Rate limiting on ticket and message creation.
- A defined, enforced boundary: anything touching money or credentials is handed to the back-office portal rather than performed here.
- Detection and masking at ingestion of credentials or card numbers pasted into a ticket.
Near-real-time scoring of transactions from the payments service, with case management for analysts and a feedback loop.
// What_You_Will_Try- Score evasion through transaction shaping, case tampering, suppression of alerts, and poisoning of the feedback loop.
- Scoring that consumes the payments ledger rather than duplicating it.
- Analyst role-based access control and case-level authorisation.
- Tamper-evident case history where decisions cannot be rewritten.
- Customer notification that does not itself disclose account detail.
- An analyst feedback loop that the customer cannot poison, and integrity protection on the rule set itself.
Outbound email, SMS and push, plus server-generated account statements.
// What_You_Will_Try- Account enumeration through notification behaviour, statement link prediction, template injection, and notification flooding used as cover for other activity.
- Authorisation checked at generation time, not at link time.
- Short-lived signed document links that are not guessable or enumerable.
- Template rendering safe against injection.
- Data minimisation in every message body.
- Rate limiting, and a full delivery audit trail.
Full application briefs, with every security requirement a judge will check, are issued in the welcome pack when registration completes.
One cell. One window.
Professional standard.
One Assigned Cell
You attack the cell you are assigned, within its scheduled window. Nothing else in the range is in scope.
Two Red Teams Per Cell
Another Red team attacks the same cell. Your activity must be attributable to your team.
Report, Not Just Exploit
Findings are reported to a professional standard. The exploit is half the score; the write-up a judge can act on is the other half.
The full rules of engagement, the evidence standard and the report template are issued with your cell assignment in the welcome pack.
No proposal.
Plenty to prepare.
Have every registration item ready: the nine-item checklist below.
Read all nine briefs. Your cell could be any of them.
Agree your team's attribution discipline now: how every request your team sends can be traced back to you.
Decide who writes. A finding nobody can reproduce from your report scores as nothing.