Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
REDCap to webowa platforma wykorzystywana do tworzenia i obsługi baz danych dla badań klinicznych, projektów naukowych oraz procesów gromadzenia danych w sektorze medycznym i akademickim. Ze względu na charakter przetwarzanych informacji system ten często funkcjonuje w środowiskach o wysokiej wartości operacyjnej, regulacyjnej i badawczej. Najnowsze ustalenia pokazują jednak, że znaczna część publicznie dostępnych instancji REDCap działa na nieaktualnym oprogramowaniu, co zwiększa powierzchnię ataku i podnosi ryzyko kompromitacji.
W skrócie
Analizy ekspozycji REDCap w internecie wskazują, że globalnie widocznych jest około 8,5 tys. instancji tego systemu. Jednocześnie tylko niewielki odsetek działa na najnowszej wersji, a większość korzysta ze starszych wydań, które mogą być bardziej podatne na nadużycia i trudniejsze w bezpiecznym utrzymaniu.
Problem nabiera szczególnego znaczenia w świetle informacji o aktywności grupy UNC6508. Według analityków aktor ten koncentrował się na webowych serwerach REDCap w kampaniach cyberszpiegowskich wymierzonych w organizacje badawcze, medyczne i akademickie.
Kontekst / historia
REDCap jest szeroko stosowany w instytucjach naukowych, szpitalach, ośrodkach badawczych oraz organizacjach non-profit. Tego typu środowiska przechowują dane wrażliwe, informacje badawcze, dokumentację projektową oraz metadane dotyczące uczestników badań, co czyni je atrakcyjnym celem dla podmiotów prowadzących wywiad cybernetyczny.
W czerwcu 2026 roku opisano kampanię prowadzoną przez UNC6508, aktora powiązanego z interesami Chińskiej Republiki Ludowej. Ataki miały dotyczyć instytucji z Ameryki Północnej działających w obszarach badań medycznych, akademickich i wojskowych. Według ustaleń napastnicy interesowali się podatnymi, starszymi wersjami REDCap, a po uzyskaniu dostępu wykorzystywali infrastrukturę do rozpoznania wewnętrznego, pozyskiwania poświadczeń i dalszego ruchu bocznego.
Dodatkowym problemem pozostaje model eksploatacyjny samej platformy. W praktyce administratorzy mogą utrzymywać starsze wersje równolegle z nowszymi, co z perspektywy ciągłości działania bywa wygodne, ale jednocześnie utrudnia pełne usunięcie historycznych komponentów z powierzchni ataku.
Analiza techniczna
Z technicznego punktu widzenia główny problem nie wynika wyłącznie z samej ekspozycji REDCap do internetu, lecz z połączenia kilku czynników: publicznej dostępności, obecności starszych wersji, wysokiej wartości danych oraz możliwości wykorzystania serwera aplikacyjnego jako punktu wejścia do dalszej penetracji środowiska.
Według dostępnych analiz około 30% obserwowanych instancji działało na wersji 16.0.17, kolejne na wersjach 16.1.4 i 16.0.15, podczas gdy najnowsza wersja identyfikowana w badaniu to 17.1.3. Taki rozkład sugeruje powszechne zaległości w zarządzaniu cyklem życia aplikacji oraz ograniczoną skuteczność procesów aktualizacyjnych.
Scenariusz ataku opisany przez badaczy pokazuje klasyczny łańcuch kompromitacji. Napastnik najpierw identyfikuje publicznie dostępne instancje i wersje oprogramowania. Następnie sonduje starsze wydania pod kątem słabości konfiguracyjnych, błędów aplikacyjnych lub niezałatanych luk. Po uzyskaniu początkowego dostępu może wdrożyć złośliwe komponenty do kradzieży poświadczeń, przeprowadzić rekonesans środowiska, zebrać dane dostępowe do usług oraz przygotować mechanizmy trwałości.
W jednym z opisanych przypadków po początkowym naruszeniu wdrożono niestandardowy backdoor, a następnie przez długi czas utrzymywano obecność w środowisku bez wykrycia. To pokazuje, że REDCap nie musi być końcowym celem ataku. Może pełnić rolę przyczółka do późniejszego dostępu do sieci wewnętrznej, baz danych, serwerów aplikacyjnych i systemów przechowujących dane badawcze.
Istotny jest również aspekt architektoniczny. Jeżeli serwer WWW i baza danych nie są odpowiednio odseparowane, skutki przejęcia frontendu aplikacyjnego mogą być znacznie poważniejsze. Brak segmentacji sieciowej, zbyt szerokie uprawnienia kont serwisowych oraz słaba kontrola dostępu do zaplecza bazy danych zwiększają prawdopodobieństwo eskalacji incydentu.
Konsekwencje / ryzyko
Dla organizacji korzystających z REDCap ryzyko obejmuje kilka warstw. Pierwsza to ujawnienie danych, w tym informacji badawczych, medycznych i operacyjnych. Druga to kradzież poświadczeń, które mogą zostać użyte do przejęcia kolejnych systemów. Trzecia to długotrwała, trudna do wykrycia obecność przeciwnika w środowisku.
W praktyce zagrożone są nie tylko same instancje REDCap, ale również powiązane zasoby: serwery bazodanowe, katalogi sieciowe, systemy pocztowe, platformy IAM oraz narzędzia administracyjne. Jeżeli kompromitacja zostanie wykorzystana do ruchu bocznego, incydent może objąć znacznie większy obszar niż pojedyncza aplikacja.
Szczególnie wysokie ryzyko dotyczy instytucji badawczych i ochrony zdrowia, gdzie wartość informacji wykracza poza dane osobowe. Przedmiotem zainteresowania mogą być także wyniki badań, dokumentacja dotycząca grantów, dane projektowe, informacje o współpracy z sektorem publicznym oraz materiały o znaczeniu strategicznym.
Rekomendacje
Organizacje eksponujące REDCap do internetu powinny w pierwszej kolejności przeprowadzić pełną inwentaryzację wszystkich instancji, w tym środowisk testowych, historycznych i utrzymywanych równolegle wersji. Kluczowe jest ustalenie, które systemy są faktycznie dostępne publicznie oraz jakie wersje oprogramowania uruchamiają.
Następnie należy wdrożyć rygorystyczne zarządzanie aktualizacjami. Starsze wersje powinny zostać wycofane lub zaktualizowane do wspieranych wydań. W środowiskach, w których równoległe utrzymywanie wersji jest niezbędne operacyjnie, konieczne jest ograniczenie ich ekspozycji oraz odizolowanie od sieci publicznej.
- przeprowadzenie pełnej inwentaryzacji instancji REDCap i środowisk towarzyszących,
- aktualizacja lub wycofanie starszych, publicznie dostępnych wersji,
- separacja serwera WWW od serwera bazy danych,
- umieszczenie bazy danych za zaporą sieciową,
- ograniczenie dostępu administracyjnego do zaufanych adresów i kanałów VPN,
- stosowanie MFA dla administratorów i kont uprzywilejowanych,
- monitorowanie logów aplikacyjnych, bazodanowych i systemowych pod kątem nietypowych żądań oraz prób enumeracji,
- przegląd uprawnień kont serwisowych i regularna rotacja poświadczeń,
- wdrożenie detekcji dla nietypowego dostępu do danych badawczych i transferów wychodzących,
- regularne skanowanie powierzchni ataku z perspektywy zewnętrznej,
- threat hunting ukierunkowany na ślady długotrwałej obecności przeciwnika.
Podsumowanie
Problem przestarzałych, publicznie dostępnych serwerów REDCap należy traktować jako realne zagrożenie dla sektora medycznego, akademickiego i badawczego. Sama ekspozycja aplikacji nie musi prowadzić do incydentu, ale połączenie nieaktualnych wersji, wysokowartościowych danych i zainteresowania ze strony zaawansowanych grup APT znacząco podnosi ryzyko.
Najważniejszy wniosek jest operacyjny: REDCap powinien być objęty takim samym poziomem kontroli bezpieczeństwa jak inne systemy krytyczne. Aktualizacja wersji, segmentacja architektury, ograniczenie ekspozycji i monitorowanie aktywności to podstawowe działania, które mogą znacząco zmniejszyć prawdopodobieństwo skutecznego ataku.
Źródła
- SecurityWeek — Majority of Internet-Accessible REDCap Servers Outdated — https://www.securityweek.com/majority-of-internet-accessible-redcap-servers-outdated/
- Google Cloud Blog — Public and Private Medical Community Targeted by China-Nexus Threat Actor Pursuing Artificial Intelligence, Cyber, Medical, and National Defense Research — https://cloud.google.com/blog/topics/threat-intelligence/prc-targets-us-medical-research
- Vanderbilt University / Project REDCap — REDCap Technical Overview — https://projectredcap.org/wp-content/uploads/2025/01/REDCapTechnicalOverview.pdf