Examples of incorrect technique mappings from ATT&CK

Mistakes happen, and we all know this. It could be an implementation that doesn’t work, a lack of knowledge or direction, or a simple mistake that happened purely by accident. The problem is mistakes can have consequences of different sizes, and you don’t typically know what the consequences are until they’ve already occurred. Hopefully, you can learn from some of the mistakes made in our past and use this to make your organization more secure.

For the first example, I think of times when I have tried to overextend resources to cover as many controls as possible, even when it wasn’t likely to be successful. It was a common practice for a while to review any areas and try to implement detection, mitigation, and security controls without thinking of the consequences for the organization, and in the long run, that was an important lesson to learn. It might have started small with over-portioning user access controls to the point that some admin users had four or five different accounts, and the thought process was that there was the separation of duties with the accounts, making it more secure. The reality was that this resulted in very few people using them correctly. I would see a mixture of scenarios. One would be that all the accounts were created but not used, and a single admin account would be used. Another scenario was that passwords or pins would be the same across all accounts. Overall, it led to just as many, if not more, security issues and resentment built up toward the security and auditing teams. As having separate admin accounts that corresponded with roles was poorly implemented, we had to put in place stronger mitigations to ensure that there were proper privileged account management mitigations. Mismanagement of privileged access accounts can correlate to the following MITRE controls:

• T1548: Abuse Elevation Control Mechanism
  • Bypass User Account Control
  • Sudo and Sudo Caching
• T1134: Access Token Manipulation
  • Token Impersonation/Theft
  • Create Process with Token
  • Make and Impersonate Token
• T1098: Account Manipulation
  • Additional Cloud Credentials
  • Additional Email Delegate Permissions
  • Additional Cloud Roles
• T1547: Boot or Logon Autostart Execution: Kernel Modules and Extensions
• T1612: Build Image on Host
• T1059: Command and Scripting Interpreter
  • PowerShell
  • Network Devices CLI
• T1609: Container Administration Command
• T1136: Create Account
  • Local Account
  • Domain Account
  • Cloud Account
• T1543: Create or Modify System Process: Systemd Service
• T1484: Domain Policy Modification
  • Domain Trust Modification
• T1611: Escape to Host
• T1546: Event-Triggered Execution: Windows Management Instrumentation Event Subscription
• T1190: Exploit Public-Facing Application
• T1210: Exploitation of Remote Services
• T1222: File and Directory Permissions Modification
  • Windows File and Directory Permissions Modification
  • Linux and Mac File and Directory Permissions Modification
• T1495: Firmware Corruption
• T1606: Forge Web Credentials
  • SAML Tokens
• T1562: Impair Defenses: Safe Mode Boot
• T1525: Implant Internal Image
• T1056: Input Capture: Web Portal Capture
• T1559: Inter-Process Communication
  • Component Object Model
• T1556: Modify Authentication Process
  • Domain Controller Authentication
  • Pluggable Authentication Modules
  • Network Device Authentication
  • Reversible Encryption
  • Hybrid Identity
• T1601: Modify System Image
  • Patch System Image
  • Downgrade System Image
• T1599: Network Boundary Bridging
  • Network Address Translation Traversal
• T1003: OS Credential Dumping
  • LSASS Memory
  • Security Account Manager
  • NTDS
  • LSA Secrets
  • Cached Domain Credentials
  • DCSync
  • Proc Filesystem
  • /etc/passwd and /etc/shadow
• T1542: Pre-OS Boot
  • System Firmware
  • Bootkit
  • TFTP Boot
• T1055: Process Injection
  • Ptrace System Calls
• T1563: Remote Service Session Hijacking
  • SSH Hijacking
  • RDP Hijacking
• T1021: Remote Services
  • Remote Desktop Protocol
  • SMB/Windows Admin Shares
  • Distributed Component Object Model
  • Windows Remote Management
• T1053: Scheduled Task/Job
  • At
  • Scheduled Task
  • Systemd Timers
  • Container Orchestration Job
• T1505: Server Software Component
  • SQL Stored Procedures
  • Transport Agent
  • IIS Components
• T1072: Software Deployment Tools
• T1558: Steal or Forge Kerberos Tickets
  • Golden Tickets
  • Silver Tickets
  • Kerberoasting
• T1553: Subvert Trust Controls: Code Signing Policy Modification
• T1218: System Binary Proxy Execution
  • Msiexec
• T1569: System Services
  • System Execution
• T1552: Unsecured Credentials
  • Credentials in Registry
  • Container API
• T1550: Use Alternate Authentication Material
  • Pass the Hash
  • Pass the Ticket
• T1078: Valid Accounts
  • Domain Accounts
  • Local Accounts
  • Cloud Accounts
• T1047: Windows Management Instrumentation

