IR 102: Remote Triage

1. Tìm kiếm những thành phần độc hại

💡

Finding Evil

Trong một số trường hợp, dữ liệu về IOCs xác định được trong quá trình ứng phó sự cố ban đầu hoặc trong quá trình phân tích sau đó có thể được sử dụng để xác định phạm vi của sự cố bảo mật. Sự tồn tại của một tiến trình lạ hay xuất hiện Registry key khả nghi, giá trị băm của một tệp thực thi,.v.v. đều có thể được dùng làm IOCs để rà quét hệ thống của tổ chức nhằm nhanh chóng xác định các hệ thống bị ảnh hưởng.

1.1. Các kết nối độc hại

💡

Rogue Connections

Trong hầu hết các cuộc tấn công, tin tặc sẽ tạo ra các kết nối mạng, có thể là kết nối tuồn dữ liệu đánh cắp được ra ngoài, các kết nối điều khiển với C2 Server hoặc các kết nối giữa các hệ thống nội bộ của nạn nhân vì những “chuyển động” này cho thấy tin tặc đang tiến thành dò quét, do thám các hệ thống.

Để hoạt động của mình trở nên khó phát hiện hơn, tin tặc sẽ không thực hiện kết nối liên tục về C2 Server, thay vào đó các kết nối sẽ được thực hiện định kỳ. Một số công cụ miễn phí dùng trong giám sát giúp xác định các kết nối độc hại và thống kê về các kết nối mạng:

Security Onion: https://securityonionsolutions.com/

Real Intelligence Threat Analytics (RITA): https://github.com/activecm/rita

Trong một hệ thống CNTT, các kết nối phổ biến nhất có thể là HTTP, HTTPS và DNS. Do vậy tin tặc thường sử dụng các giao thức này cho các lưu lượng của mình nhằm tránh bị phát hiện dễ dàng. RITA là một công cụ phân tích lưu lượng mạng dựa trên CSDL của Zeek, nó sẽ phân tích tần suất xuất hiện của một kết nối, kích thước gói tin, lượng gửi/nhận dữ liệu, thời gian và nhiều yếu tố khác để xác định đâu là lưu lượng độc hại. Quá trình ứng phó sự cố có thể gặp khó với các hệ thống sử dụng lưu lượng HTTPS, các DNS Logs hay Proxy Logs có thể sẽ hữu dụng trong trường hợp này. Khi phân tích một hệ thống bị thỏa hiệp có thể sẽ sử dụng một Web Proxy tương tác như: BurpSuite, Zed Attack Proxy (ZAP).

Ngoài ra các dạng kết nối khác cũng phổ biến trong mạng cũng cần được xem xét kỹ lưỡng, bất kỳ tài khoản nào khởi tạo các kết nối không rõ ràng đều phải được kiểm tra chi tiết hơn để xác định xem hành động có hợp pháp hay không.

Common lateral movement connection ports

1.2. Các tiến trình bất thường

💡

Unusual Processes

Đối với kẻ tấn công để có thể thực thi mã (rce) được trên hệ thống nạn nhân thì mã đó phải tồn tại trong ngữ cảnh của một tiến trình. Một tiến trình có thể được coi là một container chứa code và các tài nguyên hệ thống mà nó phụ thuộc.

💡

Một tiến trình có thể được coi là một container chứa code và các tài nguyên hệ thống mà nó phụ thuộc, tiến trình được cấp phát vùng nhớ chuyên dụng, có handle cho các tài nguyên (file, registry,..). Mỗi tiến trình được gán một ID duy nhất và được tham chiếu đến một tiến trình khác đã tạo ra nó (tiến trình cha). Cuối cùng, một tiến trình sẽ có ít nhất một luồng thực thi có khả năng thực hiện các lệnh trên CPU

