Troubleshooting Scenario Questions

Only the user's browser cache

Why it fails: Browser cache is local to one device and holds no authentication records from the Singapore session, so it cannot establish or refute the impossible-travel detection. It is tempting because the user's own workstation seems relevant, but cache inspection suits malware or web-activity investigations, not correlating sign-ins across two geographic locations.

Only DHCP logs from the London office

Why it fails: DHCP logs from London alone cannot confirm whether the Singapore authentication came from the same device or a separate host, so they cannot refute or support the impossible-travel detection. DHCP logs are useful for mapping an internal IP to a MAC address during endpoint investigations, but the Singapore session requires its own source records.

The organisation's public DNS zone file

Why it fails: A public DNS zone file lists domain name records and reveals nothing about user authentication locations or mailbox forwarding rules, so it cannot corroborate the UEBA alert. Zone files are consulted during DNS or domain-hijacking investigations, not identity-based detections, making this irrelevant to the impossible-travel and forwarding-rule evidence.

Disable all application authentication

Why it fails: Disabling authentication fundamentally alters the application's security architecture, making the scan results unrepresentative of the actual production environment's vulnerabilities. This approach would test a completely different system configuration, rendering any findings irrelevant to the real-world security posture. Furthermore, removing authentication introduces significant security risks to the testing environment itself, potentially exposing sensitive data or functionality during the scan.

Treat absence of findings as proof of security

Why it fails: Assuming an application is secure simply because a DAST scan found no vulnerabilities on unreached, authenticated pages is a critical logical fallacy. The DAST tool cannot report findings on functionality it never accessed, creating a false sense of security regarding the application's true attack surface. This approach ignores the significant risk posed by untested, protected areas where many critical vulnerabilities often reside, providing an incomplete and misleading security assessment.

Reduce the scan to only the landing page

Why it fails: Reducing the DAST scan scope to only the landing page directly contradicts the objective of testing authenticated functionality. This action would severely limit the attack surface coverage, deliberately excluding the very protected areas that need to be assessed for vulnerabilities. Consequently, critical business logic and sensitive data handling behind login screens would remain untested, leaving significant security gaps unaddressed and providing an incomplete security posture.

Disable the unnecessary services manually

Why it fails: Manually disabling unnecessary services is a highly inefficient and error-prone approach, especially in environments with numerous systems. This method lacks scalability, as administrators might inadvertently miss services, incorrectly disable critical components, or fail to apply changes uniformly across all affected machines. Furthermore, manual configurations are susceptible to being overwritten by system updates or human error, leading to configuration drift and the re-emergence of vulnerabilities without a systematic, automated enforcement mechanism.

Increase the frequency of vulnerability scans

Why it fails: Increasing the frequency of vulnerability scans is a detection-focused activity that identifies symptoms (open ports) but does not provide a solution to the underlying configuration problem. While more frequent scans might highlight issues sooner, they do not prevent services from starting unnecessarily or automatically remediate misconfigurations. This approach would primarily result in an increased volume of alerts without addressing the root cause, potentially leading to alert fatigue rather than an improved security posture.

Install a host-based firewall to block the ports

Why it fails: Installing a host-based firewall to block ports is a reactive mitigation strategy rather than a comprehensive solution for managing service configurations. While firewalls add a layer of defense by restricting network access, they do not address why unnecessary services are running and listening on those ports internally. Firewalls can be misconfigured, bypassed by local processes, or even disabled, creating a false sense of security. A firewall prevents external access but doesn't enforce a secure internal baseline for service operation.

Brute-force attack.

Why it fails: A traditional brute-force attack involves systematically trying numerous password combinations against a *single* user account until the correct one is found. This method typically generates a high volume of failed login attempts for that specific account within a short timeframe, which would quickly trigger account lockout policies and alert security systems. Therefore, it does not align with a scenario where an attacker attempts a few common passwords across *many* different accounts to avoid detection.

Kerberoasting.

Why it fails: Kerberoasting is an attack technique used to obtain service account hashes from Active Directory. An attacker requests a Kerberos Ticket Granting Service (TGS) ticket for a service principal name (SPN) associated with a service account. The domain controller encrypts this TGS ticket using the service account's NTLM hash, which the attacker can then extract and attempt to crack offline. This process does not involve direct login attempts against user accounts and thus would not manifest as failed login attempts in a SIEM.

Pass-the-hash.

Why it fails: Pass-the-hash (PtH) is a post-exploitation technique where an attacker authenticates to a remote system or service using a captured NTLM hash of a user's password, rather than the plaintext password itself. Since the hash is directly used for authentication, the system processes it as a valid credential, bypassing the need for a password and thus generating successful authentication events, not failed login attempts. This method exploits weaknesses in how Windows handles authentication tokens and cached credentials.

Disable the user's account immediately

Why it fails: Immediately disabling the user's account is a containment action that presumes the alert represents a confirmed compromise, but CASB alerts are often triggered by benign anomalies such as a legitimate user traveling, a VPN egress, or an IP geolocation mismatch. Taking this irreversible step without first reviewing the user's authentication and audit logs can lock out a productive employee or contractor and generate unnecessary helpdesk escalations. Moreover, if the alert is a false positive, the account disablement itself becomes a mini-incident that distracts from real threats; investigation must precede containment.

Reset the user's password without further analysis

Why it fails: Resetting a password without first analyzing the alert assumes the credential itself was stolen, but the CASB alert may stem from an unauthorized third-party application using OAuth tokens, a compromised device registered with the account, or a policy violation unrelated to password theft. A password reset does not invalidate existing OAuth grants, session cookies, or API tokens, so it often fails to remediate the actual access path the alert detected. Additionally, if data was already exfiltrated, a password change does nothing to recover or assess the exposure—confirming compromise through log analysis should always come first.

Block all access to the cloud application from that location

Why it fails: Blocking all access from the alert's geographic location is an aggressive and overly broad response that can affect many legitimate users who share that region or egress IP, such as remote employees connecting through the same ISP or a branch office. Attackers routinely route traffic through proxies, cloud IP ranges, or botnets in other regions, so a location-based block may not prevent further malicious access and can be easily bypassed. The CASB alert is only a trigger to investigate the specific user and session, not to impose network-level quarantine, which should be reserved for confirmed, ongoing malicious activity after evidence has been gathered.

netstat

Why it fails: netstat (network statistics) is a command-line tool used to display active network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. While it is invaluable for identifying open ports, listening sockets, and established connections on a host, it lacks the capability to capture, inspect, or log individual raw network packets.

iperf

Why it fails: iperf is a standardized network testing tool used to measure maximum achievable bandwidth on IP networks. It works by generating active traffic streams (TCP, UDP, or SCTP) between a client and a server to test throughput, loss, and jitter. Because it is designed solely for performance benchmarking and active traffic generation, it cannot intercept or record ambient network traffic.

nmap

Why it fails: nmap (Network Mapper) is an open-source utility designed for network discovery, port scanning, and vulnerability assessment. It operates by sending custom-crafted packets to target hosts and analyzing the responses to determine active hosts, open ports, and operating system versions. It is an active scanning tool rather than a passive packet capture utility, making it unsuitable for monitoring or recording ongoing network traffic.

Cross-site scripting (XSS)

Why it fails: While Cross-Site Scripting (XSS) is technically a sub-type of injection, it specifically targets the client-side browser by executing malicious scripts in the user's session. It does not involve sending malicious commands directly to a backend interpreter or database engine, which is the hallmark of classic injection vulnerabilities like SQLi or command injection.

Security misconfiguration

Why it fails: Security misconfigurations arise from improperly secured default settings, unpatched vulnerabilities, open directories, or verbose error messages rather than flawed input handling. While a DAST scanner will flag these infrastructure-level weaknesses, they are distinct from application-layer code flaws that fail to sanitize user-supplied input before processing.

Broken access control

Why it fails: Broken access control occurs when an application fails to properly enforce authorization boundaries, allowing users to access resources or perform actions outside their intended privileges. This is a logical flaw in privilege management, such as IDOR or directory traversal, rather than a failure to sanitize input passed to a backend interpreter.

Endpoint detection and response (EDR) logs

Why it fails: Endpoint detection and response (EDR) logs are designed to monitor host-level activities, such as process creation, registry modifications, memory injections, and file system changes. While they are invaluable for identifying post-exploitation behavior and malware execution, they do not natively track centralized authentication events or directory service login attempts. Therefore, they are not the primary source for auditing user authentication success or failure across the network.

Firewall logs

Why it fails: Firewall logs record network-layer and transport-layer connection details, such as source and destination IP addresses, port numbers, and protocol types, along with action states like permit or deny. They lack the application-layer visibility required to parse and log the specific success or failure outcomes of user authentication handshakes. Consequently, they cannot verify whether a login attempt succeeded or failed.

DNS logs

Why it fails: Domain Name System (DNS) logs capture queries and responses mapping hostnames to IP addresses, which helps identify command-and-control (C2) traffic or domain generation algorithms. They do not contain any user credential data, session negotiation details, or authentication status information. As a result, DNS logs are entirely unsuitable for auditing user login attempts or verifying authentication outcomes.

Metasploit

Why it fails: Metasploit is a penetration testing and exploitation framework used to discover, exploit, and validate vulnerabilities on target systems. While it can deliver payloads and establish remote sessions, it lacks the native capability to capture, decode, and analyze raw network packets flowing across an interface.

Nmap

Why it fails: Nmap is an active reconnaissance tool designed for host discovery, port scanning, and service version detection. Although it generates network traffic to probe targets and analyze their responses, it is not designed to act as a passive sniffer or capture arbitrary network packets for offline analysis.

Nikto

Why it fails: Nikto is an open-source web server scanner that performs rapid testing against web servers to identify dangerous files, outdated software, and specific configuration vulnerabilities. It operates at the application layer to audit HTTP/HTTPS services and does not possess packet-sniffing capabilities to capture raw network traffic.

Endpoint Detection and Response (EDR)

Why it fails: Endpoint Detection and Response (EDR) solutions primarily focus on endpoint activities, including process execution, file system changes, and network connection metadata. While EDR can log DNS requests made by processes, it typically captures only the query and response codes, not the full DNS payload content necessary to identify sophisticated data exfiltration techniques like DNS tunneling. Analyzing the actual data within the DNS query or response fields for anomalous patterns is beyond its standard scope.

Antivirus logs

Why it fails: Antivirus logs are designed to record events related to malware detection, quarantine, and removal, as well as file system scans. They focus on identifying known malicious signatures or behavioral anomalies at the file and process level. Antivirus software does not typically monitor or log network traffic, especially not the granular details of DNS queries and responses, making it ineffective for detecting DNS tunneling.

NetFlow

Why it fails: NetFlow, or similar flow data protocols like IPFIX, provides aggregated network session metadata such as source/destination IP addresses, ports, protocols, and byte/packet counts. While it can indicate that DNS traffic occurred between specific hosts, it explicitly does not capture the actual content of the DNS queries or responses. Therefore, NetFlow cannot reveal the encoded data within DNS requests or responses indicative of tunneling.