First Time Accessing an Internal Git Repository Not Viewed by Peers

First Time Accessing an Internal Git Repository Not Viewed by Peers


Find users who accessed a git repository for the first time, where their peer group also hasn't accessed it before.

Content Mapping

This content is not mapped to any local saved search. Add mapping

Use Case

Insider Threat


Data Exfiltration

Security Impact

This is an insider threat use case that builds off of the "Accessing New Git Repositories" example. Your developers are often granted access to the Git (or other software life cycle repository) that they require, but why would they be gaining access to other repos that other members of their team (e.g. peer group) never access? This could be an alertable condition. In order to perform searches like this you must map your users into peer groups - we have done this via a simple Splunk lookup in the example, but this could be done via more automated fashion, and Splunk UBA contains its own methods of discovering peer groups for individual users.

Alert Volume


SPL Difficulty


Data Availability



Stage 4



MITRE ATT&CK Techniques

Data from Information Repositories

MITRE Threat Groups


Kill Chain Phases

Actions On Objectives

Data Sources

Web Server

   How to Implement

Implementation of this example (or any of the First Time Seen examples) is generally very simple, though the peer group makes things slightly more complicated.

  • Validate that you have the right data onboarded, and that the fields you want to monitor are properly extracted.
  • Save the search.

To configure the Peer Group:

  1. Start with a data source that gives you visibility into the peer group -- easiest is usually querying Active Directory via the SA-ldapsearch add-on, but you could get lists of users and their teams / departments / etc from any source you have.
  2. Next you will need to convert that log source into a format that this lookup is expecting, which is as follows:
    userpeergroup (order not important)
    The easiest way to do this is with a search like | inputlookup LDAPSearch.csv | stats values(user) as user by department | eval peergroup=mvjoin(user, "|") | mvexpand user

For most environments, these searches can be run once a day, often overnight, without worrying too much about a slow search. If you wish to run this search more frequently, or if this search is too slow for your environment, we recommend leveraging a lookup cache. For more on this, see the lookup cache dropdown below and select the sample item. A window will pop up telling you more about this feature.

   Known False Positives

This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over (or for the lookup cache feature, the first occurrence over whatever time period you built the lookup). But while there are really no "false positives" in a traditional sense, there is definitely lots of noise (even though the peer groups help manage noise).

You should not review these alerts directly except for access to extremely sensitive repositories, but instead use them for context, or to aggregate risk (as mentioned under How To Respond).

   How To Respond

When this search returns values, initiate your incident response process and identify the user account accessing the specific repo. Contact the user and manager to determine if they are accessing the repo with authorization. If they did not access this repo, attempt to determine if the user credentials have been used by another party by stealing a user's credentials.


First Time Accessing an Internal Git Repository Not Viewed by Peers Help

This example leverages the Detect New Values search assistant. Our dataset is the Splunk-internal git source source checkout history for a couple of our Splunk UBA software developers, anonymized to Alice and Chuck. On the last day, I added in a few more developers who visit other repositories, but set their usernames to Chuck so that it looks like he started downloading from a bunch of repositories that he's never touched before. We also have a user Bob, who has checked out from a few other repositories in the past, and is on Chuck's team. Under the peer group, git_peer_group is selected, which includes that chuck and bob are on the same team. For this analysis, we are looking at the first time a username, or anyone in that user's peer group, has checked out from a repository names, and alerting if that was in the last day.

SPL for First Time Accessing an Internal Git Repository Not Viewed by Peers

Demo Data

First we pull in our demo dataset.
Find where the most recent value is less than -1d@d from either now() or the value showing your most recent data point (depending on your particular search desires)
Enrich primary with peer group
Here we are comparing the # of 'Secondary Field's viewed today and historically by the 'Primary Field'. multireport is a search operator that allows you to leverage the power of stats, but multiple times.
Now we join the two | stats output together into one, so that we can analyze them together
Filtering out null earliest will handle corner cases to make a clean report.