JPCERT/CC Wydaje Alert Cyberbezpieczeństwa po Wzroście Nieautoryzowanego Dostępu i Naruszeń Danych Osobowych w Japońskich Organizacjach
Detection stack
- AIDR
- Alert
- ETL
- Query
Podsumowanie
Zaobserwowano serię incydentów nieautoryzowanego dostępu wymierzoną w japońskie organizacje, prowadząc głównie do wycieku danych osobowych. Aktywność obejmuje wykorzystanie znanych podatności w oprogramowaniu, nieautoryzowane manipulacje API, ataki SQL injection w Metabase oraz wdrażanie web shelli przez pliki WAR. Te przypadki wydają się celować w systemy zarządzania, narzędzia BI oraz aplikacje wewnętrzne, które nigdy nie miały być wystawione na publiczny dostęp.
Śledztwo
JPCERT/CC zidentyfikowało wiele wektorów ataku, w tym wykorzystanie punktów końcowych API, ataków NoSQL injection oraz użycie konkretnych złośliwych adresów IP. Śledztwo pokazuje, że atakujący skanują pod kątem znanych podatności i błędnych konfiguracji, takich jak niechronione pliki konfiguracyjne lub kopie zapasowe. Ostatnie aktualizacje szczególnie podkreślają web shelle osadzone w plikach .war używane do wykonywania poleceń systemowych poprzez parametry zapytań.
Środki zaradcze
Sugerowane środki zaradcze obejmują ograniczanie szybkości na wrażliwych punktach końcowych API, rygorystyczne kontrole dostępu oraz aktualizacje zabezpieczeń dla podatnego oprogramowania, takiego jak Metabase. Organizacje powinny stosować zasadę najmniejszych uprawnień do tokenów API i ograniczać dostępność usług do określonych regionów geograficznych. Zdecydowanie zaleca się wzmocnienie systemów zarządzania i narzędzi BI, aby nie były wystawione na publiczny internet.
Odpowiedź
Po wykryciu organizacje powinny natychmiast unieważnić skompromitowane tokeny API, zablokować dostęp z zidentyfikowanych złośliwych IP i sprawdzić możliwość ruchów bocznych. Zaleca się przeglądanie logów serwera WWW pod kątem nietypowych żądań GET/POST oraz sprawdzenie nieautoryzowanych wdrożeń plików .war lub .jsp. Organizacje powinny również przygotować plany komunikacyjne w celu powiadomienia dotkniętych klientów o potencjalnych wtórnych szkodach.
Przebieg Ataku
Ciągle aktualizujemy tę część.
Wykrycia
Możliwe Wykorzystanie Serwera WWW lub WebApp [Windows] (poprzez cmdline)
Możliwe Utworzenie Webshell w Katalogach Microsoft Exchange / Sharepoint (poprzez file_event)
Możliwe Próbę Eksploatacji CVE-2026-72898 (Nieautoryzowany SQL Injection w Metabase) (poprzez serwer WWW)
Biblioteki klienta HTTP User-Agent do punktów uwierzytelniania (poprzez proxy)
Do wykrycia: Ostrzeżenie Dotyczące Niedawnego Nieautoryzowanego Dostępu do Krajowych Organizacji (SourceIP)
Do wykrycia: Ostrzeżenie Dotyczące Niedawnego Nieautoryzowanego Dostępu do Krajowych Organizacji (DestinationIP)
Podejrzana Aktywność API i SQL Injection IP [Firewall]
Symulacja Wykonania
-
Narracja Ataku i Komendy: Przeciwnik prowadzi rekonesans i skanowanie podatności (T1595.002) przeciwko publicznie dostępnemu API organizacji. Aby uniknąć wykrycia, atakujący zazwyczaj używa puli proxy; jednak w celach tej weryfikacji zasymulujemy atakera korzystającego z jednego z konkretnych adresów IP zdefiniowanych w czarnej liście wywiadu zagrożeń (np.
20.210.128.125). Celem jest zasymulowanie próby połączenia przychodzącego, które uderza w zaporę sieciową, wyzwalając regułę opartą na źródłowym IP. -
Skrypt Testu Regresyjnego:
# Ten skrypt symuluje połączenie sieciowe z czarnolistionego adresu IP. # Uwaga: W rzeczywistej symulacji zostałoby to wykonane przez kontrolowane # zewnętrzne źródło. Dla lokalnych testów wstrzykujemy wpis do logu do # potoku logów, aby odtworzyć sytuację, w której zapora widzi ten ruch. echo "$(date '+%b %d %H:%M:%S') firewall-01 filter: inbound permit tcp 20.210.128.125 44332 -> 192.168.1.50 443 tcp dport=443 spt=44332 state=NEW" >> /var/log/firewall.log echo "Symulacja: Wpis logu wstrzyknięty dla czarnolistionego IP 20.210.128.125" -
Polecenia Sprzątania:
# Usuń zsnumulowany wpis logu, aby przywrócić podstawową bazę sed -i '/20.210.128.125/d' /var/log/firewall.log echo "Sprzątanie: Zsnumulowany wpis logu usunięty."