สายอาชีพไซเบอร์ที่ดูเผินๆ แล้วเน้นเทคนิค ใช้โปรแกรม ทูล เครื่องมือเยอะๆ อย่าง DFIR หรือแม้แต่ Pentester อย่างพวกเรานั้น จะมีคำพูดที่สอนกันว่า
เน้นพื้นฐาน หลักการ ระเบียบวิธีการ อย่ายึดติดกับทูล
Do not be tool-driven. Use methodology.
เพราะด้วยระเบียบวิธี กลไกการคิดที่เป็นมาตรฐานที่ไม่อิงกับเทคโนโลยีนั้น นอกจากช่วยให้ปรับตัวได้อย่างรวดเร็วเมื่อเทคโนโลยีเปลี่ยนไว (อย่างยุค AI นี้) แล้ว ยังทำให้ (ลูกค้า) มั่นใจว่าทดสอบได้ “ครบ” ครอบคลุมด้วย
ออดิเตอร์ต้องทดสอบไล่ตามหัวข้อมาตรฐาน เช่น ISO 27001 Annex A / SOA ให้ครบเช่นไร นักทดสอบเจาะระบบก็ต้องทดสอบครบตาม Methodology / Checklist ที่เลือกหรือตกลงสโคปกับลูกค้า อย่างเช่น OWASP WSTG, MASTG หรือ PTES / NIST SP 800-115 เช่นกัน
ในแง่ของหลักการ แนวคิดที่นักทดสอบเจาะระบบควรมี นอกเหนือจากข้างต้น ก็มีหลายประการ เช่น
1. การใช้เครื่องมือสแกน ควรทำซ้ำ เพราะสแกนแต่ละครั้งให้ผลต่างกัน
ตัวอย่างเช่น การใช้ทูลสแกนพอร์ตที่เน้นความเร็ว อย่าง rustscan การสแกนครั้งเดียว โดยเฉพาะเมื่อกำหนดเรตความเร็วสูง (เช่นเดียวกับ nmap -T4 หรือ 5) ก็ทำให้สแกนไม่เจอบางพอร์ตที่เซอร์วิสตอบกลับมาช้าได้ (อีกทั้งในระบบจริง การไม่ลิมิตเรตอาจสค้างภาระให้ระบบเป้าหมายที่อ่อนไหวง่ายด้วย)
เช่นเดียวกับทูลสแกนความสัมพันธ์ระหว่างเครื่อง / ผู้ใช้ในระบบ Active Directory อย่าง Bloodhound ที่ทาง SpectreOps ย้ำเสมอมาว่าควรสแกนซ้ำด้วย เพราะไม่ว่าจะในเวลาใกล้กันหรือต่างกัน อาจมีสถานะความสัมพันธ์หรือปฏิสัมพันธ์ภายในโดเมนทึ่แตกต่างกัน ทำให้ได้ข้อมูลไม่ครบถ้าสแกนครั้งเดียว
2. “Enum Enum Enum” หมายถึง ตรวจสอบช่องทางเข้าถึงให้ครบ อย่าขี้เกียจแล้วมองข้าม
แม้เรามักถูกดึงดูด (มากเกินไป) ด้วยช่องทางเข้าถึงที่ดูเหมือนจะมีช่องโหว่ชัดเจนที่สุด (ที่เรียกว่า Low Hanging Fruit) การมุ่งทดสอบ Exploit กับจุดนั้นมากเกินไป จนเสียเวลาเกินไป จนลืมตรวจสอบช่องทางที่เหลือที่เป็นไปได้
ตัวอย่างที่เห็นบ่อยที่สุดในข้อสอบแล็ปปฏิบัติคือ การสแกนพอร์ตแต่แบบ TCP (ซึ่งเป็นโหมดดีฟอลต์ของ nmap) แล้วมักลืมสแกนโปรโตคอล UDP ที่เต็มไปด้วยบริการที่มีช่องโหว่มาก (เพราะมักไม่มีการเข้ารหัสจากความเป็น Connectionless) เช่น TFTP, SNMP ที่อาจหลุดข้อมูลสำคัญอย่างรหัสผ่านได้
หรือการยึดติดกับผลทดสอบการสแกนพอร์ตเครื่องเป้าหมายจากภายนอก เช่น ผล nmap ว่าเครื่องนี้มึเซอร์วิสเปิดอยู่เท่านี้ ทั้งๆ ที่มีหลายเซอร์วิสทึ่เปิดให้เข้าถึงได้เฉพาะในเครื่องตัวเอง เช่น ระบบฐานข้อมูล SQL ที่เมื่อเข้าถึงเครื่องดังกล่าวได้แล้วเราก็ควรตรวจพอร์ตภายในเครื่องที่รอรับการเชื่อมต่อเข้าใช้บริการด้วยคำสั่ง เช่น ss -lntup บนลีนุกซ์ หรือ netstat บนวินโดวส์ ที่อาจทำให้เรารู้และลองเข้าถึงเซอร์วิสฐานข้อมูลที่อาจมีข้อมูลสำคัญอย่างรหัสผ่านได้
3. ธรรมขาติมนุษย์ ย่อมลืม จนทิ้งรหัสผ่านไว้ในที่ต่างๆ และธรรมชาติมนุษย์เช่นเดียวกันที่มักชอบความง่าย ใช้รหัสผ่านเดียวกันกับหลายบริการ (หรือแม้แต่หลายชื่อบัญชีผู้ใช้) ที่เรียกว่า Password Reuse
ที่ต่างๆ มีทั้งที่พบได้ง่ายด้วยการ grep -ERai ‘username|password’ * ตรงๆ ไปจนถึง
– เก็บอยู่ในไฟล์บีบอัด .zip, .7z ที่ใช้รหัสผ่านเดาง่ายเปิดดูได้ผ่านทูล fcrackzip, zip2john + john หรือ Reuse จากรหัสที่ได้มาจากที่อื่น
– เก็บแบบ Hardcoded ในโค้ดโปรแกรมที่หลงทิ้งไว้บนเครื่อง ไม่ว่าจะเป็นไฟล์ config.php app.js ตรงๆ หรือซ่อนอยู่ใน .git githistory git commit หรือแม้แต่ .env ก็ตาม
– มีบันทึกในคำสั่งที่ผู้ใช้ปัจจุบันเคยสั่งก่อนหน้า ที่เวลาเราเข้ามาในเชลล์ได้แล้ว ลองกดปุ่มลูกศรขึ้นไปเรื่อยๆ ถ้าไม่มีการปิด History ก็มักเจอคำสั่งเก่าที่น่าสนใจ โดยเฉพาะที่พิมพ์ข้อมูล username กับ password ในบรรทัดเดียวกับข้อความ (inline) ทั้งใน Powershell (เก็บใน PSReadline ของโฟลเดอร์ยูสเซอร์นั้น) และใน bash/zsh (มีในไฟล์ .bash/zsh_history ของโฟลเดอร์โฮมของยูสเซอร์นั้นๆ เช่นกัน)
– เก็บในฐานข้อมูล โดยเฉพาะตารางเกี่ยวกับ user (ที่อาจได้รหัสเข้าฐานข้อมูลจากที่ Hardcoded ในโค้ดคอนฟิกโปรแกรมอีกทีหนึ่ง หรือซ่อนเปิดพอร์ตเซอร์วิสไว้เฉพาะภายในเครื่องที่ถ้าไม่มีโปรแกรมเปิดบนเครื่องเป้าหมายโดยตรง ก็ต้องใช้ ssh -L ฟอร์เวิร์ดพอร์ตออกมาเปิดจากเครื่องเราข้างนอกอีกทีหนึ่ง)
ซึ่งคนเรามักจะใช้รหัสผ่านกับหลายบริการ เราจึงมักนำรหัสผ่านที่เจอมาลิสต์อยู่ในไฟล์เดียวกัน เช่น password.txt ใช้ Password Spray ร่วมกับ username.txt เพราะการ Reuse มีโอกาสใช้ปนกันแม้คนละชื่อบัญชีผู้ใช้ก็ได้ด้วย
4. PoC หรือสคริปต์ Exploit มักไม่สามารถเอามาใช้ได้ตรงๆ กับระบบเป้าหมายถ้าไม่พลิกแพลง
นึกถึงกรณีจริง ระบบมี WAF ที่กรองเปย์โหลดมาตรฐานพวก Injection ต่างๆ แต่มักไม่กรองแค่อักขระเดียวที่เราใช้เทส เช่น Single Quote (‘) ทำให้บางครั้งเราเจอว่ามีโอกาสทำ SQL Injection แต่เปย์โหลดในลิสต์สำเร็จรูปใช้สเปรย์ไม่ผ่าน
เราจึงต้อง “ปั้น” เปย์โหลด เช่น Encoding URL, Base64, Octet ฯลฯ ไม่ว่าชั้นเดียวหรือหลายชั้นเพื่อหาทางหลบ Blacklist เป็นต้นนะครับ
การนำสคริปต์หรือ PoC จากที่อื่นมาใช้ เราจำเป็นต้องทำความเข้าใจหลักการทำงาน เพราะหลายครั้งนอกจากการฝังค่าคงที่หรือตัวแปรในสคริปต์ที่ไม่สอดคล้องกับระบบเป้าหมายของเราจริง เช่น พาธ URI, เลขพอร์ต, รหัสผ่าน ฯลฯ แล้ว ยังเสี่ยงต่อการถูกฝังโค้ดอันตรายจากที่อื่นจนสร้างผลกระทบกับระบบเป้าหมายแบบที่เราไม่ตั้งใจด้วย
เหมือนกับสมัยนี้ Vibe coding สคริปต์ Exploit หรือทูลได้เอง เราก็ต้องทำความเข้าใจและตรวจสอบความปลอดภัยของโค้ดที่ AI สร้างขึ้นมาให้ดีก่อนนำไปใช้เช่นกันครับผม
5. คิดเสมอว่าระบบเป้าหมายอ่อนไหว และมีระบบป้องกันที่ตรวจจับที่แข็งแกร่งเสมอ
เพราะของจริงไม่เหมือนแล็ปที่เล่นกันบน THM, HTB ระบบลูกค้ามีข้อจำกัดที่ต้องคุยกำหนดสโคปให้ชัดเจนว่าทำอะไรได้ไม่ได้ เพื่อเลี่ยงการสร้างความเสียหายแก่ระบบที่อ่อนไหวโดยเฉพาะระบบที่ใช้งานจริงปัจจุบัน (Production Environment) จะเน้นการสแกนด้วยทูลอัตโนมัติที่ใช้ความเร็วพร้อมๆ กัน อย่างน้อยก็กระทบกับทรัพยากรระบบที่อาจเกินขีดจำกัดที่ลูกค้ายอมรับได้
และที่สำคัญกว่านั้น การโจมตีจริงย่อมพยายามทุกวิถีทางที่เลี่ยงการตรวจจับ ซึ่งเป็นมายด์เซ็ตที่ผู้เริ่มต้นพัฒนาทักษะทดสอบเจาะระบบจะยังไม่ได้ให้ความสำคัญมากเท่าที่ควร ตัวอย่างเช่น การสแกนช่องโหว่ด้วย nmap NSE Script, ทูลสแกนพาธ Gobuster, Feroxbuster, ทูล Exploit อัตโนมัติอย่าง SQLmap ด้วยการปล่อยให้รันแบบดีฟอลต์ ย่อมขึ้นชื่อทูลใน HTTP Header ส่วน User-Agent ชัดเจน จนระบบการป้องกันที่ใข้ในองค์กรทั่วไปตอนนี้ตรวจจับและป้องกันได้ง่ายๆ
ผู้ทดสอบจึงต้องทำความเข้าใจระบบป้องกันในตลาด เช่น EDR/XDR, WAF เพื่อปรับแต่งรูปแบบการทดสอบโจมตีให้สอดคล้องกับความยากง่ายในการตรวจจับตามหลัก Pyramid of Pain ของ Indicator of Compromise (IoC) เป็นต้น เช่น ถ้าอัพโหลดทูลสำเร็จรูปอย่าง Powerview, Mimikatz ก็ควรปรับแต่งให้อย่างน้อยชื่อไฟล์ไม่ผิดสังเกต หรือ File Hash ไม่ตรงกับค่ามาตรฐานที่ผลิตภัณฑ์ความปลอดภัยในตลาดตรวจเจอได้ (ตรวจผ่าน VirusTotal เป็นต้น)
6. สิ่งที่เกิดขึ้นในระบบคอมพิวเตอร์ล้วนมีเหตุผล เราต้องเรียบเรียงเขียนที่มาที่ไปได้ ให้ลูกค้านำวิธีทดสอบของเราไปทำซ้ำด้วยสภาพแวดล้อมเดียวกันแล้วได้ผลแบบเดียวกับเรา (Reproducable)
จึงเป็นที่มาของอีกวลียอดฮิตว่า
“อยากทำเพนเทส ชอบเขียนรายงานไหม”
ซึ่งจริงๆ ไม่ได้จำกัดแค่รายงานส่งลูกค้า แต่แม้แต่ช่วงการเรียนรู้พัฒนาทักษะของตนเอง ก็จำเป็นต้องคอยจดบันทึกเรียบเรียงความคิดควบคู่กันไป ที่ทั้งช่วยให้ไม่ลืมง่าย และยังสามารถกลับมาดูสรุปในแบบของเราเพื่อทำความเข้าใจ นำไปใช้ได้อย่างรวดเร็ว
ที่สำคัญกว่านั้นคือ เป็นการฝึกนิสัยให้คอยบันทึกภาพหน้าจอ จดเก็บหลักฐาน (Evidence) ครบตลอดขั้นตอน ณ เวลาทดสอบ เพราะหลายครั้งที่เรามักพลาด เก็บไม่ครบ เมื่อจะเข้าไปเก็บหลักฐานเพิ่มเติมอีกครั้งก็ไม่สามารถทำได้แล้ว (เช่น กรณีที่ลูกค้าเปิดให้เข้าทดสอบที่หน้างานของลูกค้า (On-site) แค่ภายในระยะเวลาที่จำกัด หรือกรณีสภาพแวดล้อมระบบทดสอบ (UAT) ที่มีการปรับเปลี่ยนตลอดเวลา)
ทั้ง 6 หลักการข้างต้นนี้ สังเกตได้ว่าในการสอบใบประกาศรับรองแบบปฏิบัติของค่ายที่ได้รับความเชื่อถือจากหน่วยงานต่างๆ (จนนำไปใส่ใน TOR) ต่างพยายามวัดหลักการคิดหรือ Mindset เหล่านี้ แบบที่ไม่ต้องการให้ยึดติดกับทูล เทคนิค รูปแบบของแล็ปทั้งสิ้น การฝึกทักษะเหล่านี้ย่อมปูพื้นฐานสำคัญในการต่อยอด โดยเฉพาะในยุคที่เทคโนโลยีเปลี่ยนแปลงอย่างรวดเร็วนี้ได้ครับผม