Red Team Operations in Mumbai · BFSI

Red teaming Mumbai BFSI is not a wider VAPT and the audit committee should not buy it as one. The board-level question is narrow and specific: can a determined attacker — funded, patient, willing to spend three months on initial access — reach money movement, market data or customer accounts inside the bank before the SOC notices, and what would the bank actually do when the first alert fires? Macksofy answers that question with goal-based, intelligence-led adversary simulations that combine OSINT, spear-phishing tuned to the BKC and Nariman Point exec calendar, physical pretexting against actual BFSI office buildings, and the technical exploitation chain that lands once initial access is established.

Typical scenarios for a Mumbai private bank or large cooperative bank: SWIFT or treasury reach from a compromised back-office user in the Lower Parel ops centre; ATM-network compromise via a card-personalisation vendor laptop, FIN8/Hidden-Cobra TTPs explicitly modelled; market-data tampering on a broker desk by way of the Refinitiv/Bloomberg feed-handler; bulk customer-account access through the call-centre CRM at the Goregaon or Powai back-office; and ADCS abuse paths (ESC1, ESC4, ESC8) from a junior treasury-ops user to Domain Admin on the corporate forest backing core banking. Each scenario is mapped to TIBER-EU-style threat-intelligence and to the RBI Cyber Resilience expectations the board reports against — the November 2023 RBI Master Direction on IT Governance and the underlying Cyber Security Framework circular DBS.CO.CSITE.BC.11/33.01.001/2015-16.

Engagements run six to ten weeks end-to-end. The first two weeks are intelligence prelude — OSINT against BKC, Lower Parel and Nariman Point exec teams, vendor mapping against the bank's known third-party ecosystem (Tata Communications, Sify, Wipro Infrastructure Services for managed-services trails; printer fleets, badge-system vendors and pantry contractors for physical pretexting), and credential-leak harvesting against the bank's exact TLDs using DeHashed, IntelX and our own dark-web monitoring feed. Initial-access campaigns then run a parallel split — spear-phish tuned to a recent regulatory deadline the bank is publicly known to be working against, plus optionally a vendor-laptop physical drop at a BKC tower lobby.

Foothold and EDR evasion is genuine tradecraft, not a Cobalt Strike default profile. We run custom payloads with indirect-syscall execution, process hollowing into trusted binaries, AMSI patching tuned to the bank's actual EDR (CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender for Endpoint or, on some Mumbai cooperative banks, Trend Micro Apex One), and a Macksofy-internal C2 framework with rotating egress through Cloudflare Workers and AWS API Gateway. Persistence is established sparingly — exactly enough to survive a credential rotation, no more — because the audit committee does not want to find Macksofy beacons in the estate six months later.

Lateral movement on a Mumbai BFSI estate follows a predictable shape: BloodHound the engineering-station OU, find the ADCS template misconfig (ESC1 through ESC8 — most Indian banks still ship at least one), pivot via Kerberos delegation (RBCD, S4U2Self) to a high-value service account, and reach the SWIFT gateway, the OMS, or the core-banking jump host. The goal varies by mandate — sometimes the audit committee wants a silent Domain Admin proof, sometimes a treasury-side money-movement simulation against the FIN8 ATM-network TTP playbook, sometimes a market-data tampering proof against the broker desk. Cobalt Strike, Sliver and Mythic are all in play; Brute Ratel runs only where RoE explicitly permits.

Physical pretexting on Mumbai BFSI offices is rehearsed against actual building conventions, not generic playbooks. BKC towers (One BKC, Maker Maxity, Parinee Crescenzo) run distinct visitor-pass workflows and pantry-vendor schedules; Lower Parel mill compounds (Phoenix Mills, Kamala Mills) have different security postures than the Nariman Point heritage towers (Maker Chambers, Air India, Express Towers); the Andheri SEEPZ and MIDC ITES blocks have shared-building backbones that affect both physical and network paths. We rehearse pretexts that fit each conventon — not a US-bank social-engineering script translated into Hinglish.

Engagements run under written rules of engagement signed by the CISO, head of operations and the regulator-facing audit committee chair. Real-time deconfliction with the in-house SOC is handled via a private Signal or encrypted Teams channel so a live IR call never gets confused with a red-team artefact. We split into a red cell and a purple-team review cell — the purple cell sits with the SOC at engagement close for a full week, walking every detection-gap, writing a concrete tuning backlog for SIEM, EDR and identity controls, and delivering paired Sigma/Splunk rules per missed event. The audit committee gets a board-grade narrative, an MITRE ATT&CK heatmap (TTPs used vs detected), and a forward-looking detection-engineering roadmap.

Mumbai BFSI procurement on red team is unusual — the CISO proposes, the head of operations and the CRO co-sign, the audit committee chair gives explicit board-recorded approval. Some listed banks now run an annual red team as a board-mandated control rather than a project; we offer an annual retainer that runs one full engagement plus two narrower scope-restricted exercises (a phishing-only campaign and a physical-only exercise) so the annual budget covers three discrete board-reportable events rather than a single point-in-time test. Mumbai cooperative banks are starting to follow suit — the RBI Department of Supervision now asks about red-team posture in the larger urban-cooperative bank inspections.