Chat now with support
Chat with Support

IT Security Search 11.5.2 - User Guide

Saving Searches and Running Saved Searches

You can save any search for later reuse. Any IT Security Search operator or administrator can save searches and run saved searches, but only administrators can make them public for shared use.

Saving Searches

To save a search, click the drop-down icon at the left edge of the search box and click Save Current Search. Proceed to configure your search in the popup that appears:

  • Give the search a meaningful name.
  • Add tags so that users can easily find the search by category.
  • Select which parameters you want to make customizable, if necessary.
    All field names that occur in your search string are listed. Select the check boxes next to the ones that you want to make customizable. Whenever this saved search is used in the future, it will prompt for the values of all of the fields you select.

NOTE: The field selection controls in the popup are really only a graphical way to include special syntax in your search string. The syntax for a customizable attribute is a string (usually, the field name) enclosed in double curly braces, in the place of a value substring.

For example, Domain:{{Domain}} will make IT Security Search prompt you for the value of the Domain field, labeled "Domain"; Domain:{{Active Directory Domain}} will also prompt you for the value of Domain, but the label will be "Active Directory Domain".

You can manually construct search strings that include this syntax, without using the field selector. This helps you provide descriptive labels for parameters.

  • Specify the time period that the search must cover.
    For that, select one of the options at the right edge of the search box. These times are relative to the moment the saved search is run.

When you have configured these options, click Save.

Running a Saved Search

To run an existing saved search, click the drop-down icon at the left edge of the search box; the available saved searches are listed at the bottom of the popup that appears. You can filter the list by clicking tag buttons in the Saved Search Categories drop-down.

Making a Saved Search Public or Private

You can publish a search to make it available to all operators only if you are an IT Security Search administrator.

In the saved search list, the items have a lock icon showing their state. A private search has a closed lock icon; click the icon to make it public. A public search has an open lock icon; click the icon to make it private.

Deleting a Saved Search

To delete a saved search, highlight it in the saved search list and click the cross icon.

Importing and Exporting Searches

Saved search import and export capabilities help you back up and restore your IT data analysis knowledge and share it with other IT Security Search users.

To use the Import and Export actions, click the drop-down icon at the left edge of the search box; these actions are available at the top of the drop-down menu.

When you click Export, you are prompted to save a *.yaml file. The resulting file will contain all saved searches created under your account plus any saved searches made public by administrators.

NOTE: This action saves not only searches but also any custom action links defined in your IT Security Search deployment. For details about making custom action links, see Customizing Action Links.

When you click Import, you are prompted to select a previously exported *.yaml file. If the file includes any searches with the same names as your existing searches, you have the option to collectively skip, overwrite or automatically rename such searches.

IMPORTANT: Overwriting administrator-created public saved searches is disallowed for IT Security Search operators, but not for administrators; in this situation, if you are an operator, the search in the source file is silently skipped instead.

Customizing Action Links

An action link is a clickable search link displayed to the left of a details page for an object. Action links are a way to enhance the cohesion of data that is linked in any way and enrich the context for the data you discover.

IT Security Search provides a number of action links out of the box. For example, you get the Files and folders owned by this user link when you view the details of a user and the Who changed permissions on this file link for a file. In addition to such bundled action links, you can define your own and bring them into your IT Security Search deployment using an import operation.

Defining Action Links

To define an action link, you need to create a valid YAML file that specifies the details of that link. A single YAML file can contain definitions of multiple action links along with definitions of saved searches. If action links and saved searches are in a the same YAML file, that doesn't mean they are associated with one another in any way. Each one is defined individually, and you can group them into files however you like.

The following is an example of two YAML-formatted action link definitions specified after saved search definitions in a single file. If you need additional information about the valid format, see the documentation at




- Name: Logons by this user

  Query: 'Who:"{LogonName}" AND (What:authentication OR What:logon)'

  Source: Users

  Target: Events

  Condition: '-Department:Management'


  - My company's action link kit

  - OnPremise

- Name: Applications for this tenant

  Query: 'objecttype="Azure Applications" AND Tenant:"{name}"'

  Source: Azure Tenants

  Target: Azure Applications


  - My company's action link kit

  - Cloud

