Entra ID Attack & Defense: Building an Azure→Splunk Log Pipeline

Jv Cyberguard
Nov 16
6 min read

It’s been about five months since my last post, life has been busy as I’ve been ramping up in my new Threat Response role. The learning curve has been thrilling. Over the past few months I’ve been deepening my understanding of detection engineering, incident response, and how attackers move across a much wider set of technologies beyond the traditional Windows stack.

Now I’m shifting gears again, and I figured I shouldn’t leave you all behind. I’m going to spend some time breaking down Microsoft Entra ID, privilege relationships, and the real attack paths that exist across identity infrastructure.

Prerequisites

Before we start breaking down attacks in Entra ID, we need a reliable way to actually see what’s happening inside the tenant. Everything in detection engineering, incident response, and attack analysis ultimately comes back to one thing: the logs.

Do also note that, I will be using my home lab for this. My home lab is hybrid, so for this new series we will be using my Microsoft E5 Developer Subscription and its Azure Tenant. I would have also gone over how to create that in my home lab series. Check it out.

I decided to dedicate this first article entirely to building a clean log ingestion pipeline from Entra ID into Splunk as it was not something I did in my home lab series. This would be a good upgrade to your home lab for sure.

By the end of this article, you’ll have a working Azure-to-Splunk pipeline that captures the two most important log sources for identity investigations in Azure. In the next part of the series, we’ll use the logs we now ingest from Azure to better understand real attack paths using a tool called ENTRAGOAT, but for now, let’s focus on getting the telemetry flowing.

Let’s walk through the setup.

Ingesting Entra/ Azure Logs into Spunk

Step 1. Creating the indexes in Splunk

Before we start ingesting anything from Entra ID, we need dedicated storage locations inside Splunk. Each index acts like a logical bucket where a specific type of data will live. For this lab, we’re pulling two core log sources from Entra: audit logs and sign-in logs. Creating separate indexes for each keeps the data organized, makes searching cleaner, and simplifies building detections later. Think of this step as preparing the landing zones so Splunk knows exactly where to put the incoming events once the pipeline goes live.

Go to Settings → Indexes → New Index

Create the first index:
- Name: entra_audit
- Everything else can stay default for the lab

Create the other index and name it entra_signin.

They should be there now.

Step 2. Create an app registration for Splunk in E5 Dev Tenant

To pull Entra ID logs into Splunk, we need a secure way for Splunk to talk to Microsoft Graph API. Azure does not allow external tools to query tenant logs anonymously. Everything must authenticate through a registered application. Microsoft Graph API is the unified interface that exposes identity, audit, and activity data from Entra ID and the rest of the Microsoft cloud. Creating an app registration gives Splunk its own identity in the tenant, along with the permissions it needs to read audit and sign-in logs. Splunk uses the app’s client ID and secret to request tokens, authenticate against Microsoft Graph, and continuously pull the data we want to analyze. Without this application identity in Entra ID, Splunk would have no authorized path into the tenant and the log pipeline would not function.

Click App registration.

Name it Splunk-log-collector and choose single tenant and then register.

Go to Certificates& Secrets, click new client secret and save these three somewhere safe.

Feel free to enter a description and choose the default expiration time.

It should populate here. Save those values somewhere safe you will need it.

There are two different things in Entra for app secrets:

Secret value
- Shown once when you create it.
- This is effectively the password for your app
Secret ID (the GUID / identifier)
- Just an internal reference to that secret object.
- By itself, it can’t be used to authenticate – you still need the secret value

We now have to add the API permissions so that Splunk can read the Audit and directory logs. How this works is that Entra ID logs in the background, without me being logged in. That’s why I used Microsoft Graph with application permissions instead of delegated permissions. When you grant something like AuditLog.Read.All and Directory.Read.All as application permissions and then approve admin consent, we’re effectively telling Entra: “This app identity is allowed to read audit and sign-in logs, and basic directory info, across the whole tenant.” In other words, the permission is tenant-level – it applies to the entire directory, not just one user.

Delegated permissions work very differently. They’re meant for interactive apps, where a user signs in and the app acts on that user’s behalf. In that case, the app can only do what the user is allowed to do, and only while there’s an active user session. That model doesn’t fit a SIEM-style log collector. Splunk needs to wake up on a schedule, authenticate with its own client ID and secret, and pull logs whether or not any admin is currently logged in. Using application permissions turns the app registration into a service identity with the right level of access for log ingestion, which is exactly what you want for this kind of lab.

Finally we grant admin consent. Why? We literally were requesting API permissions, granting admin consent is where Azure actually approves the permissions at the tenant level. If we don't grant admin consent, Splunk will be able to authenticate, but every call to Microsoft graph to pull the needed logs will fail because of insufficient privileges.

Step 3. Install the Splunk Add-on for Microsoft Azure

Now a little reminder for you, when it comes to Splunk, you should try and take advantage of the developer license because with the free license you only get 500mb, but the developer license you get 10GB. When I began working on this lab I realized I forgot to renew my dev license so I will quickly show you where you can request that.

Navigate to https://dev.splunk.com/

You'll get it by email.

Drop that file on your Splunk server and then we will add it via the UI.

Notice it shows expired?

Click add license.

It should update now.

We will now install the Splunk Add-on for Microsoft Azure in my Splunk instance.

Once it is installed open the app, we have to configure it.

Step 4. Wire that app into the Splunk add-on.

For the following steps, if something is not clear below I have linked the doc I referenced for this add on during setting it up.

https://github.com/splunk/splunk-add-on-microsoft-azure/wiki/Install-the-Splunk-Add-on-for-Microsoft-Azure

In the configuration tab of the Splunk Add on for Microsoft Azure App, we will need to input the details we noted earlier when we did the splunk-log-collector app registration in Azure.

Now go to the inputs tab -> Create New Input and these are the inputs we will be setting up for starters.

We will first create Microsoft Entra ID Audit input. Ensure to assign the input to the correct index.

We will next create Microsoft Entra ID Signin input for the app, please make sure to put the correct logs in the index you created.

To confirm we are receiving logs go to Splunk indexes.

As we can see here the events have already started to roll in.

Our logs are coming in nicely. Let's run an SPL to see what we have.

Example of entra events in the logs:

Below we also run a search to test our entra_signin logs.

That is good as well.

You may be wondering why we chose those Entra Signin and Entra Audit log sources as the inputs?

Well, Entra audit logs track the configuration side of Entra ID. They record events like service principal creation, permission changes, app registration updates, credential additions and anything else an attacker would touch while setting up persistence. While, sign in logs capture the operational side by showing every authentication attempt made by users and service principals. This includes successful logins, failed logins and the IPs or clients involved.

The tool we will be using in the next few subsequent articles on the blog is called ENTRA GOAT, a vulnerable Entra ID lab, in it we work through multiple Azure identity attack paths. Therefore, we need both the configuration history from audit logs and the authentication trail from sign in logs to fully observe and understand the attack paths.

If you are interested in knowing what Entra ID Audit logs have to offer, please check out this Microsoft Doc.

https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-audit-logs

If you are interested in knowing what all it captures see this Microsoft doc.

https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-audit-activities

One final thing I suggest you do before we begin ENTRA GOAT is to create another test app and add a client secret then delete the app. See if that generates any logs in Splunk. If it does, you're golden.

Create app. Call it test-app. Single tenant only.