SOC Research

[Admin]

DNS Records Functionality and Abuses: PTR & NS Explained

Understanding how PTR (Pointer Records) and NS (Name Server Records) work is essential in threat hunting and detecting DNS-based attacks. Below, we cover their normal functions and how they are abused by attackers.

🔹 PTR Records (Pointer Records)

Normal Functionality:
PTR records perform reverse DNS lookups—translating IP addresses back to hostnames. Key use cases:
• Email Validation: Mail servers verify if the IP matches the hostname to reduce spam.
• Log Readability: Converts IPs to hostnames for easier interpretation.
• Security Policies: Used in access control for validating trusted sources.

Abuse via PTR Query Spikes:
1. DNS Reflection/Amplification Attacks:
• Attackers send spoofed PTR queries to open DNS resolvers, causing large responses to flood the victim’s IP.
• These are used to amplify DDoS attacks.

Indicators:
• Sudden increase in inbound UDP port 53 traffic.
• No matching outbound queries.
• Traffic contains large PTR responses.

2. Reconnaissance/Scanning:
• Mass reverse lookups to identify hostnames in a target network—often a precursor to targeted attacks.

---

🔹 NS Records (Name Server Records)

Normal Functionality:
NS records define authoritative DNS servers for a domain. They direct where to look for a domain’s A, MX, TXT records, etc.

Abuse via NS Query Spikes:
1. DNS Amplification Attacks:
• Similar to PTR attacks—spoofed queries generate large NS responses.

2. DNS Hijacking:
• If attackers change a domain's NS records, they can:
- Redirect traffic to phishing sites
- Intercept emails
- Issue fake SSL certs

Indicators:
• Sudden NS record changes
• High queries to attacker-controlled NS servers

3. Reconnaissance:
• Spike in NS queries from unknown IPs = attacker mapping DNS infrastructure.

4. Dangling Domains:
• Spikes in queries to expired or unregistered domains = attackers preparing for subdomain takeover.

---

🔍 SOC Investigation: Detecting PTR and NS Abuse

A Security Operations Center (SOC) can detect abuse through:

• Baseline Monitoring: Know your usual DNS traffic volume.
• DNS Log Analysis:
- Look for sharp increases in PTR/NS queries.
- Unsolicited inbound DNS responses.
• ANY Query Spikes: Sign of amplification attack.
• NetFlow/IPFIX: Identify high UDP port 53 traffic bursts.
• Firewall/IDS Logs: Alerts on excessive or unusual DNS activity.
• Threat Intelligence: Match suspicious IPs to known botnets or attackers.
• Packet Captures (PCAP): Confirm suspicious DNS behavior if data volume allows.
• External DNS Monitoring: Detect unauthorized NS record changes.

---

Conclusion:
Spikes in PTR and NS queries are often signs of DNS-based DDoS or reconnaissance attacks. Monitoring DNS behavior is critical in threat hunting, and your SOC should be equipped to identify and respond to these anomalies quickly.


Stay vigilant — DNS is powerful, but it's also a common attack surface.

[Admin]

Windows - Event Code 104 ( Log Cleared )
-----------

• Definition: Event ID 104, generated by the Microsoft-Windows-Eventlog source, indicates that a Windows event log file has been cleared. This event is typically found in the System event log.
• Usage: This event is logged whenever an event log (such as the System, Application, or Setup log) is cleared. Legitimate reasons for this might include:
  • System administrators performing routine log maintenance or archiving.
  • Automated scripts designed to manage log file sizes.
• Detection: While clearing event logs can be a legitimate administrative task, it is also a common tactic used by adversaries (often referred to as "Indicator Removal" or "Defense Evasion" in the MITRE ATT&CK framework, specifically T1070.001) to hide their malicious activity and destroy forensic evidence.
  
  How to use for detection:
  1. Unexpected Occurrence: The most significant indicator is when Event ID 104 occurs unexpectedly.
     • Baseline your environment: Understand when and why event logs are typically cleared in your environment (e.g., during scheduled maintenance windows, by specific administrative accounts). Any deviations from this baseline should be investigated.
     • Context is key: If a server's logs are cleared outside of a maintenance window, or if a user account that shouldn't have the privileges to clear logs generates this event, it's highly suspicious.
  2. Correlation with other suspicious events: Event ID 104, when seen in isolation, might not be immediately indicative of malicious activity. However, when correlated with other events, it becomes a strong indicator of compromise:
     • Preceding suspicious activity: Look for any anomalous events before the log was cleared. This could include:
       • Failed login attempts (Event ID 4625).
       • Unusual process creations (Sysmon Event ID 1).
       • New services created (Event ID 4697 or 7045).
       • Scheduled tasks created (Event ID 4698).
       • Network connections to known malicious IPs.
     • Lack of preceding events: If an event log is cleared, and there's a suspicious lack of other log data leading up to it, it might suggest an attacker successfully removed other traces.
     • Correlation with Security Log clearing: While Event ID 104 is for the System log, be aware that clearing the Security log specifically generates Event ID 1102. Attackers often clear both.
  3. Frequency and Pattern:
     • Multiple log clearings in a short period on different systems could indicate a widespread attack.
     • Clearing logs immediately after an intrusion or data exfiltration attempt.
  4. Who cleared the log? While Event ID 104 itself might not always explicitly state the user or process that cleared the log, you should look for other events around the same time that might provide this context. Tools like wevtutil or PowerShell commands are commonly used to clear logs. Monitoring for the execution of these commands (e.g., via Sysmon Event ID 1 for process creation) can provide additional context.
  
  Example Detection Logic (SIEM Query Pseudocode):
  (EventID = 104 AND Channel = "System")
  OR
  (EventID = 1102 AND Channel = "Security")
  | WHERE time_difference(now(), _time) < 1 hour
  | GROUP BY ComputerName
  | COUNT
  | ALERT if Count > X (where X is a threshold based on your baseline)
  OR
  (EventID = 104 AND Channel = "System" AND NOT SourceProcessName IN ("C:\\Windows\\System32\\wevtutil.exe", "powershell.exe") AND NOT UserName IN ("Authorized_Admin_Accounts"))
  OR
  (EventID = 104 AND Channel = "System" AND _time NOT BETWEEN 'Scheduled_Maintenance_Start' AND 'Scheduled_Maintenance_End')
  
  
  Important Note: Centralized log collection (SIEM) is crucial for effective detection of log clearing, as attackers often aim to clear logs directly on the compromised host, making local investigation difficult or impossible.