Vì mã của kẻ tấn công phải tồn tại trong một tiến trình trên hệ thống ⇒ Nhiều quản trị viên ngay lập tức sẽ kiểm tra bằng cách sử dụng các lệnh như ps hoặc tasklist để lấy danh sách các tiến trình trên hệ thống, tuy nhiên không phải lúc nào cũng may mắn mà phát hiện ngay được tiến trình nào là độc hại vì các tiến trình độc hại có thể được đặt tên giống với các tiến trình chuẩn. Do đó, để phát hiện được tiến trình độc hại, trước tiên quản trị viên cần phải có ý tưởng về những tiến trình chạy trên hệ thống như: hồ sơ về lịch sử các tiến trình trên hệ thống ở thời điểm máy "sạch". Hãy nhớ rằng, hành động phát hiện ra sự cố thường liên quan đến việc nhận thấy độ lệch so với bình thường. Để nhận ra được sự sai lệch này thì trước tiên bạn phải biết được khi bình thường thì trông nó như thế nào.

💡

Trên HĐH Windows, khi kiểm tra các tiến trình ở bất kỳ thời điểm nào cũng sẽ thấy xuất hiện rất nhiều tiến trình có tên là svchost.exe. Đây là một tiến trình đặc biệt trên Windows, được thiết kế để chạy các dịch vụ dưới dạng DLL, khi một dịch vụ được khởi chạy, tiến trình svchost sẽ nạp DLL đó vào vùng nhớ của mình và thực thi. Vì trên HĐH Windows có nhiều dịch vụ được chạy nên dẫn đến việc có rất nhiều tiến trình svchost.exe xuất hiện.

Những kẻ tấn công cũng có thể đặt tên của tiến trình độc hại giống với tiến trình chuẩn là svchost.exe, khi đó kết quả trả về của tasklist hay ps sẽ làm cho quản trị viên khó có thể xác định đâu mới là tiến trình độc hại ⇒ Để phát hiện các tiến trình độc hại dạng này, cần phải xác định vị trí của tiến trình được thực thi, tiến trình độc hại có thể đặt tên trùng với tiến trình chuẩn nhưng không thể đặt tại ví trí trùng với tiến trình chuẩn. Một ví dụ sau sẽ cung cấp chi tiết các tiến trình của hệ thống kèm commandline sẽ xác định được vị trí của tiến trình:


$ wmic process where name="svchost.exe" get name, processid, parentprocessid, commandline
CommandLine                                                                                     Name         ParentProcessId  ProcessId
C:\Windows\system32\svchost.exe -k DcomLaunch -p                                                svchost.exe  868              1008
C:\Windows\system32\svchost.exe -k RPCSS -p                                                     svchost.exe  868              924
C:\Windows\system32\svchost.exe -k DcomLaunch -p -s LSM                                         svchost.exe  868              1088
C:\Users\John\Downloads\svchost.exe                                                             svchost.exe  6096             4204
C:\Windows\System32\svchost.exe -k netsvcs -p -s BDESVC                                         svchost.exe  868              1224
C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted -p -s lmhosts                  svchost.exe  868              1264
C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted -p -s NcbService                svchost.exe  868              1304
...

💡

Trên HĐH Windows, tên tệp tin và tên thư mục không phân biệt hoa thường, điều này ngược lại với các hệ thống Linux/UNIX vì chúng phân biệt hoa thường.

Khi hệ thống hoạt động ở trạng thái được cho là bình thường, quản trị viên cần theo dõi, lưu lại các bản chụp danh sách các tiến trình trên hệ thống "sạch", đây sẽ là dữ liệu cùng quan trọng khi có sự cố xảy ra. Trong quá trình ứng phó sự cố, người thực hiện xử lý sự cố khi kiểm tra các tiến trình phải dựa vào nhiều đặc điểm, chi tiết khác nhau để xác định tính hợp pháp của tiến trình:

Thông tin về đường dẫn của tiến trình có bất thường không

Thông tin tin về các tiến trình cha-con có bất thường không

Thời gian tiến trình được khởi chạy có bất thường không

Các thư viện mà tiến trình nạp vào có bất thường không

Chữ ký số của tệp, thông tin chủ sở hữu, nhà sản xuất phần mềm,..

Xác định các kỹ thuật nâng cao: DLL Injection, Process Hollowing, Code Caving,..

