Posts Tagged ‘Security’


Mới đây, một người bạn nước ngoài thông báo cho tôi về sample có nội dung từ “Bộ Công Thương” gửi tới “Tập đoàn Dầu khí Việt Nam” như sau:

Bạn còn nhắn tôi : “APT có vẻ thích Việt Nam nhỉ!!” …Tôi không biết là mình nên vui hay nên buồn 😀

1. Stage 1 — Phân tích sơ bộ

Kiểm tra sơ bộ thấy sample này có chứa mã VBA, nhắm vào người sử dụng Office 2007+:

Nội dung của VBA code như sau:

VBA code thực hiện nhiệm vụ giải mã chuỗi Base64, sau đó tạo file Chrome.jstại thư mục C:\Windows\Tasks và lưu nội dung đã giải mã vào file này. Kiểm tra tiếp thông tin metadata liên quan:

Như vậy, VBA code sẽ tạo schedule task để thực thi file Chrome.js.

2. Stage 2 — Giải mã chuỗi Base64

Có thể dùng VBA Editor của Word để debug và có được nội dung của chuỗi Base64. Tuy nhiên, khi đọc code thấy chuỗi Base64 này sẽ được giải mã 3 lần, thông qua CyberChef tôi có thể giải mã được mà không cần phải debug:

Toàn bộ nội dung sẽ lưu vào Chrome.js sau khi giải mã:

3. Stage 3 — Giải mã JS

Chrome.js sẽ giải mã chuỗi base64 được lưu tại biến “c”, sau đó sẽ thực thi kết quả sau giải mã. Ta có nội dung giải mã của chuỗi Base64 trên như hình:

Ta có được một powershell script với nội dung như sau:

4. Stage 4 — Phân tích Powershell

Tại thời điểm phân tích tôi vẫn kết nối được tới C2:

Powershell sẽ kết nối tới C2 tại hxxp://154[.]16[.]37[.]122/GoogleUpdate/Update.php để đọc nội dung command từ Update.php vào biến $Cmd.

Nội dung của Update.php như sau:

Sử dụng wmic để lấy uuid và encode uuid này thành một chuỗi Base64:

Cuối cùng cấu thành một Uri có chứa chuỗi uuid đã encode và kết nối tới uri này:

Tới đây, tôi không thấy có thêm thông tin gì khác, cảm giác như kẻ tấn công chỉ muốn thăm dò xem người dùng có mở tài liệu này hay không để chuẩn bị cho một đợt tấn công khác!

5. IoCs

– Doc file: b22d7b196ca03b43f9b140732a3d317f328e5d5f53379c2520a0f05a17d6e617

– C2: hxxp://154[.]16[.]37[.]122

– Scheduled tasks: schtasks /create /sc MINUTE /tn “Chrome” /tr “C:\Windows\Tasks\Chrome.js” /mo 2 /F & schtasks /create /sc MINUTE /tn “Chrome” /tr “C:\Windows\Tasks\Chrome.js” /mo 2 /RU SYSTEM

Advertisements

Nhờ người em hỗ trợ, tôi có được một sample mới c580d77722d85238ed76689a17b0205b4d980c010bef9616b8611ffba21b142e sử dụng CVE-2017–11882. Sample này có thay đổi chút về OLE object, init_key để decrypt binary, cũng như các dropped binary so với mẫu tôi đã viết tại đây https://kienmanowar.wordpress.com/2018/11/08/la-1937cn-hay-oceanlotus-hay-lazarus/

1. Stage 1 — Phân tích sơ bộ

Kiểm tra thấy đây là một file RTF:

Sử dụng rtfobj để xem có các embedded objects không, thấy có 4 objects:

Thông qua Profiler, có được thông tin sau:

CVE-2017–11882 Signature
Embedded file

Mở file bằng ứng dụng Word không thấy có nội dung gì (theo đánh giá cá nhân, tụi này làm mẫu không bằng các mẫu nhắm vào VN, không viết nổi một nội dung cho tử tế 😀). Nó sẽ drop file e.m vào thư mục Temp . File này sẽ có nội dung như trên hình:

2. Stage 2 — Lấy binary được giải mã

