Home/ATT&CK Technique/Gatekeeper Bypass
ATT&CK Technique

Gatekeeper Bypass

T1553.001 · defense-impairment

Adversaries may modify file attributes and subvert Gatekeeper functionality to evade user prompts and execute untrusted programs. Gatekeeper is a set of technologies that act as layer of Apple’s security model to ensure only trusted applications are executed on a host. Gatekeeper was built on top of File Quarantine in Snow Leopard (10.6, 2009) and has grown to include Code Signing, security policy compliance, Notarization, and more.

Gatekeeper also treats applications running for the first time differently than reopened applications. Based on an opt-in system, when files are downloaded an extended attribute (xattr) called com.apple.quarantine (also known as a quarantine flag) can be set on the file by the application performing the download. Launch Services opens the application in a suspended state.

For first run applications with the quarantine flag set, Gatekeeper executes the following functions: 1. Checks extended attribute - Gatekeeper checks for the quarantine flag, then provides an alert prompt to the user to allow or deny execution. 2. Checks System Policies - Gatekeeper checks the system security policy, allowing execution of apps downloaded from either just the App Store or the App Store and identified developers. 3.

Code Signing - Gatekeeper checks for a valid code signature from an Apple Developer ID. 4. Notarization - Using the api.apple-cloudkit.com API, Gatekeeper reaches out to Apple servers to verify or pull down the notarization ticket and ensure the ticket is not revoked. Users can override notarization, which will result in a prompt of executing an “unauthorized app” and the security policy will be modified.

Adversaries can subvert one or multiple security controls within Gatekeeper checks through logic errors (e.g. Exploitation for Stealth), unchecked file types, and external libraries. For example, prior to macOS 13 Ventura, code signing and notarization checks were only conducted on first launch, allowing adversaries to write malicious executables to previously opened applications in order to bypass Gatekeeper security checks.

Applications and files loaded onto the system from a USB flash drive, optical disk, external hard drive, from a drive shared over the local network, or using the curl command may not set the quarantine flag. Additionally, it is possible to avoid setting the quarantine flag using Drive-by Compromise.

macOS
▸

Atomic Tests

1
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
shmacosGatekeeper Bypass
Gatekeeper Bypass via command line 
xattr -d com.apple.quarantine #{app_path}
▣

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1038Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions.

Application Control
  • Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution.
  • Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.
xml"`) Script Blocking
  • Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources.
  • Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g.
, Set-ExecutionPolicy AllSigned) Executable Blocking
  • Use Case: Prevent execution of binaries from suspicious locations, such as %TEMP% or %APPDATA% directories.
  • Implementation: Block execution of .exe, .bat, or .ps1 files from user-writable directories.
Dynamic Analysis Prevention
  • Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time.
  • Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.
◈

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 1
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
▣

Comply & Defend

NIST 800-53CM-02, CM-06, CM-07, SI-04, SI-07, SI-10
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin