Phát hiện chiến dịch tấn công mới của nhóm APT vào các máy chủ IIS sử dụng mã độc IIS Raid

Do Hoang Anh

• 17 min read
Phát hiện chiến dịch tấn công mới của nhóm APT vào các máy chủ IIS sử dụng mã độc IIS Raid

Vào tháng 12 vừa rồi, bộ phận Xử lý sự cố và bộ phận Phân tích mã độc của Viettel An ninh mạng đã phát hiện và xử lý thành công một cuộc tấn công có chủ đích nhắm vào doanh nghiệp ngành xây dựng sử dụng mã độc “IIS Raid”, nằm trong chiến dịch tấn công mới đầu tháng 03/2021 của một nhóm APT .

Theo báo cáo của ESET, mã độc IIS Raid được nhóm APT sử dụng là một biến thể nằm trong 14 nhóm mã độc IIS, sử dụng 2 chức năng chính: Backdoor, Infostealer. Mã độc IIS được phát hiện lần đầu trên thế giới vào năm 2018, đặc biệt được phát triển và sử dụng rộng rãi trong năm 2021.

Phần 1 bài viết: Chi tiết kịch bản tấn công và các IOC của cuộc tấn công.

Phần 2 bài viết: Phân tích kỹ thuật Persistent thông qua IIS Components.

Phần 3 bài viết: Phân tích chi tiết về mã độc sử dụng trong chiến dịch.

Mô tả chiến dịch tấn công

Nhóm tấn công thực hiện khai thác lỗ hổng ProxyLogon đã lấy được quyền truy cập vào hệ thống mà không cần xác thực, từ đó thực thi lệnh từ xa và cài đặt mã độc IIS để khai thác thông tin, dữ liệu, tài khoản hệ thống của máy lây nhiễm, đồng thời thu thập phiên, mật khẩu người dùng sử dụng dịch vụ owa (Outlook Web App) thông qua mã độc IIS trên máy lây nhiễm.

Khai thác dữ liệu thông qua mã độc IIS

Kịch bản và diễn biến tấn công

Diễn biến cuộc tấn công

Tin tặc thực hiện dò quét và khai thác thành công lỗ hổng ProxyLogon (CVE-2021-27065, CVE-2021-26855) - đây là lỗ hổng cho phép người khai thác thực thi lệnh tùy ý trên Microsoft Exchange Server với quyền “Local Administrator” thông qua cổng 443 mà không cần xác thực quyền.

Ngay sau khi vào được máy chủ Exchange, chúng thực hiện dump các tài khoản Email (được liên kết với tài khoản Active Directory) của hệ thống với mục đích chiếm được các tài khoản này để xâm nhập vào các máy chủ lân cận trong hệ thống. Tuy nhiên việc chiếm đoạt tài khoản thất bại vì thông tin được dump ra chỉ bao gồm tên và thông tin tài khoản mà không có mật khẩu.

File dump thông tin người dùng

Sau nhiều ngày thất bại trong việc tìm kiếm mật khẩu các tài khoản hệ thống, tin tặc thực hiện cài đặt mã độc IIS Backdoor, một trong những dòng mã độc sử dụng các kỹ thuật xuất hiện lần đầu năm 2013 (ISN Infostealer được báo cáo bởi Trustwave), phát hiện lần đầu trên thế giới vào năm 2018, phát triển và sử dụng rộng rãi trên trong năm 2021, được chia thành 14 nhóm với 5 chức năng chính:

  • Backdoor: Cho phép tin tặc điều khiển từ xa các máy chủ cài đặt IIS.
  • Infostealer: Cho phép tin tặc chặn các truy cập giữa máy chủ và người dùng nhằm đánh cắp thông tin như thông tin đăng nhập, cookie/phiên làm việc, thông tin thanh toán, tài khoản ngân hàng, ...
  • Injector: Mã độc thay đổi gói tin trả về người dùng để cung cấp nội dung xấu, độc hại.
  • Proxy: Biến máy chủ IIS lây nhiễm thành một thành phần của hệ thống C&C (Command & Control: Điều khiển và kiểm soát), từ đó lợi dụng máy chủ IIS này để chuyển tiếp giao tiếp giữa nạn nhân và máy chủ C&C thực.
  • SEOFraud: Mã độc sửa đổi nội dung được cung cấp cho các công cụ tìm kiếm để thao túng các thuật toán SERP và tăng xếp hạng cho các trang web được chọn.
