Phát hiện tấn công trên Windows với Splunk

Domain Reconnaissance

Các công cụ thường được sử dụng trong tấn công:

• whoami /all
• wmic computersystem get domain
• net user /domain
• net group "Domain Admins" /domain
• arp -a
• nltest /domain_trusts

Ngoài ra để thu thập thông tin về domain, kẻ tấn công có thể sử dụng SharpHound/BloodHound. Bản chất của công cụ này là sử dụng LDAP để truy vấn thông tin.

Có 2 cách thu thập dữ liệu liên quan đến truy vấn LDAP đến Splunk bao gồm:

• Bật ghi Event 1644 cho ETW - không bật ghi theo mặc định nên cần phải tìm cách cấu hình.
• Thu thập stream log trên domain controllers qua Splunk App For Stream

Cách phát hiện thông qua sysmon EventID=1:

index=main source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventID=1
| search process_name IN (arp.exe,chcp.com,ipconfig.exe,net.exe,net1.exe,nltest.exe,ping.exe,systeminfo.exe,whoami.exe) OR (process_name IN (cmd.exe,powershell.exe) AND process IN (*arp*,*chcp*,*ipconfig*,*net*,*net1*,*nltest*,*ping*,*systeminfo*,*whoami*))
| stats values(process) as process, min(_time) as _time by parent_process, parent_process_id, dest, user
| where mvcount(process) > 3

Cách phát hiện BloodHound qua LDAP filters:

index=main source="WinEventLog:SilkService-Log"
| spath input=Message 
| rename XmlEventData.* as * 
| table _time, ComputerName, ProcessName, ProcessId, DistinguishedName, SearchFilter
| sort 0 _time
| search SearchFilter="*(samAccountType=805306368)*"
| stats min(_time) as _time, max(_time) as maxTime, count, values(SearchFilter) as SearchFilter by ComputerName, ProcessName, ProcessId
| where count > 10
| convert ctime(maxTime)

LLMNR/NBT-NS/mDNS Poisoning

Các bước tấn công:

1. Thiết bị nạn nhân gửi truy vấn phân giải tên cho một tên máy chủ bị nhập sai (ví dụ: fileshare).
2. DNS không phân giải được tên máy chủ bị nhập sai.
3. Thiết bị nạn nhân gửi truy vấn phân giải tên cho tên máy chủ bị nhập sai bằng LLMNR/NBT-NS.
4. Máy chủ của kẻ tấn công phản hồi lưu lượng LLMNR (UDP 5355)/NBT-NS (UDP 137), giả vờ biết danh tính của máy chủ được yêu cầu → dẫn nạn nhân giao tiếp với hệ thống do kẻ tấn công kiểm soát.

Cách phát hiện:

• Cách 1: Triển khai các giải pháp giám sát mạng để phát hiện các mẫu lưu lượng LLMNR và NBT-NS bất thường, chẳng hạn như khối lượng lớn yêu cầu phân giải tên từ một nguồn duy nhất.
• Cách 2: Sử dụng phương pháp honeypot - việc phân giải tên cho các máy chủ không tồn tại sẽ thất bại. Nếu kẻ tấn công giả mạo phản hồi LLMNR/NBT-NS/mDNS, việc phân giải tên sẽ thành công.

Phát hiện trên Splunk:

• Theo dõi truy vấn DNS lạ

  index=main EventCode=22 
  | table _time, Computer, user, Image, QueryName, QueryResults
  

• Phát hiện rogue file shares mà attacker có thể sử dụng để thu thập credential của người dùng:

  index=main EventCode IN (4648) 
  | table _time, EventCode, source, name, user, Target_Server_Name, Message
  | sort 0 _time
  

Kerberoasting

Kerberoasting là một kỹ thuật tấn công nhắm vào các service account được đặt mật khẩu yếu trong môi trường Active Directory.

Các bước thực hiện tấn công:

1. Phát hiện các service account được sử dụng cho các service như IIS, SQL Server, Exchange,…
2. Thực hiện yêu cầu xin TGS từ KDC, sau đó trích xuất password hash từ response trả về và tiến hành crack offline với Hashcat, John the Ripper,…

Các EventID liên quan:

