HTB – Red Failure

2024/04/01
  • 安全事件應變
  • 數位鑑識
    •

    First examine the pcap

    Trace the TCP/HTTP. “tcp.stream eq 1” looks like an obfuscated powershell

    “tcp.stream eq 2” looks like an execuable

    “tcp.stream eq 3” shows a traffic which can not understand

    So far we had an idea that:
    1. Requested to 147.182.172.189 and received a response with 4A7xH.ps1
    2. Requested to the same IP and received an executable user32.dll
    3. Requested to the same IP and received the response that we can not understand so far

    De-obfuscated the PS script

    leverage pwsh in Kali to retrieve the intelligence from the obfuscated powershell

    Then managed to carved out the suspicious 32bit executable

    Remove the response header then we can have the executable

    Feed the user32.dll to VT, and we can learned it is a trojan

    Reverse the .net executable

    Since it’s a .net assembly, we can decompiled it by dnspy. In the source code, there is a function “Decrypt” the password argument, which can be learned from the de-obfuscated PowerShell. From here we can learn where “data” came from(http://147.182.172.189:80/9tVI0 == “tcp.stream eq 3”).

    According to the decompiled code, we can know the response(tcp.stream eq 3) was encrypted by AES encryption. Initial Vector is “9907bb679e1765dcbdb467c1c4b00d21”. key is “z64&Rx27Z$B%73up”. Padding mode is PKCS7.

    Further, we can see the “Loading shellcode from URL”, so the attack chain could be
    1. Requested to 147.182.172.189 and received a response with 4A7xH.ps1
    2. Requested to the same IP and received an executable user32.dll
    3. user32.dll will decrypt the response to shell from “http://147.182.172.189:80/9tVI0” since the comment written in the user32.dll “(Detonator)[*]Loading shellcode from URL”

    ShellCode decrypt

    Leverage the python script to decrypt the shellcode

    from Cryptodome.Cipher import AES
import hashlib
from Cryptodome.Util.Padding import pad, unpad
f = open('9tVI0.base64','rb')
full_9t = f.read()
f.close()

key = "z64&Rx27Z$B%73up"
print('isi key')

iv = full_9t[:16]
ciphertext = full_9t[16:]

hashed_str = bytearray(hashlib.sha256(key.encode('utf-8')).digest())

g = open('keyNew99','wb')
g.write(hashed_str)
g.close()

cipher = AES.new(hashed_str, AES.MODE_CBC, iv=iv)
plaintext = unpad(cipher.decrypt(ciphertext), 16)

print('isi plaintext')
# print(plaintext)

f = open('resultPycryptoWithPadding','wb')
f.write(plaintext)
f.close()

    Or leverage the online .net fiddle to decrypt

    After we decrypted the shellcode, we can use scdbgc(the x86 shellcode emulator) to get the flag

    >scdbgc.exe /f redfailure.sc

    ShellCode looks like to inject the net command to add the user to the victim machine.

    Beyond the flag-shellcode debugging

    x32dbg + runsc32 to step debugging the shellcode

    >runsc32.exe -f shellcode.sc

    Crtl+g in x32dbg to jump to the shellcode address(0x005E0000), then F2 to setup the breakpoint. After that, go back to runsc32.exe and press any key to resume the shellcode thread.

    We can compare the starting bytes to know we are on the right address to debug shellcode

    Step debugging over the instruction “call 5E00A3″(0x005E0021), the flag emerged.

    關於作者

    Nelley，乃力。
    就是一個村民。