Home STDiO 2023: Forensics Writeup
Post
Cancel

STDiO 2023: Forensics Writeup

Posted Dec 4, 2023
STDiO2023 CTF Cover
STDiO2023 CTF Cover
By Vilaysack
7 min read

ສະບາຍດີ ທຸກຄົນ! ມື້ນີ້ຂະພະເຈົ້າ ຈະມາສະເຫຼີຍໂຈດ Capture The Flag (CTF) ໃນໝວດ Forensics ຈາກທາງເພື່ອນບ້ານທີ່ຊື່ວ່າ STDiO CTF ເຊິ່ງຈັດຂຶ້ນໂດຍ 2600 Thailand ເຊິ່ງຂ້າພະເຈົ້າຮູ້ສຶກວ່າມີຄວາມທ້າທາຍ ແລະ ໄດ້ຮຽນຮູ້ຫຼາຍຢ່າງ ຜ່ານການເເກ້ໂຈດໃນງານນີ້.

ໃນການສະເຫຼີຍຄັ້ງນີ້ ເເມ່ນມີບາງໂຈດທີ່ຂ້າພະເຈົ້າບໍສາມາດແກ້ໄດ້ທັນເວລາການເເຂ່ງຂັນ ແຕ່ສາມາດແກ້ໄດ້ຫຼັງຈາກງານເເຂ່ງຂັນສິ້ນສຸດລົງ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າຈິ່ງໄດ້ເອົາມາເເບ່ງເປັນເພື່ອໃຫ້ເປັນແນວທາງສຳລັບລຸ້ນນ້ອງ, ໝູ່ເພື່ອນ ຫຼື ອ້າຍ/ເອື້ອຍ ທຸກໆຄົນທີ່ມີຄວາມສົນໃຈ ແລະ ກຽມພ້ອມເພື່ອເເຂ່ງຂັນ CTF ໃນອະນາຄົດໄດ້ສຶກສາໄປພ້ອມໆກັນ. ເນື່ອງຈາກວ່າ ໃນສາດຂອງການແກ້ CTF ແລະ ການເຮັດວຽກ/ການເສັງ Certification ແມ່ນເປັນໜັງຄົນລະມ້ວນເລີຍ. ການແກ້ CTF ຈະມີໃນເລື່ອງຂອງການທົດສອບທັກສະການແກ້ໄຂບັນຫາ ແລະ ໄຫວພິບທີ່ທ້າທາຍກວ່າ ເມື່ອທຽບກັບການເສັງ Cert ທີ່ຈະເປັນການທົດສອບທັກສະເພື່ອເນັ້ນໃຫ້ເຮົາພ້ອມແກ່ການເຮັດວຽກຕົວຈິງເປັນສ່ວນໃຫຍ່.

ເພື່ອບໍ່ໃຫ້ເປັນການເສຍເວລາ ເຮົາມາເບິ່ງນຳກັນເລີຍ!!

Encrypt Traffic

ໃນໂຈດໄດ້ໃຫ້ໄຟລ໌ບີບອັດທີ່ມີຊື່ວ່າ for2_Encrypted_Traffic_traffic.pcap.zip ເຊິ່ງພາຍໃນໄຟລ໌ດັ່ງກ່າວຈະປະກອບມີ ໄຟລ໌ທີ່ໜ້າສົນໃຈຢູ່ 2 ໄຟລ໌ຄື ໄຟລ໌ Network Traffic .pcap ແລະ ໄຟລ໌ key.

ເມື່ອພວກເຮົາທົດສອບເປີດໄຟລ໌ .pcap ດ້ວຍເຄື່ອງມື Wireshark ເຮົາຈະບໍ່ສາມາດອ່ານ Traffic ໄດ້ເພາະຕົວຂໍ້ມູນການໄຫລຂອງເນັກເວີກໄດ້ມີການເຂົ້າລະຫັດ (Encrypt) ໄວ້ເພື່ອປ້ອງກັນການອ່ານເຫັນ Traffic ແບບ Plaintext. ເນື່ອງຈາກວ່າຕົວໂຈດໄດ້ໃຫ້ໄຟລ໌ key ໃຫ້ກັບເຮົາ ຈິ່ງເຮັດໃຫ້ສາມາດຖອດລະຫັດ (Decrypt) ຂໍ້ມູນການໄຫລຂອງເນັດເວີກນີ້ໄດ້. ແຕ່ ເຮົາຈະຮູ້ວິທີຖອດລະຫັດໄດ້ແນວໃດ?

