T1030- Testing Data Transfer Limit Sizes

As a former security analyst, I worked diligently to assure that our defenses were strong and any gaps were closed. This was an ongoing process that seemed never ending. The looming threat was ransomware but it was not the only threat. There are many scenarios where data exfiltration can occur: Ransomware, insider threats, trojans and other malicious activities.

SSL/TLS traffic is continuous and necessary for business functions. Both uploads and downloads are required for users to perform their daily tasks. 

As any good Blue Team would, I often pondered these questions:

• How can we devise policies that will detect data uploaded via port 443.
• Should we block FTP and HTTP egress traffic and build specific allow policies to reduce risk of exfiltration?
• Should we create policies to inspect encrypted and/or compressed files?
• How can we use SSL Inspection for egress (outbound North/South) traffic without slowing transmissions? 
• What are the indicators that data is being exfiltrated maliciously 
• What methods can be used to test these detections?
  

In a previous blog, Exfiltration via C2 Channel, I discussed how the Blue Team can test DLP applications and policies using a Compound Action from SCYTHE’s Community Threats Github Repository. 

In this blog, I will discuss how SCYTHE can be used to test detection of data exfiltration by testing data transfer limits. Our friends at MITRE ATT&CK® have defined ID:T1030 Data Transfer Size Limits as:

An adversary may exfiltrate data in fixed size chunks instead of whole files or limit packet sizes below certain thresholds. This approach may be used to avoid triggering network data transfer threshold alerts.

This technique is in the Enterprise matrix, under the Exfiltration Tactic.

Detection and alerting of data exfiltration, by the SOC, DLP application, and firewall is critical but also difficult when files are transmitted through allowed ports such as port 443. If the data is encrypted, it is even more difficult to detect content unless the security applications are decrypting all SSL traffic and can inspect the content. 

SCYTHE has the functionality to test data exfiltration with varying file size. This is accomplished by increasing the file sizes on multiple tests. Red Teams can utilize data exfiltration as part of a Ransomware test or testing a Firewall policies. Blue Teams can review the results of these campaigns and fine tune their detection systems to ensure that egress (outbound) traffic containing large data packets properly triggers alerts.

Testing can be done by using a campaign that sends test data in smaller, timed chunks to mimic a malicious exfiltration. It can also be done in larger chucks if desired. 

Setup a SCYTHE Server in the Cloud

In order to test egress traffic and detections of firewall and other network perimeter security controls, a SCYTHE server must be set up in a cloud environment. The primary requirement is that the test endpoint must be able to communicate with the SCYTHE server. 

NOTE: If the SCYTHE server is internet facing, it is critical to set up an ACL that is locked down and only allows access to the test endpoints and administrators.

This test could be used in conjunction with testing Domain Fronting. Derek Johnson, a SCYTHE partner, wrote a detailed blog, about setting up Domain Fronting and utilizing SCYTHE. 

Import the Compound Action

SCYTHE’s new compound action: T1030-Testing Data Transfer Limit Sizes was created with this in mind.

1. Download the JSON file from SCYTHE’s Community Threats Github Repository. 
2. Import into the Threat Catalog of your SCYTHE cloud instance. 
3. Tag the new threat with MITRE ATT&CK Technique ID: T1030

Create a Campaign

1. Select the Threat> Scroll to the bottom and click Create Campaign from Threat. 

2. Parameters: Change the Campaign Platform Address ( --cp <IP address> ) to your SCYTHE server IP address. 

A) Five 1 GB files are downloaded to the test endpoint’s desktop (namedTest_file.xls) 

B) Test files are then uploaded to the SCYTHE server.

C) The files are deleted from the host’s desktop. 

3. The campaign can be customized by adding changing steps or adding in additional steps:

A) Add heartbeat and jitter (parameters). 

B) Change the file size (smaller than 1 GB but not larger)

• Example: Edit Step 2  - click the edit button to the right. 

• Change the --size and/ or --count then click update.

C) Changing file type or name.

• Using the example above, change the file type or file name. 

Note: Changing the configuration of step 2 will require revisions in the other steps. For example, changing file names requires the same file name for the uploader and delete steps. Changing the number of files created will require addition or removal of uploader steps to match the number of files created. 

D) Add delays between file uploads.

• Scroll to Delays> select delay time
• Drag and drop where you want them placed, in between steps. 
• Delays can be stacked

Blue Team Fine Tuning

The .CSV report may be the most useful to the Blue Team to determine the time the data was uploaded and when steps occurred. The CSV report contains process IDs and timestamps. They can correlate  the logs using the previous report information and create policies for this type of egress traffic.

My suggestion would be that once the Blue Team has found the logs for the first campaign, it should be run again with different file sizes or an increased number of files. This can be repeated until the Blue Team has determined what the threshold is and has tuned their alerting. 

This type of tuning will not close the gap on the content of encrypted data being exfiltrated but it can close the gap on large files being exfiltrated without the Blue Team’s knowledge. 

About the Author

Elaine Harrison-Neukirch has over 10 years of experience in cyber security working in the healthcare and financial services industries. She currently runs the customer support program at SCYTHE. Elaine loves giving back to the community and volunteers for the Cyber Security Non Profit (CSNP.org) and has written several blogs for them. Elaine advocates for Women in Cybersecurity; she is a member of both Women in Cybersecurity and Women’s Society of Cyberjitsu. Elaine has multiple certifications including CEH, Security + and Cyberops CCNA.

‍