Scenario practice questions

It cracks the SAM database file offline

Why it fails: This command operates on memory, not the SAM database file. The SAM database is stored on disk and is only accessible with system privileges. The command specifically targets the LSASS process memory to retrieve credentials currently held by the Windows authentication subsystem.

It resets the local Administrator password

Why it fails: This command does not modify credentials; it only reads them. Resetting the Administrator password requires different commands (e.g., 'token::elevate' followed by password change utilities). Its primary utility is credential harvesting, not credential modification or administrative password resets.

It clears the event logs to hide the attack

Why it fails: Clearing logs is done using commands like 'event::clear'. Extracting credentials from memory is purely a harvesting operation. While attackers may clear logs afterwards, 'sekurlsa::logonpasswords' has no inherent log-clearing functionality; its purpose is solely to steal identity information.

Broken Function Level Authorization

Why it fails: Broken function level authorisation concerns access to privileged operations or endpoints, such as reaching an admin-only action. This attacker stayed within the same users endpoint and altered the object identifier, so the flaw is object-level access control, not function-level. Function-level checks would matter if the path itself changed to an admin route.

Cross-Site Request Forgery

Why it fails: CSRF tricks a victim's authenticated browser into issuing unintended state-changing requests, relying on ambient session credentials. Here the attacker sent their own authenticated requests and simply changed an object identifier, which is an object-level authorisation failure, not request forgery. CSRF would fit a forged transfer or password change.

Server-Side Request Forgery

Why it fails: This flaw allows an attacker to induce the backend server to make HTTP requests to an arbitrary unintended external or internal destination, which is unrelated to modifying sequential user resource identifiers in an API path.

Broken Authentication

Why it fails: Broken authentication involves issues with session management or credential validation mechanisms. While the attacker accesses data, the failure is specifically related to object-level authorization rather than the mechanism used to verify the identity of the user requesting the resource initially.

Cross-Site Scripting

Why it fails: Cross-Site Scripting involves injecting malicious scripts into web pages viewed by other users. The scenario describes data access manipulation rather than the injection of client-side code execution. IDOR focuses on the backend resource access control logic rather than the presentation layer execution.

Insufficient Logging and Monitoring

Why it fails: Insufficient logging refers to the inability of the system to record and alert on suspicious activities. While logging might be lacking, the primary vulnerability that allowed the data access is the lack of authorization checks on the object reference itself, not the logging policy.

A standard user is accessing their home directory.

Why it fails: Accessing a home directory would involve connecting to a user-specific share, not the IPC$ share. The IPC$ share is for system-level communication and administrative tasks. Connecting to it is abnormal for standard user operations and is a clear indicator of system-level interaction that warrants further investigation by security teams.

The workstation is simply performing routine backups.

Why it fails: Backups typically target specific data shares, not the IPC$ system share. While some backup agents might interact with system shares, the pattern of 'Tree Connect' requests suggests an active, manual exploration or malicious scripted interaction rather than the expected behavior of a managed, automated enterprise backup solution.

The SMB server is correctly enforcing message signing.

Why it fails: Message signing is a cryptographic configuration, not a behavioral pattern of connecting to shares. Connecting to IPC$ has no relation to whether the traffic is signed or encrypted. It is a sign of activity level, not protocol security configuration, and must be analyzed separately to assess the risk of the connection.

It makes passwords faster to type for users

Why it fails: MFA typically makes the login process slower, not faster. It adds a step for the user, which is a known usability trade-off. The justification for MFA is security, not efficiency; users often view it as an inconvenience, but it is necessary to protect accounts against credential theft.

It eliminates the need for complex passwords

Why it fails: Even with MFA, strong, unique passwords are still necessary. If an attacker gains access to both the password and the MFA token (via session hijacking or social engineering), they can bypass both. MFA is an additional layer of security, not a replacement for strong password hygiene and policy.

It ensures that the password never expires

Why it fails: MFA does not change the rules regarding password expiration. While it reduces the pressure to rotate passwords frequently, the two are independent concepts. An organization can still require password changes even when MFA is implemented, as they serve different purposes in the overall security strategy.

Terminate the compromised EC2 instance immediately to destroy any running malicious processes and volatile memory artifacts.

Why it fails: Terminating the instance prevents further exploitation but fails to address active temporary security credentials already stolen by the attacker, leaving AWS resources vulnerable to ongoing unauthorized API calls from external IP addresses. Cyber defenders must explicitly invalidate session tokens.

Attach a restrictive Network ACL to the subnet to block all inbound and outbound traffic originating from the compromised instance's private IP address.

Why it fails: Blocking network traffic prevents the attacker from issuing further API calls from inside the instance, but it does not protect against exfiltrated STS credentials that can be utilized from any external location globally via the AWS public API endpoints.

