Account takeover in MENA: how attackers actually do it in 2026

This post is a field report. We are not going to walk through generic threat-actor taxonomies. We are going to walk through the attack patterns we see most often in MENA enterprise environments in 2026, in roughly the order of frequency, with notes on what works against each one. Read it as a checklist, not as a narrative.

Why MENA specifically gets hit this way

A few regional factors shape the threat landscape:

• Mobile-first identity. Most authentication in MENA terminates in a mobile number. That makes the mobile number the highest-value target.
• Cross-border traffic. Roaming, multi-SIM, and travelers between Gulf markets are normal. Attackers use this to hide attack origin.
• WhatsApp as a primary support channel. Social-engineering vectors that look weird in a Western customer-support context look normal here.
• High variance in carrier identity-API maturity. Some operators expose strong identity signals; some do not. Attackers route through the weaker ones.
• Fast-growing fintech and BNPL. New money-movement products with new account surfaces, often with risk controls still maturing.

None of this is a moral statement. It is the operating reality. The defender stack has to be built for it.

Pattern 1 — SIM-swap-adjacent porting fraud (still the largest single category)

The customer's mobile number is ported to an attacker-controlled SIM, usually via social engineering of the carrier or via an insider at a retail point of presence. The attacker then receives the customer's OTP messages and takes over any account gated by SMS.

What we see in 2026 versus 2024:

• Volume is up, not down, despite carrier countermeasures.
• The attackers are more patient — they often wait 48–72 hours after the port before attempting the account access, to evade the carrier's "recent port" flags.
• Targets are concentrated in fintech, brokerage, and high-balance personal banking. BNPL accounts are also increasingly targeted because of recurring payment-method access.

What works: Any identity check that depends on the device currently associated with the number, not on a code sent to the number. Silent mobile verification that validates the device-to-number binding at the moment of the action catches the porting because the device is not the customer's device. Layered with risk scoring on the post-port window, the success rate of this attack falls dramatically.

What does not work: Any control that depends on "the customer received a code." The attacker is receiving the code.

Pattern 2 — Credential stuffing with reused MENA-specific password leaks

Large credential dumps that include MENA enterprise users are now consistently traded in attacker forums. Reuse rates are high enough that mass-login attempts produce material rates of successful sign-in.

What we see:

• The dumps are increasingly regional. 2020-era global dumps are still in use, but 2024–2026 dumps that include specific MENA fintech and government-adjacent services are now what attackers prioritize.
• Velocity is throttled. Sophisticated attackers no longer hit the login endpoint with thousands of requests per minute — they spread it across thousands of source IPs at 1–3 attempts per IP, slow enough that volumetric rate-limiting misses it.

What works: Identity-aware velocity scoring (the same identity hitting many endpoints, even across IPs). Anomaly detection on the device-to-identity graph (the same device suddenly testing many identities). A trust score that incorporates the verified mobile identity alongside the password — so even a correct password against an unknown device does not get auto-approved.

What does not work: IP-based rate limiting alone. The attacker has more IPs than you have block-list slots.

Pattern 3 — Account-recovery flow exploitation

The attacker does not try to log in. They trigger the password-reset or account-recovery flow, then exploit weaknesses in the recovery path — typically the mobile-number verification step that grants access without re-authenticating against the original credential.

The vulnerability surface:

• Lax mobile-number change rules. If the recovery flow lets the user "update" the number on file using only a code sent to the new number, the attacker who controls the new number wins.
• Email-only recovery for accounts with mobile primary auth. A weaker email factor undermines the stronger mobile factor.
• Help-desk social engineering. Many recoveries that "succeed" did so because a support agent waived a control.

What works: Recovery flows that require the original verified mobile identity to authorize a change of factor, not just a code-on-the-new-factor. A risk-aware step-up on any account-state change. An audit trail on every recovery action that makes the social-engineering vector visible.

What does not work: Email-only recovery as a backstop for mobile-primary auth. Help-desk override policies without explicit risk-scoring sign-off.