Nguồn tham khảo các nhóm mã độc IIS của ESET: https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Anatomy-Of-Native-Iis-Malware-wp.pdf

Xuyên suốt thời gian này, tin tặc đã lấy được một lượng lớn phiên truy cập của người dùng, cùng với các email có nội dung chứa chuỗi “password” mà người dùng gửi qua email. Đồng thời, tin tặc còn thực hiện truy cập thường xuyên tới máy chủ lây nhiễm.

File “log.tmp” chứa cookie bị đánh cắp của người dùng
File “creds.db” chứa các nội dung có chuỗi “password” trong email người dùng
Một đoạn nội dung trong file creds.db

Sau một thời gian dài nằm trong hệ thống nạn nhân, tin tặc thực hiện cài đặt thêm 1 số webshell nhằm tăng cường khả năng tồn tại trong hệ thống nạn nhân.

Ví dụ ở dưới là 1 webshell được cài đặt tại đường dẫn:

%programfiles%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\类\bNOnB\ZagXlm.aspx
Thời gian tạo webshell
Rất nhiều truy cập tới webshell sau khi tạo từ 20/08/2021 – 01/09/2021
Các User-Agent mà tin tặc sử dụng cho những truy cập webshell trên

Kể cả sau khi thực hiện loại bỏ lỗ hổng ProxyLogon, tin tặc vẫn thực hiện sử dụng thành công kết nối từ mã độc IIS và tiếp tục khai thác dữ liệu người dùng sử dụng dịch vụ owa.

Các kỹ thuật được sử dụng

Tên kỹ thuật

Cách thức kỹ thuật được dùng trong chiến dịch

Persistence

[T1505.004] Server Software Component: IIS Components

Persistence file httpcore.dll

Defense Evasion

[T1055.002] Process Injection: Portable Executable Injection

Kẻ tấn công sử dụng kỹ thuật này để thực thi shellcode

[T1027] Obfuscated Files or Information

Các dữ liệu gửi nhận giữa attacker và mã độc sẽ được encode base64

Các IOC của chiến dịch

Mã độc IIS Raid:

  • %windir%\System32\inetsrv\httpcore.dll
  • SHA256: a11626d55ee9c958d86e8c77dfe19f66cdf545fbd8743126081f46dc24446767

Đường dẫn tới các file liên quan tới mã độc:

  • C:\Windows \system32\inetsrv\config\applicationHost.config
  • C:\Windows\Temp\creds.db
  • C:\Windows\Temp\log.tmp

Webshell:

  • %programfiles%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServerProxy.aspx
  • %programfiles%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\类\bNOnB\ZagXlm.aspx

Địa chỉ IP truy cập tới mã độc IIS Raid và các webshell:

  • 128[.]1.248.26
  • 128[.]1.248.42
  • 128[.]14.133.58
  • 128[.]14.134.134
  • 128[.]14.134.170
  • 128[.]14.141.34
  • 128[.]14.209.162
  • 139[.]162.231.247
  • 162[.]221.192.26
  • 162[.]221.192.90
  • 172[.]105.172[.]151
  • 172[.]105.189.111
  • 172[.]105.254.10
  • 176[.]58.101.217
  • 182[.]180.143.137
  • 182[.]180.143.7
  • 182[.]180.143.72
  • 182[.]180.143.79
  • 192[.]53.161.117
  • 192[.]53.170.163
  • 192[.]53.170.243
  • 193[.]118.53.194
  • 193[.]118.53.202
  • 193[.]118.53.210
  • 23[.]251.102.74
  • 23[.]251.102.82
  • 23[.]251.102.90
  • 23[.]90.160.122
  • 23[.]90.160.130
  • 45[.]33.96.205
  • 45[.]79.204.46
  • 50[.]116.22.34
  • 74[.]207.228.142
  • 82[.]80.195.4
  • 84[.]110.58.176

Đa số các IP được sử dụng là VPN (95%) và phân bổ đều cho Mỹ (Chiếm 70%), châu Âu, Trung Á.