💡

Trên HĐH Windows, không thể xóa một tệp thực thi khi mà nó đang được chạy, ngược lại trên các hệ thống *nix khi một tiến trình đang chạy vẫn có thể xóa tệp thực thi của chúng, khi đó chúng vẫn tồn tại trên bộ nhớ RAM.

1.3. Các cổng bất thường

💡

Unusual Ports

Tương tự như kiểm tra Process, với các Port đang được mở để lắng nghe các kết nối trên hệ thống cũng cần được theo dõi, lập hồ sơ, lưu lại bản chụp tại thời điểm hệ thống được cho là "sạch".


# Windows
$ netstat -anob

# Linux
$ netstat -anp

Sử dụng một công cụ như Nmap (https://nmap.org/) để quét mạng từ bên ngoài sau đó xác định các Port đang mở cũng là một cách hay trong trường hợp đã kiểm tra trên hệ thống nhưng không thể xác định được port nghi ngờ đang mở, rất có thể hệ thống đã bị lây nhiễm và đã bị ẩn đi bởi Rootkits. Ngoài ra có thể phân tích dữ liệu mạng bằng các công cụ như NetFlow/IPFIX hoặc Zeek logs để xác định các cổng bất thường.

1.4. Các dịch vụ bất thường

💡

Unusual Services

Các dịch vụ trên hệ thống là những chương trình đặc biệt, chúng không tương tác trực tiếp với người dùng. Các dịch vụ có cơ chế tự động khởi chạy khi hệ thống được bật, vì vậy tin tặc luôn muốn lợi dụng cơ chế này để duy trì được cơ chế persistent trên hệ thống. Tương tự như Process và Port, cũng cần duy trì một hồ sơ các dịch vụ chạy ở trạng thái máy "sạch”.

💡

Rogue Accounts

Xác định các tài khoản không thuộc về hệ thống hoặc đang được sử dụng không đúng mục đích, bất hợp pháp so với hành vi cùa người dùng hợp pháp là bước quan trọng trong ứng phó sự cố. Hệ thống cần được phân tích để xác định các tài khoản mới tạo ở cả Local và Domain, các tài khoản đã tạo trước đó nhưng chưa được kích hoạt (VD: Nhân viên đã nghỉ việc), các nhóm người dùng có đặc quyền cao (VD: Các nhóm quản trị viên).

💡

Nguyên tắc đặc quyền tối thiểu. Các tài khoản chỉ nên được cấp đặc quyền tối thiểu, đủ để thực hiện công việc của họ. Những tài khoản được cấp đặc quyền chỉ nên được sử dụng từ máy trạm được bảo mật tốt, những máy trạm này không được dùng chung hay sử dụng đa mục đích. VD: Không nên vừa để duyệt web, vừa dùng email, hay các hoạt động rủi do cao khác,.v.v..

Tham khảo:

Just Enough Administration - https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/jea/overview

Protected Users Security Group - https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group

Xác định các tài khoản đáng ngờ có những hoạt động bất thường, ví dụ: tài khoản được sử dụng để cố gắng thử đăng nhập ở nhiều máy khác nhau. Công cụ LogonTracer của JPCERTCC giúp chúng ta hình dung được các hoạt động đăng nhập của người dùng:

LogonTracer - https://github.com/JPCERTCC/LogonTracer

Kerberoasting (sẽ thảo luận trong các bài sau) là một kỹ thuật được sử dụng để xác định mật khẩu của các tài khoản dịch vụ được tạo thủ công, nó sử dụng công cụ bẻ khóa mật khẩu như Hashcat. Để phòng tránh, các tài khoản dịch vụ phải được quản lý bởi Managed Service Accounts (MSAs). Cách tiếp cận này giúp cho các mật khẩu có độ phức tạp cao và ngăn chặn sử dụng các tài khoản này để tương tác.

Trên các hệ thống UNIX/Linux, ngoài nhóm người dùng cũng cần lưu ý đến ID người dùng. VD: ID bằng 0 là tài khoản người dùng có đặc quyền cao. Tệp /etc/passwd cần được chú ý với bất kỳ tương tác nào, các tài khoản chạy các dịch vụ trên hệ thống, chúng không nên được phép đăng nhập vào hệ thống một cách trực tiếp, trong tệp /etc/passwd nếu xuất hiện tài khoản có login shell mà dùng để chạy các daemon process thì rất đáng nghi ngờ. Ngoài ra cũng cần kiểm tra Pluggable Authentication Modules (PAMs), nó được dùng để xác thực tài khoản, kiểm tra các tệp cấu hình của PAM.

1.6. Các tệp tin bất thường

💡

Unusual Files

Hệ thống tệp tin có thể bị sửa đổi nhằm ẩn đi các công cụ độc hại của tin tặc, các tệp thực thi nếu nằm ở những thư mục tạm thời có thể rất đáng ngờ. Kẻ tấn công có thể che giấu tệp độc hại bằng việc thay đổi thành phẩn mở rộng của tệp tin (Windows). Trên các hệ thống tệp tin NTFS, mỗi tệp tin sẽ có nhiều thuộc tính khác nhau, các bài sau sẽ nói về Alternate Data Streams (ADS) thường bị lợi dụng để ẩn dữ liệu trên các hệ thống NTFS. Phần trước đã đề cập đến việc tin tặc có thể giả mạo tên của các tiến trình chuẩn, trong quá trình kiểm tra cần theo dõi cả đường dẫn tệp thực thi, tuy nhiên cũng có trường hợp tin tặc đặt tên với ý đồ gây nhầm lẫn, tên gần giống với tiến trình chuẩn và đặt cùng đường dẫn thực thi với tiến trình chuẩn. VD: scvhost

Trên các hệ thống UNIX/Linux, cho phép đặt tên với nhiều bộ ký tự hơn và điều này thường bị lạm dụng bởi tin tặc. VD: Đặt tên tệp là 1 ký tự khoảng trắng, đặt tên tệp với chữ hoa-thường giống với tiến trình chuẩn.

1.7. Các chương trình khởi động cùng hệ thống

💡

Autostart Locations

Trên cả HĐH Windows, và UNIX/Linux sẽ có những vị trí đặt tệp hoặc những cấu hình mà cho phép chương trình được khởi chạy cùng hệ thống. Với Windows, một trong những cách đơn giản nhất đó là thêm vào một khóa Registry với giá trị trỏ đến đường dẫn của tệp thực thi, ví dụ một số vị trí có thể tạo khóa Registry khởi động chương trình cùng hệ thống:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Sử dụng công cụ Autoruns trong bộ Sysinternal Suites của Microsoft có thể kiểm tra được rất nhiều autostart location: startup folder, registry keys, browser helper object, explorer shell extension, scheduled task,.v.v.. Trên UNIX/Linux cũng có nhiều cách để khởi chạy cùng hệ thống; Crontab, Systemd, init.d,.v.v..

Autoruns: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns

💡

Hiểu về các kỹ thuật tấn công có thể giúp ích rất nhiều cho bạn trong việc xác định các dấu vết của hoạt động độc hại. ATT&CK Matrix đã phân loại các hành động của những kẻ tấn công thành các nhóm chiến thuật khác nhau, mỗi nhóm mô tả chi tiết các kỹ thuật của hacker.

2. Bảo vệ thông tin khi ứng phó sự cố

💡

Guarding Your Credentials

Khi ứng phó sự cố, chúng ta sẽ phải đối mặt với nhiều loại thông tin khác nhau, cần phải có một phương thức để tìm kiếm thông tin từ xa. Trước tiên cần phải học cách làm sao để khi ứng phó sự cố chúng ta không vô tình làm cho sự cố trở lên nghiêm trọng hơn. Ở phần trước đã đề cập đến việc hacker sẽ chủ động tìm kiếm thông tin đăng nhập có đặc quyền cao để sử dụng trong quá trình chúng tấn công, xác thực các hệ thống khác. Trong quá trình ứng phó sự cố, người ứng phó sử dụng các tài khoản có đặc quyền cao để truy vấn các hệ thống từ xa, phân tích bộ nhớ hay các hệ thống bị ảnh hưởng ⇒ Chúng ta phải nhận thức được rằng, việc sử dụng các tài khoản đặc quyền cao này trên một hệ thống có khả năng hoặc đã bị xâm phạm sẽ có nguy cơ bị đánh cắp bởi hacker.

2.1. Hiểu về đăng nhập tương tác

💡

Understanding Interactive Logons

Logon tương tác liên quan đến người dùng trực tiếp cung cấp thông tin xác thực cho một hệ thống. VD: Đăng nhập bằng username/password vào giao diện đăng nhập (LogonUI.exe). LogonUI.exe sẽ nhận được tên người dùng và mật khẩu sau đó chuyển chúng đến Local Security Authority Subsystem Service (LSASS). LSASS thực hiện việc băm mật khẩu nó nhận được (NTLM) và so sánh kết quả sau khi băm với mật khẩu đã băm được lưu trong Security Accounts Manager (SAM), nếu chúng khớp nhau thì xác thực được coi là thành công.

Với môi trường Domain, quá trình xác thực diễn có chút khác biệt so với Local. LogonUI.exe vẫn chuyển thông tin xác thực đến cho LSASS, LSASS vẫn tính toán băm nhưng thay vì nó so sánh với băm đã lưu trong SAM thì nó sẽ sử dụng các chức năng trong thư viện Kerberos.dll để gửi yêu cầu xác thực đến Domain Controller. Khi xác thực thành công, Domain Controller sẽ cấp vé Kerberos ticket-granting ticket (TGT) cho LSASS, vé này có thời gian hiệu lực nhất định (mặc định 10 tiếng).

Bất kỳ cơ chế xác thực nào được sử dụng thì LSASS vẫn lưu trữ giá trị NT Hash đã được tính toán và vé TGT nhận được từ Domain Controller trong không gian bộ nhớ của nó (RAM), điều này mục đích hỗ trợ cơ chế đăng nhập một lần của Microsoft (Single sign-on): Khi mà phiên đăng nhập đó chưa hết hạn thì người dùng sẽ không cần phải nhập lại thông tin đăng nhập để xác thực, LSASS sẽ sử dụng giá trị NT Hash hoặc Kerberos ticket-granting ticket (TGT) để “thay mặt” người dùng xác thực khi cần thiết.

Mặc dù cơ chế SSO này thuận tiện cho người dùng nhưng cần hiểu rõ rủi do sau: Giá trị NT Hash được sử dụng để thực hiện xác thực trong môi trường Windows ⇒ Sở hữu giá trị NT Hash không khác gì sở hữu mật khẩu của người dùng. Một điểm nữa, LSASS sử dụng NT Hash lưu trên bộ nhớ để mã hóa các Challenges trả về từ các hệ thống, với tài khoản Local sử dụng NT Hash trong SAM để mã hóa Challenges. Nếu Encrypted Challenges được tính toán tại Local khớp với Remote thì quyền truy cập được xác thực. Tương tự với TGT, nó được coi như tấm “hộ chiếu” của người dùng trong mạng, khi người dùng muốn truy cập hệ thống từ xa thì chỉ cần trình ra “hộ chiếu” cùng với quyền yêu cầu truy cập. Như vậy kẻ tấn công thường lợi dụng để mạo danh người dùng đã xác thực trong thời gian TGT chưa hết hạn, cộng thêm Domain Controller cũng không xác nhận xem người dùng có quyền truy cập vào tài nguyên hay không mà thay vào đó nó mã hóa các quyền truy cập bằng khóa bí mật được chia sẻ với các dịch vụ ⇒ Đây là cơ sở cho tấn công Kerberoasting sẽ trình bày chi tiết trong các bài sau.

Do đó bộ nhớ của tiến trình LSASS luôn là mục tiêu của hacker. Để có thể truy cập được vào bộ nhớ của LSASS thì hacker cần phải có đặc quyền quản trị trên hệ thống. Với thông tin về quản trị viên trên hệ thống Local đó, hacker sử dụng công cụ Mimikatz (https://github.com/gentilkiwi/mimikatz) để xác định và trích xuất thông tin đăng nhập.

Thời điêm hiện tại, hệ thống Windows băm mật khẩu và không đi kèm với Salt. Do đó những người dùng đặt mật khẩu giống nhau sẽ dẫn đến giá trị NT Hash giống nhau.

2.2. Phòng tránh các sự cố khi ứng phó

💡

Incident Handling Precautions

Có nhiều sự cố được gây ra bởi sự chủ đích của hacker với hy vọng rằng quản trị viên, helpdesk của tổ chức sẽ đăng nhập vào hệ thống diễn ra sự cố với tài khoản có đặc quyền cao. Do đó như thực hiện ứng phó sự cố, người tham gia cần phải nhận thức được rủi do này và có những hành động phù hợp. Một Logon tương tác là bất cứ phương thức đăng nhập nào có sử dụng username/password, nó có thể là:

Đăng nhập trực tiếp tại máy tính (truy cập vật lý)

Virtual Network Computing (VPN)

Remote Desktop Protocol (RDP)

Sử dụng các công cụ runas, psexec,.v.v..

⇒ Bất cứ khi nào LSASS nhận được thông tin đăng nhập nó sẽ thực hiện băm và lưu vào bộ nhớ ⇒ Đều có khả năng bị hacker dump. Một số dạng tấn công hacker sử dụng

Pass-the-hash: Sử dụng thông tin đăng nhập đã được băm để xác thực

Tương tự với Kerberos ticket-granting ticket (TGT)

Trên hệ các hệ thống *nix có sử dụng giao thức SSH để truy cập từ xa, một số hệ thống sử dụng ssh-agent để lưu các key tránh người dùng phải đăng nhập lại dẫn đến hacker cũng có thể lợi dụng để dump các key không được mã hóa.

2.3. RDP Restricted Admin và kết nối từ xa an toàn

💡

RDP Restricted Admin Mode and Remote Credential Guard

Kể từ phiên bản Windows Server 2012, Microsoft giới thiệu tính năng mới nhằm giảm thiểu rủi do đánh cắp các thông tin xác thực từ bộ nhớ có tên là “Restricted Admin mode”. Chế độ này cho phép đăng nhập được thực hiện qua Microsoft Terminal Services Client (mstsc.exe), người dùng đăng nhập từ xa sẽ tiến hành nhập username/password tại ứng dụng Client, tại máy Server sẽ không tiếp nhận username/password trực tiếp mà chỉ là NT Hash do đó nó sẽ không lưu NT Hash vào bộ nhớ. Tuy nhiên phương pháp này đối mặt với kiểu tấn công khác là Pass-the-hash, vì vậy chế độ Restricted Admin được tắt theo mặc định và sẽ dẫn đến trường hợp là còn tính năng SSO, người dùng sẽ thường xuyên phải nhập lại username/password để xác thực.

Kể từ Windows 10 version 1607, Microsoft khắc phục nhược điểm của Restricted Admin Mode bằng Windows Defender Remote Credential Guard, sử dụng xác thực Kerberos, cách tiếp cận này sẽ chuyển hướng các Kerberos request trong phiên RDP. Tham khảo: https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

3. Kết luận

💡

Conclusion

Tiến hành phân tích hiệu quả một hệ thống Local hay Remote để xác định phạm vi của sự cố là rất quan trọng trong toàn bộ quá trình ứng phó sự cố. Những thông tin quan trọng như: Tên miền, Địa chỉ IP, Các tiến trình, dịch vụ, các cổng hay sự xuất hiện của các tài khoản lạ, các tệp bất thường,.v.v. đều rất quan trọng. Khi tiến hành ứng phó sự cố, người tham gia cần cẩn thận bảo vệ các thông tin đặc quyền, thông tin đăng nhập để tránh những tình huống làm cho sự cố trở lên nghiêm trọng hơn.

4. Tham khảo

Steve Anson (2020). Applied Incident Response, John Wiley & Sons, Inc