Investigate Fake Accounts incidents

Fake Account (FA) incidents refer to fraudulent accounts created with fabricated or stolen information. Whenever HUMAN Sightline mitigates FA, it’ll record them in the Recent Attacks dashboard as either single events or network events. Single events are isolated incidents, while network events are unique HUMAN detection events where Sightline detected shared identifiers across multiple compromised accounts that indicated these incidents originated from the same attacker or group or attackers. Once these incidents are recorded, you can investigate each one to learn more about how Sightline mitigated this incident, what suspicious activities occurred, and ultimately resolve the incident.

While each process will be different depending on the incident and your organization’s needs, you can follow the steps in this article to start investigating single or network FA incidents. See Investigate Account Takeover incidents for information on investigating ATO.

👍

Tip

You can search for any account ID from the Fake Accounts investigation page regardless of whether that account was recently under attack. This means you can check any ID and see if it had an FA incident, even if that ID does not appear in Recent Attacks.

You can also use HUMAN Insights to generate AI insights about your incidents as well. Note that Insights are still experimental.

Prerequisites

• Configured Policy Rules to mitigate incidents.
• The incident’s Account ID to search for and start investigating it.

Investigate single FA incidents

Single FA incidents refer to an isolated fake account created to access your applications. When this occurs, it can be helpful to investigate the incident to ensure that the proper mitigation was done.

1. Browse for incidents

To get started, you need to search for an affected account or incident to investigate.

1. Navigate to Sightline Cyberfraud Defense > Explore > Visitors > Recent Attacks.
2. From the Fake Account tab, find an incident to investigate. You can do this in two ways:
   1. Browse the list of incidents
   2. Search the Account ID of the specific incident you want to investigate.
3. Click the incident to open its Investigation page.

2. Review the incident

When you first start investigating an incident, it’s important to understand what risky activities and triggers caused Sightline to identify this incident as FA.

First, we recommend reviewing the Account Overview for the Account Registration Date, as fake accounts tend to be newer accounts, and Targeted activities, which are the tasks the attacker attempted to perform on the sensitive account-related paths that Sightline monitors. Sightline combines targeted activities and overall risk score to determine how risky the behavior is before mitigating an incident. We recommend that you understand what these were as well so you can get an idea of what triggered the mitigation. For example, the sample incident below targeted routes related to resetting passwords, registering an account, and logging in. We should also note that it was created on July 16th. This can be useful information later.

Next, we recommend you review the Account Activities Timeline. While the Overview helps you understand what occurred, the Timeline helps you understand when it occurred. This is important for determining a precise history of when the risky activities happened, and you can filter the timeline by specific risky activities. Using the same incident example as above, we can see that this account had one period of risky activity before Sightline mitigated it. Additionally, we know that the account was created on July 16th, and Sightline detected risky activity within one day. This can support the conclusion that this is a fake account, since we typically wouldn’t expect risky activities on a legitimate account so soon after it’s registered.

Risky activities are marked and color coded on the Timeline. You can hover over the risky activities to get a breakdown of the precise activities that occurred during that time. You can also hover over the policy rule or action when they were triggered to learn which of your rules and actions were used to mitigate this incident.

3. Get detailed incident activity information

The Activities Log lists out each activity taken on the account in a detailed log so you can get granular insights on each activity, including the time and date of the activity, the path the activity occurred on, the risk score, risk triggers, and more. You can edit the columns to customize the information displayed here. Be sure to take advantage of this log to find specific information about each activity you want to learn more about. If a certain column is not there and you would like to sort by that information, consider adding it as a custom parameter or contact us.

4. Compare incident activity to legitimate behavior

Now that you have detailed information about what triggered Sightline’s mitigation on this incident, we recommend comparing it to legitimate account behavior. Fake accounts are made with malicious intentions and don’t act the same way as users on legitimate accounts do, so if Sightline observes atypical, high risk behavior on new accounts, then it flags it as FA. By comparing between the risky activity and legitimate behavior, you can answer questions such as:

1. Does it make sense that these risky activities were flagged as incidents?
2. Was this incident correctly identified as a fake account?

First, we recommend reviewing the Reputation components. The email domain, IP address, and IP geolocation history reputations can help determine how reputable or trustworthy the account may be. Let’s continue to consider the same sample FA incident below.

From this example’s Email Domain Reputation, we can see that this account used a Yahoo email domain. However, email domains are typically not strong enough of an indicator for fraudulent behavior, and we need to consider other information to draw a conclusion.