Modify the VPC route table to remove the internet gateway route, isolating the entire virtual private cloud from external communication.

Why it fails: Isolating the entire VPC disrupts business operations for all other workloads running within that network segment. Incident response procedures demand surgical containment steps rather than broad network outages that impact unaffected production systems.

A user struggling to remember their password.

Why it fails: While a user might fail a login, the subsequent execution of reconnaissance commands like 'whoami' and 'net user' is not typical user behavior. These commands are diagnostic tools used by attackers to map the environment after gaining access. Ignoring this activity would result in missing an active security breach.

A network administrator performing routine maintenance.

Why it fails: Administrative maintenance does not typically involve repeated failed logins followed by 'whoami' checks. Even if an administrator forgot a password, they would not need to run enumeration commands immediately upon login. This behavior deviates significantly from standard administrative workflows and should be treated as a high-priority security incident.

An automated script updating software versions.

Why it fails: Software update scripts are pre-configured and do not usually fail logins due to incorrect passwords. Furthermore, they perform specific tasks rather than running reconnaissance commands like 'net user'. This scenario does not align with the behavior of legitimate administrative automation tools and strongly points to malicious activity.

Server-Side Template Injection via malicious expressions evaluated by template engines

Why it fails: Server-Side Template Injection occurs when user input is embedded unsafely into template engines like Jinja2 or Twig. This differs fundamentally from XML parsing flaws, as template injection evaluates server-side code constructs directly within view rendering logic.

Cross-Site Scripting via injected script tags within CDATA sections

Why it fails: While XML documents can contain CDATA sections holding script content, rendering them improperly in a web browser leads to Cross-Site Scripting. Server-side command execution requires flaws in server processing logic rather than client-side script rendering issues.

LDAP injection through improper attribute filtering in directory search queries

Why it fails: LDAP injection targets directory search filters, not XML parsers, so it cannot explain external entity resolution or command execution here. It is tempting because both involve unsanitised input reaching an interpreter, but LDAP injection would be correct against a directory service querying attributes, not an XML parser.

Credential dumping using LSASS memory access

Why it fails: Credential dumping targets LSASS to extract password hashes or tickets, often using tools like Mimikatz. It does not involve creating scheduled tasks or periodic downloads. The observed behavior is a recurring task, not memory access to LSASS, so credential dumping is not the technique here.

Privilege escalation via unquoted service path

Why it fails: Unquoted service path exploitation involves placing a malicious executable in a directory whose path contains spaces, causing the service to execute it. The scenario describes a scheduled task, not a service with an unquoted path. No service creation or path manipulation is mentioned, so this technique does not apply.

Lateral movement using PsExec

Why it fails: PsExec copies a service binary to a remote host and starts a service to execute commands, generating service creation events and SMB traffic. The scenario describes a local scheduled task on a single workstation, not remote service execution. Thus PsExec lateral movement is not indicated.

The attacker compromises a legitimate website and uses it to host malicious payloads.

Why it fails: This describes a watering hole or compromised website attack, not domain fronting. Domain fronting does not require compromising the front domain; it leverages the domain's infrastructure, such as a CDN, to relay traffic. The attacker does not need to control the front domain's content. Therefore, this option is incorrect.

The attacker uses a fast-flux network to rapidly change DNS records and evade detection.

Why it fails: Fast-flux involves rapidly changing DNS A records to multiple compromised hosts, often used for resilience. Domain fronting, in contrast, uses a stable front domain and manipulates the Host header. The random subdomains in the scenario might suggest fast-flux, but the key indicator is the mismatch between the front domain and the actual C2, which is domain fronting.

The attacker uses DNS tunneling to exfiltrate data through the DNS queries.

Why it fails: DNS tunneling involves encoding data in DNS queries and responses, often using TXT records. In domain fronting, the DNS queries themselves are not used to carry data; they simply resolve the front domain. The actual malicious traffic is in the HTTPS connection to the same IP but with a different Host header. Therefore, this option mischaracterizes the technique.

The workstation's SMB client is misconfigured to use only SMB 2.0.2 due to a missing registry key.

Why it fails: A misconfiguration would typically cause consistent behavior, but the scenario states the workstation normally uses SMB 3.1.1. The sudden change to 2.0.2 and NTLMSSP suggests external manipulation, not a static configuration issue. Additionally, a registry misconfiguration would not explain the NTLMSSP Type 3 message if Kerberos was previously used successfully.

The file server is configured to only accept SMB 2.0.2 connections, forcing the client to downgrade.

