{ "id": "a1d7dcb9-d1d7-46de-bd88-b47935175f6f", "created_at": "2026-04-06T00:19:59.763198Z", "updated_at": "2026-04-10T03:32:26.569261Z", "deleted_at": null, "sha1_hash": "360394f33e3e2f99029aa4cd8fae22bad3ef8ae2", "title": "Checks on executable code in Catalina and Big Sur: a first draft", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 228643, "plain_text": "Checks on executable code in Catalina and Big Sur: a first draft\r\nPublished: 2020-11-16 · Archived: 2026-04-05 17:48:08 UTC\r\nAll eyes have turned to the checks that recent versions of macOS make when preparing to load and run executable\r\ncode. To date, as far as I can see, there are disparate accounts of what have been considered certificate and\r\nnotarization checks, and a few marginal notes about changes when running native code on Apple Silicon Macs.\r\nWhat I attempt in this article is a coherent account of how macOS checks executable code before it’s loaded and\r\nrun, in macOS 10.15 and 11.0. This is my first draft, so please bear with my errors and help me correct them to\r\nbuild a more accurate picture. You can see my external sources listed at the end, to which you can add a\r\nsuccession of my own articles here.\r\nThese processes don’t just occur when you open an app, but also when any other executable code is loaded, for\r\nexample when using a command tool, or when running code needs to load an executable from another source such\r\nas a dylib. I’m not going to consider the loading of code contained within the protected System volume, or that\r\nsigned by Apple, and that run in sandboxed apps supplied from the App Store may also differ in parts. I’m also\r\ngoing to ignore the handling of code for Intel architecture on Apple Silicon Macs, which involves its translation by\r\nRosetta 2.\r\nCode signing\r\nThere’s an important difference between loading natively executable code on Intel and Apple Silicon Macs: the\r\nformer allows code to be completely unsigned, but the latter refuses to load ARM code which isn’t signed at all.\r\nHowever, that requirement is enforced not to establish any chain of trust from its signing certificate (using an ad\r\nhoc certificate is sufficient), but so that the cdhashes created during the signing process are available.\r\nHas this code been run before?\r\nThe first question to be answered is whether this copy of macOS has run this code before. To determine that, if the\r\ncode is signed its hash is looked up in the cdhashes created during the signing process. If there are no cdhashes\r\n(because the code is unsigned), then macOS has to compute its hash on the fly. That takes time, particularly if this\r\nis a large app, so Apple Silicon Macs attain superior performance by refusing to compute the hash of native code,\r\nso block its loading. The code signing requirement on Apple Silicon Macs is therefore to eliminate the first run\r\ndelays which many have noticed on Intel Macs running Catalina. Although a minor nuisance for some users, this\r\nshould hasten app launch and execution.\r\nArmed with the hash for the code to be run, this is looked up in the local security database, which establishes\r\nwhether that code has been run before. If it has, checks move on to examine the code signature.\r\nIf this is the first time that code with that hash has been run, the hash is added to the local security database, and\r\nthat hash is sent to Apple via a connection to api.apple-cloudkit.com. This has been thought to relate to\r\nnotarization, but I don’t think has anything to do with that. At the least, Apple collects hashes as they’re\r\nencountered, and appears to look them up in a database of known malware (see below).\r\nhttps://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/\r\nPage 1 of 4\n\nIs it signed using a developer certificate?\r\nCode which hasn’t been signed using a developer certificate now can’t be checked any further, except by routine\r\nchecks in XProtect to see if it is known malware and should be blocked. Otherwise, it is now loaded and run.\r\nWhere a developer certificate has been used to sign that code, the second question to be answered is whether that\r\ncertificate is still valid. Before macOS 10.14, this appears to have been handled locally by lookup in the\r\n‘Gatekeeper’ database. However, that was only updated periodically, so revoked signatures could still be accepted\r\nfor a couple of weeks after they were known to have been compromised. Apple appears to have changed this\r\nsystem over a year ago, and at least in Catalina and later, now checks the validity of certificates online with its\r\nown servers at ocsp.apple.com.\r\nThis process uses the well-known OCSP protocol, in which the Mac queries the status of the developer certificate\r\nthrough that certificate’s ID. To prepare for the check, macOS therefore extracts that ID. Because online checking\r\ntakes time, this isn’t performed on signatures which have been checked recently: before Apple’s server problems\r\nlast week, results were cached for a period of 5 minutes; this appears to have been extended to 12 hours now, so\r\nshould only occur the first time that you run an app each day.\r\nIf the local OCSP cache doesn’t contain a sufficiently recent result for that certificate ID, macOS sends an OCSP\r\nquery to establish the status of that certificate. If that reports the certificate should be accepted, the executable\r\ncode is given a clean bill of health, loaded and run. If the OCSP service reports that certificate has been revoked,\r\nthen the code is blocked.\r\nI have drafted a first proposal of how these processes integrate, shown here:\r\nhttps://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/\r\nPage 2 of 4\n\nYou can download this as a PDF from here: SignatureCheck1015a\r\nHow can you block transfer of information?\r\nhttps://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/\r\nPage 3 of 4\n\nChecking whether executable code can be run is a fundamental part of your Mac’s security. Apple can and does\r\nrevoke certificates because they’re being abused by malicious software. If you were to prevent OCSP checks on\r\nsignatures, you could end up running known malware whose certificate has already been revoked. Interfering with\r\nthese checks thus has serious consequences, and shouldn’t be considered unless you have a really compelling\r\nreason, and have assessed the security risk of the consequences.\r\nFor a very few Mac users, such as journalists who work in hostile environments where state security services may\r\nbe monitoring them, the OCSP exchange and transmission of new hashes could conceivably be used against them.\r\nThere are solutions which should be able to mitigate against that. For instance, provided that an app has already\r\nbeen run and its cdhashes entered into the local security database, no repeated copies of those hashes should be\r\nsent to api.apple-cloudkit.com.\r\nMuting the OCSP query is just as simple. It can’t occur when the code isn’t signed, so stripping an app’s signature\r\nwill ensure that no query can be sent. However, unsigned code can’t be run on Apple Silicon Macs, and on both\r\narchitectures its integrity can’t be checked either. For specific apps whose use might be sensitive, one approach is\r\nto strip any developer signature and replace it with an ad hoc signature. That isn’t technically difficult at all using\r\ncodesign , and used only on specific apps shouldn’t increase security risk significantly.\r\nHow is it changing?\r\nExceptionally, Apple has responded strongly to recent concerns about online checks being made on executable\r\ncode (see link below). This confirms that the hash lookup performed with api.apple-cloudkit.com does involve\r\nverifying “if an app contains known malware”, and certificate revocation checks with ocsp.apple.com as described\r\nabove.\r\nFor those concerned with protecting their privacy, Apple makes it clear that “these security checks have never\r\nincluded the user’s Apple ID or the identity of their device”, and that it has stopped logging IP addresses.\r\nFurthermore, it states that certificate revocation checks will change in the next year to feature:\r\n“a new encrypted protocol”;\r\n“strong protections against” [OCSP] “server failure”;\r\n“a new preference for users to opt out of these security protections”, which presumably means both hash\r\nlookup and certificate revocation checks.\r\nI will report on those changes as and when they occur.\r\nKey external sources:\r\nApple’s updated account of ‘Gatekeeper’ checks, including details of intended changes,\r\nJeff Johnson on OCSP checks,\r\nJeff Johnson on hash reporting,\r\nJacopo Jannone has an excellent account of the OCSP checks.\r\nSource: https://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/\r\nhttps://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://eclecticlight.co/2020/11/16/checks-on-executable-code-in-catalina-and-big-sur-a-first-draft/" ], "report_names": [ "checks-on-executable-code-in-catalina-and-big-sur-a-first-draft" ], "threat_actors": [ { "id": "9de1979b-40fc-44dc-855d-193edda4f3b8", "created_at": "2025-08-07T02:03:24.92723Z", "updated_at": "2026-04-10T02:00:03.755516Z", "deleted_at": null, "main_name": "GOLD LOCUST", "aliases": [ "Anunak", "Carbanak", "Carbon Spider ", "FIN7 ", "Silicon " ], "source_name": "Secureworks:GOLD LOCUST", "tools": [ "Carbanak" ], "source_id": "Secureworks", "reports": null }, { "id": "cfdd35af-bd12-4c03-8737-08fca638346d", "created_at": "2022-10-25T16:07:24.165595Z", "updated_at": "2026-04-10T02:00:04.887031Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "Cosmic Wolf", "Marbled Dust", "Silicon", "Teal Kurma", "UNC1326" ], "source_name": "ETDA:Sea Turtle", "tools": [ "Drupalgeddon" ], "source_id": "ETDA", "reports": null }, { "id": "33ae2a40-02cd-4dba-8461-d0a50e75578b", "created_at": "2023-01-06T13:46:38.947314Z", "updated_at": "2026-04-10T02:00:03.155091Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "UNC1326", "COSMIC WOLF", "Marbled Dust", "SILICON", "Teal Kurma" ], "source_name": "MISPGALAXY:Sea Turtle", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "62b1b01f-168d-42db-afa1-29d794abc25f", "created_at": "2025-04-23T02:00:55.22426Z", "updated_at": "2026-04-10T02:00:05.358041Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "Sea Turtle", "Teal Kurma", "Marbled Dust", "Cosmic Wolf", "SILICON" ], "source_name": "MITRE:Sea Turtle", "tools": [ "SnappyTCP" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434799, "ts_updated_at": 1775791946, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/360394f33e3e2f99029aa4cd8fae22bad3ef8ae2.pdf", "text": "https://archive.orkl.eu/360394f33e3e2f99029aa4cd8fae22bad3ef8ae2.txt", "img": "https://archive.orkl.eu/360394f33e3e2f99029aa4cd8fae22bad3ef8ae2.jpg" } }