User Profile
TheriumSec
Copper Contributor
Joined Jun 12, 2020
User Widgets
Recent Discussions
Odd Field mapping behavour
Hello All - Wondering if anyone else has/is encountering some odd behavior with log indexing to uncommon fields? Recently we discovered when we we doing queries in Sentinel/Log Analytics Workspace we would be getting results but the columns would be empty but the count would be high. We then discovered that many new fields had been populated such as: UserId_, ClientIP_,Site_ All of these fields have an underscore and are not part of the supported Connectors (Office 365). Whats more bizarre is that sometime data is indexed to the common support field such as UserId and the next record is indexed to UserId_ This makes it a nightmare to query, run Workbooks, Playbooks etc. Just curious if anyone else is seeing this?972Views1like2CommentsRe: Query level parsing numerous call participants
CliveWatson Thank you Clive for the suggestion, I believe the mv-extend will help with structuring the display of the results but unfortunately not with initial issue I am trying to overcome. When looking at the call records where type = groupCall there is more then 2 participants under participants_s, these are represented by integers [#] for each participant. What I am hoping to do is be able to query the Call records and parse the unknown number of partiicpants using a wildcard or loop condition if possible. As you can see below an extend has been used for each individual participant to extract and map there username to a field, but this is only because I happen to know there were 4 participants in this case. In all other cases the number would be unknown. TEAMSGraphCallRecords_CL | extend caller0 = parse_json(tostring(parse_json(participants_s)[0].user)).displayName | extend caller1 = parse_json(tostring(parse_json(participants_s)[1].user)).displayName | extend caller2 = parse_json(tostring(parse_json(participants_s)[2].user)).displayName | extend caller3 = parse_json(tostring(parse_json(participants_s)[3].user)).displayName1.3KViews0likes1CommentAzure Firewall (Preview) Data Connector
Hello - Just a quick blurb on the Azure Firewall Connector. Its seems really odd to release (even in preview) a firewall Connector that does not parse source/destination/ports in to separate mapped fields, they clustered into one. As I was observing this this morning it felt like I was taking a step back to L2 ACLs on a switch... Just some friendly feedback that I suspect you might have saw coming...651Views0likes0CommentsAuditing Power-Users and Administrative Tasks with non-repudiation - Does it exist?
I am trying to to track down what one would seem to be a seemingly basic task - When and Who created a particular user in AAD? I believe I have been able to answer part of the question, the when. I see a timestamp in the AuditLogs specific to the 'Add User' OperationName - Excellent! The other part however leaves me wondering if the data exists or if its hidden somewhere in Azure and does not qualify to make into the standard AuditLogs. Who clicked the buttons to enable the user account? What I see is the following: InitiatedBy {"app":{"displayName":"Microsoft Substrate Management","servicePrincipalName":null,"servicePrincipalId":"ad#4b51d9-dqw5-87d9-827c-t9c07s4284#31","appId":null}} I have randomized the servicePrincipalId So safe to say this was likely a service/process or script that kicked off to create the user account in AAD. The question is, who set the script in motion? Does anyone have any experience with this and is there a way to prove non-repudiation for this type of event? Many Thanks!2.9KViews0likes3CommentsRe: Odd Field mapping behavour
Hi Ofer_Shezaf Thank you for your insight into this issue. We are now seeing the data mapping to the proper fields, however the newly created fields such as UserId_, ClientIP_, OrganizationId_, etc. are all still being populated as well. Also when this occurred it caused historical data to be misrepresented in unsupported fields and not even written to in the supported fields, that has not been fixed. Is anyone else noticing this specific to Office 365 logs in Sentinel?881Views0likes0Comments
Recent Blog Articles
No content to show