• Event ID 4768 (Kerberos TGT Request)
• Event ID 4769 (Kerberos Service Ticket Request)
• Event ID 4624 (Logon)

Cách phát hiện dựa vào Splunk:

• Tìm kiếm các truy vấn SPN của service account qua dữ liệu LDAP

  index=main source="WinEventLog:SilkService-Log" 
  | spath input=Message 
  | rename XmlEventData.* as * 
  | table _time, ComputerName, ProcessName, DistinguishedName, SearchFilter 
  | search SearchFilter="*(&(samAccountType=805306368)(servicePrincipalName=*)*"
  

• Dựa vào việc quan sát normal baselines của service account. Ví dụ: quan sát thứ tự sự kiện khi service account của dịch vụ IIS được đăng nhập sẽ gồm 2 EventID được ghi lại là 4769 và 4648 (A logon was attempted using explicit credentials). Khi có tấn công Kerberoasting, do cần có thời gian crack hash password, sẽ không có EventID 4648 diễn ra. SPL Splunk ví dụ:

  #Ví dụ 1
  index=main earliest=1690450374 latest=1690450483 EventCode=4648 OR (EventCode=4769 AND service_name=iis_svc)
  | dedup RecordNumber
  | rex field=user "(?<username>[^@]+)"
  | bin span=2m _time 
  | search username!=*$ 
  | stats values(EventCode) as Events, values(service_name) as service_name, values(Additional_Information) as Additional_Information, values(Target_Server_Name) as Target_Server_Name by _time, username
  | where !match(Events,"4648")
  
  #Ví dụ 2: Detecting Kerberoasting Using Transactions - TGS Requests
  index=main earliest=1690450374 latest=1690450483 EventCode=4648 OR (EventCode=4769 AND service_name=iis_svc)
  | dedup RecordNumber
  | rex field=user "(?<username>[^@]+)"
  | search username!=*$ 
  | transaction username keepevicted=true maxspan=5s endswith=(EventCode=4648) startswith=(EventCode=4769) 
  | where closed_txn=0 AND EventCode = 4769
  | table _time, EventCode, service_name, username
  

AS-REProasting

AS-REProasting là một kỹ thuật tấn công nhắm vào các user account không bật pre-authentication.

Khi pre-authentication được bật, yêu cầu AS-REQ từ client đến KDC sẽ chứa giá trị timestamp được mã hoá (pA-ENC-TIMESTAMP) bởi password hash của user. KDC xác nhận timestamp bằng cách giải mã giá trị này.

Khi pre-authentication được bật, timestamp không được xác nhận bởi KDC, cho phép user yêu cầu TGT mà không cần password.

Các bước tấn công:

1. Tìm kiếm các user account với pre-authentication bị tắt
2. Yêu cầu AS-REQ Service Ticket với các account phát hiện được
3. Thu thập TGT và triển khai offline hash crack

Cách phát hiện với Splunk:

• Phát hiện LDAP query filter pattern với các account có pre-authentication bị tắt

  index=main source="WinEventLog:SilkService-Log" 
  | spath input=Message 
  | rename XmlEventData.* as * 
  | table _time, ComputerName, ProcessName, DistinguishedName, SearchFilter 
  | search SearchFilter="*(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=4194304)*"
  

• Tìm kiếm các sự kiện có EventID=4768 với Pre_Authentication_Type=0

  index=main source="WinEventLog:Security" EventCode=4768 Pre_Authentication_Type=0
  | rex field=src_ip "(\:\:ffff\:)?(?<src_ip>[0-9\.]+)"
  | table _time, src_ip, user, Pre_Authentication_Type, Ticket_Options, Ticket_Encryption_Type
  

Pass-the-Hash

Pass-the-Hash là kỹ thuật tấn công mà trong đó, kẻ tấn công không sử dụng plaintext password để đăng nhập vào hệ thống mạng mà sử dụng NTLM hash. Để có được NTLM hash trên một máy bị thao túng thì cần có quyền quản trị viên.

Các bước tấn công như sau:

1. Khi thao túng được một máy với quyền cao nhất, kẻ tấn công sử dụng Mimikatz để trích xuất NTLM hash của user đang trong phiên đăng nhập.
   
