When aviation cyber security makes the headlines, it’s usually the sci-fi stuff that catches everyone’s attention like the high-profile GPS-spoofing attacks that disrupted operations and delayed hundreds of flights across major Indian airports recently.
But while the industry’s attention is naturally fixed on the skies and aircraft avionics, a quieter, equally critical threat vector remains entirely grounded: the sprawling corporate and operational IT networks that actually keep the terminals alive.
An airport operator’s IT estate is a massive, federated labyrinth. It’s heavily reliant on a revolving door of third-party vendors and legacy integrations, creating an incredibly complex attack surface. When you test these environments the way a real adversary does, you quickly realize they are porous in ways a standard, automated vulnerability scan will completely miss.
What follows is a sanitized, step-by-step debrief of a 90-day, black-box adversary emulation we executed against the corporate IT environment of a tier-1 Indian airport operator.
A quick note on confidentiality: All names, dates, system identifiers, hostnames, and vendor specifics have been entirely scrubbed to protect the organization.
Our goal here isn’t to sensationalize, but to leave a technically accurate, defensible record of how an APT-grade actor moves from an external, internet-facing foothold to full Domain Admin control in less than a fiscal quarter—and to be completely honest about the hidden architectural blind spots we uncovered along the way.
Engagement framing
Black-box. No prior knowledge of the network. No asset list shared. Scope was “the IT estate of the group” — corporate AD, identity, the public attack surface, and anything downstream we could reach without crossing into runway, ATC, or OT/SCADA systems (those were carved out explicitly; we have a separate phygital lab where we exercise the OT side, and a follow-up post will cover that work). MITRE ATT&CK Enterprise was the reference framework throughout.
The brief from the security leader was one line: assume an APT had decided you were the target — show me what they’d get to, and how long it would take them.
T-90 → T-60: External reconnaissance
Three weeks. No exploitation, no probing that would have tripped a scanner. The aim was inventory.
- 80+ internet-reachable hosts across the parent group and its subsidiaries, mapped through certificate transparency, passive DNS, and ASN enumeration. Several were unmanaged — registered under obsolete cost centres, still serving traffic, no owner on record.
- 300+ valid corporate email identities harvested from public filings, LinkedIn, regulatory disclosures, and conference rosters.
- O365 / Azure AD tenant fingerprint confirmed — including the authentication endpoints, federation posture, and MFA enrolment signals (the latter inferred from public sign-in surfaces, not authenticated probing).
- A regional micro-site maintained by a marketing vendor — three versions behind on the framework, exposed admin console, and on the same DNS zone as the corporate parent.
- An exposed application server running a Java application framework with the management console reachable from the public internet, default authentication realm still in place.
- An edge networking device with a vendor-default credential pair surfaced via a previous data leak posted on a paste-aggregation site.
We did not act on any of it. We watched.
T-60 → T-45: Weaponisation and quiet foothold
Two findings from recon were enough to plan a full kill chain. The application server with the exposed management console was the cleanest path — it was joined to the corporate Active Directory forest, which is the misconfiguration that makes everything that follows possible.
We built a small custom Java application — a web archive package — designed to do exactly three things on deployment: phone home to a controller, accept a tasking channel, and stay quiet. No off-the-shelf implant. No public signature. We deployed it through the management console as a legitimate application package, the way an authorised administrator would. The host accepted it.
We waited three days before exercising the foothold. Patience is a control we deliberately rehearse — most blue teams expect immediate post-exploitation activity, and the silence buys time. ATT&CK mapping for this phase:
- T1190 — Exploit Public-Facing Application
- T1505.003 — Server Software Component: Web Shell (we treat the custom WAR as functionally equivalent)
- T1071.001 — Application Layer Protocol: Web Protocols (the controller channel)
T-45 → T-30: Execution and credential access
On day three of foothold-active, we moved.
The host was a standard Windows server build, AD-joined, with a service account running the application framework. We staged a small set of well-known live-off-the-land binaries through the foothold — process-dumping utilities, archiving tools, network reconnaissance utilities. None of these were malicious by signature. All of them are dual-use system administration tools.
We dumped the memory of the lsass process. Credential material for
a domain-joined user was recoverable in plaintext — the host had not
been hardened against credential theft (no Credential Guard, no LSA
protected process, no Restricted Admin mode for inbound RDP). The
recovered credential was for a service account with broader rights
than its name implied.
ATT&CK for this phase:
- T1003.001 — OS Credential Dumping: LSASS Memory
- T1059.003 — Command and Scripting Interpreter: Windows Command Shell
- T1078.002 — Valid Accounts: Domain Accounts
Nothing in the SOC’s signal pipeline fired. We checked twice.
T-30 → T-10: Discovery, then patience
The credential gave us the operator’s collaboration suite, the mailbox of a mid-tier IT manager, and a foothold inside the corporate file share. We spent the next twenty days reading.
What we read, in order of usefulness to a real adversary:
- Internal and external audit reports, including unmitigated findings from prior assessments, with timelines and named owners.
- Asset inventories that included system criticality ratings, backup schedules, and recovery time objectives — i.e., a ranked list of which systems would hurt most if encrypted.
- Network and AD architecture documents that mapped trust relationships and identified the choke points between the corporate domain and the operational segments we were forbidden from touching.
- Vendor and procurement records for the security stack itself — which EDR, which SIEM, which mail gateway, which patch cycle.
Discovery is the longest phase of a real APT operation. It was the longest phase of ours.
ATT&CK for this phase:
- T1087 — Account Discovery
- T1018 — Remote System Discovery
- T1083 — File and Directory Discovery
- T1213 — Data from Information Repositories (the collaboration suite, the file share, the shared drives)
T-10 → T-0: Privilege escalation to domain admin
The escalation was not technically clever. It rarely is.
A domain administrator logged into the compromised application server during a routine maintenance window. We were still resident, still extracting LSASS memory on a schedule. The administrator’s plaintext credential was in the next dump.
From there, the rest of the kill chain was procedural:
- We minted a Kerberos ticket for a high-privilege account (T1558.001 — Steal or Forge Kerberos Tickets: Golden Ticket was demonstrated in the lab; in the live engagement we used pass-the-hash via the recovered NTLM material, T1550.002).
- We confirmed read access to the AD database, the GPO store, and the backup configuration.
- We documented — but did not exercise — the path to mass password reset, mass account disablement, and the keys to the backup system that would have been the precondition for a ransomware operator’s detonation.
We did not deploy ransomware. We did not exfiltrate the documents we had read. We took the screenshots the report required and stopped.
The crown jewel, and what it meant
Full forest control. Read and write across the corporate identity plane. By the operator’s own business-continuity plan — which we quoted back to them in the debrief — a ransomware detonation at this stage would have locked out a low five-figure user population and halted ground-side corporate operations for two to three days before manual workarounds restored a degraded service. Airside operations would have continued; the corporate IT collapse would have cascaded into check-in, manifest, crew rostering, ground handling coordination, and vendor settlement within hours.
We stopped because we had a defensible record. The report we left included the screenshots, the timestamps, the artefacts the blue team would need to reconstruct each step, and the specific configuration the operator would need to change to make the same path harder next time.
The uncomfortable finding
While we were inside the foothold host, we found forensic artefacts that didn’t belong to us.
Specifically: log entries, scheduled tasks, and modified system files with timestamps that pre-dated our engagement by approximately two months. The artefacts were consistent with persistence mechanisms a separate actor would deploy. The credentials they used, the binaries they staged, and the times they were active did not match our own activity.
We had no remit to investigate. We packaged the artefacts, escalated to the operator’s security leadership the same day, and recommended an immediate, scoped threat hunt across the same set of internet- exposed hosts and the AD audit logs going back six months. The hunt that followed is its own story; we are not free to write it.
The point worth carrying: a real attacker had found the same path we had, two months before we did. The control gap was old enough that someone else had already walked through it.
What the operator changed in the four weeks after the debrief
These changes shipped within thirty days of report delivery. None of them are exotic. All of them were findings the operator’s prior audits had flagged, in different language, that had not been prioritised:
- Network-level separation between the parent group’s corporate AD forest and any host with an internet-routable interface. The application server class — the foothold class — moved to a forest-isolated DMZ with its own identity provider.
- LSASS protection and Credential Guard enabled on every server build that touched the corporate domain, with the build template updated so new hosts inherited the hardening.
- Universal MFA enforcement across the O365 / Azure AD tenant for every account class — including the operational, service, and break-glass accounts that had been carved out as exceptions.
- Azure AD ↔ on-prem AD sync hardening — the password write-back configuration was removed, the sync account was restricted, and the privileged-identity surface in Azure AD was reduced.
- A SOC tier-1 capability that actually alerts on the signals our engagement had generated. We re-ran the same kill chain four months later in a tabletop and the SOC detected the foothold within the first hour. The original engagement had run for thirteen weeks undetected.
What good looks like — recommendations beyond the report
The operator’s report had five recommendations. For a public audience working in or around Indian aviation, the list is longer and worth being explicit about. Treat this as the floor, not the ceiling.
Regulatory and reporting posture
- CERT-In Directions 70B (28 April 2022) require notifiable incidents to be reported within six hours of detection, logs to be retained for 180 days, and time-synchronised to NPL or NIC. An airport operator with critical-information-infrastructure designation has no margin for runbook ambiguity here. Tabletop the six-hour clock end-to-end at least quarterly.
- BCAS, under the Aircraft (Security) Rules 2023, is the regulatory authority for airport security and treats unlawful interference broadly enough to encompass cyber-induced disruption. Your AVSEC programme and your cyber programme should not be separate runbooks with separate incident managers — they should reference each other explicitly.
- DGCA Civil Aviation Requirements remain the umbrella framework. As cyber-specific guidance hardens (ICAO Annex 17 cybersecurity amendments are the inbound direction), maintain a living map of your controls to whichever CAR the regulator ultimately publishes.
Architecture
- Forest isolation between internet-exposed services and the identity plane the rest of the corporate estate uses. If your public-facing application is joined to the same AD as your CFO’s laptop, you are one credential theft away from domain admin.
- Tiered administration (Microsoft’s tier-0/1/2 model is the reference): privileged credentials are issued from, and only usable on, hosts that are themselves at the same privilege tier. Domain admins logging into application servers is the single failure mode that ends most of these engagements.
- Hardened administrative workstations (PAWs) for any account with rights over the identity plane. No web browsing, no email, no general productivity software.
Credential and identity hygiene
- Credential Guard / LSA protected process enabled on every server class, enforced by GPO and verified by configuration drift monitoring.
- MFA universal — no exceptions for service accounts, no exceptions for break-glass accounts (use vaulted, monitored break-glass credentials instead), no exceptions for “this vendor doesn’t support it” without a compensating control documented and reviewed.
- Privileged-account inventory maintained, rotated, and reconciled against AD reality on a schedule. Stale privileged accounts are the second-most-common path we exploit after internet-exposed services.
Detection
- Outbound channel monitoring — DNS, HTTPS to uncategorised destinations, and unusual user-agent patterns. The custom controller channel we used in this engagement did not match any signature; it did however have telemetry that a behaviour-based detection programme could have caught.
- LSASS access auditing — Sysmon event 10, with handle access filtered for the binaries that have no business reading process memory. This is one of the highest-signal detections available and one of the most consistently missing.
- SOC validation through adversary emulation on a fixed cadence — not annual, not “when the budget allows”. The Microsoft-rebuilt estate that survived our re-run did so because the SOC had been exercised against it.
Programme
- Quarterly tabletop covering the CERT-In six-hour clock, the BCAS notification path, and the internal escalation tree — measured in minutes, not pass/fail.
- Annual full-scope red team with an OT carve-out covered separately under a phygital range engagement (forthcoming post). Aviation is one of the few sectors where the IT and OT threat models are genuinely distinct and need their own exercises.
- Pre-existing-intrusion hypothesis baked into every red team scope. If you are large enough, vendor-heavy enough, and perimeter-porous enough to be a credible target for an APT, the null hypothesis at the start of any engagement is that someone is already inside. Hunt accordingly.
What we would write differently next time
Two reflections from the team that ran this engagement.
We waited too long in discovery. Twenty days inside an environment without action is appropriate for the simulation, but it left forensic artefacts of our own that a hunting team — had one existed — could have used. In our next airport engagement we tightened the discovery window to ten days and accepted that we’d see less, in exchange for a smaller footprint.
We should have triggered an alarm deliberately. To be completely blunt, the operator’s SOC genuinely didn’t see us. Not once.
But the scarier realization for their leadership team wasn’t just that their defenders were blind—it was that they had no real way of knowing it. They lacked any sort of baseline or “positive control” to stress-test their own security monitoring. They were essentially flying blind, just hoping the vendor’s dashboard was telling the truth.
This exact problem is why we’ve built a specific ritual into the tail end of our engagements. Exactly thirty minutes before the final debrief presentation begins, we deliberately kick the door down. We execute a massive, intentionally noisy, completely undisguised malicious action on the network.
If the SOC flags it, awesome—we’ve established their baseline “detection floor.” But if that screamingly obvious attack goes unnoticed? Well, it gives the operator some incredibly sharp ammunition for a very different kind of conversation with their SOC vendor the next morning.
This debrief sits inside an active client relationship. The narrative is faithful to the engagement; every identifier that could attribute it to a specific operator has been removed. If you are an Indian airport operator, an aviation ministry stakeholder, or a critical-infrastructure security leader and would like to discuss the methodology, the OT follow-up, or a scoped engagement of your own, the team is reachable through the contact page.