- Name: Find this event in Event-o-pedia

  Query: '{EventID}'

  Source: Events

  External: true

The following fields are required in an action link definition (mandatory fields are bolded):

  • Name
    The display name of the link as it should appear in the left pane of the object details page; make sure this name is unique across your entire IT Security Search deployment.
  • Query
    The search query that is run when the action link is clicked; the query can contain references to the field values of the current object, enclosed in curly braces.
  • Source
    The type of object for which the action link is available.
  • Target
    The search will run for all object types, but this tab will be opened. This field is ignored if the External field is set to true.
  • Condition
    A valid IT Security Search query that specify particular properties that an object must have to provide this action link. If the condition isn't met, then the action link remains hidden. The query can contain references to the field values of the current object.
  • External
    If set to true, the link is treated as the URL of an external resource instead of an IT Security Search query. If you want to insert field values in any part of the URL, use field names enclosed in curly braces. This helps automate the use of search engines and similar resources directly from IT Security Search details pages.
  • Tags
    Arbitrary tags with arbitrary values. Currently, this field is unused and treated as a user comment. Consider giving your custom action links unified tags for your own convenience.

Importing and Resetting Custom Action Links

Only IT Security Search administrators can import and reset actions links. To import action links, click the drop-down icon at the left edge of the search box and select Import. Note that both action links and saved searches are imported by this action. If you want strictly action links, don't include any saved searches in the *.yaml file intended for import.


  • Unlike saved searches, action links cannot be made private. All imported action links become available to everyone.
  • In the event of a name clash during import, you are prompted to choose if you want to overwrite, rename or skip the links, or cancel the import.

To remove all custom action links and restore the default set, click the Reset Actions button, which is at the top of the Actions section in object details. Note that the button removes all custom action links for all object types and leaves only the default set.

Use Scenarios

The following examples explain how IT Security Search tools can be applied in practice to real-life situations.

Finding and Examining a User

To find events where a particular user is somehow involved (as the doer or as a subject), run a search for any of the variety of names that identify the user in the environment. You can supply the first name, last name, full name, logon name and so on.

The results of your search put the most relevant matching users at the top of the list. If there are too many matches, refine the results using facets.

From a different perspective, if you need to find a user whose name you are not sure about but whose manager's name you remember, try searching for the manager's name, then opening the details of the manager's user account and finding the user you are looking for among the manager's direct reports.

Understanding Who Did What

A typical use case is tracking the activity that involved a particular object, such as a file, folder, group or user account. You begin by finding this object; this provides a starting point and a context for your session. The next step is to use the links in the object's details view. This is the easiest way to create a context and filter out irrelevant data.

Another option is to start with events directly, especially if you expect to find specific events within a specific period of time. To specify the period, use the date range filter. The graphical timeline in the result grid can help you quickly locate peaks of activity that need closer examination.

For example, suppose you have discovered an unknown application called testaadapp in your Azure environment, and you want to know how it got there. To find the relevant events, run a search like the following:

testaadapp AND description:"add"

In the events that you find, use the Who link to discover who added the application.

Getting Insights from the Who and Whom Fields

You can learn a lot about a security incident just by looking at the initiator of an event and the account or object affected by the event. For this common pattern, the Who and Whom fields are defined for a variety of events. This gives you a consistent analysis tool, no matter what event fields the relevant data is actually stored in.

The technique is especially useful when you are looking at the account management activity of a particular user with administrative privileges.

Exploring a User's Scope of Access

IT Security Search provides quick access to information about files and folders owned by a user and all permissions assigned to the user; for that, use the Files and folders owned by this user, Files and folders where this user has direct permissions and Files and folders where this user has permissions (both direct and indirect) links in the details view for the user you are interested in.

Conversely, if you start with a particular file or folder, its details contain a table of permissions, which can prompt your further steps.

Tracking Permission Management

You can easily follow permission assignment activity using the Who changed permissions on this file and Who changed permissions on this folder links in the details view of a file or folder, respectively.

