piątek, 31 lipca 2015

Dekodowanie plików konfiguracyjnych

Nadarzyła się dobra okazja aby opisać proces tworzenia narzędzi dekodujących pliki konfiguracyjne. Ta okazja to kolejny atak z użyciem złośliwego oprogramowania na klientów bankowości internetowej – w tym klientów banków w Polsce ale też Allegro. Atak ma miejsce od 3-4 dni.
Poniżej fragmenty pliku konfiguracyjnego:

Zainfekowani klienci powyższych instytucji mogą otrzymać komunikaty podobne do poniższych:





Nie będziemy opisywali wszystkich szczegółów technicznych gdyż są dobrze opisane tutaj [1]. Tym razem zajmiemy się plikami tworzonymi przez malware.


Dwa z nich log.dat oraz ntf.dat są co kilka minut tworzone i kasowane. Zawierają one zakodowaną wiadomość przesyłaną do serwera C&C - między innymi listę aktualnie uruchomionych procesów na zainfekowanym komputerze.
Pliki są szyfrowane za pomocą RC4 z kluczem:
 Poniżej przykład komunikacji:

Odpowiedzią z serwera może być nowy plik wykonywalny lub aktualna konfiguracja.
Ostatni plik web.dat to aktualna konfiguracja – również zakodowana. Poza celami ataków są tam fragmenty html i javascript. Są też URL dodatkowych serwerów C&C na których znajdują się dodatkowe skrypty js.

 

Odkodowywanie składa się z 3 etapów:

 

1. Odkodowanie XOR z losowym kluczem. 

 

Niestety na każdym komputerze generowany jest inny klucz związany z hostem. Klucz można pozyskać z kilku miejsc, między innymi z komunikacji sieciowej lub nazwy katalogu w którym zapisywany jest plik wykonywalny. W naszym przypadku będzie to D77AE23E.
Poniżej kod realizujący tą funkcję:


Fragment pliku konfiguracyjnego przed i po kodowaniu:

Funkcja naszego programu odkodowującego może wyglądać następująco:

