Remcos RAT. Anatomia trojana, który zamienia firmowego Excela w narzędzie szpiegowskie

Stary znajomy, nowe załączniki

8 października 2026 roku CERT Orange Polska poinformował o aktywnej kampanii phishingowej wymierzonej w polskie przedsiębiorstwa. Przestępcy wykorzystują wiadomości e-mail z załącznikami w formacie XLS, które mają prowadzić do infekcji Remcos RAT.

Dwa dni wcześniej podobne ostrzeżenie opublikował CERT Polska - tam również pojawia się motyw fałszywego zapytania ofertowego oraz arkusza Excel, który zamiast spodziewanych informacji handlowych dostarcza złośliwe oprogramowanie.

To nie przypadek, że przestępcy wykorzystują właśnie korespondencję biznesową. Zapytanie ofertowe, aktualizacja cennika, zamówienie czy zestawienie produktów należą do codziennego obiegu dokumentów. Dla pracownika działu zakupów plik XLS otrzymany od kontrahenta jest czymś równie zwyczajnym jak kolejna kawa przy biurku.

CERT Orange zwraca przy tym uwagę na szczególnie niewygodny szczegół: część wiadomości pochodzi z przejętych skrzynek pocztowych rzeczywistych przedsiębiorstw. Zdarzały się też przypadki korespondencji trafiającej do faktycznych kontrahentów nadawcy.

To zasadniczo zmienia sytuację. Atakujący nie musi podszywać się pod firmę przy użyciu podobnej domeny. Może wysłać wiadomość z prawdziwego konta przedsiębiorstwa, z którym odbiorca współpracuje od lat. Poprawny adres nadawcy, istniejąca historia kontaktów, a nawet pozytywne wyniki SPF, DKIM i DMARC nie gwarantują wtedy bezpieczeństwa załącznika.

Mechanizmy uwierzytelniania poczty potwierdzają określone właściwości pochodzenia wiadomości. Nie potwierdzają uczciwości osoby, która w danym momencie kontroluje skrzynkę. I w tym miejscu zaczyna się właściwy problem.

Remcos nie jest kolejnym programem, który wyświetla fałszywy komunikat i znika po zamknięciu okna. To rozbudowana platforma zdalnego zarządzania komputerem, wyposażona w funkcje rejestrowania aktywności użytkownika, pozyskiwania danych i wykonywania poleceń.

Remcos RAT - co to właściwie jest?

Remcos, czyli Remote Control and Surveillance, powstał jako komercyjne oprogramowanie do zdalnego administrowania i monitorowania komputerów z systemem Windows. Jego producentem jest Breaking Security. Sam produkt nie musi być złośliwy w każdym możliwym zastosowaniu. Istnieją legalne scenariusze zdalnego wsparcia technicznego, administracji czy testowania bezpieczeństwa.

Problem polega na tym, że funkcjonalności przydatne administratorowi są niemal idealnym zestawem narzędzi dla cyberprzestępcy, jeśli zostaną uruchomione bez wiedzy i zgody właściciela urządzenia. W klasyfikacji MITRE ATT&CK Remcos figuruje pod identyfikatorem S0332 jako narzędzie wykorzystywane również w kampaniach złośliwego oprogramowania.

Jego podstawowe możliwości obejmują:

• Zdalne wykonywanie poleceń systemowych i uruchamianie programów

• Zarządzanie plikami oraz przesyłanie danych pomiędzy komputerem ofiary a operatorem

• Rejestrowanie naciśnięć klawiszy, czyli keylogging

• Wykonywanie zrzutów ekranu, także w określonych odstępach czasu

• Przechwytywanie dźwięku z mikrofonu oraz obsługę kamery

• Odczytywanie i modyfikowanie zawartości schowka systemowego

• Pozyskiwanie informacji o systemie, procesach, aplikacjach i użytkowniku

• Manipulowanie rejestrem Windows oraz usługami systemowymi

• Uruchamianie dodatkowych modułów i aktualizowanie własnego kodu

• Utrzymywanie dostępu po ponownym uruchomieniu komputera

Nie wszystkie funkcje muszą być aktywne w każdej infekcji. Remcos jest konfigurowalny, a jego zachowanie zależy zarówno od ustawień przygotowanych przez operatora, jak i poleceń wydawanych podczas działania. To istotne rozróżnienie. Dwa komputery zainfekowane tą samą rodziną malware mogą pozostawiać zupełnie inne ślady.

Na jednym będzie działał keylogger i okresowe wykonywanie zrzutów ekranu. Na drugim Remcos może służyć przede wszystkim jako kanał zdalnego wykonywania poleceń i dostarczania kolejnych ładunków.