Pattern 4 — Session-replay against signed-in customers

Less common but rising fast. The attacker captures a customer's session token via malicious extension, phishing-as-a-proxy, or compromised public Wi-Fi, and replays the session against the application from their own device.

What we see:

• The capture vectors are increasingly mobile (malicious app on the customer's phone) rather than desktop. Browser extensions are now a secondary vector.
• The replay window is shrinking — attackers act fast to evade session-binding controls.

What works: Session binding to a continuously-verified mobile identity. If the session token can be replayed but the underlying identity check happens on every sensitive action, the replay is contained. Continuous risk scoring inside the session, not just at sign-in, catches the device-change at the moment of action.

What does not work: Long-lived session tokens with no continuous re-evaluation.

Pattern 5 — Coupon, promo, and bonus farming

Not technically account takeover, but worth including because it sits on the same defender stack. Multiple accounts on a single device, sometimes hundreds, exploit referral bonuses, sign-up promos, or limited-time discounts.

What we see:

• Farming operations are professionalized. There are crews running thousands of accounts across mobile emulators, residential proxy networks, and disposable phone numbers.
• Disposable mobile numbers from secondary markets are a primary tool. Cheap enough that the farming economics still work even with detection.

What works: Identity graph at the device level — same device, many accounts is an immediate flag. Behavior signals on the early-account window (no real engagement, just promo consumption). Mobile identity intelligence to deduplicate against verified-once-anywhere graphs.

What does not work: Account-only deduplication. Email-only deduplication. IP-only deduplication. The farmers route around each of these individually.

Pattern 6 — Insider-enabled account compromise

Less frequent than the others but disproportionately costly. A current or former employee with access to internal customer tooling makes an account change at the attacker's request.

What we see:

• The internal control vulnerability is usually in the support tooling, not the primary IAM. Support agents have powerful capabilities ("update customer mobile", "reset password without verification") that are hard to monitor in real time.
• Detection is often post-fact — the customer reports an unauthorized change days or weeks later.

What works: Internal step-up on customer-account changes. Approval workflows on any change that grants account access without re-authentication. Insider-aware audit review on the support-tooling action log. Identity-aware logging that ties every internal change to a customer-side identity event.

What does not work: Trusting internal access by default. The threat model includes the inside.

The defender stack that holds up across all of these

We have seen a lot of defender stacks. The pattern that works across the categories above shares these properties:

• Mobile identity intelligence at the auth layer (not just an OTP, an actual verified-device check).
• Continuous trust scoring that re-evaluates inside the session, not just at sign-in.
• Identity-aware velocity and anomaly detection that operates on the device-to-identity graph, not just on IP and request rate.
• Risk-aware step-up that triggers additional verification on the actions where risk concentrates — payouts, recovery flows, account-state changes.
• Audit trails that can be correlated across customer-side and internal-side events, so insider-enabled compromise is visible.
• Honest fall-through to a manual identity check when the silent path cannot complete — most attackers will not stick around for the manual step because the device binding is too hard to fake.

A note on threat intel

The attack patterns above are not theoretical. They are observed in production across MENA enterprise environments in the months immediately before this post. The specific volumes, target verticals, and attack tooling shift on a quarterly cadence. If you operate a customer-facing product at any scale in MENA, the patterns above are happening to your customers today, regardless of whether your detection is surfacing them.

The Authmatech security team keeps an internal log of pattern shifts and is happy to brief enterprise customers on what we are seeing in their specific vertical. Bring your current detection coverage; we will tell you honestly where the gaps line up against the patterns above.

---

The shorter version: the attack patterns in MENA in 2026 concentrate on the mobile identity layer. Defenses that depend on "we sent the customer a code" are increasingly being routed around. The defender stack that holds up combines verified mobile identity, continuous trust scoring, identity-aware anomaly detection, and honest fall-through paths. The patterns are observable; the controls are buildable; the work is in disciplined execution.