Standardization, continuous flow, division of labor and reducing wasted effort. Those are terms that usually applies to mass production and are known mainly due to Henry Ford, but now we see those principles being applied even to an activities where it is not common.
Like during successful phishing
attacks. I am talking about cases when user is delivered email that routes him
to phishing site. Those are usually pretending to be login pages for Microsoft,
Google and many other popular portals. Once user insert his credentials, the
attacker collects those and forward it to the real service. When user has MFA
configured, the only difference is that attacker has to present the MFA request
to the phished user and then pass it to the original service, so there are
multiple stages but the principle of intercepting traffic is the same. Phished
user usually confirms the MFA request. Mainly because of the believe that he is
trying to login in a standard way to common portal/service. For such cases
attacker are using automated solution like Evilginx2 and many others that are
currently available. Those solutions are creating fake login portals of known
services, listens for a connections, grab credentials and MFA challenge and
forwards them to the original services, collect session cookies.
High level representation of the process is on the picture below and more details can bee seen on the picture source and some other aspects here: https://cloudbrothers.info/en/fido2-security-keys-are-important/#conclusion-mitigation-and-prevention
Picture source: https://m0chan.github.io/2019/07/26/Bypassing-2FA-For-Fun-With-Evilginx2.html
Up to now nothing new, nothing surprising.
But attackers are aware that once they gain access, it might be not forever.
Actually they may lose the access if there are some detections mechanisms for
suspicious access, unlikely travelers and similar. If the phished user password
is reset as well as session cookies they would need to phish the same user
again which is less likely. So attackers start to cooperate.
And very likely they divided the
roles. So the scenario may look like this: attackers receive information that
user was phished, they notify other available “buddies” and share the session
cookie with them and agree who is doing what. Then one (group) of attackers are
browsing the phished user inbox and searching for interesting emails with “juicy”
content; second group usually focus on creating a new inbox rule to move specific
emails to folders like Archive or Deleted and mark them as unread, then they
send new email to the user inbox and pick it up from specified folder. In such
email you can expect content for additional phishing email/s that is later send
from user mailbox to his contacts or new contacts collected by attackers in
previous cases. In some cases there is a third group that is trying to gain
persistence by registering additional MFA method to have the possibility to
return if needed. In cases where phished user has multiple services available within
one portal (for example SharePoint Files, Yammer,…) one group is focusing on
going through the available files, chat conversation and download content that
can be later reused (invoices, excel files, partner information,…)
Despite the typical session
validity is multiple days, attackers can finish “their investigation” within
couple of hours and the outcome is that they send from phished user additional
phishing emails or follows existing conversation where someone was requesting/expecting
invoice, Excel sheet and similar. Now imagine if you were in the contact with
the phished user, expecting some document and now it is finally sent, but this time
with malicious excel macro or invoice with account number of attacker. Any
chance you would get tricked?
Ok, now how you can distinguish standards
phishing case from the one where multiple attackers are cooperating by sharing
session cookie? It depends on how detailed your logs are, but lets imagine
ideal scenario. Fist you will see attacker sign-in log from IP that wasn’t previously
used by phished user (hopefully). Then you will see in non-interactive sign-in
activity additional IP addresses with different user-agent string. The same
will happen with the user portal (email) activities. You will see actions done
by attackers (again multiple IPs and user-agents) and each type of activity
will be specific to respective IP user-agent combination. For example: Opening
emails from IP x.x.x.1 and Mozilla x1; Create inbox rule from IP x.x.x.2 and
Mozilla x2; Open SharePoint file from IP x.x.x.3 and Chrome x1. And again you
wont find matching record for those IPs in sign-in logs.
Once you start to model available
logs and pivot on top of different variables (IPs, User-agent, Timestamps; type
of activities) you will see more and more that the activities looks like parallel
project streams done by different individual/groups that follows similar goal –
complete all the recon, phishing forwarding, data collection in a fast and
effective way and then disappear.
