09-29-2020 06:06 PM
09-29-2020 06:06 PM
According to the link https://docs.microsoft.com/en-us/azure-advanced-threat-protection/cef-format-sa Azure ATP is capable of sending events in CEF format when sending logs to a Syslog server, however, many events come without being formatted in that way.
<36>1 2020-09-18T01:31:27.936158+00:00 SERVERNAME CEF 5424 EnumerateSessionsSecurityAlert 0|Microsoft|Azure ATP|2.126.8634.25312|EnumerateSessionsSecurityAlert|User and IP address reconnaissance (SMB)|5|start=2020-09-18T01:28:38.7486210Z app=SrvSvc shost=hostname msg=username (domain) on hostname enumerated SMB sessions on target_host, retrieving recent IP addresses of 10 accounts. externalId=2012 cs1Label=url cs1=https://vuw-production.atp.azure.com/s... cs2Label=trigger cs2=new
As can be seen in the redacted message, the msg field contains the username and domain, but there is no suser field, nor a domain field.
The same problem afftects other alerts as well.
I would like to have those fields in a standardised way.
09-30-2020 01:53 AM
@Rodrigo Carneiro , Some alerts are computer based, and some are user based, so you will get either shost or suser.
in this case, the alert is computer based, so you are getting shost.
the message is more dynamic, in this case, you had only one user involved , so it mentioned it's name. but it's a private case, in the generic case for this alert, there could be more then one, in which case the dynamic text would say "3 accounts" instead of a specific name, and this is not something you want inside suser...
09-30-2020 06:56 PM
Hi @Eli Ofek, thanks for your response.
I understand the messages are dynamic, and it is great because they give you some context before you dig deep into the problem, but they only work well if you are in the AATP console. If you need them for an automated action, then they are not very helpful.
For example, in this specific case I would suspect the account was compromised and I would act to prevent further compromise originating from the account. But I can only do that automatically if I can see who did what, and although there was a user associated with that alert I couldn't do much.
It would be great to receive a syslog message where all the fields are present, regardless of the alert type. That way we could extract the fields and process them in a way that automatic remediation actions are possible.
10-01-2020 12:13 AM
@Rodrigo Carneiro I see your point, but how would you suggest to send an array of accounts (in some cases can be thousands) in CEF format ? The 2 available format are one machine and many users or one users with many machines.
You can know which is which by checking if you have the suser or the shost field in the payload...
10-01-2020 02:16 PM - edited 10-02-2020 12:39 AM
I would suggest to not use an array and treat each detection as a separate syslog message, as it currently happens to other Microsoft Security products, like DATP, MCAS, etc.
The alerts in the console don't need to be affected and should continue to be dynamic as they are part of the same incident (if related), but the syslog messages would be more useful for an automated response as they would allow actions on both the suser and shost (if present).
10-05-2020 03:18 PM - edited 10-05-2020 03:23 PM
But they are new alerts anyway, aren't they? But that doesn't mean they are not part of the same incident.
The gui allows you to select to be notified when A new security alert is detected and An existing security alert is updated. Why not the same for syslog messages including these fields?
10-05-2020 03:28 PM
@Rodrigo Carneiro in AATP the term alert and incident are the same, but for a computer based alert, additional user accounts won't open a new alert (new alert id), it will be the same alert with more data added to it (relevant user entities).
marking syslog with updates will send you updates when new entities are added I believe.
10-05-2020 04:05 PM
10-05-2020 07:08 PM - edited 10-06-2020 04:55 PM
Another example. The alert below does show the suser field, but where is the domain field?
<36>1 2020-10-04T12:24:47.624590+00:00 SERVERNAME CEF 5896 PassTheTicketSecurityAlert 0|Microsoft|Azure ATP|2.128.8682.7486|PassTheTicketSecurityAlert|Suspected identity theft (pass-the-ticket)|5|start=2020-10-04T10:09:52.9072060Z app=Kerberos suser=useraccount msg=An actor took Shang**** (Thesis Student)'s Kerberos ticket from SURFACE**** and used it on MACBOOK**** to access ***** (HTTP). externalId=2018 cs1Label=url cs1=https://vuw-production.... cs2Label=trigger cs2=new
10-14-2020 08:14 AM - edited 10-14-2020 08:15 AM
@Rodrigo Carneiro , Pass the ticket is a user based alert, so you get suser.
we only send samName there, no domain info indeed.
This feature was designed to alert, and provides a link to the full alert in the portal where you can see all the details. it wasn't designed to allow automation.
If you aim for automation, I suggest to go another path, if you upgraded to the new user experience with cloud app security, you have the option to get full alert data using graph API, and I am pretty sure you get can there the full ideas of both the computer and user accounts...
The syslog message can be a trigger to go to graph and get the full details from there, and then you can try and build automation on top of it.
Adding @Or Tsemah from product to the thread , as he might be interested on hearing more about this automation requirement.