Malware ანალიზი 'NativeApp_G4QLIQRa.exe' ნაწილი #1

დასაწყისი

კინოს ვუყურებდი, როდესაც რეკლამამ უცნაურ ლინკზე გადამიყვანა, საიდანაც .exe ფაილის გადმოწერა დაიწყო ბრაუზერმა. ეს ამბავი ძალიან მეუცნაურა. ასე, რომ გამოვრთე ფილმი, ჩავრთე ვირტუალური მანქანა და ეს ფაილი იქ გადავიტანე.

ანტივირუსის გამორთვა მომიწია, რადგან Windows Defender-მა ეგრევე დაიჭირა ვირუსი.

ანალიზის დასაწყისი

რა თქმა უნდა, გარკვეული ხელსაწყოებია საჭირო ამ ფაილის ანალიზისათვის. ამ შემთხვევაში ორ პროგრამას გამოვიყენებ:

1. radare2
2. xdbg

xdbg უფრო დინამიური ანალიზისას გამოიყენება, ხოლო radare2-ს ორივე სახის ანალიზი შეუძლია, სტატიკურიც და დინამიურიც. რა თქმა უნდა, xdbg-საც შეუძლია იგივეს გაკეთება, მაგრამ ამ ორ პროგრამას შორის საკმაოდ დიდი განსხვავებაა და შესაძლებელია ზოგი რამ სხვანაირად გამოჩნდეს.

radare2

პირველ რიგში, სტატიკური ანალიზი უნდა გავაკეთო. ბრძანება ასეთი იქნება:

.\r2.exe NativeApp_G4QLIQRa.exe

ამის შემდეგ, r2 ფაილის ანალიზში დამეხმარება:

[0x004033bf]>

ეს პრომპტი(Prompt) აჩვენებს თუ რომელ Memory Address-ს უყურებს r2. თავდაპირველად, საჭიროა ამ ფაილის სრული ანალიზი:

aaaa

ამ ბრძანებით r2 სრულად გააანალიზებს ფაილს. ფაილის ანალიზის შედეგად მეცოდინება კონკრეტულად რა ხდება ფაილში:

1. იმპორტები(Imports)
2. ექსპორტები(Exports)
3. სიმბოლოები და ტექსტები(Symbols and Strings)
4. ფუნქციები(Functions)

ანუ, რა სიმბოლოები, ბიბლიოთეკები და ფუნქციებია გამოყენებული. ამის შემდეგ, შემიძლია afl ბრძანების გამოყენება, რათა არსებული ფუნქციები გამოვიტანო ტერმინალში:

რა თქმა უნდა, კიდევ ბევრი ფუნქციაა, უბრალოდ ერთ ფოტოში ვერ ვატევ. ამ შემთხვევაში, საჭიროა entry0-ზე გადასვლა, რადგან სწორედ ესაა პროგრამის ე.წ. Entry Point.

s entry0

სწორედ ამ ბრძანებით შეიძლება entry0-ზე გადასვლა. ამის შემდეგ, v ბრძანებით შესაძლებელია გრაფიკული ინტერფეისის ჩართვა, რომელიც ნაგულისხმევად(By default) დისასემბლის, სიმბოლოების სიას და გამოყენებული ფუნქციების სიას გამოიტანს:

გამოყენებული ფუნქციების სიის ანალიზისას, ჩანს, რომ ძალიან ბევრი Win32API ფუნქციაა გამოყენებული. მაგალითად:

1. CreateThread
2. CreateDirectoryW
3. CreateProcessW
4. GetProcAddress

რატომ შეიძლება იქმნებოდეს წრედი?