Why it fails: If the server only supported SMB 2.0.2, the client would consistently negotiate that dialect. However, the scenario implies the server normally supports SMB 3.1.1, and the sudden appearance of NTLMSSP instead of Kerberos suggests an active interception, not a static server limitation. A server-side restriction would not typically alter the authentication mechanism from Kerberos to NTLM.

The capture shows normal fallback behavior because the client and server could not agree on SMB 3.1.1 encryption.

Why it fails: SMB 3.1.1 negotiation failure would not automatically force NTLMSSP authentication; the client would still attempt Kerberos if available. Moreover, fallback due to encryption mismatch would typically be logged and might not result in a successful session with NTLMSSP. The presence of only SMB 2.0.2 and NTLMSSP strongly indicates malicious downgrade rather than benign fallback.

The identity provider is not configured to send the correct user attributes.

Why it fails: If the IdP is not sending correct attributes, users might fail to authenticate via SSO, but they would not be able to use old credentials unless local authentication is still enabled. The scenario states users can access with old credentials, indicating that local auth is active. Incorrect attributes would cause SSO logins to fail, not allow bypass. Therefore, this is not the most likely cause.

The SAML assertion is not properly signed, allowing users to forge authentication.

Why it fails: If SAML assertions were not properly signed, it would be a serious vulnerability allowing attackers to impersonate users. However, the scenario describes users accessing with old credentials, not forging SAML assertions. This suggests that the service's native authentication is still active. While SAML signing is important, it is not the cause of users bypassing SSO with their old credentials.

The users have cached credentials in their browsers that bypass SSO.

Why it fails: Browser cached credentials might allow users to log in directly to the service if the service still supports local authentication. However, the root cause is more likely that the service's local authentication is still enabled. Cached credentials are a symptom, not the cause. The analyst should check the service's authentication settings to ensure that local authentication is disabled and only SSO is allowed.

The attacker cannot recover any passwords because the presence of a salt in the hash makes brute-force attacks mathematically infeasible regardless of password strength.

Why it fails: This is false. Salts do not make brute-force attacks infeasible; they only prevent the reuse of precomputed tables and force the attacker to crack each hash individually. Weak passwords remain vulnerable to dictionary and brute-force attacks even with salting. The security of the hash depends primarily on the password's entropy and the computational cost of the KDF, not on the salt alone.

The attacker can decrypt the hashes using the publicly available SHA-512 algorithm because the algorithm is reversible when the salt is known.

Why it fails: This is incorrect. Cryptographic hash functions are one-way by design; they are not encryption algorithms and cannot be decrypted, even when the salt is known. The salt only prevents precomputed rainbow table attacks and ensures identical passwords produce different hashes. Knowing the salt does not provide any shortcut to recovering the original password beyond enabling a fresh cracking attempt.

The attacker can immediately use the hashes to authenticate to other systems via pass-the-hash because SHA-512 crypt hashes are accepted as credentials by SSH and other services.

Why it fails: This is false. Pass-the-hash attacks rely on protocols that accept the hash itself as an authentication token, such as NTLM in Windows environments. SHA-512 crypt hashes in /etc/shadow are not transmitted over the network during SSH authentication; instead, the password is verified locally by the server. An attacker cannot replay these hashes to authenticate to remote systems without first cracking them to plaintext.

Require the operator to manually approve each drafted pretext before it is used in the engagement.

Why it fails: Human review is a valuable compensating control but it is a detection step, not a fix. The assistant would still be generating content shaped by the injected instruction, and a reviewer focused on prose quality could easily miss an altered recipient field. It leaves the underlying prompt-injection vector intact and relies on operator vigilance rather than design.

Lower the model's temperature setting to zero so that outputs become deterministic across repeated runs.

Why it fails: Temperature controls sampling randomness, not instruction authority. A deterministic model will still reliably obey the injected instruction every single time, which arguably makes the problem more consistent rather than less. It does nothing to distinguish the target's legitimate page content from embedded adversarial directives, so it fails to address the root cause in this engagement.

Increase the context window so the assistant can ingest the entire target website rather than individual pages.

Why it fails: Expanding the context window enlarges the attack surface by admitting more untrusted content into a single prompt. The injected text would simply arrive alongside more material the model must weigh. Nothing about a larger window establishes that scraped pages are data rather than commands, so this change likely worsens the observed behavior instead of correcting it.

Ping scan (-sn)

Why it fails: The -sn scan is used for host discovery only; it does not scan ports or IP protocols. It sends a few probes to determine if a host is up but does not enumerate supported IP protocols. Therefore, it cannot fulfill the requirement of identifying which IP protocols the target supports.

TCP SYN scan (-sS)

Why it fails: The -sS scan is used to identify open TCP ports by sending SYN packets and analyzing responses. It does not probe IP protocols other than TCP, so it cannot determine which other IP protocols the target supports. This scan is limited to TCP port discovery.

