Outbound Connection to a New External IP Address From Application

This alert occurs when Lacework FortiCNAPP detects an outbound (egress) connection from a software application in your cloud deployment to an external IP address that has not been previously contacted within the last 90 days. The determination of the IP address as external is based on host routing tables, excluding private IP ranges as defined in RFC 1918. Lacework FortiCNAPP conducts a reverse IP lookup by correlating DNS queries and network connections within your cloud deployment.

This alert indicates no corresponding DNS query from the software, suggesting that the connection was established directly to a raw IP address.

Why this alert is important​

Software operating within cloud deployments generally demonstrates consistent network behavior. Therefore, when there is new access to external IP addresses, it is advisable to investigate the situation.

Egress connections are commonly utilized to establish control during exploits, such as Log4J vulnerabilities. In cloud environments, the use of raw IP addresses raises suspicion due to several factors. Cloud deployments typically avoid direct reliance on IP addresses due to their frequent and unpredictable changes caused by mechanisms like load balancers, proxies, virtual hosting frameworks, content distribution networks, and more.

Conversely, malicious actors often favor raw IP addresses for various reasons. Using raw IPs allows them to evade traceability and avoid the overhead associated with setting up a dedicated domain name. Attackers are also comfortable with the unreliable and ephemeral nature of raw IPs.

Why this might be just fine​

Though connections to IP addresses can be legitimate in some cases, it is important to consider that such instances are relatively uncommon. Certain services may be hosted behind static IP addresses for reasons related to reliability or performance. However, these fixed-IP services are typically rare, and if they exist, they usually involve a static or slowly changing set of IP addresses that are frequently and consistently used.

In specific scenarios, Lacework FortiCNAPP may encounter difficulties correlating an IP address to a resolved domain name. This can occur when the DNS query takes place on a different machine, and the IP address is transmitted within a network message, or due to application-level caching in libraries used for connecting to cloud providers. Additionally, high CPU usage or memory pressure can sometimes cause the Lacework FortiCNAPP agent to drop data necessary for identifying the DNS query.

In such cases, it is possible for this alert to generate false positives. However, the alert is still triggered to prevent attackers from concealing their activities behind a high system load. It is crucial to carefully evaluate the circumstances and gather additional context to determine the validity of the alert.

Investigation​

Each alert of this nature requires an initial investigation. Here are the key steps to follow:

1. Gather information about the IP address:
   • Perform reverse DNS lookups to gather information about the IP address, helping identify false positives. For example, if the service already communicates with example.com, a reverse DNS lookup might reveal that the IP address belongs to example.com.
   • Explore other sources such as Whois registration and historical records to gain additional insights.
   • Check for any available threat information to determine if the IP address is known to be malicious.
     • Click the IP address in the Alert Description to initiate a VirusTotal search. This can provide further analysis and context regarding the IP address.
2. Identify the originating software and assess if it is usual for it to establish egress connections by reviewing its historical behavior. Click the application name in the Alert Description to access the application dashboard. Examine the external connection details and Polygraph sections to determine if the software frequently makes external connections.
3. Determine the user responsible for the connection by checking the Who section.
4. Assess the volume of exchanged data by analyzing the number of bytes transferred in both directions. Data exceeding 10KB indicates a significant amount of exchanged information.
5. Verify whether the egress connection is associated with the software supply chain. For instance, check if the software has been recently updated, potentially introducing a new version of a library that now relies on an external dependency.
   • Depending on your organization, it is advisable to examine platforms like Jira, ServiceNow, or your preferred SCM provider such as GitHub or GitLab for relevant information.
6. If there are any suspicious indications, escalate the investigation further. Look for patterns in logs that involve the specific IP address and involve your DevOps peers to gather their insights and opinions.

Resolution​

If the connection appears to be the result of malicious use of an existing administrative tool, malware, or an exploited application, review logs from the host. If the machine is compromised, take the necessary steps to restore the affected systems to a known, clean state.