Od XLS do infekcji. Gdzie naprawdę zaczyna się atak?

Najpierw trzeba oddzielić dwa elementy: sposób dostarczenia złośliwego kodu oraz sam Remcos. Plik XLS zazwyczaj nie jest właściwym implantem Remcos. Jest nośnikiem pierwszego etapu ataku. Zadaniem tego etapu jest doprowadzenie do uruchomienia kodu, który następnie dostarczy, rozpakowuje lub załaduje właściwy program szpiegowski.

Typowy, uproszczony łańcuch może wyglądać następująco:

1. Dostarczenie wiadomości. Ofiara otrzymuje e-mail związany z jej obowiązkami, często podszywający się pod korespondencję handlową.

2. Otwarcie załącznika. Użytkownik uruchamia dokument, który może zawierać złośliwą zawartość lub wykorzystywać podatność aplikacji obsługującej plik.

3. Uruchomienie pierwszego etapu. Jeśli mechanizm infekcji zadziała, wykonywany jest kod odpowiedzialny za pobranie lub przygotowanie kolejnego ładunku.

4. Działanie loadera. Program ładujący może rozpakować, odszyfrować lub umieścić właściwy implant w pamięci procesu.

5. Inicjalizacja Remcos. Implant odczytuje konfigurację, uruchamia aktywne moduły i zależnie od ustawień, ustanawia mechanizmy trwałości.

6. Połączenie z C2. Zainfekowany komputer nawiązuje komunikację z infrastrukturą kontrolowaną przez operatora.

Nie należy jednak zakładać, że każda infekcja Remcos przebiega identycznie. W przypadku złośliwych dokumentów Office-a spotykano różne metody wykonania kodu: makra, wykorzystanie podatności, pobieranie dodatkowych skryptów oraz wieloetapowe loadery.

Co ważne, klasyczny XLS to format binarny wykorzystujący strukturę OLE Compound File. Nie należy utożsamiać go z nowoczesnym XLSX ani zakładać, że każdy niebezpieczny arkusz wykorzystuje makra VBA.

Październikowe ostrzeżenia CERT Orange i CERT Polska nie przedstawiają pełnej analizy konkretnego dokumentu ani nie wskazują jednoznacznie użytej podatności. Nie ma więc podstaw do twierdzenia, że obecna kampania wykorzystuje określone CVE.

Warto też pamiętać, że dokument może wywołać niepożądane działanie już podczas przetwarzania przez podatną aplikację. Samo niekliknięcie przycisku „Włącz zawartość” nie daje absolutnej ochrony przed wszystkimi klasami ataków.

Co pokazują wcześniejsze kampanie?

W 2024 roku CERT Orange analizował inną kampanię, w której wykorzystano DBat Loadera. W opisanym przypadku pierwszy etap pobierał skrypt BAT, a następnie uruchamiał kolejne komponenty, aż do załadowania końcowego implantu. Analiza wskazywała między innymi na DLL side-loading, modyfikacje konfiguracji Microsoft Defendera i wstrzyknięcie kodu do legalnego procesu Windows.

W lutym 2025 roku CERT Orange opisał z kolei kampanię podszywającą się pod BNP Paribas. Tym razem łańcuch obejmował archiwum 7z, skrypt VBS, PowerShell i próbę obejścia interfejsu AMSI, a następnie uruchomienie Remcos w pamięci.

To dwa różne sposoby dostarczenia tego samego rodzaju zagrożenia. Dlatego skuteczna detekcja nie może koncentrować się wyłącznie na rozszerzeniu pliku czy nazwie konkretnego loadera. Trzeba analizować zachowanie całego łańcucha infekcji.

Jak zbudowany jest Remcos?

Jedną z najbardziej szczegółowych publicznych analiz Remcos przeprowadzili badacze Elastic Security Labs. W 2024 roku rozebrali na części wersję 4.9.3 Pro, dokumentując jej inicjalizację, konfigurację, funkcje inwigilacyjne i protokół komunikacji. Z ich ustaleń wynika, że analizowany implant był natywną aplikacją Windows x86 napisaną w C++. To ważne, ponieważ Remcos nie jest jedynie prostym skryptem wykonującym kilka poleceń. Ma własną logikę inicjalizacji, strukturę konfiguracji, obsługę komunikacji sieciowej i liczne moduły wykonujące konkretne zadania.

W analizowanej wersji badacze odtworzyli 45 z 56 pól konfiguracyjnych oraz 74 z 78 poleceń obsługiwanych przez mechanizm C2. Taka liczba funkcji pokazuje skalę możliwości narzędzia.

Zaszyfrowana konfiguracja SETTINGS.