2. Kẻ tấn công sử dụng NTLM hash này đăng nhập vào các hệ thống khác trên mạng → di chuyển ngang.
   

Các quan sát thấy được trên hệ thống bị thao túng khi có tấn công:

• access token là một cấu trúc dữ liệu định nghĩa security context của một process hay thread. Khi nói đến security context, tức là liên quan đến hai đối tượng chính là identity (user account) và quyền của nó (privileges). Khi user đăng nhập thành công, hệ thống tạo access token và sau đó, tất cả process chạy dưới context của user đó đều có bản copy của access token này.

• Mỗi access token liên quan đến một LogonSession khi người dùng đăng nhập. LogonSession bao gồm các thông tin như Username, Domain, và AuthenticationID (NTHash/LMHash) được sử dụng khi tiến trình cố gắng truy cập tài nguyên từ xa

• Alternate Credentials cho phép cung cấp một credential của user khác cho một process hoặc để thực hiện hành động nào đó mà không làm thay đổi phiên đăng nhập chính. Ví dụ dễ hình dung hơn chính là runas command:

  • Khi không được chạy với flag /netonly, trên máy bị thao túng thực hiện tấn công, cả access token và LogonSession đều mới hoàn toàn.

    • Nếu kẻ tấn công dùng /runas để chạy process tại local, EventID 4624 sẽ ghi LogonType=2 (Interactive)

  • Khi chạy với flag /netonly, process sẽ vẫn dùng access token cũ nhưng được liên kết với LogonSession mới.

    • Nếu kẻ tấn công dùng /runas để chạy process tại local, EventID 4624 sẽ ghi LogonType=9 (Interactive)

• Trong trường hợp của Mimikatz, nó sẽ truy cập LSASS (Sysmon Event=10) để thay đổi LogonSession

Cách phát hiện sử dụng mimikatz để pass-the-hash trên Splunk:

• Sử dụng EventCode=4624 Logon_Type=9

index=main earliest=1690450708 latest=1690451116 source="WinEventLog:Security" EventCode=4624 Logon_Type=9 Logon_Process=seclogo
| table _time, ComputerName, EventCode, user, Network_Account_Domain, Network_Account_Name, Logon_Type, Logon_Process

• Kết hợp với Sysmon Event=10 và EventCode=4624

index=main earliest=1690450689 latest=1690451116 (source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 TargetImage="C:\\Windows\\system32\\lsass.exe" SourceImage!="C:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\MsMpEng.exe") OR (source="WinEventLog:Security" EventCode=4624 Logon_Type=9 Logon_Process=seclogo)
| sort _time, RecordNumber
| transaction host maxspan=1m endswith=(EventCode=4624) startswith=(EventCode=10)
| stats count by _time, Computer, SourceImage, SourceProcessId, Network_Account_Domain, Network_Account_Name, Logon_Type, Logon_Process
| fields - count

Pass-the-Ticket

Tương tự Pass-the-Hash, nhưng thay vì khai thác NTLM hash thì tấn công này sử dụng lại TGT/TGS để tiếp cận tài nguyên, hệ thống khác trong mạng.

Các bước tấn công:

1. Trên máy bị thao túng mà kẻ tấn công có quyền quản trị, Mimikatz hoặc Rubeus được sử dụng để trích xuất TGT/TGS
2. Sử dụng TGT để request TGS mới hoặc gửi thẳng TGS đến service muốn truy cập.

Các sự kiện liên quan:

• Event ID 4648 (Explicit Credential Logon Attempt)
• Event ID 4624 (Logon)
• Event ID 4672 (Special Logon)
• Event ID 4768 (Kerberos TGT Request)
• Event ID 4769 (Kerberos Service Ticket Request)

Cách tiếp cận để phát hiện tấn công:

• Tìm kiếm máy nào không có sự kiện 4768 trong khoảng thời gian cụ thể → việc xác định khoảng thời gian cụ thể này có thể dựa vào cấu hình expire của TGT/TGS trong môi trường, đôi lúc sẽ dễ có nhiều False Postitives.
• Trong nhiều trường hợp, có thể có sự bất hợp lý từ Service và Host IDs trong sự kiện 4769 với Source/Destination trong EventID=3 (ghi lại các kết nối mạng). Tức máy do attacker gửi TGS đi (có Source trong EventID=3) khác với Host IDs thực sự trong ticket TGS mà sự kiện 4769 ghi nhận được.
• Xem xét cả Event ID 4771 (Kerberos Pre-Authentication Failed) với hai giá trị Pre-Authentication type và Failure Code. Ví dụ, Pre-Authentication type 2 (Encrypted Timestamp) với Failure Code 0x18 (Pre-authentication information was invalid) chỉ ra rằng client đã gửi Kerberos AS-REQ với dấu thời gian được mã hóa xác thực trước, nhưng KDC không thể giải mã được.

Phát hiện với Splunk:

index=main earliest=1690392405 latest=1690451745 source="WinEventLog:Security" user!=*$ EventCode IN (4768,4769,4770) 
| rex field=user "(?<username>[^@]+)"
| rex field=src_ip "(\:\:ffff\:)?(?<src_ip_4>[0-9\.]+)"
| transaction username, src_ip_4 maxspan=10h keepevicted=true startswith=(EventCode=4768)
| where closed_txn=0
| search NOT user="*$@*"
| table _time, ComputerName, username, src_ip_4, service_name, category

maxspan=10h - window time này cần được custom để giảm False Positives.

Overpass-the-Hash

Hay Pass-the-Key là một kỹ thuật sử dụng password hash để tạo yêu cầu TGT đến KDC.

Cả NTLM hash và AES keys đều có thể được dùng để yêu cầu TGT.

Các bước tấn công:

1. Sử dụng Mimikatz để trích xuất NTLM hash của user hiện tại đang trong phiên đăng nhập trên máy, tối thiểu phải có quyền local administrator để thực hiện việc này.
2. Sử dụng công cụ như Rubeus để tạo yêu cầu TGT đến KDC.

Cách phát hiện:

• Đây là một tấn công khá tinh vi, quá trình xác thực Kerberos diễn ra bình thường và có đủ các sự kiện nên không thể áp dụng phương pháp phát hiện như PtT.
• Có thể phát hiện các process không phải LSASS kết nối đến dest_port=88 qua EventID=1. Nhưng một lần nữa, việc triển khai lưu trữ log tại Splunk gặp giới hạn do cần có log ở máy thực hiện tấn công của attacker, trong khi Splunk chỉ có log AD/DC. Ý tưởng khác là tận dụng endpoint protection được cài tại máy hơn là sử dụng WinEventLog.

Golden Tickets

Khi kẻ tấn công đã có trong tay NTLM hash của tài khoản krgtgt thông qua tấn công DCSync hoặc LSASS Dump thì hắn có thể tạo TGT với user bất kỳ và gắn quyền administrator một cách bất hợp pháp.

Dưới góc độ phân tích dữ liệu log thì tấn công sử dụng Golden Tickets có sự tương quan với Pass-the-Hash. Do đó, có thể dùng phương pháp tương tự để phát hiện.

Silver Ticket

Khi đã có được NTLM hash của một service account hoặc machine account, kẻ tấn công không cần phải giao tiếp với KDC để lấy TGT hay TGS mà hắn tự tạo cho mình một TGS hợp lệ và cho phép hắn truy cập bất hợp pháp vào service/machine đó.

Ví dụ:

• Domain Controller: DC01.example.local
• File Server: FS01.example.local
• Service Account: fs01$ (tài khoản máy của File Server, có SPN: cifs/fs01.example.local)

Mô tả tấn công trong ví dụ này:

• Kẻ tấn công đã có hash hoặc key của tài khoản fs01$ (ví dụ bằng dumping credential từ server đó).
  → Có nghĩa là họ biết “chìa khóa” mà KDC dùng để ký ticket dành cho dịch vụ FS01.
• Họ tự tạo ra một TGS giả (forged TGS) cho SPN cifs/fs01.example.local, gán username giả như Administrator, ký ticket đó bằng chính hash của fs01$.
• Sau đó, họ đưa ticket này vào bộ nhớ của họ (inject vào session Kerberos).
• Khi họ truy cập \\FS01\Shared, File Server thấy ticket hợp lệ (vì được ký bằng khóa thực của fs01$), nên chấp nhận → cho truy cập dù người đó không có TGT thật, không liên hệ với Domain Controller.

