Skip to main content

New Application

This alert occurs when Lacework detects the execution of a newly introduced software that has never been run within your entire cloud deployment in the past 90 days. The new software can be in any of the following forms:

  • A container image (such as from docker.io) that is currently running on a cluster.
  • A newly introduced software binaryrunning on a host.
note

For interpreters such as Java and Python, any new main program files (such as the main class or JAR file in Java) will be classified as new software binaries.

Why this alert is important

Malicious entities use different attack vectors to execute newly introduced software. Whether they are external parties or internal users controlled by outsiders (due to credential theft), executing new software is often crucial for a successful attack. Attackers commonly rely on "living off the land" tactics, leveraging existing software on a host or container image, even if it has not been executed before. Therefore, the initial execution of any new software raises security concerns.

Why this might be just fine

New software is regularly introduced in cloud environments, including new binaries, processes, and container images. Simply detecting new software does not automatically imply a security breach. However, it is important for the security team to monitor and confirm the intended use of new software, especially if it deviates from established operational practices. In some cases, alerts for routine software updates may require minimal investigation.

Investigation

In many instances, a prompt communication with your DevOps peers can verify the intended use of the new software. However, there might be situations where the DevOps team is uncertain about the new software. In such cases, the security team needs to exercise judgment and potentially initiate further investigation. For example, if a host that has remained without software updates for an extended period suddenly executes new software binaries, it raises suspicion and necessitates an investigation.

The security team can validate credential usage, review CI/CD logs, SSH sessions, or monitor other potentially suspicious activities on the host or container.

Here are the steps you can follow to triage this issue:

  1. Is this binary harmless and intended for execution?
    • To gather more information about the binary, including a file hash for cross-checking with VirusTotal, click the application name in the Alert Description to access the application dossier.
  2. Is this behavior expected or indicative of malicious activity?
  3. How was this binary initiated?
    • Who initiated the process?
      • Refer to the Who section under the Details tab to identify the user responsible for executing the process.
    • Was the execution related to a regular ticketed task?
      • Check if there is a corresponding Jira, Snowflake, or similar ticket that provides context for the deployment of this new application.
  4. Is this machine directly accessible from the internet?
    • You can verify this by checking the Exposure Polygraph located under the Exposure tab in the Alert Details.
  5. What are the access privileges of this machine, resource, or identity?
  6. Are any hard-coded secrets stored on the resource or machine?
    • You can verify this by checking the Exposure Polygraph located under the Exposure tab in the Alert Details.
  7. What data is stored on this machine or resource, and what data does it have access to?
  8. If this is deemed malicious:
    • What was the initial infection vector?
    • Are other machines on the network impacted?
      • To gather more information about other machines running this application or binary and the associated command line options, click the application name in the Alert Description to access the application dossier.
    • Was lateral movement observed?
    • Was any data exfiltrated?
    • What level of access does the attacker have?

Resolution

If it appears to be possible malicious use of an existing administrative tool, review logs from both source and destination machines. Disable the user and take the necessary steps to restore either host to a known, clean state.