Với sample này, tôi không áp dụng được dụng tính năng Image File Execution Options (IFEO) nên tôi dùng HxD để patch Entry Point của EQNEDT32.exethành 0xEB 0xEF.

Sau đó mở file bằng ứng dụng Word, dùng OllyDBG tiến hành attach tiến trình EQNEDT32.exe. Sau khi attach xong khôi phục lại các bytes gốc đã patch bằng HxD. Đặt một bp tại CreatFileW:

Thông qua shellcode gọi hàm VirtualAlloc để cấp phát vùng nhớ phục vụ cho việc lưu nội dung của file e.m:

Tiếp theo gọi hàm ReadFile để đọc nội dung từ e.m và lưu vào vùng nhớ ở trên:

Dùng vòng lặp xor để giải mã dữ liệu tại vùng nhớ trên (thuật toán tương tự như bài viết https://kienmanowar.wordpress.com/2018/11/08/la-1937cn-hay-oceanlotus-hay-lazarus/ , chỉ khác init_key):

Sau vòng lặp trên có được một PE file mới như sau:

Dump vùng nhớ này ra đĩa để phân tích:

3. Stage 3 — Phân tích binary đã dump

Load binary ở trên vào IDA, nó thực hiện tạo thư mục có tên IISWebClient tại %appdata%:

Thực hiện giải mã một buffer:

Sau đó copy toàn bộ các bytes đã giải mã ở trên vào vùng nhớ đã được cấp phát:

Tạo một key là “Direct3D” tại HKEY_CURRENT_USER\Software & lưu toàn bộ decrypted bytes:

Tiếp theo, drop 3 files vào thư mục IISWebClient đã tạo ở trên:

· iassvcs.exe (signed by Symantec).

· sqlite3.dll (signed by Qihoo 360).

· RasTls.dll (signed by Avira — not valid cert).

Thông tin Digital Signatures của các files:

Tạo persistence key để tự động chạy tại “Software\Microsoft\windows NT\CurrentVersion\windows”:

Sau khi tạo key trong Registry xong, thực thi file iassvcs.exe, file này sẽ load các đã drop cùng thư mục:

Binary cuối cùng được lưu thành file 189AFE4.TMP:

Tiến trình iassvcs.exe sau khi thực thi sẽ kết nối tới C2 tại:

4. IOCs

· Malicious RTF:c580d77722d85238ed76689a17b0205b4d980c010bef9616b8611ffba21b142e

· Decrypted binary: 8D7425AE30FD2D5196EC4DCD2540B31A0D26772F

· Dropped binary:

o %appdata%\IISWebClient\iassvcs.exe: 62944E26B36B1DCACE429AE26BA66164

o %appdata%\IISWebClient\sqlite3.dll: FEE0B982AF421FF8C16C0187B376B086

o %appdata%\IISWebClient\RasTls.dll: C6A73E29C770065B4911EF46285D6557

· C2:

o Name: skylineqaz[.]crabdance[.]com

o Name: xn — ylineqaz-y25ja[.]crabdance[.]com

· Registry:

o “HKCU\Software\Microsoft\windows NT\CurrentVersion\windows”; Value name “Load”; Data: C:\Users\{username}\AppData\Roaming\IISWEB~1\iassvcs.exe

o “HKEY_CURRENT_USER\Software\Direct3D”


Hôm nay, tình cờ lướt twitter của @DissectMalware, tôi có đọc được một mẹo nhỏ hỗ trợ để lấy được toàn bộ malicious script.

Link sample: hxxps://www.hybrid-analysis.com/sample/4991e2bf6c1384c9077366f9bebf159001e5ba922e9b615cf8a331c69efab586?environmentId=120

Thông qua HxD biết được đây là OLE Compound File:

Dùng olevba (https://github.com/decalage2/oletools) có được thông tin về VBA code:

Thường thì các bạn hay gặp các samples sử dụng Document_Open() hay AutoOpen() để tự động thực thi VBA khi người dùng mở tài liệu (chính xác hơn là sau khi nhấn nút Enable Content). Còn ở sample này, nó sử dụng AutoClose() để khi người dùng đóng tài liệu thì VBA code sẽ được thực thi.

Khi parse sample bằng olevba, công cụ có highlight đoạn code liên quan đến thực thi Shell như trên hình. Tiến hành debug VBA code và đặt breakpoint tại chỗ Shell này ta sẽ thấy mal_doc gọi cmd.exe để thực thi một đoạn powershell script:

Như các bạn đã biết, khi debug thì hạn chế của tính năng Watch trong trình debugger sẽ không hỗ trợ ta xem và lấy được toàn bộ nội dung của một chuỗi dài như trên hình.

Còn nếu dùng Process Hacker thì phải thật “nhanh tay” mới lấy được toàn bộ nội dung của Powershell như sau:

Tuy nhiên, có một cách khá hay được @DissectMalware chia sẻ nhằm giúp ta lấy được nội dung của toàn bộ script, đó là sử dụng ActiveDocument.Content.InsertAfter để ghi toàn bộ đoạn text ra chính tài liệu. Bổ sung đoạn code này vào trước lệnh Shell như sau:

Sau khi trace qua ta sẽ có được toàn bộ nội dung của script được ghi ra tài liệu như sau:

Decode chuỗi Base64 trên ta có được nội dung của script thực hiện nhiệm vụ download một PE file từ C2 về máy nạn nhân để thực thi:

….

Cập nhật:

Ngoài cách trên, có thể áp dụng cách của anh TQN là sử dụng lệnh Debug.Print. Bổ sung đoạn code sau vào trước lệnh Shell:

Thực hiện Debug, trace qua lệnh và quan sát cửa sổ Immediate, ta sẽ có được nội dụng của toàn bộ script:

End.

m4n0w4r


1. Tìm VBA code

Hôm rồi, một người bạn bên ARTeam có gửi cho tôi một sample, có vẻ lại nhắm vào ai đó tại VN:

Sample này có dạng MIME :

Mở bằng Notepad++ và tìm dòng “Content-Location”, tôi có được thông tin sau:

Thực hiện decode toàn bộ nội dung base64 ở trên có được thông tin về OLE file:

OLE file

Parse ole file có được thông tin về VBA code:

VBA code

2. Nhiệm vụ của VBA code

Khi tài liệu được mở, lấy đường dẫn tới thư mục temp (%temp%):

Tạo file msohtml.log trong thư mục temp, tiến hành decode base64 data:

Nội dung sau khi decode được lưu vào file msohtml.log:

Như trên hình, đây là một mảng các giá trị decimal, qua một vòng lặp thực hiện xor với key là 372 để decode và thực thi lệnh. Tôi sẽ decode sau!

Quay trở lại với VBA code, nó thực hiện copy wscript.exe thành msohtml.exe vào thư mục temp (cùng chỗ với msohtml.log):

Tạo một Schedule Task với tên là WindowsMediaUpdates và Action là explorer.exe shell:::{giá trị CLSID đã tạo ở trên}.

Tạo Registry key với CLSID đã tạo ở trên, ví dụ: “HKCU\Software\Classes\CLSID\{93A61ECC-2527–498C-B94A-5CAA00284A5A}\Shell\Manage\Command\”.

Tóm lại, VBA code sẽ thực hiện drop một script lưu tại file msohtml.log, nhân bản wscript.exe thành msohtml.exe. Xậy dựng command trong Registry với CLSID ngẫu nhiên và tạo một schedule task với tên là WindowsMediaUpdates để thực hiện command.

3. Nhiệm vụ của msohtml.log

Thực hiện decode nội dung của msohtml.log bằng Reneo (www.kahusecurity.com/tools.html) sẽ có được nội dụng của script:

Trong script decode được ở trên lại có một đoạn code như sau:

Tiếp tục decode sẽ có được kết quả:

Như vậy, script khi thực hiện sẽ móc lên C2 để download một file có đuôi .gif: hxxps://beta[.]officopedia[.]com/dr/msg[.]gif. Tính tới thời điểm phân tích thì file này không còn tồn tại.

4. IOCs

File (ITW: Scan_Mau_Ao_Thun.doc): 5c41652ee19351f344243d2f10bc79b024db1183598df8e8474e0f4629f0a49a

Other script: msohtml.log

940FBAC34F7F2DB40617F3E0F68DC395CB9D8E71DE20788E1524FD35838AB5CF

Task Scheduler:

Name: WindowsMediaUpdates

Action: explorer.exe shell:::{random_CLSID}

Registry key:

“HKCU\Software\Classes\CLSID\{random_CLSID}\Shell\Manage\Command\”

C2:

hxxps://beta[.]officopedia[.]com


Vô tình bắt gặp trên twitter của @blu3_team (Tôi không rõ sao acc này lại rất hay có được những mẫu target vào VN), tôi tò mò muốn biết kĩ thuật đằng sau nó là gì bởi tôi thấy nó tương tự như một bài mà tôi đã đọc https://medium.com/@Sebdraven/malicious-document-targets-vietnamese-officials-acb3b9d8b80a, và vì xem comment, người nghi ngờ là OceanLotus, người khẳng định là 1937CN Team

Xin lỗi vì bài viết khá dài, tôi cũng không biết làm thế nào để cho nó ngắn hơn :D, nếu bạn không có thời gian để đọc hết thì bấm một like rồi chuyển trang khác. Phần tôi, một là do tôi thích viết, mặt khác cũng là cách tôi tự rèn kĩ năng … phần nữa là vì tôi biết rằng chỉ khi mình thực sự bắt tay vào phân tích mới thấy nó khác xa với những gì mình đọc bằng mắt và tưởng tượng….



1. Môi trường thực hiện

1. Máy ảo REMnux (https://remnux.org/): sử dụng để phân tích files, giả lập Internet services và capture network traffic.

2. Máy ảo Win10x64 (tự build): sử dụng cho Static & Dynamic Analysis

a. Cài đặt sẵn các cộng cụ debugger & disassembler: OllyDbg, x64dbg, IDA …

b. Cài đặt sẵn Office 2013.

c. Enable tải khoản Administrator (mặc định tài khoản này bị disable) và đăng nhập bằng tải khoản này để thực hiện phân tích.

2. Phân tích theo hành vi

Khi mở tài liệu trên máy ảo Win10, sẽ thấy ứng dụng EQNEDT32.exe được gọi, sau đó xuất hiện thêm hai tiến trình khác là QcConsol.exedllhst3g.exe:


Trên máy ảo REMnux chạy Wireshark để capture traffic từ máy ảo Win10, thu được kết quả kết nối tới C2 server là login[dot]dangquanwatch[dot]com:

Log của Noriben (https://github.com/Rurik/Noriben) cung cấp:

3. Phân tích sample trên REMnux

Sample nhận được là một file có định dạng RTF:

Sử dụng rtfobj (https://github.com/decalage2/oletools), biết được sample này có 3 objects:


Object tại id 0 có FileName là 8.t, khi mở tài liệu thì file này sẽ được drop vào thư mục Temp trên máy. Hai object còn lại được nhận diện là “Not a well formed ole object”.

Dùng luôn rtfobj để dump toàn bộ các objects này:

Kiểm tra thông tin từng file. Đầu tiên là b45087ad4f7d84758046e9d6eb174530fee98b069105a78f124cbde1ecfb0415_8.t:

Theo data như trên hình thì khả năng file này đã bị mã hóa và sẽ được giải mã sau khi drop vào thự mục Temp.

Với file b45087ad4f7d84758046e9d6eb174530fee98b069105a78f124cbde1ecfb0415_object_000C11FB.raw:

Căn cứ vào dấu hiệu như trên hình thì khả năng file RTF có thể sẽ sử dụng exploit CVE-2017–11882 (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882).

Kiểm tra file còn lại là b45087ad4f7d84758046e9d6eb174530fee98b069105a78f124cbde1ecfb0415_object_000C11E9.raw:

File này khả năng sẽ chứa đoạn shellcode để thực hiện sau khi máy nạn nhân bị exploit. Thông tin sợ bộ là như vậy, tiếp theo ta sẽ thực hiện debug sample này để xem file 8.t được sử dụng như thế nào.

4. Debug maldoc trên Windows10

Liên quan tới exploit CVE-2017–11882, khi chạy sample, Winword.exe sẽ gọi tiến trình EQNEDT32.exe để handle OLE object. Tuy nhiên, Winword.exe không phải là process cha của EQNEDT32.exe, tiến trình EQNEDT32.exe được gọi bởi Winword.exe thông qua việc sử dụng COM Object như hình dưới đây:

Như vậy, bằng cách nào đó ta phải attach được EQNEDT32.exe vào debugger để debug. Ở đây, tôi sử dụng một kĩ thuật của M$ là Image File Execution Options (IFEO: https://blogs.msdn.microsoft.com/mithuns/2010/03/24/image-file-execution-options-ifeo/).

Vào Registry, tạo một key như sau hoặc nếu cài Word2013 trở lên thì khả năng có sẵn key này (vì tôi thấy trên máy tôi có sẵn):

Tiếp theo, tạo một string value để khởi chạy debugger khi EQNEDT32.exe được thực thi, qua đó sẽ attach đươc debugger vào tiến trình của EQNEDT32.exe.

Với thiết lập như trên, kiểm tra lại bằng Autoruns sẽ như sau:

Lưu ý: khi thiết lập IFEO, các thiết lập sẽ tự động bộ giữa hai key: HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution OptionsHKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Tiếp theo, mở WINWORD.EXE, sau đó từ Winword mở tài liệu malicious rtf. Lúc này, tiến trình EQNEDT32.exe cũng sẽ được khởi chạy và được attach vào debugger:

Tại debugger, ta đang dừng lại tại EP(Entry Point) của EQNEDT32.exe:

Kiểm tra ta thấy file 8.t đã được drop vào thư mục Temp:

Đặt BP tại API CreatFileW, sau đó nhấn F9 để thực thi, ta thấy chương trình sẽ thực hiện mở file 8.t để đọc nội dung:

Trace qua hàm này và return, sẽ tới shellcode của exploit:

Gọi hàm GetFileSize để lấy kích thước của 8.t:

Sau đó, gọi hàm VirtualAlloc để thực hiện cấp phát một vùng nhớ:

Vùng nhớ được cấp phát trỏ bởi thanh ghi EAX, follow theo vùng nhớ này để xem code sẽ tác động gì lên nó:

Hàm ReadFile được gọi để đọc ra nội dung của 8.t:

Toàn bộ nội dung của 8.t được đọc vào vùng nhớ đã được cấp phát ở trên:

Tiếp tục trace sẽ tới đoạn shellcode thực hiện giải mã toàn bộ nội dung của file 8.t trong memory tại 0x4F70000:

Sau vài lần trace code sẽ thấy được dấu hiệu MZ, nhưng vậy file 8.t sau khi giải mà sẽ là một PE file:

Cho thực hiện xong toàn bộ vòng lặp giải mã trên sẽ có được một PE hoàn chỉnh trong bộ nhớ:

Dump PE mới này và lưu lại để thực hiện phân tích sau:

File dump được là một exe file:

Tiếp tục debug, shellcode gọi tiếp hàm VirtualAlloc để cấp phát một vùng nhớ khác tại địa chỉ 0x5170000:

PE được giải mã tại vùng nhớ 0x4F70000 sẽ được copy vào vùng nhớ mới được cấp phát ở trên:

Dump vùng mem trên ra bộ nhớ, và vì file này đã được mapping trên memory và có thay đổi, nên sử dụng cộng cụ pe_unmapper của hasherezade (https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper) để chuyển đổi từ virtual format về định dạng raw:

Debug tiếp, shellcode gọi hàm GetModuleFileNameA được gọi để lấy đường dẫn của EQNEDT32.exe:

Sử dụng CreateProcessA (CreateProcessInternalA) để tạo một process EQNEDT32.exe khác ở trạng thái Suspended. Do đang thiết lập tính năng IFEO nên ta sẽ thấy process của debugger thay vì là process EQNEDT32.exe:

Note: Nếu thực hiện lại, tới bước này thì sử dụng Autoruns để bỏ việc sử dụng IFEO và cho thực hiện hàm CreateProcessA, ta sẽ có được kết quả đúng như hình:

Đoạn code tiếp theo sẽ lấy thread context bằng GetThreadContext, đọc dữ liệu từ vùng nhớ với hàm ReadProcessMemory, gọi VirtualProtectEx (PAGE_EXECUTE_READWRITE 0x40) để thay đổi trang thái của vùng nhớ trên Suspend process, và cuối cùng shellcode ghi đè lên bằng PE tại địa chỉ 0x5170000:

Thực hiện đặt lại thread context bằng SetThreadContext, cuối cùng shellcode thực hiện hàm ResumeThread để launch PE mới:

Tổng kết lại, toàn bộ quá trình thực hiện của shellcode là giải mã file 8.t thành một PE mới, sau đó thực hiện nhân bản sang một vùng nhớ khác, thực hiện tạo một fork process mới là EQNEDT32.exe, cuối cùng áp dụng kĩ thuật runPE để launch EQNEDT32.exe mới đã bị ghi đè code bởi nội dung của file 8.t.

5. Phân tích binary đã dump

Như đã biết khi phân tích dynamic, sau khi resume thread thì malware sẽ drop ra disk các file sau: QcConsol.exe; QcLite.dll; stdole.tlb vào thư mục %AppData%\Microsoft\Windows\Printer Shortcuts.

Ở trên tôi có 2 file đã dump là _04F70000.memdrop_bin.exe (được unmap bằng công cụ pe_unmapper). Tuy nhiên, chỉ có file _04F70000.mem là thực thi được bình thường, còn file drop_bin.exe thì bị crash (mặc dù lúc fix, kiểm tra bằng PE bear thấy mọi thứ đều ok. Tôi có chat hỏi về vấn đề này thì nhận được trả lời của hasherezade như sau: “dumped samples may not always work, so it is normal”).

Mở IDA và load file _04F70000.exe (đổi tên lại từ file .mem), dừng lại tại WinMain():

Binary lấy đường dẫn tới thư mục %AppData%\Microsoft\Windows\Printer Shortcuts:

Cấu thành đường dẫn của các file:

Tới đoạn code thực hiện call sub_331860 3 lần để thực hiện drop các file trên vào thư mục chỉ định. Tôi đổi tên sub này thành thành drop_file như hình:

Đi sâu vào hàm này sẽ gặp vòng lặp xor thực hiện decode bytes, sau đó là đoạn code thực hiện WriteFile vào thư mục:

Kết quả sau khi thực hiện hàm drop_file đầu tiên, có được file QcConsol.exe:

Đây là một file hợp lệ, có chữ kí và được phát triển bởi hãng McAfee, Inc.:

Lời gọi hàm drop_file thứ 2 sẽ drop ra file QcLite.dll, file này không có thông tin gì về Signature cũng như info, như vậy malicious code sẽ nằm ở file này:

Lời gọi hàm drop_file thứ 3 sẽ drop ra file stdole.tlb. Thông tin về .tlb có thể xem tại đây (https://docs.microsoft.com/en-us/windows/desktop/midl/com-dcom-and-type-libraries):

Tiếp tục, cấu thành một command như sau:

Cuối cùng, gọi hàm WinExec để thực thi QcConsol.exe với tham số là “-LowIntegrityServer”:

Như vậy, với việc thực thi thành công, QcConsol.exe chắc chắn sẽ phải load QcLite.dll vào để thưc thi malicious code.

6. DLL hijacking — Phân tích file QcConsol.exe

Load file vào IDA nhận được thông báo:

Để nạp được QcLite.dll, QcConsol.exe sử dụng API LoadLibraryW và sau đó gọi GetProcAddress để lấy địa chỉ của hàm. Về bản chất khi thực hiện nạp module thì đồng thời code của dll cũng sẽ được thực hiện bắt đầu từ DllMain:

7. Phân tích sơ bộ file QcLite.dll

Gọi hàm VirtualAlloc để cấp phát một vùng nhớ:

Lấy đường dẫn đầy đủ tới QcLite.dll:

Dll này sẽ load file .tlb:

Gọi hàm CreatFileW để mở file này (lpFileName trỏ tới stdole.tlb):

Lấy kích thước của stdole.tlb:

Đọc dữ liệu từ stdole.tlb và lưu vào vùng nhớ đã cấp phát ở trên:

Thực hiện vòng lặp sử dụng xor để decode toàn bộ dữ liệu của stdole.tlb đã được copy lên memory:

Kết quả có được sau khi decode, nghi ngờ khả năng đây có thể sẽ là một PE file khác:

Qua rất nhiều rop_chain (tôi đoán thế :D) thì sẽ nhảy tới vùng nhớ trên để thực thi code (Cách nhanh nhất thì các bạn có thể đặt một HWBP on Execute tại 4 bytes đầu 0x50 0x68 0xA7 0x45; sau đó nhấn F9 là tới):

Shellcode tại 0x01A10000 sẽ truy cập PEB (Process Environment Block) để lấy ra địa chỉ base address của kernel32.dll:

Sau khi có được base address của kernel32.dll, shellcode sẽ tìm địa chỉ của hàm API GetProcAddress:

Với hàm API GetProcAddress, shellcode sẽ lấy địa chỉ của các hàm API khác là LoadLibraryA, VirtualAlloc, FreeLibraryA, Sleep:

Sử dụng hàm VirtualAlloc để cấp phát một vùng nhớ và gọi hàm decode_data() để decode bytes trong shellcode vào vùng nhớ cấp phát:

Tiếp tục sử dụng VirtualAlloc để cấp phát thêm một vùng nhớ khác với kích thước lấy từ vùng nhớ trên (dwSize = SizeOfImage = PE_header + 0x50) và thiết lập vùng nhớ mới này là PAGE_EXECUTE_READWRITE:

Sau khi lấy được section header tại vùng nhớ 0x01880000 ở trên, thực hiện vòng lặp để copy toàn bộ các section data sang vùng nhớ mới được cấp phát:

Tiến hành resolve toàn bộ địa chỉ API ghi lại vào IAT của vùng nhớ mới:

Sau khi lấy địa chỉ của toàn bộ các API cần thiết, sử dụng lệnh call để nhảy tới vùng nhớ để thực hiện lệnh:

Tiếp tục debug xuyên qua nhiều lớp call sẽ tới đoạn gọi hàm CreateThread để tạo một thread mới:

Đi tới ThreadFunction tại địa chỉ 0x01EE35D0. Code tại đây thực hiện lấy thông tin binary có sẵn của Windows là dllhst3g.exe:

Xem tổng quan code thì thấy có đoạn code liên quan đến C2 (login[dot]dangquanwatch[dot]com):

Tạo một thread khác làm nhiệm vụ tạo Persistent trong Registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run:

Gọi hàm WritePrivateProfileStringW để ghi string vào file tại “C:\ProgramData\desktop.ini”:

Thiết lập thuộc tính cho file với hàm SetFileAttributesW:

Tạo một Mutex {986AFDE7-F299–4A7D-BBF4-CA756FC01F1B65027208}, tuy nhiên handle tới mutext này sẽ bị đóng ngay sau đó:

Tiếp tục sử dụng bộ API CreateFileW, GetFileSize, VirtualAlloc, ReadFile để một lần nữa đọc ra nội dung được lưu trong file %AppData%\Microsoft\Windows\Printer Shortcuts\stdole.tlb và thực hiện decode dữ liệu giống như đã nói ở bước trước:

Thực hiện kĩ thuật inject code bằng cách gọi hàm CreateProcessW để khởi động tiến trình dllhst3g.exe ở trạng thái Suspended:

Cấp phát vùng nhớ trong tiến trình này thông qua hàm VirtualAllocEx:

Gọi hàm WriteProcessMemory để ghi dữ liệu từ 0x00F90000 (buffer chứa data đã decode của stdole.tlb) vào vùng nhớ đã cấp phát tại tiến trình dllhst3g.exe, đặt lại thread context và resume thread. Lúc này dllhst3g.exe sẽ thực thi bình thường và thực thi luôn malicious code:

8. Debug dllhst3g.exe

Hoàn thành xong việc inject code vào dllhst3g.exe sẽ gọi ExitProcess để kết thúc tiến trình QcConsol.exe và tiếp tục thực thi tiến trình dllhst3g.exe. Do dllhst3g.exe bị inject code của file stdole.tlb sau khi decode trên bộ nhớ, nên cách thức hoạt động cũng tương tự. Để có thể debug xem dllhst3g.exe sẽ làm gì thì trước khi thực hiện bước WriteProcessMemory ở trên, sửa 2 bytes đầu là 0x50 0x68 thành 0xEB 0xFE. Sau khi resume thread, mở một debugger khác để attach và khôi phục lại 2 bytes đã bị sửa.

Lúc này, debug sẽ thấy code tạo một mutext và đọc lại nội dung từ file “C:\ProgramData\desktop.ini” và decode string trong file này thành:

Gắn thêm tham số: 0206F4E4 00D80B30 UNICODE “”C:\Users\REM\AppData\Roaming\Microsoft\Windows\Printer Shortcuts\QcConsol.exe” –LowIntegrityServer và gọi hàm WinExec để thực thi

Tiến trình mới này sẽ kết nối tới C2 (Ở đây tôi đang lái traffic về REMnux):

Tại máy REMnux, sử dụng wireshark sẽ capture được thông tin như hình:

9. IOCs

Domain: login[dot]dangquanwatch[dot]com / IP: 185.77.129.142

RTF: b45087ad4f7d84758046e9d6eb174530fee98b069105a78f124cbde1ecfb0415

8.t: 6328dd14eda2ef983810c0c7b3af47298b5998e4fa52d97b204be2818f08bb69

Binary:

QcConsol.exe: 9f3114e48dd0245467fd184bb9655a5208fa7d13e2fe06514d1f3d61ce8b8770

QcLite.dll: 5b652205b1c248e5d5fc0eb5f53c5754df829ed2479687d4f14c2e08fbf87e76

Others:

stdole.tlb: ba620bad026f25ba6decc4bdcefc6415b563503cf9eaddc4e1137a5871d5cee2

desktop.ini: 31c2be9ca29fb2bd8096720c221ee9682f013eee119b02d390d6efc12684392d

Registry:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run & HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

ValueName: Windows HD Audio Manager

Data: %AppData%\MICROS~1\Windows\PRINTE~1\QcConsol.exe -LowIntegrityServer


Course Overview

CS-6V81 is a graduate level, research oriented, system and software security course.

The goal of this course is to explain the low-level system details from compiler, linker, loader, to OS kernel and computer architectures, examine the weakest link in each system component, explore the left bits and bytes after all these transformations, and study the state-of-the-art offenses and defenses.

The learning outcome is students shall be able to understand how an attack is launched (e.g., how an expoit is created), and how to do the defense (e.g., developing OS patches, analyzing the binary code, and detecting intrusions)

In particular, we will cover

  • Memory exploits. We will investigate the unsafe but widely used system programming language C, cover typical vulnerabilities such as buffer overflows, format strings, integer overflows, etc. How to create robust shell code using such as ROP, HeapSpray.
  • OS Kernel Internals. What’s the behavior when a program is running on top of OS. Why we use paging. How virtual to physical address translation is performed. How MMU (e.g., TLB) helps this. How OS manage files, and disks. How can we model the program behavior when sitting at OS layer. We will use both Linux and Windows as working kernel.
  • Linker and Loader Internals. How a program can be dynamically linked, and what an attacker can do to cheat the system and meanwhile what we can do to protect the system.
  • Kernel-level Defense, how can we defend against the common exploits, techniques including such as ASR, and DEP, NX-bits.
  • User-level Defense. Safe library, Compiler extension, Binary Transformation/Rewriting, Runtime Verification.
  • Binary code reverse engineering. Static binary code analysis. Dynamic Binary code instrumentation. Data flow analysis, and control flow analysis. Malware packing and unpacking.

The class will also have a heavy-hands on project. Students could choose either to perform research (will work on a semester-long research topic of their choosing), or perform an engineering project.

Link : http://www.utdallas.edu/~zhiqiang.lin/spring2012.html

Regards,

m4n0w4r