Finger.exe & ClickFix: jak stary protokół Finger (TCP/79) wraca w nowoczesnych atakach

Wprowadzenie do problemu / definicja luki

W najnowszym wpisie SANS ISC zwrócono uwagę, iż w kampaniach ClickFix napastnicy znów nadużywają starego, zapomnianego protokołu Finger oraz wbudowanego w Windows klienta finger.exe do pobierania skryptów i komend z Internetu. Finger działa po TCP/79, a klient systemowy nie obsługuje proxy, co bywa najważniejsze dla obejścia polityk egress w firmach polegających na explicit proxy. Rezultat: polecenia kopiowane ręką użytkownika (esencja ClickFix) mogą ściągać i uruchamiać payloady z pominięciem części kontroli sieciowych.

W skrócie

• ClickFix = socjotechnika „zrób to sam”: strona-lurka prowadzi ofiarę do ręcznego uruchomienia polecenia (np. w cmd/PowerShell), które pobiera i uruchamia złośliwy kod. Microsoft opisał wzorzec ataku i jego obejścia zabezpieczeń.
• W najnowszej odsłonie atakujący używają finger.exe (Windows) do pobrania skryptu przez Finger/TCP 79 – często z serwerów kontrolowanych przez napastnika lub z serwisów skompromitowanych. Temat nagłośnił również BleepingComputer.
• Finger to stary protokół zdefiniowany w RFC 1288; port nie jest konfigurowalny (zawsze 79/TCP).
• finger.exe to LOLBIN: narzędzie wbudowane, znane społeczności obronnej i opisane w projekcie LOLBAS – dostępne ścieżki, przypadki nadużyć i reguły Sigma.
• Dla SOC: patrz sekcja „Rekomendacje” – gotowe KQL/Sigma/Splunk, przykładowe reguły Suricata (TCP/79), blokady AppLocker/WDAC, kontrola egress oraz TTPs do huntów.

Kontekst / historia / powiązania

Technika ClickFix była szeroko opisywana w 2024–2025 jako sposób „ominięcia” części automatów antymalware poprzez włączenie człowieka do łańcucha ataku: ofiara sama kopiuje komendę, która robi „resztę”. To redukuje sygnał detekcyjny (mniej klasycznego „drop & exec”). Microsoft szczegółowo rozebrał ten łańcuch, wskazując m.in. malvertising, fałszywe strony „naprawy błędu” i presję czasu w ofierze. W 2025 r. media branżowe odnotowały odświeżoną falę ataków, m.in. z użyciem Finger.

Analiza techniczna / szczegóły luki

Finger: adekwatności protokołu

• Transport: TCP
• Port: stały 79/tcp (klient łączy się na 79)
• Model zapytań: jedna linia zapytania → odpowiedź serwera (RUIP)
• Brak TLS/uwierzytelniania, mechanizm archaiczny, projektowany do informacji o użytkownikach/hostach.
  Te cechy pochodzą z definicji protokołu w RFC 1288.

finger.exe w Windows jako LOLBIN

• Lokalizacje: C:\Windows\System32\finger.exe, C:\Windows\SysWOW64\finger.exe.
• Kluczowa obserwacja obrońców: nie powinien wykonywać się na typowych stacjach końcowych; jego aktywność sieciowa do Internetu to anomalia.
• W projekcie LOLBAS znajdziesz reguły Sigma i znane nadużycia (np. pobieranie treści jako „komunikatu” finger i pipowanie do interpretera).

Łańcuch ClickFix z użyciem Finger (przykład)

1. Wejście: phishing/malvertising → landing z instrukcjami „naprawy” (np. „skopiuj to polecenie i wklej do Run/PowerShell”).
2. Pobranie: finger.exe łączy się do attacker[.]domain:79, pobiera „odpowiedź” zawierającą komendy/payload (np. Base64 PowerShell). SANS ISC zwraca uwagę, iż finger.exe nie jest proxy-aware (łatwiej ominąć explicit proxy) i portu 79 nie da się zmienić.
3. Wykonanie: odpowiedź Finger bywa przekierowana do shella/interpretera (np. | powershell -), co finalnie uruchamia loader/infostealer. O samej fali nadużyć Finger w kampaniach ClickFix informował BleepingComputer.

