SK Telecom: the web shell that sat undetected for three years
A South Korean web shell planted in June 2022 spread quietly across 23 servers, dropped 25 different pieces of malware, and wasn't found until April 2025. By the time anyone caught it, the attacker had the authentication keys for roughly 27 million SIM cards — stored, the regulator later found, in plain text.
Background
SK Telecom is South Korea's largest mobile carrier. Every SIM card it issues holds a secret authentication key — the USIM key — that proves to the network a given phone is who it says it is. It's the thing that makes SIM cloning and carrier-level impersonation possible if it leaks, which is a meaningfully different risk than a typical "your email and password were in a breach" notice. In April 2025, SK Telecom disclosed that an intrusion had reached exactly that data. What made the case genuinely alarming wasn't the sophistication of the attack — it was how long it had already been running by the time anyone noticed.
Three years between the intrusion and the discovery
What actually happened
On the night of April 19, 2025, SK Telecom's internal teams detected unusual activity on its network. Within days — SK Telecom reported the incident to Korea's national CERT, KISA, on April 22 — the scale of what they were looking at became clear: a web shell, a lightweight piece of malicious code that gives an attacker a remote command line into a compromised server, had been sitting on the company's Linux infrastructure since June 2022. It had spread to 23 separate servers. A joint investigation later identified 25 distinct pieces of malware on those systems, including BPFDoor, a backdoor specifically built to be hard to spot — it doesn't open a listening port the way most malware does, instead waiting silently for a specially crafted packet to wake it up.
The data the attacker ultimately reached was USIM authentication key material for somewhere between 23 and 27 million subscriber records — sources differ on the exact figure, and it's not fully clear whether that spread reflects different points in the investigation or different definitions of "affected." What's consistent across every account is that the exposed data did not include payment card numbers, national ID numbers, or device IMEI numbers. It was the authentication keys themselves, which is a narrower category of data than a typical breach notice but a more operationally dangerous one: those keys are what a SIM-cloning or carrier-impersonation attack would need.
SK Telecom's public response moved quickly once the breach was confirmed: free USIM replacement for its entire subscriber base, a measure the company says eventually cost on the order of ₩500 billion on top of roughly ₩700 billion in additional security investment — over ₩1.2 trillion combined. That's a genuinely large, genuinely fast commitment. It didn't stop the bleeding. Between April 19 and July 14, 2025, SK Telecom lost a net 720,000 subscribers to number portability, mostly to its two main domestic competitors. By its second-quarter 2025 results, the company reported operating profit down 37.1% year over year and net profit down 76.2%, with roughly ₩250 billion of that attributed directly to one-off breach costs.
The regulatory and legal aftermath has run on multiple separate tracks since, and they shouldn't be conflated. Korea's Personal Information Protection Commission (PIPC) fined SK Telecom ₩134.8 billion — reported in dollar terms anywhere from roughly $91 million to just under $100 million depending on the outlet and the exchange-rate date used — citing weak access controls and, specifically, that the USIM authentication keys had been stored in plain text rather than encrypted, a precaution the regulator noted peer telecoms had already taken. SK Telecom filed suit in January 2026 to overturn that fine, arguing no confirmed financial harm to users; that appeal remains unresolved. Separately, two different mediation bodies proposed consumer-compensation figures — the Personal Information Dispute Mediation Committee suggested ₩300,000 per person in November 2025, and the Korea Consumer Agency's own Consumer Dispute Mediation Committee separately proposed ₩100,000 per person in January 2026 — and SK Telecom rejected both, pointing to its existing relief package instead. More than 9,000 plaintiffs have since filed a civil suit seeking ₩500,000 per person. None of these three tracks has reached a final court outcome as of this writing.
Root cause
- A web shell was installed on SK Telecom's Linux server infrastructure in June 2022 and was not detected for roughly three years.
- The intrusion spread laterally to 23 servers, where investigators later found 25 distinct malware variants, including the BPFDoor backdoor.
- USIM authentication key material for tens of millions of subscribers was exfiltrated and was stored, at the time of the breach, unencrypted.
- PIPC's investigation separately found SK Telecom's access controls over this infrastructure to be inadequate, and its breach notification to be slower than required.
- How the web shell was first planted — the actual initial-access vector into SK Telecom's environment — has not been publicly disclosed by SK Telecom, KISA, or PIPC in anything reviewed for this case study. That's a genuine, acknowledged gap in the public record, not a detail this write-up is choosing to omit. Treat any specific claim about the initial entry point as unconfirmed until SK Telecom or Korean authorities say otherwise.
Timeline
Detection
SK Telecom's own internal teams detected unusual activity on the network on the night of April 19, 2025; public sources don't specify the exact technical signal that first triggered that detection, only the date. The company reported the incident to Korea's national CERT, KISA, on April 22, beginning the joint investigation that confirmed the three-year dwell time, server count and malware inventory.
Roughly three years — from the web shell's installation in June 2022 to internal detection on April 19, 2025. The exact exfiltration date for the USIM key material within that multi-year window has not been publicly specified.
- A web shell and 25 distinct malware variants, including the BPFDoor backdoor, persisted across 23 servers for roughly three years without triggering any internal alert — the dwell time itself is this case study's own central finding, not an incidental detail.
- BPFDoor specifically doesn't open a listening port the way most malware does, so it wouldn't show up in the connection-table or port-scanning checks a lot of basic monitoring relies on — a known evasion property of the specific tool found here.
- USIM authentication keys were stored in plain text rather than encrypted, which PIPC separately noted was inconsistent with peer telecoms' practice — not a detection signal itself, but a condition that meant any eventual access to that data yielded the most sensitive possible material immediately.
What to monitor for in your own environment
An unexpected remote command-line process or outbound connection pattern consistent with a web shell on Linux server infrastructure
Linux server-level endpoint detection and command-execution loggingA backdoor process that doesn't bind to a listening port but responds to a specially crafted packet
Network behavioral analysis tuned for non-port-binding malware, rather than connection-table checks aloneUnusual, large-scale read access to USIM or authentication-key data stores
Database and data-store access/query audit logsContainment, eradication & recovery
Containment
Apr 19–22, 2025- Detected unusual activity internally on the night of April 19, 2025.
- Reported the incident to Korea's national CERT, KISA, on April 22, 2025, within three days of internal detection.
Eradication
Apr 2025- A joint investigation with KISA identified the web shell and all 25 malware variants, including BPFDoor, across the 23 affected servers. Public sources confirm this identification but do not itemize the specific removal or rebuild steps taken on each server.
Recovery
Apr 2025 – ongoing- Launched free USIM replacement for its entire subscriber base within weeks of disclosure.
- Committed over ₩1.2 trillion combined to customer relief (about ₩500 billion) and additional security investment (about ₩700 billion).
- Faced a ₩134.8 billion PIPC fine around August 2025, which it is appealing as of January 2026; two separate consumer-compensation mediation proposals were rejected, and a civil suit from more than 9,000 plaintiffs remains unresolved.
Security control analysis
PIPC's own finding: the keys were stored in plain text. The regulator explicitly noted that comparable telecoms had already encrypted this category of data.
A web shell and 25 malware variants persisted across 23 servers for roughly three years without triggering internal detection. Whatever monitoring existed on this infrastructure did not catch an intrusion of this scale and duration.
PIPC cited "weak access controls" as a contributing finding, though the public record doesn't specify which controls or how they failed.
SK Telecom reported to KISA within three days of its own internal detection, which is reasonably fast once the company knew — but PIPC's fine separately cites the overall notification as too slow, suggesting a gap between internal awareness and the point authorities consider timely disclosure to have actually occurred.
Free USIM replacement for the full subscriber base, launched within weeks of disclosure, backed by a genuinely large financial commitment. This is the one part of the response that functioned as intended.
Controls that would have prevented or limited this
Would have denied the attacker usable key material even after the three-year intrusion succeeded in reaching the data store.
Would have shortened a three-year undetected dwell time by catching the kind of evasive backdoor this intrusion specifically used.
Would have limited the spread from one web shell to 23 servers, even if initial access still succeeded.
Blast radius
What was reached
- USIM authentication key material for an estimated 23–27 million subscriber records
- 23 Linux servers across SK Telecom's infrastructure, compromised for roughly three years
- The integrity of the carrier's own detection and monitoring capability — not a data category, but a confidence category
What stayed out of reach
- Payment card numbers
- National identification numbers
- Device IMEI numbers
What the breach cost SK Telecom in one quarter, beyond the fine
What they got right
Once the breach was confirmed, SK Telecom moved fast and at real scale: free USIM replacement was offered to its entire subscriber base within weeks, and the company committed over ₩1.2 trillion combined to customer relief and security investment — not a token gesture, a genuinely large number for a company of this size.
SK Telecom reported the incident to KISA within three days of its own internal detection on April 19, which, whatever the regulator's separate finding about overall notification speed, is a reasonably fast internal-to-authorities timeline once the company actually knew what it was looking at.
The company didn't contest the core facts of the intrusion — the web shell, the server count, the malware families — even as it has pushed back hard on the fine amount and the compensation proposals. Disputing a financial penalty while not disputing the underlying technical findings is a meaningfully different posture than disputing the breach happened at all.
Why this keeps happening
Multi-year undetected dwell time on server infrastructure isn't unique to SK Telecom — it's one of the most common findings in breaches involving legacy Linux estates, where monitoring tooling is often built around Windows-centric endpoint detection and server fleets get comparatively less attention precisely because they're assumed to be more stable and less exposed to the kind of day-to-day user behavior that triggers most alerts.
BPFDoor specifically is built to avoid exactly the kind of detection that would have caught a more conventional backdoor — it doesn't bind to a network port the way malware typically does, which means it doesn't show up in the connection-table checks a lot of basic monitoring relies on. Its presence here, alongside 24 other tools, points to an environment that had been operating as a long-term base of operations, not a single opportunistic intrusion.
Storing authentication secrets in plain text is a pattern that shows up across industries wherever a system was built before the data it held was treated as sensitive, and nobody ever circled back to re-architect it once the threat model changed. PIPC's comparison to peer telecoms matters here: this wasn't an industry-standard practice SK Telecom happened to follow. It was a gap other carriers had already closed.
No threat actor has been publicly attributed to this intrusion, by SK Telecom, KISA, or any independent researcher reviewed for this case study. That's worth stating plainly rather than filling the gap with a plausible-sounding guess — a three-year, multi-server, multi-tool intrusion against a telecom's core subscriber-authentication data is consistent with a well-resourced actor, but consistency with a profile isn't the same as attribution, and none has been made here.
Lessons for your own environment
- Dwell time is itself a metric worth measuring and reporting on
A three-year gap between compromise and detection means whatever monitoring existed on this infrastructure effectively didn't function as a detection control for that entire period. If your organization doesn't know its own typical dwell time, that's worth finding out before an incident forces the question.
- Encrypt the data an attacker would actually want, not just the data a compliance checklist names
USIM authentication keys are about as close to "the crown jewels" as a telecom's data gets, and they were stored in plain text. Ask specifically, by name, whether your organization's most operationally dangerous data categories are encrypted at rest — not whether encryption exists somewhere in the environment.
- Server fleets need the same detection investment as endpoints
This intrusion lived on 23 Linux servers for years. Server infrastructure often gets less behavioral monitoring than user endpoints, on the assumption that it's more stable and less exposed — which is exactly the assumption an intrusion like this one is built to exploit.
- A fast, well-funded customer response doesn't undo a detection failure, but it's still worth doing fast and well
SK Telecom's USIM replacement program and >₩1.2 trillion commitment didn't stop 720,000 subscribers from leaving or prevent a 37% profit decline. It still mattered — the alternative, a slow or token response on top of a three-year detection failure, would have been worse on every axis that matters afterward.
- A regulatory fine and a market reaction are two separate punishments, and the market often moves first
The PIPC fine landed months after the subscriber exodus and profit decline had already happened. If your board is only modeling regulatory risk as the cost of a security failure, this case is a reminder that customer attrition can be the larger and faster-arriving number.
- "We don't know the initial access vector" is a legitimate, honest answer — say it plainly
No public account of this breach specifies how the web shell was first planted. A security program that can't answer that question about its own real incident has a real gap to close; a case study that invents an answer to fill the silence is doing the reader a disservice. Both things are worth sitting with.
CISO & board lessons
- Ask your own team, directly and by name, what your organization's estimated dwell time is for an undetected intrusion on server infrastructure — not endpoint infrastructure, server infrastructure specifically. If nobody can give you a confident answer, that's the finding, not a side note.
- Get a specific inventory of which data categories are encrypted at rest versus which are merely access-controlled. "Encrypted somewhere" is not the same question as "is the specific data an attacker would most want encrypted."
- Model customer attrition and revenue impact as a first-order cost of a major breach, alongside regulatory fine exposure — SK Telecom's quarterly profit hit was larger and arrived faster than its eventual fine.
- When a regulator cites a specific, nameable control gap (plain-text storage, in this case) rather than a vague "inadequate security" finding, treat that as a gift: it tells you exactly what to fix first, and exactly what a future audit will ask about again.
- Plan your incident communications assuming the market will react before your investigation is finished. SK Telecom's subscriber losses began within days of disclosure, well before the full malware count or PIPC's findings were public.
Action plan
First 24 hours
- If unusual activity is detected on server infrastructure, assume lateral spread until proven otherwise — a single-server view of an intrusion this type can badly understate its actual footprint.
- Identify what sensitive data lives on the affected systems and whether it's encrypted at rest, before assuming the question is settled by policy documentation alone.
- Begin the regulatory notification clock immediately on confirmed compromise, even while scope is still being established — SK Telecom's three-day internal-to-KISA timeline was reasonably fast; don't let scoping delay the initial report.
First 7 days
- Stand up a customer-facing remediation option (credential/key replacement, in this case USIM reissue) and commit to it publicly and specifically, rather than a vague "we are investigating" holding statement.
- Hunt across the full server estate for additional malware families or persistence mechanisms — a single confirmed implant on server infrastructure that's gone undetected for any length of time should trigger a full-fleet sweep, not a single-host cleanup.
- Separate the technical investigation from the communications and legal workstreams explicitly, with named owners for each, so neither slows the other down.
First 30 days
- Commission an independent review of monitoring coverage specifically on server infrastructure, not just endpoints — ask directly what would and wouldn't have been caught by current tooling.
- Re-architect storage for any authentication or credential material found unencrypted, treating this as the highest-priority remediation item, not a backlog ticket.
- Model the full cost curve of the incident — fine exposure, customer attrition, remediation spend — and report it to the board as a single connected picture, not three separate line items.
Could this happen in your organization?
- Do you know your organization's estimated average dwell time for an undetected intrusion on server infrastructure specifically, separate from endpoint infrastructure?
- Is your most sensitive authentication or credential data — the equivalent of a USIM key — encrypted at rest, confirmed by someone who has actually checked, not assumed from policy?
- Does your server fleet receive the same behavioral monitoring investment as your endpoint fleet, or does it get less scrutiny on the assumption that it's more stable?
- Would a backdoor designed specifically to avoid opening a listening port (like BPFDoor) be caught by your current detection tooling?
- If a major breach happened tomorrow, do you have a costed, ready-to-launch customer remediation program, or would building one from scratch add weeks to your response?
- Has your board modeled customer attrition as a first-order cost of a security incident, separate from and in addition to regulatory fine exposure?
- If your regulator asked you to name every system storing authentication secrets in plain text, could you answer completely today?
If this happened to you: what to ask, and what to say
Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.
- "What's our actual dwell-time detection capability on server infrastructure, not just endpoints?"Ask for a specific answer, not a reassurance. This incident ran three years on Linux servers before internal detection caught it.
- "Is our authentication and credential material encrypted at rest — confirmed, not assumed?"The specific finding that made this a negligence story, not just a breach story, was plain-text storage of exactly the data an attacker would most want.
- "Would a backdoor like BPFDoor, which doesn't open a listening port, show up in our current monitoring?"Many detection approaches rely on connection-table or port-scanning checks that this class of malware is specifically built to avoid.
- "If we found one web shell today, how would we scope whether there are others?"This intrusion eventually involved 25 distinct malware families across 23 servers. A single-host cleanup response would have badly understated the real footprint.
- State plainly what was taken and why it matters.Avoid generic "data was accessed" language; name the specific risk."Authentication keys for roughly 27 million subscriber SIM cards were exposed. That's the specific data an attacker would need to clone or impersonate a customer's connection — not just a privacy exposure, an authentication-integrity one."
- Own the detection gap directly, with a number attached.A vague admission invites worse assumptions than a specific one."The intrusion was present on our infrastructure for approximately three years before we detected it internally. That gap, not the intrusion itself, is the finding we are addressing first."
- Separate the fine from the market reaction when briefing the board on cost.Don't let the regulatory number stand in for the full financial picture."The regulatory fine is one cost among several. We lost 720,000 subscribers and roughly 37% of quarterly operating profit in the months before any fine was even imposed — that is the larger and faster number."
- Commit to a specific, dated remediation milestone."We're investing in security" without a number or date reads as deflection."We have committed over ₩1.2 trillion to customer relief and security investment, and we will report progress against specific milestones at each subsequent board meeting."
- State exactly what was and wasn't exposed.Narrow, specific language is more reassuring than broad caution when it's accurate."Your SIM authentication key may have been exposed. Your payment card details, national ID number, and device IMEI were not part of this incident."
- Give customers a concrete, free remediation action, not just an apology.A SIM/USIM replacement is a real technical fix, not a gesture — frame it that way."We are offering a free USIM replacement to every subscriber. This directly replaces the specific credential that was exposed."
- Acknowledge the detection timeline honestly if asked.Customers who read coverage of this incident will know about the three-year gap; address it rather than let it surface as a surprise."This intrusion was active for a longer period before we detected it than we are satisfied with. We are not minimizing that, and it is the specific gap our security investment is now targeting."
- Explain what changes going forward, specifically."We take security seriously" is not an answer a technically literate customer will accept after a three-year dwell time."We are encrypting the categories of authentication data involved in this incident and increasing monitoring investment specifically on the server infrastructure where this intrusion lived undetected."
References & confidence
- ConfirmedKorea Times — SK Telecom files lawsuit to revoke record $91M fine over data breach — Appeal filing, company-stated relief/security spend figures.
- ConfirmedGRC Report — South Korea's privacy regulator hits SK Telecom with $99.9M sanction — PIPC's plain-text-storage finding; USD figure varies by outlet, treat the ₩134.8B figure as primary.
- ConfirmedSecurity Affairs — SK Telecom revealed that malware breach began in 2022 — Intrusion timeline and malware count.
- ConfirmedMobileIDWorld — SK Telecom data breach exposes 26.9 million USIM records — Scope of exposed records.
- ConfirmedKorea Times (via view.asiae.co.kr) — SK Telecom rejects Personal Information Commission's compensation mediation — November 2025 mediation rejection, ₩300,000/person proposal.
- ConfirmedKorea Times — SK Telecom rejects arbitration recommending ₩100,000 compensation — January 2026, a separate mediation track from the November 2025 one — do not conflate the two.
- ConfirmedKorea Times — SK Telecom continues to lose users after data breach — Subscriber portability figures.
- ConfirmedCoverage of SK Telecom's Q2 2025 financial results (operating/net profit decline) — Company-reported figures, about ₩250B attributed directly to breach costs.
- UnknownInitial access vector into the compromised infrastructure — Not specified in any source reviewed. This case study does not speculate on a specific mechanism.
- UnknownThreat actor attribution — No attribution has been publicly made by SK Telecom, KISA, or independent researchers reviewed for this case study.