Mục tiêu của chiến dịch

Chiến dịch có mục tiêu khai thác tất cả hệ thống có tồn tại lỗ hổng ProxyLogon của các đơn vị, tổ chức để lấy được quyền truy cập vào hệ thống mà không cần xác thực, từ đó thực thi lệnh từ xa và cài đặt mã độc IIS với mục đích khai thác thông tin, dữ liệu, tài khoản hệ thống của máy lây nhiễm, đồng thời thu thập phiên, mật khẩu người dùng sử dụng trong hệ thống.

Phân tích kỹ thuật Persistent thông qua IIS Components

Tổng quan

Kẻ tấn công có thể lây nhiễm các mã độc trên máy chủ web Internet Information Services (IIS) thông qua một số cơ chế mà IIS cung cấp. Thông thường, các cơ chế này giúp quản trị viên tự phát triển hoặc cài đặt thêm các tính năng của máy chủ web. Hai phương thức thường được sử dụng để cài đặt mã độc là thông qua ISAPI hoặc Native Module.

Chi tiết kỹ thuật

I. ISAPI

Microsoft đã định nghĩa một API được gọi là ISAPI (Internet Server Application Programming Interface) để giúp các nhà phát triển thêm các tính năng vào IIS. Hai loại thành phần có thể được thêm vào IIS là extension ISAPI hoặc filter ISAPI. Các thành phần extension và filter của ISAPI có thể được triển khai để kiểm tra, sửa đổi các web request đến và đi của IIS.

  1. ISAPI Extensions

Các Extension là các DLL tuân theo quy tắc phải có export 3 hàm như sau:

  • GetExtensionVersion
  • HttpExtensionProc
  • TerminateExtension

Các Extension sẽ chạy giống như các ứng dụng bên trong IIS và sẽ được load bất cứ khi nào cần. Các extension này sẽ đọc nội dung của request và response cho client. Ví dụ cách gọi một extension đã được cài đặt:

http://Server_name/ISAPI_name.dll/Parameter

Hàm HttpExtensionProc sẽ được gọi, dữ liệu nhận được sẽ tuân theo cấu trúc sau:

Typedef struct _EXTENSION_CONTROL_BLOCK EXTENSION_CONTROL_BLOCK {

   DWORD cbSize;

   DWORD dwVersion;

   HCONN connID;

   DWORD dwHttpStatusCode;

   char lpszLogData[HSE_LOG_BUFFER_LEN];

   LPSTR lpszMethod;

   LPSTR lpszQueryString;

   LPSTR lpszPathInfo;

   LPSTR lpszPathTranslated;

   DWORD cbTotalBytes;

   DWORD cbAvailable;

   LPBYTE lpbData;

   LPSTR lpszContentType;

   BOOL (WINAPI * GetServerVariable) ();

   BOOL (WINAPI * WriteClient) ();

   BOOL (WINAPI * ReadClient) ();

   BOOL (WINAPI * ServerSupportFunction) ();

} EXTENSION_CONTROL_BLOCK;

Sau khi xử lý, dữ liệu sẽ được trả về response thông qua các callback function ReadClient và WriteClient.

2. ISAPI Filters

Tương tự như các extension, các filter cũng là các DLL tuân theo quy tắc phải có export 3 hàm như sau:

  • GetFilterVersion
  • HttpFilterProc
  • TerminateFilter

Các filter sẽ được đăng ký để handle một số các event như sau:

  • SF_NOTIFY_PREPROC_HEADERS: xảy ra khi IIS đã hoàn thành việc tiền xử lý các Header.
  • SF_NOTIFY_SEND_RESPONSE: xảy ra khi IIS sẵn sàng gửi response cho client.
  • SF_NOTIFY_END_OF_REQUEST: xảy ra khi một request đã kết thúc vòng đời của nó (kết thúc một vòng request & response).
  • SF_NOTIFY_LOG: xảy ra trước khi IIS ghi log cho request hiện tại.
  • ...

Ứng với mỗi event sẽ có một struct để truyền dữ liệu vào cho hàm HttpFilterProc xử lý. Ví dụ: ứng với SF_NOTIFY_LOG sẽ có struct:

typedef struct _HTTP_FILTER_LOG HTTP_FILTER_LOG {

   const char * pszClientHostName;

   const char * pszClientUserName;

   const char * pszServerName;

   const char * pszOperation;

   const char * pszTarget;

   const char * pszParameters;

   DWORD dwHttpStatus;

   DWORD dwWin32Status;

   DWORD dwBytesSent;

   DWORD dwBytesRecvd;

   DWORD msTimeForProcessing;

} HTTP_FILTER_LOG, * PHTTP_FILTER_LOG;
Cách thức hoạt động của filter và extension

3. IIS Backdoor thông qua extension và filter

Kẻ tấn công có thể cài đặt các extension và filter ISAPI độc hại để giám sát, sửa đổi traffic, thực hiện các command trên server bị xâm nhập. Các extension và filter ISAPI có thể có quyền truy cập vào tất cả các request và response trên web IIS. Ví dụ: kẻ tấn công có thể lợi dụng các cơ chế này để sửa đổi request, response HTTP nhằm nhận, thực thi các command độc hại đến các server đã bị lây nhiễm.

Vì cơ chế extension cần attacker phải truy cập vào URL như: http://mydomain/myextension. Việc này có thể được server ghi log lại. Nếu sử dụng filter, mã độc có thể được truy cập bằng cách gọi bất kỳ site nào trên máy chủ. Nên cơ chế filter thường được sử dụng để cài đặt mã độc hơn.

Có thể đăng ký một filter thông qua IIS configuration panel (bên trong các file config của IIS). Chi tiết xem tại đây.

II. Native module

  1. Cách sử dụng

Các tính năng của web server trong IIS 7 trở lên được cấu thành thành 30 module độc lập. Một module có thể là Win32 DLL (Native module) hoặc .NET 2.0 (managed module). Các module được thêm vào máy chủ để cung cấp chức năng mong muốn cho các ứng dụng. Tất cả các module IIS có thể bị xóa hoặc thay thế bằng các module tùy chỉnh được phát triển bằng các API IIS C++ hoặc các API ASP.NET 2.0.

Native module IIS là một DLL sử dụng API IIS C++. Các module gốc nằm trong thư mục %windir%\system32\inetsrv\ trên Server và có thể được config cho một số hoặc cho tất cả các ứng dụng trên Server. Các module này có thể được cài đặt bằng command line AppCmd.exe, thông qua GUI IIS Manager hoặc bằng cách chỉnh sửa file cấu hình %windir%\system32\inetsrv\config\ApplicationHost.config.

Ví dụ: Cách cài đặt một Native module bằng AppCmd.exe:

appcmd.exe install module /name:ImageCopyrightModule /image:%windir%\system32\inetsrv\imageCopyrightModule.dll

Một Native module là một DLL có export hàm:

  • RegisterModule

Khi tạo hàm RegisterModule, cần chỉ định một bitmask chứa danh sách notify mà module sẽ xử lý. Hàm RegisterModule cũng cho phép chỉ định mức độ ưu tiên cho module. Các ưu tiên có sẵn là PRIORITY_ALIAS_FIRST, PRIORITY_ALIAS_HIGH, PRIORITY_ALIAS_MEDIUM, PRIORITY_ALIAS_LOW và PRIORITY_ALIAS_LAST. Ví dụ: một module có thể chỉ định rằng nó sẽ xử lý notify RQ_BEGIN_REQUEST và mức độ ưu tiên là PRIORITY_ALIAS_HIGH. Khi các module được đăng ký, chúng được xử lý theo thứ tự ưu tiên và theo notify. Chi tiết về ý nghĩa các notify và mức độ ưu tiên xem tại đây.

Dưới đây là thứ tự các notify xảy ra mỗi khi có một request tới Server:

Notify

Bitmask

RQ_BEGIN_REQUEST

0x00000001

RQ_AUTHENTICATE_REQUEST

0x00000002

RQ_AUTHORIZE_REQUEST

0x00000004

RQ_RESOLVE_REQUEST_CACHE

0x00000008

RQ_MAP_REQUEST_HANDLER

0x00000010

RQ_ACQUIRE_REQUEST_STATE

0x00000020

RQ_PRE_EXECUTE_REQUEST_HANDLER

