Nhóm tin tặc Lazarus - Phần 2

Nhiều công cụ ẩn sâu bên trong cơ sở hạ tầng của ngân hàng bị tấn công được tìm thấy sau khi biến thể mới dòng mã độc Trojan-banker.Win32.Alreay được phát hiện.

Vụ việc #1

Vụ việc xảy ra ở một quốc gia Đông Nam Á vào tháng 8 năm 2016, khi biến thể mới của dòng mã độc Trojan-Banker.Win32.Alreay được phát hiện. Mã độc này có liên quan với kho công cụ trước đó được sử dụng bởi các kẻ tấn công ở Bangladesh. Vì tổ chức bị tấn công là ngân hàng, chúng tôi đã quyết định điều tra kỹ trường hợp này. Trong thời gian hợp tác với ngân hàng bị tấn công, chúng tôi đã khám phá ra rất nhiều các công cụ ẩn sâu bên trong cơ sở hạ tầng. Dường như những kẻ tấn công đã biết về cuộc điều tra và xóa sạch mọi dấu vết có thể, bao gồm các công cụ, tệp cấu hình và bản ghi chép. Dù vậy, chúng đã bỏ quên một vài công cụ và thành phần khi vội vã bỏ trốn.

Sự tương đồng của mã độc

Giống như các ngân hàng khác có máy chủ riêng kết nối với SWIFT, ngân hàng trong sự việc #1 cũng có một máy chủ chạy phần mềm SWIFT Alliance.

Từ cuộc tấn công mạng khét tiếng tại Bangladesh, phần mềm SWIFT Alliance đã được cập nhật, bổ sung thêm một số bước kiểm tra nhằm xác thực tính toàn vẹn của phần mềm và cơ sở dữ liệu. Đây là việc cần thiết và hợp lý khi, như bài viết của BAE Systems đã chỉ ra, các hacker đã tìm cách can thiệp vào phần mềm SWIFT Alliance trên ổ đĩa vật lý và trong bộ nhớ, vô hiệu hóa quá trình sử dụng cơ sở dữ liệu trực tiếp. Hacker đã nắm được điều này khi theo dõi những thay đổi trong phần mềm SWIFT Alliance. Các công cụ phần mềm độc hại trong sự việc #1 cho thấy các kẻ tấn công đã thận trọng phân tích các bản vá và tìm ra cách để đối phó.

Phần mềm độc hại được phát hiện trên máy chủ kết nối với SWIFT liên kết chặt chẽ sự việc #1 với sự cố tại Bangladesh. Mặc dù một số công cụ nhất định là mới và có sự khác nhau trong mã phần mềm độc hại, những điểm giống nhau giữa hai vụ việc vẫn đủ để khẳng định các thủ phạm đã sử dụng cùng một nền tảng mã. Dưới đây là một số mã giống hệt nhau mà chúng tôi tìm thấy.

Ảnh trên cho thấy mã nguồn được dịch ngược của chức năng ghi log trong phần mềm độc hại. Mã gần như là giống hệt nhau, chỉ khác biệt một chút ở cải tiến thêm ID của tiến trình hiện tại vào log.

Có vẻ, một trong những chiến lược dài hạn của Lazarus là không ngừng sửa đổi mã, ngay cả khi việc thay đổi không bổ sung được nhiều tính năng mới. Việc thay đổi giúp mã độc vượt qua được sự phát hiện của Yara và các nền tảng (khác) dựa trên chữ ký. Một ví dụ khác về việc thay đổi mã trong khi vẫn giữ ý tưởng cốt lõi là tập mẫu của Novetta. Một trong những mô-đun phần mềm độc hại của Lazarus do Novetta phát hiện ra có sử dụng tệp cấu hình nhị phân được mã hóa bằng RC4 và khóa mã hóa cứng.

Trong ảnh là một đoạn mã có nhiệm vụ tải, giải mã và xác thực tệp cấu hình magic.