W analizowanych próbkach Remcos konfiguracja jest przechowywana w zasobach pliku PE, w obszarze oznaczonym nazwą SETTINGS. Znajdują się w niej informacje niezbędne do działania implantu, między innymi:

• Adresy serwerów Command and Control.

• Porty i ustawienia komunikacji.

• Interwały ponawiania połączeń.

• Nazwy oraz lokalizacje plików instalacyjnych.

• Ustawienia trwałości w systemie.

• Parametry keyloggera i wykonywania zrzutów ekranu.

• Opcje związane z wstrzykiwaniem kodu.

• Ustawienia mechanizmu watchdog.

• Dane dotyczące szyfrowania oraz identyfikacji instalacji.

W badanym wydaniu konfiguracja była zabezpieczana przy użyciu algorytmu RC4. Nie jest to nowoczesny, zalecany mechanizm kryptograficzny. W tym zastosowaniu pełni głównie funkcję ukrywania konfiguracji przed pobieżną analizą statyczną.

Dla analityka malware to istotna informacja. Odzyskanie konfiguracji może pozwolić ustalić serwery C2, parametry uruchamiania, charakter planowanej aktywności i powiązania pomiędzy próbkami. Sama obecność zasobu o nazwie SETTINGS nie jest jednak wystarczającym dowodem infekcji Remcos. Właściwa identyfikacja wymaga uwzględnienia struktury zasobów, cech binariów i zachowania programu.

Persistence, czyli dlaczego restart komputera nie wystarcza.

Po uruchomieniu, Remcos może zainstalować swoją kopię na dysku i zarejestrować mechanizm automatycznego startu. Jednym ze sposobów jest wykorzystanie kluczy Run w rejestrze Windows:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

W analizie Elastic Security Labs pojawia się również:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Jeśli mechanizm zostanie skutecznie skonfigurowany, kolejne logowanie lub ponowne uruchomienie systemu może spowodować ponowne wykonanie programu.

Przykładową lokalizacją instalacji opisaną w badaniach jest:

%ProgramData%\Remcos\remcos.exe

To nie jest uniwersalna ścieżka. Nazwy folderów i plików mogą wynikać z konfiguracji konkretnej próbki.

Remcos potrafi również nadawać plikom i katalogom atrybuty ukryte, systemowe i tylko do odczytu. Taki plik nie musi być widoczny w zwykłym widoku Eksploratora Windows, szczególnie przy domyślnych ustawieniach pokazywania chronionych plików systemowych.

Watchdog - dodatkowa warstwa utrzymywania dostępu.

Interesującym elementem architektury Remcos jest mechanizm watchdog. W uproszczeniu działa on jak drugi proces nadzorujący pierwszy. Jeśli główny komponent przestanie działać, watchdog może go ponownie uruchomić. W analizowanej wersji Remcos mechanizm wykorzystywał również wstrzykiwanie kodu do procesów Windows oraz informacje o identyfikatorach procesów przechowywane w rejestrze.

Dla administratora oznacza to, że samo zakończenie podejrzanego procesu w Menedżerze zadań może nie usunąć zagrożenia. Co gorsza, po ponownym uruchomieniu komponent może pojawić się w innym procesie, utrudniając analizę opartą wyłącznie na nazwach aplikacji. To jeden z powodów, dla których ręczne „zabijanie procesu” nie jest wystarczającą metodą obsługi incydentu.

Process injection. Złośliwy kod w legalnym procesie.

Remcos obsługuje również process injection czyli technikę polegającą na uruchamianiu kodu w przestrzeni adresowej innego procesu. W badanej przez Elastic wersji wykorzystano mechanizm oparty między innymi na mapowaniu pamięci współdzielonej, zmianie kontekstu wątku i wznowieniu jego wykonywania.

Celem nie jest koniecznie podmiana pliku wykonywalnego na dysku. Chodzi o to, aby kod implantu działał wewnątrz procesu, który z perspektywy systemu może wyglądać na zwykłą aplikację Windows. To zasadniczy problem dla zabezpieczeń opartych wyłącznie na reputacji nazwy pliku. Proces uruchomiony z legalnej lokalizacji nie musi wykonywać wyłącznie legalnego kodu.

Wśród procesów wykorzystywanych w badanych wariantach znajdowały się komponenty systemowe oraz aplikacje dostarczane wraz z Windowsem. Nie oznacza to oczywiście, że obecność svchost.exe lub iexplore.exe jest sygnałem infekcji. Takie procesy mogą być całkowicie prawidłowe. Znaczenie mają ich relacje z innymi procesami, sposób utworzenia, nietypowe operacje pamięciowe, aktywność sieciowa i pochodzenie uruchamianego kodu.

