Krajobraz zagrożeń 05-11/02/2026

Obserwowane w ostatnim okresie incydenty jednoznacznie wskazują na przyspieszoną eskalację cyberzagrożeń, w której czas reakcji obrońców staje się czynnikiem krytycznym. Automatyzacja ataków wspierana przez duże modele językowe umożliwia przejmowanie środowisk chmurowych w czasie liczonym w minutach, przy jednoczesnym ograniczeniu udziału człowieka po stronie atakującej. Równolegle identyfikowane są wyrafinowane kampanie wymierzone w stacje robocze osób o podwyższonych uprawnieniach, narzędzia powszechnego użytku oraz systemy centralnego zarządzania tożsamością i urządzeniami. Wspólną cechą tych działań jest skrócenie ścieżki od podatności lub błędu konfiguracyjnego do pełnej kontroli operacyjnej nad środowiskiem oraz zdolność atakujących do dynamicznego dostosowywania wektorów eskalacji w trakcie trwania incydentu. Trzy poniższe analizy pokazują te zjawiska z różnych perspektyw, ale razem rysują spójny obraz nowej rzeczywistości, w której przewaga nie wynika już wyłącznie z zaawansowanych exploitów, ale z umiejętnego połączenia skali, czasu i inteligentnej orkiestracji ataku.

Future

„Chmury trudne są?” – nie dla LLMów

Zespół badawczy Sysdig Threat Research Team udokumentował incydent z 28 listopada 2025 r., który stanowi jeden z pierwszych dobrze opisanych przykładów w pełni zautomatyzowanego ataku na środowisko Amazon Web Services, wspieranego przez duże modele językowe. W ciągu zaledwie ośmiu minut napastnik uzyskał uprawnienia administracyjne, co znacząco skraca klasyczny łańcuch ataku w chmurze i pokazuje, iż fazy rekonesansu, eskalacji uprawnień oraz podejmowania decyzji operacyjnych mogą być dziś realizowane niemal w czasie rzeczywistym. Kluczowym wyróżnikiem tego incydentu była nie tylko prędkość działania, ale także wysoki poziom automatyzacji oraz liczne artefakty sugerujące aktywne użycie LLM do generowania kodu, analizy środowiska i wyboru kolejnych kroków ataku.

Początkowy dostęp został uzyskany poprzez kradzież poświadczeń IAM przechowywanych w publicznie dostępnym bucketcie S3, który zawierał dane wykorzystywane w procesach RAG dla modeli AI. Ujawnione klucze należały do użytkownika posiadającego uprawnienia do usług Lambda oraz Bedrock, co już na starcie zapewniło atakującemu szeroką widoczność środowiska i możliwości dalszej eskalacji. Następnie przeprowadzono szybki rekonesans, obejmujący enumerację kluczowych usług, takich jak Secrets Manager, SSM, Bedrock czy SageMaker, co pozwoliło na precyzyjne dopasowanie kolejnych działań do rzeczywistej konfiguracji konta.

Decydującym momentem ataku była eskalacja uprawnień zrealizowana poprzez wstrzyknięcie złośliwego kodu do funkcji Lambda o nazwie „EC2-init”. Kod ten, zawierający rozbudowaną obsługę wyjątków, timeout 30 sekund oraz komentarze w języku serbskim, automatycznie listował użytkowników IAM, generował nowe klucze dostępu dla konta administracyjnego „frick” oraz przeszukiwał kolejne buckety S3. Charakterystyka kodu, jego struktura oraz tempo przygotowania silnie sugerują, iż został on wygenerowany lub co najmniej wspomagany przez LLM, co znacząco obniżyło barierę techniczną eskalacji. Już w pierwszych minutach ataku napastnik uzyskał trwały dostęp administracyjny, co w praktyce zakończyło fazę initial compromise.

W dalszym etapie zaobserwowano intensywny ruch boczny pomiędzy kontami, realizowany poprzez wielokrotne wywołania mechanizmu AssumeRole, w tym roli OrganizationAccountAccessRole. Łącznie skompromitowano 19 principalów AWS, obejmujących zarówno użytkowników, jak i role, również w kontekstach cross-account. Co istotne, część prób wskazywała na typowe „halucynacje” modeli językowych, takie jak odwołania do nieistniejących identyfikatorów kont, co pośrednio potwierdza użycie automatycznego systemu decyzyjnego zamiast manualnego operatora. Równolegle atakujący stosował rotację adresów IP, utrudniając korelację zdarzeń i obniżając skuteczność klasycznych mechanizmów detekcji.