Đoạn mã phía trên được dùng để đọc, giải mã và kiểm tra tệp cấu hình bên ngoài. Có thể thấy mã này thay đổi theo thời gian. Mẫu thu thập từ vụ việc #1 có những sự khác biệt nhất định nhằm vô hiệu hóa cơ chế phát hiện nhị phân thông thường với Yara. Rõ ràng rằng, các đoạn mã là một dù có sự khác biệt nhất định. Thay vì đọc tệp một lần, phần mềm độc hại cố đọc tới năm lần với độ trễ 100 mili giây. Sau đó nó giải mã tệp với khóa mã hóa cứng RC4 gồm 16 bytes giống hệt nhau trong hai mẫu (4E 38 1F A7 7F 08 CC AA 0D 56 ED EF F9 ED 08 EF), và xác thực giá trị magic là 0xA0B0C0D0.

Theo phân tích forensic, phần mềm độc hại này được truy cập từ xa vào hệ thống thông qua backdoor tùy chỉnh. Hầu hết các máy chủ được phân tích không được điều khiển trực tiếp thông qua máy chủ C2. Thay vào đó, chúng kết nối đến một máy chủ nội bộ khác, máy chủ này có nhiệm vụ chuyển tiếp kết nối TCP tới máy chủ C2 bằng một công cụ được đặt tên là TCP Tunnel. Công cụ này được sử dụng để kết nối các máy chủ nội bộ và chuyển tiếp kết nối tới máy chủ C2 thực. Điều này khiến quản trị viên khó xác định máy chủ bị xâm nhập hơn bởi các kết nối cục bộ có vẻ ít bị nghi ngờ. Một công cụ tương tự mà Novetta mô tả là Proxy PapaAlfa. Công cụ này là một trong những công cụ phổ biến nhất trong một cuộc tấn công. Một vài máy chủ không chứa phần mềm độc hại được dùng như là công cụ chuyển tiếp. Đó là lý do vì sao chúng tôi tin rằng, Lazarus có nhiều biến thể của công cụ này cũng như thay đổi chúng thường xuyên để tránh việc phát hiện dựa trên mạng hoặc tệp. Để biết đầy đủ các chi tiết kĩ thuật của công cụ được phát hiện trong sự việc #1, hãy xem Phụ lục (MD5: e62a52073fd7bfd251efca9906580839) (được đăng trong những kỳ sau).

Trên một trong những máy chủ trung tâm được cài đặt SWIFT Alliance của ngân hàng, chúng tôi phát hiện một backdoor có cùng mã và thiết kế giao thức với dòng backdoor có tên Romeo. Một backdoor tương tự đã được tải lên dịch vụ multiscanner từ Ba Lan và Hàn Quốc tháng 11 năm 2016 (MD5: 06cd99f0f9f152655469156059a8ea25). Chúng tôi tin rằng đây là ‘điềm báo’ của những cuộc tấn công sau đó tại Ba Lan và các nước Châu Âu khác. Tháng 1 năm 2017, phần mềm mã độc tương tự đã được phát tán nhắm đến các ngân hàng Châu Âu trong một cuộc tấn công khai thác.

Có rất nhiều sự tương đồng hữu hình giữa phần mềm độc hại của Lazarus và phần mềm độc hại được phát hiện ở sự vụ #1, ví dụ như quy trình nhập API và PE Loader. PE loader được dùng cho nhiều thành phần của phần mềm độc hại: DLL loader, Injector và backdoor.

Cần lưu ý rằng các mô-đun khác nhau về thể loại tệp và mục tiêu: ví dụ tệp EXE – mẫu của Novetta, được sử dụng để tải các tệp PE độc hại khác, trong khi mẫu được phát hiện trong vụ việc #1 là DLL backdoor. Tuy nhiên, chúng dựa trên một cơ sở mã giống hệt nhau.

Có thể sẽ còn có những ý kiến khác về sự tương đồng này. Dù vậy, có một điều đã rất rõ ràng rằng cuộc tấn công vào ngân hàng trung ương Bangladesh và vụ việc #1 có mối liên hệ với nhau thông qua việc sử dụng phần mềm độc hại Lazarus.

Điều tra số trên máy chủ kết nối với SWIFT

Trong trường hợp tấn công ở Đông Nam Á, mã độc đã lây lan trên cả máy chủ kết nối với SWIFT và một số hệ thống thuộc bộ phận công nghệ thông tin của công ty. Chúng tôi phục hồi hầu hết các mô-đun, trong khi một số mô-đun khác bị xóa hoàn toàn và không thể truy cập để phân tích. Tuy nhiên, trong nhiều trường hợp, chúng tôi có tham chiếu đến các tệp có tên như thế trên các hệ thống bị lây nhiễm khác và rất có thể là các công cụ độc hại. Như vụ việc này, có những mối tương quan giữa các nạn nhân, cho thấy kẻ tấn công nhắm vào nhiều ngân hàng cùng một lúc.

Dưới đây là những điểm chính từ phân tích forensic:
Các kẻ tấn công đã nằm vùng trong công ty trong hơn bảy tháng. Ngân hàng Đông Nam Á đã bị xâm phạm cùng thời điểm với vụ cướp ở ngân hàng Trung ương Bangladesh.

• Hầu hết phần mềm mã độc nằm trong thư mục C:\Windows hoặc C:\MSO10. Hai đường dẫn này được mã hóa cứng trong nhiều mô-đun.
• Phần mềm độc hại được viết chỉ vài ngày hoặc đôi khi vài giờ trước khi tấn công, điều này cho thấy đây là một hoạt động có chủ đích.
• Các kẻ tấn công sử dụng một bộ giải mã có ‘vẻ ngoài’ vô hại với PE loader tùy chỉnh được thiết kế nhằm qua mặt các sản phẩm bảo mật.
• Hầu hết các mô-đun được thiết kế để chạy như một dịch vụ hoặc có các quyền quản trị hệ thống.
• Backdoor trên máy chủ kết nối tới SWIFT được tìm thấy trong cuộc tấn công trùng khớp với dòng mã độc RAT được Novetta đặt tên là Romeo, trong khi đó Romeo liên quan trực tiếp tới trường hợp Đông Nam Á và Lazarus.
• Không phải lúc nào cũng hoàn toàn dễ dàng đối với kẻ tấn công. Chúng tôi đã tìm thấy nhiều chi tiết của quá trình phá hủy và khởi động lại hệ thống khi có sự hiện diện của kẻ tấn công.
• Để tránh bị phát hiện, các kẻ tấn công hoạt động ngoài giờ hành chính theo lịch trình và múi giờ của nạn nhân.
• Chúng đã cố gắng debug một số vấn đề bằng cách kích hoạt trình điều khiển sysmon trong vài giờ. Sau đó, chúng quên xóa tệp nhật ký chi tiết sysmon chứa thông tin các quy trình đang chạy, các dòng lệnh và tệp hash tương ứng.
• Có một loại mã độc nhắm vào phần mềm SWIFT Alliance, làm vô hiệu hóa việc kiểm tra tính toàn vẹn nội bộ và chặn các tệp giao dịch đã được xử lý. Chúng tôi đặt tên mã độc này là ‘SWIFT targeted malware’ và cho rằng đơn vị Bluenoroff của Larazus chính là tác giả.
• Mã độc SWIFT khác với các công cụ Lazarus khác, vì nó thiếu tính che giấu, ngụy trang và đóng gói.
• Mã độc nằm vùng được cài đặt như một dịch vụ DLL của Windows, đăng ký trong nhóm Dịch vụ mạng (netsvcs).
• Chúng sử dụng trình theo dõi thao tác bàn phím, một chương trình lưu trữ tại ổ chứa được mã hóa. Ổ chứa này được giải mã và đọc bởi một loader lấy thông tin mã hóa từ một máy khác (được ẩn dưới dạng 1 file trong C:\Windows\Web\Wallpaper\Windows\).
• Những kẻ tấn công đã vá các mô-đun phần mềm SWIFT Alliance vĩnh viễn trên đĩa, nhưng sau đó đã khôi phục các thay đổi. Một lỗi hoạt động khác là quên khôi phục mô-đun đã vá trong thư mục sao lưu. Bản vá được áp dụng cho mô-đun liboradb.dll rất giống với bản được mô tả bởi BAE Systems trong bài viết về các cuộc tấn công Bangladesh.
• Các kẻ tấn công đã sử dụng cả backdoor chủ động và bị động. Các backdoor bị động dựa vào cổng TCP được mở trong Firewall thông qua lệnh netsh.exe chuẩn. Điều này đã tạo ra thêm một bản lưu trên hệ thống nhật ký sự kiện. Cổng được đặt trong cấu hình, hoặc được truyền dưới dạng đối số dòng lệnh. Chúng thường lựa chọn các cổng có đuôi 443, ví dụ 6443, 8443, 443.
• Nhật ký phần mềm nội bộ SWIFT Alliance có một số cảnh báo về lỗi cơ sở dữ liệu từ tháng 6 đến tháng 8 năm 2016, tương ứng với những nỗ lực giả mạo cơ sở dữ liệu giao dịch của hacker.
• Những kẻ tấn công không giành được quyền kiểm soát trực quan trên máy tính thông qua backdoor của chúng, đó là lý do tại sao chúng đã dựa vào các công cụ TCP tunnel của riêng mình để chuyển tiếp các cổng RDP tới nhà điều hành. Do đó, chúng tôi đã xác định được hoạt động bất thường của Terminal Service: Làm việc muộn và đôi khi vào cả cuối tuần.
• Một trong những phiên Terminal Service gần đây được bắt đầu từ máy chủ web lưu trữ website của công ty. Máy chủ web nằm trong cùng mạng với máy chủ được kết nối với SWIFT, và rất có thể không phải là nạn nhân của cuộc tấn công này.

Dòng thời gian của các cuộc tấn công

Việc hợp tác với ngân hàng lâu dài giúp chúng tôi có cơ hội kiểm tra một số máy chủ trong ngân hàng bị xâm nhập. Có thể thấy các kết nối đến các máy chủ trong mạng thông qua việc phân tích máy chủ trung tâm kết nối với SWIFT. Chúng tôi nghi ngờ rằng các máy chủ này bị nhiễm độc, và điều này đã được xác nhận khi phân tích sâu hơn.

Khi mối liên hệ giữa ngân hàng và Kaspersky Lab được hình thành, các kẻ tấn công phần nào nhận ra sự bất thường trong hành vi của các quản trị viên hệ thống và bắt đầu xóa sạch mọi dấu vết hoạt động. Dù rằng phải mất vài tháng để công bố những dấu vết về sự hiện diện của chúng, nhưng chúng tôi đã thu thập và xây dựng một dòng thời gian sơ bộ về một số hoạt động của các kẻ tấn công.

Các dấu mốc chỉ ra hoạt động của các kẻ tấn công đã được thu thập, điều này giúp chúng tôi xây dựng dòng sự kiện dựa vào các giả lập còn lại.
Tính đồng bộ của các sự việc trong các sự cố khác nhau.

Trong quá trình phân tích nhật ký sự kiện, chúng tôi đã tìm thấy một tệp từ Sysinternals Sysmon. Đáng ngạc nhiên, tệp nhật ký này chứa các bản ghi hoạt động của phần mềm độc hại từ nhiều tháng trước khi phân tích forensic, ghi lại một số hoạt động chủ động của kẻ xâm nhập.

Khi phát hiện ra nhật ký sysmon có điều bất thường, chúng tôi khá bối rối bởi có vẻ như kẻ tấn công đã kích hoạt nó, hoặc ai đó muốn theo dõi hoạt động của kẻ tấn công. Sau đó, một nhà nghiên cứu bảo mật trong vụ Bangladesh đã xác nhận rằng hoạt động sysmon tương tự đã được đăng ký ngày 29 tháng 1 năm 2016. Điều này có nghĩa rằng nó đã xảy ra với ít nhất hai nạn nhân khác nhau trong vòng vài phút.