Keylogger - odczytywanie tego, czego użytkownik nie chciał nikomu pokazywać.

Jedną z podstawowych funkcji Remcos jest przechwytywanie naciśnięć klawiszy. W analizowanej wersji implementacja keyloggera wykorzystywała mechanizm Windows SetWindowsHookExA z parametrem WH_KEYBOARD_LL. Pozwala on na instalowanie niskopoziomowego mechanizmu obserwowania zdarzeń klawiatury.

Remcos może rejestrować wszystkie naciśnięcia albo ograniczać obserwację do sytuacji, w których aktywne jest okno pasujące do określonych warunków. Przykładowo operator może być zainteresowany momentem, w którym użytkownik pracuje w konkretnej aplikacji biznesowej, portalu bankowym lub formularzu uwierzytelniania.

Przechwycone dane mogą być buforowane i zapisywane do plików. W analizowanych konfiguracjach zaobserwowano także możliwość szyfrowania takich plików algorytmem RC4. Z perspektywy przedsiębiorstwa ryzyko wykracza więc poza przejęcie samej stacji roboczej.

Na zainfekowanym komputerze pracownik może korzystać z systemu ERP, bankowości elektronicznej, poczty, aplikacji finansowych, systemów produkcyjnych i paneli administracyjnych. Nawet jeśli przestępca nie otrzyma bezpośrednio dostępu do tych usług w chwili infekcji, może zbierać informacje pozwalające mu próbować przejęcia kolejnych kont.

Trzeba przy tym zachować techniczną precyzję: keylogger nie gwarantuje przejęcia każdego hasła, sesji ani mechanizmu MFA. Jego skuteczność zależy od sposobu uwierzytelniania, uprawnień procesu, konfiguracji systemu i dodatkowych zabezpieczeń. Nie zmienia to faktu, że jest to bardzo poważna metoda pozyskiwania informacji z urządzenia końcowego.

Zrzuty ekranu, mikrofon i kamera.

Keylogging to tylko część możliwości obserwacyjnych Remcos-a. W analizowanej wersji funkcja przechwytywania ekranu wykorzystywała między innymi interfejsy CreateCompatibleBitmap i BitBlt. Zrzuty mogły być wykonywane cyklicznie albo po spełnieniu określonych warunków związanych z aktywnym oknem.

Ich zawartość może być znacznie bardziej użyteczna dla napastnika niż same naciśnięcia klawiszy. Na ekranie mogą znajdować się dokumenty, wewnętrzna korespondencja, dane klientów, podgląd systemów biznesowych, kody jednorazowe, raporty finansowe czy fragmenty poufnych projektów.

Remcos obsługuje również nagrywanie dźwięku. W analizie Elastic opisano wykorzystanie interfejsów Windows z rodziny Wave* i zapisywanie nagrań w plikach WAV.

Osobne funkcje dotyczą obsługi kamery. Nie należy jednak wyobrażać sobie, że każda infekcja automatycznie uruchamia mikrofon, kamerę i wszystkie dostępne funkcje jednocześnie. Operator może aktywować tylko część możliwości, a ich działanie zależy od środowiska i uprawnień.

Z punktu widzenia użytkownika szczególnie niebezpieczne jest to, że obecność takiego implantu nie musi powodować żadnych widocznych objawów. Brak komunikatu o błędzie, niezmieniony pulpit i normalnie działający Excel nie są dowodem, że komputer pozostaje bezpieczny.

Command and Control. Jak komputer rozmawia z operatorem?

Po inicjalizacji Remcos podejmuje próby nawiązania połączenia z infrastrukturą Command and Control, czyli C2. Adresy serwerów oraz niektóre parametry transmisji są przechowywane w konfiguracji implantu. Zazwyczaj to zainfekowany komputer inicjuje połączenie wychodzące, co ma znaczenie z perspektywy firmowych firewalli. Nie jest wymagane wystawianie na Internet otwartego portu nasłuchującego na komputerze ofiary.

W analizowanych wydaniach Remcos komunikacja była realizowana przy użyciu własnego protokołu działającego na połączeniach TCP. Pakiety mają określoną strukturę, zawierającą między innymi identyfikator formatu wiadomości, długość danych, identyfikator polecenia i jego parametry. Elastic Security Labs dokumentuje charakterystyczny nagłówek protokołu:

24 04 FF 00

To przykład sygnatury, która może mieć wartość przy analizie ruchu w odpowiednich warunkach, ale sama w sobie nie jest uniwersalnym wskaźnikiem wszystkich współczesnych infekcji. Remcos może bowiem korzystać z TLS, przez co zawartość komunikacji zostaje zaszyfrowana na poziomie transportu.

