User Login to Unauthorized Geo

Description

For regulated environments, detect users logging into servers where they're not permitted.


Use Case

Compliance

Category

Compliance

Security Impact

For organizations that face strong regulations, you may need to restrict access to servers in specific geographies (particularly, Germany tends to have strict laws). If your legal team has indicated that you need to restrict access based on the types of data that you have, Splunk makes it easy to detect unauthorized logins.

Alert Volume

Medium (?)

SPL Difficulty

Medium

Journey

Stage 4

MITRE ATT&CK Tactics

Initial Access

MITRE ATT&CK Techniques

Valid Accounts

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Leviathan
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
menuPass

Kill Chain Phases

Actions on Objectives

Data Sources

Authentication
AWS
Audit Trail

   How to Implement

This search is easy to implement technically, though difficult for business purposes. Building a reliable list of which servers are in which zones, and which users are permitted to log into which zones can be a project that takes weeks or months to complete, and never completes with complete accuracy (though the importance of absolute accuracy is up to the interpretation of your legal advisor). Once you have two lookups, servers_to_geos and users_authorized_geos, the search implementation should proceed smoothly.

   Known False Positives

Not Applicable

   How To Respond

When this alert fires, your first step should be to validate whether this user should be allowed to log into the server in question (i.e., if it's a question of out of date or inaccurate lookups). Next, validate whether there is a permissions issue that should have prevented the login, and whether the login was with malicious intent or merely an accident.

   Help

User Login to Unauthorized Geo Help

This example leverages the simple search assistant. Our dataset is an anonymized collection of Windows Authentication logs. For this analysis, we are combining the authentication logs with a lookup table that indicates what country the server is a part of and what resources a user is permitted to access, so that we can detect users who are logged into servers in countries they're not permitted to (e.g., a US user logging into a Germany server).

SPL for User Login to Unauthorized Geo

Demo Data

First we bring in our basic demo dataset. In this case, a list of anonymized Windows events. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Now it's time for enrichment. First we pull a lookup associating hosts with the countries to which they belong. Most organizations who desire this detection will pull this data from a CMDB which lists physical server location (as most countries that have the greatest concern also have requirements that data stay local). However, you could also look at this based on the country of origin of the people whose data is on the server, as is done in the similar GDPR example.
Now we need to see what users are authorized to log in here. This lookup doesn't need to list all associations, just those for countries that are problematic. Because it's probable that many users will be permitted to log into multiple hosts, we are doing an mvexpand to break the value into multiple values based on a pipe (|) between them. You could also replace this with a lookup based on LDAP OU or group membership to determine what users are permitted to log on in Germany.
We've got the enrichment done, now we can look for users logging into hosts where they're not permitted. We are also constricting the list of countries that are in-scope for this detection. Most people who ask for this detection are looking specifically at Germany or Japan, but you can include any countries you desire here.
We're about to do a stats, and we have a multi-value field here. This means we could end up with many rows accidentally. If a user was permitted to log into 15 different countries, a stats by country would result in 15 rows -- very confusing! Much easier to combine the authorized countries back into a comma-separated list so that the analyst has all of the information consolidated for them.
Because it's very easy to generate a large number of login events, we are counting the number of logon events (and unique server names) by user, authorized geo, and server geo.

Live Data

First we bring in our dataset, in this case of successful Windows security events.
Now it's time for enrichment. First we pull a lookup associating hosts with the countries to which they belong. Most organizations who desire this detection will pull this data from a CMDB which lists physical server location (as most countries that have the greatest concern also have requirements that data stay local). However, you could also look at this based on the country of origin of the people whose data is on the server, as is done in the similar GDPR example.
Now we need to see what users are authorized to log in here. This lookup doesn't need to list all associations, just those for countries that are problematic. Because it's probable that many users will be permitted to log into multiple hosts, we are doing an mvexpand to break the value into multiple values based on a pipe (|) between them. You could also replace this with a lookup based on LDAP OU or group membership to determine what users are permitted to log on in Germany.
We've got the enrichment done, now we can look for users logging into hosts where they're not permitted. We are also constricting the list of countries that are in-scope for this detection. Most people who ask for this detection are looking specifically at Germany or Japan, but you can include any countries you desire here.
We're about to do a stats, and we have a multi-value field here. This means we could end up with many rows accidentally. If a user was permitted to log into 15 different countries, a stats by country would result in 15 rows -- very confusing! Much easier to combine the authorized countries back into a comma-separated list so that the analyst has all of the information consolidated for them.
Because it's very easy to generate a large number of login events, we are counting the number of logon events (and unique server names) by user, authorized geo, and server geo.

Accelerated Data

First we bring in our dataset of success authentication events.
We rename Authentication.user to user and Authentication.dest to dest just to make the search easier to read and easier to write.
Now it's time for enrichment. First we pull a lookup associating hosts with the countries to which they belong. Most organizations who desire this detection will pull this data from a CMDB which lists physical server location (as most countries that have the greatest concern also have requirements that data stay local). However, you could also look at this based on the country of origin of the people whose data is on the server, as is done in the similar GDPR example.
Now we need to see what users are authorized to log in here. This lookup doesn't need to list all associations, just those for countries that are problematic. Because it's probable that many users will be permitted to log into multiple hosts, we are doing an mvexpand to break the value into multiple values based on a pipe (|) between them. You could also replace this with a lookup based on LDAP OU or group membership to determine what users are permitted to log on in Germany.
We've got the enrichment done, now we can look for users logging into hosts where they're not permitted. We are also constricting the list of countries that are in-scope for this detection. Most people who ask for this detection are looking specifically at Germany or Japan, but you can include any countries you desire here.
We're about to do a stats, and we have a multi-value field here. This means we could end up with many rows accidentally. If a user was permitted to log into 15 different countries, a stats by country would result in 15 rows -- very confusing! Much easier to combine the authorized countries back into a comma-separated list so that the analyst has all of the information consolidated for them.
Because it's very easy to generate a large number of login events, we are counting the number of logon events (and unique server names) by user, authorized geo, and server geo.

Screenshot of Demo Data