Technology Essentials practice questions

ps -ef | grep 443

Why it fails: ps displays process status but does not correlate process IDs with network sockets.

route -n

Why it fails: route manages the routing table and does not show active socket connections to processes.

tcpdump -i eth0 port 443

Why it fails: tcpdump captures traffic but does not map the traffic to a local PID.

Audit logs

Why it fails: Audit logs track user actions and configuration changes, not performance metrics.

Flow logs

Why it fails: Flow logs track IP traffic patterns, not database application performance.

IAM logs

Why it fails: IAM logs track authentication and authorization events.

Strict-Transport-Security

Why it fails: HSTS enforces HTTPS connections, not iframe usage.

Content-Security-Policy: default-src 'self'

Why it fails: While CSP is useful, X-Frame-Options is the specific header for clickjacking prevention.

X-XSS-Protection: 1

Why it fails: This header is for cross-site scripting protection, not clickjacking.

Change the root password

Why it fails: This does not impact resource limits for existing sessions.

Disable the swap partition

Why it fails: This would likely crash the system faster under high load.

Use iptables

Why it fails: iptables is a firewall and does not limit local process counts.

Active Directory Users and Computers

Why it fails: This tool manages objects, it does not track history or audit GPO changes.

Registry Editor

Why it fails: The registry is where the GPO is applied, not where it is audited.

DNS Manager

Why it fails: DNS manages name resolution, not GPO security.

The email's digital signature, if present, using the sender's public key.

Why it fails: While digital signatures can verify authenticity, most phishing emails lack a valid signature. Relying on this first would miss the majority of attacks. Additionally, obtaining the sender's public key may not be straightforward. SMTP headers are more universally available and provide immediate clues about the email's origin and routing.

The email's attachment file hash, comparing it to known malware databases.

Why it fails: The scenario describes a link to an external site, not an attachment. Hashing the attachment is irrelevant if no attachment exists. Even if an attachment were present, the link itself is the primary vector here. Examining headers is more directly applicable to determining email legitimacy.

The email's SPF, DKIM, and DMARC alignment by querying DNS records.

Why it fails: SPF, DKIM, and DMARC checks are valuable, but they require access to DNS records and may not be immediately available. In many phishing cases, attackers use domains with properly configured records. Headers provide the raw data to perform these checks and more, making them the essential first step in analysis.

DNS cache poisoning attack

Why it fails: DNS cache poisoning involves injecting false DNS records into a resolver's cache to redirect traffic. It does not involve a high volume of queries with encoded data in subdomains. The observed pattern is about data transfer, not cache manipulation.

Domain generation algorithm (DGA) for malware command-and-control

Why it fails: DGAs generate many domain names to evade blocklists, but they typically result in queries for many different domains, not subdomains of a single domain. The queries would also not typically use TXT records with encoded data. DGA is about domain flux, not data encoding within subdomains.

Fast flux DNS for botnet resilience

Why it fails: Fast flux involves rapidly changing the IP addresses associated with a domain to avoid takedown. It does not typically involve random subdomains or TXT records with encoded payloads. The scenario describes data encoding within DNS queries, which is characteristic of tunneling, not fast flux.

netstat -tulpn | grep 4444

Why it fails: netstat with those flags performs a similar function to ss, showing listening ports and associated PIDs. It does not provide the command line or executable path. Using it here would be redundant and would not yield the deeper process details the analyst needs. It is also deprecated on many modern Linux distributions in favor of ss.

lsof -i :4444

Why it fails: lsof -i :4444 lists open files associated with network connections on port 4444, including the process name and PID. However, it does not directly show the full command line or executable path. While it can confirm which process is listening, it is less informative than /proc-based inspection for retrieving the exact command and binary location, which are critical for determining maliciousness.

ps -p <PID> -o pid,cmd

