Tác nhân đe dọa lạm dụng Cloudflare Tunnel để phát tán RAT

 (proofpoint.com)
2 điểm bởi GN⁺ 2024-08-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hoạt động tội phạm mạng được quan sát từ tháng 2/2024 đã lạm dụng TryCloudflare Tunnel để phát tán mã độc; hoạt động tăng trong giai đoạn tháng 5–7 và các chiến dịch gần đây phần lớn dẫn tới Xworm
  • Cuộc tấn công dẫn người dùng từ URL hoặc tệp đính kèm trong email tới tệp .URL, sau đó cài đặt RAT qua WebDAV, LNK/VBS, BAT/CMD, gói cài đặt Python và các script
  • Trong tháng 6–7, Xworm chiếm tỷ trọng cao, nhưng các chiến dịch trước đó cũng dùng AsyncRAT, VenomRAT, GuLoader, Remcos; một số script Python chia nhỏ việc cài đặt nhiều payload
  • Các chiến dịch có quy mô từ hàng trăm đến hàng chục nghìn thư, ảnh hưởng tới hàng chục đến hàng nghìn tổ chức trên toàn cầu; sử dụng mồi nhử dạng nghiệp vụ như hóa đơn, yêu cầu tài liệu, giao hàng, thuế và nhiều ngôn ngữ
  • Hạ tầng Cloudflare tạm thời và việc đóng gói Python khiến việc chặn và gỡ bỏ khó hơn, nhưng để thực thi payload cuối cùng vẫn cần nhiều lần tương tác của người dùng như bấm liên kết, chạy tệp, giải nén

Cách lạm dụng TryCloudflare Tunnel

  • Hoạt động này là một cụm tội phạm mạng sử dụng Cloudflare Tunnels làm hạ tầng phân phối mã độc
  • Tính năng bị kẻ tấn công lạm dụng là TryCloudflare, cho phép tạo tunnel dùng một lần mà không cần tạo tài khoản
  • Tunnel hoạt động theo cách cho phép truy cập từ xa tới dữ liệu và tài nguyên bên ngoài mạng cục bộ, tương tự VPN hoặc SSH
  • Mỗi lần dùng TryCloudflare Tunnel, một subdomain ngẫu nhiên của trycloudflare[.]com sẽ được tạo
    • Ví dụ: ride-fatal-italic-information[.]trycloudflare[.]com
    • Lưu lượng tới subdomain đó được proxy qua Cloudflare tới máy chủ cục bộ của người vận hành
  • Việc lạm dụng TryCloudflare Tunnel đã bắt đầu được sử dụng rộng rãi vào năm 2023 và đang có xu hướng gia tăng trong giới tác nhân đe dọa tội phạm mạng

Chuỗi tấn công và payload

  • Phần lớn chiến dịch bắt đầu bằng URL trong tin nhắn hoặc tệp đính kèm dẫn tới tệp lối tắt Internet .URL
  • Khi .URL được thực thi, nó kết nối tới dịch vụ chia sẻ tệp bên ngoài để tải xuống tệp LNK hoặc VBS
    • Dịch vụ chia sẻ tệp bên ngoài thường sử dụng WebDAV
    • Một số bước staging tệp dùng trình xử lý giao thức search-ms để lấy LNK từ chia sẻ WebDAV
  • Sau đó LNK/VBS chạy tệp BAT hoặc CMD; tệp này tải xuống gói cài đặt Python và nhiều script Python, dẫn tới cài đặt mã độc
  • Thông thường, một PDF vô hại được hiển thị kèm theo để khiến người dùng nhầm là tài liệu hợp lệ
  • Gần như toàn bộ các chiến dịch quan sát trong tháng 6–7 đều phân phối Xworm
    • Các chiến dịch trước đó cũng phân phối AsyncRAT, VenomRAT, GuLoader, Remcos
    • Một số chiến dịch dẫn tới nhiều payload độc hại, trong đó mỗi script Python cài đặt một mã độc khác nhau

Quy mô chiến dịch và mồi nhử

  • Quy mô tin nhắn của các chiến dịch dao động từ hàng trăm đến hàng chục nghìn
  • Phạm vi ảnh hưởng trải rộng trên hàng chục đến hàng nghìn tổ chức trên toàn cầu
  • Ngoài tiếng Anh, các ngôn ngữ mồi nhử được quan sát gồm tiếng Pháp, tiếng Tây Ban Nha và tiếng Đức
  • Các chiến dịch Xworm, AsyncRAT, VenomRAT nhìn chung được triển khai với quy mô lớn hơn so với các chiến dịch phân phối Remcos hoặc GuLoader
  • Chủ đề mồi nhử tập trung vào các nội dung có khả năng được mở trong bối cảnh công việc
    • Hóa đơn
    • Yêu cầu tài liệu
    • Giao hàng
    • Thuế

Thay đổi chiến thuật và né tránh phát hiện

  • Chiến thuật, kỹ thuật và quy trình của các chiến dịch nhìn chung nhất quán, nhưng kẻ tấn công cố thay đổi một số phần của chuỗi tấn công để tăng độ tinh vi và khả năng né tránh phòng thủ
  • Các script hỗ trợ trong những chiến dịch ban đầu hầu như không có hoặc hoàn toàn không có obfuscation
    • Script còn chứa cả chú thích mô tả chi tiết chức năng của mã
  • Từ tháng 6/2024, mã bắt đầu có obfuscation
  • Hoạt động này chưa được quy kết cho một tác nhân đe dọa cụ thể đang được theo dõi; các chiến dịch liên quan được gom thành một cụm hoạt động dựa trên TTP

Chiến dịch ngày 28/5/2024

  • Chiến dịch ngày 28/5/2024 phân phối AsyncRAT và Xworm
  • Thư có chủ đề thuế chứa URL, và URL này dẫn tới tệp .URL được nén
  • Mục tiêu là các tổ chức pháp lý và tài chính, với tổng số thư dưới 50
  • Tệp .URL trỏ tới một tệp .LNK từ xa
  • Khi được thực thi, script hỗ trợ CMD gọi PowerShell để tải xuống gói Python được nén và script Python
  • Gói Python và script dẫn tới việc cài đặt AsyncRAT và Xworm

Chiến dịch ngày 11/7/2024

  • Chiến dịch ngày 11/7/2024 cũng sử dụng Cloudflare Tunnel để phát tán AsyncRAT và Xworm
  • Chiến dịch gồm hơn 1.500 thư, nhắm vào các tổ chức thuộc nhiều lĩnh vực như tài chính, sản xuất và công nghệ
  • Thư chứa tệp đính kèm HTML có truy vấn search-ms trỏ tới tệp LNK
  • Khi được thực thi, nó dẫn tới một tệp BAT đã bị obfuscate; tệp này gọi PowerShell để tải xuống gói cài đặt Python và script
  • Các thành phần được tải xuống dẫn tới việc chạy AsyncRAT và Xworm

Những điểm quan trọng về phòng thủ

  • Cloudflare Tunnel cho phép kẻ tấn công sử dụng hạ tầng tạm thời để mở rộng hoạt động, nhanh chóng tạo và gỡ các instance
  • Các instance Cloudflare tạm thời tạo ra điều kiện khó khăn hơn cho các biện pháp bảo mật truyền thống dựa vào danh sách chặn tĩnh và cho đội phòng thủ
  • Cách phân phối dựa trên script Python cần được đặc biệt chú ý
    • Khi đóng gói thư viện Python và trình cài đặt có thể thực thi cùng với script Python, mã độc có thể được tải xuống và chạy ngay cả trên host chưa cài sẵn Python
    • Các tổ chức không cần Python cho công việc cá nhân nên hạn chế việc sử dụng Python
  • Đây không phải lần đầu phần mềm được phân phối cùng với tệp độc hại
    • Gần đây, trong các chiến dịch mã độc dựa trên Java, đã quan sát thấy trường hợp đưa cả JAR và Java Runtime Environment vào ZIP để phần mềm cần thiết được cài đặt trước khi downloader hoặc dropper chạy
  • Việc thực thi payload cuối cùng đòi hỏi mức độ tương tác đáng kể từ nạn nhân
    • Bấm vào liên kết độc hại
    • Nhấp đúp vào nhiều tệp như LNK hoặc VBS
    • Giải nén script đã nén
    • Quá trình này cung cấp nhiều cơ hội để người nhận nhận diện hoạt động đáng ngờ và cắt đứt chuỗi tấn công
  • Ngày càng nhiều tác nhân đe dọa sử dụng WebDAV và Server Message Block(SMB) để staging và phân phối payload
  • Tổ chức nên giới hạn quyền truy cập tới dịch vụ chia sẻ tệp bên ngoài chỉ ở các máy chủ trong danh sách cho phép đã biết

