August 3, 2020

Red Team Engagement: การขอ AWS ทำ Phishing Simulation และการทำ Infra ให้น่าเชื่อถือ

การทำ Phishing simulation นั้นเป็นกิจกรรมซึ่งมีลักษณะคล้ายกับการปรุงอาหาร สูตรอาหารหนึ่งสูตรสามารถปรุงได้หลายวิธีการและสร้างความอร่อยได้ในหลากหลายรูปแบบ การทำ Phishing simulation ก็มีปัจจัยซึ่งถูกแอบซ่อนไว้อยู่หลายปัจจัยที่จะช่วยการันตีในความสำเร็จของปฏิบัติการโดยอาศัยการพึ่งพาผู้ใช้บริการให้น้อยที่สุด มีปฏิบัติการที่เสมือนจริงที่สุดตามลักษณะภัยคุกคามที่เป็นไปได้ที่ผู้ใช้บริการของเราจะเผชิญ และคงไว้ซึ่งความลับของปฏิบัติการให้มากที่สุด

ปัจจัยที่มักได้รับความสนใจและความทุ่มเทเป็นอย่างสูงโดยเหล่า Red team มักจะล้อมอยู่ในประเด็นของการข้ามผ่านการตรวจจับและเฝ้าระวัง ซึ่งเราได้มีการพูดถึงไปบางส่วนแล้วในโพสต์ Red Team Engagement ที่ผ่านมา

ดูเทคนิคการทำ Phishing technique ให้แนบเนียนได้ที่โพสต์ Red Team Engagement: Phishing Techniques

อย่างไรก็ตามอีกหนึ่งปัจจัยที่มักถูกลืมหรือไม่ได้รับความสนใจมากเท่าไหร่นั้นคือชัยภูมิในการปฏิบัติการ หรือ Infrastructure ที่เราจะใช้ในการจำลองพฤติกรรมของภัยคุกคาม ซึ่งวันนี้เราจะมาพูดถึงทั้งในประเด็นของการเลือกและพัฒนาชัยภูมิให้เหมาะสม รวมไปถึงประเด็นในการใช้บริการของ AWS เป็นชัยภูมิในการจำลองการโจมตีครับ

Battle of Reputation

เมื่อพูดถึงประเด็นในเรื่องของ Infrastructure สำหรับการทำ Phishing simulation นั้น คำสำคัญซึ่งมีผลต่อความสำเร็จและความแนบเนียนของปฏิบัติการก็ยังคงเป็นคำเดิมๆ ตามตำรา Social engineering คือความน่าเชื่อถือ ระบบเฝ้าระวังและตรวจจับภัยคุกคามทางอีเมลมีการอาศัยปัจจัยอ้างอิงและการคำนวณทางสถิติมากมายเพื่อตัดสินว่าอีเมลที่ถูกซึ่งมาจากโดเมนใดโดเมนหนึ่งนั้นน่าจะเป็นอันตรายมากแค่ไหน บางส่วนของปัจจัยที่มักถูกใช้ในการช่วยระบบตัดสินใจนั้นได้แก่

  1. แหล่งอ้างอิงโดเมน (Reference) ยิ่งโดเมนนี้มีการปรากฎในอินเตอร์เน็ต และมีกิจกรรมซึ่งเกี่ยวข้องกับโดเมนดังกล่าวตลอดเวลา ความเชื่อถือก็จะยิ่งมากขึ้น
  2. สถานะการถูก Blacklist ของโดเมนหรือเครือข่ายที่เกี่ยวข้องกับหมายเลขไอพีแอดเดรสของเรา ถ้าเคยมีประวัติไม่ดีมาก่อน ความน่าเชื่อถือจะยิ่งต่ำ
  3. อายุของโดเมน โดเมนซึ่งมีอายุน้อย พึ่งถูกจดใหม่ไม่นาน ก็จะถือว่ามีความน่าเชื่อถือต่ำ
  4. Top-level domain ในกลุ่มของ TLD นั้นแน่นอนว่ามีส่วนซึ่งราคาถูก จดทะเบียนได้ง่าย ไม่มีการตรวจสอบมากมายอยู่ หากโดเมนเนมของเราอยู่ในกลุ่มนี้ก็อาจได้รับความน่าเชื่อถือที่ต่ำตามไปด้วย
  5. เป็นโดเมนเนมในกลุ่มของอีเมลฟรีหรือแบบอีเมลชั่วคราวหรือไม่ ถ้าส่งมาจากบริการแบบ Disposal อีเมลของเราก็จะมีความน่าเชื่อถือที่ต่ำ
  6. การตั้งค่า SPF/DKIM/DMARC ถ้ามีการตั้งค่าที่เหมาะสม อุปกรณ์หรือระบบบางประเภทจะถือว่ามีความน่าเชื่อถือสูง
  7. โปรโตคอลสำหรับรับส่งอีเมล ยิ่งมีการใช้ TLS และการพิสูจน์ตัวตนที่ถูกต้อง ก็อาจได้ความน่าเชื่อถือที่สูงตาม

จากรายการด้านบน ประเด็นที่เราจะยกมาพูดถึงกันวันนี้จะเน้นไปที่เรื่องที่ 2 คือการเลือก Infrastructure ที่มีพื้นฐานและความน่าเชื่อถือดีตั้งแต่แรก เพื่อให้ลดความเสี่ยงที่จะถูก Blacklist ทั้ง Subnet ตั้งแต่ยังไม่เริ่มปฏิบัติการครับ

Why AWS?

หมายเหตุ: AWS ไม่ได้สปอนเซอร์ Blog นี้

  • ผู้ให้บริการส่วนใหญ่ในไทยไม่ได้คำนึงถึงผลกระทบเท่าไหร่นักกับการถูก Blacklist ชุดหมายเลขไอพีแอดเดรสซึ่งส่งผลให้อีเมลมีโอกาสถูกระบุ Spam/Junk โดยทันที
  • ผู้ให้บริการต่างประเทศส่วนใหญ่ขยับไปทำระบบ Vetting เพื่อขออนุญาตส่งอีเมล ดังนั้นความ Responsive ของ Support จึงกลายมาเป็นประเด็นสำคัญ ถ้าถูก Approve ช้าก็อาจกระทบกับปฏิบัติการของเรา
  • เฟรมเวิร์คในการทำ Phishing simulation มากมายรองรับการใช้ Amazon SES ซึ่งเหมาะสมกับหากเป้าหมายเป็นองค์กรขนาดใหญ่ และถูกกว่าเมื่อเทียบกับเซอร์วิสอื่น เช่น Sendgrid

Removing Email Restriction on EC2

AWS มีแนวทางในการป้องกันการนำ Infrastructure มาใช้ในการโจมตีมานานแล้ว แต่การปรับเปลี่ยนล่าสุดซึ่งส่งผลต่อการใช้ระบบของ AWS ในปฏิบัติการคือการไม่อนุญาตให้ EC2 ใช้งานพอร์ต TCP/25 เป็นค่าเริ่มต้น นอกเสียจากจะมีการขออนุญาตใช้งานก่อน

ความก้ำกึ่งของประเด็นนี้อยู่ที่ AWS Acceptable Use Policy มีการระบุไว้อย่างชัดเจนว่าไม่ให้มีการใช้บริการของ AWS ในการกระทำซึ่งผิดกฎหมายที่รวมไปถึงการทำ Phishing ด้วย

แนวทางในการขออนุญาตเพื่อให้สามารถใช้ EC2 ในการรับ/ส่งอีเมลได้นั้น ผู้ใช้งานจะต้องมีการกรอกฟอร์มขออนุญาตโดยจะต้องอธิบายการใช้งานและ Use case โดยละเอียด ซึ่งสำหรับการทำ Phishing simulation ของเรานั้น ผมมี Best practice ในการขออนุญาตตามรายละเอียดดังนี้ครับ

  1. ใช้บัญชี AWS ที่ลงทะเบียนโดยอีเมลของบริษัท ให้มีความน่าเชื่อถือและสามารถยืนยันตัวตนได้ มีข้อมูล Billing ชัดเจน
  2. อธิบาย Use case โดยละเอียดในการใช้ EC2 เพื่อส่งอีเมล โดยจะต้องครอบคลุมประเด็นดังนี้
    1. จะเอาไปใช้ทำอะไร ในจุดประสงค์อะไร เช่น cybersecurity product/service demonstration, evaluation หรือ assessment
    2. EC2 จะถูกตั้งค่าอย่างไร ใช้ซอฟต์แวร์ใดในการส่งอีเมล เนื้อหาอีเมลเป็นอย่างไร ส่งหาใครบ้าง จำนวนกี่ฉบับต่อวัน จำนวนรวมเท่าไหร่ ใช้ถึงแค่ไหน
    3. การตั้งค่า EC2 หรือ Mail server จะมีการตั้งค่าอะไรบ้าง เช่น SPF, DKIM, DMARC หรือการป้องกันการสแปมในรูปแบบอื่นๆ
    4. ทำการ Allocate หมายเลขไอพีแอดเดรสแบบ Elastic IP เอาไว้ พร้อมจดทะเบียนโดเมนเนมที่จะใช้ส่งอีเมลเพื่อระบุในการตั้งค่าสำหรับ Reverse DNS ด้วย ค่าตรงนี้แนะนำให้ระบุลงในฟอร์มที่เรากรอกเพื่อให้ทาง AWS กำหนดค่าให้เราทันทีให้การขออนุญาตนั้นผ่าน
  3. เราจะมีการดำเนินการอย่างไรเพื่อให้แน่ใจว่าบัญชีของเราจะไม่ถูกเอาไปใช้เพื่อส่งอีเมลขยะ โดยสามารถพูดทั้งในประเด็นของการตั้งค่าบัญชี และการตั้ง Mail server ได้เช่น
    1. บัญชีถูกดูแลด้านความปลอดภัยอย่างไร แนะนำให้เปิด MFA และพูดถึงในประเด็นนี้พร้อมกับเรื่องความแข็งแกร่งของรหัสผ่านบัญชีด้วย
    2. จะควบคุมการเข้าถึง EC2 instance อย่างไร เช่น ตั้งค่า Security group ให้เฉพาะเครือข่ายในกลุ่มนี้เข้าถึงได้เท่านั้น
    3. จะป้องกันอย่างไรไม่ให้ลูกค้าของเราเองไปรีพอร์ตระบบ AWS เช่น อาจพูดถึงการมี NDA และการควบคุมปฏิบัติการ (work closely)
    4. เน้นในประเด็นของการตั้งด้านความปลอดภัยใน Mail server โดยเฉพาะเรื่อง SPF, DKIM และ DMARC รวมไปถึงการรับส่งอีเมล

กระบวนการ Vetting อาจใช้เวลา 1-2 วัน โดยหากข้อมูลไม่เพียงพอ ทาง AWS จะมีการส่ง Inquiry มาทางอีเมลซึ่งเราใช้เปิดบัญชี AWS เอาไว้เพื่อสอบถามข้อมูลเพิ่มเติม

AWS

ในกรณีที่คำอธิบายของเราเพียงพอ ทาง AWS จะส่งอีเมลมาแจ้งว่าได้ปลด Restriction พร้อมทั้งตั้งค่า Reverse DNS ให้แล้วตามตัวอย่างรูปด้านบนครับ