All Apps and Add-ons

TA-luhn: How to use the luhn command, and how to apply a regex to look for a specific card type before the luhn check?

New Member

The usage of the luhn command (see below) specified in the splunk app and the script doesn't work for me. It keeps giving syntax errors no matter what options I try.

* | luhn regex="regex string" output_field=field_to_output_true/false input_field=field_to_check

Two questions:

1) What is the correct way to apply the luhn check?
2) How can I apply a regex to look for a specific card type before doing luhn check? The default command produces a lot of false positives for me and I think that's because it's looking at length of card from 13 digits to 30 instead of 13 to 19 which I believe is the true length for a card number.

0 Karma

Path Finder

For item 1: Can you provide the syntax error? And the search you try to run when the syntax error occurs?

For item 2: It's important to know how the script does its matching. You can look at the comments in the script to get that information but here's the summary.

  1. Look at the input field, match against a generic regex (?:\d[ -]*?){13,30}
  2. If matched, strip all non-numeric characters
  3. Match new string against better regex (?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})
  4. If matched, run luhn check
  5. If luhn validated, set output field to true.

You can change the first regex to limit what gets passed to the rest of the script (and feasibly limit false positives). The reason the script was done this way was to be more paranoid - in my log data, I don't always expect a perfectly formatted card number. However, IIS logs tend to throw false positives with this method because of the status code followed by more numbers. (i.e. 404 239058293) You can change it like this:
| luhn regex="[\d\s-]{13,19}" output_field=luhn_check input_field=_raw

An alternative suggestion is to change the input_field. It defaults to _raw but you could use "ccfield" instead.

,For item 1: What are the syntax errors you are getting? In some distributed search environments, if the script is not replicated as part of the knowledge bundles, you may need to do: | localop | luhn. Without the actual error, I can't say for certain.

For item 2: regex="your regex string". You can modify the regular expression that the command is using. You could also modify the script directly which wouldn't be too terrible. The design decision around doing 13-30 instead of 13-19 is related to how card numbers can be presented. So the matching works like this (if the display doesn't work here, refer to the comments in the script):

  1. We take a provided string and match it against the pattern provided by regex="your regex string" which defaults to (?:\d[ -]*?){13,30}).
  2. For each match, remove all non-numeric characters.
  3. Check the remaining number with regex
  4. If matched, run a luhn check.

I have seen false positives when working with web logs quite a bit because of the status codes followed by more numbers and this may be an area where changing the initial regex may help. If you wanted to match 13-19 character length of format "XXXXXXXXXXXX" or "XXXX-XXXX-XXXX-XXXX", assuming my regex is correct:

| luhn regex="[\d-]{13,19}" output_field=luhn_check input_field=_raw

Let me know if that helps at all. The app isn't perfect so I'm willing to make some changes here...

0 Karma

Path Finder

It should be (backslash)d not d.

0 Karma
Get Updates on the Splunk Community!

The Splunk Success Framework: Your Guide to Successful Splunk Implementations

Splunk Lantern is a customer success center that provides advice from Splunk experts on valuable data ...

Splunk Training for All: Meet Aspiring Cybersecurity Analyst, Marc Alicea

Splunk Education believes in the value of training and certification in today’s rapidly-changing data-driven ...

Investigate Security and Threat Detection with VirusTotal and Splunk Integration

As security threats and their complexities surge, security analysts deal with increased challenges and ...