Why it fails: ps with -p and -o pid,cmd shows the command line for a specific PID, but the analyst must first obtain the PID. The ss output includes the PID with the -p flag, so this command could work if the PID is known. However, it does not reveal the executable path or the full environment, and it may truncate long command lines, potentially hiding malicious arguments.

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

Why it fails: This suite uses DHE for key exchange, which can provide forward secrecy, but it uses AES-128 in CBC mode. CBC mode is vulnerable to padding oracle attacks and is not considered as strong as GCM. Additionally, DHE with weak parameters can be susceptible to Logjam attacks. While it offers forward secrecy, the encryption mode is weaker and less recommended than GCM. The requirement specifies strong encryption, and CBC is generally discouraged in favor of AEAD modes like GCM.

TLS_PSK_WITH_AES_128_GCM_SHA256

Why it fails: This suite uses pre-shared keys (PSK) for authentication and key exchange. PSK does not provide forward secrecy because the same pre-shared key is used across sessions; if compromised, all sessions can be decrypted. While AES-128-GCM is strong, the lack of forward secrecy fails the requirement. PSK is typically used in constrained environments, not for general web applications requiring forward secrecy. Therefore, this suite is not suitable.

TLS_RSA_WITH_AES_256_CBC_SHA

Why it fails: This cipher suite uses RSA for key exchange, which does not provide forward secrecy because the same private key is used to decrypt all session keys. If the server's private key is compromised, past sessions can be decrypted. It also uses AES-256 in CBC mode, which is susceptible to padding oracle attacks like BEAST and Lucky Thirteen. While AES-256 is strong, the lack of forward secrecy and use of CBC make this suite unsuitable for the requirement.

Apply the filter ssl.handshake.type == 1 and export the associated objects to reconstruct the server certificate from the TLS record layer.

Why it fails: Handshake type 1 is Client Hello, which does not contain the server certificate. The obsolete ssl.handshake filter field also does not match modern TLS 1.3 dissection, and exporting objects from the record layer cannot reconstruct a certificate that is encrypted. The analyst would obtain client capabilities rather than the server's certificate issuer.

Use the protocol hierarchy statistics window to confirm TLS traffic exists, then infer the version from the port number and assume the issuer from the destination domain.

Why it fails: Protocol hierarchy statistics only summarize protocol distribution and do not expose handshake parameters. Inferring TLS version from port 443 is inaccurate because TLS runs on arbitrary ports, and assuming the issuer from a domain name does not verify the actual certificate chain. This approach produces an unsubstantiated conclusion unsuitable for incident evidence.

Display filter tcp.port == 443, then read the raw TCP payload bytes to locate the ASCII strings for the negotiated version and issuer name.

Why it fails: TLS 1.3 encrypts the certificate and most handshake content after the Server Hello, and even the version is carried in a binary extension, not plain ASCII. Filtering only on port 443 and reading raw payload yields ciphertext that cannot reveal the issuer. The analyst would misidentify the protocol version and fail to validate the certificate chain.

windows.malfind

Why it fails: windows.malfind scans for suspicious memory regions, such as those with RWX permissions or containing injected code like reflective DLLs. While it is valuable for detecting injected code, it does not specifically identify hidden or unlinked processes. The question asks for both hidden processes and injected code, and malfind alone does not cover hidden processes.

windows.pslist

Why it fails: windows.pslist enumerates processes by walking the active process list, which is the same method used by Task Manager. It will not show processes that have been unlinked from the list by rootkits or advanced malware. While it provides a baseline, it is insufficient for detecting hidden processes or injected code, which require more advanced techniques.

windows.netscan

Why it fails: windows.netscan enumerates network connections and listening sockets, similar to netstat. It does not detect hidden processes or injected code. While useful for identifying command-and-control connections, it does not address the specific need to find unlinked processes or reflective DLL loading, which require memory structure scanning.

System Configuration (msconfig)

Why it fails: msconfig is primarily for troubleshooting startup issues and allows enabling or disabling startup services and some startup items. However, it does not display all autostart extensibility points, such as Run registry keys or startup folders in full detail. It is less comprehensive than tools designed for autorun analysis, and it does not show digital signatures or command-line arguments.

Event Viewer

Why it fails: Event Viewer displays system, application, and security logs but does not list autostart programs. While it may contain events related to process creation or service starts, it does not provide a consolidated view of startup items. The analyst would need to correlate multiple event IDs and still would not see the full set of autostart locations that Autoruns reveals.

Task Manager

Why it fails: Task Manager shows currently running processes and can disable startup items, but it does not provide a comprehensive view of all autostart locations, such as Run keys and scheduled tasks. It is useful for immediate process management but lacks the detailed enumeration needed for a thorough malware investigation. The analyst would miss many persistence mechanisms if relying solely on Task Manager.

alert tcp $HTTP_SERVERS 80 -> $EXTERNAL_NET any

Why it fails: This header reverses the direction, matching outbound traffic from the web server to external networks. The scenario describes inbound traffic to the web server, so this header would not match. The direction operator -> is crucial; using the wrong direction will cause the rule to miss the attack entirely.

alert udp $EXTERNAL_NET any -> $HTTP_SERVERS 80

Why it fails: This header uses UDP instead of TCP. Web traffic on port 80 is typically TCP, and the scenario specifies TCP packets. Using UDP would not match the traffic because the protocol is incorrect. While UDP port 80 could theoretically be used, standard HTTP uses TCP, so this header would fail to detect the described attack.

content:"cmd.exe"; nocase;

Why it fails: While this option includes the content match, it adds 'nocase', which makes the match case-insensitive. The scenario does not specify case insensitivity, and adding it could cause false positives. However, the question asks for required components to match the traffic; 'nocase' is not required. The basic content match without modifiers is sufficient, and this option is not one of the two required header components.

The VM is isolated from the physical network.

Why it fails: Bridging attaches the VM to the physical network segment, so it is not isolated; it becomes directly reachable by other LAN hosts. It is tempting because host-only and internal modes do isolate a VM, but those are different adapter configurations, not bridged mode.

The VM can only communicate with the host.

Why it fails: A bridged adapter places the VM directly on the physical LAN with its own IP, so it is not limited to host-only communication. It is tempting because host-only networking does restrict a VM to the host, but that is a separate adapter mode, not bridging.

The VM uses the host's IP address.

Why it fails: A bridged adapter gives the VM its own MAC and IP on the physical LAN; it does not borrow the host's address. It is tempting because NAT mode does share the host's IP for outbound traffic, but that is a distinct adapter type, not bridging.

firewalld

Why it fails: firewalld filters network packets by zone and port; it never reads file contents, so it cannot detect altered binaries. It is tempting because it is a core RHEL security component, but its purpose is traffic control, whereas integrity verification needs a tool such as AIDE that compares cryptographic hashes against a baseline database.

systemctl status

Why it fails: systemctl status reports whether a unit is active and shows recent journal entries; it never hashes files on disk. It is tempting because it inspects running services, but service state is unrelated to binary integrity, whereas AIDE compares current file hashes against a stored baseline to reveal tampering.

yum check-update

Why it fails: yum check-update queries configured repositories for newer package versions; it does not hash installed binaries or compare them against known-good values. It is tempting because it reports package-level change, but that reflects available updates rather than unauthorised file modification, which AIDE detects through its baseline database.

Task Manager - Details tab

Why it fails: Task Manager's Details tab lists running processes, PIDs and resource usage; it exposes no ACL or permission data for an executable. Auditing a service account's effective permissions needs the file's Advanced Security settings, Effective Access tab. Task Manager is correct for identifying or terminating a hung service process.

Local Security Policy (secpol.msc)