ກ່ອນອື່ນໝົດ, ເຮົາມາກວດສອບເບິ່ງເນື້ອຫາພາຍໃນຂອງໄຟລ໌ key ນີ້ກັນກ່ອນ. ໂດຍເນື້ອຫາບ່າງສ່ວນໄດ້ສະແດງດັ່ງລຸ່ມນີ້:

1
2
3
4

SERVER_HANDSHAKE_TRAFFIC_SECRET 89f95292cf3b33c625361114bda6f3d2a99516ac9edc951658d53afad6a22202 8d515f43ab94aab1f9e430ddc077c6c4026e1658207e638d8bacee51d649c98e2e3e290ea0f8754f13d8e814d4623bcf
EXPORTER_SECRET 89f95292cf3b33c625361114bda6f3d2a99516ac9edc951658d53afad6a22202 056add79b69ebe7c7f77e332b9a46a26f65951ed20f8bfe741c997030aef054692f45a494017d715af4d5662e27be6b9
SERVER_TRAFFIC_SECRET_0 89f95292cf3b33c625361114bda6f3d2a99516ac9edc951658d53afad6a22202 cdae9488f2322cdef20dad8e9240de442064b6c73633a2dad80b8e338d051225ab5415732e219783c91664176b40fb09
<-- snip --->

ຈາກຕົວຢ່າງຂ້າງຕົ້ນ ເຮົາສັງເກດເຫັນວ່າ ໄຟລ໌ Key ດັ່ງກ່າວເປັນ Pre-Master-Secret.

ໃນການຖອດລະຫັດ ໃນໜ້າ Wireshark ເຮົາສາມາດເຂົ້າໄປທີ່ Edit > Preferences > Protocols > TLS ຈາກນັ້ນເຮົາສາມາດຖອດລະຫັດດ້ວຍການ import ເຂົ້າໄປໃນສ່ວນ (Pre)-Master-Secret key log filename. ເມື່ອສຳເລັດການ import ເຮົາກໍຈະເຫັນຄຳຕອບທັນທີ.

Wireshark Decrypted Traffic Figure 1.1 — Wireshark Decrypted Traffic Sample

ຄຳຕອບ: STDIO23_14{bddbe90b56bbb69e10c1807a2eddbd13}

Isolated Server

ໃນໂຈດຂໍ້ນີ້ຈະເປັນການວິເຄາະໄຟລ໌ .ldb ເຊິ່ງເປັນໄຟລ໌ບັນທຶກການເປີດ ຫຼື ເຂົ້າເຖິງຖານຂໍ້ມູນຂອງ Microsoft (Microsoft Access Lock Information). ໃນການວິເຄາະໄຟລ໌ນີ້ເຮົາສາມາດນຳໃຊ້ເຄື່ອງມື tdbdump ເພື່ອດຶງເອົາຂໍ້ມູນຈາກໄຟລ໌ດັ່ງກ່າວ. ໃນບາງ Linux distro ຈະບໍ່ມີຕົວໂປຣແກຣມນີ້ມານຳ ແຕ່ເຮົາກໍສາມາດຕິດຕັ້ງໄດ້ໂດຍໃຊ້ຄຳສັ່ງ sudo apt install tdb-tools.

ເພື່ອດຶງເອົາຂໍ້ມູນຕ່າງໆອອກຈາກໄຟລ໌ .ldb ເຮົາສາມາດໃຊ້ຄຳສັ່ງຕໍ່ໄປນີ້:

1

tdbdump for3_Isolated_Server_cache_sdhbank.local.ldb > dump.txt

ຫາກເຮົາສາມາດດຶງຂໍ້ມູນອອກຈາກໄຟລ໌ໄດ້ ຜົນລັບຂອງເຮົາຈະຄ້າຍຄືກັບທີ່ສະແດງຂ້າງລຸ່ມນີ້:

1
2
3
4
5
6
7
8
9
10
11
12
13