Szczególnie niepokojącym elementem incydentu było wykorzystanie usługi Bedrock do tzw. LLMjackingu. Napastnik wywoływał modele takie jak Claude 3.5 Sonnet czy Llama 4 Scout, jednocześnie weryfikując brak pełnego logowania oraz automatycznie akceptując umowy Marketplace. Działania te wskazują na motywację stricte ekonomiczną – nieautoryzowane użycie mocy obliczeniowej modeli językowych, zarówno w celu uniknięcia kosztów, jak i potencjalnej dalszej odsprzedaży dostępu. Zjawisko to wpisuje się w obserwowany od 2024 r. trend nadużyć usług AI w chmurze, gdzie dzienne koszty nielegalnego wykorzystania LLM mogą sięgać dziesiątek tysięcy dolarów.

Kulminacją ataku było uruchomienie instancji GPU typu p4d.24xlarge, której koszt przekracza 30 dolarów za godzinę. Na instancji zainstalowano CUDA oraz PyTorch, a analiza artefaktów sugeruje przygotowanie środowiska do trenowania modeli uczenia maszynowego z użyciem publicznie wystawionego Jupytera. Choć instancja działała jedynie kilka minut, sam fakt jej uruchomienia potwierdza, iż atakujący dążył do szybkiej monetyzacji przejętych zasobów, zanim incydent zostanie wykryty.

Analizowany incydent można interpretować jako kolejny etap ewolucji ekosystemu ataków na chmurę, który wcześniej był reprezentowany przez kampanie przypisywane do TeamTNT oraz Kinsing, a dziś coraz częściej przybiera formę półautonomicznych lub w pełni autonomicznych botów przejmujących konta AWS. W przypadku TeamTNT obserwowano centralnie zarządzaną infrastrukturę C2, masowe skanowanie Internetu pod kątem źle zabezpieczonych środowisk Docker, Kubernetes i ECS oraz szybkie wdrażanie minerów kryptowalut i backdoorów opartych na prostych skryptach powłoki. Kinsing, choć operacyjnie mniej scentralizowany, wprowadził istotny krok naprzód poprzez natywne wykorzystanie API dostawców chmurowych, automatyczne zakładanie zasobów compute oraz dynamiczne pobieranie modułów zależnych od wykrytego środowiska. Obie te kampanie łączyła jednak fundamentalna cecha: ich logika decyzyjna była statyczna, a zachowanie – w dużej mierze przewidywalne po zidentyfikowaniu wzorców skanowania i sekwencji wywołań API.

W analizowanym ataku widoczna jest jakościowa zmiana tego paradygmatu, polegająca na przeniesieniu części „inteligencji operacyjnej” z człowieka lub sztywnego skryptu do warstwy modelu językowego. LLM pełni tu rolę dynamicznego silnika decyzyjnego, który na bieżąco interpretuje wyniki rekonesansu, generuje kod dostosowany do aktualnych uprawnień IAM i wybiera kolejne wektory eskalacji, bez konieczności wcześniejszego zaprogramowania wszystkich możliwych scenariuszy. Podejście to tłumaczy zarówno niezwykle krótki czas przejścia od initial access do pełnych uprawnień administracyjnych, jak i obecność artefaktów typowych dla generatywnego kodu, takich jak rozbudowana obsługa wyjątków, nadmiarowe komentarze czy próby odwołań do nieistniejących zasobów. W tym sensie atak ten nie jest anomalią, ale logiczną kontynuacją trendu zapoczątkowanego przez wcześniejsze „AWS takeover bots”, które od lat krążą w podziemnych kanałach dystrybucji, publikowane w postaci frameworków na GitHub, sprzedawane w zamkniętych grupach na Telegram lub oferowane jako usługa na forach cyberprzestępczych.

Kluczowa różnica polega na tym, iż wcześniejsze narzędzia wymagały od operatora szczegółowej znajomości architektury AWS i manualnego dostosowywania parametrów ataku, podczas gdy obecna generacja botów może abstrahować tę wiedzę do poziomu wysokopoziomowych poleceń, delegując szczegóły implementacyjne do modelu językowego. W efekcie próg wejścia dla ataków na chmurę ulega dalszemu obniżeniu, a zdolności dotychczas zarezerwowane dla wyspecjalizowanych grup stają się dostępne dla szerokiego spektrum aktorów – od cyberprzestępców finansowych po podmioty działające na styku cyberprzestępczości i cyberwywiadu. Z perspektywy obronnej oznacza to, iż klasyczna atrybucja oparta na TTP przestaje być jednoznaczna: te same sekwencje API, role IAM i usługi chmurowe mogą być wykorzystywane zarówno przez kampanie przypisywane do TeamTNT czy Kinsing, jak i przez w pełni zdecentralizowane, autonomiczne boty, których „podpis” operacyjny jest generowany dynamicznie. W dłuższej perspektywie sugeruje to przejście od rozpoznawania znanych rodzin zagrożeń do detekcji anomalii behawioralnych i ekonomicznych, takich jak nienaturalnie szybka eskalacja uprawnień, masowe wywołania usług AI czy krótkotrwałe, kosztowne alokacje zasobów GPU, które stają się nowym, wspólnym mianownikiem nowej generacji ataków na chmurę.

Na naszych oczach widoczny jest wyraźny sygnał zmiany paradygmatu zagrożeń chmurowych. Automatyzacja wspierana przez LLM skraca czas od kompromitacji do pełnej kontroli środowiska do minut, a nie dni czy tygodni, jak miało to miejsce w klasycznych kampaniach cloud intrusion. W praktyce oznacza to, iż organizacje nie mogą już polegać wyłącznie na prewencji konfiguracyjnej, ale muszą inwestować w ciągły monitoring runtime, korelację zdarzeń oraz aktywne wykrywanie anomalii.

Więcej informacji:
https://www.sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes

Zaawansowane zagrożenia

Notepad++, czyli jak uzyskać dostęp do cennych stacji roboczych.

Ataki na łańcuch dostaw nie bez powodu mrożą krew w żyłach analitykom ryzyka i cyberbezpieczeństwa. Funkcjonowanie wielu korporacji i firm w erze cyfrowej opiera się na długiej liście systemu niezbędnego do realizacji podstawowych zadań. choćby o ile wprowadzono listę systemu akceptowanego w organizacji, ale aktualizacje są wdrażane automatycznie, każde zaufane narzędzie może stać się niebezpieczne przy pobraniu nowej wersji. W przypadku dobrze zewidencjonowanego rozwiązania obecnego na jednym lub dwóch dobrze znanych serwerach, problem jest zarządzalny. Ale co dzieje się w przypadku narzędzia, które jest niemalże wszędzie?

Taka sytuacja wyszła na jaw częściowo już w grudniu 2025 roku, ale pełnoprawne ogłoszenie incydentu wraz z szerszym opisem problemu pojawiło się na początku lutego tego roku. To właśnie wtedy Notepad++ w oficjalnym komunikacie poinformował o ataku na poziomie infrastruktury dostawcy hostingu. Umożliwił on atakującym przechwycenie i przekierowanie ruchu związanego z aktualizacjami kierowanego do oficjalnych zasobów N++. Atak był możliwy przez słabość mechanizmu aktualizacji, który nie wdrażał dostatecznej ochrony przed takim scenariuszem. Poprawka implementująca weryfikację podpisu i certyfikatu instalatora w czasie aktualizacji została wydana 9 grudnia 2025 roku. W komunikacie na temat incydentu zaznaczono, iż przy współpracy z zewnętrznymi ekspertami przeanalizowano incydent i oceniono, iż nieautoryzowany dostęp miał miejsce już w czerwcu i trwał z dużą dozą prawdopodobieństwa aż do 2 grudnia 2025 roku. Każda instalacja w tym zakresie czasowym była potencjalnie złośliwa.