0x00000040

RQ_EXECUTE_REQUEST_HANDLER

0x00000080

RQ_RELEASE_REQUEST_STATE

0x00000100

RQ_UPDATE_REQUEST_CACHE

0x00000200

RQ_LOG_REQUEST

0x00000400

RQ_END_REQUEST

0x00000800
Quy trình xử lý Request

Ví dụ tại bước đầu tiên, Begin Request Processing ta sẽ có notify là RQ_BEGIN_REQUEST.

HRESULT __stdcall RegisterModule(DWORD dwServerVersion,

IHttpModuleRegistrationInfo * pModuleInfo,

IHttpServer * pGlobalInfo){

UNREFERENCED_PARAMETER( dwServerVersion );

UNREFERENCED_PARAMETER( pGlobalInfo );

 

// Set the request notifications and exit.

return pModuleInfo->SetRequestNotifications(

new CHelloWorldFactory,

RQ_BEGIN_REQUEST,

0);

}

Tiếp theo để tạo một Native module, cần tạo một class kế thừa từ class IHttpModuleFactory. Ví dụ:

class CHelloWorldFactory : public IHttpModuleFactory{

public:

HRESULT GetHttpModule(OUT CHttpModule ** ppModule,

IN IModuleAllocator * pAllocator){

UNREFERENCED_PARAMETER( pAllocator );

CHelloWorld * pModule = new CHelloWorld;

if (!pModule){

return HRESULT_FROM_WIN32( ERROR_NOT_ENOUGH_MEMORY );

}

else {

*ppModule = pModule;

pModule = NULL;

return S_OK;

}

}

void Terminate() {

delete this;

}

};

Cuối cùng là tạo class kế thừa từ class CHttpModule. Tùy vào các notify cần xử lý mà ta cần định nghĩa lại các hàm của class CHttpModule. Ví dụ:

class CHelloWorld : public CHttpModule {

public:

REQUEST_NOTIFICATION_STATUS OnBeginRequest(

IN IHttpContext * pHttpContext,

IN IHttpEventProvider * pProvider) {

UNREFERENCED_PARAMETER( pProvider );

HRESULT hr;

IHttpResponse * pHttpResponse = pHttpContext->GetResponse();

if (pHttpResponse != NULL){

//Do something

}

return RQ_NOTIFICATION_CONTINUE;

}

};

Các ví dụ trên mô tả một Native module, có chức năng xử lý các notify RQ_BEGIN_REQUEST là các request được gửi tới Web server. Hàm bị ghi đè là hàm OnBeginRequest. Sau đó compile code dưới dạng file DLL.

2. Native module backdoor

Thông thường các loại mã độc sử dụng kỹ thuật này thường handle notify RQ_BEGIN_REQUEST, vì các notify RQ_BEGIN_REQUEST được raise bởi tất cả các request tới Web Server và dữ liệu nằm trong header, body của request đều chưa được xử lý.

Sau khi nhận dữ liệu từ attacker, mã độc sẽ xử lý và trả về kết quả thông qua response. Thông thường mã độc sẽ đính kèm kết quả thực thi vào header hoặc body của response thay vì clear toàn bộ data của response đó.

Cách thức đăng ký một Native module có thể xem ở đây.

Phần sau sẽ phân tích mẫu mã độc IIS Raid mà Viettel Cyber Security thu thập được trong chiến dịch này.

Phân tích mã độc IIS Raid trong chiến dịch

Thông tin mẫu mã độc

Mã độc IIS Raid được sử dụng trong chiến dịch thuộc nhóm mã độc IIS sử dụng Native Module.

Sơ đồ tổng quan

Mã độc sử dụng kỹ thuật Persistent trên IIS Server để thực thi, được load lên bởi file dịch vụ IIS “w3wp.exe” (IIS Worker Process – File sạch của hệ thống) với config tại

“%windir%\System32\inetsrv\config\applicationHost.config”.
File config applicationHost.config trên server nhiễm mã độc

Đây là kỹ thuật lợi dụng tính năng xử lý request & response thông qua dll của IIS để thực thi mã độc. Khi được thực thi, mã độc sẽ handle các request để thực hiện một số chức năng như sau:

Get password trong body request và lưu vào C:\Windows\Temp\creds.db

