1. Logpoint Service Desk
  2. Community
  3. SIEM - Searching & Analytics

Query returning no logs when field is [ true ]?

Avatar
Follow
0

Hey folks,

First time posting here - I’ve got a bit of a strange issue when querying for a specific type of log.

We have our Azure AD logging to Logpoint and I wanted to search for any account updates where the previous value of the ‘AccountEnabled’ field was ‘true’. 

"ModifiedProperties": [
    {
      "Name": "AccountEnabled",
      "NewValue": "[\r\n  false\r\n]",
      "OldValue": "[\r\n  true\r\n]"
    },
]

As you can see from my screenshot below, there is this field in the normalized log which outputs the previous value, but when querying under the same timeframe after clicking on that specific field, the query shows 0 logs.

Is this something I’m doing wrong, is this a bug with how the search query is interpreting it or is it a normalisation issue?

Field that I’m interested in searching for (with the matching value)
Clicking the field and searching with this query shows 0 logs. I’ve also tried re-formatting the query, but no dice.

We are using the built-in Azure AD normalizer, with most of the default fields. Any ideas how I might resolve this/work around this would be great.

Share This Post:

2 comments

Date Votes
0
Avatar
Nils Krumrey

Hi Ash,

Welcome onboard!

This looks to be a bit like a normalisation issue - I think we are taking the literal field value from the JSON response, and that doesn’t just seem to be true , but [true] , or indeed something even weirder like [\r\n true\r\n] (with spaces and carriage returns?).

Even though you seem to have managed to paste that into the search somehow, it isn’t built for searching for formatted strings like that, and I suspect something doesn’t get escaped correctly to match this, even though it looks “similar” in the search bar. Perhaps you could try a search for old_accountenabled=*true* ? That should return something (as long as the right timeframe and repo is selected), no matter what the extra characters around that string are.

Once we can get that to work, we could decide whether we need to change the normaliser - although it’s a bit weird that this field gets returned like this. An alternative could be an in-line “ norm on ” if you need to work with this value further.

Let us know how you get on - it’s a bit tricky to try this from afar as it relies on having the right logs to “play” with.

0
Avatar
CSO Integrations

Hi Nils,

Thanks for the welcome, and the very quick response!

I don’t know why I didn’t think of using the double wildcards you suggested, but that has indeed returned the expected value.

It’s good to know that the search bar doesn’t support that type of query (and to be honest, this is the first time I’ve come across it).

I’m happy for now, though!

Please sign in to leave a comment.