Ví dụ tạo bởi ChatGPT

Cá dấu hiệu phát hiện tấn công:

• Do kẻ tấn công tự tạo TGS và gửi thẳng đến service để yêu cầu truy cập nên không có các sự kiện yêu cầu TGT đến KDC. Do đó, KDC không có Event 4768 (AS-REQ) hoặc 4769 (TGS-REQ) tương ứng, nhưng service (server) vẫn ghi nhận đăng nhập thành công (Event 4624).

• Event ID 4672 (Special Logon)

• users.csv là danh sách user có trong DC, nếu thấy event đăng nhập mà không có event tạo, rất có thể kẻ tấn công sử dụng user tuỳ ý

  index=main latest=1690545656 EventCode=4624
  | stats min(_time) as firstTime, values(ComputerName) as ComputerName, values(EventCode) as EventCode by user
  | eval last24h = 1690451977
  | where firstTime > last24h
  | convert ctime(firstTime)
  | convert ctime(last24h)
  | lookup users.csv user as user OUTPUT EventCode as Events
  | where isnull(Events)
  

Unconstrained Delegation

Unconstrained Delegation là một đặc quyền (privilege) được cấp cho User Accounts hoặc Computer Accounts trong môi trường AD, cho phép một service xác thực dưới danh nghĩa của user khác và được truy cấp tài nguyên nằm trong phạm vi quyền được truy cập của user đó.

Tại sao lại có cơ chế Unconstrained Delegation này?

Trong môi trường doanh nghiệp, có rất nhiều tình huống kiểu sau:

Người dùng → Web Server → Database Server

Ví dụ:

• Một người dùng đăng nhập vào ứng dụng web nội bộ (IIS, SharePoint...).
• Ứng dụng đó cần truy cập dữ liệu trên SQL Server thay mặt người dùng — để lấy dữ liệu tương ứng với quyền của user đó.

→ Tức là, web server cần được phép "impersonate" (giả lập) danh tính của user để truy cập tài nguyên khác trong nội bộ domain.

Khi một service (computer hoặc user account) được gán quyền “Trust this computer for delegation to any service (Kerberos only)”:

• Domain Controller (KDC) sẽ cấp cho service đó toàn quyền giữ lại và tái sử dụng ticket của người dùng.
• Cụ thể:
  1. Khi user đăng nhập vào service này, KDC đính kèm TGT của user trong ticket được gửi tới service.
  2. Service có thể lấy TGT đó, rồi tự dùng nó để yêu cầu TGS cho bất kỳ dịch vụ nào khác trong domain — thay mặt user.

=> Service có thể giả mạo user để truy cập bất kỳ tài nguyên nào mà user được phép truy cập.

Các bước tấn công:

1. Kẻ tấn công thu thập thông tin về các hệ thống có đặc quyền Unconstrained Delegation được bật cho service account
2. Khi may mắn có được quyền truy cập hệ thống đó, kẻ tấn công có thể sử dụng Mimikatz để trích xuất toàn bộ TGT trong bộ nhớ

Cách phát hiện:

• Kẻ tấn công buộc phải kiểm tra hoặc dò tìm xem hệ thống nào có Unconstrained Delegation qua LDAP

  index=ldap_logs (ldap_filter="*msDS-AllowedToDelegateTo*" OR ldap_filter="*userAccountControl:1.2.840.113556.1.4.803*")
  | stats count by src_ip, src_user, ldap_filter, _time
  | where count > 1
  

• Sau khi có được TGT, kẻ tấn công có thể tiến hành Pass-the-Hash

Constrained Delegation

Microsoft đưa ra Constrained Delegation để giới hạn phạm vi delegation:
Một service chỉ được phép impersonate user đến những dịch vụ cụ thể, được liệt kê sẵn trong thuộc tính msDS-AllowedToDelegateTo — danh sách SPNs mà service có thể thay mặt user truy cập.

Ví dụ:

• Web server cần truy cập SQL server thay mặt người dùng.
• Ta cấu hình web server được phép delegation chỉ đến SPN của SQL.
• Dù web server bị chiếm quyền, attacker không thể dùng delegation để truy cập service khác (như LDAP/DC).

