Prevent In-Memory Code Execution
Block dyld from loading code via NSCreateObjectFileImageFromMemory temp files, raising the bar for in-memory execution and reflective loaders.
Idea
Executing new code out of memory instead of on disk has been part of a stealthy attacker's playbook for decades. A few years ago, Apple changed the macOS dynamic loader (dyld) to disable in-memory code loading and always write a temporary file to disk instead. These files match the pattern NSCreateObjectFileImageFromMemory-*, and we can use Workshop and Santa's FAA rules again to prevent this attack while allowing legitimate applications that require it.
Solutions
- Paths
- •
- Policy
- Custom Message
Mitre Attack
Tactics
Techniques
Tags
Deployment Notes
This is not a silver bullet, however. There are still some ways to circumvent this file creation and load payloads in memory by writing your own reflective loader or recompiling old versions of dyld. We still think this has value as blocking the basic technique raises the complexity of an attack and only an extremely small number of applications use this technique legitimately.
False Positive Guidance
Very few legitimate applications use in-memory code loading. If you encounter false positives, add exceptions for specific applications by their signing ID.