ATP Query to find an event ID in the security log

AFAIK this is not possible. This is not how Defender for Endpoint works. Events are locally analyzed and new telemetry is formed from that. It does not send all the raw ETW events to the backend (as that would actually be something totally different and may overload endpoints). It's doing some magic on its own and you can only query its existing https://docs.microsoft.com/en-US/microsoft-365/security/mtp/advanced-hunting-schema-tables?view=o365-worldwide

So there is no way to get raw access for client/endpoints yet, except installing your own forwarding solution (e.g. Splunk UniversalForwarder, e.g. WEC/WEF -> e.g. analyze in SIEM) on these clients or by installing https://docs.microsoft.com/en-US/azure/azure-monitor/platform/log-analytics-agent - the Microsoft Monitoring Agent (MMA) additionally (e.g. analyze in Loganalytics Workspace). The same approach is done by Microsoft with Azure Sentinel in the schema https://docs.microsoft.com/en-US/azure/azure-monitor/reference/tables/securityevent. Until today, the builtin Defender for Endpoint sensor does not allow raw ETW access using Advanced Hunting nor forwards them.

Microsoft tries to get upfront on each detection theirselfs, so you would always have the kind of logic you are trying to archieve, doing on their cloud/ML-backend already and then forming a new incident/alert from you from these various raw ETW sources, they may have seen and updated in the agent. Thats why Microsoft is currently also so powerful with Defender, cause the telemetry they have, allows to build an unbelievable good amount of detection sets and sequences ;-). So I think at some point you don't need to regulary go that deep, only when doing live-forensic maybe. Like use the Response-Shell builtin and grab the ETWs yourself. Atleast, for clients. No need forwarding all raw ETWs.

Defender for Identity allows what you are trying to archieve, as it allows https://docs.microsoft.com/en-US/defender-for-identity/configure-windows-event-collection

This can be https://docs.microsoft.com/en-US/defender-for-identity/configure-event-forwarding. But thats also why you need to install a different agent (Azure ATP sensor). Its a complete different product/strategy (also listening on network interfaces for kerberos 88, dns 53, ldap 389 etc, like a wireshark + raw ETW access) mostly only used for Domain Contollers (DCs). But this needs another agent and is not meant to be used for clients/endpoints TBH. You can also forward these events to an SIEM using https://docs.microsoft.com/en-US/defender-for-identity/cef-format-sa Again, you could use your own forwarding solution on top for these machines, rather than doing that.

I think this should sum it up until today, please correct me if I am wrong.