{
key(21) = "DN=@INDEX:CN:CERTMAP\00"
data(81) = "g\19\01&\02\00\00\00@INDEX:CN:CERTMAP\00@IDXVERSION\00\01\00\00\00\01\00\00\002\00@IDX\00\01\00\00\00\13\00\00\00cn=certmap,cn=sysdb\00"
}
{
key(91) = "DN=@INDEX:MEMBER:NAME=Domain [email protected],CN=GROUPS,CN=SDHBANK.LOCAL,CN=SYSDB\00"
data(225) = "g\19\01&\02\00\00\00@INDEX:MEMBER:NAME=Domain [email protected],CN=GROUPS,CN=SDHBANK.LOCAL,CN=SYSDB\00@IDXVERSION\00\01\00\00\00\01\00\00\002\00@IDX\00\01\00\00\00]\00\00\00name=Denied RODC Password Replication [email protected],cn=groups,cn=sdhbank.local,cn=sysdb\00"
}
{
key(72) = "DN=@INDEX:OBJECTSIDSTRING:S-1-5-21-1310303666-1233753094-3832251473-520\00"
data(195) = "g\19\01&\02\00\00\00@INDEX:OBJECTSIDSTRING:S-1-5-21-1310303666-1233753094-3832251473-520\00@IDXVERSION\00\01\00\00\00\01\00\00\002\00@IDX\00\01\00\00\00R\00\00\00name=Group Policy Creator [email protected],cn=groups,cn=sdhbank.local,cn=sysdb\00"
}
<-- snip -->

ຫຼັງຈາກອ່ານຂໍ້ມູນທີ່ດຶງອອກມາຈາກໄຟລ໌ .ldb ດັ່ງກ່າວ, ເຮົາຈະພົບກັບ hash ຂອງຜູ້ໃຊ້ admin. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ດຳເນີນການ crack ເພື່ອທົດສອບວ່າເຮົາສາມາດກູ້ລະຫັດຈາກ wordlist ໄດ້ຫຼືບໍ່.

1
2
3
4

# Write the hash to file
echo -n '$6$kLD6uZK9nK8VuQ65$Bs13zM0B3nGcCqMdfNPMbwrON0DpoJSn/c9ry/CEatJJY8Jtvfvss7k6o.dxZfbfxKm5SdlApx2jR8PTwtF7B0' > hash
# Using John to crack the file in dictionary mode with rockyou.txt dictionary
john --wordlist=/usr/share/wordlists/rockyou.txt hash

ຫຼັງຈາກທີ່ໃຊ້ເວລາປະມານໜຶ່ງ, ເຮົາສາມາດ crack ລະຫັດດັ່ງກ່າວດ້ວຍ wordlist ທີ່ຊື່ວ່າ rockyou.txt

1
2
3
4
5
6
7
8
9

Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 128/128 AVX 2x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Michael1         (?)     
1g 0:00:00:03 DONE (2023-12-03 23:10) 0.2849g/s 2844p/s 2844c/s 2844C/s 12345b..stevens
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

ຫຼັງຈາກນັ້ນ, ເຮົາສາມາດນຳໃຊ້ຄຳສັ່ງ md5sum ເພື່ອຄິດໄລ່ຄ່າ hash ໃຫ້ກັບລະຫັດທີ່ເຮົາ crack ໄດ້ເພື່ອເປັນຄຳຕອບສຳລັບຂໍ້ນີ້.

1

echo "STDIO23_15{`echo -n 'Michael1' | md5sum - | cut -c 1-32`}"

ຄຳຕອບ: STDIO23_15{b2b3ac0899ba5d01a530ca6f4525248a}

Broken Document

ພາຍໃນໂຈດໄດ້ໃຫ້ໄຟລ໌ .bin ເຊິ່ງພາຍຫລັງນຳໃຊ້ຄຳສັ່ງ file for4_BrokenDocument.bin ເພື່ອກວດສອບຊະນິດຂອງໄຟລ໌. ສັງເກດເຫັນວ່າໄຟລ໌ດັ່ງກ່າວ ແມ່ນ Linux filesystem.

