Finding Credit Card...
Clear all

Finding Credit Card Numbers - zero results...


I'm working a case in which I am searching for about 44 unique credit card numbers. I'm using EnCase 8.05. I've indexed and have found quite a few that way, which is fine, but I wanted to be a bit more thorough and went for keyword searches. I opted to also use grep.

Here's my grep expression



I had to write two since I exceeded the max length for expressions… The reason I wrote these particular expression vs using a generic expression to find any possible CC#'s was to limit the possible false positives (I started one and killed it once it passed 750k hits…). The first four digits represent the first four digits for the credit cards I'm after. This resulted in about 1600 hits after I filtered down to unique hits.

So I got my results and further searched them for exact matches for my CC#'s and got zero hits…

I am guessing I could have done this differently and gotten some better results, since I sorta expected to find some credit card numbers using a keyword search.

What are your thoughts, experiences on what I did and what you would do?

Topic starter Posted : 08/02/2018 11:38 pm
Active Member

Unicode? I'd do an all out search for CC details using different encoding types, then search that result.

They could also be stored as 1234123412341234 without separators, and even have the expiration/CVV attached to it. Or keep numbers stored with an offset (i.e. rotated right 4 numbers)

I guess someone doing a card dump would not care much for how it was formatted as long as they could use it.

Posted : 09/02/2018 6:51 am
Community Legend

I'm using EnCase 8.05.

I would be very wary about EnCase regexps. I remember several occasions where bugs in regexp implementation have surfaced, one even during an EnCase class.

I don't trust it any more, particularly as it has/had some awkward limitations – at least one of which you seem to have run in to. I also remember some rather spectacular failures of an regexp 'optimizier' that very often converted the entered regexp into something slightly different from what had been entered.

I would recommend using Unix regexp software instead.

I've indexed and have found quite a few that way,…

Did you examine what format those matches were in? What kind of files they appeared in etc. That might help in deciding what regexps


Well, yes, … regexps are difficult. You should not do them unless you really know them. And even then, you should validate that you've got it right, because most of the times, you don't. Not the first time, anyway.

So … did you get it right? Did you test your expression against test data? (Or, alternatively, did EnCase get it wrong?)

My immediate impression is that I would add a parenthesis around the initial sequence of numbers, just to ensure there wasn't an operator precedence problem

What happens here


I would need to test it to be entirely certain, but to my eyes it looks very much as if you're matching 4427 on the one hand or 4821-?### on the other. Not 4427 or 4821 followed by -?####. (But as I don't trust EnCase, perhaps it has some other operator precedence rules that I'm not aware of).

I'd make it ((4427)|(4821))-?####, i.e. I'd add () around all the initial 4-digit sequences to start with.

And what happens at the other end of the regexp


| is the operator with loweest precedence, so all concatenated patterns bind closer … looks like you need () here as well.

But then I'm likely to make mistakes myself. Regexps are dangerous – you need to check and double-check.

Posted : 13/02/2018 8:28 pm

Thanks for the replies! Yes, I tested my expression on some test data and felt it was working as intended, but not being very knowledgeable of the limitations and best way to implement them I certainly could have created an expression that doesn't work like I thought it was…

I will try and re-visit my test data and use some of the suggested tips you gave. Thanks again!


Ok.. added the parenthesis around the expression as suggested and didn't seem to notice any difference in the data being found in the test data… so I think the expression is working as expected.

As to your question on the hits being found in the Index. I will have to get back to this to verify, but I know some/most of the hits were found in PDF docs…

Topic starter Posted : 19/02/2018 3:21 pm
Junior Member

I don't think that it is matching how you'd like it.

Take a look at it will give you a graphical view as to the paths through your regex.

I think this is something more like what you are after. Compare it with yours in debuggex.


Not tested this works in encase mind…

If you're looking for a fun way to play/learn regex then take a look at this site

Posted : 19/02/2018 6:49 pm
Share to...