NTM Reporting Module - request wildcard search capability under Investigate > Run Query

What is a one sentence summary of your feature request?

In the NTM Reporting Module we want the ability to conduct a wildcard search under Investigate > Run Query.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

  1. In the NTM Reporting Module we want the ability to conduct a wildcard search under Investigate > Run Query.

  2. As a specific example for an Active Directory Attribute like “Perpetrator Protocol” we would like to search for rc4 (or using whatever wildcard characters are correct).

How do you currently solve the challenges you have by not having this feature?

+++++
Below are the steps for a current workaround:
+++++

  1. Save an investigation in the NTM RM and call it “Perp_Prot_TGS_CIFS_RC4” (for example).
    I saved it using the TGS: cifs label and value.

  2. Run the following query against the PostgreSQL database to locate the investigation that you just created in step 1:

<\*
SELECT p.\*
FROM alert_query_parameters p
JOIN alert_query q ON q.id = p.alert_query_id
where 1=1
and q.name = ‘Perp_Prot_TGS_CIFS_RC4’  << This is my specific name for the Investigation that I created and saved!!!
ORDER BY p.id desc
LIMIT 1;
\*>
  1. Copy and past the “filters” JSON into a text editor and modify it as follows. (This is my specific example and an example only.)
<\*
\[{“id”: “1”, “operator”: 1, “attribute”: 23, “filterValue”: \[{“value”: 1}\]}, {“id”: “2”, “operator”: 1, “attribute”: 29, “filterValue”: \[{“value”: 1}\]}, {“id”: “3”, “operator”: 3, “attribute”: 18, “filterValue”: \[{“label”: “TGS: cifs”, “value”: “TGS: cifs”}\]}\]
*>
<*
\[{“id”: “1”, “operator”: 1, “attribute”: 23, “filterValue”: \[{“value”: 1}\]}, {“id”: “2”, “operator”: 1, “attribute”: 29, “filterValue”: \[{“value”: 1}\]}, {“id”: “3”, “operator”: 3, “attribute”: 18, “filterValue”: \[{“label”: “rc4”, “value”: “rc4”}\]}\]
\*>
  1. You must copy and paste your newly created filters JSON value and ID and ALERT_QUERY_ID in order to run the SQL to apply this workaround to your database.
<\*
update alert_query_parameters
set filters = ‘\[{“id”: “1”, “operator”: 1, “attribute”: 23, “filterValue”: \[{“value”: 1}\]}, {“id”: “2”, “operator”: 1, “attribute”: 29, “filterValue”: \[{“value”: 1}\]}, {“id”: “3”, “operator”: 3, “attribute”: 18, “filterValue”: \[{“label”: “rc4”, “value”: “rc4”}\]}\]’
where id =<YOUR_PRECISE_ID> and alert_query_id = <YOUR_PRECISE_ALERT_QUERY_ID>;
\*>
  1. Attribute 18 is for perpetrator protocol.

  2. Note you will have to restart the NTM Web Service after editing the database.

  3. Current work around screenshot is below:

Thank you @mcando for posting this for us! RC4 searching has been a big one for our customers lately due to Beyond RC4 for Windows authentication | Microsoft Windows Server Blog

2 Likes

Thanks for the submission! I’m reviewing this with the team.

1 Like

This is great news!

After discussing with development, we should be able to quickly add the functionality to type in custom values. This should solve the use case for the customer without needing to edit the investigation in the DB.

Look out for an update on when that hotfix becomes available. I’ll look to come back and mark this as complete when it’s available also.

1 Like