ເພື່ອດຳເນີນການວິເຄາະໄຟລ໌ດັ່ງກ່າວ ເຮົາສາມາດ mount ເຂົ້າກັບເຄື່ອງ linux ຂອງເຮົາໂດຍນຳໃຊ້ຄຳສັ່ງ ດັ່ງຕໍ່ໄປນີ້:

1
2
3
4

# Create a new directory for mounting
sudo mkdir /mnt/brokenDocument/
# Mount a filesystem to our machine
sudo mount ./for4_BrokenDocument.bin /mnt/brokenDocument

ເມື່ອເຮົາດຳເນີນການ mount ສຳເລັດ, ພາຍໃນ filesystem ດັ່ງກ່າວຈະພົບ directory ທີ່ມີຊື່ແປກໆເປັນຈຳນວນຫຼາຍ. ດ້ວຍເຫດນັ້ນ, ເຮົາທົດສອບຄົ້ນຫາໄຟລ໌ທີ່ອາດຈະຢູ່ໃນ filesystem ນີ້ດ້ວຍການນຳໃຊ້ຄຳສັ່ງຕໍ່ໄປນີ້:

1

find /mnt/brokenDocument/ -type f 2> /dev/null

ຫາກທຸກຄົນນຳໃຊ້ຄຳສັ່ງແບບດຽວກັນກັບທີ່ກ່າວມາ, ຜົນລັບຂອງຄຳສັ່ງຈະຄ້າຍຄືກັບທີ່ສະແດງຂ້າງລຸ່ມນີ້:

1
2
3
4
5
6
7
8
9
10

/mnt/brokenDocument/75x9guqw/5IZnQugB/free_excel.ods
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/25/619ecff9d4c3259f3b1793ced95e455948f289
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/5e/211d7af9ad2798589769655a6aa457afc764fb
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/d2/f3c321e3587175e84c1baceac717da0584a80e
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/4f/7cf3318d699bcf4e5415e77d2806efb1dc84f1
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/7d/4e5c813e71e1961e6ab9483a4ec389554b1274
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/b2/2a76bbd31fa3f09cec3cc7d2a021fbe467b7df
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/79/a139ca2be29e2531630b3bf4775eb0514e6df6
/mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/objects/dd/6ed23b16b2085361f501b9616af3db09c9aaf7
<-- snip -->

ຈາກຜົນລັບຂອງຄຳສັ່ງ find, ເຮົາປະກົດເຫັນໄຟລ໌ທີ່ໜ້າສົງໃສຢູ່ສອງໄຟລ໌ຄື: free_excel.ods ແລະ .git. ດ້ວຍເຫດນັ້ນ, ເຮົາດຳເນີນການຄັດລອກໄປວາງໄວ້ໃນ home directory ຂອງເຮົາເພື່ອກວດສອບໃນຂັ້ນຕໍ່ໄປ.

1
2

cp /mnt/brokenDocument/75x9guqw/5IZnQugB/free_excel.ods ~/stdio2023_ctf/forensics/brokenDocument/
cp /mnt/brokenDocument/75x9guqw/Qhc3N9Ob/.git/ ~/stdio2023_ctf/forensics/brokenDocument/

ໃນຂັ້ນທຳອິດ, ເຮົາດຳເນີນການກວດສອບໄຟລ໌ OpenDocument Spreadsheet (.ods), ຂ້າພະເຈົ້າສັງເກດເຫັນວ່າ magic number ຂອງ header ໄຟລ໌ດັ່ງກ່າວແມ່ນບໍ່ຖືກ ເຊິ່ງເຮັດໃຫ້ເມື່ອເປີດອ່ານໄຟລ໌ ໂປຣແກຣມທີ່ໃຊ້ອ່ານຈິ່ງແຈ້ງວ່າໄຟລ໌ນັ້ນໆເສຍຫາຍ. ເພື່ອແກ້ໄຂໃນພາກສ່ວນດັ່ງກ່າວ, ເຮົາສາມາດນຳໃຊ້ hexeditor ແກ້ໄຂ header ໃນ offset ທີ 0x00 ແລະ 0x01 ຈາກ 4B 50 ໄປເປັນ 50 4B.

