← Wróć do bloga

Atak na MyDr: co naprawdę wiemy o wycieku danych medycznych

10 sierpnia 2026 r. firma MyDr - jeden z największych w Polsce dostawców systemu Elektronicznej Dokumentacji Medycznej - ogłosiła, że bada poważny incydent bezpieczeństwa. Nieznani sprawcy twierdzą, że wykradli 2,5 TB danych i bazę zawierającą 18 814 422 unikatowych numerów PESEL wraz z danymi recept. To potencjalnie jeden z największych wycieków danych medycznych w historii kraju - ale słowo „potencjalnie" jest tu kluczowe.

Kontekst i legalność. To materiał edukacyjny opisujący publicznie relacjonowany incydent. Konsekwentnie oddzielamy twierdzenia sprawców od tego, co udało się niezależnie zweryfikować - na tym etapie firma nie potwierdziła wycieku, a śledztwo trwa. Nie korzystaliśmy z żadnych źródeł w sieci Tor ani ze stron „leak-site"; opieramy się na relacjach renomowanych źródeł w otwartej sieci (przede wszystkim Zaufana Trzecia Strona) oraz na oficjalnych komunikatach. Testowanie cudzych systemów jest legalne wyłącznie za pisemną zgodą właściciela.

Czym jest MyDr i dlaczego skala jest tak duża

MyDr to platforma, z której korzystają lekarze i placówki - to oni wprowadzają dane wizyt i wystawiają recepty. Pacjent zwykle nawet nie wie, że jego dane przechodzą przez ten system. Sama firma podaje, że obsługuje 3 mln wizyt i 2,7 mln recept miesięcznie w tysiącach punktów ochrony zdrowia. To wyjaśnia, dlaczego deklarowana liczba ponad 18 mln rekordów jest wiarygodna co do rzędu wielkości - pasuje do potencjalnego zasięgu systemu.

Własnościowo MyDr należy do grupy ZnanyLekarz, a ta do DocPlanner (firmy obecnej w 13 krajach, założonej przez Mariusza Gralewskiego). Co istotne dla oceny ryzyka: MyDr i ZnanyLekarz mają oddzielne systemy i nie wymieniają się danymi - incydent dotyczy platformy MyDr, nie całego portfela DocPlanner.

Chronologia

Według dostępnych relacji: 5 sierpnia sprawcy mieli wysłać wiadomość do prezesa firmy-właściciela, dołączając zabezpieczony hasłem plik PDF z „dowodami" i prośbą o kontakt. W sobotę 8 sierpnia skontaktowali się z redakcją Zaufanej Trzeciej Strony. 10 sierpnia MyDr opublikowało komunikat o badaniu incydentu i FAQ dla klientów, a wicepremier i minister cyfryzacji Krzysztof Gawkowski potwierdził, że sprawą zajęły się służby, pisząc, że „wiele wskazuje na to, że osoba nieuprawniona mogła uzyskać dostęp" do danych.

Jakie dane wchodzą w grę

Sprawcy deklarują posiadanie kompletnej bazy pacjentów. Zaufana Trzecia Strona zweryfikowała część przekazanych próbek i - w zakresie, w jakim było to możliwe - nie przyłapała sprawców na kłamstwie. Na podstawie tych próbek rekordy zawierają:

• numer PESEL, imię i nazwisko oraz datę urodzenia (dla sprawdzanej osoby publicznej data i PESEL były prawidłowe),
• numery telefonów (jeden z numerów udało się potwierdzić w innych źródłach; część rekordów miała zaślepkę 111111111),
• region NFZ (zgadzał się dla weryfikowanych osób),
• dane recept - m.in. lista 25 numerów recept przypisanych do jednej osoby (bez nazw leków w tej próbce).

Dla oceny zasięgu redakcja przeprowadziła mały eksperyment: dla pięciu sprawdzonych numerów PESEL osób z branży sprawcy zwrócili rekordy w trzech przypadkach. Próba jest statystycznie niewielka, ale spójna z deklarowanym rozmiarem bazy.