Warto podkreślić sformułowanie potencjalnie. Według komunikatu ruch był przekierowywany wybiórczo tak, by jedynie wyselekcjonowani przez atakujących użytkownicy otrzymali złośliwą aktualizację. Wybierane były jedynie strategicznie istotne cele. Z pewnością nieprzypadkowo przejęto akurat łańcuch dostaw Notepad++, w końcu jest to narzędzie wykorzystywane przez developerów, administratorów i analityków. Jest to grupa osób potencjalnie posiadających wysokie uprawnienia i szerokie dostępy, co z perspektywy atakujących jest szczególnie cenne. W oparciu o analizę incydentu Rapid7 stwierdziło, iż odpowiedzialna była za to grupa Lotus Blossom, chiński aktor klasy APT. Wnioski te zostały wyciągnięte między innymi na podstawie użycia charakterystycznego loadera, który był wyraźnie podobny do tego opisywanego przez Symantec i wiązanego z Lotus Blossom. Zaobserwowano także użycie podobnego łańcucha wykonania oraz tego samego klucza publicznego pozyskanego z wykorzystanego beacona Cobalt Strike, co dodatkowo potwierdza to przypisanie. Analizując metody wykorzystywane w trakcie ataku i łańcuchy wykonania złośliwego oprogramowania, Kaspersky także wskazuje na chińskiego threat actora. Lotus Blossom to grupa aktywna od 2009 roku i realizująca przede wszystkim celowane kampanie szpiegowskie głównie w Azji Południowo-Wschodniej i Ameryce Środkowej. Sektory znajdujące się w grupie ich szczególnego zainteresowania to telekomunikacja, lotnictwo, infrastruktura krytyczna, media i instytucje rządowe. Jak pokazał także ten incydent, nie uderzają w przypadkowe cele.

Obraz uzyskanego przez atakującego dostępu, który wyłania się z analiz wskazuje na duży potencjał wykorzystania go do masowych infekcji. Mimo to, zainfekowany został jedynie mały zbiór celów, a dalsze obserwowane działania wskazywały na wykorzystanie personalizowanego malware oraz Cobalt Strike. Nietrudno sobie wyobrazić scenariusz, w którym taki dostęp jest wykorzystywany w pełni na szeroką skalę. Kradzież danych logowania i portfeli kryptowalutowych, stworzenie botnetu lub instalacja cryptominerów to tylko przykłady możliwych sposobów na monetyzację takich możliwości. Jednym z prawdopodobnych wyjaśnień ograniczenia tej aktywności do tak wąskiej grupy było zmniejszenie prawdopodobieństwa wykrycia i umożliwienie utrzymania długotrwałego dostępu bez zakłóceń. Wpisuje się to w metodykę gwarantującą szczególnie chińskim grupom APT tak dużą skuteczność działań cyberszpiegowskich.

Miesiące lub lata pozostawania w infrastrukturze w uśpieniu i długotrwałe aktywne działania atakujących klasy APT to wyzwanie w analizie na wielu poziomach. Jednym z nich może być zasięg czasowy przechowywanych logów. Należy zadać sobie pytanie, czy mamy szansę potwierdzić taką aktywność lub jej brak, o ile miała ona miejsce w czerwcu minionego roku. Uczciwa odpowiedź na to pytanie wraz z rzeczową oceną, czy nasza firma leży w kręgu zainteresowań konkretnych grup APT może pozwolić lepiej przygotować się na tego typu ataki zanim nastąpią. W przypadku Notepad++ zalecana jest niezwłoczna aktualizacja wszystkich instalacji Notepad++ do najnowszej wersji. Ponadto, by wykluczyć lub potwierdzić aktywność Lotus Blossom w infrastrukturze należy zweryfikować obecność indykatorów sieciowych w logach i plikowych na stacjach, gdzie mogły one pozostać po ataku.

Więcej informacji:
https://notepad-plus-plus.org/news/hijacked-incident-info-update/
https://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/
https://www.validin.com/blog/exploring_notepad_plus_plus_network_indicators/
https://securelist.com/notepad-supply-chain-attack/118708/
https://censys.com/blog/npp-infra

Cybercrime

Błąd w Ivanti EPMM i jego skutki dla bezpieczeństwa rządów w Europie.