ເຖິງແມ່ນວ່າເຮົາຈະແກ້ໄຂຂໍ້ຜິດພາດດັ່ງກ່າວໄປແລ້ວ ເຮົາກໍຍັງບໍ່ສາມາດເປີດອ່ານໄຟລ໌ດັ່ງກ່າວໄດ້ ເນື່ອງຈາກເຮົາບໍ່ຮູ້ລະຫັດຜ່ານຂອງໄຟລ໌ນີ້. ດັວຍເຫດນັ້ນ, ຂ້າພະເຈົ້າໄດ້ດຳເນີນການກວດສອບໂຟເດີ .git ກ່ອນເພື່ອຈະໄດ້ຂໍ້ມູນຫຍັງທີ່ໜ້າສົນໃຈ. ໂຟເດີ .git ເປັນ repository ຂອງ Git ທີ່ໃຊ້ໃນການບັນທຶກກິດຈະກຳຂອງໂປຣເຈັກຕ່າງໆ ແລະ ມີການເກັບປະຫວັດຕ່າງໆໃຫ້ເຮົາສາມາດ review ໄດ້ອີກດ້ວຍ. ດ້ວບເຫດນີ້, ການກວດສອບໂຟເດີດັ່ງກ່າວ ຈິ່ງເປັນ foothold ທີ່ດີໃນການພະຍາຍາມກູ້ຄືນຂໍ້ມູນທີ່ອາດຈະເກັບ ລະຫັດຂອງໄຟລ໌ spreadsheet ທີ່ກ່າວມາຂ້າງຕົ້ນນັ້ນ.

ເພື່ອກວດສອບປະຫວັດການ commit ທີ່ຜ່ານມາເຮົາສາມາດນຳໃຊ້ຄຳສັ່ງ git log ເຊິ່ງຜົນລັບຂອງຄຳສັ່ງຈະຄ້າຍຄືກັບຂ້າງລຸ່ມນີ້:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

commit dd6ed23b16b2085361f501b9616af3db09c9aaf7 (HEAD -> master)
Author: root <[email protected]>
Date:   Wed Nov 29 03:48:34 2023 +0700

    clean up

commit 15173896c55d6620d74e2d6ef02ccf9e81c37f53
Author: root <[email protected]>
Date:   Wed Nov 29 03:48:13 2023 +0700

    note for my excel

commit 9e330ec43c248855b47251eff287444d49f98fb8
Author: root <[email protected]>
Date:   Wed Nov 29 03:45:21 2023 +0700

    gone forever

commit 79a139ca2be29e2531630b3bf4775eb0514e6df6
Author: root <[email protected]>
Date:   Wed Nov 29 03:44:55 2023 +0700
<-- snip -->

ຈາກຜົນລັບຂ້າງຕົ້ນ, ຂ້າພະເຈົ້າໄດ້ທົດສອບກູ້ໄຟລ໌ທີ່ສ້າງໃນການ commit ທີ່ comment ໄວ້ວ່າ “note for my excel”. ແຕ່ລະຫັດດັ່ງກ່າວບໍ່ຖືກຕ້ອງ, Rabbit Hole ເຕັມໆ! ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າກໍໃຊ້ເວລາດົນພໍສົມຄວນໃນການຊອກຫາວິທີອື່ນ.

ພາຍຫຼັງທີ່ການແຂ່ງຂັນສິ້ນສຸດລົງ. ຂ້າພະເຈົ້າໄດ້ຮຽນຮູ້ອີກວິທີການໜຶ່ງທີ່ສາມາດໃຊ້ຢັ້ງຢືນຄວາມເປັນເຈົ້າຂອງໄຟລ໌ດ້ວຍການເຂົ້າລະຫັດໄຟລ໌ spreadsheet ດັ່ງກ່າວດ້ວຍ private key ທີ່ສ້າງໂດຍໃຊ້ເຄື່ອງມືເຊັ່ນ: gpg ດ້ວຍເຫດນັ້ນ, ຄຳຕອບທີ່ກ່າວມາຈຶ່ງໄປຕອບຄຳຖາມທີ່ຢູ່ໃນຫົວຂອງຂ້າພະເຈົ້າໃນລະຫວ່າງທີ່ອ່ານປະຫວັດຂອງ .git ທີ່ກ່າວມາກ່ອນໜ້ານີ້ວ່າ ເປັນຫຍັງຕ້ອງມີໄຟລ໌ .asc ໃນປະຫວັດການ commit. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ໃຊ້ຄຳສັ່ງ git checkout ເພື່ອກູ້ໄຟລ໌ໃນ commit ນັ້ນໆ.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Jump to the version that contains key.asc
git checkout 79a139ca2be29e2531630b3bf4775eb0514e6df6