xor(const void *source, int size)
{
    __asm {

        mov esi, ebx
        xor ebx, ebx
        mov ebx, 0x3E2C7AD7
       
    loop1:
        xor [ecx], bl
        ror ebx, 8
        inc ecx
        dec eax
        jnz loop1
    end1:
        mov ebx, esi
    }


Do funkcji przekazujemy dwa parametry: wskaźnik do tablicy z wczytanym plikiem web.dat oraz rozmiar. Poniżej fragment kodu odczytujący plik i wyliczający rozmiar.

FILE *fin;

fopen_s(&fin, argv[1], "rb");
fseek(fin, 0, SEEK_END);
sourcefilesize = ftell(fin);
rewind(fin);
char * tab_scr = (char *)malloc(sourcefilesize);
fread(buf1, 1, sourcefilesize, fin);
for (i = 0; i <= sourcefilesize; i++)
tab_scr[i] = 0;
memcpy(tab_scr, buf1, sourcefilesize); 

 

2. Odkodowywanie z kluczem RC

 


Fragment odkodowanego pliku:


Poniżej funkcja [2], którą zastosujemy w naszym programie dekodującym:

    rc4(char * Input, char * password, char * &Output, int sourcefilesize){
    char * temp;
    int i, j = 0, t, tmp, tmp2, s[256], k[256];
    for (tmp = 0; tmp<256; tmp++){
        s[tmp] = tmp;
        k[tmp] = password[(tmp % strlen((char *)password))];
    }
    for (i = 0; i<256; i++){
        j = (j + s[i] + k[i]) % 256;
        tmp = s[i];
        s[i] = s[j];
        s[j] = tmp;
    }
    temp = new char[sourcefilesize];
    i = j = 0;
    for (tmp = 0; tmp< sourcefilesize; tmp++){
        i = (i + 1) % 256;
        j = (j + s[i]) % 256;
        tmp2 = s[i];
        s[i] = s[j];
        s[j] = tmp2;
        t = (s[i] + s[j]) % 256;
   
            temp[tmp] = s[t] ^ Input[tmp];
    }
   
    Output = temp;
}

 

3. Dekompresja odkodowanego pliku

 

Kompresja danych i dekompresja bazuje na aPlib:


Ostatni fragment kodu funkcji dekompresującej: 

        int decompress(const void *tab_scr, void *tab_dst){

            __asm{
            pushad
            mov    esi, [esp + 0x18]; tablica źródłowa
            mov    edi, [esp + 0x1c]; docelowa tablica
            add    esi, 4; omijamy nagłówek AP32
            cld
            mov    dl, 80h
            xor    ebx, ebx
           
        literal:
            movsb
            mov    bl, 2
        nexttag:
            call    getbit
            jnc     literal               

            xor     ecx, ecx
            call    getbit
            jnc     codepair           
            xor     eax, eax
            call    getbit
            jnc     shortmatch           
            mov    bl, 2
            inc     ecx
            mov     al, 10h
        getmorebits:
            call    getbit
            adc     al, al
            jnc     getmorebits               
            jnz     domatch
            stosb
            jmp     nexttag
        codepair:
            call    getgamma_no_ecx
            sub     ecx, ebx; sub    ecx, ebx
            jnz     normalcodepair
            call    getgamma
            jmp     domatch_lastpos
        shortmatch:
            lodsb                               
            shr     eax, 1
            jz      donedepacking               
            adc     ecx, ecx
            jmp     domatch_with_2inc
        normalcodepair:
            xchg    eax, ecx
            dec     eax
            shl     eax, 8
            lodsb                               
            call    getgamma

            cmp     eax, 32000
            jnc     domatch_with_2inc           
            cmp     ah, 5
            jnc     domatch_with_inc           
            cmp     eax, 7Fh
            ja      domatch_new_lastpos
        domatch_with_2inc:
            inc     ecx
        domatch_with_inc:
            inc     ecx
        domatch_new_lastpos:
            xchg    eax, ebp
        domatch_lastpos:
            mov     eax, ebp
            mov    bl, 1
        domatch:   
            push    esi
            mov     esi, edi
            sub     esi, eax
            rep     movsb
            pop     esi
            jmp     nexttag
        getbit:       
            add     dl, dl
            jnz     stillbitsleft
            mov     dl, [esi]
            inc     esi
            adc     dl, dl
        stillbitsleft:
            ret
        getgamma:
            xor     ecx, ecx
        getgamma_no_ecx:
            inc     ecx
        getgammaloop:
            call    getbit
            adc     ecx, ecx
            call    getbit
            jc      getgammaloop       
            ret
        donedepacking:
            sub    edi, [esp+0x1c];    dest //wyliczanie rozmiaru
            mov    [esp], edi; //esp _ret$ zwracamy rozmiar docelowy
            popad
    }}

Kod aPlib możemy znaleźć  między innymi na tych stronach  [3] i [4].  Uwaga, w stosunku do wskazanych źródeł [2,3,4] dokonaliśmy modyfikacji, więc najlepiej wykorzystać podany tutaj kod.
Pozostaje nam już tylko zapisać wynik do pliku.

size_of_output = decompress(tab_scr, tab_dst);
fwrite(tab_dst, size_of_output, 1, fout);


Rezultat przedstawiony jest poniżej:


Analizując malware można też zidentyfikować inny klucz XOR - F3AA0663 (tym razem stały). Używany jest on do odkodowywania fragmentów konfiguracyjnych malware, które w formie zakodowanej znajdują się w sekcji danych aplikacji.

Funkcja dekodująca:


Fragment wczytujący BOTUID do zapytania URL:

Plik wykonywalny dodawany do klucza RUN zapisywany jest w katalogu:

C:\Users\<username>\AppData\Roaming\3E2C7AD7\bin.exe

Źródła:
[1] http://blog.fortinet.com/post/tinba-the-pied-piper-leading-your-banking-credentials-into-the-hands-of-hackers
[2] http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=4653&lngWId=3
[3] http://ibsensoftware.com/products_aPLib.html
[4] https://code.google.com/p/at2/issues/detail?id=17
[5] Próbki:  MD5: 49BDB9D33F6F7B0C5919A1CB289365EA oraz MD5: AE2B35B39011DFAA7F5A8072899A699C


sobota, 13 czerwca 2015

Malware timeline

Historia aktywności (ang. timeline lub jak ktoś woli oś czasu) jest techniką wykorzystywaną w informatyce śledczej. Chodzi o odtworzenie w czasie sekwencji aktywności wykonywanych przez użytkownika.

Tę technikę możemy zastosować gdy nie mamy 100% pewności czy i ewentualnie który plik/pliki są złośliwym oprogramowaniem na komputerze. Oczywiście cele analizy mogą być różne – od identyfikacji złośliwego oprogramowania po określenie do których informacji intruz uzyskał dostęp.

Odtworzenie zdarzeń w czasie jest tym dokładniejsze im większą ilość danych posiadamy. Można to porównać do dedykowanych systemów używanych w instytucjach do zbierania i korelacji zdarzeń z wielu systemów i aplikacji. Przenosząc analogiczną funkcjonalność na poziom jednego serwera lub stacji roboczej również mamy na myśli zdarzenia generowane przez aplikacje ale nie tylko. Są to również zdarzenia zapisywane w metadanych systemu plików (w tym informacje o usuniętych obiektach), dane z rejestrów czy dzienników zdarzeń systemu operacyjnego.

Przed rozpoczęciem analizy chcemy zwrócić uwagę na dwie istotne kwestie.

Timeline to historia zdarzeń w czasie gdzie głównym parametrem są daty zapisane w systemie. W przypadku danych z systemu plików jest to informacja o ostatnim dostępie do pliku czy ostatniej zmianie zawartości pliku. Dla przykładu, jeśli użytkownik pięć razy odczytywał zwartość pliku – to w systemie plików mamy informację o ostatniej dacie. Oczywiście jest wiele wyjątków od tej zasady (miejsc gdzie możemy odczytać inne daty).

Podczas analizy istotna jest również wiedza na temat jak konkretny system się „zachowuje” (np. kiedy uaktualniana jest zawartość parametru Date Accessed atrybutu STANDARD_INFORMATION dla pliku - rekordu typu FILE w tablicy MFT dla systemu Windows 7).

Podsumowując – trzeba być bardzo ostrożnym w formułowaniu wniosków w raporcie z analizy.

Zacznijmy jednak od prostego przykładu. Chcemy sprawdzić, czy użytkownik otworzył otrzymaną „fakturę/informację o przesyłce, paczce, działce itp” oraz czy i ewentualnie jaka była aktywność złośliwego oprogramowania na zainfekowanym komputerze.

Pierwszy krok to wykonanie kopii dysku twardego komputera.

Drugi krok to zamontowanie partycji w trybie do odczytu na systemie używanym do analizy. Polecamy SIFT Workstation [1].

#mount.ntfs-3g –o ro,nodev,noexec,show_sys_files,loop malware_ntfs01.dd /cases/training/analiza

Krok trzeci – korzystając z narzędzia log2timeline generujemy plik w formacie csv o “wszystkich” zdarzeniach w analizowanym systemie [2]:

#log2timeline –z CET –w /cases/wynik_timeline.csv –f win7 –r –p /cases/training/analiza


Istotna jest wartość parametru -f. Lista win7 zawiera następujące moduły (parser-y do analizy danych): chrome, evtx, exif, ff_bookmark, firefox3, iehistory, iis, mcafee, opera, oxml, pdf, prefetch, recycler, restore, sol, win_link, xpfirewall, wmiprov, ntuser, software, system, sam, mft, ff_cache, mcafeefireup, mcafeehel, mcafeehs, openvpn, skype_sql, security, Symantec, firefox2 oraz safari.

Mamy też inną możliwość - zapisanie wyników w formacie mactime [3] (przełącznik –o) i za pomocą komendy mactime wykonania filtrowania w przedziale czasu (#mactime –b /cases/wynik_timeline.txt  2015-06-01..2015-06-11 > wynik_timeline_filtered.txt)

My zapisujemy dane w formacie csv gdyż do analizy aktywności użyjemy narzędzia graficznego 4n6time [2].

Po uruchomieniu 4n6time tworzymy nową bazę i wczytujemy plik csv. Dodatkowo wprowadzamy filtr dotyczący przedziału czasu.

4n6time pozwala wyszukiwać po każdym z pół. Jeżeli nie mamy pomysłu od czego zacząć – sprawdźmy czy zmodyfikowany został np. rejestr RUN (częste zachowane malware). Użyjemy do tego funkcji String Search.


8 czerwca o godzinie 13:19:37 zmodyfikowany został klucz RUN (MACB to kolejno: File Modified, Accessed, MFT Modified, Changed).

Sprawdźmy inne zdarzenia w tym samym czasie zapisane w analizowanym systemie:


Oprócz informacji z rejestrów (NTUSER.dat – profil zainfekowanego użytkownika) jest jeszcze zdarzenie dotyczące utworzenia pliku exe w podkatalogu c:/Users/<username>/AppData/Local użytkownika.

Sekundę wcześniej został zmodyfikowany plik w katalogu Prefetch. Informacja z prefetch (modyfikacja czasów AB) oznacza, że plik aaa.exe („faktura” – plik wykonywalny ze złośliwym kodem) był uruchamiany przez użytkownika więcej niż 1 raz.

Potwierdza to informacja o pliku z funkcji systemu Windows User Assist (zapisuje dane w NTUSER.DAT):


W niniejszym przykładzie korelacja danych pochodzi tylko z 3 modułów (prefetch, mft, ntuser) a mimo to pozwoliła na odtworzenie fragmentu zdarzeń z przeszłości.

Kontynuując analizę możemy zauważyć, że niecałe 3 minuty później tworzone i modyfikowane są pliki (exe i tmp) w katalogu temp zainfekowanego użytkownika.


Z poziomu narzędzia 4n6time będzie możliwe  sprawdzenie podejrzanych plików w VirusTotal lub wyświetlić ich zawartość.

Pliki exe to programy rozsyłające wiadomości email z „informacją o przesyłce” na kolejne adresy email. W plikach .tmp znajdują się treści email oraz stron w różnych językach – w tym ten dotyczący przesyłek DHL.




Należy pamiętać, że timeline nie umożliwi odtworzenia wszystkich zdarzeń / aktywności programów – w szczególności wszystkich aktywności złośliwego kodu (zazwyczaj malware nie korzysta z przeglądarki internetowej tylko bezpośrednio z API bibliotek). Niemniej technika ta pozwala na odtworzenie działań użytkowników w tym zidentyfikowania źródła infekcji.

Odnośniki:

[1] http://digital-forensics.sans.org/community/downloads
[2] http://plaso.kiddaland.net/
[3] http://www.sleuthkit.org/

czwartek, 28 maja 2015

ARCFOUR

Od dawna twórcy złośliwego oprogramowania stosują algorytmy kryptograficzne do utrudnienia analizy (np. uniemożliwienia uzyskiwania plików konfiguracyjnych z zrzutu pamięci procesu, szyfrowania komunikacji sieciowej) czy ograniczenia prób identyfikacji przez systemy AV/BDS.
Już pisaliśmy o malware i szyfrowaniu RC4, jednak niniejszy przypadek jest ciekawszy. Algorytm symetryczny RC4 został zastosowany kilka razy w procesie uruchamiania złośliwego kodu na zainfekowanym komputerze.

Analizowany plik ze złośliwym oprogramowaniem to „pdf informacja o działki.exe”. Od 7 maja na skrzynki email osób prywatnych ale również konta firmowe w Polsce regularnie (co 6-7 dni) trafiają wiadomości, które umożliwiają nam pobranie tego pliku.



Przykłady pobieranych plików zip zawierających plik exe:


Uruchomienie aplikacji powoduje instalację komponentu malware (system.pif) w katalogu domowym użytkownika Startup/Autostart. Ten komponent może pobierać/uruchamiać bez wiedzy/udziału użytkownika inne pliki wykonywalne (efektem końcowym są zaszyfrowane pliki – nie tylko dysków lokalnych ale i podłączonych zasobów sieciowych). Jest też wersja na system Android mająca inną funkcjonalność [1].

Algorytm RC4  wykorzystywany jest do:
  • Odszyfrowania fragmentu kodu wykonywalnego loader-a (ten fragment odpowiada za odkodowanie głównego kodu),
  • Odszyfrowywania klucza, który użyty jest do odszyfrowania dwóch plików wykonywalnych,
  • Odszyfrowania dwóch plików wykonywalnych. Jeden plik mapowany jest do pamięci procesu system.pif, drugi (spakowany UPX) mapowany do pamięci procesu iexplore.exe. W obu przypadkach zastosowana technika to process hollowing,
  • Szyfrowania komunikacji pomiędzy działającym procesem malware a serwerami C&C (jeden z zastosowanych kluczy &^V8trcv67d[wf9798687RY). Serwery C&C są w domenie .RU (zastosowano również usługę Fast-Flux) – niektóre adresy IP są jeszcze aktywne.
Poniżej fragmenty oryginalnego pliku system.pif i przykłady zastosowania algorytmu RC4.

Fragment kodu, który identyfikuje klucz RC4 używany do odkodowania głównego kodu loader-a (rozmiar loader-a 0x3E80).


Poszczególne fragmentu zakodowanego kodu oddzielone są tagiem „RT-t”. W zielonej ramce klucz deszyfrujący.


Zaszyfrowane pliki wykonywalne umieszczone są jako zasób 21 (widok z CFF Explorer).


Fragment kodu odszyfrowujący pliki wykonywalne:


Odkodowany fragment malware (pierwszego pliku wykonywalnego):


Co ciekawe klucz odszyfrowujący dwa pliki jest również zaszyfrowany RC4. Poniżej jego wersja zaszyfrowana (z pliku pif) i odszyfrowana (z pamięci):


Poniżej ostatni przykład. Proces szyfrowania danych przed wysłaniem do serwerów C&C.


Malware przesyła do serwera C&C nazwę użytkownika, nazwę hosta oraz listę aktualnie uruchomionych procesów.

Odnośniki zewnętrzne:
[1] http://www.cert.pl/news/10180

sobota, 16 maja 2015

Analiza złośliwego załącznika z makro

Poniżej przedstawiamy krótką analizę rozsyłanego dzisiaj załącznika. Malware rozsyłany w załączniku miał bardzo małą wykrywalność przez programy AV – ale to nie powinno nikogo dziwić.

Załączany do wiadomości email plik jest dokumentem z rozszerzeniem doc. Jednak gdy otworzymy go w edytorze szesnastkowym możemy zauważyć, że zapisany jest w formacie MIME. Oryginalnie zapisany był jako plik htm a następnie rozszerzenie zostało zmienione na .doc. Zaletą takiego formatu jest to, że obiekty w pliku doc kodowane są za pomocą base64 (np. skrypty VBS). Taki plik bez problemów może być otworzony przez użytkownika z poziomu klienta poczty.


Następnym krokiem jest konwersja do formatu doc (Word 97 – 2003). Najszybciej zrobimy to z pomocą edytora Word z wyłączoną obsługą makr. Możemy zauważyć, że plik zawiera makra ale dostęp do projektu VBS chroniony jest hasłem.



Jest kilka znanych metod obejścia tego mechanizmu. Zamieniamy hasło na znane modyfikując wartości CMG/DPB/GC lub modyfikujemy nazwę parametru. Możemy też rozpakować plik doc i z poziom edytora szesnastkowego uzyskać dostęp do VBS.

Poniżej przykład modyfikacji parametru:


Po ponownym otwarciu pliku doc w edytorze Word pojawi się komunikat o błędzie.


Akceptujemy ostrzeżenie i zapisujemy plik jako nowy plik doc. Teraz gdy ponownie go otworzymy mamy dostęp do skryptów. Niestety skrypty są obfuskowane więc przydatny będzie debugger. Do monitorowania parametrów możemy wykorzystać funkcjonalność Watch lub funkcje MsgBox(). Poniżej zawartość głównej funkcji:


Na początku odkodowywane są nazwy obiektów (np. MSXML2.XMLHTTP), adres URL i wywoływane są funkcje pobierające kolejny skrypt (z serwera pastebin.com), który jest zapisywany w katalogu TEMP a następnie uruchamiany. Funkcja VunjuLavjtQLpqQ() odpowiada za odszyfrowywanie fragmentów danych: Public Function VunjuLavjtQLpqQ(ByVal Data As String, ByVal Password As String) As String. Dodając na jej końcu funkcję MsgBox() będziemy mogli monitorować zwracane wartości. Poniżej przykład odkodowanego adresu URL z którym łączy się skrypt:


Poniżej fragment zawartości pobranego skryptu. Pierwszy adres URL nie jest zakodowany. Dopiero z tego adresu URL pobierany jest plik EXE ze złośliwym oprogramowaniem.


Dalsza część skryptu sprawdza między innymi czy uruchomiony jest Microsoft Word (za pomocą WMI - iyuiuiiii.ExecQuery). Jest też zakodowany drugi adres URL w domenie .RU na który wysyłane są powiadomienia:


Załącznik: (MD5: 9F38297FEB64734AB3E95ECBCD5F75E7) = VT: 5
Pobierany EXE: (MD5: EDB660EF32E2FD59AD1E610E9842C2DF) = VT: 21

środa, 13 maja 2015

Metody socjotechniczne w bankowości internetowej

Od dwóch dni obserwujemy dużą aktywność złośliwego oprogramowania (powiadomienia z DHL), które zawiera w swoich plikach konfiguracyjnych kilka banków z Polski. Są to:
  • *citibankonline.pl*
  • *online.ingbank.pl
  • *aliorbank.pl/
  • *ebgz.pl/detal-web/jbank/*
  • *online.mbank.pl*
  • *www.ipko.pl/nowe*
Jest to malware typu "webinject". Złośliwy kod javascript „doklejany” jest do stron bankowości internetowej po zalogowaniu użytkownika. Niektóre skrypty są w całości doklejane a niektóre pobierane z wielu serwerów za pomocą https. Mogą się również pojawiać komunikaty w dodatkowych oknach.

Oto komunikaty, które będą się pojawiały zainfekowanym klientom bankowości.

Treść komunikatu numer 1:


Treść komunikatu numer 2:


Treść komunikatu numer 3:


Powiązane komunikaty:



Treść komunikatu numer 4 (Zarezerwowany jak na razie dla jednego banku):


Ja łatwo zauważyć tłumaczenie na język polski nie jest najlepsze.

Jest to malware wykrywany przez systemy AV jako EMOTET. O tym jak odkodować plik konfiguracyjny tego malware pisaliśmy tutaj.

Jak znaleźć i usunąć z dysku złośliwy kod?

Plik wykonywalny:
c:\users\<username>\AppData\Local\1a7c93b1b3afe745137ad900a554236d.exe

Autostart z klucza RUN:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run -> 1a7c93b1b3afe745137ad900a554236d.exe