Ivanti Endpoint Manager Mobile (EPMM), dawniej znany jako MobileIron Core, platforma klasy MDM/UEM (Mobile Device Management/Unified Endpoint Management). Z punktu widzenia architektury bezpieczeństwa, system ten stanowi punkt centralny dla wszystkich mobilnych urządzeń organizacji— zarządza konfiguracją, dystrybucją aplikacji oraz, co najważniejsze, poświadczeniami dostępu do zasobów wewnętrznych. Przejęcie serwera MDM daje cyberprzestępcom dużo możliwości, co sprawia, iż jest on celem o wysokim priorytecie. Uzyskanie dostępu do takiego systemu, pozwala nie tylko na kradzież danych z samego serwera, ale potencjalnie na infekcję tysięcy podłączonych do niego urządzeń (najczęściej telefonów komórkowych). Jednoczesne ujawnienie podatności CVE-2026-1281 oraz CVE-2026-1340, ich prawie natychmiastowe uwzględnienie w katalogu CISA KEV (Known Exploited Vulnerabilities Catalog) z zaleceniem 3-dniowej remediacji oraz potwierdzone włamania do systemów organów rządowych w Holandii i Finlandii obrazują sytuację, która wykracza poza ramy standardowego incydentu IT.

Operacyjne znaczenie podatności wynika z możliwości zdalnego wykonania dowolnego kodu w systemie bez uwierzytelnienia. Podatność wynika z faktu, iż Bash interpretuje zmienne w obliczeniach arytmetycznych jako wyrażenia, a nie zwykły tekst. Pozwala to atakującym podstawić pod parametr wejściowy nazwę innej zmiennej zawierającej ukryte polecenie systemowe, które zostanie automatycznie wykonane przez skrypt podczas przetwarzania. Aby oszukać filtry sprawdzające długość danych, cyberprzestępcy stosują dopełnienie ciągów znaków spacjami, co pozwala na skutecznie przeprowadzenie ataku. Uzyskany w ten sposób dostęp może zostać wykorzystany jako pierwszy krok do trwałego przejęcia systemu, na przykład przez instalację ukrytych mechanizmów utrzymania dostępu.

Analiza wykazała wykorzystanie mechanizmu utrzymania dostępu (persistence) opartego na technice Sleeper Shell, która polega na osadzeniu w systemie skryptu pozostającego w uśpieniu przez większość czasu. Aktywacja złośliwego komponentu następuje dopiero po spełnieniu określonego warunku, otrzymaniu specjalnego parametru wejściowego, co skutecznie utrudnia detekcję ze względu na brak stałej komunikacji z infrastrukturą atakującego. W badanym przypadku wykorzystano ścieżkę sieciową /mifs/403.jsp do ładowania złośliwego kodu (shellcode) bezpośrednio do pamięci procesu serwera, co pozwala na ominięcie skanerów EDR i AV poprzez unikanie pozostawiania śladów w systemie plików. Istotnym wskaźnikiem tej aktywności jest obecność nagłówka Java CAFEBABE, zakodowanego w formacie Base64 jako yv66vg. Sam implant base.info nie działa samodzielnie, ale oczekuje na specyficzny wyzwalacz dostarczający drugą część kodu, po czym przystępuje do zbierania informacji o hoście, takich jak katalog roboczy, system operacyjny czy nazwa użytkownika. Informacje te są przekazywane atakującemu jako argumenty, co pozwala dostosować dalsze działania do konkretnego celu.

Przegląd globalnej telemetrii dostarcza dowodów na to, iż eksploitacja przeprowadzana jest na masową skalę, a dynamika kampanii ewoluowała od fazy rozpoznania do infiltracji. Dane z systemów GreyNoise wskazują, iż dominującym źródłem ataków, odpowiadającym za 83% zaobserwowanych prób, jest pojedynczy adres IP osadzony w rosyjskiej infrastrukturze bulletproof hostingu (PROSPERO OOO, AS200593). Trustwave SpiderLabs udokumentowało wcześniej powiązania między PROSPERO a siecią Proton66 (AS198953), łącząc obie z usługami hostingowymi typu bulletproof sprzedawanymi na rosyjskojęzycznych forach poświęconych cyberprzestępczości pod marką BEARHOST. Sieć ta była powiązana z infrastrukturą dystrybucyjną wielu rodzin złośliwego oprogramowani, takich jak GootLoader czy SpyNote. Wskazuje to na wykorzystanie współdzielonej infrastruktury, co uniemożliwia przeprowadzenie atrybucji do jednego threat aktora, a potwierdza jedynie korzystanie z zasobów o udokumentowanej historii hostowania różnorodnych złośliwych operacji.