# Crack the key with John The Ripper
gpg2john key.asc > key.hash
john --format=gpg --wordlist=/usr/share/wordlists/rockyou.txt key.hash

# The password result be 1234

# import key
# The prompt will ask to enter the password (Which we've cracked before)
gpg --import key.asc

# modify a key trust level to level 5 (ultimately trust) and (y)es to confirm our changed
# using gpg option --command-fd 0 to receive input from prompt --expert to fully fine control over the encryption process, then use --edit-keys to tell the command that we are going to edit this key
echo -n "5\ny\n" | gpg --command-fd 0 --expert --edit-keys 50B9439A179EEFFAEDE6BD8C14B31C1CD673DF25 trust

ພາຍຫລັງປະຕິບັດຕາມຂັ້ນຕອນທີ່ສະແດງຂ້າງເທິງ. ເຮົາສາມາດເປີດໄຟລ໌ ແລະ ນຳໃຊ້ລະຫັດຜ່ານທີ່ເຮົາ crack ມາ ເພື່ອເປີດອ່ານໄຟລ໌ໄດ້ທັນທີ.

ຄຳຕອບ: STDIO23_16{476c3f289c409ada45e303e08f5ab76d}

Check Mem

ໂຈດໄດ້ໃຫ້ໄຟລ໌ memory dump. ໃນໂຈດຂໍ້ນີ້ໄດ້ມີຄຳໃບ້ທີ່ຊັດເຈນກັບເຮົາໃນຄຳອະທິບາຍຂອງໂຈດ ເຊິ່ງໄດ້ກ່າວໄວ້ວ່າ: “somewhere that every-windows have it”. ດັ່ງນັ້ນ, ສິ່ງທຳອິດທີ່ຂ້ພະເຈົ້ານຶກເຖິງກໍຄື Windows environment variable ເຊິ່ງເປັນສິ່ງທີ່ໜ້າຈະແມ່ນທີ່ສຸດແລ້ວ.

ແຕ່ເຮົາຈະສາມາດອ່ານໄຟລ໌ດັ່ງກ່າວໄດ້ແນວໃດ? ຄຳຕອບຄື Volatility, ເຊິ່ງເປັນເຄື່ອງມືການເຮັດ Memory forensics ທີ່ຊົງພະລັງ, ຟຣີ ແລະ ດີຕົວໜຶ່ງໃນຕະລາດ. ເຊິ່ງຂ້າພະເຈົ້າຈະນຳໃຊ້ Volatility 3 ໃນການສາທິດນີ້:

1
2

# Using volatility3 to dump a Windows environment variables
python3 vol.py -f STDiO_memdump Windows.envars.Envars

ເມື່ອນຳໃຊ້ຄຳສັ່ງທີ່ກ່າວມາຂ້າງຕົ້ນ, ເຮົາຈະໄດ້ຜົນລັບຄ້າຍຄືດັ່ງຕໍ່ໄປນີ້:

1
2
3
4
5
6
7
8
9
10
11

<-- snip -->
2372    RuntimeBroker.  0x21a71e03430   DriverData      C:\Windows\System32\Drivers\DriverData
2372    RuntimeBroker.  0x21a71e03430   F.1.a.G is d616ad7365a1b99bc7257091356d9514
2372    RuntimeBroker.  0x21a71e03430   HOMEDRIVE       C:
2372    RuntimeBroker.  0x21a71e03430   HOMEPATH        \Users\Mirth
2372    RuntimeBroker.  0x21a71e03430   LOCALAPPDATA    C:\Users\Mirth\AppData\Local
2372    RuntimeBroker.  0x21a71e03430   LOGONSERVER     \\DESKTOP-QPU6OJ5
2372    RuntimeBroker.  0x21a71e03430   NUMBER_OF_PROCESSORS    1
2372    RuntimeBroker.  0x21a71e03430   OneDrive        C:\Users\Mirth\OneDrive
2372    RuntimeBroker.  0x21a71e03430   OneDriveConsumer        C:\Users\Mirth\OneDrive
<-- snip -->

