Wprowadzenie do problemu / definicja luki
W najnowszym wpisie SANS ISC zwrócono uwagę, że 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 kluczowe 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.exeto 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 na 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: właściwoś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)
- Wejście: phishing/malvertising → landing z instrukcjami „naprawy” (np. „skopiuj to polecenie i wklej do Run/PowerShell”).
- Pobranie:
finger.exełączy się doattacker[.]domain:79, pobiera „odpowiedź” zawierającą komendy/payload (np. Base64 PowerShell). SANS ISC zwraca uwagę, żefinger.exenie jest proxy-aware (łatwiej ominąć explicit proxy) i portu 79 nie da się zmienić. - 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śli organizacja bazuje na explicit proxy i blokuje „direct to Internet”, to brak proxy-awareness w
finger.exepowoduje 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/79outbound. - (Opcjonalnie) NLA: monitoruj jakiekolwiek połączenia do zewnętrznych IP:79 w NetFlow/Zeek.
Endpoint:
- AppLocker (EXE Rule):
- Deny dla
%WINDIR%\System32\finger.exei%WINDIR%\SysWOW64\finger.exew „Unrestricted → Deny unless needed”.
- Deny dla
- WDAC: umieść
finger.exew 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=792) 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 DeviceNameSplunk (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_portSuricata (prosty port-based; w praktyce lepiej TLS/JA3/treść, jeśli 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.exew ogóle „wyjdzie” na Internet w Twojej sieci (explicit vs transparent proxy). - Wygeneruj kontrolowany ruch do hosta testowego na TCP/79 i upewnij się, że alertują: EDR (proc creation), NDR/IDS (port 79), SIEM (korelacja).
- Przejrzyj atakowy playbook ClickFix z bloga Microsoft — od symulacji malvertising po ręczne 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/certutilczy „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
bitsadminlubcurl,finger.exejest rzadko używany w środowiskach korporacyjnych, więc jego anomalia jest bardziej oczywista, ale jednocześnie bywa nieprzefiltrowany w egress. - Jako LOLBIN
finger.exepozostaje 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 / kluczowe wnioski
- ClickFix nadal 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)