W niektórych kampaniach wykorzystywane są również domeny dynamicznego DNS, pozwalające operatorowi zmieniać adres IP serwera bez konieczności zmiany nazwy domenowej. Co istotne, samo używanie dynamicznego DNS nie jest dowodem działalności przestępczej. Takie usługi mają wiele legalnych zastosowań.

Podejrzana staje się dopiero konkretna kombinacja okoliczności: nietypowy proces, niezaufany plik, nowo utworzony mechanizm autostartu i połączenia do infrastruktury niepowiązanej z działalnością organizacji.

Co operator może robić po połączeniu?

Wśród poleceń odtworzonych przez badaczy znalazły się funkcje pozwalające zarządzać plikami, wykonywać polecenia systemowe, monitorować procesy, obsługiwać keylogger, zrzuty ekranu, kamerę, dźwięk i schowek.

Istnieją także mechanizmy aktualizowania implantu i dostarczania kolejnych komponentów. Oznacza to, że zainstalowany Remcos może stanowić pierwszy etap poważniejszego incydentu. Cyberprzestępca może wykorzystać skompromitowaną stację do rozpoznania środowiska, pozyskania dodatkowych danych, kradzieży poświadczeń lub uruchomienia kolejnego oprogramowania.

Nie wynika z tego automatycznie, że każda infekcja skończy się ransomware'em albo przejęciem domeny Active Directory. Taka eskalacja wymaga dodatkowych działań i sprzyjających warunków. Ryzyko pozostaje jednak realne, ponieważ operator otrzymuje interaktywny punkt dostępu do środowiska użytkownika.

Jak wykrywać Remcos? Nie szukaj wyłącznie jego nazwy

Detekcja Remcos to problem wielowarstwowy - można szukać charakterystycznych plików, ustawień rejestru, mechanizmów iniekcji, podejrzanego ruchu sieciowego i efektów działania funkcji inwigilacyjnych. Największą wartość daje jednak korelacja tych sygnałów.

1. Nietypowy łańcuch procesów

Jednym z pierwszych sygnałów może być uruchomienie procesu nietypowego dla programu biurowego. Na przykład Excel uruchamiający interpreter poleceń, silnik skryptowy albo narzędzie służące do pobierania danych z Internetu. Sam taki przypadek nie przesądza jeszcze o infekcji. Istnieją legalne automatyzacje biurowe, dodatki i skrypty administracyjne.

Natomiast nieoczekiwane uruchomienie powershell.exe, cmd.exe, wscript.exe, mshta.exe czy rundll32.exe w bezpośrednim kontekście podejrzanego dokumentu powinno być sygnałem do dalszej analizy. Dla zespołu SOC szczególnie istotne jest odtworzenie pełnego drzewa procesów, a nie sprawdzanie wyłącznie procesu końcowego.

2. Modyfikacje autostartu

Należy monitorować tworzenie i modyfikowanie wpisów Run, szczególnie wtedy, gdy wskazują na świeżo utworzone pliki w lokalizacjach zapisywalnych przez użytkownika. Dotyczy to między innymi katalogów:

%APPDATA%

%LOCALAPPDATA%

%TEMP%

%ProgramData%

Plik EXE umieszczony w takim katalogu nie musi być złośliwy, ale jego nieznane pochodzenie, świeża data utworzenia i powiązanie z podejrzanym dokumentem zwiększają ryzyko.

3. Wstrzykiwanie kodu

Warto obserwować nietypowe operacje pamięciowe i tworzenie procesów w stanie zawieszenia, szczególnie jeśli następują po uruchomieniu nieznanego pliku z załącznika. Niektóre implanty mogą działać wewnątrz legalnych procesów Windows. W takich sytuacjach analiza samej nazwy procesu lub podpisu cyfrowego pliku na dysku może być niewystarczająca. Przydatne są rozwiązania EDR potrafiące korelować zdarzenia dotyczące procesów, pamięci, modułów i połączeń sieciowych.

4. Artefakty keyloggera i nagrywania

W analizowanych wersjach Remcos wykorzystywał charakterystyczne nazewnictwo plików przechowujących zrzuty ekranu, na przykład:

time_YYYYMMDD_HHMMSS.jpg

A także osobne mechanizmy zapisu danych keyloggera. Dla analityka takie artefakty mogą stanowić cenne wskazówki, zwłaszcza jeśli są regularnie tworzone przez proces niezwiązany z legalnym oprogramowaniem do rejestrowania ekranu. Nie są jednak wystarczające do jednoznacznej identyfikacji rodziny malware.

5. Komunikacja sieciowa