Quy tắc phát hiện và chỉ báo xâm nhập

  • Emerging Threats ruleset có bao gồm phát hiện mã độc được xác định trong chiến dịch này
  • Quy tắc ví dụ:
    • 2853193 | ETPRO MALWARE Win32/Xworm V3 CnC Command – PING Outbound
    • 2852870 | ETPRO MALWARE Win32/Xworm CnC Checkin – Generic Prefix Bytes
    • 2852923 | ETPRO MALWARE Win32/Xworm CnC Checkin – Generic Prefix Bytes (Client)
    • 2855924 | ETPRO MALWARE Win32/Xworm V3 CnC Command – PING Outbound
    • 2857507 | ETPRO ATTACK_RESPONSE Suspicious HTML Serving Abused URL Linking Method Observed
  • Ví dụ chỉ báo xâm nhập:
    • spectrum-exactly-knitting-rural[.]trycloudflare[.]com: TryCloudflare Host, quan sát lần đầu vào tháng 5/2024
    • 157[.]20[.]182[.]172: IP C2 của Xworm, quan sát lần đầu vào tháng 5/2024
    • dcxwq1[.]duckdns[.]org: C2 của AsyncRAT, quan sát lần đầu vào tháng 5/2024
    • ride-fatal-italic-information[.]trycloudflare[.]com: TryCloudflare Host, quan sát lần đầu vào tháng 7/2024
    • todfg[.]duckdns[.]org: C2 của AsyncRAT, quan sát lần đầu vào tháng 7/2024
    • welxwrm[.]duckdns[.]org: C2 của Xworm, quan sát lần đầu vào tháng 7/2024
    • xwor3july[.]duckdns[.]org: C2 của Xworm, quan sát lần đầu vào tháng 7/2024

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-08-03
Các ý kiến trên Hacker News

  • Thời mà phần mềm độc hại được phát tán từ các domain .ru đáng ngờ hay từ IP lộ diện của các nhà cung cấp hosting “bulletproof” đã qua rồi
    Giờ đây kẻ tấn công cũng dùng hạ tầng mà ai cũng dùng như GCP, AWS, Azure, Cloudflare, và truy cập thiết bị bằng cùng loại VPN mà ông bà bạn dùng để xem Netflix
    Internet đang dần chuyển sang một mô hình trong đó địa chỉ IP và tên miền ngày càng vô dụng như chỉ dấu bảo mật; bạn không thể chặn dải Cloudflare hay AWS, và cũng khó chặn người dùng các VPN thương mại lớn khỏi website
    Hơn nữa, cả lưu lượng lẫn truy vấn tên đều được mã hóa, nên nhà vận hành mạng không thể biết người dùng đang làm gì trên Internet
    Đây là một thay đổi tích cực vì nó tăng quyền riêng tư và tính ẩn danh, làm giảm hiệu quả của các giải pháp bảo mật mạng, khiến mạng trở lại đơn giản hơn và tránh bị cứng nhắc, đồng thời buộc chúng ta xử lý các vấn đề bảo mật căn bản thay vì một ngành công nghiệp “đập chuột” kém hiệu quả

    • Bạn nói “không thể chặn truy cập tới các dải IP của Cloudflare hay AWS”, nhưng Reddit có vẻ làm chuyện đó khá chắc tay
      Gần đây tôi phải sửa phần mềm backend của một tumblelog dùng yt-dlp để tải video Reddit xuống, vì Reddit đã chặn dải IP máy chủ dedicated của Hetzner
      Cuối cùng tôi lách bằng cách cho JavaScript tải video ở phía client rồi upload lên server của tôi
    • Nếu có thể biết được dải IP của các nhà cung cấp VPN thương mại lớn, bạn có thể chặn khách truy cập
      Một số website đã làm vậy, và tôi cũng đang cân nhắc
      Ngoài ra, lấy danh sách IP exit node của TOR để chặn TOR cũng đáng làm; nhờ chặn TOR mà tôi đã giảm được rất nhiều phiền toái do các tác nhân độc hại gây ra
    • Việc phần mềm độc hại không còn được phát tán từ hosting hay nhà đăng ký tên miền đáng ngờ mà từ hạ tầng chính thống có vẻ là hệ quả của việc cơ quan thực thi pháp luật không thể hoặc không muốn thực sự xử lý tội phạm trực tuyến
      Điều đó đặc biệt đúng nếu không phải các lĩnh vực gây bất tiện cụ thể cho các tập đoàn lớn, như bản quyền; nếu dùng nhà cung cấp chính thống mà vẫn tránh được trừng phạt thì chẳng có lý do gì phải dùng hosting bulletproof hay nhà đăng ký đáng ngờ
    • Điều đáng lo là các cơ quan quản lý có thể không chờ đến khi vấn đề gốc rễ được giải quyết mà sẽ chọn cách xác minh danh tính mạnh tay hơn
      Kịch bản tệ nhất là toàn bộ Internet trở nên giống Facebook: chỉ cần muốn xem thứ gì đó cũng phải có tài khoản không thể tách rời khỏi danh tính thật
    • Vì vậy có vẻ có thể tóm lại là KYC cũng sẽ được áp dụng cho cloud hosting

  • Tôi bắt đầu chán các tiêu đề kiểu phần mềm độc hại được “chuyển giao” qua những thứ như trình rút gọn liên kết
    Việc người ta có nhiều cách để đưa file lên Internet chẳng có gì đáng ngạc nhiên

    • Đây không phải trình rút gọn liên kết mà là tunnel, nên người dùng thấy như mình đang kết nối tới Cloudflare, nhưng phía sau lại dẫn đến đích độc hại
      Đích cuối bị che giấu hoàn toàn khỏi cả người dùng lẫn stack bảo mật của công ty
      Nếu Cloudflare muốn bán mình như một sản phẩm bảo mật, tôi không nghĩ kỳ vọng họ giám sát malware trên chính dịch vụ của mình là quá đáng
    • Đến mức này, đặc biệt với người không phải người dùng nâng cao, nên xem đây là vấn đề của thiết kế tương tác hệ điều hành
      Chỉ đổ Cloudflare là kẻ tiếp tay sẽ bỏ lỡ bức tranh lớn hơn
      Trước đây, để tránh vô tình bị nhiễm từ ổ đĩa độc hại, người ta phải tắt AutoRun trên Windows, nhưng chẳng ai đổ lỗi cho nhà sản xuất CD-RW hay USB flash drive
    • Tôi ước Cloudflare phản hồi các báo cáo lạm dụng nghiêm túc hơn một chút
      Tôi không nhớ đã từng thấy họ thực sự hành động khi tôi báo cáo phishing và hosting malware rõ ràng
    • Tôi thấy thật vô lý khi thiết kế trình duyệt đã bị đóng khung theo cách chỉ cần bấm vào một liên kết cũng có thể phơi mình trước nguy cơ malware
      Ban đầu lời khuyên tốt là “đừng ăn thứ gì không nhận diện được”, nhưng rồi bằng cách nào đó nó bị bóp méo thành “đừng xem thứ gì không nhận diện được”
      Thế mà nếu không làm theo lời khuyên này thì người dùng lại bị đối xử như kẻ ngốc, trong khi họ dễ rơi vào trạng thái không biết mối đe dọa thực sự trông như thế nào
      Cách tốt hơn là mọi liên kết đều có thể bấm một cách an toàn, miễn là không làm các hành động nguy hiểm như thực thi
      Như vậy bạn mới có thể đánh dấu những gì mình tìm thấy là nguy hiểm hoặc đáng tin để giúp đồng nghiệp

  • Tôi đã viết về việc công cụ này bị lạm dụng gần như đúng 1 năm trước[0]
    Điểm có vẻ mới ở đây chỉ là họ làm gì thông qua tunnel, và việc cách này thành công đến mức chiếm tỷ trọng ngày càng lớn trong toàn bộ kỹ thuật tấn công
    Theo tôi, TryCloudflare mới là vấn đề thật sự
    Hoàn toàn không cần tài khoản, khiến việc truy vết quy trách nhiệm gần như bất khả thi
    0: https://www.guidepointsecurity.com/blog/tunnel-vision-cloudf...

  • Tôi nghĩ cuối cùng các sản phẩm tunnel tức thời miễn phí đều sẽ thành ra thế này
    ngrok ban đầu cũng rất hay vì tunneling không ma sát, nhưng cuối cùng phải đưa tất cả vào sau luồng đăng ký do cùng kiểu lạm dụng

    • Nếu kẻ tấn công không lạm dụng thứ này thì tôi mới thất vọng
      Cung cấp mã hóa đầu cuối miễn phí mà không có trách nhiệm gắn với người dùng thì chẳng khác gì mời gọi lạm dụng

  • Nếu không phải Cloudflare Tunnel, thì sẽ là kiểu yêu cầu mở một trang web qua Google Dịch với payload nhét trong URL
    Chuyện này khó coi là tin tức

  • Có lẽ đây là lý do chúng ta không thể có những thứ tốt đẹp trên Internet, ở đây là các tính năng hay của Cloudflare
    Bạn có biết từng có thể gửi email miễn phí từ Cloudflare không? (https://blog.cloudflare.com/sending-email-from-workers-with-...)
    Giờ thì không còn nữa
    Việc chấm dứt có lẽ không nhất thiết là lỗi của Cloudflare, nhưng đó là một ví dụ tương tự về việc dịch vụ tốt bị lạm dụng rồi biến mất

  • Từ lâu trước đây Cloudflare có một tính năng “xem trước” CSS và HTML dùng cho trang lỗi tùy chỉnh
    Về cơ bản, tính năng xem trước nhận CSS và HTML nằm trong query string rồi hiển thị nguyên xi tại cloudflarepreview.com/...
    Tôi đã báo cáo chuyện này, cho thấy có thể rất dễ tạo một trang kiểu “Hãy đăng nhập bằng tài khoản Cloudflare để truy cập bản xem trước beta của Cloudflare!” và đánh cắp thông tin đăng nhập Cloudflare
    Bug bounty bị đóng với lý do “được chấp nhận do đặc tính của playground cloudflarepreview”, rồi sau đó họ sửa bằng cách thêm JWT token vào URL, nhưng không có thưởng
    Tôi đã là khách hàng Cloudflare trong thời gian dài, nhưng có vẻ có nhiều góc tối trong sản phẩm của họ không được chú ý mấy cho đến khi bị lạm dụng, và tôi nghi TryCloudflare cũng là một trong số đó

  • Nhìn vào vấn đề “không ai muốn chi đủ tiền cho moderation và chống lạm dụng”, tôi tự hỏi ý tưởng thời PGP sơ khai về một mạng lưới tin cậy/không tin cậy phân tán cho danh tính trực tuyến đã đi đâu
    Giờ nó chỉ còn sót lại phần nào dưới dạng các tài khoản mạng xã hội được “tin cậy” dựa trên số follower, follower của follower và vô tận bot bên dưới, hoặc dưới dạng PageRank và việc lạm dụng tối ưu hóa công cụ tìm kiếm

    • Những người có thể hiểu và dùng các đề xuất như vậy vốn đã không ngu đến mức cài trojan
    • Khi các deepfake siêu thực tiếp tục xuất hiện, xã hội sẽ sớm phải tìm cách xác minh nguồn gốc có thật hay không

  • Tôi tự hỏi kiểu tấn công này có bị chương trình bảo mật endpoint khét tiếng đó, chẳng hạn ClownStrike, phát hiện không
    Có vẻ lưu lượng này chỉ hiện ra nếu kẻ tấn công non tay đến mức tái sử dụng trojan truy cập từ xa đã biết

    • Nếu là CrowdStrike thì chỉ cần cấu hình để chặn việc thực thi exe tùy ý
      Kẻ tấn công có dùng file thực thi độc hại đã biết hay không không quan trọng

  • Chuyện này làm tôi nhớ thời đĩa tài khoản dùng thử miễn phí AOL vương vãi khắp nơi
    Nhiều cộng đồng thường chặn ngay subdomain của AOL

    • Cũng cần chặn *.ipt.aol.com
      Vì có người dùng AOL nào đó dùng reverse DNS HOST.ipt.aol.com để né chặn và làm khổ tất cả mọi người
      Thế hệ Prodigy / CompuServe / Blue Light cũng có mặt ở đây