ARTEX prowadzi nową falę agentycznych ram ofensywnych
Detection stack
- AIDR
- Alert
- ETL
- Query
Podsumowanie
Podmioty zagrażające coraz częściej wykorzystują agentowe, napędzane LLM ramy, takie jak ARTEX, PentAGI i CAIRN, do automatyzacji złożonych cykli życia ataków. Te systemy wieloagentowe umożliwiają szybkie rozpoznanie, ruch boczny i eskalację uprawnień w tempie maszynowym. Ta ewolucja oznacza przejście w kierunku wysoce zautomatyzowanych, skalowalnych intruzji, które stanowią dodatkowe wyzwanie dla tradycyjnych strategii obronnych.
Śledztwo
Mandiant i GTIG zaobserwowały te ramy podczas rzeczywistych zaangażowań w odpowiedzi na incydenty, w tym działalność powiązaną z grupami takimi jak UNC7228 (STORM-0940). Dochodzenia dokumentowały wybuchy o wysokiej prędkości, w tym 27 zdarzeń w ciągu 23 sekund, obok zautomatyzowanej korekcji błędów używanej do wdrażania powłok sieciowych. Badacze podkreślali również, jak te narzędzia nadużywają uprawnień chmury i legalnych API aplikacji, aby osiągnąć cele atakujących.
Łagodzenie
Obrońcy powinni przyjąć pięciowarstwową strategię obrony: ochronę płaszczyzn kontrolnych, ograniczanie tożsamości i kluczy za pomocą krótkotrwałych poświadczeń, wzmocnienie konfiguracji, zabezpieczanie funkcji aplikacji przed nadużyciami oraz monitorowanie anomalii behawioralnych i wolumetrycznych. Redukcja zewnętrznej powierzchni ataku i ograniczanie zbędnej ekspozycji administracyjnej pozostają kluczowymi środkami obronnymi.
Odpowiedź
Gdy wykryte zostanie podejrzane działanie, organizacje powinny priorytetować reakcję opartą na tożsamości, ponieważ wiele działań opiera się na ważnych poświadczeniach. Monitoruj nieoczekiwane wybuchy wezwań API zarządzania, nieoczekiwane źródła uwierzytelniania i nagłe zmiany w wzorcach dostępu do płaszczyzny danych. Szybkie unieważnianie skompromitowanych tożsamości i badanie pełnego zakresu zautomatyzowanego ruchu lateralnego jest niezbędne.
Przepływ ataku
Nadal aktualizujemy tę część.
Detekcje
Możliwe ataki DCSync (poprzez audyt)
Możliwe działania Kerberoasting [korelacja/bucket_span_10m/po src_user] (poprzez audyt)
Możliwe działania Kerberoasting [korelacja/bucket_span_10m/po src_ipaddr] (poprzez audyt)
Typowe podejrzane filtry wyszukiwania LDAP (poprzez usługę katalogową)
Nagły wzrost odpowiedzi kodu statusu HTTP 40* dla jednego IP (poprzez serwer www)
Możliwe Infiltracje/Ekfiltracje Danych/C2 za pośrednictwem Usług/Tools firm trzecich (poprzez proxy)
Możliwa dystrybucja złośliwego oprogramowania za pośrednictwem punktów końcowych WebsiteHook (poprzez proxy)
Możliwa dystrybucja złośliwego oprogramowania za pośrednictwem punktów końcowych WebsiteHook (poprzez dns)
Możliwe zidentyfikowanie użytkownika AWS za pomocą kodów błędów API (poprzez ślad w chmurze)
Wykrywanie sondowania rekonesansowego ARTEX w katalogach sieciowych [Serwer www]
Wykrywanie działań rekonesansu ARTEX na platformie Azure [Dzienniki aktywności Azure]
Wykrywanie działań rekonesansu ARTEX [Cloudtrail AWS]
Wykonanie symulacji
-
Narracja ataku i polecenia: Przeciwnik wdrażający ramę ARTEX dąży do odwzorowania uprawnień środowiska chmurowego. Aby zweryfikować możliwości zapisu/usuwania w Azure, rama wykonuje szybką sekwencję tworzenia blobu o nazwie
TinyTestBlobnatychmiast po czym następuje jego usunięcie. Jednocześnie, w środowisku AWS, przeciwnik próbuje wypisać lub zmodyfikować instancje EC2, używając flagi--dry-run. Pozwala to potwierdzić, czy ich obecna rola IAM ma wystarczające uprawnienia bez wyzwalania rzeczywistych zmian stanu lub generowania dzienników sukcesu, zamiast tego opierając się na kodzie błęduDryRunOperationw celu potwierdzenia statusu „odmówiono” lub „dozwolono”. -
Skrypt testu regresji:
# Skrypt symulacji ramy ARTEX Write-Host "[!] Rozpoczynanie symulacji rekonesansu ARTEX..." # --- Część 1: Rekonesans blobu Azure --- Write-Host "[*] Symulowanie zapisu/usuwania Azure TinyTestBlob..." $azureAccount = "artex_test_account" $container = "recon-container" $blobName = "TinyTestBlob" $testFile = ".temp_recon.txt" "recon_data" | Out-File $testFile # Symulacja szybkiego wzorca zapisu/usuwania try { Set-AzStorageBlobContent -File $testFile -Container $container -Blob $blobName -Context $ctx -ErrorAction Stop Write-Host "[+] Zapis Azure pomyślny" Remove-AzStorageBlob -Blob $blobName -Container $container -Context $ctx -ErrorAction Stop Write-Host "[+] Usunięcie Azure pomyślne" } catch { Write-Error "Symulacja Azure nie powiodła się: $_" } # --- Część 2: Rekonesans AWS EC2 DryRun --- Write-Host "[*] Symulowanie sprawdzania uprawnień AWS EC2 DryRun..." # Ta komenda ma na celu zakończyć się niepowodzeniem z błędem DryRunOperation, jeśli uprawnienia są obecne lub nieobecne aws ec2 describe-instances --dry-run --region us-east-1 if ($LASTEXITCODE -ne 0) { Write-Host "[+] Sprawdzenie DryRun AWS zakończone (oczekiwany kod błędu)" } Remove-Item $testFile Write-Host "[!] Symulacja zakończona." -
Polecenia czyszczenia:
# Czyszczenie artefaktów symulacji Remove-Item -Path ".temp_recon.txt" -ErrorAction SilentlyContinue # Uwaga: Blob w Azure został już usunięty przez skrypt symulacyjny.