ຈາກຜົນລັບ ເຮົາສັງເກດເຫັນວ່າມີຄ່າ variable ທີ່ຊື່ວ່າ F.1.a.G ເຊິ່ງເປັນຄຳຕອບທີ່ເຮົາຕ້ອງການ.

ຄຳຕອບ: STDIO23_25{d616ad7365a1b99bc7257091356d9514}

Check Mem 2

ໃນໂຈດຂໍ້ນີ້ແມ່ນນຳໃຊ້ໄຟລ໌ດຽວກັນກັບໂຈດ Check Mem ເຊິ່ງໃນໂຈດຂໍ້ນີ້ເຮົາຕ້ອງໄດ້ດຳເນີນການວິເຄາະ process ຕ່າງໆຈາກ memory dump ນີ້.

ໃນຂັ້ນຕອນທຳອິດໃຫ້ເຮົາດຳເນີນການດຶງ process ອອກມາ ໂດຍໃຊ້ຄຳສັ່ງດັ່ງຕໍ່ໄປນີ້:

1

python3 ./volatility3-2.5.0/vol.py -f ./STDiO_memdump windows.pstree.PsTree

ເມື່ອໃຊ້ຄຳສັ່ງດັ່ງກ່າວຜົນລັບທີ່ໄດ້ ຈະຄ້າຍຄືກັບທີ່ສະແດງຂ້າງລຸ່ມນີ້:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Volatility 3 Framework 2.5.0

PID     PPID    ImageFileName   Offset(V)       Threads Handles SessionId       Wow64   CreateTime      ExitTime

4       0       System  0x8a059be83040  166     -       N/A     False   2023-11-13 07:07:06.000000      N/A
* 72    4       Registry        0x8a059bf35080  4       -       N/A     False   2023-11-13 07:07:01.000000      N/A
* 528   4       smss.exe        0x8a059cea3040  2       -       N/A     False   2023-11-13 07:07:06.000000      N/A
* 1780  4       MemCompression  0x8a059beee040  42      -       N/A     False   2023-11-13 07:07:10.000000      N/A
632     624     csrss.exe       0x8a059ce19140  10      -       0       False   2023-11-13 07:07:07.000000      N/A
704     696     csrss.exe       0x8a059f160140  12      -       1       False   2023-11-13 07:07:08.000000      N/A
712     624     wininit.exe     0x8a059f168080  1       -       0       False   2023-11-13 07:07:08.000000      N/A
* 824   712     services.exe    0x8a059f196080  8       -       0       False   2023-11-13 07:07:08.000000      N/A
** 1540 824     svchost.exe     0x8a05a0630300  13      -       0       False   2023-11-13 07:07:10.000000      N/A
** 1924 824     svchost.exe     0x8a059bf86080  8       -       0       False   2023-11-13 07:07:11.000000      N/A
** 908  824     svchost.exe     0x8a05a03c92c0  17      -       0       False   2023-11-13 07:07:09.000000      N/A
** 1548 824     svchost.exe     0x8a05a0632240  3       -       0       False   2023-11-13 07:07:10.000000      N/A
** 2064 824     svchost.exe     0x8a05a08412c0  8       -       0       False   2023-11-13 07:07:12.000000      N/A
** 1148 824     svchost.exe     0x8a05a05052c0  18      -       0       False   2023-11-13 07:07:09.000000      N/A
** 2452 824     vm3dservice.ex  0x8a05a0aee240  5       -       0       False   2023-11-13 07:07:13.000000      N/A
*** 2564        2452    vm3dservice.ex  0x8a05a0b5f200  5       -       1       False   2023-11-13 07:07:13.000000      N/A
** 2328 824     svchost.exe     0x8a05a0a97240  13      -       0       False   2023-11-13 07:07:13.000000      N/A
** 6552 824     svchost.exe     0x8a05a22f9080  14      -       0       False   2023-11-13 07:09:39.000000      N/A
** 2080 824     svchost.exe     0x8a05a08892c0  15      -       0       False   2023-11-13 07:07:12.000000      N/A
** 2464 824     vmtoolsd.exe    0x8a05a0af0280  11      -       0       False   2023-11-13 07:07:13.000000      N/A
** 1188 824     svchost.exe     0x8a05a050f2c0  14      -       0       False   2023-11-13 07:07:09.000000      N/A
** 2852 824     dllhost.exe     0x8a05a09af280  18      -       0       False   2023-11-13 07:07:14.000000      N/A
** 4004 824     svchost.exe     0x8a05a10e10c0  21      -       1       False   2023-11-13 07:08:35.000000      N/A
** 6948 824     svchost.exe     0x8a05a26e3080  12      -       0       False   2023-11-13 07:09:13.000000      N/A
** 556  824     spoolsv.exe     0x8a059bf44080  10      -       0       False   2023-11-13 07:07:11.000000      N/A
** 2476 824     MsMpEng.exe     0x8a05a0af2340  29      -       0       False   2023-11-13 07:07:13.000000      N/A
** 1204 824     svchost.exe     0x8a05a0527280  37      -       0       False   2023-11-13 07:07:09.000000      N/A
*** 2904        1204    ctfmon.exe      0x8a05a15d5300  11      -       1       False   2023-11-13 07:08:36.000000      N/A

ພາຍຫຼັງທີ່ໃຊ້ເວລາກວດສອບ process ຕ່າງໆສັງເກດເຫັນວ່າ ທຸກໆ process ກໍເບິ່ງປົກກະຕິດີ ເຊິ່ງເຮັດໃຫ້ຂ້າພະເຈົ້າ ພົບກັບ Rabbit Hole ອີກຄັ້ງ ວ່າເຮົາຕ້ອງໄປຫາ flag ຢູ່ໃນສ່ວນໃດ ແລະ ເຮົາໄດ້ລືມກວດສອບພາກສ່ວນໃດໄປ ຫຼື ບໍ່?

ຫຼັງຈາກນັ້ນ, ເຮັດໃຫ້ຂ້າພະເຈົ້າເລີ່ມຄິດຄືນວ່າ ແລ້ວພາຍໃນ msedge, ຜູ້ໃຊ້ເປີດໄປເຮັດຫຍັງ? ແລະ ໃນທີ່ສຸດຄຳຕອບກໍຄື flag ບໍ່ໄດ້ຢູ່ທີ່ຄວາມຜິດປົກກະຕິຂອງ process ແຕ່ມັນຢູ່ທີ່ url ທີ່ຜູ້ໃຊ້ເຂົ້າເຖິງ.

ດ້ວຍເຫດນັ້ນ, ຂ້າພະເຈົ້າໄດ້ດຳເນີນການ dump ໄຟລ໌ ທີ່ກ່ຽວຂ້ອງກັບ process msedge.exe ອອກມາໂດຍໃຊ້ຄຳສັ່ງ:

1

python3 ./volatility3-2.5.0/vol.py -f ./STDiO_memdump windows.dumpfiles --pid 5928

ຈາກນັ້ນ, ກໍໄດ້ທົດສອບຄົ້ນຫາ url ທີ່ user ເຂົ້າໃຊ້ທັງໝົດດ້ວຍວິທີ ປະຖົມມະຖານ ດັ່ງນີ້:

1

strings * | grep "https://"

ພາຍຫລັງນຳໃຊ້ຄຳສັ່ງດັ່ງກ່າວ, ປະກົດວ່າ ຂ້າພະເຈົ້າໄດ້ພົບກັບ url ຂອງ canva ທີ່ຄ້າຍຄືກັບລິ້ງແຊຣ໌ https://www.canva.com/design/DAE9sYVcpW0/ASjUf8Fyi5rQvvXASJytvQ/view?utm_content=DAE9sYVcpW0&utm_campaign=designshare&utm_medium=link&utm_source=publishsharelink.

ຕາມຄາດ, ລິ້ງດັ່ງກ່າວມີ flag ຢູ່ຂ້າງໃນ 5555

Canva link contains flag

ຄຳຕອບ: STDIO23_26{4250CC2AF06CE224E8BCE618456796DB}

Write Up, CTF
writeup ctf forensics
This post is licensed under CC BY 4.0 by the author.
Contents