Các bước tấn công:

1. Kẻ tấn công thu thập thông tin về các hệ thống có đặc quyền Constrained Delegation được bật cho service account
2. Trích xuất TGT từ bộ nhớ của hệ thống nếu may mắn chiếm được quyền truy cập vào một trong các hệ thống.
3. Sử dụng kỹ thuật S4U để giả danh (impersonate) user có đặc quyền cao đến dịch vụ khác (nằm trong danh sách SPNs của msDS-AllowedToDelegateTo)

S4U (Service-for-User) là một phần mở rộng của Kerberos (Microsoft implementation) cho phép một service lấy vé Kerberos (ticket) đại diện cho một user mà service đó không có mật khẩu. Có hai biến thể chính:

• S4U2Self

  • Mục đích: Service (ví dụ HTTP/webapp) yêu cầu KDC một service ticket tới chính nó nhưng có chủ đề (principal) là user X — nói cách khác: “Hãy cấp cho tôi một vé mà trông như user X đã trình diện cho dịch vụ này”.
  • Kịch bản dùng: web app muốn bắt đầu một workflow as-if-user mà không có TGT/TGS của user. Thường là bước đầu để service có một ticket mang danh tính user.
  • Ai gửi yêu cầu: chính service account (ví dụ WEBAPP$) gửi request S4U2Self đến KDC.
  • KDC trả về: một service ticket cho WEBAPP nhưng có identity = user X (được gọi “S4U2Self ticket”).

• S4U2Proxy

  • Mục đích: Sau khi đã có S4U2Self (hoặc với TGT), service muốn request TGS tới một service đích (proxy) thay mặt user X.
  • Ràng buộc: KDC sẽ chỉ cấp nếu service được phép delegate đến SPN đích (msDS-AllowedToDelegateTo or resource-based delegation).
  • Ai gửi yêu cầu: service account gửi request S4U2Proxy cho KDC để lấy TGS tới target SPN as user X.
  • Kết quả: service có thể truy cập service đích với tư cách user X.

Tóm lại: S4U2Self lấy “vé cho chính service nhưng mang identity user”; S4U2Proxy đổi vé đó thành vé tới service đích — giải quyết vấn đề “double hop“.

Cách phát hiện với Splunk:

• Phát hiện ở bước thu thập thông tin với log LDAP:

  index=wineventlog (EventCode=4662 OR EventCode=5136 OR EventCode=4738 OR EventCode=4742)
  | search Message="msDS-AllowedToDelegateTo" OR Message="AllowedToDelegateTo"
  | table _time, ComputerName, SubjectUserName, ObjectName, Message
  

• Tìm thay đổi msDS-AllowedToDelegateTo

  index=wineventlog (EventCode=4662 OR EventCode=5136 OR EventCode=4738 OR EventCode=4742)
  | search Message="msDS-AllowedToDelegateTo" OR Message="AllowedToDelegateTo"
  | table _time, ComputerName, SubjectUserName, ObjectName, Message
  

DCSync

DCSync là kỹ thuật cho phép kẻ tấn công trích xuất toàn bộ hash password (bao gồm cả KRBTGT và Administrators) từ Domain Controllers. Điều kiện để có thể thực hiện kỹ thuật này là phải có được user account/computer account có quyền Replication Directory Changes. Các user account nằm trong nhóm Administrators, Domain Admins, và Enterprise Admin hoặc computer account của máy có vai trò domain controllers đều mặc định có quyền này.

Các bước tấn công:

1. Kẻ tấn công tiến hành mọi cách để leo thang đặc quyền, chiếm được các account có khả năng thực hiện DCSync

2. Sử dụng các công cụ như Mimikatz, kẻ tấn công sẽ yêu cầu dữ liệu sao chép domain bằng interface DRSGetNCChanges, về cơ bản là giả mạo yêu cầu hợp pháp của domain controller.

3. Sau khi có được hash password của mọi user, để khai thác hoàn toàn môi trường, một số tấn công có thể được áp dụng như Golden/Silver Tickets, Pass-the-Hash/Overpass-the-Hash.

Cách phát hiện với Splunk:

• Dựa vào Event ID 4662

  index=main earliest=1690544278 latest=1690544280 EventCode=4662 Message="*Replicating Directory Changes*"
  | rex field=Message "(?P<property>Replicating Directory Changes.*)"
  | table _time, user, object_file_name, Object_Server, property
  

DCShadow

Kẻ tấn công đăng ký DC giả và đẩy thay đổi vào AD này bằng con đường replication. Dấu hiệu nổi bật: tạo server / nTDSDSA objects trong Configuration partition + các thay đổi AD xuất hiện như replication-originated (không theo thao tác CRUD trên quản trị). DCShadow có thể tránh một số audit vì thay đổi đến AD qua replication channel.

Các bước tấn công:

1. Kẻ tấn công cần tài khoản có đặc quyền cao (Domain Admin / local admin trên DC / quyền write vào Configuration partition) hoặc có thể gán quyền replication.

2. Tạo object server và nTDSDSA trong Configuration partition, có thể tạo/ghi computer account; thực hiện thay đổi AD (ví dụ: thêm user vào Domain Admins).

3. Domain controller giả khởi tạo replication với các domain controller hợp pháp, lan truyền các thay đổi đó khắp domain.

Cách phát hiện:

• Event 5137 (object created) và 5136 (object modified) liên quan tới Configuration partition: DN chứa CN=Sites,CN=Configuration hoặc objectClass nTDSDSA, server.

• Event 4662 với Accesses: Replicating Directory Changes / Replicating Directory Changes All từ account không phải DC — chỉ ra DCSync/DC-like activity.

• Event 4728/4729/4732/4733: thay đổi membership nhóm (Domain Admins) — đặc biệt nếu không có change ticket.

• Tạo computer object trong OU=Domain Controllers hoặc sửa object có tên lạ hoặc Event ID 4742 (Computer account was changed)

• DNS: bản ghi SRV _ldap._tcp.dc._msdcs.<domain> mới.

index=main EventCode=4742 
| rex field=Message "(?P<gcspn>XX\/[a-zA-Z0-9\.\-\/]+)" 
| table _time, ComputerName, Security_ID, Account_Name, user, gcspn 
| search gcspn=*

Khi một Domain Controller được bật hoặc tắt chức năng Global Catalog, hoặc SPN GC/<DCName> được cập nhật → sinh event 4742. Vì vậy, filter EventCode=4742 giúp tìm các thay đổi trên tài khoản máy tính Domain Controller — đặc biệt hữu ích khi muốn phát hiện:

• Thêm / xoá SPN (bao gồm GCSPN),
• Thay đổi quyền / flag replication,
• Dấu hiệu attacker đăng ký DC giả (rogue DC) hoặc bật Global Catalog trái phép.

Global Catalog là một dịch vụ đặc biệt chạy trên Domain Controller (DC), nó giữ bản sao một phần (partial replica) của mọi object trong forest.

• Một DC thông thường chỉ lưu dữ liệu của domain mà nó thuộc về.

• GC thì ngoài domain chính, nó lưu thêm các thuộc tính quan trọng (một tập con) của mọi object trong các domain khác trong forest.

Vì Global Catalog là một dịch vụ LDAP đặc biệt, chạy song song với dịch vụ LDAP thông thường trên DC, nên nó cũng cần SPN riêng để Kerberos có thể cấp vé (TGS ticket) cho client muốn truy cập dịch vụ GC.

• Dịch vụ LDAP trên DC có SPN: LDAP/dc01.corp.local LDAP/dc01

• Dịch vụ Global Catalog thêm SPN riêng: GC/dc01.corp.local GC/dc01

index="cobaltstrike_beacon" sourcetype="bro:http:json" 
| sort 0 _time
| streamstats current=f last(_time) as prevtime by src, dest, dest_port
| eval timedelta = _time - prevtime
| eventstats avg(timedelta) as avg, count as total by src, dest, dest_port
| eval upper=avg*1.1
| eval lower=avg*0.9
| where timedelta > lower AND timedelta < upper
| stats count, values(avg) as TimeInterval by src, dest, dest_port, total
| eval prcnt = (count/total)*100
| where prcnt > 90 AND total > 10