Malicious URL Access Detected

Malicious URL access detected means when a user or host attempts a connection to a malicious website, like phishing pages, malware, or command-and-control (C2) infrastructure.

This access is flagged as a security concern; hence, immediate investigation is required to prevent potential breaches.

The Discovery:

Ravi started hurryingly from home to the office as his shift timings started; he also needed mocha coffee at the beginning of his shift, so he grabbed a coffee from the work cafe and opened the dashboard. One particular offense catches his eye among the routine alerts: "Malicious URL accessed by a user account."

The Investigation:

The rule flagged a scenario where a user accessed a URL known for hosting malicious content or malware category URL. A quick lookup revealed the URL was part of a malware category identified in free online scanning service tools.

1. Malicious URL Category: Malware
2. Malicious URL: http://free-rewards-now.com
3. Time of Access: 10:32 AM
4. User Account: lucy.k@company.com
5. Source IP: 192.168.1.45

The URL had been identified in external threat intelligence feeds as a malware site that distributes malware disguised as reward offers.

Ravi also opened the site in isolation and checked it; this site asked for credentials. This site provides coupons or offers.

He also analysed the site and considered how the user might connect. 

Does any email have this site?

He checked the logs on the URL; he found the IP for this URL hosted,

You can find out by pinging this URL from cmd or searching in Censys search, url void, etc.

He checked the logs of the remote IP; he observed Lucy's events that she accessed this malicious URL.

The Possible Culprits:

1. Phishing Attack: The malicious URL was embedded in a fake promotional email.
2. Malware Delivery: The URL likely hosted a payload designed to infect the user's system.
3. Users may click this link for coupons
4. Command-and-Control: The URL may have been part of a C2 server network.

The Attack:

This attack is observed because the URL is a malicious category with a risk of 10.

Ravi observed this URL is allowed on the proxy,  

1. He clicked the link, which redirected him to a webpage, prompting him to "Enter his details."

If the user provides the organisation credentials, this seriously impacts the organisation, as user credentials leak.

After checking the email gateway logs, Ravi found a mail with a free coupon subject.

Further checking on the particular subject, only Lucy got this mail from the malicious sender.

Response:

Ravi immediately followed the incident response protocol: This incident was assigned to relevant teams.

1. Containment Phase:
   • Blocked the URL at the proxy level to prevent further access.
   • Blocked the IP at the firewall level to prevent further access
   • Immediate Password reset
   • Isolated Lucy's workstation from the network.
2. Eradication Phase:
   • Checked Lucy's workstation for any signs of malware infection.
   • The AV team scanned the host; no detections or traces were found on the antivirus.
   • The observed malicious URL was added to the organisation's blocklist to prevent future access.
   • The observed remote IP was added to the organisation's blocklist to prevent future access.
3. Lessons Learnt:
   • Recommended enabling advanced email filtering to detect similar phishing attempts.
   • Updated threat intelligence feeds to monitor similar malicious domains.
   • Educated Lucy on recognising phishing emails and safe browsing practices.

Rule Logic Reference:

This rule can be written two ways

1) To detect when the URL is malicious

1) IF (Log Source = "Web Proxy Logs")

AND (URL Category = "Malicious")

AND(Confidence of risk/reputation > 75)

AND (Access Attempt = "Successful/Blocked")

THEN Trigger an Alert

2) To detect when the destination IP is malicious 

IF( Log Source = "Firewall")

