This week’s guided threat hunting blog focuses on a specific policy violation - the use of unauthorized FTP services within your organization’s network. Security teams set certain policies in order to ensure safe practices across the network, so it is important that they have the ability to see when these policies are violated. This is where threat hunting can help. 

Stamus Security Platform (SSP) automatically detects and identifies threats on the network, and presents security teams with incident timelines and extensive context for each threat. Many organizations take advantage of advanced SSP features and take an even more proactive approach to their defenses. When this is the case, they might task a security analyst with hunting for specific threat types, anomalous activity, or suspicious behaviors. To do this, they can use the Stamus Enriched Hunting Interface.

This interface provides security practitioners with over 100 ready-to-use guided threat hunting filters, including various filters for policy violations, that they can use to investigate, classify, escalate, and automate vast amounts of event data, alerts, and contextual metadata. For a more detailed look at the Enriched Hunting Interface, read our blog titled, “Introduction to Guided Threat Hunting”.

In this example, we know the organizational policy does not allow internal non-IT staff to use any FTP services. Those that need to use an FTP service either need explicit approval or must use an already established procedure for file sending/sharing. While this is not technically a guided hunting filter, Stamus Security Platform allows analysts to quickly search for and identify the users that violated the policy and extract the file artifacts for forensic evidence and investigation if needed.

What is Unauthorized FTP Usage?

File Transfer Protocol (FTP) is a standardized network protocol used to transfer files across a network between a server and a client. FTP is commonly used through a command-line interface such as DOS or Terminal, though online FTP clients like FileZilla, WinSCP, and SmartFTP are frequently used as well. Essentially, FTP is just a simple way to transfer large numbers of files efficiently. 

The danger of unauthorized FTP usage is that FTP is not generally a very secure method of transfer. Because it relies on clear-text usernames and passwords for authentication, FTP can be vulnerable to brute force attacks or other various attack methods. Organizations will often set a policy that restricts users on their network from using unauthorized FTP or FTP services in general. This is because unauthorized usage often lacks the visibility the IT or security teams need in order to maintain clear network oversight. By identifying unauthorized usage, security teams can locate potential areas where data leakage could occur as well as any areas in their policy that are not functioning as they should be. 

Identifying Unauthorized FTP Usage using Stamus Security Platform

The enriched hunting interface within the Stamus Security Platform has tools that can help identify unauthorized FTP usage on the network. Let’s look at an example: 

In the past 48 hours, we have had about 1.6 million alert events which have triggered hundreds of thousands of results.

The Hunt for Unauthorized FTP Services

In addition to all these alert events, we have access to over two billion related network protocol transactions in this deployment. Despite this, narrowing down the FTP usage and filtering to see only the end users and clients is easy. By doing so, we can see previously unseen activity - some of which could be malicious. If that is the case, then we are able to see all the needed network forensic artifacts, such as extracted files, for further investigation. 

To start this hunt, we can head to the Host Insights tab. Select the active filters for client service by FTP protocols (as seen on the screenshot below). This will list all Hosts and their relevant network forensics attributes.

It is important to note that SSP enriched hunting also provides additional organization-specific context. Users can filter for queries from various departments or user groups within the organization, allowing them to hyper-focus on specific areas without having to aggregate events or organize IP addresses to find specific users or departments. 

Evidence for Incident Response

With just a few clicks, We are able to view two important sets of evidence: 

• The associated network protocol transactions and flow logs
• Host Insights - a single screen for reviewing 60+ network activity attributes collected for every host

The generated events are already enriched by SSP to include important metadata like DNS records, TLS protocol data containing certificate names, fingerprint JA3/JA3S, connection flow sizes, http user agent, http host, request body, status codes, file transaction info, and more. 

From this screen, we can see a spike of “Sightings” activity, which indicates that this host and their user has generated previously unseen, unique communication on the organization’s network. 

As you can see below, we have switched off any alert events in order to concentrate on the newly discovered network communication artifacts.

