Event type for login failure

Hi,

How can we filter logs related to authentication failure across all log sources. We can see authentication activities using metadata.event_type="USER_LOGIN" but this contains overall login activities not just success and failure

Solved Solved
0 4 169
1 ACCEPTED SOLUTION

The best place to start would be the base search like this:

metadata.event_type = "USER_LOGIN" and security_result.action = "BLOCK"

Like metadata.event_type, security_result.action is an enumerated field so there are a fixed set of values allowed. These include 

 

Enum Value Enum Number Description
ALLOW 1 Allowed.
ALLOW_WITH_MODIFICATION 3 Strip, modify something (e.g. File or email was disinfected or rewritten and still forwarded).
BLOCK 2 Blocked.
CHALLENGE 6 Challenged (e.g. the user was challenged by a Captcha, 2FA).
FAIL 5 Failed (e.g. the event was allowed but failed).
QUARANTINE 4 Put somewhere for later analysis (does NOT imply block).
UNKNOWN_ACTION 0 The default action.

https://cloud.google.com/chronicle/docs/reference/udm-field-list#securityresultaction

Hopefully this gets you going in the right direction!

 

View solution in original post

4 REPLIES 4

The best place to start would be the base search like this:

metadata.event_type = "USER_LOGIN" and security_result.action = "BLOCK"

Like metadata.event_type, security_result.action is an enumerated field so there are a fixed set of values allowed. These include 

 

Enum Value Enum Number Description
ALLOW 1 Allowed.
ALLOW_WITH_MODIFICATION 3 Strip, modify something (e.g. File or email was disinfected or rewritten and still forwarded).
BLOCK 2 Blocked.
CHALLENGE 6 Challenged (e.g. the user was challenged by a Captcha, 2FA).
FAIL 5 Failed (e.g. the event was allowed but failed).
QUARANTINE 4 Put somewhere for later analysis (does NOT imply block).
UNKNOWN_ACTION 0 The default action.

https://cloud.google.com/chronicle/docs/reference/udm-field-list#securityresultaction

Hopefully this gets you going in the right direction!

 

Thanks @jstoner . That did point in the right direction. I am assuming all the logs parsed by default parser are going to have same fields and if not we will be able to leverage parser extension for it?

So each log type has its own parser but there is a default parser for each log type. The usage guide (https://cloud.google.com/chronicle/docs/unified-data-model/udm-usage) in addition to the field list referenced above provides fields and guidance around the fields that will be populated. The usage guide calls out specific fields for each event_type but don't cover all the possible fields. If you find that the default parser for a specific log type doesn't have every field you want or you want to manipulate a certain field into another field within the UDM schema, a parser extension can then be leveraged that is unique to your tenant to accomplish this. Hope that helps!

->You can look for auth type to differentiate between system login or login's through any another source.

iamviking_0-1710878485573.png

->Choose the right event ID

Windows 4768 A Kerberos authentication ticket (TGT) was requested
Windows 4769 A Kerberos service ticket was requested
Windows 4770 A Kerberos service ticket was renewed
Windows 4771 Kerberos pre-authentication failed
Windows 4772 A Kerberos authentication ticket request failed
Windows 4773 A Kerberos service ticket request failed
Windows 4774 An account was mapped for logon
Windows 4775 An account could not be mapped for logon
Windows 4776 The domain controller attempted to validate the credentials for an account
Windows 4777 The domain controller failed to validate the credentials for an account
Windows 4820 A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions

->Check for action status

iamviking_1-1710878756032.png

Allowed are successful events and blocked are failure events, if you want to drilldown more you can user error codes further to identify such cases