The MITRE ATT&CK "Collection" Tactic is Missing Very Important Techniques: Data From a Database (Structured) - Rich Johnson
- 1. 1 Thales Trusted Cyber Technologies The Underappreciated Tactic: Collection D a t a F r om a n I nf or ma t i on R e po si t o ry
- 2. 2 Motivation for this Presentation After reading about cyber security incidents I see focus in the following areas: • Exploits – compromising a system • Phishing attacks leading to initial access • Privilege escalation • Credential access………… • And from the defenders point of view: • Patching • Vulnerability scanning • Encryption • Zero Trust – My Favorite – NOT!!!
- 3. 3 Now you can’t ignore these. They are essential. What they fail to consider (in my humble opinion) is that attackers want to “do something.” In my case…they want to TAKE data.
- 4. 4 Since cyber security attacks DO succeed and data breaches DO occur…..then maybe we need to look at this more closely
- 5. 5 Attackers do have to spend time on…….. Collection Collection
- 6. 6 Attackers do have to spend time on…….. Collection Collection of Data by interception (Adversary in the Middle) Data in transit being sniffed/skimmed/captured Data from existing files • Word Documents, Excel files, DB queries saved as .csv, • Backup database files Emails (stored as files????) What about a Database? (Information from a data repository)
- 7. 7 How Is Database Access Monitored? Database activity can be monitored in two ways: • Native Audit. Most database solutions have a built in logging mechanism. • External Vendor Solution (Disclosure) – external system can be used to record this activity using agents or inline evaluation of SQL activity Another possibility is for the calling application (such as a front end web application) to log the back end database queries.
- 8. 8 What database activity is monitored? Databases provide infinite options for queries and management activities. The DOD Defense Information Systems Agency (DISA) publishes Security Technical Implementation Guidelines (STIGs): The database STIGs give a pretty good list: • Successful and unsuccessful attempts to access, modify, and delete categories (classification) of information • Successful and unsuccessful attempts to access, modify and delete security objects • Enforcement of access restrictions associate with changes to configuration • Successful and unsuccessful attempts to add, modify and delete privileges/permissions • Logins and logouts • Unsuccessful logins • Concurrent logins by same user from different workstations • Unsuccessful access to objects • All direct access (outside of a frontend application such as a web application that it supports)
- 9. 9 The Good, Bad and Ugly of Database Activity Monitoring Good: • Provides a good accounting of the who, what, when, where/how of database access • This accountability can be preventative against insider threats such as disgruntled employees • Just about every database has some form of native audit or add on capability • In many organizations it is a requirement. • Commercial entities may need to perform audit to meet requirements such as SOX, HIPAA, PCI, etc. • Federal government entities usually required per STIG and ATO.
- 10. 10 The Good, Bad and Ugly of Database Activity Monitoring Bad: • Configuring native audit can be technically challenging. Each solution does it differently • The types of audit capability vary from solution to solution • A large organization may have numerous database solutions so enabling audit requires expertise in each solution
- 11. 11 The Good, Bad and Ugly of Database Activity Monitoring And The Ugly: • Database auditing generates more information than is on the database itself! Huge volumes of data! • Hard for typical admin or SOC engineer to make useful due to volume • Audit data is not looked at by many organizations. The focus is on the capturing of audit data (for compliance) than its actual use.
- 12. 12 How do the bad guys do their “Collection”? • In the 2024 version of MITRE ATT&CK enterprise addition, the following are mentioned: • Adminer – a PHP database client. – I’m not sure how you’d run it unless you were on a host that could run code from that runtime environment. • P.A.S. Webshell – I’m not sure this has a built in data client. It might try to access databases via SQL Injection which is more of an application attack • SQLRat – supposedly can run SQL scripts and is used by FIN7
- 13. 13 How do the bad guys do their “Collection”? Other potential methods of collection: • Powershell – many libraries available for connecting to databases and it will be available on most workstations or windows servers. Invoke- SQLcmd commandlet • Python – (and other scripting languages) have many libraries to connect to databases • Command line SQL clients – MySQL client, SQLPlus (Oracle), SQL. • Front end web applications with built in DB clients – if it is a LAMP server (apache/MySQL) for example, a MySQL connector will be on that server. • Small footprint SQL clients built in C/C++
- 14. 14 Detection of “Collection” of Data from Information Repositories The first part of Detection is to record (audit) activity. • Detection DS0015 – Application Log – Focuses on what appears to be file based access. It does give a reference to the use of User-Based Analytics The Collection/Data from Cloud Storage technique looks as if databases could also be a source, let’s look at the detection method: • Detection DS0010 – monitor for unusual queries to cloud provider’s storage service. The description of the technique also references varies types of sensitive data that one might query from a database – PII, credit cards or medical records
- 15. 15 Benefits of examining patterns/methods of Database Access This might fall under User behavioral analytics (UBA) or what is also known as User-Entity Behavioral Analytics (UEBA) mentioned in Detection DS0015 To make use of UEBAs, it is necessary to understand what “normal” activity looks like. Normal activity is sometimes referred to as a “profile” or “profiled activity” Most normal data access from a database will come from a front end application accessing the database via a service account Most access will come directly from the application servers The specific databases and database clients used by users/admins can be profiled The source IPs of users/admins can be profiled Anomalous activity (with regards) to these baselines can be examined for “dangerous” activity
- 16. 16 Examples of Suspicious Events (from Database Audit Records) 1. User accesses database (that he’s never accessed before) and performs very specific query of sensitive data using a service account. • Anomaly: Never accessed database before (by itself this is not significant) • Anomaly: Specific query of sensitive data (not necessarily bad by itself) • Anomaly: Use of service account from non application host (In this case always questionable. By itself it’s just a bad practice) 2. Multiple SQL errors in a short period by user/admin • Anomaly: multiple SQL errors in a row may be indicative of attempt to perform privileged actions by bad actor 3. Specific privileged actions by user/Admin that user has never performed before and inappropriate for role • Anomaly: User uses create assembly command
- 17. 17 Proposed Additional Technique/Subtechniques Data from a relational or Big Data database: Adversaries may leverage relational or big data database solutions to acquire sensitive data. The following is a brief list of example information that may hold potential value to an adversary and may be found in relational or Big Data databases: • Personally Identifiable Information (PII) • Personal Health Information (PHI) • Financial Data • Credit Card Data • Proprietary Data • Personnel Data • Usernames/Passwords • Other sensitive data
- 18. 18 Proposed Additional Techniques/Subtechniques Specific relational and Big Data databases include (but are not limited to) the following: • Oracle • Microsoft SQL Server • MySQL • PostgreSQL • IBM DB2 • MongoDB • AWS Relational Database Service • Azure SQL
- 19. 19 Proposed Additional Techniques/Subtechniques Procedure Examples ID Name Description ID Name Description G0037 Sandworm Team Sandworm Team exfiltrates data of interest from enterprise databases using Adminer
- 20. 20 Proposed Defenses You have to detect first – Look for suspicious activities: It is necessary to distill the audit data to a manageable number of events to examine: • Queries of sensitive data coming from a source other than the normal application server(s) • Any DDL activity against an audit table (or log file such as in MS SQL Server) • Any activity from a user that has been inactive (or accounts that should have been disabled) • And major administrative activity that does not correspond to a change management item (ticketed)
- 21. 21 Proposed Defenses You have to detect first (layer on context): • Improper use of service accounts (accounts that are for an application to use not a person) • Unusual database clients • Time of day • Query size (based on source). Example: large query coming from application (where typical query returns small number of records • Query coming from IP address/workstation not associated with user historically (using UEBA) • Database activity by user (admin) not seen before or against database not seen before (using UEBA)
- 22. 22 Summary/Conclusion Many organizations have a requirement to collect database activity logs (database audit) Most organizations perform this activity to meet some compliance requirement: Government organizations do it in support of an Authorization to Operate (ATO). Commercial organizations do it to comply with a compliance program such as PCI DSS. Security organizations do not look closely at this data as a method to detect attacks in progress/ongoing. The use is more forensic (after the fact). MITRE ATT&CK includes the critical tactic of Collection. However, the nature of databases as well as their ubiquity necessitates a more specific and detailed treatment within the Collection techniques.
- 23. 23 Questions?
- 24. Rich Johnson Principal Sales Engineer (703) 777-7263 [email protected]