We can clearly see the FTP usage by the client, but we need to know more about it. For example, what was transferred and if there are related network forensic artifacts like extracted files. To see this, we select the “ftp” client services and the user “Maggie Simpson” and then switch over to the dashboard to review the event’s network evidence. 

We can immediately see some potentially negative results as well as an accompanying alert. As you can see in the above screenshot, we can also see the extracted file with its corresponding gilemagic and checksum. We need to do some forensic analysis on this to determine potential malicious activity and the TTPs of the offender. 

From the accompanying events details we can also see the clear-text username and password and check to see if they have been seen elsewhere in the organization.

Audit , Traceability, and Scoping the Damage

On the screenshots below we explicitly search for any users that have used FTP services that resulted in any zip files transferred in the clients/users networks:

We were able to find some other cases of Hosts and Users of similar file transfers by reviewing the network transaction logs.

Also more clear text usernames, passwords, and zip file transfers.

Sightings - Finding Patient 0 

It is simple to switch to the Dashboard view and filter for only previously unseen communications coming from end users or clients using FTP services. As seen below, all we have to do is switch off ‘Alerts’ in the Dashboard. 

We can see new, previously unseen HTTP server transactions and encrypted/TLS communications coming from the same clients using FTP services that we previously identified. Data from new TLS servers, SNIs, and certificates that have not been seen before within the organization can be used as Indicators of Compromise (IoCs) to locate Patient 0 and comeplete the scope of damage.  

The metadata generated by the Stamus Security Platform is incredibly rich and reveals important information about the threat. All domains, TLS SNI, IP addresses, HTTP hosts, and more can easily be checked with an external threat intelligence provider such as Virus Total. Encrypted communications can be decoded directly inside the Stamus Security Platform using the Cyberchef integration.

By switching back over to the Hosts tab in the hunting interface, we can see a list of all hosts within those new communications related to the FTP services. 

Furthermore, I would like to review any similar events pertaining to zip files transferred over any clear text FTP applications within the user networks. The hunting filter on the screenshot below would show me exactly that: 

Armed with the above information and evidence, a threat hunter has enough information to generate an Incident Response ticket. 

However, there are still two tasks left to complete: 

1 - We do not want to have to repeat this exact same process again in the future, so we need to set up classification and auto-escalation for future occurrences.
2 - If anything like this has happened before, we want it to be found and escalated with all the associated evidence - all based on historical data.

Classification

In order to streamline the event review/triage process in the future, an experienced analyst can choose to tag/classify the events associated with this filter  By doing so, SSP will tag future events that match the filter criteria as “relevant” or “informational,” depending upon the analyst’s selection. These tags can be used to automate event review/triage and make it easier for a less-experienced analyst to identify events that are relevant for manual review.

To do so, the analyst selects the Tag option from the Policy Action menu on the right hand side menu. This action will cause SSP to insert a tag into each event record as shown below:   

This allows the analyst to easily filter out or search for them in any SIEM (Chronicle, Splunk, Elasticsearch, etc) or data lake using that tag.

It also allows for easy filtering out of those events in the Stamus Enriched Hunting GUI by switching to “relevant” only classified events. 

Escalation and Automation of this Threat Hunt

To set up an automation which causes SSP to escalate past and future occurrences, we can create a Declaration of Compromise (DoC) event from the Policy Actions drop down menu on the right hand side panel in the Stamus Enriched Hunting Interface. 

The next step is to add some explanation about the type of threat. This also gives us a chance to provide informational context and helps convey knowledge to colleagues.

Select options to generate events from historical data and generate Webhook notifications.

Just like that, the hunt and all related activities are complete. Any past or future generated events from that automation will then be further auto-classified and escalated to the desired response process -  via SOAR playbook, chat notification, or incident response ticket.

Conclusion

The post-hunt activities completed in this example are just the tip of the iceberg when it comes to the automation and escalation capabilities of Stamus Security Platform (SSP). To learn more about these features and how to implement them, read our article titled “After the Hunt”. To learn more about Network Detection and Response (NDR) from Stamus Networks and see the enriched hunting interface for yourself, click the button below and schedule a live demo.