არის ორი ვარიანტი. პირველი ვარიანტი არის ის, რომ ეს წრედი უყურებს დებაგერს(ამ შემთხვევაში r2 ან xdbg და მისი გამოჩენის შემთხვევაში პროგრამას ან გათშავს ან საერთოდ სხვა რამეს გააკეთებინებს. მეორე ვარიანტი წრედში შესაძლებელია იყოს მავნე თვისება, რომელიც მთავარ მავნე თვისებასთან ერთად უნდა გამოჩნდეს.

რეგისტრებთან მომუშავე ფუნქციები

ასევე აღმოვაჩინე ისეთი ფუნქციები, რომლებიც რეგისტრების შეცვლას ცდილობენ:

1. RegDeleteKeyW
2. RegDeleteValueW
3. RegEnumKeyW
4. RegCloseKey
5. RegSetValueExW
6. RegQueryValueExW

რატომ ცვლის მავნე კოდი რეგისტრებს?. აქაც არსებობს რამდენიმე ვარიანტი. მაგალითად, შესაძლებელია მავნე კოდი რომელიღაც დამალულ ფაილში მალავს იმპლანტს და რეგისტრებში ამატებს მისი გაშვების ბრძანებას. როდესაც კომპიუტერი ჩაირთვება, მავნე კოდი ავტომატურად გაეშვება რეგისტრებიდან.

სექციების ანალიზი

ყველაზე მეტად იმ ფაქტმა დამაეჭვა, რომ ფაილი არის 50MB ზომაში. ეს ბევრ რამეს შეიძლება ნიშნავდეს.

1. თავდამსხმელმა დიდი payload მოათავსა რომელიმე სექციაში, რომელსაც გაშვების დროს ხსნის და სამიზნე ფაილში ათავსებს.

წინაზე რომ ვთქვი რეგისტრებს ცვლის და შესაძლოა ფაილს ავტომატურად უშვებს-მეთქი, შესაძლოა სწორედ ეგ ფაილია ჩადებული, მაგალითად .text სექციაში და იქიდან ხდება ამ ფაილის ამოღება და სადმე შენახვა.

ამის გაკეთება ძალიან მარტივია. ზოგადად, ასეთ ფაილებს მატრიოშკებს ვეძახი, რადგან სწორედ მატრიოშკას პრინციპით მუშაობს ასეთი ფაილები.

📰 საინტერესო ფაქტი:

ე.წ. “მატრიოშკა” არის რუსული სათამაშო. მოცემულია ხუთი სხვადასხვა ზომის ერთნაირი ფიგურა და ისინი ერთმანეთში ლაგდებიან. სწორედ ასეთი პრინციპი შეიძლება ჰქონდეს ვირუსს. მთავარი იმპლანტი დროპერშივე შეიძლება იყოს დაენკოდებული/დაშიფრული.

Dropper                                   Extracted Mutant as a file 
┌───────────────────────────────────┐     ┌─────────────────────────┐
│                                   │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
│Mutant            Mutant Extractor │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
│┌─────────────┐   ┌──────────────┐ │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
││xxxxxxxxxxxxx│   │              ├─┼────►│xxxxxxxxxxxxxxxxxxxxxxxxx│
││xxxxxxxxxxxxx│   └──────▲───────┘ │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
││xxxxxxxxxxxxx│   ┌──────┴───────┐ │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
││xxxxxxxxxxxxx┼───►              │ │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
│└─────────────┘   └──────────────┘ │     │xxxxxxxxxxxxxxxxxxxxxxxxx│
│                  Decoder/Decryptor│     │xxxxxxxxxxxxxxxxxxxxxxxxx│
└───────────────────────────────────┘     └─────────────────────────┘

რა თქმა უნდა, შესაძლებელია უფრო მეტი რაღაცის დამატება დროპერში და ზოგადად ეს ასეცაა ხოლმე, მაგრამ სიმარტივისთვის აღარ დავამატე გრაფაში ვირუსის შესაძლო დამატებითი უნარ-ჩვევები.

ამ შემთხვევაში, “მატრიოშკას” მუტანტი და დროპერი განასახიერებენ.

1. შესაძლებელია Malware დეველოპერმა შემთხვევითობის პრინციპით შეტენა ფაილს რესურსებში დამატებითი ფაილები მხოლოდ იმიტომ, რომ ანტივირუსს მისი სტატიკური ანალიზი ვერ შეძლებოდა.

მაგალითად, NTFS ფაილურ სისტემაში(File System) შესაძლებელია რამდენიმე ე.წ. Data Stream-ის ქონა. აქედან გამომდინარე, მეორე ნაკადში შესაძლებელია მუტანტის/იმპლანტის ჩადგმა ან თუნდაც ამ ნაკადების უაზრო ფაილებით ამოვსება, რათა ანტივირუსს ამ კონკრეტული ფაილის ანალიზი გაუჭირდეს.

მაგალითად, არსებობს main ნაკადი, რომელიც თვითონ ფაილს შეიცავს. მაგრამ ასევე შესაძლებელია სხვა ნაკადების დამატება, რომელთა დანახვა ძალიან რთული შეიძლება იყოს და დამწყებ “რევერს ინჟინერს”/”Malware ანალიტიკოსს” შესაძლოა გამორჩეს კიდეც მათში მოთავსებული მონაცემები(ფაილები).

აქ მოცემულია სექციების ზომები. როგორც ჩანს, .text სექცია ყველაზე დიდია. მაგრამ ასევე საკმაოდ დიდია .rdata და .rsrc სექციები. .rsrc სექცია ზოგადად დამატებით რესურსებს შეიცავს, როგორიც შეიძლება იყოს icon ან რამე მსგავსი. იდეაში, ნებისმიერი რამის მოთავსება შეიძლება ამ სექციაში, ისევე როგორც ყველა სხვა სექციაში. .rdata სექცია არის read-only data, სადაც ასევე შეიძლება მოთავსდეს იმპლანტი. შესაძლებელი იქნება მისი ბაიტების ამოკითხვა და სხვა ფაილში ჩაწერა.

თვითონ .text სექცია ASM ინსტრუქციებს შეიცავს.

ეს ტექსტი მაეჭვებს, რომ ვირუსი ქსელში გადის. იმიტომ, რომ SSL ხშირადაა ნახსენები. SSL(Secure Socket Layer) კავშირის შიფრაციისათვის გამოიყენება.

მაგალითად, შესაძლებელია OpenSSL ბიბლიოთეკით სოკეტზე SSL ტუნელის გატარება, რაც სოკეტზე გამავალ ინფორმაციას დაშიფრავს. წესით, ამან საქმე ბევრად უნდა გაართულოს იმ შემთხვევაში თუ SSL სერტიფიკატი ვირუსშივე არაა ჩაქსოვილი. წინააღმდეგ შემთხვევაში, სერტიფიკატითვე გავშიფრავ ტრაფიკს დინამიური ანალიზის დროს.

Assembly იცი???

კი, რა თქმა უნდა ვიცი. ეს მაძლევს იმის შესაძლებლობას, რომ კარგი Malware დავწერო და სხვისი დაწერილი ნებისმიერი კოდი გავაანალიზო კიდეც.

ამ სურათში ვხედავთ, რომ ESP რეგისტრატორს გამოაკლდა 0x2d4, რათა ლოკალური ცვლადებისათვის გამოიყოს ადგილი სტაკზე. შემდეგ, სტაკზე შეგვაქვს ebx, esi, edi რეგისტრატორების მნიშვნელობები და ასევე 0x20. ამ შემთხვევაში, ebx დაიკავებს arg2-ის მნიშვნელობას. ეს arg2 ამ ფუნქციას დეკლარაციაშივე აქვს გაწერილი:

int32_t arg1, int32_t arg2

პირველ არგუმენტს eax რეგისტრატორი შეინახავს, ხოლო მეორეს ebx. ეს იქიდან გამომდინარე, რომ General Purpose რეგისტრატორები ასე იწყობა:

1. ax
2. bx
3. cx
4. dx

ხოლო იმის გამო, რომ 16 ბიტიანი სისტემიდან საზოგადოება ჯერ 32, შემდეგ კი 64 ბიტიან სისტემებზე გადავიდა, შეიცვალა რეგისტრატორების სახელებიც:

1. eax
2. ebx
3. ecx
4. edx

ეს, რა თქმა უნდა, 32 ბიტიან სისტემებზე.

ამ ფოტოში ტექსტიცაა მოცემული: Error writing temporary file. Make sure your temp folder is valid.

როდესაც KERNEL32.dll ფაილიდან SetErrorMode ფუნქცია მორჩება, პირდაპირ მეორე ფუნქცია იწყებს მოქმედებას, რომელიც არის GetVerson.

ეს ფუნქცია საკმაოდ უცნაურია და ყურადღების გამახვილებაა საჭირო. GetVersion(); აბრუნებს DWORD-ს, რომელიც ნიშნავს Double Word-ს. ეს არის 32 ბაიტი.

ფორმატი არის ასეთი:

0x00000000

პირველი 4 სიმბოლო წარმოადგენს ე.წ. Build number-ს. მის შემდეგ ორი სიმბოლო წარმოადგენს სისტემის მინორულ ვერსიას, ხოლო ბოლო ორი სიმბოლო აჩვენებს სისტემის მაჟორულ ვერსიას. მაგალითად:

Windows Version: 10.0 (Build 19045)

ამ შემთხვევაში, მაჟორული ვერსიაა 10, მინორული ვერსიაა 0, ხოლო Build Number არის 19045.

აქ მოცემულია ეს ინსტრუქცია:

and eax, 0xbfffffff

რომელიც პირველ არგუმენტსა და 0xbfffffff მნიშვნელობას შორის ჩაატარებს and ოპერაციას. ეს შესაძლოა რამდენიმე რაღაცის გამო მოხდეს. შესაძლოა დეველოპერს eax-ის მნიშვნელობაში კონკრეტული ბიტების განულება სურს. რა თქმა უნდა, ამას მოყვება სხვადასხვა სახის ეფექტი. მოკლედ რომ ვთქვა, ეს ინსტრუქცია eax-ის მნიშვნელობით მანიპულირებს.

მის შემდეგ არის

cmp ax, 6

ინსტრუქცია, რომელიც eax-ის ქვედა 16 ბიტს შეადარებს 6-ს. მომდევნო რამდენიმე ინსტრუქციის მიხედვით თუ ეს დებულება შესრულდება, მაშინ EIP რეგისტრატორის მნიშვნელობა გახდება 0x4033df რაც ნიშნავს იმას, რომ CPU ამ მეხსიერების მისამართიდან განაგრძობს ინსტრუქციების შესრულებას: 0x4033df.

თუ ეს ყველაფერი მოხერხდა, მაშინ 0x00406624 მეხსიერების მისამართზე მყოფი ფუნქცია ამოქმედდება. თუ ეს არ მოხდა, მაშინ ebx-ის მნიშვნელობა შევა სტაკზე, შემდეგ ამოქმედდება ფუნქცია, რომელიც არის 0x00406694 მეხსიერების მისამართზე მდებარეობს.