As you can see from that long list, privilege access management can be related to a large number of different techniques and sub-techniques, spanning different matrices and tactics. In creating the different admin accounts, the team implementing the access controls was so focused on being compliant with every security technical implementation guide (STIG) at the time that they weren’t practical. If I were to go back in time, I would then recommend that team take the list of the MITRE techniques, filter out the ones for matrices that don’t apply, and then compare the various mitigation and detection tips to make the account changes that would have the most impact. In this case, the practical response would be to have a separate end user and admin account or have a way to temporarily grant admin permissions based on the use case and have sufficient logging enabled to be able to review for misuse. This solution can be done in various ways, for example, using tools such as Allowance, which can grant admin access to authorized users for 24 hours. Again, this is one solution that I’ve used in environments in the past, and not all solutions to mistaken mappings will work for you.

Another scenario where we clearly over-complicated work instead and ended up creating more problems by not mapping and implementing controls in a way that made sense was a few years ago when we expanded our network detection and response capabilities. To do so, we needed to increase visibility. We essentially took on too many steps of utilizing a network defense and response tool, implementing SSL Decrypt for most traffic, and creating our own alerts, among other steps. At first glance, all of this sounds good; it provides visibility and alerting, but we had half-implemented projects because we were trying to do too much at once. For example, SSL Decrypt works if you are on the company network or the company VPN but we found that most users used their personal devices to conduct work unless absolutely necessary to be on their company endpoints. Similarly, we spread ourselves too thin by creating alerts, resulting in higher levels of false positives. Then, even when SSL Decrypt was put in place, many categories for data were not decrypted, and we would see malicious traffic use those categories fraudulently to ensure their traffic was still encrypted. That also rendered some of the alerts useless. Our strategy of doing as much as possible because the MITRE Framework can relate to the mitigation for the following techniques and sub-techniques:

• T1557: Adversary-in-the-Middle
  • LLMNR/NBT-NS Poisoning and SMB Relay
  • ARP Caching Poisoning
  • DHCP Spoofing
• T1071: Application Layer Protocol
  • Web Protocols
  • File Transfer Protocols
  • Mail Protocols
  • DNS
• T1132: Data Encoding
  • Standard Encoding
  • Non-Standard Encoding
• T1602: Data from Configuration Repository
  • SNMP (MIB Dump)
  • Network Device Configuration Dump
• T1001: Data Obfuscation
  • Junk Data
  • Steganography
  • Protocol Impersonation
• T1030: Data Transfer Size Limits
• T1568: Dynamic Resolution
  • Domain Generation Algorithms
• T1573: Encrypted Channel
  • Symmetric Cryptography
  • Asymmetric Cryptography
• T1048: Exfiltration Over Alternative Protocol
  • Exfiltration Over Symmetric Encrypted Non-C2 Protocol
  • Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
  • Exfiltration Over Unencrypted Non-C2 Protocol
• T1041: Exfiltration Over C2 Channel
• T1008: Fallback Channels
• T1105: Ingress Tool Transfer
• T1570: Lateral Tool Transfer
• T1104: Multi-Stage Channels
• T1046: Network Service Discovery
• T1095: Non-Application Layer Protocol
• T1571: Non-Standard Ports
• T1566: Phishing
  • Spearphishing Attachment
• T1542: Pre-OS Boot
  • ROMMONkit
  • TFTP Boot
• T1572: Protocol Tunneling
• T1090: Proxy
  • Internal Proxy
  • External Proxy
• T1219: Remote Access Software
• T1029: Scheduled Transfer
• T1221: Template Injection
• T1204: User Execution
  • Malicious Link
  • Malicious Image
• T1102: Web Service
  • Dead Drop Resolver
  • Bidirectional Communication
  • One-Way Communication

Looking over the list of mitigations (and there are even more), when it comes to implementing network detection and response efforts, you can clearly tell that there are a lot of areas that can add value in the realm of making your environment more secure, but trying to attempt all types of mitigation at once doesn’t make sense and, if anything, leads to you having your attention divided to the point where you are more likely to miss something or make a mistake with implementing the tools or even choosing tools that aren’t the best for your environment. Instead, ensure that you analyze the controls you want to be implemented, determine how to create the mitigations and detections, then prioritize them so you don’t try to tackle too many at once.

You should always strive to have common sense security measures in place because if you create controls that consistently make work harder, fewer and fewer people are going to follow those controls, but if you create controls that will change some workflows, don’t add too much pain, and can get the point across about them through demonstrative security, then more people are likely to follow them. You also want to prioritize what controls you need to focus on and then make a plan based on the level of effort, the implementation, and potential pitfalls. A comprehensive plan will lead to a higher level of success for correct mapping to techniques and a higher level of success for correct implementation.