Zespół SOC powinien zwracać uwagę na nieoczekiwane połączenia wychodzące z nieznanych procesów, wykorzystanie nietypowych portów i infrastrukturę dynamicznego DNS. W przypadku niezaszyfrowanej komunikacji charakterystyczne elementy protokołu Remcos mogą być wykrywane przez odpowiednio skonfigurowane rozwiązania IDS/NDR.

Jeśli transmisja jest szyfrowana, analiza musi opierać się również na metadanych, reputacji infrastruktury, procesie źródłowym i kontekście wcześniejszych zdarzeń. Nie ma jednego magicznego portu TCP, którego zablokowanie unieszkodliwia całą rodzinę Remcos.

Praktyczny threat hunting w Windows i Microsoft Defender

W organizacji korzystającej z Microsoft Defender for Endpoint można rozpocząć od poszukiwania podejrzanych procesów uruchamianych bezpośrednio przez aplikacje biurowe.

Poniższe zapytanie KQL jest przykładem reguły typu hunting, a nie gotową sygnaturą Remcos:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (
    "EXCEL.EXE",
    "WINWORD.EXE",
    "OUTLOOK.EXE"
)
| where FileName in~ (
    "powershell.exe",
    "cmd.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe",
    "rundll32.exe",
    "regsvr32.exe"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    FileName,
    ProcessCommandLine,
    SHA256
| order by Timestamp desc

Zapytanie ma wykrywać niecodzienne zachowanie procesów Office, a nie identyfikować konkretną rodzinę malware.

Będzie generować fałszywe alarmy w środowiskach, w których funkcjonują legalne automatyzacje wykorzystujące interpretery poleceń lub skrypty.

Nie wykryje również wszystkich infekcji, na przykład takich, w których złośliwy kod uruchamia się bez typowego łańcucha procesów potomnych widocznego w tej telemetrii.

Drugim obszarem do przeszukania są wpisy autostartu:

DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has
    @"\Software\Microsoft\Windows\CurrentVersion\Run"
| project
    Timestamp,
    DeviceName,
    RegistryKey,
    RegistryValueName,
    RegistryValueData,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

To także reguła ogólna. W praktyce należy ją dostroić do środowiska, wykluczyć znane legalne instalatory oraz skorelować wynik z historią procesów i aktywnością sieciową urządzenia.

Co daje Sysmon?

Na stacjach z odpowiednio skonfigurowanym Sysmonem szczególnie użyteczne są:

Nie wszystkie zdarzenia są rejestrowane przy każdej konfiguracji Sysmona. Szczególnie Event ID 7 może generować bardzo dużą ilość danych, a Event ID 8 nie pokrywa wszystkich technik process injection.

Wykrywanie musi więc uwzględniać rzeczywistą politykę zbierania telemetrii.

Analiza próbki: co powinien zrobić analityk malware?

W przypadku znalezienia podejrzanego załącznika XLS lub pliku wykonywalnego powiązanego z infekcją podstawową zasadą jest niewykonywanie go na komputerze produkcyjnym. Próbkę należy zabezpieczyć wraz z oryginalną wiadomością i nagłówkami pocztowymi, zachowując jej integralność i obliczając sumę SHA-256.

Przy analizie dokumentów Office przydatne są narzędzia takie jak oletools, oledump.py czy odpowiednio skonfigurowane środowiska sandboxowe.

Dla końcowego pliku PE można wykorzystać między innymi:

• PEStudio lub PE-bear > do analizy struktury pliku i zasobów.

• Ghidra albo IDA > do analizy kodu wykonywalnego.

• FLOSS > do odzyskiwania części ukrywanych ciągów znaków.

• capa > do identyfikacji możliwości programu na podstawie kodu.

• YARA > do porównywania próbek z przygotowanymi regułami.

• EDR i narzędzia do analizy pamięci > do badania artefaktów działania implantu.

W przypadku Remcos szczególnie interesujący jest zasób SETTINGS, a także powiązania z konfiguracją autostartu, adresami C2 i strukturą poleceń. Trzeba jednak pamiętać o ograniczeniach analizy statycznej. Loader może przechowywać końcowy ładunek w postaci zaszyfrowanej, a wstrzyknięty implant nie musi istnieć na dysku w formie łatwej do znalezienia.

Dlatego analiza pamięci i telemetrii z okresu uruchomienia może być niezbędna do pełnego odtworzenia zdarzenia. Nie zalecam uruchamiania takich próbek nawet na zwykłym komputerze testowym podłączonym do sieci firmowej. Środowisko badawcze powinno być izolowane, kontrolowane i zaprojektowane tak, aby analiza nie naraziła innych systemów.

IOC to nie wszystko. MITRE ATT&CK i detekcja behawioralna.

Próbki Remcos mogą różnić się hashami, nazwami plików, konfiguracją i infrastrukturą operatorów. Wskaźniki kompromitacji, takie jak pojedynczy adres IP albo SHA-256, są potrzebne, ale ich przydatność bywa ograniczona do określonej kampanii.

Dlatego warto budować reguły wokół technik ATT&CK.

Nie wszystkie te techniki muszą pojawić się w każdej infekcji.

Przewagą detekcji behawioralnej jest jednak to, że może ujawnić złośliwe działanie również wtedy, gdy operator zmieni domenę C2, nazwę pliku albo zastosuje nowy loader.

Czym objawia się infekcja?

Najbardziej niewygodna odpowiedź brzmi: czasami niczym, co użytkownik byłby w stanie samodzielnie zauważyć. Nie należy oczekiwać charakterystycznego okna Remcos na ekranie, komunikatu o instalacji czy spektakularnego spowolnienia komputera. Możliwe symptomy obejmują nietypową aktywność sieciową, nieoczekiwane procesy, nowe wpisy autostartu, działanie nieznanych programów w profilu użytkownika oraz alerty EDR.

Czasem użytkownik zauważy nietypowe zachowanie kamery lub mikrofonu, zniknięcie plików cookie czy konieczność ponownego logowania do aplikacji. Każdy z tych objawów może mieć jednak zupełnie niewinne wyjaśnienie. Równie ważny jest brak objawów: poprawnie działający komputer nadal może być zainfekowany.

Jeżeli pracownik otworzył podejrzany dokument, a następnie pojawiły się alerty ochrony punktu końcowego, należy rozpatrywać całość jako potencjalny incydent, a nie problem z Excelem.

Co robić po podejrzeniu infekcji Remcos?

W środowisku firmowym właściwa reakcja powinna opierać się na procedurze incident response. Pierwszym krokiem jest ograniczenie możliwości dalszej komunikacji złośliwego oprogramowania, najlepiej poprzez izolację urządzenia z poziomu EDR albo kontrolowane odłączenie od sieci. Nie należy pochopnie usuwać wszystkich plików i czyścić systemu przed zebraniem potrzebnych artefaktów. Może to zniszczyć dane pozwalające ustalić zakres incydentu.

Zespół bezpieczeństwa powinien zabezpieczyć wiadomość źródłową, próbki załączników, drzewa procesów, zdarzenia rejestru, informacje o połączeniach sieciowych oraz - jeśli procedury i okoliczności na to pozwalają - materiał pamięciowy. Kolejny krok to ustalenie, czy zainfekowany użytkownik korzystał z kont uprzywilejowanych, aplikacji finansowych, poczty, systemów biznesowych albo dostępu VPN.

Zmiana haseł powinna odbywać się z zaufanego urządzenia. W razie potrzeby należy unieważnić aktywne sesje, tokeny i inne dane uwierzytelniające, które mogły być narażone na przejęcie. Przy potwierdzonej kompromitacji za pomocą RAT odtworzenie stacji z zaufanego obrazu systemu często daje większą pewność usunięcia zagrożenia niż próby ręcznego kasowania kolejnych komponentów.

Na końcu pozostaje ustalenie przyczyny infekcji i skali jej oddziaływania. Bez tego nawet skuteczne usunięcie Remcos z jednej stacji nie oznacza zakończenia incydentu.

Jak ograniczyć ryzyko w firmie?

W przypadku Remcos szczególnie istotne są zabezpieczenia kilku warstw. Na poziomie poczty warto stosować analizę załączników, sandboxing, kontrolę typów plików, ochronę przed przejęciem kont i procedury potwierdzania nietypowej korespondencji biznesowej. Na stacjach roboczych podstawą pozostają regularne aktualizacje Windows i aplikacji Office, ograniczenie uprawnień użytkowników, polityki blokowania niebezpiecznych zachowań oraz działający EDR.

Istotne są również reguły ograniczające uruchamianie nieautoryzowanych programów i skryptów, kontrola dostępu do Internetu z procesów użytkownika oraz monitorowanie zmian w mechanizmach autostartu. W środowiskach Microsoft można dodatkowo wykorzystać odpowiednio dobrane reguły Attack Surface Reduction i polityki kontroli aplikacji. Nie wszystkie organizacje będą mogły wprowadzić identyczne ograniczenia. W zakładzie produkcyjnym, biurze projektowym i przedsiębiorstwie wykorzystującym rozbudowane makra Excel istnieją różne zależności operacyjne.

Dlatego blokowanie powinno być oparte na inwentaryzacji legalnych zastosowań i pilotażowym wdrożeniu, a nie na przypadkowym włączaniu wszystkich dostępnych zabezpieczeń.

W szczególności należy pamiętać o jednym: poprawnie skonfigurowana bramka pocztowa nie zastępuje ochrony punktu końcowego, a EDR nie zastępuje bezpiecznego procesu obsługi korespondencji. Każda z tych warstw może zawieść. Sens architektury obronnej polega na tym, żeby awaria jednej nie oznaczała natychmiastowego przejęcia całego środowiska.

Niepozorny RAT, bardzo poważny problem.

Remcos nie potrzebuje zaawansowanego mechanizmu samodzielnego rozprzestrzeniania się po sieci ani własnego arsenału podatności zero-day, żeby być groźnym.

Jego skuteczność wynika z połączenia trzech elementów: sprawnego dostarczenia złośliwego kodu, szerokich możliwości zdalnego zarządzania oraz infrastruktury pozwalającej operatorowi utrzymywać kontakt ze skompromitowanym urządzeniem - wystarczy, że pierwszy etap infekcji zadziała. Od tej chwili atakujący może otrzymać dostęp do systemu, w którym użytkownik pracuje na co dzień - z jego dokumentami, aplikacjami, uprawnieniami i informacjami biznesowymi.

I tu znajduje się największa różnica między zwykłym szkodliwym załącznikiem a pełnoprawnym trojanem zdalnego dostępu. Załącznik jest tylko sposobem dostarczenia problemu. Remcos jest tym, co pozostaje później. Nie musi szyfrować dysku ani wyświetlać żądania okupu. Może przez pewien czas po prostu obserwować. Zbierać informacje. Rejestrować aktywność. Czekać na odpowiedni moment.

W przypadku przedsiębiorstwa taki dostęp może być szczególnie niebezpieczny, ponieważ wartość przechowywanych na komputerze danych często wykracza poza sam komputer. Korespondencja z dostawcami, dokumentacja techniczna, dane klientów, informacje finansowe i konta służbowe stają się potencjalnym źródłem dalszych ataków.

Dlatego październikowa kampania opisana przez CERT Orange i CERT Polska powinna interesować nie tylko osoby odpowiadające za pocztę elektroniczną. To temat dla administratorów Windows, inżynierów bezpieczeństwa, analityków SOC, zespołów incident response i osób odpowiedzialnych za ciągłość działania przedsiębiorstw.

Bo ostatecznie problemem nie jest sam plik XLS. Problemem jest to, że niepozorny arkusz może stać się początkiem zdalnej obecności przestępcy wewnątrz firmowego systemu. A najlepszy moment na wykrycie tej obecności jest zdecydowanie wcześniejszy niż chwila, w której ktoś zacznie przeglądać dokumenty, kopiować dane albo obserwować pracownika przez jego własny komputer.

Źródła i materiały techniczne

Źródła dotyczące kampanii w Polsce:

1. CERT Orange Polska - Remcos RAT w załączniku XLS. Na co uważać w firmowej poczcie? - Michał Rosiak, 8 października 2026 r.

2. CERT Polska - Prowadzisz firmę? Uważaj na fałszywe zapytania ofertowe! - 6 października 2026 r.

3. CERT Orange - Remcos RAT wraca. Analiza nowej kampanii - wcześniejsza analiza wykorzystania DBat Loadera.

4. CERT Orange - Ostrzeżenie dotyczące kampanii Remcos.RAT - analiza kampanii wykorzystującej skrypty i PowerShell.

Analiza architektury i reverse engineering:

5. Elastic Security Labs - Dissecting REMCOS RAT, Part One - inicjalizacja, konfiguracja, trwałość i process injection.

6. Elastic Security Labs - Part Two - watchdog, keylogging, nagrywanie i C2.

7. Elastic Security Labs - Part Three - struktura konfiguracji i polecenia C2.

8. Elastic Security Labs - Part Four - techniki detekcji oraz threat hunting.

9. MITRE ATT&CK - Remcos, S0332 - klasyfikacja narzędzia i udokumentowane techniki.

10. MalwareBazaar - Remcos - dane o próbkach i wskaźnikach, które należy weryfikować dla poszczególnych kampanii.

Opracowanie własne HACKIN9.PL na podstawie komunikatów CERT Orange Polska i CERT Polska oraz publicznie dostępnych analiz technicznych Elastic Security Labs i MITRE ATT&CK. Opisy architektury oraz artefaktów dotyczą udokumentowanych wersji Remcos i nie stanowią potwierdzenia wszystkich szczegółów październikowej kampanii z 2026 roku.