Một sự kiện khác cũng liên quan với việc giả mạo mô-đun cơ sở dữ liệu SWIFT.
Qua phân tích hệ thống ở sự vụ #1, chúng tôi đã tìm thấy thư mục C:\Users\%username%\Desktop\win32\ được tạo vào 2016-02-05 03:22:51 (UTC). Thư mục chứa tệp liboradb.dll đã vá được sửa đổi vào 2016-02-04 14:07:07 (UTC), trong khi tệp chưa được vá dường như được tạo vào ngày 2015-10-13 12:34:26 (UTC) và được lưu trữ trong liboradb.dll.bak. Điều này cho thấy hoạt động của kẻ tấn công và khoảng thời gian 2016-02-04 14:07:07 (UTC), cũng chính là thời gian diễn ra vụ cướp ngân hàng tại Bangladesh.

Phát hiện này đúng với sự cố tại Ngân hàng Trung ương Bangladesh vào tháng 2 năm 2016. Theo BAE systems, tại ngân hàng BCB, mô-đun “liboradb.dll” cũng được vá bằng kỹ thuật “NOP NOP”.

Điều này có nghĩa rằng hoạt động của kẻ tấn công và việc chỉnh sửa tệp đã diễn ra cùng một ngày tại hai ngân hàng ở hai đất nước khác nhau vào ngày 29 tháng Một năm 2016 và ngày 4 tháng Hai năm 2016.

Tóm lại, ngân hàng Trung ương Bangladesh có lẽ là một trong nhiều ngân hàng bị xâm phạm bởi hoạt động liên quan đến hàng trăm triệu đô. Một ngân hàng ở Đông Nam Á liên quan đến sự vụ #1 này là minh chứng cho thực tế này.

Kỹ thuật chống Forensic

Các kẻ tấn công sử dụng một số kỹ thuật khá mới mẻ và thú vị. Cho đến nay, tất cả tài sản bị nhiễm độc đều nằm giữa các hệ thống kết nối tới SWIFT và hệ thống riêng của ngân hàng. Bằng cách chia tải trọng độc hại thành hai phần và đặt chúng ở hai khu vực khác nhau, các kẻ tấn công đã lẩn trốn bất kỳ bên nào điều tra hoặc phân tích các tệp đáng ngờ.

Về mặt kỹ thuật, nó được thực hiện qua việc tách các tệp, ghép lại với nhau thành một quy trình độc hại có đầy đủ chức năng. Chúng tôi phát hiện cách làm này ít nhất hai lần khi phân tích forensic, và tin rằng đó không phải là sự trùng hợp ngẫu nhiên.

Thông thường các quy trình forensic sẽ được áp dụng cho toàn bộ hệ thống. Với các quy trình forensic tiêu chuẩn, bao gồm phân tích kết xuất bộ nhớ và disk image của hệ thống bị xâm nhập, hiếm khi nào một máy tính được xem là một hệ thống bị xâm phạm một nửa, nghĩa là còn một thành phần khác được đặt ở nơi khác. Tuy nhiên, trên thực thế, hệ thống vẫn bị xâm nhập. Có nghĩa rằng, khi phân tích forensic mà tập trung vào một hệ thống đơn lẻ, chúng ta sẽ không nhận ra được bức tranh tổng thể. Đó là lý do tại sao chúng tôi tin rằng kĩ thuật này đã được sử dụng nhằm ngăn chặn phân tích forensic. Với suy nghĩ này, chúng tôi muốn khuyến khích tất cả các nhà phân tích forensic nên có tư duy mới mẻ hơn, đặc biệt là khi đối phó với Lazarus.

Mật khẩu bảo vệ phần mềm độc hại