So, let’s consider its IP Address Reputation next. In this case, we can see that Sightline has not classified this account’s IP address. This means that Sightline couldn’t categorize this IP as TOR, proxy, or from a data center. It doesn’t explicitly mean that this account is fraudulent. This means that we need to continue to consider other information about the account.

The last reputation to consider is the account’s IP Geolocation History. Here, we can see some interesting differences between this account and other accounts. While this account is based in the US, we can see from the distribution in this graph that legitimate US accounts are only 15% of total accounts. The other 85% of accounts are outside of the country that this account belongs to. Still, while this is unlikely, it’s clearly still possible and not entirely unexpected based on legitimate accounts’ population distribution. So while this might be unusual, we can’t conclude that this is a fake account just from this.

While we can observe some unusual characteristics about this account, we can’t assume it’s fraudulent based on this example’s reputation data. In order to come to a conclusion, we need to continue to investigate this account’s behavior. This can be done from the Behavior Distribution graph, which shows the population distribution against the number of repetitions an account performs a certain attack pattern. While it defaults to the pattern that Sightline detected activity on, you can choose different patterns with the Show by Attack Pattern dropdown selection. You can also choose a date to compare data to.

Let’s continue to investigate our example incident with the Behavior Distribution above. Here, we can track typical repetitions the legitimate users tend to complete deposits. As evidenced by the graph, nearly 70% of accounts attempt to deposit up to two times in a day. However, this account attempted to deposit eight times in one day. This puts the account in the 99th percentile of all accounts and makes it extremely suspicious because it acted very differently from a typical user. This is strong evidence that this is a fraudulent account.

To sum it up, because we know that Sightline flagged risky behavior within a day of this account being created from the Accounts Timeline and we can see that this account conducted highly suspicious behavior in the Behavior Distribution, we can likely conclude that this was indeed a FA incident.

👍

Takeaway

Be sure to compare incident activity to legitimate behavior with the Accounts Timeline, the Reputation components, Behavior Distribution, and, if needed, the Activities Log. It’s important that you resolve the incident based on all the data from all sources rather than just one.

5. Resolve the incident

Once you finish investigating an incident, it’s important that you resolve it so that it’s no longer pending and waiting to be looked at. You can also update the account status to a different attack type or mark it as not at attack at all. This not only updates your records, but updates HUMAN’s learning model to be more accurate on your applications.

To resolve an incident:

1. Click Update account status.
2. Click the Account status you want to update the account as, or leave it at Fake Account.
3. Add a note with any additional information, observations, or justification for your update.
4. Click Update & Resolve.

👍

Tip

You can also resolve accounts that Sightline did not detect an incident on by searching for the account’s ID and similarly updating its account status from No Attack to the attack type of your choice.

When you resolve the account, Sightline will add a new log entry to the Activities Log and move it to the Pending section in Recent Attack’s Fake Account tab.

Investigate network FA incidents

Network FA incidents refer to incidents where multiple fraudulent accounts shared identifiers, including accounts that may have looked legitimate on their own. These identifiers led Sightline to believe that all these accounts were part of a single attack campaign from the same attacker or group of attackers. Investigating these accounts as a single network rather than many seemingly unrelated individual attacks helps your organization make informed mitigation choices.

📘

Note

Sightline updates network events every 30 minutes. This adds any new accounts and removes stale ones, which are accounts Sightline has not detected in seven days.

1. Find the affected network

To get started, you need to first identify and search for the network event. Typically, you can identify a network attack by finding an individual account that was part of a network. You can then click Investigate the network to open the network investigation page.

However, if you already know about a network event and when it happened, you can also navigate to Sightline Cyberfraud Defense > Explore > Visitors > Recent Attacks. Then, filter by Network events to quickly find the incident you’re looking for.

2. Learn what triggered the incident

When you first start investigating an incident, it’s important to understand what risky activities caused Sightline to identify this incident as network FA and what its identifiers are. The network’s identifiers are at the top of the Linked Accounts By Network component, which also shows the number of affected accounts. In the example below, this network event shared VIDs, ASNs, a country, an email domain, and devices across all its compromised accounts. However, these identifiers can change per network.

Based on these identifiers, we can begin to evaluate if this was indeed a network event. Based on the example above, we can likely assume that these accounts were connected in an FA campaign. This is because some of these identifiers, while perhaps possible in isolation, become more and more unlikely to happen legitimately when considered all together. For example, while it is possible for 74 accounts to come from a single country in isolation, it’s unlikely that all of these accounts would only share two ASNs. This could indicate that the attackers attempted to create these accounts from a specific location.

Another example is that, despite there being 74 accounts, Sightline only detected two devices. It’s typically unlikely that 74 accounts, particularly newer accounts, would be created from only two devices. This could indicate that attackers used a set of devices to create the 74 accounts instead.

