Załącznik techniczny do zawiadomienia z dnia 01.09.2026 r.

25 i 26 sierpnia 2026 r. doszło do nieuprawnionego dostępu do naszego wewnętrznego systemu analitycznego. System ten służy nam do analityki i nie jest częścią aplikacji Kadromierz, z której korzystają nasi klienci. Osoba nieuprawniona wykorzystała podatność w mechanizmie resetowania hasła, uzyskała uprawnienia administratora tego systemu i uzyskała przez niego dostęp do podłączonych baz danych.

Potwierdziliśmy, że pobrane zostały dane kilkunastu pracowników Kadromierz korzystających z systemu analitycznego: imiona i nazwiska, adresy e-mail oraz skróty haseł do tego systemu. Osoba nieuprawniona pobrała również informacje o strukturze naszych baz danych, czyli nazwy tabel i kolumn. Usunęła ponadto zawartość samego systemu analitycznego - zapisane pytania i dashboardy - co nie objęło danych w podłączonych bazach.

Do bazy zawierającej dane osobowe klientów skierowano 16 zapytań. Nie znamy ich treści, ponieważ zapisy techniczne od dostawcy infrastruktury ich nie zawierają. Czasy wykonania tych zapytań wskazują, że nie doszło do pobrania danych w większej ilości. Nie znaleźliśmy również śladu, by dane z baz opuściły nasz system. Na tym etapie nie możemy jednak potwierdzić ani wykluczyć naruszenia ochrony danych osobowych naszych klientów - informujemy o tym również na bieżąco na stronie poświęconej incydentowi.

Analiza wskazuje, że był to atak zautomatyzowany, prowadzony masowo przeciwko wielu systemom naraz, a nie działanie wymierzone w Kadromierz.

Poniżej opisujemy szczegółowo, co ustaliliśmy i na jakiej podstawie. Wskazujemy również, czego na tym etapie nie wiemy.

Poniżej przedstawiamy chronologię ustaloną na podstawie logów systemu analitycznego oraz logów po stronie BigQuery. Wszystkie godziny podano w czasie polskim (CEST, UTC+2).

25 sierpnia, ok. 12:00 - wzrost natężenia ruchu kierowanego do systemu analitycznego.

25 sierpnia, 19:02 - osoba nieuprawniona uzyskała dostęp do konta administratora systemu, wykorzystując podatność w mechanizmie resetowania hasła.

25 sierpnia, 20:16–20:18 - pobrała informacje o strukturze wszystkich podłączonych baz danych: nazwy tabel i kolumn.

25 sierpnia, 20:17–21:58 - wykonała 145 zapytań do baz danych, korzystając z poznanej struktury. Szczegóły w sekcji 4.

26 sierpnia, 10:40 - w ciągu 18 sekund usunęła zawartość systemu analitycznego: zapisane pytania i dashboardy, a także 21 z 22 połączeń do baz danych. Usunięcie nie objęło danych w podłączonych bazach.

26 sierpnia, 12:39 - podjęła nieudaną próbę pozyskania poświadczeń i danych osobowych. Wszystkie zapytania zakończyły się błędem. Szczegóły w sekcji 6.

26 sierpnia 17:02 → 27 sierpnia 04:47 - założyła osiem kont administracyjnych, aby utrzymać dostęp do systemu.

26 sierpnia 20:45 → 27 sierpnia 04:47 - założyła osiem kont administracyjnych na zewnętrzne adresy, tworząc kanał komunikacji na zewnątrz. Odnotowaliśmy osiem wywołań tego kanału. Szczegóły w sekcji 5.

27 sierpnia, 07:59 - podjęła próbę usunięcia ostatniego połączenia do bazy danych. Operacja zawiesiła się i połączenie pozostało aktywne.

27 sierpnia, 14:33 - ostatnia zarejestrowana aktywność osoby nieuprawnionej.

27 sierpnia, 16:03 - nasz zespół techniczny wykrył nieuprawniony dostęp i zgłosił go do działu bezpieczeństwa.

27 sierpnia, 17:00 - odłączyliśmy system analityczny od internetu.

27 sierpnia, 20:00 - wymieniliśmy hasła do wszystkich baz danych. Od tej chwili system nie miał ani dostępu do danych, ani możliwości komunikacji na zewnątrz.

Dalsze działania opisujemy w sekcji 7.

Incydent bada nasz wewnętrzny zespół bezpieczeństwa i IT razem z zewnętrznymi specjalistami od cyberbezpieczeństwa. Do zdarzenia doszło w trakcie zaplanowanych testów penetracyjnych środowiska Kadromierz, dzięki czemu do analizy mogliśmy od razu włączyć dodatkowych specjalistów pracujących wtedy w tym środowisku. 27 sierpnia do sprawy włączyliśmy również zewnętrzną kancelarię prawną.

Ustalenia opieramy na logach systemu analitycznego oraz na logach po stronie BigQuery. Wystąpiliśmy również do dostawcy infrastruktury o zapisy techniczne z baz danych i otrzymaliśmy je w zakresie, jakim dostawca dysponuje. Nie zawierają one treści zapytań kierowanych do baz ani liczby zwróconych rekordów, ponieważ dostawca nie przechowuje takich zapisów dla wskazanego okresu.

Ma to bezpośredni wpływ na to, co możemy dziś stwierdzić. Brakujące zapisy mogły zawierać treść zapytań kierowanych do baz danych - informację, której system analityczny nie rejestruje. Bez nich nie jesteśmy w stanie ustalić definitywnie, po jakie dane osoba upoważniona sięgała ani ile rekordów zwróciły poszczególne zapytania. W miejscach, w których nasze wnioski opierają się na przesłankach pośrednich, zaznaczamy to wyraźnie.

Dane pracowników Kadromierz

Potwierdziliśmy naruszenie ochrony danych osobowych kilkunastu pracowników Kadromierz, którzy byli użytkownikami systemu analitycznego. Ich dane znajdowały się bezpośrednio w tym systemie, a nie w podłączonych do niego bazach, dlatego dysponujemy tu pełnymi zapisami i wiemy, że zostały pobrane.

Naruszenie objęło imię i nazwisko, adres e-mail oraz skrót hasła do systemu analitycznego. Dotyczy wyłącznie dostępu do tego systemu i nie obejmuje danych logowania do aplikacji Kadromierz.

System analityczny przywróciliśmy do wcześniejszej wersji, odłączyliśmy od baz danych oraz od sieci publicznej.

Struktura baz danych

Osoba nieuprawniona pobrała informacje o strukturze baz danych Kadromierz: nazwy tabel i kolumn. Nie są to dane osobowe, ale sama znajomość struktury ułatwia kolejne próby ataku, dlatego traktujemy to ustalenie poważnie.

Usunięcie zawartości systemu analitycznego

Osoba nieuprawniona usunęła zapisane w systemie pytania i dashboardy, czyli definicje zapytań i widoków analitycznych, z których korzystaliśmy wewnętrznie. Zawartość odtworzyliśmy w znacznym stopniu, przywracając system do wcześniejszej wersji. Usunięcie nie objęło danych w podłączonych bazach danych.

Czego ta sekcja nie obejmuje

Powyższe dotyczy wyłącznie ustaleń, co do których mamy pewność. Kwestię dostępu do bazy zawierającej dane osobowe klientów omawiamy w sekcji 4 - na tym etapie nie możemy potwierdzić ani wykluczyć naruszenia w tym zakresie.

Osoba nieuprawniona miała dostęp do systemu analitycznego z uprawnieniami administratora, a przez ten system do podłączonych baz danych, w tym bazy zawierającej dane osobowe klientów.

Główna aktywność miała miejsce 25 sierpnia między 20:17 a 21:58. Z konta administracyjnego wykonano wtedy 145 zapytań. 78 z nich trafiło do BigQuery i wszystkie zakończyły się błędem, nie zwracając żadnych danych — potwierdzają to logi po stronie BigQuery. Pozostałe 67 zapytań mogło zwrócić dane. Spośród nich 16 skierowano do bazy zawierającej dane osobowe klientów. Baza ta liczy ponad 40 tabel, z których mała część zawiera dane osobowe. Nie wiemy, do których tabel trafiły te zapytania, ponieważ nie znamy ich treści.

System analityczny dostawcy baz danych nie dostarcza informacji o treści zapytań, więc nie znamy liczby rekordów zwróconych przez poszczególne zapytania.

Skalę odczytu szacujemy więc pośrednio, na podstawie czasu wykonania. Wszystkie 67 zapytań, które mogły zwrócić dane, wykonały się łącznie w 4 sekundy. Szesnaście zapytań do bazy z między innymi danymi osobowymi klientów zajęło łącznie 0,9 sekundy, przy medianie 53 milisekund na zapytanie.

Uznajemy tę miarę za wiarygodną, ponieważ w tych samych zapisach widzimy zwykłe, niezwiązane z incydentem operacje systemu trwające po kilkadziesiąt sekund, zarejestrowane z pełnym czasem. Czasy nie są zaokrąglane ani skracane. Zapytanie zwracające dużą liczbę rekordów trwałoby zauważalnie dłużej i byłoby w zapisach widoczne.

Takie czasy odpowiadają sprawdzaniu i próbkowaniu danych, a nie pobieraniu ich w większej ilości. Jest to jednak wnioskowanie pośrednie i mówimy o tym otwarcie: nie pozwala ono ustalić, ile dokładnie rekordów zostało odczytanych. Pozwala natomiast wskazać górną granicę skali. Z tego powodu na obecnym etapie nie możemy potwierdzić ani wykluczyć naruszenia ochrony danych osobowych klientów. W sekcji 5 opisujemy osobno, dlaczego nie znaleźliśmy śladu, by dane z tych baz opuściły system.

Osoba nieuprawniona utworzyła jeden kanał komunikacji z zewnątrz: przekierowała funkcję asystenta AI w systemie analitycznym na kontrolowane przez siebie adresy.

Zapisy rejestrują osiem wywołań tego kanału, wszystkie o identycznym przebiegu. W czasie wokół tych wywołań asystent nie odpytał żadnego źródła danych.

Kanał utworzono około 10 godzin po tym, jak usunięto 21 z 22 połączeń systemu do baz danych. Jedynym źródłem, które wtedy pozostało podłączone, było BigQuery — próba usunięcia tego połączenia zawiesiła się i pozostało ono aktywne.

Dysponujemy logami po stronie BigQuery i wynika z nich, że wszystkie skierowane tam zapytania zakończyły się błędem składni, którego ani razu nie skorygowano. Żadne z nich nie zwróciło danych.

Sprawdziliśmy również pozostałe mechanizmy, którymi można wyprowadzić dane z systemu: pobieranie plików, subskrypcje wysyłane e-mailem oraz publiczne linki udostępniające. Żaden z nich nie został wykorzystany po przejęciu konta.

27 sierpnia o godz. 17:00 odłączyliśmy system analityczny od internetu i jednocześnie wymieniliśmy hasła do wszystkich baz danych. Od tego momentu system nie miał ani dostępu do danych, ani możliwości komunikacji na zewnątrz. Zamknęło to wszystkie drogi wyprowadzenia danych, niezależnie od tego, jakie mechanizmy osoba nieuprawniona pozostawiła w systemie.

Na tej podstawie nie znaleźliśmy śladu, by dane z baz podłączonych do systemu analitycznego zostały wyprowadzone na zewnątrz.

26 sierpnia z przejętego konta sprawdzano w naszych bazach 34 nazwy tabel z gotowej listy. Znalazły się na niej nazwy pochodzące ze szwedzkiego systemu księgowego Fortnox, z fińskiego agregatora usług bankowych oraz z systemów płatniczych — pozycje takie jak „fortnox_invoice", „enablebanking_session" czy „stripe_customer". Nie mają one żadnego związku z systemem do zarządzania czasem pracy i kadrami. Lista nie powstała na potrzeby ataku na Kadromierz; jest to zestaw wielokrotnego użytku, najprawdopodobniej pochodzący ze struktury innego, wcześniej zaatakowanego systemu.

Dwie z tych nazw istnieją w naszym środowisku, ale w bazach, które w chwili próby nie były już podłączone do systemu. Pozostałe nie istniały w naszych bazach w ogóle, więc wszystkie zapytania z tej fazy zakończyły się niepowodzeniem. Lista nie zmieniła się ani razu, mimo powtarzających się błędów. Ten sam brak reakcji widać w logach BigQuery: wszystkie skierowane tam zapytania zawierały błąd składni, którego również nigdy nie poprawiono.

Dzień wcześniej pobrano informacje o strukturze naszych baz. Rzeczywisty układ był więc znany, a mimo to nie został wykorzystany. Przekierowanie asystenta AI również nastąpiło na osiem różnych adresów w publicznym serwisie do przechwytywania żądań, co odpowiada działaniu skryptu sprawdzającego kolejne warianty, a nie osoby prowadzącej atak świadomie.

Wskazuje to na atak zautomatyzowany, prowadzony masowo przeciwko wielu systemom naraz, wykorzystujący publicznie znaną podatność, a nie na działanie wymierzone w Kadromierz.

Zastrzegamy, że powyższe dotyczy fazy z 26 sierpnia. Wcześniejsza sesja z 25 sierpnia, opisana w sekcji 4, była prowadzona w oparciu o rzeczywistą znajomość struktury naszego środowiska. Jak omówiliśmy w poprzednich sekcjach, również w jej przypadku czasy wykonania zapytań wskazują, że nie doszło do pobrania danych w większej ilości, i nie znaleźliśmy śladu, by dane opuściły system.

27 sierpnia — odłączyliśmy system analityczny od internetu i wymieniliśmy hasła do wszystkich baz danych. Usunęliśmy podatność w mechanizmie resetowania hasła. Do sprawy włączyliśmy zewnętrzną kancelarię prawną.

28 sierpnia — w aplikacji Kadromierz unieważniliśmy wszystkie sesje logowania. Każdy użytkownik został wylogowany, a firmy korzystające z integracji musiały wygenerować nowy klucz. Unieważniliśmy również niewykorzystane linki z zaproszeń do systemu i z niedokończonych resetów hasła, zablokowaliśmy ruch z regionów, w których nie mamy użytkowników, oraz uruchomiliśmy wymuszenie ustawienia nowego hasła na środowisku produkcyjnym.

System analityczny przywróciliśmy do wcześniejszej wersji, co usunęło konta założone w trakcie incydentu oraz utworzony wtedy kanał komunikacji z zewnątrz. System pozostaje odłączony od baz danych i od sieci publicznej.

Pragniemy poinformować, że zakończyliśmy pełną analizę techniczną incydentu bezpieczeństwa z końca sierpnia, prowadzoną przy wsparciu zewnętrznego zespołu specjalistów ds. cyberbezpieczeństwa. Niniejszy komunikat stanowi uzupełnienie naszych poprzednich informacji i zamyka fazę dochodzeniową, przedstawiając ostateczne wnioski dotyczące skali naruszenia.

W poprzednich komunikatach informowaliśmy, że do bazy zawierającej dane osobowe klientów skierowano 16 zapytań. Ponieważ ani system analityczny, ani logi dostawcy infrastruktury nie zarejestrowały samej treści tych zapytań, odczyt danych klientów pozostaje niepotwierdzony i nie da się ustalić dokładnej liczby potencjalnie pobranych rekordów. Udało nam się jednak zgromadzić nowe, niezależne od siebie pomiary z warstwy infrastruktury, które pozwalają nam z dużym prawdopodobieństwem oszacować, że skala odczytu była znikoma.

Najważniejszym nowym ustaleniem, pozyskanym ze statystyk silnika bazy danych po stronie jednego z klastrów, jest odzyskanie treści 22 zapytań, które w tym samym czasie włamywacz skierował do naszych baz pomocniczych.

Analiza tych zapytań przyniosła jednoznaczny wynik: wszystkie 21 zapytań dotyczących danych (z serii liczącej 22 zapytania) miało narzucony limit wyników do zaledwie 3 wierszy. Wzorzec ten występował bez żadnych odstępstw na przestrzeni półtorej godziny działań zautomatyzowanego skryptu. Pozostałe 1 zapytanie dotyczyło pobranie listy tablic w bazach.

Co wiemy na pewno, a co wnioskujemy z tego odkrycia?

Nasze szacunki dotyczące bardzo małej skali pobierania danych potwierdzają twarde, niezależne metryki infrastrukturalne, na które osoba nieuprawniona nie miała żadnego wpływu:

Niezależnie od naszych szacunków opartych na odzyskanych limitach 3 wierszy, potwierdziliśmy również twardą barierę wynikającą z mechaniki samego systemu analitycznego. Prezentuje on wyniki zapytania w liczbie maksymalnie 2 000 wierszy. Przekroczenie tej liczby wymagałoby uruchomienia eksportu do pliku, a z analizy wynika, że żaden kanał eksportu nie został użyty. Daje to bezwzględną górną granicę 32 000 wierszy dla 16 zapytań – jest to sufit, którego nie dało się przekroczyć.

Zebrane dowody – błyskawiczne czasy zapytań, znikomy ruch sieciowy oraz zidentyfikowany w innych bazach twardy limit pobierania zaledwie 3 rekordów per zapytanie – składają się na spójny obraz działania. Atak miał charakter zautomatyzowanego przeszukiwania struktury (odpytywania nazw tabel używanych w obcych systemach finansowych, co daje 6% skuteczności w naszej infrastrukturze), a nie ukierunkowanej kradzieży paczek danych.

Wszystkie drogi wyprowadzenia danych zostały przez nas zamknięte, w tym poprzez odłączenie systemu analitycznego od publicznego internetu. Faza analizy incydentu dobiegła końca, co pozwala nam w pełni skupić się na wdrażaniu dodatkowych warstw ochrony.

Zaplanowaliśmy niezależny audyt bezpieczeństwa przeprowadzany przez zewnętrzną firmę, który zweryfikuje poprawne usunięcie podatności będącej przyczyną incydentu, a także oceni poziom bezpieczeństwa całego naszego systemu. Liczymy również, że audyt ten wskaże nam dodatkowe działania i metody zabezpieczeń, które wdrożymy.

Niezależnie od zaleceń, które otrzymamy po audycie, już teraz aktywnie realizujemy własny plan rozbudowy bezpieczeństwa, który obejmuje: