ระวัง มัลแวร์ปลอม แอป Maccy ที่แอบขโมยข้อมูลองค์กร

Fake Maccy Stealer: เมื่อ Clipboard Manager ปลอม เปลี่ยน Mac ให้กลายเป็นแหล่งขโมย Credential

ลองนึกภาพเช้าวันทำงานธรรมดาของ Developer คนหนึ่ง เขากำลังตั้งค่า Mac เครื่องใหม่ จึงเปิด Search Engine แล้วค้นหาคำว่า Maccy ซึ่งเป็น Clipboard manager แบบ Open-source ที่ได้รับความนิยมบน macOS

ผลการค้นหาปรากฏเว็บไซต์ที่ดูเหมือนของจริง ชื่อ Domain ก็แทบไม่ต่างกัน หน้าเว็บดูน่าเชื่อถือ มีปุ่ม Download พร้อมใช้งาน เขาคลิก ดาวน์โหลด maccy.dmg เปิดไฟล์ และทำตามคำแนะนำบนหน้าจอ

ไม่กี่วินาทีต่อมา ทุกอย่างดูเหมือนจะจบลงตามปกติ

ไม่มีหน้าต่างแปลกๆ ไม่มี Error ไม่มีอาการเครื่องค้าง และไม่มีสัญญาณชัดเจนว่า Mac เครื่องนี้เพิ่งถูกเจาะ

แต่เบื้องหลัง สิ่งที่ถูกติดตั้งลงไปไม่ใช่ Maccy มันคือ Infostealer ที่กำลังอ่าน Keychain, Credential และ Cookie จาก Browser รวมถึงข้อมูลที่อยู่ใน Clipboard ซึ่งอาจเป็น Password, 2FA Code, API Token หรือข้อมูลสำคัญที่ผู้ใช้เพิ่ง Copy มาเมื่อไม่กี่นาทีก่อน

ที่น่าสนใจกว่านั้นคือ Malware ไม่ได้ซ่อนตัวด้วยชื่อประหลาด มันเลือกปลอมตัวเป็นสิ่งที่ผู้ใช้ Mac เห็นทุกวัน

"Finder" นี่คือแคมเปญ Malware บน macOS ที่ถูกเรียกภายในว่า MacOSapp1 และความน่าสนใจของมันไม่ได้อยู่แค่การสร้างเว็บไซต์ปลอม แต่คือการนำองค์ประกอบที่ผู้ใช้คุ้นเคยและเชื่อถืออยู่แล้ว ตั้งแต่ Search Engine, Script Editor ไปจนถึง Finder และ Login Items มาเชื่อมต่อกันเป็น Attack chain ที่แนบเนียน

จุดเริ่มต้น: Maccy ที่เหมือนของจริงแทบทุกอย่าง

Maccy ตัวจริงเป็น Clipboard manager แบบ Open-source ดาวน์โหลดได้จาก maccy.app และเผยแพร่โดย Publisher ที่มี Apple Developer ID อย่างถูกต้อง ผู้โจมตีจึงไม่ได้สร้างชื่อผลิตภัณฑ์ใหม่ขึ้นมา แต่เลือกสร้างสิ่งที่ “เกือบเหมือนของจริง” Domain ที่ใช้คือ: maccyapp[.]com หากมองผ่านๆ ชื่อนี้แทบไม่ต่างจาก maccy.app

จากนั้นผู้โจมตีสร้างเว็บไซต์ให้มีหน้าตาคล้ายกับโครงการจริง และใช้ SEO ช่วยผลักเว็บไซต์อันตรายให้ปรากฏใกล้กับเว็บไซต์จริงบน Search Engine ลองนึกภาพผู้ใช้ที่กำลังรีบติดตั้งเครื่องมือก่อนเริ่มงาน เขาอาจไม่ได้ตรวจ URL ทีละตัวอักษร แต่ใช้สิ่งที่คุ้นเคยเป็นตัวตัดสินว่า “ชื่อถูก หน้าตาถูก โปรแกรมถูก ก็น่าจะใช่” Social engineering ในกรณีนี้จึงไม่ได้พยายามสร้างเรื่องที่หวือหวา แต่ใช้ ความคุ้นเคย เป็นเครื่องมือ มีรายละเอียดหนึ่งที่ช่วยแยกของจริงออกจากของปลอมได้อย่างชัดเจน Payload จากเว็บไซต์ปลอมถูกแจกจ่ายเป็น: maccy.dmgแต่ Maccy ตัวจริง ไม่ได้เผยแพร่ Release ในรูปแบบ DMG Release บน GitHub ของโครงการใช้: Maccy.app.zipดังนั้น หากผู้ใช้ดาวน์โหลด Maccy แล้วได้ไฟล์ .dmg นั่นคือสัญญาณผิดปกติที่ควรหยุดตรวจสอบทันที

เปิด DMG แล้วเจอ Script Editor จุดที่ Attack chain เริ่มทำงาน

ปกติเมื่อเปิด DMG ของ Application บน macOS ผู้ใช้อาจคาดว่าจะเห็น Application bundle หรือขั้นตอนลาก App เข้า Applications

แต่ maccy.dmg ปลอมกลับพาผู้ใช้ไปพบกับ Apple Script Editor

บนหน้าจอมี Script สั้นๆ พร้อม URL ของ Maccy บน App Store จริง และคำแนะนำให้กด:

⌘ + R

หรือคลิก Run เพื่อติดตั้งโปรแกรม

ตรงนี้เป็น Social engineering ที่น่าสนใจ เพราะ URL ของ App Store จริงทำหน้าที่เหมือน “ตราประทับความน่าเชื่อถือ”

ผู้ใช้อาจคิดว่า

“มันอ้างถึง App Store จริง ก็คงไม่มีอะไร”

แต่ Script ที่มองเห็นไม่ใช่สิ่งสำคัญ Payload จริงคือ JavaScript for Automation (JXA) ที่ถูก Obfuscate อย่างหนัก และซ่อนอยู่ด้านล่างด้วย Whitespace padding

พูดง่ายๆ คือ เหมือนมีคนยื่นเอกสารหนึ่งหน้าให้เราเซ็น ด้านบนมีข้อความไม่กี่บรรทัดที่ดูไม่มีพิษภัย แต่เนื้อหาที่ต้องการจริงๆ ถูกซ่อนไว้ในพื้นที่ที่เราไม่ได้เลื่อนลงไปดู JXA ดังกล่าวใช้หลายเทคนิคประกอบกัน เช่น การกลับ String, การคำนวณ XOR ตัวอักษร และ URI-encoded Function() constructors เพื่อประกอบคำสั่งที่จะถูก Execute จริง เมื่อผู้ใช้กด Run คำสั่งจึงไม่ได้ทำงานผ่าน Terminal แต่มันทำงาน ภายใน Process ของ Script Editor และนี่คือจุดสำคัญของแคมเปญนี้

ทำไมการใช้ Script Editor จึงน่าสนใจในมุม Security?

มาตรการป้องกัน Fake-installer lure รุ่นใหม่ของ Apple ให้ความสำคัญกับพฤติกรรมที่เกี่ยวข้องกับ Terminal paste prompt เนื่องจากเป็นเส้นทางที่ ClickFix และแคมเปญลักษณะใกล้เคียงกันนิยมใช้ แต่แคมเปญนี้เปลี่ยนสนาม แทนที่จะพยายามหลอกผู้ใช้ให้ Copy คำสั่งไปวางใน Terminal มันใช้ Script Editor ซึ่งเป็น Application ที่ Apple ลงนามเองและผู้ใช้คุ้นเคยอยู่แล้ว macOS ยังไม่ได้ปล่อยให้ Script ทำงานทันทีโดยไม่มีคำเตือน ผู้ใช้จะได้รับ Prompt แจ้งว่า Script มาจาก Developer ที่ไม่รู้จัก และถามว่าจะดำเนินการต่อหรือไม่

แต่ปัญหาอยู่ที่บริบทผู้ใช้เพิ่งถูกเว็บไซต์บอกว่า “ให้กด Run เพื่อติดตั้ง Maccy” ดังนั้น Prompt ที่ควรทำหน้าที่เป็นกำแพงป้องกัน อาจกลายเป็นเพียงปุ่มอีกหนึ่งปุ่มในขั้นตอนติดตั้งที่ผู้ใช้คาดว่าจะต้องกดผ่านอยู่แล้ว เมื่ออนุมัติแล้ว โค้ดสามารถ Execute ภายใน Process context ของ Script Editor โดยไม่มีการตรวจสอบ Quarantine, Paste หรือ Notarization เพิ่มเติมต่อสิ่งที่ Script สร้างขึ้นใน Memoryกล่าวอีกแบบหนึ่งคือ Attack chain นี้ไม่ได้พยายามพังกำแพง มันพยายามทำให้ผู้ใช้เปิดประตูให้เอง

ก่อนโจมตี Malware ขอรู้ก่อนว่า “เครื่องนี้อยู่ที่ไหน”

ก่อนเริ่มขั้นตอนติดตั้ง JXA Script จะตรวจสอบข้อมูลด้าน Geographic สามส่วนแยกจากกัน ได้แก่

• System time zone
• Country code
• ภาษา Keyboard input

หากพบว่าเครื่องอยู่ใน Russia, Belarus, Kazakhstan, Armenia, Azerbaijan, Kyrgyzstan, Moldova, Tajikistan, Uzbekistan, Turkmenistan หรือ Georgia Malware จะหยุดทำงานอย่างเงียบๆ นอกจากนี้ยังมีการตรวจสอบ System architecture เพื่อแจ้ง C2 ว่าควรส่ง Binary แบบใดกลับมา

Geofencing ในลักษณะนี้มีความหมายในเชิง Threat intelligence เพราะการหลีกเลี่ยงประเทศในกลุ่ม Commonwealth of Independent States เป็นรูปแบบการปกป้องตัวเองที่มีการบันทึกไว้ใน Malware operator ที่พูดภาษารัสเซียอย่างไรก็ตาม จุดนี้ควรตีความอย่างระมัดระวัง มันเป็น เบาะแสเกี่ยวกับรูปแบบการดำเนินงาน มากกว่าจะเป็นหลักฐานที่เพียงพอสำหรับระบุตัวผู้โจมตีโดยตรง

Finder ตัวที่สอง: Malware ที่เลือกซ่อนตัวอยู่ในสิ่งที่คุ้นเคยที่สุด

หากเครื่องผ่าน Geo check Dropper จะเขียน ARM64-native Mach-O binary ที่ Compile ด้วย Rust ลงใน:

~/Library/Application Support/com.apple.finder.monitor/Finder.app/Contents/MacOS/F8C06C86

Path นี้ดูธรรมดา แต่เมื่อแยกดูทีละส่วนจะเห็นว่ามีการออกแบบมาอย่างจงใจ

1. com.apple.finder.monitor

ชื่อนี้เลียนแบบรูปแบบ Reverse-DNS ที่ Apple ใช้กับ System service

สำหรับผู้ใช้ทั่วไป หรือแม้แต่ผู้ดูแลระบบที่กำลังไล่ดูไฟล์จำนวนมาก คำว่า com.apple อาจทำให้ Directory นี้ดูเหมือน Component ของระบบ

2. Finder.app

แทนที่จะใช้ชื่อ Malware แปลกๆ ตัว Bundle ถูกตั้งชื่อว่า Finder

3. ใช้ Finder icon ของจริง

Malware Copy Icon มาจาก:

/System/Library/CoreServices/Finder.app/Contents/Resources/Finder.icns

ผลคือชื่อก็เหมือน Icon ก็เหมือน และหน้าตาก็ดูเหมือน Component ที่ควรอยู่บน Mac

4. Executable ใช้ชื่อ Hex แบบสุ่ม

ในตัวอย่างที่วิเคราะห์พบชื่อ:

F8C06C86

Executable ภายในเชื่อว่าใช้ชื่อ Hex แปดตัวที่สร้างใหม่ต่อ Host

ดังนั้น Defender ที่พึ่งชื่อไฟล์แบบตายตัวเป็น IOC อาจตรวจจับได้ยากขึ้น เพราะเครื่องหนึ่งอาจไม่ได้ใช้ชื่อเดียวกับอีกเครื่องหนึ่ง

เมื่อ Gatekeeper บอกว่า “ไม่ผ่าน” แต่ Malware ยังทำงานได้

Binary นี้ถูกลงนามแบบ Ad-hoc ไม่มี Apple Developer ID และไม่มี Team Identifier หากนำ Binary ไปประเมินตรงๆ ด้วย:

spctl --assess

Gatekeeper จะปฏิเสธ ฟังดูเหมือนระบบป้องกันควรหยุด Malware ได้ แต่ปัญหาคือ เมื่อ Binary ถูก Drop ลงเครื่อง ผู้ใช้ได้อนุญาต Execution ผ่าน Script Editor ไปก่อนแล้ว และ Gatekeeper ไม่ได้กลับมาประเมิน Binary ดังกล่าวซ้ำในเส้นทาง Execution นี้ นี่ทำให้เราเห็นความแตกต่างระหว่างคำถามสองข้อที่สำคัญมากใน Endpoint security

“ไฟล์นี้ผ่าน Security assessment หรือไม่?”

กับ

“ไฟล์นี้สามารถถูก Execute ผ่านเส้นทางอื่นได้หรือไม่?”

สองคำถามนี้ไม่จำเป็นต้องมีคำตอบเหมือนกัน

เบาะแสสำคัญ คือ Activity Monitor อาจมี Finder สองตัว และนั่น

เมื่อ Malware ทำงาน จะเกิด Process อีกตัวที่ชื่อ:

Finder

ดังนั้นใน Activity Monitor ผู้ใช้อาจเห็น Finder สอง Process ทำงานอยู่พร้อมกัน ตัวหนึ่งคือ Finder จริงของ macOS อีกตัวคือ Malware ชื่อ Process เพียงอย่างเดียวจึงแทบไม่ช่วยอะไร เพราะทั้งคู่แสดงเป็น “Finder” สิ่งที่แยกออกจากกันได้คือ Executable path

Finder ของจริงควรมาจาก:

/System/Library/CoreServices/Finder.app

ถ้ามี Process ชื่อ Finder แต่ Execute มาจาก:

~/Library/Application Support/com.apple.finder.monitor/

หรือ Path อื่นที่ไม่ใช่ System path นั่นคือสัญญาณ Compromise ที่มีความน่าเชื่อถือสูง นี่เป็นตัวอย่างที่ดีว่าทำไม Detection ที่ดูแค่ Process name จึงไม่เพียงพอ สำหรับ SOC หรือ Endpoint administrator สิ่งที่ควร Correlate คืออย่างน้อย Process name + Executable path + Code signing information

Persistence ที่ไม่เดินตามเส้นทางยอดนิยม

Malware ยังต้องตอบคำถามอีกข้อหนึ่ง “ถ้าผู้ใช้ Restart เครื่อง จะกลับมาทำงานอย่างไร?” แทนที่จะใช้ Persistence แบบที่ Malware บน macOS ใช้กันมายาวนาน เช่น:

~/Library/LaunchAgents

หรือ

/Library/LaunchDaemons

แคมเปญนี้ลงทะเบียนตัวเองผ่าน Login Items โดยใช้ LSSharedFileList และ SMAppService APIs

เมื่อเปิด:

System Settings → General → Login Items & Extensions

ผู้ใช้สามารถมองเห็นรายการดังกล่าวได้ แต่ชื่อที่ปรากฏคือ:

Finder

เพราะ Display name ถูกดึงมาจาก Bundle ที่ปลอมแปลงไว้ ลองคิดในมุมผู้ใช้ทั่วไป หากเปิด Login Items แล้วเห็นชื่ออย่าง Stealer, UpdaterXYZ หรือชื่อ Application ที่ไม่รู้จัก อาจเกิดความสงสัยทันที แต่ถ้าเห็นคำว่า Finder หลายคนอาจคิดว่าเป็นส่วนหนึ่งของ macOS และปล่อยผ่าน ในมุม Detection นี่เป็นอีกประเด็นที่น่าสนใจ เพราะ EDR และ AV จำนวนมากให้ความสำคัญกับ LaunchAgent และ LaunchDaemon ในฐานะ Persistence mechanism มานาน แต่แคมเปญนี้ไม่สร้างอะไรไว้ในสองตำแหน่งนั้นเลย ดังนั้น การตรวจสอบ Persistence บน macOS โดยมองเฉพาะ LaunchAgents และ LaunchDaemons อาจไม่เพียงพออีกต่อไป

สิ่งที่ Malware ต้องการ ไม่ใช่แค่ Clipboard

เมื่อฝังตัวสำเร็จ Malware ทำงานทั้งหมดภายใต้ User context โดยไม่จำเป็นต้องยกระดับสิทธิ์ก่อนเริ่มเก็บข้อมูล

เป้าหมายประกอบด้วย:

• macOS Keychain ผ่าน SecItemCopyMatching API chain
• Credential และ Cookie จาก Chrome, Firefox และ Safari ผ่าน SQLite direct access
• Apple Notes
• Clipboard ผ่าน NSPasteboard.generalPasteboard

และ Clipboard คือส่วนที่ทำให้การเลือก Maccy มาเป็นเหยื่อล่อดูสมเหตุสมผลอย่างมาก

ลองนึกถึง Clipboard ของ Developer หรือทีม IT ในหนึ่งวัน

09:10 น. Copy Password ชั่วคราว

09:30 น. Copy 2FA Code

10:15 น. Copy API Token เพื่อทดสอบระบบ

ช่วงบ่าย Copy SSH Key หรือข้อมูลสำหรับ Login เข้า Environment ต่างๆ

สำหรับผู้ใช้ทั่วไป Clipboard อาจมีเพียงข้อความหรือ Link

แต่สำหรับ Developer, IT administrator หรือ Security professional มันอาจทำหน้าที่เหมือน พื้นที่พัก Credential ชั่วคราว โดยที่เจ้าของเครื่องแทบไม่รู้สึกตัว ดังนั้น การปลอมตัวเป็น Clipboard manager จึงไม่ใช่เพียงการเลือก Application ยอดนิยมมาใช้เป็นเหยื่อ ตัว Lure และเป้าหมายของ Payload สอดคล้องกันโดยตรง ผู้ใช้กำลังติดตั้งโปรแกรมที่คิดว่าจะช่วยจัดการ Clipboard แต่สิ่งที่ติดตั้งกลับเป็นโปรแกรมที่กำลังอ่าน Clipboard ของเขาเอง

ข้อมูลถูกส่งออกไปอย่างไร?

ข้อมูลที่รวบรวมจะถูก Stage ไว้ใน:

/private/tmp

จากนั้นเข้ารหัสด้วย ChaCha20-Poly1305 ซึ่งเป็น IETF AEAD variant ที่กำหนดไว้ใน RFC 8439 ก่อนส่งผ่าน HTTPS ไปยัง:

https://avengerflow[.]com/api/sync

C2 domain คือ:

avengerflow[.]com

โดยใช้ Cloudflare fronting ไปยัง:

172.67.210.219
104.21.93.138

และพบ Backend origin บน AWS EC2 ที่:

51.92.110.33

Beacon จะมี Campaign identifier:

MacOSapp1

ตามด้วย Encrypted blob แต่สิ่งที่ทำให้ Incident นี้ร้ายแรงกว่าการเป็น Infostealer ทั่วไป คือ Communication channel ไม่ได้ส่งข้อมูลออกอย่างเดียว C2 สามารถส่ง Encrypted response กลับมายัง Implant นั่นหมายความว่าเครื่องที่ติด Malware ไม่ควรถูกมองเพียงว่า “Password อาจรั่ว” แต่ควรถูกมองว่า Endpoint เครื่องนี้อาจอยู่ภายใต้การควบคุมของผู้โจมตีแล้ว Credential harvesting เป็นเพียงความสามารถแรกที่ถูกสังเกตพบ

Indicators of Compromise

หากดู Attack chain ทั้งหมด เราเรียนรู้อะไรจาก Fake Maccy Stealer นี้?

สิ่งที่ทำให้ Fake Maccy น่าสนใจไม่ใช่เทคนิคใดเทคนิคหนึ่ง แต่คือการนำหลายองค์ประกอบมาประกอบกัน

Search Engine → Domain ปลอม → DMG → Script Editor → JXA → Fake Finder → Login Items → Credential harvesting → C2

แต่ละขั้นไม่ได้ดูผิดปกติรุนแรงเมื่อมองแยกกัน Domain คล้ายของจริง, Script Editor เป็นของ Apple, Finder เป็นชื่อที่ทุกคนรู้จัก, Login Item ก็เป็น Feature ปกติของ macOS, HTTPS ก็เป็น Traffic ที่พบได้ทั่วไป ความอันตรายเกิดขึ้นเมื่อองค์ประกอบที่ดู “ปกติ” เหล่านี้ถูกต่อเข้าด้วยกันเป็น Attack chain นี่จึงเป็นเหตุผลว่าทำไมการป้องกัน Endpoint สมัยใหม่ไม่ควรพึ่ง IOC หรือชื่อ Process เพียงอย่างเดียว แต่ต้องมอง Context และความสัมพันธ์ระหว่างพฤติกรรม Finder ไม่ใช่สิ่งผิดปกติ แต่ Finder ที่รันจาก User Library เป็นอีกเรื่องหนึ่ง Login Item ไม่ใช่สิ่งผิดปกติ แต่ Login Item ชื่อ Finder ที่ชี้ไปยัง Bundle ซึ่งไม่มี Apple Developer ID เป็นอีกเรื่องหนึ่ง Script Editor ไม่ใช่ Malware แต่ Script Editor ที่นำไปสู่การ Drop Binary และสร้าง Persistence เป็นอีกเรื่องหนึ่ง Detection ที่ดีจึงไม่ได้ถามเพียงว่า “Process นี้ชื่ออะไร?” แต่ต้องถามต่อว่า

“มันมาจากไหน ใครสร้างมัน มันรันอย่างไร และหลังจากรันแล้วทำอะไรต่อ?”

วิธีรับมือกับ Fake Maccy Stealer

สำหรับผู้ใช้ Mac

ดาวน์โหลด Maccy จากแหล่งที่เชื่อถือได้เท่านั้น ได้แก่ maccy.app, GitHub Releases ของโครงการ หรือ Mac App Store ของ Publisher Alexey Rodionov ซึ่งมี Team Identifier:

MN3X4648SC

สิ่งที่จำง่ายที่สุดคือ:

Maccy จริงเผยแพร่เป็น Maccy.app.zip ไม่ใช่ DMG

หากค้นหา Maccy แล้วเว็บไซต์ขอให้ดาวน์โหลด .dmg ก่อนเปิด Script Editor และสั่งให้กด ⌘ + R นั่นไม่ใช่ขั้นตอนติดตั้งปกติที่ควรดำเนินการต่อ

สำหรับผู้ดูแลระบบและ SOC

ควร Block:

maccyapp[.]com
avengerflow[.]com

ที่ชั้น DNS และ Proxy พร้อมตรวจ Endpoint จาก SHA-256 และ File path ใน IOC อีกจุดที่ควรตรวจคือ Login Items โดยเฉพาะรายการที่แสดงชื่อ Finder อย่าตัดสินจากชื่อ Process เพียงอย่างเดียว ให้ตรวจ Executable path ด้วย Finder ของระบบควรมาจาก:

/System/Library/CoreServices/Finder.app

หากพบ Process ชื่อ Finder จากตำแหน่งอื่น โดยเฉพาะ:

~/Library/Application Support/com.apple.finder.monitor/

ควรถือเป็นสัญญาณ Compromise ที่มีความน่าเชื่อถือสูงและเข้าสู่กระบวนการ Incident response

ManageEngine Malware Protection Plus และ Endpoint Central สามารถ Block การส่ง Malware และ C2 infrastructure ที่ชั้น Network, Flag การปลอมตัวเป็น Finder ที่ไม่มีลายเซ็นในชั้น Application และแสดง Login Item persistence entry เพื่อให้ผู้ดูแลแก้ไขจากส่วนกลางบน Endpoint ที่บริหารจัดการ

และหากยืนยันว่าเครื่องถูก Compromise แล้ว ไม่ควรจบ Incident ด้วยการลบ Malware เพียงอย่างเดียว

ควรถือว่า Credential ที่ Malware สามารถเข้าถึงได้อาจถูกเปิดเผยแล้ว ไม่ว่าจะเป็นข้อมูลใน Keychain, Password ที่บันทึกใน Browser, Clipboard history และ Web session ที่ยังใช้งานอยู่

เพราะในเหตุการณ์นี้ สิ่งที่ถูกขโมยอาจไม่ใช่เพียงข้อมูลใน Mac เครื่องหนึ่ง แต่คือ กุญแจที่ใช้เปิดประตูไปยังระบบอื่นต่อได้