Skip to main content
Solved

Search Returning Internal IPs Instead Of Lookup IPs From Various Sources

  • April 21, 2026
  • 17 replies
  • 3 views

This message originated from Cribl Community Slack.
Click here to view the original link.

I am considering scheduling a search to return if any IOCs are found from various sources I get e.g. CISA, MSISAC, EDR company, etc. I have a basic lookup:
ip,source_desc
5.252.179.169,waterisac
5.252.179.89,waterisac
I tried what I thought would work in search and then went to AI to refine it because it was returning my internal IPs not the IPs in the lookup:

Links for this message:
image.png

Best answer by David Cavuto

For your search, the data in your event is expected to be in a field called src_ip and matching that with the field ip in the lookup table, The lookup operator will add the ip and source_desc fields to every matching event in your search results, and do nothing to any unmatching event. What is happening with your search results?

17 replies

  • Author
  • Participating Frequently
  • April 21, 2026
I am still getting only internal IPs showing up. Which I do not have any unrouteable IPs in my lookup but that is what is being returned... Any ideas?

  • Employee
  • Answer
  • April 21, 2026
For your search, the data in your event is expected to be in a field called src_ip and matching that with the field ip in the lookup table, The lookup operator will add the ip and source_desc fields to every matching event in your search results, and do nothing to any unmatching event. What is happening with your search results?

  • Author
  • Participating Frequently
  • April 21, 2026
I am seeing a bunch of class A unrouteable IPs in the ip field

does the IP field exist in the source data?

  • Author
  • Participating Frequently
  • April 21, 2026
I don't think so, but let me verify w/o a lookup

  • Author
  • Participating Frequently
  • April 21, 2026
oh darn it

  • Author
  • Participating Frequently
  • April 21, 2026
hmm, even with diligently cutting fields and making them CIM, I see more fields than I think should be there.

  • Author
  • Participating Frequently
  • April 21, 2026
let me change the lookup to have a weird name for IP

ok, so perhaps we can try changing the field name on the lookup? Maybe "match_ip" or something like that?

note you can also have it output only the source_desc field using the output=<field_list> optional parameter.

So you could try:
... | lookup output=source_desc Iran_IPs on src_ip=match_ip | ...

and then you could apply filters on those events if you only wanted to see the matching ones:
... 
| lookup output=source_desc Iran_IPs on src_ip=match_ip
| where source_desc == "waterisac"

  • Author
  • Participating Frequently
  • April 21, 2026
If I want to make this an alert and only return results IF events have the lookup IPs, how do I form that search?

It's important to remember that the lookup operator is essentially a "left-join" operator. It does NOT eliminate any event from the source pipeline. It just enriches events with matching information, if any. If you want to remove events, you'll need a follow-up where clause, or any equivalent filtering expression.

The easiest way to make that into an alert is to add a count to the end of it:
... 
| lookup output=source_desc Iran_IPs on src_ip=match_ip
| where source_desc == "waterisac"
| count
This will return either 0 or non-zero, and then you can use that in the condition for the alert. Alternatively, just leave off the count and use the "Count of events greater than zero" as a condition for the alert. But remember, counting events is always less costly (in CPU terms) than listing them all out (even if you're not sending them anywhere). So if you want the list, great. But if you don't need the list, use the count expression.

  • Author
  • Participating Frequently
  • April 21, 2026
I appreciate you teaching me to fish!!!

Of course, we're here to help! Let me know if that helped, and if you have any other questions!