Uwaga: Finger widziano też jako kanał eksfiltracji/transferu (LOLBIN living-off-the-land) — warto to uwzględnić w hypothesach podczas huntów. (Dobry przegląd ryzyka dają materiały analityczne i praktyka DFIR).

Praktyczne konsekwencje / ryzyko

• Omijanie egress przez proxy: jeżeli organizacja bazuje na explicit proxy i blokuje „direct to Internet”, to brak proxy-awareness w finger.exe powoduje po prostu brak wyjścia — to akurat dobra wiadomość. Jednak w sieciach z transparent proxy lub źle egzekwowanym egress (np. brak deny-all + allow-list) ruch TCP/79 może przejść.
• Niska widoczność: wiele IDS/NGFW nie obserwuje dziś intensywnie portu 79, bo usługa jest historyczna; to czyni z Finger atrakcyjny kanał niszowy.
• Living-off-the-land: użycie narzędzia wbudowanego (finger.exe) utrudnia polityki „block-by-default” oparte wyłącznie na hashach/znanych loaderach; trzeba sięgnąć po AppLocker/WDAC, EDR i kontrole kontekstowe.

Rekomendacje operacyjne / co zrobić teraz

1) Szybkie twardnienie (hardening)

Sieć (egress):

• Jeśli polityka organizacji nie wymaga Finger – zablokuj TCP/79 na brzegu i w segmentach użytkowników (deny-all → allow-list).
• W transparent proxy/NGFW dodaj reguły blokujące tcp/79 outbound.
• (Opcjonalnie) NLA: monitoruj jakiekolwiek połączenia do zewnętrznych IP:79 w NetFlow/Zeek.

Endpoint:

• AppLocker (EXE Rule):
  • Deny dla %WINDIR%\System32\finger.exe i %WINDIR%\SysWOW64\finger.exe w „Unrestricted → Deny unless needed”.
• WDAC: umieść finger.exe w polityce „Deny-List” (FileNameRule albo podpis/hashe).
• SRP: „Disallowed” dla ścieżek finger w regułach Additional Rules.

Windows Firewall (host-based) – przykład (cmd jako admin):

netsh advfirewall firewall add rule name="Block Outbound TCP 79 (Finger)" dir=out action=block protocol=TCP localport=any remoteport=79

2) Detekcja — gotowe reguły i zapytania

Sigma (proc creation – finger.exe):

title: Suspicious Use of finger.exe id: 3d2f2f5a-isc-clickfix-finger status: experimental logsource: product: windows category: process_creation detection: sel: Image|endswith: - '\finger.exe' condition: sel fields: - Image - CommandLine - ParentImage - User - ComputerName level: high tags: - attack.command_and_control - attack.t1105

(W projekcie LOLBAS znajdziesz też oficjalną regułę Sigma dla finger.exe — zaadaptuj do swojej telemetrii.)

Defender for Endpoint / KQL (wykrycie użycia + ruchu na 79/tcp):

// Procesy finger.exe DeviceProcessEvents | where Timestamp > ago(14d) | where FileName =~ "finger.exe" | project Timestamp, DeviceName, InitiatingProcessAccountName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessParentFileName // Połączenia sieciowe inicjowane przez finger.exe do publicznych IP (port 79) DeviceNetworkEvents | where Timestamp > ago(14d) | where InitiatingProcessFileName =~ "finger.exe" | where RemotePort == 79 and RemoteIPType == "Public" | summarize dcount(RemoteIP) by DeviceName

Splunk (Sysmon EventID=1 + net connection EventID=3):

index=win* (EventCode=1 OR EventCode=3) | eval is_finger=if(like(Image,"%\\finger.exe"),1,0) | search is_finger=1 OR (EventCode=3 dest_port=79 process_name="finger.exe") | table _time host user Image CommandLine parent_process_name dest_ip dest_port

Suricata (prosty port-based; w praktyce lepiej TLS/JA3/treść, jeżeli możliwe):

alert tcp $HOME_NET any -> $EXTERNAL_NET 79 (msg:"Egress Finger protocol (TCP/79)"; flow:to_server,established; classtype:policy-violation; sid:790001; rev:1;)

Zeek (conn.log szybki hunt):

# filter: outbound connections to port 79 cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service | awk '$3==79 && $4=="tcp"'

3) Reagowanie (IR)

• Izoluj host i zbierz artefakty procesu rodzica finger.exe (kto zainicjował? cmd.exe, powershell.exe, przeglądarka?) oraz stronę/lurkę (artefakty przeglądarki, DNS Cache, Prefetch).
• Artefakty łańcucha ClickFix: zrzuty schowka, historia RunMRU, TypedPaths, PowerShell Operational (Event ID 4104/4103), Shell-Core (ShellExecute).
• Blokuj i burnuj: domeny/IP na 79/tcp, usuń reguły wyjątków w proksy/NGFW, zaktualizuj listy blokad w EDR.
• User awareness: szybki komunikat do użytkowników o NIEKOPIOWANIU poleceń z pop-upów/stron „naprawczych”.

4) Testy kontrolne (Purple Team)

• W bezpiecznym labie sprawdź, czy finger.exe w ogóle „wyjdzie” na Internet w Twojej sieci (explicit vs transparent proxy).
• Wygeneruj kontrolowany ruch do hosta testowego na TCP/79 i upewnij się, iż alertują: EDR (proc creation), NDR/IDS (port 79), SIEM (korelacja).
• Przejrzyj atakowy playbook ClickFix z bloga Microsoft — od symulacji malvertising po manualne wykonanie komendy — i dopasuj własne kontrolki.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Wcześniej ClickFix częściej polegał na powershell/bitsadmin/certutil czy „curl w PowerShell” — dziś widzimy „egzotyczne” kanały jak Finger. To obniża skuteczność sygnatur i allowlist tworzonych „pod modne TTP”.
• W przeciwieństwie do bitsadmin lub curl, finger.exe jest rzadko używany w środowiskach korporacyjnych, więc jego anomalia jest bardziej oczywista, ale jednocześnie bywa nieprzefiltrowany w egress.
• Jako LOLBIN finger.exe pozostaje w tym samym koszyku co inne narzędzia „żyjące na systemie”, ale ma sztywny port 79 i brak proxy-awareness, co daje zarówno wektor obejścia, jak i łatwy wskaźnik do blokady.

Podsumowanie / najważniejsze wnioski

• ClickFix przez cały czas rośnie — powrót do Finger/TCP 79 to sprytne wykorzystanie niszy. Zablokuj 79/tcp, zabroń finger.exe, dołóż telemetrię i hunting na anomalie LOLBIN.
• Wprowadź kontrolki procesowe (AppLocker/WDAC), korelację proces→sieć, oraz edukację użytkowników przeciwko „kopiuj–wklej”.
• Od dziś: deny 79/tcp, alert na finger.exe, review egress i proxy, zapytania w SIEM — gotowce masz wyżej.

Źródła / bibliografia

• SANS ISC Diary — Finger.exe & ClickFix (port 79, brak proxy-awareness, użycie w ClickFix). (SANS Internet Storm Center)
• Microsoft Security Blog — ClickFix: łańcuch ataku, socjotechnika i obejście zabezpieczeń. (Microsoft)
• BleepingComputer — nadużycie Finger w kampaniach ClickFix (2025-11). (BleepingComputer)
• RFC 1288 — specyfikacja protokołu Finger (TCP/79). (IETF Datatracker)
• LOLBAS — strona Finger.exe (LOLBIN, lokalizacje, detekcje). (lolbas-project.github.io)