Unfamiliar Sign-In

Unfamiliar Sign-In means a security event where a login attempt is detected from a device, location, or IP address that was not previously associated with the user's account. This behaviour is flagged as potentially suspicious, as it could indicate unauthorized access or credential compromise.

Let's discuss the Tale of the Unfamiliar Sign-In.
It was a calm Tuesday evening, and the IT security team was humming quietly, showing no major incidents. Priya, A SOC analyst on her evening shift, sipped her coffee, expecting a routine session. Suddenly, an alert lit up her screen: "Unfamiliar Sign-In Properties Detected."

It was the mystery login.

The alert pointed to user Aladdin; Analyst Priya checked his profile in the o365, Service Now, and other availability tools and came to know he is a senior developer known for his diligent work habits. The system flagged a login attempt to the company’s internal tools from a device detected as suspicious.

“Hmm,” Priya thought, and checked Aladdin's logs for the last 3 days and found out his usual device was “MacBook".
But the alert says  Windows device, and it’s coming from an IP address in an entirely different city—Lucknow.”

What made it more suspicious was the timing:

• The attempt was made at 2:00 AM, far outside Aladdin’s regular work hours.
• The system also noted a mismatched User-Agent string, hinting at a possible spoofed device or browser.

Priya also identified other logs that Aladdin accessed multiple websites having suspicious categories after successfully connecting to the network,
However, all URLs are blocked on proxy because of the proxy rule.

Uncovering the Truth
Priya Immediately raised an incident, sent a mail to the AD Team, Security Team, Service Desk Teams, and began her investigation:
Device Check:
She reviewed with the AD team about Aladdin’s registered devices in the Active Directory. None matched the one used in the suspicious login attempt.
Geolocation Analysis:
The IP address was traced back to Lucknow, a city far from Aladdin’s home and office. Aladdin had no travel plans logged with HR.
Login Pattern Review:

She pulled up Aladdin's historical login logs. He typically worked from his MacBook in Bangalore between 9:00 AM and 8:00 PM. This 2:00 AM login from an unknown Windows device seems suspicious.

The Call
All teams worked in bridge call to mitigate this incident; they immediately contacted Aladdin. Groggily, he answered, “What? No, I didn’t log in at 2:00 AM. I was asleep.”
That confirmed it—this wasn’t Aladdin’s doing.

The Response
Priya swung into action:

Account Lockdown:
She temporarily disabled Aladdin’s account to prevent further unauthorized access and Remote IP that was observed blocked on perimeter firewalls.
Incident Logging:
She documented the event, noting the unfamiliar device and IP address.
Enhanced Investigation:
Priya checked for other anomalies tied to the suspicious IP. This revealed several failed login attempts across multiple accounts towards O365, hinting at a broader brute force attack.
Credential Reset: 
Aladdin’s password was reset, and he was required to enable Multi-Factor Authentication (MFA).
Cross-Check with Threat Intelligence: 
Priya searched for the flagged IP address in threat intelligence feeds and open source tools like Virus Total, IBM Xforce exchange, MX toolbox, etc. It was listed as part of a known botnet.
Priya also checked the logs from 2:00 AM to 4:00 AM to see what kind of activities Aladdin performed from his account.
Based on that, she took all remediation steps and enforced tight security.

Lessons Learned
All the findings were that the documented incident was resolved within SLA, minimised the threat, and stopped without a breach, but the team treated it as a wake-up call and implemented below-mentioned measures:

Stronger Policies: 
Enforced strict device registration for all employees.
MFA for All: 
Enforced Multi-Factor Authentication is mandatory for every account.
Enhanced Anomaly Detection: 
She tuned the Unfamiliar Sign-In Properties rule to consider additional factors, like known bad IPs, and also created a new rule for Unauthorized login from non-business hours.
Training and Awareness: 
She recommended providing training and Educating employees about not sharing credentials, phishing attempts and the importance of reporting unusual account activity.
Priya’s vigilance and the "Unfamiliar Sign-In Properties" detection rule minimised the risk and further prevented what could have been a significant breach. The story became an example in the company’s next security training session, reminding everyone that even the smallest anomaly could hide a major threat.
And Priya? She ended her shift knowing she had made a difference, proud of how quickly and effectively the team had responded.

 

Types of accounts in Windows | Windows Accounts

Windows Account Types

 

References :

Local and Domain Accounts

Types of windows accounts

Windows | Multiple Login Failures from a Single User Analysis

Multiple Login Failures from a Single User

Objective:

The objective of this use case is to identify brute force attacks that could be dictionary attacks or password spraying attacks.

Scenarios for identifying a brute-force attack is

When multiple login failures occur 10 times from the same username within a specified time frame (e.g., 5 minutes).

Let's assume the user is trying to log in to a Windows service but is failing; the most common failures are

0xC000006A - The username is valid, but the password entered is incorrect

0xC0000064- The username does not exist in the system.

0xC0000234- The user account is locked due to multiple failed login attempts.

0xC0000071- The user's password has expired and needs to be changed

0xC0000072 - The account is disabled and cannot be used for login.

The service shows incorrect credentials as an error.

Analysts can see the error codes, event ID, and logon type in the logs and identify the failure types.

But the main motto of analysts is to detect attacks,

Let's talk about Scenarios.

Scenario 1:

There is a huge number of failures from the same user in 5 minutes; assume the failure count is 1000

Analysts need to identify the reason for the 1000 count from the same user,

Here, there are chances for the attacker to use the same username against multiple passwords, or it can be the genuine login from the user, but 1000 failures are counted because of some misconfiguration because few services would authenticate with the user credentials.

Users will not know that these many authentications are coming,

Any how that needs to be identified,

Clues :

1000 authentication failures on multiple domain controllers,

5 Failures because of 6A error

event ID is 4625,

logon type 3(Network logins) ,

followed failures because of 234( user account lockout).

there is also a password change event,

There are successful logins after 10 minutes, followed by failures.

Analysis:

Follow the incident response, raise an incident with the team, or check with a user about these failures to determine whether these are genuine or not.

Update from the user.

The user gave an update that he forgot his network credentials, and the user also gave an update that he only tried 3 to 5 times, and he changed the password.

Analysts need to do further analysis; in the logs,

Please refer to the reason for domain controller failures on multiple DCs here.

Here the failures on multiple domain controllers are observed; in the 5 minutes, check followed logs, there are successful logins, only one account lockout, and a password change event; it is clear that these are network credentials that can be towards some shared network, and

The user confirmed that these are genuine failures,

There is no risk, but when it comes to security threats, there are also chances that, at the same time, the attacker tried his user name against multiple passwords,

Assign to the relevant team, for instance, the Windows team,  further investigation on many failures because this incident is subjective to security.

Analysts can suspect these are because of some process login automatically, and DC's were not because of sync.

But  there should be confirmation of these failures,

Windows team Update:

These failures are because DC sync did not happen around the time frame; we observed that the password got changed; you may close the incident.

After receiving an update from the Windows team, please close the incident.

Crystals:

If the other users also get more failure counts, ask the Windows team to check what service is causing these many failures and ask them to raise a case with OEM for confirmation.