Amazon ostrzega przed trwającą kampanią cryptominingu wykorzystującą przejęte konta AWS - Security Bez Tabu

Amazon ostrzega przed trwającą kampanią cryptominingu wykorzystującą przejęte konta AWS

Wprowadzenie do problemu / definicja luki

Amazon (AWS) poinformował o trwającej kampanii cryptominingu wymierzonej w klientów korzystających z Amazon EC2 i Amazon ECS. Atakujący nie wykorzystują luki w usługach AWS, lecz legalne, skompromitowane poświadczenia IAM (tożsamości i uprawnienia), co pozwala im szybko wdrażać koparki i utrzymywać się w środowisku dzięki nowym technikom utrwalania (persistence). AWS wykrył kampanię 2 listopada 2025 r. i opisał jej przebieg oraz wskaźniki kompromitacji (IoC).

W skrócie

  • Wejście uzyskiwane jest przez przejęte klucze/hasła IAM o uprawnieniach zbliżonych do admina. Koparki startują w ~10 minut od pierwszego logowania.
  • Wykorzystywane są EC2 (w tym instancje GPU/ML) oraz ECS/Fargate z agresywnym autoscalingiem (do 999 instancji w grupie).
  • Nowa technika persistence: masowe ustawianie ModifyInstanceAttribute → disableApiTermination: true utrudnia automatyczną reakcję/terminację.
  • W kampanii użyto złośliwego obrazu Docker Hub yenik65958/secret (usunięty) z SBRMiner-MULTI i pulami *.rplant.xyz:17155.
  • Media branżowe potwierdzają szczegóły (m.in. DryRun do sprawdzania uprawnień, publiczne Lambda URL i tworzenie użytkownika z SES Full Access).

Kontekst / historia / powiązania

Cryptojacking w chmurze nie jest nowy – wcześniejsze kampanie uderzały m.in. w AWS Lambda czy klastry kontenerowe, często opierając się na wykradzionych kluczach bądź błędach konfiguracji. Przykładowo w 2022 r. opisano pierwszy znany malware ukierunkowany na AWS Lambda. Dzisiejsza kampania wyróżnia się jednak tempem i dojrzałym łańcuchem działań w wielu usługach jednocześnie.

Analiza techniczna / szczegóły kampanii

Wejście i rozpoznanie

  • Logowanie z anomalii sieciowej przy użyciu skompromitowanego użytkownika IAM z uprawnieniami admin-like.
  • Szybkie sondowanie limitów EC2 (GetServiceQuota) oraz walidacja uprawnień przez wielokrotne wywołania RunInstances z flagą DryRun (tani „test” bez tworzenia instancji). To charakterystyczny, wczesny sygnał ostrzegawczy w logach CloudTrail.

ECS / Fargate – wpływ

  • Tworzenie dziesiątków klastrów ECS (czasem >50 w jednej ofierze).
  • Rejestracja task definition z obrazem yenik65958/secret:user, uruchamianie usług na Fargate z CPU=16384, RAM=32 GiB, desiredCount=10. Skrypt run.sh uruchamia RandomVIREL z pulami asia|eu|na.rplant.xyz:17155.

EC2 – wpływ

  • Tworzenie szablonów uruchamiania i 14 grup autoskalujących z parametrami do 999 instancji, celowanie w GPU/ML (g4dn/g5/p3/p4d/inf1) oraz instancje ogólnego przeznaczenia (c6i/m5/r5).

Persistence / utrudnianie IR

  • Masowe ustawienie disableApiTermination: true dla każdej instancji (via ModifyInstanceAttribute). To przerywa automatyczną remediację i zmusza zespoły do ręcznego cofnięcia ochrony przed terminacją.
  • Utworzenie publicznego URL w AWS Lambda (CreateFunctionUrlConfig z AuthType: NONE) oraz nadanie AddPermission z principal: "*".
  • Dodanie użytkownika user-x1x2x3x4 z polityką AmazonSESFullAccess – wskazuje to na potencjalne kampanie phishingowe przez Amazon SES.

IoC / Telemetria

  • Obraz: yenik65958/secret (Docker Hub – usunięty).
  • Domeny mining pool: asia|eu|na.rplant.xyz.
  • UA / narzędzia: ślady Boto3 (AWS SDK for Python).
  • Wzorce nazewnictwa ASG: SPOT-us-east-1-G*-* oraz OD-us-east-1-G*-*.

Wykrycie

  • Kampanię skorelowały mechanizmy Amazon GuardDuty Extended Threat Detection (m.in. AttackSequence:EC2/CompromisedInstanceGroup), łącząc TI, anomalie sieciowe i runtime. Niezależne serwisy (BleepingComputer, Dark Reading, THN) potwierdzają opis AWS.

Praktyczne konsekwencje / ryzyko

  • Koszty: gwałtowny wzrost wykorzystania zasobów (GPU/ML, Fargate) może przełożyć się na pięcio-/sześciocyfrowe kwoty na fakturze, zanim monitoring zareaguje. (Wprost wynika z opisu skalowania do setek instancji.)
  • Degradacja usług: wyczerpanie limitów i zasobów wpływa na aplikacje produkcyjne.
  • Bezpieczeństwo komunikacji: nadużycie SES do phishingu zwiększa ryzyko wtórnych incydentów (brand abuse, BEC).

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa higiena tożsamości

  • Rotacja wszystkich długoterminowych kluczy IAM; wymuś MFA dla użytkowników i ról, w tym break-glass.
  • Zasada najmniejszych uprawnień i tymczasowe poświadczenia (IAM Roles, SSO) zamiast długowiecznych access keys.

2) Szybkie kontrole detekcji

  • Sprawdź w CloudTrail nietypowe wywołania: RunInstances z DryRun, CreateServiceLinkedRole, CreateRole, RegisterTaskDefinition, CreateService, CreateLaunchTemplate, CreateAutoScalingGroup, ModifyInstanceAttribute (disableApiTermination=true), CreateFunctionUrlConfig (AuthType=NONE), AddPermission (principal="*"), tworzenie użytkowników i polityk SES.
  • W GuardDuty upewnij się, że masz Runtime Monitoring i Extended Threat Detection dla EC2/ECS.

3) Blokady prewencyjne (SCP/Config/CIEM)

  • Wdróż SCP zakazujące publicznych Lambda URL (FunctionUrlAuthType="NONE").
  • Wymuś image scanning i deny-listę podejrzanych rejestrów/obrazów dla ECS/Fargate.
  • Zablokuj możliwość ustawiania disableApiTermination poza procesem IR (np. przez SCP/Config Rules, reguły automatyczne). (Wniosek z analizy AWS).

4) Playbook reakcji (skrót)

  • Izoluj podejrzane instancje/klastry, cofnij disableApiTermination, terminuj workloady miningowe.
  • Rotuj wszystkie klucze i unieważnij sesje.
  • Przejrzyj SES (nadane uprawnienia, wysyłki), usuń publiczne Lambda URL/permissions.
  • Oceń koszty i wdróż budżety/limity + alerty kosztowe na poziomie kont i OU. (Zalecenia wprost/pośrednio z wpisu AWS).

Różnice / porównania z innymi przypadkami

W porównaniu z wcześniejszymi falami cryptojackingu w AWS, obecna kampania:

  • łączy wiele usług (ECS/Fargate + EC2) z agresywnym autoscalingiem,
  • wykorzystuje DryRun do cichej walidacji uprawnień,
  • utrudnia IR przez hurtowe disableApiTermination,
  • dobudowuje wektor phishingu (SES) i publiczne Lambda URL dla utrzymania obecności.
    Te elementy razem składają się na bardziej dojrzałą metodykę nadużycia skradzionych poświadczeń w chmurze.

Podsumowanie / kluczowe wnioski

  • To nie jest „bug w AWS” – to nadużycie zaufanych poświadczeń i błędów procesowych.
  • Sekundy i minuty mają znaczenie: atak osiąga pełną moc kopania w ~10 min; bez automatyki koszt eskaluje wykładniczo.
  • Detekcja wzorca (DryRun, disableApiTermination, publiczne Lambda URL, SES Full Access, obrazy spoza zaufanych rejestrów) powinna być stałą regułą w SIEM/SOAR.
  • GuardDuty (ETD + Runtime) + MFA, SCP, least privilege to dziś must-have dla każdego konta/OU.

Źródła / bibliografia

  1. AWS Security Blog – „Cryptomining campaign targeting Amazon EC2 and Amazon ECS” (16 grudnia 2025) – opis techniczny, IoC, rekomendacje. (Amazon Web Services, Inc.)
  2. BleepingComputer – „Amazon: Ongoing cryptomining campaign uses hacked AWS accounts” (17 grudnia 2025) – podsumowanie i kontekst rynkowy. (BleepingComputer)
  3. The Hacker News – „Compromised IAM Credentials Power a Large AWS Crypto Mining Campaign” (16 grudnia 2025) – dodatkowe szczegóły o DryRun, Lambda URL, SES. (The Hacker News)
  4. Dark Reading – „Attackers Use Stolen AWS Credentials in Cryptomining Campaign” (17 grudnia 2025) – potwierdzenie ETD/GuardDuty i IoC. (Dark Reading)
  5. The Record – „Cryptomining malware targeting AWS Lambda” (5 kwietnia 2022) – kontekst historyczny dot. wcześniejszych kampanii na AWS Lambda. (The Record from Recorded Future)