Poza danymi pacjentów sprawcy twierdzą, że uzyskali dostęp do wewnętrznych systemów firmy: Jira, HubSpot CRM, konta w bramce SMSApi (mieli rzekomo wysłać SMS do pracowników z własnego konta firmy), a także repozytorium GitHub z kodem źródłowym i infrastruktury AWS. W wykradzionym materiale miały się znaleźć wewnętrzna korespondencja, informacje o nowych pracownikach, raport sygnalisty oraz cennik reklam konkretnych leków. Podkreślmy: 2,5 TB i 18,8 mln to liczby podane przez atakujących, których nie da się na tym etapie niezależnie potwierdzić.

Co pokazują opublikowane zrzuty ekranu (dane zamazane)

Sprawcy nie opublikowali publicznego zrzutu całej bazy - dowody przekazywali prywatnie: redakcji Zaufanej Trzeciej Strony oraz prezesowi firmy (przez komunikator Session). Poniżej opisujemy, co widniało na tych materiałach, z zamazanymi danymi osób. Nie przytaczamy żadnych prawdziwych numerów, nazwisk ani telefonów.

Najmocniejszym dowodem był zrzut ekranu rekordu z bazy dotyczącego jednego z czołowych polskich polityków. Zawierał jego prawidłową datę urodzenia, numer PESEL, imię i nazwisko oraz dwa numery telefonu (jeden potwierdzono w innych źródłach), zgodny region NFZ, a także receptę. Osobno przekazano listę 25 numerów recept przypisanych do tej osoby (bez nazw leków). Redakcja potwierdziła też własny rekord: prawidłowy PESEL i region NFZ, przy czym w polu telefonu figurowała zaślepka 111111111.

Poza rekordami pacjentów krążyły materiały wewnętrzne firmy: zrzut ekranu z systemu Jira, SMS rzekomo wysłany do pracowników z firmowego konta w bramce SMSApi oraz zabezpieczony hasłem PDF wysłany do prezesa (hasłem był jego PESEL) - z wewnętrzną korespondencją, informacjami o nowych pracownikach, raportem sygnalisty, fragmentem bazy współpracujących lekarzy i cennikiem reklam konkretnych leków. Publikująca te zrzuty Zaufana Trzecia Strona sama zamazała w nich wrażliwe elementy - m.in. wciąż działający link do pliku PDF.

Dlaczego to jest groźne. Impact takiego zestawu danych wykracza daleko poza „numer w bazie":

• Kradzież tożsamości i wyłudzenia. PESEL + imię i nazwisko + data urodzenia + telefon to komplet wystarczający do prób wyłudzeń finansowych i podszywania się.
• Ukierunkowany phishing i vishing. Z danymi recept i regionem NFZ napastnik może zadzwonić „z przychodni w sprawie Pana/Pani recepty" - wiarygodnie, bo zna szczegóły. To dane, których nie zmienisz jak hasła.
• Szantaż i dane wrażliwe. Informacja o leczeniu to szczególna kategoria RODO; jej ujawnienie może służyć do nacisku, dyskredytacji czy dyskryminacji - szczególnie wobec osób publicznych, których rekordy pojawiły się w próbkach.
• Nadużycie kanału SMS. Dostęp do firmowego konta SMSApi pozwala wysyłać phishingowe SMS-y od prawdziwego nadawcy - ofiara nie ma jak odróżnić ich od komunikacji placówki.
• Szkody dla firmy. Wyciek wewnętrznej korespondencji, raportu sygnalisty czy cennika reklam leków to osobna warstwa strat - reputacyjnych i biznesowych.

Jak - według sprawców - doszło do włamania

To fragment, który należy czytać z największą ostrożnością, bo pochodzi wyłącznie od atakujących i nie został potwierdzony. Według ich relacji łańcuch wyglądał tak:

1. XXE w obsłudze certyfikatów PKCS#12 → zdalne wykonanie kodu. Punktem wejścia miała być podatność typu XML External Entity przy przetwarzaniu kontenerów PKCS#12. To wiarygodny technicznie scenariusz: PKCS#12 to format „paczki" z kluczem i certyfikatem, a jeśli aplikacja gdzieś parsuje powiązane dane XML ze źle skonfigurowanym parserem (z włączonymi encjami zewnętrznymi), atakujący potrafi zmusić serwer do sięgnięcia po lokalne pliki lub zasoby sieciowe - a w cięższych wariantach doprowadzić do wykonania kodu.
2. Klucz API do GitHuba. RCE miało pozwolić odczytać z hosta klucz API, który otwierał dostęp do repozytorium z kodem źródłowym serwisu.
3. Kod źródłowy → infrastruktura AWS. Mając kod, sprawcy mieli odnaleźć drogę do środowiska chmurowego na AWS, a stamtąd do danych.