We also recommend you familiarize yourself with the risky behaviors Sightline detected for the network. These are indicated to the right of the network visualization and include the number of activities done per behavior. These behaviors are determined by the sensitive routes you asked Sightline to specifically monitor for account-related incidents. In the same example, this network incident focused primarily on login attempts.

Based on the number of activities per behavior, we can also conclude that this was likely an FA network. This is because, across 74 accounts, there were 631 login attempts alone. If we assumed all these accounts were legitimate, then 631 is a very high number of login attempts for the number of accounts involved. So, we can likely assume that attackers were attempting to log in with fake accounts instead.

👍

Takeaway

Use a combination of the number of identifiers and risky behaviors to determine if it makes sense that this incident was flagged as a network incident.

3. Evaluate the connections between accounts

Once you have a general idea of what happened during this network attack, we recommend investigating the connections between accounts in combination with identifiers Sightline detected. Assessing these helps determine if it makes sense that Sightline flagged these accounts as part of an incident.

This evaluation can differ slightly based on the type of network event you’re investigating. Some network events may have multiple VIDs, while others may only have one VID. You can learn about evaluating either case below.

Networks with multiple VIDs

Networks with multiple VIDs show the connections between each VID and all the accounts that used them. You can hover over each account to learn which VIDs it's connected to or over each VID to see how many accounts are related to it. An example of this is shown in the visualization below.

👍

Tip

You can also click on a VID to open the accounts associated with it in the control panel, copy it, or filter the Activities Log by it.

In this example, we can observe there are 74 accounts that are connected in some way or another to only eight VIDs. In particular, VID 2 is shared by 72 accounts. This alone strongly indicates that this was a case of a fake account campaign across all these accounts, since it’s very unlikely for that many accounts to share one VID. We can observe similar connections across multiple VIDs.

📘

Note

Sometimes, you might see disconnected clusters of accounts and VIDs from the main network. This happens when Sightline has not observed the account that connected them to others in seven or more days. However, these are still considered part of the network and are therefore displayed in the visualization.

Networks with a single VID

Networks with a single VID typically have accounts that share a single identifier instead. These accounts don’t show connections like in visualizations with multiple VIDs, but instead group together the accounts by identifier like in the example below. To determine whether an incident is a network event, we should evaluate if it makes sense for the accounts involved to have the shared identifiers that Sightline flagged.

In this example, we can observe that there are 20 accounts shared by multiple identical identifiers: the VID, the device, the ASN, the country, and the email domain. Based on the VID alone, we can likely assume that this is a case of network FA, as it’s very unlikely for 20 accounts to have the same VID.

Additionally, we can see that these 20 accounts shared two IP addresses, and the visualization separates the accounts into two groups representing this. Not only did these 20 accounts share an identical VID, but 19 of them came from the same device. We typically would not expect this for legitimate accounts, which helps us conclude that this is likely a network event.

4. Get detailed incident and account information

The Activities Log lists out each activity taken on each account in the network as a detailed log so you can get granular insights on each activity, including the time and date, the path, the risk score, risk triggers, and more. You can edit the columns to customize the information displayed here. Activities that are network-exclusive, or activities that occurred on a set of accounts in the network rather than individual ones, are highlighted in yellow so you can quickly differentiate them. Be sure to take advantage of this log to find specific information about each activity you want to learn more about. If a certain column is not there and you would like to sort by that information, consider adding it as a custom parameter or contact us.

You can also use the control panel to get detailed information per account that’s involved in the network. To open it, click Open control panel from the Network Attack overview component. You can sort this list with the options in the Show by menu and toggle open each account to learn more about the risky behaviors Sightline flagged on each. This is useful for evaluating each account within the context of the network. If needed, you can also investigate or filter by each account from here as well.

5. Resolve the incident

Once you finish investigating the network, it’s important that you resolve the accounts involved in it. You can resolve network events via the control panel, which lists all accounts involved in the event. Each resolution is per account, and you can resolve an entire network event by resolving all of its accounts. You can also update the account status to a different attack type or mark it as not at attack at all. This not only updates your records, but updates HUMAN’s learning model to be more accurate on your applications.

To resolve an incident:

1. Click Open control panel.
2. Select each account you want to resolve, or click Select all to choose all of them at once.
3. Click Update account status.
4. Click the Account status you want to update the account as, or leave it at Fake Account.
5. Add a note with any additional information, observations, or justification for your update.
6. Click Update & Resolve.

When you resolve the network incident, Sightline will add a new log entry to the Activities Log and move it to the Pending section in Recent Attack’s Fake Account tab.