Paweł Goleń, blog

W tym eksperymencie użyłem starego zrzutu, o którym pisałem w cyklu o analizie malware, zrzuty można pobrać stąd. To, co interesuje mnie tym razem, to możliwość prostego odtworzenia sekwencji zdarzeń, a konkretnie sekwencji nawiązywanych połączeń. Prezentowane dalej przykłady pochodzą z pliku 2-infekcja.pcap.

Jeszcze małe uzasadnienie tego eksperymentu. Śmieszą mnie "hakerskie filmy" z latającymi cyferkami i innymi takimi efektami wizualnymi, ale muszę również przyznać, że jestem wzrokowcem, łatwiej mi dostrzec pewne rzeczy i powiązania między nimi, gdy zamiast białych literek na czarnej konsoli, mam nieco ładniejszą wizualizację sytuacji.

Najpierw spojrzenie na całą historię zdarzeń zarejestrowaną w pliku.

Komputer o adresie 172.16.0.41 to ofiara malware. Jak widać w czasie objętym zrzutem nawiązywał on komunikację z sześcioma innymi komputerami, z czego jeden znajdował się w sieci lokalnej, jeden natomiast nie odpowiedział (ten bez koloru oznaczony przerywanymi liniami). Poniżej zarejestrowana w logu informacja o aktywności 172.16.0.41 pokazana przy użyciu NetworkMiner:

To, czego brakuje mi w NetworkMiner to możliwość ustalenia sekwencji zdarzeń. Co prawda sesje TCP są opatrywane informacjami dotyczącymi czasu ich rozpoczęcia i zakończenia, ale już wysłane pakiety UDP nie.

Ponieważ celem jest uzyskanie sekwencji zdarzeń, w NetGrok można zmniejszyć zakres czasowy wizualizowanego ruchu sieciowego do minimum (np. kilku sekund), a następnie "przesuwać okno" po całym zarejestrowanym logu. Można uzyskać następujące rezultaty:

Rolę komunikacji z wewnętrznym serwerem o adresie IP 172.16.0.254 stosunkowo łatwo ustalić, tu można skorzystać z narzędzia NetworkMiner, które przedstawia następującą informację o pakietach wysyłanych z 172.16.0.41 do 172.16.0.254:

172.16.0.41 (Windows) -> 172.16.0.254 : 11 packets (696 Bytes), 0,00% cleartext (0 of 0 Bytes)
    UDP: 1030 -> 53 : 10 packets (638 Bytes), 0,00% cleartext (0 of 0 Bytes)
    UDP: 1032 -> 53 : 1 packets (58 Bytes), 0,00% cleartext (0 of 0 Bytes)

Jak widać host 172.16.0.41 korzysta z usługi DNS udostępnionej na 172.16.0.254, lista ciekawych wykorzystanych nazw:

• ss.MEMEHEHZ.INFO (IP: 67.43.232.37),
• nadsam0.info (IP: 72.10.167.74),
• xx.sqlteam.info (IP: 72.10.172.212),
• u.sqlteam.info (IP: 67.43.236.106),
• serv1.alwaysproxy3.info (IP: 72.8.143.183),

Tu widać nawiązanie połączenia z adresem 67.43.232.37. Informację o tej sesji łatwo uzyskać z NetworkMiner:

Server: 67.43.232.37 [ss.MEMEHEHZ.INFO] 
    TCP 8080 (1850 data bytes sent), 
        Client: 172.16.0.41 (Windows) TCP 1031 (215 data bytes sent), 
        Session start: 2008-05-17 21:47:19, 
        Session end: 2008-05-17 21:49:21

Tu z kolei nawiązane zostało połączenie z 72.10.167.74, kolor tego hosta świadczy o stosunkowo dużej ilości przesłanych danych. W NetworkMiner znajdują się następujące informacje o sesjach:

Server: 72.10.167.74 [nadsam0.info] TCP 80 (26445 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1033 (45 data bytes sent), 
    Session start: 2008-05-17 21:47:21, 
    Session end: 2008-05-17 21:47:22

Server: 72.10.167.74 [nadsam0.info] TCP 80 (38735 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1034 (48 data bytes sent), 
    Session start: 2008-05-17 21:47:21, 
    Session end: 2008-05-17 21:47:23

Server: 72.10.167.74 [nadsam0.info] TCP 80 (69452 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1035 (45 data bytes sent), 
    Session start: 2008-05-17 21:47:21, 
    Session end: 2008-05-17 21:47:23

Patrząc na port (80) oraz wielkość danych wysyłanych/pobieranych, można przypuszczać, że w tym momencie pobierane są pliki.

Tu pojawia się połączenie z 72.10.172.212.

Server: 72.10.172.212 [xx.sqlteam.info] TCP 5190 (1598 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1036 (178 data bytes sent), 
    Session start: 2008-05-17 21:47:31, 
    Session end: 2008-05-17 21:47:34

A tu znowu pojawia się komunikacja z IP: 72.10.167.74:

Server: 72.10.167.74 [nadsam0.info] TCP 80 (9552 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1038 (49 data bytes sent), 
    Session start: 2008-05-17 21:47:34, 
    Session end: 2008-05-17 21:47:35

Server: 72.10.167.74 [nadsam0.info] TCP 80 (26445 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1039 (45 data bytes sent), 
    Session start: 2008-05-17 21:47:34, 
    Session end: 2008-05-17 21:47:35

Server: 72.10.167.74 [nadsam0.info] TCP 80 (23375 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1037 (47 data bytes sent), 
    Session start: 2008-05-17 21:47:34, 
    Session end: 2008-05-17 21:47:35

Tu pojawia się z kolei połączenie z Server: 67.43.236.106:

Server: 67.43.236.106 [u.sqlteam.info] TCP 7000 (642 data bytes sent), 
  Client: 172.16.0.41 (Windows) TCP 1041 (59 data bytes sent), 
    Session start: 2008-05-17 21:47:35, 
    Session end: 2008-05-17 21:47:36

Tutaj następuje próba komunikacji z 72.8.143.183, wysłany jest jeden pakiet UDP:

172.16.0.41 (Windows) -> 72.8.143.183 [serv1.alwaysproxy3.info] : 
1 packets (32 Bytes), 0,00% cleartext (0 of 0 Bytes)
  UDP: 1044 -> 18386 : 1 packets (32 Bytes), 0,00% cleartext (0 of 0 Bytes)

I to wszystko. Nic nowego w stosunku do oryginalnej analizy, ale tak jakoś ładniej, bo z obrazkami.