Threats tagged 'proofpoint.com'

Hi all, I am a cybersecurity analyst with 1 year and 6 month experience. Im writing this for fun and to teach some people who maybe interested and are at a beginner level on detecting suspicious sign in activity. In my example Im going to be using Entra ID, as this is the most common IAM solution and the one Im most familiar monitoring. First step is analyzing the alert you received in the queue. "Impossible travel time" or "Anomalous sign in activity" "sign in from bad IP" - These are the type of suspicious authentication logs that you will see in the SOC. Gather all the information: time generated (time of the sign in) app that was logged into (ex officehome, msgraph) username/email IP address device info (will normally be blank if its tuned properly, if its coming from managed trusted AD device it is a big indicator its benign so need to tune it to avoid FP for VPN usuage) locationdetails (will be crucial to see which location logged from, will determine later if its physical location or location from VPN server) user agent (crucial to detect what type of device it's coming from, potential spoofing as well) Then you can run a query like this (will differ greatly based off your SIEM querying lanaguage, Im using Kusto MS Sentinel) Signinlogs | Summarize count by timegenerated, appname ,userprincipalname, IPaddress, tostring(locationdetails), tostring(deviceinfo), useragent | where resulttype == 0 (filtering to see successful sign in attempts only) \^ use a query like this to gather all crucial details, we can then use the time range to see 24 hours and then compare past previous sign ins from last 2-3 weeks to see a baseline, for location, IP address, device info, to see if they have accessed that app before. Once you determine the sign in activity is indeed suspicious, its a combination of blank device details (non managed device), new IP address, new useragent or a suspicious useragent (potential spoofed), new app that's been used and potential impossible travel based off the last successful login). We need to analyze what type of IP address is being used, from either a VPN server or a ISP IP (will show approximate physical location of actual sign in). NEVER just focus on the IP reputation, vast majority of the true positives I caught are all coming from clean IP reputations, threat actors are smart enough to know that if their IP address has been flagged and reported numerous times, their sign in activity will be blocked. Analyze the ISP info, a threat actor MAJORITY of the time will be using an IP address from a suspicious VPN server, you can do a ISP search for that VPN name and most of the time it will be something foreign. Once you confirm the IP is coming from a suspicious entity such as a VPN server that is not authorized to be used in the company or its a VPN server with suspicious name, can confirm it's indeed malicious. From there you can quickly check Auditlogs table to see any major changes to the users account. Most threat actors will remove and change the comprised users MFA, will remove the comprised user mobile device and probably add theirs. From here, you can check the email logs and url click events on the suspicious link that was clicked for them to be comprised. Once you find that suspicious email you can plug that phishing URL into a interactive sandbox such as Browserling to confirm it. Some threat actors phishing sites are capable of detecting sandboxes and won't show their sign in page so be wary of that, but this isn't very common. After detecting all these suspicious events, you can begin to lock the users account, resetting MFA settings and starting the IR process and doing some forensics on what the threat actor did. Will have to look for: \- Potential data exfiltration attempts. Can detect this from email logs or web traffic logs. \- Potential lateral movement, the threat actor will likely send the same phishing email but this time from comprised users account to other internal users. Can detect this from email events as well. \- File modifications - the threat actor could have modified a file, deleted a file, for this can check logs such as office activity (365 events)

Phishing#netsec#redditGermany+9