AND (Access Attempt = "Successful / Permit)

AND when destination IP is categorized by X-Force as [Anonymization Servers|Botnet C&C|DynamicIPs|Malware|ScanningIPs|Spam] with confidence value >75

Tip:

Monitoring this below condition enhances security :

Detect when this URL is categorized by X-Force as [Gambling|Auctions|Job Search|Alcohol|Social Networking|Dating] 

Ravi got applause, felt very happy for remediating this and slept that day without any worries. 

Multiple VPN Logins From Different Countries

Multiple VPN Logins From Different Countries means that the same user account is trying to log in from multiple geographical locations through VPN endpoints within a short timeframe. While VPNs are commonly used to hide a user's actual location or to access services securely, such behaviour often indicates suspicious activity, particularly when the logins span different countries.

As a SOC analyst, Sarah starts her day with tea and biscuits and refreshes her dashboard every minute; she gets new alerts. Among the usual login attempts, a peculiar pattern grabs her attention.

“Multiple VPN logins from different countries or different IPs, all tied to the same user account?” Sarah cries to see multiple alerts; after checking, She knows this isn’t normal.

The Investigation:

 The rule flags a scenario where a single user account is seen logging in from different IPs through VPN endpoints from geographically distant countries, often within a short span of time. For example:

• At 10:05 AM, the user logs in from a VPN server in Germany.
• At 10:15 AM, another login appears from a VPN server in Singapore.
• Moments later, the same account accesses a VPN endpoint in Canada.

While VPNs can mask a user’s physical location, this kind of behaviour suggests one of two possibilities:

1. The user is hopping between VPN servers at lightning speed (unlikely in most legitimate cases).

2. The account credentials have been compromised and are being used by attackers from multiple locations.

"Detections can also occur within the same country. Even in such cases, they should be considered suspicious. The two IPs you observed are from Jio and Airtel, which might indicate that the user switched networks from Jio to Airtel. However, this activity should be considered as  suspicious behaviour as same user connecting to vpn from two different IP's

The Possible Culprits

• Credential Theft: Attackers often exploit stolen credentials to access organizational resources.
• Malicious Activity: Such logins could be used to exfiltrate data, install malware, or execute attacks.
• Evasion Tactics: Attackers might use multiple VPN logins to bypass geo-based restrictions and confuse monitoring systems.

The Attack:

An attacker gains access to an employee’s VPN credentials.

One attacker logs in through a VPN endpoint in Russia, while another attacker, using the same credentials, logs in from Brazil.

Within moments, the account shows activity from a third endpoint in Hong Kong.

Response:

• Sarah followed the incident response protocol and promptly notified all relevant infrastructure teams, including the Firewall Team, AD Team, and Service Desk Team.
• After obtaining the required approvals, the AD Team and Service Desk Team immediately disabled the compromised account and reset the user's password. Meanwhile, the Firewall Team blocked all associated IPs.
• After resetting the credentials and notifying the user, Sarah received an update that the logins were not recognized by the user.
• She conducted a deeper investigation and discovered evidence of credential theft through a phishing email.
• By reviewing the logs of the sender's address and the email subject line over the past seven days, she found that the phishing email had been sent only to the victim.
• Since only this user was affected, mitigations were applied, including resetting the password and unlocking the account.
• If the attacker successfully logged in using the stolen credentials, Sarah reviewed the user's activities to identify any unauthorized changes and implemented rollbacks where necessary.
• To prevent similar incidents in the future, she recommended strengthening policies and enhancing security measures.

Rule Logic Reference

IF (Log Source = "VPN Logs") 

And (Event Name = "Login Successful") 

And (Count of Logins by Same User >= 2) 

And (Timeframe <= 15 minutes) 

And NOT (UserID IN Exclusion List) THEN Trigger an Alert -> ( create a reference set and exclude)

And when at least two events are seen with the same username, event name, and different source geographic country /region in 2 hours

Tune accordingly to your customer.

The Moral:

Vigilence is a key , By setting up rules like Multiple VPN Logins From Different Countries, can detect compromise early and take action.

This not only safeguards user accounts but also protects critical resources from malicious actors.

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.

 

Impossible Travel Activity | Use Case Analysis

It was a regular Monday morning in the IT security operations centre. Analysts were monitoring login activity when an "Impossible Travel" alert was received in the SIEM.

The Analyst opened the events and saw something odd.:

• At 9:00 AM, Sarah, the sales manager, logged in from her home in California.
• At 9:45 AM, her account showed another login from Paris, France.

"That's strange," "Sarah can't possibly fly from California to Paris in 45 minutes. Something's up."
 
The Investigation

The Analyst began digging deeper. He pulled up the logs for Sarah's account:

• The first login from the California IP address was legitimate because the Analyst got update that logins from the California region from her are approved.
• The second login from Paris IP

"Looks like someone might have stolen Sarah's credentials," the Analyst thought.
But before jumping to conclusions, he needed to rule out other possibilities.

The Possible Culprits

1. VPN Usage: "What if Sarah used a Virtual Private Network (VPN) that routed her connection through Paris?" Anil considered. However, checking the logs confirmed that no VPN was in use.
2. Credential Sharing: "Could Sarah have shared her password with a colleague or friend in Paris?" This was possible but unlikely, as Sarah had recently completed a security training program emphasizing the dangers of password sharing.
3. Compromise: The most likely scenario was that Sarah's credentials had been stolen—perhaps through phishing or a previous data breach.

The Analyst has followed the incident response and created the incident.

The Response:
The analyst quickly followed the incident response protocol:

Account Lockdown: Account lockout must be done until further verification from the user, so we recommend the team deactivate Sarah's account to prevent further misuse temporarily.
User Verification: Analyst/Incident response team called Sarah to confirm her activity. She was shocked to learn about the Paris login and confirmed she wasn't travelling.
Incident Analysis: Analyst examined the suspicious login further and found evidence of brute force attempts on Sarah's account over the weekend.
Credential Reset: Sarah's account password was reset, and Multi-Factor Authentication (MFA) was enforced to add an extra layer of security.