Exploring and Rolling Back Changes to Active Directory Objects

Object change history is available only if the Recovery Manager for Active Directory connector is enabled. For information about changes to an object and recovery tools, go to the History tab on the object's details page. This tab has two modes: Changes and Backups.

In Backups mode, the most recent backup states (three by default) of the object are shown, with details about how their attribute values differ from the current state. You can fully restore any of these states by clicking the Restore from backup link for that state.

In Changes mode, you have more fine-grained control and can view and roll back individual attribute changes. All changes recorded in the most recent backups are shown, including the "before" and "after" values, and you can sort them by attribute name or by date. To roll back individual changes, select their check boxes in the table and click the Revert to the previous attribute state link.

NOTE: In Changes mode, the date shown for a particular change is the date of the backup that contains information about that change. The date can be empty, meaning that the change is recent and has not been recorded in any backup state.

Detecting Preparations for Intrusion

You can track attempts to probe Active Directory prior to intrusion. One symptom of such activity is a trail of LDAP queries from unlikely workstations or by suspicious accounts. It may mean an effort to find vulnerable Active Directory accounts with administrative privileges. The following types of LDAP query in quick succession are telltale signs of this:

  • Looking for information about account passwords and statuses
  • Listing groups
  • Querying administrative group membership

In IT Security Search, you can track such queries by running the following search:

What:"AD Query Performed"

In the search results, examine the LDAP - Attributes and LDAP - Filter fields.

In the following examples, trustedworkstation1 and trustedworkstation2 are computers where you don't consider running LDAP queries suspicious; with all other workstations, it's best to take a closer look.

  • Someone is looking for information about user accounts:
    Source="ChangeAuditor" What="AD Query Performed" [LDAP - Attributes]:"*password*" [LDAP - Filter]:"*user*" -Workstation=trustedworkstation1 -Workstation=trustedworkstation2
  • Someone is exploring administrative group membership:
    Source="ChangeAuditor" What="AD Query Performed" [LDAP - Attributes]:"*member*" [LDAP - Filter]:"*admin*" [LDAP - Filter]:"*group*" -Workstation=trustedworkstation1 -Workstation=trustedworkstation2

Similar suspicious behavior often precedes pass-the-hash attacks that rely on stored password hashes. In this case, it can be accompanied by series of remote logon attempts to computers in the network. To capture such activity, you should also search for logon events that occurred around the same time as the LDAP queries you found.

Case Studies

See also the following topics for examples of investigations that IT Security Search can help carry out:

Case Study: Investigating Tampering

Suppose a critical file (such as a project roadmap or payroll file) is showing signs of tampering. You want to use IT Security Search to look into this.

What you will need

To make the investigation as efficient as possible, make sure that data from the following sources is available:

  • For security events, including user session events: InTrust
  • For file change information: Change Auditor
  • For user information: Enterprise Reporter
Where to start

You are about to examine the circumstances of file modifications, so it makes sense to start by finding the affected file. This will provide clues about where to go next and also mark a point (as a breadcrumb) that you can always fall back to, even if your next steps take you too far.

How to proceed

When you have found the file, open its full details and use the Who accessed this file link provided in that view. In the list of events that are found, find a "File changed" event and use the What facet to filter out other types of events. Try to spot any unlikely users in the list of file change events.

Suppose you find an event by a user who is not meant to have access to the file. Note the time of the event, and then open the details of the event and click the user name. In the the user details view that opens, click the Files and folder where this user has permissions link. If the file in question is not listed, that means the permissions have been rolled back by now—likely a piece of incriminating data.

You can also view the entire history of permission management for the file. Use the breadcrumbs to go back to the file details view, and click the Who granted permissions to this file link.

Use the breadcrumbs to go back to the user details view, and click the Activity initiated by this user link. Use the time range filter to restrict the results to a period around the time of the suspicious file modification. The results may reveal noteworthy details about the situation. Consider examining InTrust-specific user session events for the following clues:

  • Logon session time and duration
  • Whether the session was interactive or Terminal Services-based

In addition, check if there were any attempts to clear security logs.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating