# Là 1937CN hay OceanLotus hay Lazarus … **[tradahacking.vn/là-1937cn-hay-oceanlotus-hay-lazarus-6ca15fe1b241](https://tradahacking.vn/l%C3%A0-1937cn-hay-oceanlotus-hay-lazarus-6ca15fe1b241)** m4n0w4r November 3, 2018 [m4n0w4r](https://kienbigmummy.medium.com/?source=post_page-----6ca15fe1b241--------------------------------) [Follow](https://medium.com/m/signin?actionUrl=https%3A%2F%2Fmedium.com%2F_%2Fsubscribe%2Fuser%2F3d670b41fa5f&operation=register&redirect=https%3A%2F%2Ftradahacking.vn%2Fl%C3%A0-1937cn-hay-oceanlotus-hay-lazarus-6ca15fe1b241&user=m4n0w4r&userId=3d670b41fa5f&source=post_page-3d670b41fa5f----6ca15fe1b241---------------------follow_byline-----------) Nov 3, 2018 15 min read ----- Vô tình bắt gặp trên twitter của @blu3_team (), 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-officialsacb3b9d8b80a, 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à](https://remnux.org/) 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.exe và dllhst3g.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:](https://github.com/Rurik/Noriben) ## 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:](https://github.com/decalage2/oletools) ----- 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 Temo. 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).](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à (IFEO: [https://blogs.msdn.microsoft.com/mithuns/2010/03/24/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_ _Options và HKLM\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, 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 để lấy kích thước của 8.t: Sau đó, gọi hàm để 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 đượ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 : 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 để cấp phát một vùng nhớ khác tại địa chỉ : PE được giải mã tại vùng nhớ 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ụ của [(https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper) để chuyển đổi từ](https://github.com/hasherezade/pe_recovery_tools/tree/master/pe_unmapper) virtual format về định dạng raw: ----- Debug tiếp, shellcode gọi hàm được gọi để lấy đường dẫn của EQNEDT32.exe: ----- Sử dụng (CreateProcessInternalA) để tạo một process EQNEDT32.exe khác ở trạng thái . 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, ta sẽ có được kết quả đúng như hình:_ Đoạn code tiếp theo sẽ lấy thread context bằng, đọc dữ liệu từ vùng nhớ với hàm, gọi (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ỉ : ----- Thực hiện đặt lại thread context bằng, cuối cùng shellcode thực hiện hàm để 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: vào thư mục %AppData%\Microsoft\Windows\Printer Shortcuts. Ở trên tôi có 2 file đã dump là và . Tuy nhiên, chỉ có file là thực thi được bình thường, còn file 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 như sau: “dumped samples may not always work, so it is normal”). Mở IDA và load file (đổi tên lại từ file .mem), dừng lại tại : ----- 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 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 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 vào thư mục: Kết quả sau khi thực hiện hàm đầu tiên, có được file : Đây là một file hợp lệ, có chữ kí và được phát triển bởi hãng : ----- Lời gọi hàm thứ 2 sẽ drop ra file, 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 thứ 3 sẽ drop ra file stdole.tlb. Thông tin về có thể xem tại đây [(https://docs.microsoft.com/en-us/windows/desktop/midl/com-dcom-and-type-libraries):](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 để thực thi với tham số là ”: Như vậy, với việc thực thi thành công, QcConsol.exe chắc chắn sẽ phải load 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, sử dụng API và sau đó gọi để 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ừ : ## 7. Phân tích sơ bộ file QcLite.dll Gọi hàm để cấp phát một vùng nhớ: Lấy đường dẫn đầy đủ tới : Dll này sẽ load file : Gọi hàm để mở file này ( trỏ tới stdole.tlb): Lấy kích thước của : Đọc dữ liệu từ 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 để decode toàn bộ dữ liệu của đã đượ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 tại 4 bytes đầu ; sau đó nhấn F9 là tới):_ Shellcode tại sẽ truy cập để lấy ra địa chỉ base address của : ----- Sau khi có được base address của, shellcode sẽ tìm địa chỉ của hàm API : Với hàm API, shellcode sẽ lấy địa chỉ của các hàm API khác là,,, : ----- Sử dụng hàm để cấp phát một vùng nhớ và gọi hàm để decode bytes trong shellcode vào vùng nhớ cấp phát: Tiếp tục sử dụng để 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 () và thiết lập vùng nhớ mới này là : ----- Sau khi lấy được section header tại vùng nhớ ở 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 để tạo một thread mới: Đi tới ThreadFunction tại địa chỉ . Code tại đây thực hiện lấy thông tin binary có sẵn của Windows là : ----- 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 : Gọi hàm để ghi string vào file tại “”: Thiết lập thuộc tính cho file với hàm : 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,,, để một lần nữa đọc ra nội dung được lưu trong file 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 để khởi động tiến trình ở trạng thái : Cấp phát vùng nhớ trong tiến trình này thông qua hàm : Gọi hàm để ghi dữ liệu từ (buffer chứa data đã decode của stdole.tlb) vào vùng nhớ đã cấp phát tại tiến trình, đặt lại thread context và resume thread. Lúc này 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 sẽ gọi để kết thúc tiến trình và tiếp tục thực thi tiến trình . Do 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 sẽ làm gì thì trước khi thực hiện bước ở trên, sửa 2 bytes đầu là _thành . 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 “” 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” -” và gọi_ hàm để thực thi Tiến trình mới này sẽ kết nối tới C2 (): 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 -----