When analysts encounter suspicious Events of Interest (EOI) during verification, CTI platforms can provide additional context about whether those indicators are associated with known threats. Querying reputation databases, threat intelligence feeds, and community-sourced information provides insight that can help distinguish between confirmed malicious activity and benign behavior. This is especially important during the verification phase, where the goal is to quickly assess the validity of the incident without expending unnecessary resources.

For example, using one or more CTI sources, analysts can query intelligence databases using technical indicators such as IP addresses, domain names, URLs, or file hashes observed in the environment. The CTI database may indicate whether those indicators have been previously associated with malware distribution, phishing campaigns, command-and-control infrastructure, or other malicious activity. Platforms such as VirusTotal, AlienVault OTX, Shodan, and commercial threat intelligence feeds may even provide different perspectives on the same indicator, allowing analysts to cross-reference multiple sources to increase confidence in the assessment.

For example, in an incident engagement, the IP address 147.45.44.131 was observed as a source for PowerShell script downloads in web proxy logs. While suspicious, this is not definitive proof of malicious activity. Cross-referencing this IP address against CTI sources, including VirusTotal and AlienVault OTX, provided additional context on malicious activity patterns, as shown in Figure 3 and Figure 4.

CTI enrichment also helps identify false positives before they consume investigation resources. Legitimate services sometimes exhibit behavior that triggers security alerts: content delivery networks with unusual traffic patterns, cloud infrastructure with dynamic IP allocation, or security tools performing authorized scanning. Threat intelligence platforms often maintain databases of known-good infrastructure that can quickly rule out false positives. For example, regularly timed outbound connections to an unfamiliar IP address might initially appear to match common command-and-control activity patterns, but CTI enrichment revealing that the IP address belongs to Microsoft’s Windows Notification Service (WNS) infrastructure can quickly close the verification loop, as shown in Figure 5 and Figure 6.

The same IOC can represent vastly different risk levels depending on what threat intelligence reveals about its origin, associated threat actors, and typical attack patterns. Using the CTI context, analysts can better assess the initial risk classification during the verification assessment.

For example, consider how attribution context influences our understanding of risk. A phishing email with a credential harvesting link might warrant a medium classification if threat intelligence associates it with a mass-distributed commodity campaign targeting broad populations. The same indicator escalates to high or critical if CTI links it to a threat actor known for targeting similar organizations with follow-on ransomware deployment.

Threat intelligence also informs risk classification by revealing the capabilities of attackers and the typical impact. CTI sources often document the outcomes of previous campaigns attributed to specific threat actors, including average dwell times, data exfiltration volumes, and recovery costs for victim organizations. This historical context helps analysts calibrate their risk assessment against real-world consequences rather than theoretical harm.

When integrating CTI into risk classification, analysts should consider the following factors:

Threat intelligence platforms often provide relationships between indicators, allowing analysts to expand their verification scope based on known associations. A single suspicious indicator may connect to additional domains, IP addresses, file hashes, or behavioral patterns associated with the same campaign or threat actor.

When CTI reveals related indicators, analysts can search for those additional IOCs across the environment to determine whether the initial finding represents an isolated event or a broader compromise. This pivoting capability transforms verification from a single-indicator assessment into a more comprehensive evaluation of potential threat presence.

For example, an analyst investigating a domain hosting a ransomware message might discover through CTI that the domain shares infrastructure with several other domains used by the same threat actor. Searching proxy logs or DNS records for those related domains could reveal additional affected users or systems that the initial detection missed, as shown in Figure 7. This expanded scope informs both the verification decision (continue vs. stop) and the subsequent scoping activity if the incident is confirmed.

CTI pivoting also helps analysts anticipate what else to look for if the incident is confirmed. Threat intelligence often documents the Tactics, Techniques, and Procedures (TTPs) associated with specific threat actors or campaigns. If the indicator under verification is attributed to a threat actor known for deploying specific persistence mechanisms or lateral movement techniques, analysts can proactively search for those TTPs during scoping rather than discovering them reactively.

A repeating help desk ticket caught the attention of the incident response team. A WordPress server used for distributing customer documentation for a software product was repeatedly reported as down or unresponsive. System administrators rebooted the server multiple times, resolving the issues. Engineering would close the help desk ticket, unable to reproduce the performance problems after a reboot, but the system would still become unresponsive, sometimes hours or days later.

Internal reporting from a savvy help desk analyst suggested that the problem might be broader than the engineering team realized. To verify the incident, the IRT collected logging information from the Apache web server. Reviewing the log activity revealed a large number of requests for a specific PHP file in the WordPress wp-includes directory, as shown in Listing 2.

By itself, this was not enough to verify that this was an incident, though the engineering team could not explain the purpose of the strangely named FkhDUPZ.php file in the WordPress wp-includes directory. Inspecting the contents of the file revealed the PHP file source code, as shown in Listing 3.

Recognizing the PHP script contained obfuscated code, the incident response team confirmed the report as an incident, escalating the event to involve the broader incident response team and other company stakeholders and decision-makers.

An accounts payable clerk forwarded a suspicious text message he received to the incident response team, as shown in Figure 8.

Upon initial investigation, the IRT learned that the URL in the text message redirected to the rhodeislandturnpike.com, which in turn redirected to a longer URL, as shown in Figure 9.

While the site had a semi-professional appearance that matched other Rhode Island government websites, the IRT suspected this was a phishing attempt. Using threat intelligence resources, the analyst learned that the rhodeislandturnpike.com domain had been registered that day, as shown in Listing 4. Further, the website server certificate was also created that day, as shown in Listing 5.

In their conversation, the accounts payable clerk indicated that he did not follow the SMS link and did not visit the "Rhode Island Turnpike" website. The phone’s browser history confirmed this account. Further, the analyst found no other evidence of web activity to rhodeislandturnpike.com in the company’s web proxy server activity logs.

After conferring with another analyst on the IRT, the incident was classified as an Indicator of Attack (IOA), but not as an Event of Interest (EOI) warranting further investigation. The IRT added the rhodeislandturnpike.com domain name and the server IP address to the threat intelligence platform for monitoring, and the incident was closed.

An analyst on the incident response team received a report concerning the disclosure of a vulnerable Amazon Simple Storage Service (S3) bucket. The report was from an unknown source, a self-identified bug bounty hunter, indicating that they found a high-risk vulnerability in the ssptmsdata S3 bucket. The bug bounty hunter wanted to know the organization’s policy on rewarding bug bounty hunters for their work.

The company analyst reviewed the report and identified that the ssptmsdata bucket was indeed used by one of the company’s AWS accounts. Using the AWS Command Line Interface, she reviewed the bucket’s security settings, as shown in Listing 6.

Reviewing the policy details, the analyst confirmed that the bucket policy allowed any AWS principal to apply S3 get and list actions to the bucket and its contents. This allowed any AWS account (from any organization) to list the files in the bucket and retrieve the contents of any file. However, she also knew that this bucket was used for public data sharing, including company website resources, the distribution of images, CSS, fonts, JavaScript files, and other related data.

To determine whether this required action by the incident response team, the analyst reviewed the contents of the bucket, as shown in Listing 7.

The S3 bucket contained several folders that appeared to be related to public website resources, as well as a pdf folder and a uat (User Acceptance Testing) folder. The analyst reviewed the contents of the pdf folder and found that it contained public documentation, and the uat folder contained documentation, test data, and sample configuration data for several products.

What remained unclear was whether the bucket configuration and the data met the organization’s business needs. Was the intention to share this data publicly, or was this a misconfiguration? Were any of the files in the bucket sensitive, or was the data intended for public use?

The analyst reached out to the AWS account holder of the ssptmsdata bucket to confirm its purpose and contents. She advised that the team responsible for this asset review each file contained in the bucket and determine whether sensitive data is disclosed. She insisted that the review was urgent, and asked the account owner to return his analysis by the end of the day. Once that review was complete, she could determine if the bucket configuration and information disclosure warranted further investigation by the incident response team.

As technical analysts, responders are responsible for helping decision-makers understand the incident and its potential impact on the organization. Using the insights gained from the verification activity and initial risk assessment, the analyst’s explanation of the incident significantly impacts how the risk is triaged and response actions taken.

When presenting the incident to decision makers, analysts should consider the following:

The decision maker should consider the organization’s overall needs, other demands on the incident response team, the team’s well-being, and the potential impact of the incident on the organization. While the incident response analyst provides insight into the incident, the decision-maker is ultimately responsible for determining appropriate response actions and allocating resources to the response effort based on the organization’s overall needs.

Establishing open communication between the incident response team and decision-makers occurs during the preparation activity. See the sidebar Building Management Support for Policy Development for insight on how to build management support for the incident response process.