Re-processing after cracking passwords

[Jacques B]

I occasionally encounter encrypted PDFs that Intella was unable to decrypt. Naturally, I only know this after processing is done. I've had success cracking passwords of PDFs of bank statements where the password is numeric (part of the account number). Once cracked, I know I can add it to the keystore. But as far as I can tell, I then have to re-index the entire evidence item(s) with content that needs to be decrypted. I don't see any option to simply decrypt and index the 10, 20 or 30 files that are encrypted. I have to re-index tens or hundreds of thousands of files in the evidence source(s).

Is there a way to have Intella only re-index select items instead of all items in a source?

[ShaunC]

Personally, I would just use the facet to filter to, and then export the encrypted items and add them as a new source.

[Jacques B]

Thanks. I’ve done that in the past. But the down side of that approach is the decrypted item is not at the original path within the evidence. For example, if the original is an attachement in an email, the decrypted version won’t be if imported as a new source.

 It would be great if Intella had the ability to index filtered files instead of needing to index all of them. 

[ShaunC]

I wonder if you could script it as part of initial processing?

It would be pretty unintelligent, but I wonder if you could do something like (100% pseudo-code):

if item.encrypted = true
	wordlist = get-content item.parent (separator 'whitespace')
	foreach word in wordlist
		try item.decrypt word

You could build your wordlist in a way that makes sense. The above is hoping the parent is an email and they've supplied the password in the email for example

[Jacques B]

I’m not sure if Intella supports that type of scripting. In my case I’ve been using John the Ripper in a Linux VM to crack PDF docs typically. So I don’t think there would be any way to call upon it from Windows. 

The other challenge is that in the case of PDF bank statements for example, the accompanying email from the bank usually provides the mask for the password (e.g., the middle six characters of the bank account number) which I use as a parameter for cracking the password. In other cases, I’ve found the password right in the email. “Hey John, here’s the encrypted spreadsheet for your review. The password is “abc123”.

i wouldn’t want to delay Intella processing while it tries to brute force each time it finds an encrypted file it can’t automatically decrypt. I appreciate your suggestions as possible alternative options. The ideal solution rests with Vound adding the ability to process/re-process selected files. You would think you could choose only docs that it couldn’t decrypt and reprocess those with the keystore rather than hanving to reprocess every item in the data set. 
 

Thanks again for taking the time to offer suggestions. 

[ShaunC]

No worries at all and I agree; it would be best solved with that sort of mechanism - the permutations of what you would come across would be way too complex to script effectively.

[Mateusz]

Hey guys, I have to admit that these are all good ideas and I have sent these through to the dev team for consideration. Thanks!