Troubleshooting practice questions

You are troubleshooting an issue where a SIEM cannot parse an incoming STIX 2.1 bundle. The bundle contains a 'Relationship' object linking a 'Malware' object to an 'Infrastructure' object. Which property within the 'Relationship' object must be verified to ensure the link type is recognized by the parser?

Trap 1: 'source_ref'

'source_ref' identifies the originating object's identifier, not the semantic link type, so a parser cannot determine the relationship's meaning from it. It is tempting because it is mandatory in every Relationship, and would be the correct property to verify when confirming which object the relationship originates from.

Trap 2: 'target_ref'

'target_ref' names the destination object's identifier, not the relationship's semantics, so it cannot tell the parser what kind of link exists. It is tempting because it is mandatory, and would be correct when verifying which object the relationship points to, not the link type.

Trap 3: 'spec_version'

'spec_version' declares the STIX specification version used, not the relationship's semantic type, so it cannot identify the link. It is tempting because version mismatches genuinely break parsing, and would be correct when diagnosing whether the bundle conforms to a supported STIX release.

A
'source_ref'
Why it fails: 'source_ref' identifies the originating object's identifier, not the semantic link type, so a parser cannot determine the relationship's meaning from it. It is tempting because it is mandatory in every Relationship, and would be the correct property to verify when confirming which object the relationship originates from.
B
'relationship_type'
STIX 2.1 Relationship objects use the 'relationship_type' property to define the semantic link between source_ref and target_ref, such as 'communicates-with'. A parser reads this property to classify the connection, so an unrecognised or malformed value prevents parsing.
C
'target_ref'
Why it fails: 'target_ref' names the destination object's identifier, not the relationship's semantics, so it cannot tell the parser what kind of link exists. It is tempting because it is mandatory, and would be correct when verifying which object the relationship points to, not the link type.
D
'spec_version'
Why it fails: 'spec_version' declares the STIX specification version used, not the relationship's semantic type, so it cannot identify the link. It is tempting because version mismatches genuinely break parsing, and would be correct when diagnosing whether the bundle conforms to a supported STIX release.

Question 2hardmultiple choice

You are troubleshooting a feed ingestion failure in an OpenCTI platform where the connector logs show '403 Forbidden' during a HTTPS pull. What is the primary troubleshooting step?

Trap 1: Update the SSL certificates on the collector.

Expired or untrusted TLS certificates cause handshake failures such as certificate verify failed or SSL errors, not a 403, which arrives after a successful handshake. Certificate renewal is correct when the connector cannot establish HTTPS at all because the remote chain is invalid or expired.

Trap 2: Increase the connector memory allocation.

A 403 response indicates the remote server rejected the request as unauthorised, so credentials, API tokens or user-agent headers need checking. Memory exhaustion would surface as OutOfMemoryError or timeouts, not an HTTP status code. Raising heap is correct when connectors crash while parsing unusually large STIX bundles.

Trap 3: Restart the OpenCTI RabbitMQ service.

RabbitMQ carries messages between OpenCTI components; a broker outage produces connection-refused or queue errors, not a 403 from the remote feed host. Restarting it is correct when ingestion stalls with workers idle and queues backing up, but it cannot alter the remote server's authorisation decision.

A
Update the SSL certificates on the collector.
Why it fails: Expired or untrusted TLS certificates cause handshake failures such as certificate verify failed or SSL errors, not a 403, which arrives after a successful handshake. Certificate renewal is correct when the connector cannot establish HTTPS at all because the remote chain is invalid or expired.
B
Increase the connector memory allocation.
Why it fails: A 403 response indicates the remote server rejected the request as unauthorised, so credentials, API tokens or user-agent headers need checking. Memory exhaustion would surface as OutOfMemoryError or timeouts, not an HTTP status code. Raising heap is correct when connectors crash while parsing unusually large STIX bundles.
C
Check if the source IP is whitelisted on the threat intelligence provider side.
A 403 during an HTTPS pull means the provider received the request but refused it, so authentication and connectivity are working. Verifying that the connector's source IP is whitelisted on the provider side addresses the authorisation constraint causing the rejection.
D
Restart the OpenCTI RabbitMQ service.
Why it fails: RabbitMQ carries messages between OpenCTI components; a broker outage produces connection-refused or queue errors, not a 403 from the remote feed host. Restarting it is correct when ingestion stalls with workers idle and queues backing up, but it cannot alter the remote server's authorisation decision.

Question 3hardmulti select

When hunting for lateral movement, which THREE activities should be flagged as highly suspicious in a Windows environment?

Trap 1: Opening a local text file

Standard daily user activity.

Trap 2: Standard user running 'whoami'

Can be part of normal troubleshooting.

A
Remote RDP access to a Domain Controller
Domain Controllers hold authentication authority; interactive RDP sessions to them are rare in normal administration, which typically uses RSAT or WinRM. Such access often indicates credential theft and privileged lateral movement, warranting immediate investigation during threat hunting.
B
Opening a local text file
Why it fails: Standard daily user activity.
C
Execution of services.exe via WMI
WMI executing services.exe is abnormal because services.exe normally launches from System32 via the Service Control Manager. Remote WMI process creation of that binary indicates an attacker abusing WMI for lateral movement or persistence, matching the hunting scenario's suspicious-activity criteria.
D
Standard user running 'whoami'
Why it fails: Can be part of normal troubleshooting.
E
Creation of remote services via SC.exe
SC.exe creates or configures Windows services remotely, letting an attacker execute code on another host without interactive logon. This is a classic lateral movement technique, distinct from local service creation, because the remote service control manager accepts the instruction across the network.

Question 4hardmultiple choice

You are troubleshooting a synchronization issue between two threat intelligence platforms. One platform is configured for TAXII 2.1 and the other is receiving the data but failing to parse the STIX 2.1 bundle. Which diagnostic step is most appropriate?

Trap 1: Restart the TAXII server service

Restarting the TAXII server cannot fix a STIX 2.1 parsing failure, since the bundle content, not the transport service, causes the error. It is tempting because restarts clear transient TAXII connection faults, and would be correct if the server were unreachable rather than delivering unparseable content.

Trap 2: Check the TLS certificate expiration date

TLS certificate expiry would abort the HTTPS connection to the TAXII server entirely, producing handshake failures rather than a received bundle that fails STIX parsing. Certificate checks are the right diagnostic when transport cannot be established, not when payload content is delivered but rejected as malformed.

Trap 3: Check the firewall rules for port 443

Port 443 blocking would prevent the TAXII collection from being retrieved at all, so no bundle would arrive to parse. Firewall rule checks suit connectivity failures — timeouts, refused connections or empty polls — whereas a bundle that arrives and fails parsing points to STIX schema or version mismatch.

A
Restart the TAXII server service
Why it fails: Restarting the TAXII server cannot fix a STIX 2.1 parsing failure, since the bundle content, not the transport service, causes the error. It is tempting because restarts clear transient TAXII connection faults, and would be correct if the server were unreachable rather than delivering unparseable content.
B
Validate the JSON bundle against the STIX 2.1 schema
Schema validation confirms the JSON conforms to STIX 2.1 structure before parsing logic runs, isolating whether the failure stems from malformed content rather than TAXII transport. This directly tests the receiving platform's parse error against the specification.
C
Check the TLS certificate expiration date
Why it fails: TLS certificate expiry would abort the HTTPS connection to the TAXII server entirely, producing handshake failures rather than a received bundle that fails STIX parsing. Certificate checks are the right diagnostic when transport cannot be established, not when payload content is delivered but rejected as malformed.
D
Check the firewall rules for port 443
Why it fails: Port 443 blocking would prevent the TAXII collection from being retrieved at all, so no bundle would arrive to parse. Firewall rule checks suit connectivity failures — timeouts, refused connections or empty polls — whereas a bundle that arrives and fails parsing points to STIX schema or version mismatch.

Question 5hardmulti select

Which THREE of the following are critical steps when troubleshooting a failed TAXII 2.1 server connection?

Trap 1: Reinstall the operating system.

Reinstalling the operating system destroys the client configuration and certificates without addressing the connection fault. It is tempting when a host is suspected corrupt, but TAXII failures stem from TLS trust, endpoint URLs, authentication or firewall rules, which OS reinstallation neither diagnoses nor repairs.

Trap 2: Modify the TAXII protocol specification.

The TAXII 2.1 specification is a fixed OASIS standard; clients cannot alter it to fix connectivity. Editing the spec is tempting because protocol mismatches do cause failures, but the correct troubleshooting step is verifying the advertised discovery URL and supported API roots against the server's actual implementation.

A
Reinstall the operating system.
Why it fails: Reinstalling the operating system destroys the client configuration and certificates without addressing the connection fault. It is tempting when a host is suspected corrupt, but TAXII failures stem from TLS trust, endpoint URLs, authentication or firewall rules, which OS reinstallation neither diagnoses nor repairs.
B
Verify network connectivity (e.g., ping/telnet).
Verifying network connectivity confirms that TCP reachability to the TAXII 2.1 endpoint exists before investigating application-layer faults. Ping and telnet tests isolate firewall, routing or port-blocking issues that would otherwise masquerade as TAXII protocol errors, satisfying the stem's requirement to identify critical troubleshooting steps for a failed server connection.
C
Validate server TLS certificate chain.
Validating the server TLS certificate chain confirms the TAXII 2.1 endpoint presents a trusted, unexpired chain, satisfying the stem's failed-connection constraint. Because TAXII 2.1 mandates HTTPS, a broken or untrusted chain aborts the TLS handshake before any collection exchange, so verifying the chain isolates transport-layer trust failures from authentication or polling errors.
D
Modify the TAXII protocol specification.
Why it fails: The TAXII 2.1 specification is a fixed OASIS standard; clients cannot alter it to fix connectivity. Editing the spec is tempting because protocol mismatches do cause failures, but the correct troubleshooting step is verifying the advertised discovery URL and supported API roots against the server's actual implementation.
E
Confirm valid API credentials.
Valid API credentials authenticate every TAXII 2.1 request, and the server rejects unauthenticated or expired tokens with HTTP 401 before any collection query runs. Confirming credentials therefore isolates authentication failures from transport or endpoint errors, satisfying the stem's requirement to identify a critical troubleshooting step for a failed connection.