Một kỹ thuật thú vị khác là việc sử dụng mật khẩu để bảo vệ phần mềm độc hại. Mặc dù kỹ thuật này không hoàn toàn mới, thường là chữ ký của những kẻ tấn công. Mã độc Gauss bí ẩn là một phần mềm như vậy, đòi hỏi một thành phần bí mật để giải mã. Chúng tôi đã công bố nghiên cứu về phần mềm độc hại Gauss vào năm 2012 và kể từ đó, đã có nhiều nỗ lực được thực hiện nhằm bẻ khóa mật khẩu mã hóa Gauss nhưng đều thất bại.

Ý tưởng này là một biện pháp chống forensic khá đơn giản nhưng rất hiệu quả: Phần mềm độc hại Dropper (trình cài đặt) sử dụng cụm mật khẩu bí mật được truyền quan đối số dòng lệnh. Đối số được băm với MD5 và được sử dụng như chìa khóa giải mã tải trọng. Trong bối cảnh của cuộc tấn công #1, payload được xem như một trình tải của payload giai đoạn kế tiếp, được mã hóa và nhúng vào trình tải. Trình tải không có khóa để giải mã payload được nhúng, nhưng lại tìm thấy trong registry value. Registry value cần được đặt bởi trình cài đặt, nếu không phần mềm độc hại không hoạt động. Vì vậy, rõ ràng rằng trừ khi có cụm mật khẩu bí mật, bạn sẽ không thể xây dựng lại chuỗi biến động. Trong trường hợp #1, chúng tôi đã có cụm mật khẩu – một chuỗi gồm 24 ký tự chữ hoa và chữ thường ngẫu nhiên được chọn lựa cẩn thận.

Cách thức lây nhiễm
Không rõ những kẻ tấn công ban đầu đã xâm nhập hệ thống ngân hàng như thế nào. Tuy nhiên, rõ ràng rằng chúng đã sử dụng một máy chủ web đặt ở ngân hàng để kết nối đến các hệ thống kết nối SWIFT thông qua Terminal Services. Trong một số trường hợp, thay vì máy chủ web, chúng sẽ dùng một máy chủ nội bộ bị lây nhiễm khác. Tuy nhiên, tất cả các máy chủ mà chúng tôi phân tích đều không có tương tác với bên ngoài, ngoại trừ máy chủ web lưu trữ trang web của công ty được đề cập tới.

Quá trình cài đặt máy chủ web khá mới mẻ: server này lưu trữ trang web mới của công ty chỉ vài tháng trước khi bị xâm nhập. Ngân hàng đã kí hợp đồng với một công ty kiểm thử để thực hiện đánh giá bảo mật trang web mới, và quá trình này diễn ra đúng lúc Lazarus xâm phạm máy chủ. Sự lây nhiễm trên máy chủ web xuất hiện ở giữa các đầu dò kiểm thử. Một số đầu dò đã thành công và người kiểm thử đã tải webshell dạng C99 lên máy chủ như một bằng chứng vi phạm. Sau đó, người kiểm thử tiếp tục dò các lệnh dễ bị tấn công trên máy chủ. Cuối cùng, tất cả các kịch bản đều được báo cáo và vá.

Xét rằng trên máy chủ web đã có những vi phạm được phát hiện và khắc phục với sự trợ giúp của kiểm toán bảo mật độc lập thì khả năng cao là máy chủ này xâm nhập bởi Lazarus trước thời điểm kiểm toán. Một khả năng khác là webshell C99 được tải lên bởi người kiểm thử đã nhiễm backdoor và Lazarus đã ngay lập tức tiếp quản máy chủ. Thật không may, webshell C99 chỉ được xác định bởi chuỗi truy vấn mà không thể khôi phục phần thân.

Bằng cách này hay cách khác, vi phạm máy chủ web dường như là cách thức lây nhiễm dễ xảy ra nhất được Lazarus sử dụng để xâm nhập vào mạng ngân hàng.

Bài viết đã đăng:
Nhóm tin tặc Lazarus - Phần 1