Istnieją podejrzenia, iż kampania wymierzona w Ivanti EPMM jest prowadzona przez brokerów dostępu (Initial Access Brokers – IAB) ze względu na dwuetapowy modelu działania atakujących, który skupia się na budowaniu bazy wielu dostępów zamiast na natychmiastowej kradzieży danych. Analiza GreyNoise wykazała, iż aż 85% zaobserwowanych ataków służy jedynie do weryfikacji podatności systemu dzięki mechanizmu OAST (DNS callback), co pozwala cyberprzestępcom potwierdzić, iż dany cel jest do przejęcia. Zamiast od razu podejmować dalsze działania, atakujący umieszczają opisywane wcześniej Sleeper Shells, które nie wykonują żadnych akcji i czekają na specjalny sygnał aktywujący. Taka strategia jest charakterystyczna dla brokerów, którzy przygotowują zweryfikowane dostępy do sieci organizacji, aby następnie odsprzedać je lub przekazać innym grupom przestępczym, które zajmą się np. eksfiltracją danych lub atakiem ransomware w późniejszym terminie. Co więcej, stosowane narzędzia są uniwersalne i zaprojektowane tak, by działały niezależnie od specyfiki konkretnego serwera, co sugeruje chęć masowego wykorzystania, a nie precyzyjny atak na jedną wybraną instytucję.

Z drugiej strony profilowanie ofiar na podstawie incydentów w holenderskim organie ochrony danych (AP), Radzie Sądownictwa (Rvdr), Komisji Europejskiej oraz fińskim Valtori (rządowe centrum usług ICT) dostarcza dowodów na precyzyjny charakter kampanii celowany w europejskie organy państwowe. Skalę zagrożenia dobrze obrazuje sytuacja w Valtori, gdzie system zarządzania urządzeniami dla 50 000 zamiast trwale kasować dane pracowników, jedynie oznaczał je jako usunięte. Oznacza to, iż skutki ataku obejmują nie tylko obecnych pracowników, ale potencjalnie całą historię cyklu życia usługi, eksponując dane kontaktowe i metadane urządzeń osób, które dawno opuściły struktury rządowe. Kradzież tych informacji stwarza bazę wiedzy o personelu kluczowych instytucji, co może stanowić fundament dla przyszłych operacji phishingowych i działań z zakresu inżynierii społecznej o wysokim stopniu personalizacji.

Dla zespołów bezpieczeństwa najważniejsze znaczenie ma zrozumienie, iż samo usunięcie podatności systemu jest niewystarczające. Katalogowanie celów podatnych na ataki zamiast natychmiastowego dostarczania złośliwego systemu oraz odkrycia dotyczące Sleeper Shell sugerują, iż początkowe wykorzystanie jest jedynie pierwszą fazą. jeżeli kampania ta przebiega zgodnie z modelem IAB, zainfekowane instancje EPMM mogą nie wykazywać oczywistych oznak nadużycia przez tygodnie lub miesiące. Pojawienie się nieoczywistej ścieżki /mifs/403.jsp w instancjach EPMM wskazuje na naruszenie bezpieczeństwa, choćby jeżeli nie są widoczne żadne dalsze złośliwe działania.

Operacyjnie, po wdrożeniu poprawek, absolutnie krytyczne jest wykonanie restartu wszystkich serwerów aplikacji— jest to jedyna metoda na wyczyszczenie pamięci operacyjnej z ewentualnych implantów Sleeper Shell, które będąc w pamięci nie przetrwają restartu procesu. Zignorowanie tego kroku oznacza utrzymanie uśpionego dostępu, który w każdej chwili może zostać aktywowany do przeprowadzenia destrukcyjnych ataków typu ransomware lub długofalowego szpiegostwa.

Więcej informacji:
https://labs.watchtowr.com/someone-knows-bash-far-too-well-and-we-love-it-ivanti-epmm-pre-auth-rces-cve-2026-1281-cve-2026-1340/
https://defusedcyber.com/ivanti-epmm-sleeper-shells-403jsp
https://www.greynoise.io/blog/active-ivanti-exploitation
https://www.levelblue.com/blogs/spiderlabs-blog/proton66-part-1-mass-scanning-and-exploit-campaigns