Post cover image
The SSH source IP was visible inside the raw events, but my search could not yet group the events using src_ip.

September 4, 2026

The IP Address Was in My Splunk Logs. Splunk Still Couldn’t Use It.

In Article 2, I got Linux authentication telemetry into Splunk.

By William | SOC and Detection Engineering

3 min read

The logs were there.

The failed SSH attempts were there.

Even the source IP address was visible inside every event.

But when I tried to group those events by source IP, I got nothing.

That exposed a problem I had not thought much about before building the lab:

Visible data is not necessarily usable data.

The Raw Log Already Had What I Needed

My linux_secure events contained entries like:

Failed password for root from 192.168.64.15 port 58926 ssh2

So the information required for a basic SSH investigation was already present.

I could see the attempted account.

I could see the source IP.

I could see repeated authentication failures.

But my earlier search tried this:

index=* sourcetype="linux_secure"
| search "Failed password"
| stats count by host, src_ip
| sort -count

Splunk returned 44 matching events, but the Statistics tab returned 0 results.

The raw event contained 192.168.64.15, but I did not yet have a usable src_ip field for that search.

None

I Needed to Extract the Field

Instead of treating the entire log line as one piece of text, I needed to pull the source IP into a field Splunk could work with.

I used rex against _raw:

| rex field=_raw "from (?P<src_ip>\d+\.\d+\.\d+\.\d+)"

The expression looks for the word from followed by an IPv4-style value and captures that value as src_ip.

Then I could use that field in the rest of the search.

My completed search became:

index=* sourcetype="linux_secure"
| search "Failed password"
| rex field=_raw "from (?P<src_ip>\d+\.\d+\.\d+\.\d+)"
| stats count as failed_attempts by src_ip, host
| where failed_attempts > 10
| sort -failed_attempts

Now Splunk could group the authentication failures by source IP and host.

The Same Logs Became Much More Useful

In this later search window, Splunk returned 92 failed authentication events.

Instead of manually reading individual log lines, I now had one structured result:

src_ip          host             failed_attempts
192.168.64.15   wazuh-manager    92

The Statistics tab that previously gave me nothing could now answer a useful investigation question:

Which source was repeatedly failing authentication against this host?

None

There is an important distinction here.

The 44 events from the previous screenshot and the 92 events here are from different search moments.

I am not claiming that field extraction somehow turned 44 events into 92.

The improvement was not the number.

The improvement was the structure.

Splunk could now use information that previously existed only inside the raw event.

Why That Matters in a SOC Investigation

Imagine having thousands of authentication events.

Reading them individually would tell me what happened.

Structuring them lets me ask better questions.

Which source IP generated the most failures?

Which host was targeted?

How many attempts came from the same source?

Does a source cross a threshold that deserves investigation?

That is where the value of field extraction became obvious to me.

The log itself had not changed.

My ability to investigate it had.

I Also Added a Simple Threshold

After counting the attempts, I included:

| where failed_attempts > 10

This was not meant to represent a universal brute-force threshold.

It was simply a lab condition that allowed me to surface sources generating repeated failures.

That distinction matters.

A useful detection threshold should eventually consider the environment, normal authentication behavior, time windows and the possibility of false positives.

For this stage of my lab, the objective was simpler:

Take raw authentication telemetry and make repeated activity immediately visible.

What I Learned

This changed how I think about log collection.

Getting telemetry into a SIEM is only one layer.

I also need to ask:

Can I extract the entities that matter?

Can I group activity around those entities?

Can I measure repeated behavior?

Can I turn a raw event into something another analyst could quickly understand?

In this case, one field changed the investigation from reading repeated SSH messages to seeing:

192.168.64.15 → wazuh-manager → 92 failed attempts

That is a much more useful starting point for triage.

The data had been there the entire time.

I just had to make it usable.

In Article 4, I'll take this further by looking at the SSH activity as an investigation rather than just a log-processing problem.