NoVVy Opublikowano 25 Października 2010 Zgłoś Udostępnij Opublikowano 25 Października 2010 Witam. Chciałem się upewnić czy mam infekcję rootkitem. Zrobiłem skan GMER'em w trybie awaryjnym i wykryło mi coś i sam nie wiem czy to rootkit. Zupełnie zapomniałem o tym, że nie wolno samemu bez wyraźnego sygnału stosować Combofix'a... Załączam więc loga także z Combofix'a (nie sprzątałem po nim - katalog Qoobox jest nadal - nie ruszany). Załączam również wymagany raport z OTL (z zaznaczoną opcją "Use No-Company-Name WhiteList" - wersja nowsza OTL od tej w tutorialu posiada tą opcję i nie wiedziałem czy mam ją odznaczyć). Miałem już wcześniej jakieś stare pozostałości "malicious code" po wcześniejszej infekcji /index.php?showtopic=136884&view=findpost&p=593222"]S-E ale teraz wygląda to na coś innego (moim zdaniem). Specjalnie nie robiłem "fixa" w MBR (który wykrywa infekcję). GMER OTL Extras Combofix MBR Odnośnik do komentarza
Landuss Opublikowano 25 Października 2010 Zgłoś Udostępnij Opublikowano 25 Października 2010 Rzeczywiście jest infekcja bo w narzędziu mbr.exe jest linia: MBR rootkit infection detected ! Use: "mbr.exe -f" to fix. A więc użyj tego narzędzia z parametrem -f tak jak pisze program. W dalszym etapie wykonaj do OTL taki skrypt: :Files RECYCLER /alldrives :Commands [resethosts] [emptyflash] [emptytemp] Kliknij w Wykonaj skrypt. Zatwierdź restart komputera. Następnie uruchamiasz OTL ponownie, tym razem wywołujesz opcję Skanuj. Pokazujesz nowe logi z OTL oraz z Gmer i mbr.exe Odnośnik do komentarza
NoVVy Opublikowano 25 Października 2010 Autor Zgłoś Udostępnij Opublikowano 25 Października 2010 Uruchomiłem MBR z parametrem "-f" i wyskoczył komunikat, że operacja zakończyła się pomyślnie. Uruchomiłem jeszcze raz MBR żeby sprawdzić czy znowu wykryje rootkita no i niestety wykrył. Po restarcie system nie wstał. W ogóle tak jakby nie było dysku, na którym jest system. Piszę właśnie z linux'a (live cd bo innego systemu na dyskach nie mam). Prawdę mowiąc to nie wiem teraz co mam robić. Odpaliłem instalator z plyty z XP i myślałem, że uda sie to jakoś naprawić ale komenda "fixboot" nic nie daje bo nie widać partycji z systemem (w ogóle nie widać żadnej partycji z tego dysku, na którym był system). Chciałem też użyc opcji "fixmbr" ale wyskoczył komunikat, ze moze to uszkodzić tablice partycji wiec zrezygnowałem. Czy przez użycie parametru "-f" w MBR mogło właśnie dojść do takiego uszkodzenia tablic partycji? Czy da się to jakoś naprawić? Sam nie wiem dlaczego teraz się tak stało bo używałem kiedyś MBR i wszystko było w porządku. Mam sporo rzeczy na tym dysku, ktorych nie chciałbym stracić. Dodam jeszcze, że pod linuxem także nie widać partycji dysku, na którym jest system. ----update--- W instalatorze od XP widać dysk, na którym był system ale bez partycji. Odnośnik do komentarza
Landuss Opublikowano 25 Października 2010 Zgłoś Udostępnij Opublikowano 25 Października 2010 Nie mam pojęcia dlaczego tak się stało, nie powinno. Chciałem też użyc opcji "fixmbr" ale wyskoczył komunikat, ze moze to uszkodzić tablice partycji wiec zrezygnowałem. Mimo wszystko użyj FIXMBR. Odnośnik do komentarza
NoVVy Opublikowano 25 Października 2010 Autor Zgłoś Udostępnij Opublikowano 25 Października 2010 Przed chwilą właśnie użyłem polecenia FIXMBR ale niestety nic się nie zmieniło. Instalator XP pokazuje, że dysk jest niepodzielony czyli chyba jednak doszło do uszkodzenia tablic partycji. Jeżeli jest jeszcze jakaś szansa na odratowanie partycji (i zawartości) to bardzo bym prosił o pomoc. Odnośnik do komentarza
Landuss Opublikowano 25 Października 2010 Zgłoś Udostępnij Opublikowano 25 Października 2010 Wypróbuj narzędzie TestDisk. Tutaj masz też pomocny poradnik po polsku: KLIK Odnośnik do komentarza
NoVVy Opublikowano 26 Października 2010 Autor Zgłoś Udostępnij Opublikowano 26 Października 2010 Udało się przywrócić partycje na tym dysku. Jestem już na Xp'ku i wykonałem skrypt w OTL oraz skanowanie OTL, Gmer i MBR. Oto logi: Gmer Log po użyciu skryptu w OTL OTL Extras MBR Zamieszczam jeszcze wczorajszego loga z MBR po użyciu parametru "-f" - MBR Odnośnik do komentarza
Landuss Opublikowano 26 Października 2010 Zgłoś Udostępnij Opublikowano 26 Października 2010 Gmer i mbr nadal nie są czyste choć sam nie wiem już co o tym myśleć. A zobacz jeszcze co powie Kaspersky TDSSKiller Odnośnik do komentarza
NoVVy Opublikowano 26 Października 2010 Autor Zgłoś Udostępnij Opublikowano 26 Października 2010 Log z TDSSKiller --> klik. Nie wykrył nic. ----- UPDATE ----- Problem z wykrywaniem rootkita w MBR zniknął (a użyłem tylko parametru "-t"czyli zgodnie z instrukcją "trace called modules "). Przed użyciem MBR jeszcze wykrywał a zaraz po użyciu przestał. Gmer wykrywa nadal rootkita (a właściwie rootkit-like). Skopiowałem zawartość każdego sektora, w którym Gmer wykrył to coś rootkit-like i wrzuciłem na stronkę Virus Total. Jedynie w 61 sektorze jest coś wykrywane. Na stronie bitdefender.com jest opisane działanie tego rootkita. This is a small malware that is located in the Master Boot Record (MBR) of the disk. When de PC is starting up, the infected MBR is loaded into memory and executed. The virus first reserves memory for its body by substracting 2 from the total amount of conventional memory installed (in order to hide its traces and prevent the OS from overwriting it). Then, it will move its first 256 bytes in the memory hole created, read two more sectors from the disk (61 & 62 which contain malware code as well), and it will hook the 13h interrupt vector (BIOS disk service), functions 2 and 42h (responsabile for reading sectors into memory). It will then load the original MBR code, located on cylindre 0, sector 63 (last physical sector from that head) at the address 0:7C00h and execute it. Since the read services of the interrupt 13h are hooked by the virus, each time the original MBR or the BOOT sector will perform read operations from the disk, the virus will be activated. (However, after the operating system is up and running, disk I/O are made using drivers, not the interrupt 13h, thus, the virus will not intercept disk-reads anymore).During the BOOT sequence, the virus will execute its own kernel loader (located on sectors 61 & 62), which will patch the windows kernel into memory, in order to load a specific rootkit-driver and prepare the execution of other malware components already present in the system. Wydaje mi się, że w tym 61 sektorze znajdują się pozostałości po rootkicie. Nie wiem tylko dlaczego Gmer nadal pokazuje (jest podświetlone na czerwono), że coś siedzi w MBR (sektor 00) a sam program MBR pokazuje, że już jest czysto. Logi: użycie parametru -t w MBR MBR po użyciu parametru -t Gmer Link do wyników ze skanowania 61 sektora na Virus Total - klik. ------ UPDATE ------ Nie wspomniałem wcześniej, że od pewnego czasu w logach Sunbelt Personal Firewall (czyli wcześniejsze Kerio) pojawiają się informacje typu "ICMP superscan echo" oraz "PortScan" (raz nawet był atak typu DOS). Nie byłoby w tym nic dziwnego gdyby nie to, że dochodzi do tego dwa czy trzy razy w ciągu dnia (lub nocy) a wcześniej tak nie było. Adresy źródeł ataku pochodzą z Korei, Chin, Rosji, Kanady. Strony z warezem, xxx czy też gry z witaminami omijam szerokim łukiem. Podejrzewam, że mogłem coś złapać poprzez kliknięcie w link prowadzący do strony z niebezpiecznym kodem (mam trochę znajomych w biurach, którzy w międzyczasie wysyłają mnóstwo linków do śmiesznych rzeczy typu filmiki, animacje flash czy też mailem wysyłają pps). Aktualizuję wszystko ręcznie (nie lubię jak coś się ma samo w tle robić a tak mam pewność) i często. Używam Sandboxie i Firefox'a (z pluginami Adblock Plus, NoScript, DownloadHelper, WOT i ostatnio zainstalowałem jeszcze CsFire z tym, że ten ostatni wyłączam na czas pobytu na youtube bo inaczej wyświetla się "an error occurred, please try again later." a nie wiem jak ustawić we wtyczce żeby "tolerował" zawartość strony). No ale wracając do tego skanowania to może to coś co złapał mój komputer powiadomiło o uruchomieniu serwera i teraz ktoś chciałby to wykorzystać. Pytanie tylko po co tyle zachodu skoro to jest zwykły komp używany głównie do słuchania muzyki z wav'ów zrzuconych z oryginalnych płyt (dla wygody), czasem pogrania w CS:S, Q3 czy Diablo 1 i 2, uruchamianie emulatora Atari 65 XE () i oglądania filmów na dvd lub youtube. W każdym razie od razu w tym temacie pytam czy wystarczy mi taka ochrona przed tym internetowym agresorem i czy może być jakiś związek z tym co wykrywa Gmer w 00 sektorze. Zamieszczam log z Sunbelt Personal Firewall (powtarzający się w krótkich odstępach czasu komunikat "ICMP Destination Unreachable Port Unreachable" to efekt działania Steam) ----> klik. Ustawienia firewalla są takie: 1, 2, 3 ----- UPDATE ------- Log z Rootkit Unhooker ---> klik W sekcji Stealth jest coś takiego: Unknown page with executable code Address: 0xFE154F53 Size: 173 Unknown page with executable code Address: 0xFE1E507B Size: 3973 Unknown page with executable code Address: 0xFE1E3E44 Size: 444 Unknown page with executable code Address: 0xFE1EBD66 Size: 666 Porobiłem zrzuty i przeskanowałem na Virus Total. W dwóch z nich wykryło coś ale tylko przy McAfee-GW-Edition. Ten o wielkości 666 jest wykrywany jako Heuristic.BehavesLike.Exploit.CodeExec.EOOJ a ten o wielkości 3973 wykrywa jako Heuristic.BehavesLike.Exploit.CodeExec.FFOO Odnośnik do komentarza
Landuss Opublikowano 31 Października 2010 Zgłoś Udostępnij Opublikowano 31 Października 2010 Zostawiłbym to i nic już tutaj nie ruszał. Często tak jest, że Gmer wykazuje szczątki po rootkicie, który kiedyś mógł być. Z tym już nic się nie robi bo to też nie jest w żaden sposób szkodliwe. Gdyby naprawde był rootkit Kaspersky TDSSKiller by to wykazał, zaś Gmer miałby taką linie: Disk \Device\Harddisk0\DR0 sector 00 (MBR): rootkit-like behavior; TDL4 <-- ROOTKIT !!! Generalnie jeżeli nie masz problemów z systemem to nie ma się czego obawiać. Odnośnik do komentarza
picasso Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Landuss Często tak jest, że Gmer wykazuje szczątki po rootkicie, który kiedyś mógł być. (...) Gdyby naprawde był rootkit Kaspersky TDSSKiller by to wykazał, zaś Gmer miałby taką linie: Ale TDL4 to tylko jeden z przykładów bootkitów, nie każdy rootkit MBR w GMER będzie tak opisany i nie każdy będzie wykryty w Kasperskym specjalizowanym pod jedną infekcję a nie wszystkie możliwości .... U niego GMER nie zgłasza tego jako "szczątki" (za takowe już po leczeniu infekcji uważa się odczyty z sektorów innych niż zero), wykrywa aktywność rootkit (może w raporcie nie przeskrolowałeś okna do prawej do napisu "ROOTKIT !!!"): Disk \Device\Harddisk0\DR0 sector 00 (MBR): rootkit-like behavior; [b]NoVVy[/b] Nie wiem tylko dlaczego Gmer nadal pokazuje (jest podświetlone na czerwono), że coś siedzi w MBR (sektor 00) a sam program MBR pokazuje, że już jest czysto. Dla porównania pokaż jeszcze log z [color=#0000FF][b]MBRCheck[/b][/color]. Wydaje mi się, że w tym 61 sektorze znajdują się pozostałości po rootkicie. Przeszedłeś już swoją historię infekcji w MBR na SE. Miałeś infekcję w MBR ze dwa lata temu i ją usunąłeś, potem zgłosiłeś się z początkiem 2010 pokazując log z mbr.exe właśnie ze szczątkami tej infekcji, czyli ślady szkodliwego kodu w sektorach 61 i 62, których nadpis MBR nie czyści i nic się z tym nie robi = skan tego obszaru będzie wykryty jako "zainfekowany", ale to nie jest istotne. Owe ślady będziesz miał, dopóki działasz na dysku nie podannym destrukcyjnemu zerowaniu całej zawartości od czasu tamtych infekcji. To jedno. Ale: Wracasz teraz i należy zauważyć, że tym razem jest pokazywany krytyczny sektor [b]zero[/b] z podejrzaną aktywnością (co jest alarmujące), mbr.exe miał jednak zastrzeżenia i wyraźnie mówił o potencjalnej infekcji, a GMER po niby leczeniu nie zmienia zdania i widzi tam rootkita. Dlatego ja bym nadpisała dla pewności całe MBR raz jeszcze, ale nie z poziomu Windows i przy użyciu narzędzi typu mbr.exe, tylko przez Konsolę Odzyskiwania i FIXMBR. Stosowałeś już to, tylko że po pierwsze stosowałeś to w stadium rozwalonych partycji, po drugie [u]wykorzystałeś po tym TestDisk[/u], który wszystko odkręcił. . Odnośnik do komentarza
NoVVy Opublikowano 3 Listopada 2010 Autor Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Jestem po formacie partycji systemowej. Pełne formatowanie (ale standardowe z poziomu instalatora chociaż wiem, że przydałoby się całkowite wyzerowanie dysku). Logi przed wykonaniem FIXMBR: MBRCheck Gmer Logi po wykonaniu FIXMBR: MBRCheck Gmer Pamiętam o pozostałościach z poprzedniej infekcji w sektorze 61 ale wspominam o tym ponieważ linijka z "malicious code" w Gmer trochę się teraz różni. Pozostałości po wcześniejszej infekcji kiedyś wyglądały tak: malicious code @ sector 0x950a600 size 0x1c6 Dziś Gmer pokazuje je tak: malicious code @ sector 0x12a18ac1 size 0x1c6 Pamiętam też, że MBR pokazywał pozostałości w taki sposób, że wymieniał tylko sektor 61 z "malicious code" i sektor 62 z kopią MBR a ostatnio program MBR wskazywał już ten inny "malicious code" (i dodatkowy wers z treścią "MBR rootkit infection detected"). No i trochę przeraża mnie log z Sunbelt Personal Firewall - klik. Odnośnik do komentarza
picasso Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Logi przed wykonaniem FIXMBR: Logi po wykonaniu FIXMBR: To logi po formacie? Pamiętam też, że MBR pokazywał pozostałości w taki sposób, że wymieniał tylko sektor 61 z "malicious code" i sektor 62 z kopią MBR a ostatnio program MBR wskazywał już ten inny "malicious code" (i dodatkowy wers z treścią "MBR rootkit infection detected"). Ale to oczywiste przy nowej czynnej infekcji. Komentuję, że niezależnie od leczenia ślady zawsze zostają, a najważniejszym do sprawdzania jest zawsze sektor zero a nie te pozostałe. No i trochę przeraża mnie log z Sunbelt Personal Firewall Blokuje zapora = nie ma tu nic do roboty. Pytanie tylko po co tyle zachodu skoro to jest zwykły komp używany głównie do słuchania muzyki z wav'ów zrzuconych z oryginalnych płyt (dla wygody), czasem pogrania w CS:S, Q3 czy Diablo 1 i 2, uruchamianie emulatora Atari 65 XE Choćby po to, by wpiąć komputer w botnet i używać go jako hosta rozsyłającego spam / infekcje. Poczytaj sobie ustęp początkowy z "Mitów bezpieczeństwa": KLIK . Odnośnik do komentarza
NoVVy Opublikowano 3 Listopada 2010 Autor Zgłoś Udostępnij Opublikowano 3 Listopada 2010 To logi po formacie? Tak. To są logi wykonane już po formacie na nowo postawionym XP'ku. Ale to oczywiste przy nowej czynnej infekcji. Komentuję, że niezależnie od leczenia ślady zawsze zostają, a najważniejszym do sprawdzania jest zawsze sektor zero a nie te pozostałe. No właśnie najbardziej obawiam się tego co siedzi w sektorze zero ale pomyślałem, że informacja o trochę zmienionej linijce przy "malicious code" może się przydać. Myślałem, że tam już jest coś nowego, coś co mogło nadpisać tamte pozostałości. Blokuje zapora = nie ma tu nic do roboty. To blokowanie najbardziej z tego wszystkiego mnie cieszy ale martwi mnie to, że od jakiegoś czasu do skanowania dochodzi kilka razy w ciągu doby od pewnego czasu. Wcześniej tak nie było (może raz na miesiąc) i to może chyba mieć związek z infekcją. Choćby po to, by wpiąć komputer w botnet i używać go jako hosta rozsyłającego spam / infekcje. Poczytaj sobie ustęp początkowy z "Mitów bezpieczeństwa": KLIK Czytałem już wcześniej ale teraz też sobie przeczytałem. I odnośnie fragmentu tego artykułu mam też pytanie: po trzecie, większość ataków jest przeprowadzana automatycznie w poszukiwaniu wszystkich komputerów podatnych na nie Czy to znaczy, że w logach firewall'a każdego komputera można znaleść treści wskazujące na skanowanie portów codziennie kilka razy na dobę czy tylko tych zainfekowanych? Log, który podałem zawiera tylko dwa dni (czyli tyle ile pracuje zapora po nowym postawieniu systemu) a już zaczyna wypełniać się informacjami o skanowaniu. Wcześniej tak nie było a logi były od czasu do czasu uzupełniane tylko o wpisy typu: ICMP PING CyberKit 2.2 Windows oraz ICMP Destination Unreachable Port Unreachable przy czym to ostatnie przeważnie ukazywało się po odpaleniu Steam'a. Odnośnik do komentarza
picasso Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Te wyniki mi się wcale nie podobają, nie widzę podstaw dla nieszkodliwej działalności rootkit podobnej w sektorze zero. W związku z tym: Tak. To są logi wykonane już po formacie na nowo postawionym XP'ku. Format to może być za mało, znane są przecież przypadki jak to narzędzia Windows (instalator XP / Konsola Odzyskiwania) nie potrafią nadpisać porządnie MBR w zetknięciu się choćby z Linuxem w tym obszarze i wtedy sięga się po mocniejsze procedury. Skoro lekką ręką prowadziłeś format, to ja bym poszła dalej i w końcu raz a porządnie uziemiła ślady w sektorach. Lepiej to zrobić niż płakać (rootkity MBR wykradają hasła), jeśli jest nieodgadnione podłoże dla aktywności określanej jako "rootkit". Przykładowe narzędzia do wbijania zer w MBR: SeaTools for DOS - Firmowa płyta startowa producenta Seagate (taki typ dysków jest odnotowany w MBRCheck). Opcja Erase Drive daje m.in. możliwość szybkiego czyszczenia ścieżki 0 lub wyzerowanie całego dysku. Ultimate Boot CD - Boot płyta ma załączone narzędzia do MBR. Uwaga: to zrobi dysk "na goło", zniszczy wszystkie partycje na tym dysku fizycznym, dlatego ważne dane musisz przemigrować gdzieś. Czy to znaczy, że w logach firewall'a każdego komputera można znaleść treści wskazujące na skanowanie portów codziennie kilka razy na dobę czy tylko tych zainfekowanych? Skanowanie portów i pingowanie hosta nie oznacza infekcji tego komputera, tylko próbę nieautoryzowanego dostępu (mogą być także fałszywe alarmy związane z dostawcą). Takie zjawisko może zachodzić na czystym systemie. . Odnośnik do komentarza
sphere Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Nadpisanie MBR i reszty sektorów na pierwszej ścieżce można wykonać z pod samego windowa programami typu DMDE, HxD itp. Trzeba tylko uważać co się robi. Odnośnik do komentarza
picasso Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Nadpisanie MBR można wykonać z pod samego windowa programami typu DMDE, HxD itp. Ale tu chodzi o całkowite wyczyszczenie ścieżki 0 (MBR i dalszych sektorów, wszelakich sygnatur i overlay tam zlokalizowanych). Taka operacja nie może być wykonana spod działającego systemu, bo renderuje system operacyjny na całkowicie niebootowalny. Odnośnik do komentarza
sphere Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Jak zwykle w pierwszej chwili wyraziłem się niezbyt jasno A moja poprawka posta się trochę za późno pojawiła. Nie chodziło mi o zerowanie MBR (pierwszego sektora dysku) bo jest jasne że windows po tym nie wstanie, tylko całej reszty pierwszej ścieżki czyli sektorów 2-63 (przy założeniu numeracji od 1) Odnośnik do komentarza
picasso Opublikowano 3 Listopada 2010 Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Nie chodziło mi o zerowanie MBR (pierwszego sektora dysku) bo jest jasne że windows po tym nie wstanie, tylko całej reszty pierwszej ścieżki czyli sektorów 2-63. To nie rozumiem co to za akcja, skoro sektor zero wykazuje tu odczyt rootkit i to jest najważniejsze, i mnie chodzi o zerowanie wszystkich sektorów w ścieżce zero (w tym MBR, którego wielokrotny nadpis okazał się nieskuteczny). Disk \Device\Harddisk0\DR0 sector 00 (MBR): rootkit-like behavior; Disk \Device\Harddisk0\DR0 sector 32: rootkit-like behavior; Disk \Device\Harddisk0\DR0 sector 61: rootkit-like behavior; malicious code @ sector 0x12a18ac1 size 0x1c6Disk \Device\Harddisk0\DR0 sector 62: rootkit-like behavior; copy of MBRDisk \Device\Harddisk0\DR0 sector 63: rootkit-like behavior; Disk \Device\Harddisk0\DR0 sectors 156301232 (+255): rootkit-like behavior; PS. Dodatkowo, dlaczego tu już nie ponawiam żadnych akcji spod Windows. Pierwsze podejście miało fatalne skutki: Uruchomiłem MBR z parametrem "-f" i wyskoczył komunikat, że operacja zakończyła się pomyślnie. Uruchomiłem jeszcze raz MBR żeby sprawdzić czy znowu wykryje rootkita no i niestety wykrył. Po restarcie system nie wstał. W ogóle tak jakby nie było dysku, na którym jest system. . Odnośnik do komentarza
NoVVy Opublikowano 3 Listopada 2010 Autor Zgłoś Udostępnij Opublikowano 3 Listopada 2010 Jestem w trakcie przenoszenia ważniejszych danych na drugi dysk. Postanowiłem, że postawię system właśnie na tym drugim dysku (8mb cache, tamten ma 2mb a więc oprócz poprawy bezpieczeństwa skoczy troszkę wydajność). Mam taki odruch, że zawsze gdy robię partycje na dyskach to pierwsza jest nie za duża (6gb) i nadaje się idealnie pod XP'ka albo żeby wrzucić pamięć wirtualną. Czyli zamienię dyski rolami ^^. Dla pewności zrobię Full Erase w SeaTools for DOS (czyli całe wyzerowanie dysku - ciekawe ile to potrwa ^^). Zanim jednak zabiorę się do tego zrobię malutki eksperyment - odinstaluję po kolei Sandboxie, Eset Smart Security 4 i Sunbelt Personal Firewall, odpalę Gmer'a i zobaczę czy czasem to nie jest jego błędna interpretacja. ----- UPDATE ------ Wracam z nowym logiem z Gmer'a. Skanowanie przeprowadzone po instalacji systemu na innym dysku -----> klik. Log z Gmer'a wygląda na czysty. Tamten dysk przeszedł Full Erase czyli powinien być czysty (jeżeli mam jeszcze czymś go przeskanować to proszę o info). Co do samej infekcji to miałem nadzieję, że to fałszywy alarm ze strony Gmer'a. Odinstalowywałem po kolei wymienione wyżej programy i robiłem skan ale okazało się, że to żaden z tych programów -----> klik - (log utworzony przed zerowaniem tamtego zainfekowanego dysku) - nadal coś tam siedziało (oprócz tego widać jeszcze pozostałości po ESS 4). Jeśli chodzi o te logi z firewall'a to na razie wygląda to tak -----> klik. Ja wiem, że uparcie wracam do tego tematu ale to tylko dlatego, że widzę ogromną różnicę w porównaniu z tym co było wcześniej (żałuję bardzo, że nie mam już starych logów ale dałbym sobie obie ręce uciąć, że takiej częstotliwości skanowania portów tam nie było - raz na miesiąc góra i to wcale nie dlatego, że firewall nie rejestrował wszystkiego ^^). No chyba, że na przestrzeni kilku miesięcy znacznie powiększyła się liczba automatycznie przeprowadzanych ataków (o których jest mowa w artykule "- Mity bezpieczeństwa") co oczywiście nie jest niemożliwe. Skoro lekką ręką prowadziłeś format, to ja bym poszła dalej i w końcu raz a porządnie uziemiła ślady w sektorach. Prawdę mówiąc to bardzo nie chciałem robić tego formatowania partycji systemowej a co dopiero zerowania całego dysku Na tym kompie nie robiłem formatu od kilku lat ponieważ jestem zdania, że format to takie obejście problemu a tak jak się zawsze posiedziało nad jakimś problemem to nie tylko znalazło się jakieś rozwiązanie ale i wiedzy w głowie przybywało ^^ Niestety w przypadku tej infekcji zerowanie dysku było chyba najrozsądniejszą opcją. @picasso po raz kolejny bardzo mi pomogłaś - bardzo Ci dziękuję! @Landuss dziękuję Ci za pomoc i poświęcony czas @sphere dzięki za zainteresowanie tematem Pozdrawiam! ps. jeżeli mam wrzucić jeszcze logi z jakiegoś programu to proszę o informację. Odnośnik do komentarza
picasso Opublikowano 4 Listopada 2010 Zgłoś Udostępnij Opublikowano 4 Listopada 2010 (edytowane) Tamten dysk przeszedł Full Erase czyli powinien być czysty (jeżeli mam jeszcze czymś go przeskanować to proszę o info). Po zerowaniu to nie ma już co skanować. Co do samej infekcji to miałem nadzieję, że to fałszywy alarm ze strony Gmer'a. Odinstalowywałem po kolei wymienione wyżej programy i robiłem skan ale okazało się, że to żaden z tych programów W to akurat powątpiewałam i czekałam aż tu się zgłosisz już z wynikami zerowania, przypuszczając, że false alarmu i tak nie zdołasz udowodnić. Już wczoraj dla świętego spokoju sprawdzałam w wirtualnej maszynie kilka rzeczy przy udziale tej konkretnej wersji GMER, ta kombinacja programowa nie skutkowała żadnymi zgłoszeniami w MBR. Niestety w przypadku tej infekcji zerowanie dysku było chyba najrozsądniejszą opcją. Też tak sądzę i nie żałuj tego kroku. Po pierwsze: nie wiadomo co tam było i jaki był tego cel (a jeszcze: mam nadzieję, że masz wszędzie już nowe hasła). Po drugie: to system, który już wcześniej był zainfekowany w MBR. Przy wielokrotnej infekcji w tej samej sferze nie ma pewności jakie mogą być skutki. Dla porównania: przy którymś tam wariancie TDL, nawet po wyczyszczeniu infekcji zostawały pewne dane w sektorach, a po reinfekcji tym samym wariantem i próbie usuwania następował całkowity pad systemu, bo infekcja już zachowywała się całkiem inaczej na dysku uprzednio tym zaprawionym niż na dysku nigdy wcześniej nie poddanym temu działaniu. U Ciebie była dziwna sprawa, po użyciu MBR z przełącznikiem reperacji padły wszystkie partycje. Nie wiem do czego to podpasować, czy do tego że na dysku były ślady poprzedniej infekcji, czy do kolizji między rootkitem a próbą reperacji (ja zresztą się ogólnie skłaniam, by na zarażonym MBR raczej robić naprawy z bootowalnych płyt a nie spod Windows, rootkit jest czynny w pamięci). Na koniec: infekcje w MBR umieją obchodzić narzędzia. Na forum tutaj MBRCheck już raz został oszukany. Zdarza się, że TDSSKiller nawala i wcale nie widzi rootkita. Trochę podratował ostatnio sprawę GMER / MBR.EXE, bo w końcu oba narzędzia mają poprawkę na detekcję nowych wariantów (przed tym było kiepsko, nie widziały wcale nowych infekcji w MBR i trzeba było posiłkować się MBRCheck i Bootkit Remover). Ja wiem, że uparcie wracam do tego tematu ale to tylko dlatego, że widzę ogromną różnicę w porównaniu z tym co było wcześniej (żałuję bardzo, że nie mam już starych logów ale dałbym sobie obie ręce uciąć, że takiej częstotliwości skanowania portów tam nie było - raz na miesiąc góra i to wcale nie dlatego, że firewall nie rejestrował wszystkiego ^^). No chyba, że na przestrzeni kilku miesięcy znacznie powiększyła się liczba automatycznie przeprowadzanych ataków (o których jest mowa w artykule "- Mity bezpieczeństwa") co oczywiście nie jest niemożliwe. Nie wiem dlaczego zwiększyła się częstotliwość, ale jest wysoce prawdopodobne, że w sieci grasuje jakiś robak / wirus, który wyszukuje hosta i próbuje się doń dostać. Z Twoimi wynikami i tak nie da rady nic zrobić. Tylko pilnuj aktualizacji Windows. . Edytowane 25 Listopada 2010 przez picasso 25.11.2010 - Brak komentarzy, temat więc zamykam. //picasso Odnośnik do komentarza
Rekomendowane odpowiedzi