Chức năng lấy password chứa trong request

Get Cookie và User-Agent trong header request lưu vào C:\Windows\Temp\log.tmp

Chức năng thu thập User-Agent và Cookie
Lưu User-Agent và Cookie vừa lấy vào file log.tmp

Tiếp theo mã độc sẽ kiểm tra các điều kiện trong gói tin request để nhận biết request nào là của attacker. Các điều kiện kiểm tra bao gồm Cookie: sophos và trường X-FFEServer.

Kiểm tra Cookie và X-FFEServer trong header

Giá trị nằm trong X-FFEServer chính là các chức năng khác của mã độc. Có 4 chức năng chính như sau:

  1. Thực thi commandline: “X-FFEServer: CMD|<command>”
Chức năng thực thi command
Debug mã độc chức năng CMD

2. Ping & Pong, chức năng kiểm tra mã độc đã được thực thi: “X-FFEServer: PIN|”

Chức năng Ping&Pong
Debug mã độc chức năng PIN|

3. Chức năng  thực thi shellcode: “X-FFEServer: INJ|<base64_shellcode>”

Chức năng thực thi Shellcode
Debug mã độc chức năng INJ|
Process injection thực thi shellcode

4. Chức năng lấy Credential đã lưu tại C:\Windows\Temp\creds.db: “X-FFEServer: DMP|”

Chức năng lấy thông tin credential đã thu thập được

Cuối cùng kết quả trả về của chức năng sẽ được base64 encode và gửi về cho attacker thông qua trường X-FFEServer trong gói tin response:

Gửi output của các chức năng về cho attacker
Debug mã độc chức năng DMP|

Cách thức phát hiện

  1. Thông qua file config

Giám sát các thay đổi đối với %windir%\system32\inetsrv\config\applicationHost.config có thể phát hiện các ISAPI và Native module.

Ví dụ:

  • Config ISAPI Filter trong applicationHost.config, nằm trong cặp thẻ <isapiFilters></isapiFilters>
  • Config ISAPI Extension trong applicationHost.config, nằm trong cặp thẻ <isapiCgiRestriction></isapiCgiRestriction>
  • Config Native module trong applicationHost.config, nằm trong cặp thẻ <globalModules></globalModules>

2. Thông qua log thực thi

Giám sát việc thực thi và các tham số của AppCmd.exe để phát hiện việc cài đặt các module IIS độc hại.

Ví dụ:

  • Command cài đặt ISAPI Filter
appcmd.exe set config -section:system.webServer/isapiFilters /+"[name='SalesQueryIsapi',path='c:\Inetpub\www.contoso.com\filters\SalesQueryIsapi.dll',enabled='True',enableCache='True']" /commit:apphost
  • Command cài đặt Native module
appcmd.exe set config -section:system.webServer/globalModules /+"[name='ImageCopyrightModule',image='%windir%\system32\inetsrv\imageCopyrightModule.dll']" /commit:apphost

Kết luận

Mã độc IIS là một dòng mã độc nguy hiểm, khó phát hiện, ít được biết đến nhưng ảnh hưởng và tác động của nó gây ra trên hệ thống là vô cùng lớn. Với sự phát triển nhanh chóng của dòng mã độc này từ năm 2018, một số nhóm tấn công đã bắt đầu sử dụng để khai thác dữ liệu trên nhiều máy chủ Exchange trên thế giới, gây ra các thiệt hại lớn về tài sản, mất mát dữ liệu, ... không thể bù đắp lại.

Chiến dịch tấn công này có mức độ nghiêm trọng cao, sử dụng kỹ thuật mới, tinh vi, khó phát hiện với mục đích thu thập, đánh cắp dữ liệu, tài khoản một cách bí mật. Với khả năng khai thác đường vào dễ dàng với lỗ hổng ProxyLogon, Viettel Cyber Security khuyến cáo các đơn vị đề cao cảnh giác, thực hiện loại bỏ lỗ hổng ProxyLogon còn tồn tại trong hệ thống của mình, đồng thời theo dõi các IOC của chiến dịch để phát hiện sớm nguy cơ mất mát dữ liệu của đơn vị mình.

Sign up for more like this.

Enter your email
Subscribe