Track invalid user login attempts OS X

Thank you for pointing me in the right direction. I was able create a Swift class to handle the whole process except for setting up the auditpipe. I had to do that in an Objective-C class.

I wasn't sure how to port "AUDITPIPE_SET_PRESELECT_MODE" and a few of the other macros to swift. Ie

ioctl(fileDescriptor_AuditPipe, AUDITPIPE_SET_PRESELECT_MODE, &mode)

I'm now able to proprly track authentication events from the loginwindow and the fingerprint sensor. 🙂

I wasn't sure how to port

AUDITPIPE_SET_PRESELECT_MODE

and a few of the other macros to swift.

Right. Swift’s C importer can handle many simple macros but it can’t cope with something as complex as

AUDITPIPE_SET_PRESELECT_MODE

// In the `.h`:

extern unsigned long QAUDITPIPE_SET_PRESELECT_MODE;

// In the `.c`:

unsigned long QAUDITPIPE_SET_PRESELECT_MODE = AUDITPIPE_SET_PRESELECT_MODE;

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Seems so obvious now :facepalm: I'll probably do this.

Thanks again for the help!

Due to the audit subsystem being deprecated and now disabled in Sonoma, I am now moving towards using EndpointSecurity API to track invalid logins.

I've been able to use the SampleEndpointApp to track ES_EVENT_TYPE_NOTIFY_AUTHENTICATION events. While waiting for approval for the EndpointSecurity entitlement, I've disabled SIP/AMFI on some test VMs.

While doing some experimenting, I've noticed that the event message is not consistent across different macOS versions.

For example, to capture user login attempts (valid or invalid), I was initially looking at the ES_EVENT_TYPE_NOTIFY_AUTHENTICATION message on macOS 14. Here, I can see that when looking inside:

msg->event.authentication->data.od->instigator
or 
msg->event.authentication->data.touchid->instigator

I am able to discern if it is a matching event if the signing ID or executable is from the authorizationhost or coreauthd similar to what I looked for in the auditpipe. (I used a test device with macOS 14 and eslogger to verify the touchID part)

However, on macOS 13, the data.od->instigator information is different. It is instead coming from loginwindow. I tried looking at the msg version/schema_version, but they match in both versions of macOS. So, my thought is, I can just ignore macOS 13 and only use the EndpointSecurity API if it is macOS 14 or newer (auditpipe still works on macOS 13 without having to re-enable the audit subsystem). But, my question now is, how likely is the instigator going to change in future versions of macOS? Am I going to need to re-examine this info for each subsequent release of macOS and add more conditions when checking for the desired events?

I also looked into using the new ES_EVENT_TYPE_NOTIFY_AUTHORIZATION_JUDGEMENT in macOS 14, however, it does not produce an event when an invalid touch ID event occurs. (It also is not apparent how to distinguish between a valid touch id authentication vs a password authentication from the authorization_judgement event msg). So, I've decided to stick to ES_EVENT_TYPE_NOTIFY_AUTHENTICATION events for now.