UDP scan (-sU)

Why it fails: The -sU scan probes UDP ports to identify open UDP services. While UDP is an IP protocol, this scan only tests UDP, not other protocols like ICMP or IGMP. It does not provide a comprehensive view of supported IP protocols, so it is not the correct choice.

Cross-Site Request Forgery

Why it fails: Cross-Site Request Forgery involves forcing an authenticated user to execute unwanted actions on a web application in which they are currently authenticated. It relies on ambient authority of browser cookies and does not involve manipulating file path references to access server-side system files directly.

SQL Injection

Why it fails: SQL Injection involves the injection of malicious SQL queries into input fields to manipulate database execution. It targets the interaction between the application and the database engine rather than the file system traversal mechanisms used to access local files through insecure URL references or file parameters.

Server-Side Request Forgery

Why it fails: Server-Side Request Forgery involves inducing the server to make requests to unintended locations, such as internal services or external networks. While it involves manipulating input references, the target is typically network-accessible services rather than local file system objects located on the disk of the web server.

Cross-Site Request Forgery

Why it fails: Cross-Site Request Forgery forces authenticated users to execute unintended state-changing actions under their current session. The described scenario involves direct parameter manipulation to query unauthorized resources rather than forging requests via third-party malicious websites leveraging browser cookie persistence mechanisms.

Server-Side Request Forgery

Why it fails: Server-Side Request Forgery occurs when a vulnerable application fetches a remote resource supplied by the user without adequate validation. Modifying a numerical user identifier in a RESTful API path is an access control failure, not an arbitrary outbound network request vulnerability originating from the backend server.

Mass Assignment

Why it fails: Mass Assignment happens when client-supplied inputs are automatically bound to internal object properties, potentially allowing privilege escalation or unwanted attribute modification. Manipulating a URL path parameter to access sequential resource records represents an authorization flaw rather than unintended data binding during object creation.

Broken Authentication due to weak session token generation algorithms allowing session hijacking across user accounts.

Why it fails: Weak token generation allows attackers to forge active session identifiers, whereas this scenario involves a fully authenticated user simply swapping integer resource identifiers within the URI path to access unauthorized data objects belonging to other users directly.

Mass Assignment vulnerability caused by automatically binding incoming HTTP request parameters to internal backend database object properties.

Why it fails: Mass Assignment binds request body fields to object properties, whereas this attack manipulates the URI path identifier to reach another user's record, which is Broken Object Level Authorization. Mass Assignment would be correct if extra JSON fields altered unintended attributes on the caller's own object.

Improper Assets Management stemming from exposed documentation and forgotten non-production API endpoints lacking proper security controls.

Why it fails: Improper Assets Management concerns undocumented, deprecated or non-production endpoints left exposed, not an authorised endpoint missing object-level checks. Here the live /api/v1/users/{id}/settings route lacks ownership validation, which is Broken Object Level Authorization; assets management would apply to forgotten staging APIs.

The token expires in less than 60 seconds

Why it fails: Token expiration is a standard security control to limit the window of opportunity for intercepted tokens. It is unrelated to the algorithm field validation. A short expiration does not prevent an attacker from modifying the header to 'none' if the backend fails to validate signatures.

The token uses RS256 instead of HS256

Why it fails: RS256 is an asymmetric algorithm and is generally considered more secure than symmetric HS256. Using RS256 does not inherently indicate a vulnerability. The vulnerability lies in the improper handling of the algorithm header, regardless of whether asymmetric or symmetric keys are used for signing.

The secret key is stored in an environment variable

Why it fails: Storing secret keys in environment variables is a standard security practice, provided those variables are protected. This does not relate to the JWT 'alg' field vulnerability, which is an implementation flaw in how the API processes the incoming token's signature requirements and the algorithm specified.

nmap -sU 10.0.0.0/16

Why it fails: The -sU option initiates a UDP scan, which probes UDP ports on each host. This is a port scan, not a host discovery method, and it can be slow and unreliable. It does not meet the requirement of quickly identifying live hosts without port scanning.

nmap -sV 10.0.0.0/16

Why it fails: The -sV option enables version detection, which probes open ports to determine service and version information. This is a deep inspection technique that requires port scanning and is not suitable for simple host discovery. It would take much longer and generate more traffic than needed for identifying live hosts.

nmap -sS 10.0.0.0/16

Why it fails: The -sS option performs a TCP SYN scan, which attempts to identify open ports on each host. This goes beyond simple host discovery and will generate significant traffic, potentially triggering IDS alerts. It is not the appropriate command for quickly identifying live hosts without port scanning.