BYOB: Bring your own Blackbox - Containerized Defense Evasion on macOS

Colson Wilhoit, a security research engineer at Elastic, explains why an attacker might run a second-stage payload inside a container on macOS. Containers are compact, are not inspected the way scripts or binaries are by Gatekeeper or XProtect, and are common on developer machines, so their activity blends into routine work. Much of what happens inside the container is not visible to the Endpoint Security framework.

Two proofs of concept follow. A Python payload drives the Docker Engine API, starting Docker Desktop headless if needed, pulling a private image, mounting the user keychain and SSH keys, sending them out, and removing all traces in about ten seconds. A Swift payload uses Apple's container framework client APIs on macOS Tahoe to perform the same steps in about two seconds. Wilhoit links the technique to a DPRK-linked intrusion that began on a developer's Mac and to recent red-team research, while noting that those cases built their images on the host.

For defenders, he suggests alerting when non-Docker processes modify Docker settings files, flagging unusual Docker Desktop launches, and watching for XPC connections from non-Apple binaries to container framework services. Collecting Docker logs, using osquery's Docker tables, and baselining normal container use are also recommended. The takeaway is that containers should be treated as part of the endpoint attack surface, since Apple has not yet added container-specific endpoint security events.