Why it fails: Local Security Policy configures account and audit policy on the local machine; it cannot enumerate a service account's effective permissions on a specific executable. Effective access auditing requires the file's Security tab, Advanced, then Effective Access. secpol.msc is the right tool for setting password, lockout and audit policy.

Event Viewer - System Log

Why it fails: The System log records service start failures and their error codes, but it never reports which ACE granted or denied access. Determining effective permissions requires the executable's Advanced Security settings, Effective Access tab. Event Viewer is the right tool for confirming the failure reason before investigating permissions.

Protocol: UDP, Port: 443, Source: 10.0.1.0/24

Why it fails: HTTPS runs over TCP, so a UDP rule on 443 matches no TLS handshake packets; the port and subnet are correct but the transport protocol is wrong. It tempts because 443 is the HTTPS port, and UDP 443 would suit QUIC or HTTP/3 traffic.

Protocol: TCP, Port: 80, Source: 10.0.1.0/24

Why it fails: Port 80 carries unencrypted HTTP, so HTTPS traffic on 443 is never matched; the subnet scope is right but the port is wrong. It tempts because port 80 is the standard web port, and would be correct for permitting inbound plain HTTP from that subnet.

Protocol: All Traffic, Port: All, Source: 0.0.0.0/0

Why it fails: Opening all protocols and ports to 0.0.0.0/0 exposes the instance to the entire internet, not just the subnet, and permits far more than HTTPS. It tempts as a quick troubleshooting rule, and would be correct only for temporarily diagnosing connectivity from any source.

Delete the registry key.

Why it fails: Deleting the registry key destroys the evidence needed to determine whether the entry is malicious and how it persists. It is tempting as immediate remediation to stop the program launching, but that is containment, not investigation; the examiner must first capture and analyse the value, its binary and associated timestamps.

Reboot the server.

Why it fails: Rebooting the server destroys volatile evidence such as running processes, network connections and memory-resident malware, and may trigger the persistence entry itself. It is tempting as a quick way to observe whether the entry executes, but forensic examination demands static analysis of the registry value and referenced binary before any restart.

Rename the file to .txt.

Why it fails: Renaming a file to .txt changes nothing about its content or behaviour, so it cannot reveal whether the Run entry is malicious. It is tempting as a safe way to inspect suspicious code, but proper analysis requires examining the binary, hash or signature rather than altering the artefact and destroying evidential integrity.

SNMPv1

Why it fails: SNMPv1 carries community strings in cleartext and offers no encryption or per-user authentication, so it cannot secure management sessions. It is tempting because it is a lightweight protocol for polling device metrics and traps, and it would be the right choice for read-only monitoring on a segregated management VLAN.

Telnet

Why it fails: Telnet transmits credentials and session data in cleartext, so anyone capturing the traffic reads the admin password directly. It is tempting because it is a simple, universally available CLI remote-login protocol, and it would suffice only on an isolated, trusted lab segment where confidentiality is not a requirement.

HTTP

Why it fails: HTTP carries management traffic in cleartext with no encryption or server authentication, exposing credentials to interception. It is tempting because it is simple and universally supported for web-based device interfaces, but it would be correct only for non-sensitive lab access where confidentiality is not required.

VLAN Tagging

Why it fails: VLAN tagging separates traffic into broadcast domains but does not filter DHCP server replies; a rogue server on an access port still answers clients. Tagging is the correct choice for segmenting departments or isolating voice traffic, not for blocking unauthorised DHCP.

Dynamic ARP Inspection

Why it fails: Dynamic ARP Inspection validates ARP packets against the DHCP snooping binding table, blocking ARP spoofing rather than rogue DHCP offers. It is the right control when attackers poison ARP caches; DHCP snooping itself drops unauthorised server replies.

Port Security

Why it fails: Port Security limits the number of MAC addresses learned on an interface, defending against MAC flooding and unauthorised devices. It cannot distinguish legitimate from rogue DHCP servers, so it is chosen when the threat is switch port abuse.