This blog post is the second in a series about threat hunting by Shani Touitou, Incident Response and Threat Hunting Specialist. To read the first blog in the series, click here.
As part of the cyber defense strategy, threat hunting is a proactive approach to identify and neutralize potential threats before they cause harm. This blog post, the second in a series of technical reflections on threat hunting methods, will explore the steps taken to uncover suspicious usage of a PowerShell downloading functionality.
Through an in-depth threat hunting process, I discovered an entire company’s code repository that was exposed on the Internet through a publicly accessible web interface. Depending on each organization’s code infrastructure, there are different ways to detect exposed code repositories.
The following sections outline one example of a repository that used PowerShell, a command-line interface that allows for task automation and configuration.
How code repositories and management systems operate
Code repositories and managers are critical components of the software development lifecycle. They serve as a central storage location for software binaries and dependencies, allowing teams to share and reuse code components.
Repository managers also ensure that the correction version of a software is being used, helping to avoid conflicts and errors. This means that multiple members of a team of developers can work on software simultaneously, while preserving a single official version. Oftentimes, organizations maintain their own private repositories that are entirely internal and serve as the foundation of all software development in an organization. Many of these repositories are software and web-based, increasing their chance of exposure to threat actors. Given the importance of these tools and their value to threat actors, it is vital to ensure that they are properly secured.
The consequences of cyberattack on a repository manager
Exposing a code repository can have severe consequences. Cybercriminals can exploit vulnerabilities in the code to gain unauthorized access to the network, steal sensitive data, or plant malware.
By exposing a repository manager web interface, threat actors gain full visibility into an organization’s software development processes, making it easier for them to launch a cyberattack.
Code repositories hold an added layer of complexity when it comes to identifying cyberattacks. Because many mitigation techniques are rule-based, threats embedded into code repositories can often go missed. Threat actors add in dynamic and unique commands of script into code repositories, meaning that usually, there is no precedent or rule that may trigger an automatic remediation and response . This means that oftentimes, proactive threat hunting is the only way to detect and mitigate these types of directed, hidden attacks.
By exposing a repository manager web interface, threat actors gain full visibility into an organization’s software development processes, making it easier for them to launch a cyberattack.
Beginning the threat hunting process: Searching for a suspicious PowerShell script
In a standard threat hunting process that took place monthly for my clients, I ran an investigation within Microsoft PowerShell, a command line shell that creates automations and configurations across a wide range of programs. In this query, I set out to search for any suspicious PowerShell scripts that could be identified by set download parameters. These download parameters indicate that the PowerShell script is downloading something to the enterprise network, which can be a red flag. Hunting processes like these are a standard part of proactive threat hunting activities.
My ultimate findings, which did not identify suspicious download activity within PowerShell, were made as a result of my investigative process. This is some of the beauty of the threat hunting journey: I started my explorations in one particular direction, and along the way, uncovered sensitive data that I hadn’t been looking for.
In this case, my findings were extremely significant, identifying a critical exposure that threatened the foundations of the company’s security and their intellectual property.
Defining the search scope of the threat hunting session
The first stage in starting any hunting session is defining the scope of the hypothesis, including selecting which systems to investigate and what data sources need to be collected and which queries to run. When looking for an exposed web interface, for example, the hunt should focus on systems that have access to the repository manager and other systems that could be potentially affected by a breach.
Because modern network infrastructures are so complex and multi-layered, setting scopes is critical. This allows security teams to limit the amount of data processed in order to run a more directed query into relevant sections of an organization’s network.
Searching for PowerShell-dedicated events to identify suspicious activity
I defined the scope of my threat hunting query to focus on PowerShell as an example of a technique for communicating outside of the network. I then began sifting through PowerShell-specific events that would identify any suspicious activity. Some well-known events that were essential for my hunting were:
-
Process Creation (Event ID 4688): This event logs data when any new process is created, including command line terminal session records, which have a very high value for cyber attackers. For detecting PowerShell activities, an additional filter limiting the search to the PowerShell command line of the PowerShell process or parent name is required.
-
PowerShell Script Block Logging (Event ID 4104): This event logs when a PowerShell script block is executed.
-
PowerShell Module Logging (Event ID 4103): This event logs when a PowerShell module is loaded .
-
PowerShell Script Block Logging (Event ID 4104): This log presents the actual script that was run, which can be useful for understanding what actions were taken by the PowerShell scripts.
To those events, I then added more specific parameters to note any suspicious activity, such as downloading, policy bypassing, running encoded PowerShell code, and more. These parameters would flag behaviors occurring within these specifically selected PowerShell events.
To identify these events, SIEM and EDR platforms have various options to create custom queries that hunt for specific event IDs.
For example, in order to search for PowerShell Process Creation events with a download parameter in the terminal session, the following query could be used in KQL syntax:
SecurityEvent
| where EventID == 4688
| where ProcessCommandLine contains “powershell.exe” and ProcessCommandLine contains “-Command” and ProcessCommandLine contains “Download”
| project TimeGenerated, Computer, AccountName, ProcessCommandLine
Through this query, and with these set parameters, I identified an exposed URL that contained a web interface that included the code folders for various business activities, including employee salary calculations and clock entry controls. This code repository was hosted in a very well-known product developed by a software vendor that organized all of the enterprise’s binary resources.
In this case, I found that the exposed URL was accessible via the Internet using an HTTP protocol with no restriction and no requirement for authentication. 
Example of the code repository accessible with no authentication
Recommendations for mitigating security risk to prevent future attacks
Because code repositories and managers are so commonly used, strict and comprehensive security policy surrounding them must be enforced across the organization. Policy and configurations must be constantly updated to ensure that access limitations and the principle of least privilege is enacted. For every new web interface created, access permissions must be reviewed to determine if it can be externally accessed, or not. This is especially critical with code repositories that are used for collaborative work across developers in an organization. In such cases, access must be restricted to internal use only – and this access must be monitored very closely for any changes.
Layers of security must be put in place to prevent future cyberattacks. Because of the nature of script and code-based cyberattacks, multi-type cyber defenses are critical to ensure identification. For cyberattacks that are not rule-based, proactive hunting services, network monitoring, and access supervision must be put in place across various areas.
Data can and should be used as a powerful tool to prevent future attacks. Once a suspicious PowerShell script is identified, data can be analyzed to determine its purpose and potential risks. Examination of the script’s code can determine if the script holds any malicious material or if it may be used for harmful purposes. Collaboration across teams and security incidents can help enrich data, allowing past security incidents to inform future proactive analysis and hunting for suspicious or malicious material that may be embedded into an organization’s environment.
Want to learn more about how proactive threat hunting can be used to mitigate risk? Contact us.
This blog post is the second in a series about threat hunting by Shani Touitou, Incident Response and Threat Hunting Specialist. To read the first blog in the series, click here.