Nawet jeśli ten opis okaże się nieścisły, jego morał jest uniwersalny: pojedyncza podatność w parsowaniu danych rzadko kończy się na jednym hoście. Sekrety zaszyte w kodzie lub dostępne z hosta (klucze API, poświadczenia chmurowe) zamieniają lokalne RCE w pełny łańcuch aż do bazy.

Kto stoi za atakiem - i dlaczego „grupa APT" to na razie nadużycie

Tu trzeba postawić sprawę jasno, bo w sieci szybko pojawiają się etykiety. Na ten moment nikt nie przypisał ataku żadnej znanej grupie - ani APT (sponsorowanej przez państwo), ani konkretnej ekipie ransomware. Co więcej, sprawcy wyraźnie zacierają ślady i podszywają się pod kogoś, kim nie są. Zaufana Trzecia Strona zwróciła uwagę na kilka sygnałów: komunikują się po angielsku, „uśmiechają po rosyjsku" (charakterystyczne ))))))))), a ich angielszczyzna brzmi, jakby ktoś kazał modelowi AI przepisać tekst „tak, jakby napisał go średnio znający język obywatel jakiegoś kraju Azji". To układa się w obraz celowego fałszywego tropu, a nie autentycznego podpisu grupy.

Wskazówki co do motywu są za to dość czytelne i wskazują na wymuszenie finansowe, a nie klasyczne szpiegostwo: kontakt przez komunikator Session, „oferta sprzedaży wyników audytu bezpieczeństwa" złożona prezesowi, próba nagłośnienia sprawy przez media. To repertuar współczesnego data-extortion (wymuszenie oparte na groźbie ujawnienia danych), często bez etapu szyfrowania. Warto też odnotować, czego (jak dotąd) nie widać w relacjach: publicznego wpisu na torowym „leak-site". Sprawcy poszli drogą bezpośredniego nacisku, nie publicznej licytacji. Jeśli pojawią się twarde dowody atrybucji, zaktualizujemy ten wpis - do tego czasu „grupa APT" pozostaje hipotezą bez pokrycia.

Jak oceniać wiarygodność - lekcja metodyczna

Ten incydent to dobra ilustracja, jak podchodzić do „mega-wycieków" na gorąco. Po pierwsze, próbki można weryfikować, całości nie: dało się potwierdzić kilka rekordów, ale nie 2,5 TB czy 18 mln. Po drugie, prawdziwość próbki nie dowodzi rozmiaru bazy - to dwie różne rzeczy. Po trzecie, styl komunikacji bywa kostiumem; emotki i łamany angielski to dziś tani sposób na mylenie tropów. Rzetelna relacja - jak ta ZTS - właśnie tak stawia sprawę: podaje, co zweryfikowano, i wprost mówi, czego nie.

Reakcja firmy i państwa - oraz haczyk z RODO

MyDr uruchomiło procedury reagowania, zaangażowało zespoły bezpieczeństwa, inżynierii i infrastruktury oraz zewnętrznych ekspertów i doradców prawnych, powiadomiło organy i klientów (placówki oraz lekarzy) i opublikowało FAQ. Firma zapewnia, że systemy działają normalnie, i - dopóki trwa postępowanie - nie potwierdza kradzieży danych.

Jest tu jednak realny problem dla pacjentów. MyDr występuje jako podmiot przetwarzający w rozumieniu RODO, a administratorami danych są tysiące placówek ochrony zdrowia. W praktyce oznacza to, że MyDr nie może po prostu przekazać danych ofiar np. do CERT Polska i serwisu bezpiecznedane.gov.pl. Ustalenie „czy jestem w wycieku" będzie więc dla wielu osób trudne i czasochłonne - informacja musi przejść drogą: MyDr → placówka (administrator) → pacjent.

Dlaczego ochrona zdrowia jest tak łakomym celem

Dane medyczne to komplet: dane osobowe i kontaktowe, historia chorób, wyniki, leczenie. A stan zabezpieczeń bywa słaby. Badanie Centrum e-Zdrowia wśród ponad 11 tys. podmiotów pokazało, że 72% placówek nie ma zespołu ds. cyberbezpieczeństwa (wśród szpitali ok. 59%), około 60% nie monitoruje podatności, a niecałe 60% regularnie testuje odtwarzanie kopii zapasowych. Według sektorowego CSIRT CeZ liczba ataków ransomware na ochronę zdrowia na świecie wzrosła z 69 (2020) do 506 (2024). W 2024 r., według Check Point Research, organizacje medyczne odpowiadały za około 10% wszystkich publicznie ujawnionych ofiar ransomware - drugie miejsce po przemyśle wytwórczym.

Jak się bronić - wnioski dla dostawców i placówek

Niezależnie od tego, jak dokładnie przebiegł ten atak, deklarowany łańcuch wskazuje na typowe, naprawialne słabości. W kolejności priorytetów:

1. Utwardź parsowanie XML (obrona przed XXE). Wyłącz encje zewnętrzne i rozwijanie DTD w parserach XML; korzystaj z bibliotek w konfiguracji „secure by default". To najskuteczniejsze i najtańsze łagodzenie XXE, także przy przetwarzaniu certyfikatów i podpisanych dokumentów.
2. Wyprowadź sekrety z kodu i hostów. Klucze API (jak rzekomy token do GitHuba) i poświadczenia chmurowe trzymaj w dedykowanym magazynie sekretów, wstrzykiwane w trakcie działania, z krótkim czasem życia. Skanuj repozytoria pod kątem zaszytych sekretów i po każdej ekspozycji rotuj wszystko.
3. Least privilege w chmurze. Załóż, że pojedynczy host zostanie przejęty, i ogranicz zasięg: wąskie role IAM, segmentacja, brak „płaskiej" drogi z aplikacji front-end do pełnej bazy pacjentów. Dostęp do danych wrażliwych - za dodatkowymi barierami.
4. Monitoring i kontrola ruchu wychodzącego. Eksfiltracja 2,5 TB to zdarzenie, które powinno zostawić ślad. Filtruj egress, alarmuj na nietypowe transfery i loguj dostęp do danych. Ciągły wgląd bije kwartalny audyt, gdy liczy się wykrycie w godzinach, nie miesiącach.
5. Bezpieczeństwo łańcucha dostaw. Dla placówki dostawca EDM to element własnej powierzchni ataku. Wpisz do umów wymogi bezpieczeństwa, prawo do audytu i tryb notyfikacji o incydentach - to także wprost wymóg NIS2/KSC.

Co może zrobić pacjent

Na dziś nie ma prostego sposobu, by samodzielnie sprawdzić obecność w tym wycieku, więc warto działać prewencyjnie. Rozsądne kroki to zastrzeżenie numeru PESEL (usługa mObywatel/rejestr zastrzeżeń), czujność na phishing i vishing odwołujący się do „danych medycznych" lub recept, oraz ostrożność wobec telefonów i e-maili żerujących na tej sprawie. Numeru PESEL nie da się „unieważnić", ale jego zastrzeżenie utrudnia nadużycia finansowe.

Co z tego wynika

Atak na MyDr - o ile potwierdzi się jego skala - pokazuje, że pojedynczy dostawca oprogramowania medycznego może stać się pojedynczym punktem awarii dla danych milionów pacjentów. To wprost tematyka NIS2/KSC: zarządzanie podatnościami, kontrola dostępu, bezpieczeństwo łańcucha dostaw i zdolność wykrywania incydentów. Kierunek jest ten sam, o którym pisaliśmy przy kampanii GTG-1002 i agentowym ransomware JadePuffer - rośnie skala i tempo, a najsłabszym ogniwem bywa higiena podstaw: parsowanie danych, sekrety, uprawnienia.

Szczegóły wymogów opisaliśmy na stronie NIS2 / KSC. Jeśli budujesz lub hostujesz systemy przetwarzające dane wrażliwe i chcesz sprawdzić swoją odporność - od podatności typu XXE/RCE, przez higienę sekretów, po zasięg po przejęciu pojedynczego hosta - to dokładnie nasza specjalizacja: testy penetracyjne i weryfikacja powierzchni ataku. Umów konsultację, zanim zrobi to za ciebie ktoś, kto zapuka wiadomością „mamy wyniki waszego audytu".

Źródła: Zaufana Trzecia Strona · CRN Polska · ITwiz · Bankier.pl · iMagazine · Komunikat MyDr (FAQ)