Recently, one of our healthcare client’s end users (an employee) was the target of a phishing attack that resulted in a security incident.
How the attack started:
The attack started when the employee received the following email:
While, at a glance, this email might look real, it’s not. The scammers who send emails like this one do not have anything to do with the companies they pretend to be.
Red flags spotted from the email:
If you look closely, the FROM ADDRESS had an unfamiliar subdomain. Though Microsoft uses many subdomains, @security-acc subdomain is not one of them. The images were blurry and not coming from an original source. Instead, the images were coming from a URL shortener.
Finally, all three hyperlinks were directed to one URL. That URL was not Office 365 or its affiliates.
A link to a normal-looking website?
Clicking on the link opened up a website in the end user's default web browser application – in this case, Microsoft's Sign In page.
The website looked similar to this:
Red flags on the phishing website
After entering a username, it continues to the password page with the same red flags as before.
Something is wrong:
After submitting a password, it redirected him to the Microsoft Privacy page (the legit one) while the username and password information was sent to the phisher.
Alerting IT, determining the scope of the problem
We received an email notification from our Security Operations Center (SOC) regarding a suspicious sign-in from an unauthorized country.
It appears that the attacker’s fake Microsoft website had successfully harvested the employee's company login credentials – and resulted in a password compromise.
Malicious emails were sent from his account to vendors/customers persuading them to send payments to updated bank accounts that were owned by the attackers. Then the hackers created a mailbox rule to delete all inbound traffic to hide any response from the human user.
Change your password - NOW!
This was suddenly a potentially very serious security incident. We immediately took the following remediation steps:
Reset the user’s compromised password enabled MFA for all employees to avoid this in the future.
Checked other accounts that were re-using the same compromised password, and reset those passwords too (this incident illustrates why it’s a bad idea to re-use passwords)
blocked the account from signing in, which would have required manual interaction by a Network Doctor admin to “unblock” the account and pretty much prevented further compromise. Otherwise, the attacker could have easily signed back in after getting knocked out, failed to succeed, and proceeded with attempts to guess and re-sign in with the “reset” password
Checked Outlook for suspicious activity (new forwarding rules, changes to account settings, email forwarding addresses, etc)
Informed other employees about the phishing email and scheduled a cybersecurity training for the entire company
Fortunately, the attack was detected and mitigated relatively quickly and no permanent damage was done.