Every month, the Pondurance team hosts a webinar to keep clients current on the state of cybersecurity. In July, the team discussed threat intelligence, notable vulnerabilities and trends, security operations center (SOC) updates, and SOC engineering insights.

The Principal Digital Forensics and Incident Response (DFIR) Consultant discussed attacker-in-the-middle (AiTM) phishing and what the incident response team usually sees when responding to these threats, specifically those involving emails.

AiTM attacks are when an attacker covertly intercepts and modifies emails between two parties and uses these communications for malicious gain. These attacks have become more popular over the last several years, mostly due to the widespread implementation of multifactor authentication (MFA) for email. Years ago, threat actors used phishing kits, but MFA has reduced the window of opportunity for success, forcing threat actors to migrate to AiTM attacks to access the network.

Launching an AiTM attack requires four steps:

1. Phishing emails are sent from a compromised trusted source. Threat actors use legitimate email accounts from known co-workers and executives within a company to initiate the attack.
2. Phishing emails direct users to a phony login page. Once users click on the email, they are redirected to a phony login page — the legitimate web page (most often a Microsoft 365 page) with the AiTM framework — that will then prompt users for their credentials. 
3. Users submit their credentials. With MFA, users submit their credentials at login on the legitimate web page. However, this submission is not considered a true MFA bypass since MFA is legitimately satisfied but through the phishing kit.
4. Threat actors work toward their goals. At this point, the phony login page usually goes blank. The team sees an “I could not open the file” reply in the user’s inbox and observes that the AiTM page relayed the MFA response and intercepted the session token. Then, once the threat actors gain access, they send out mass phishing emails, hoping to find a user email account that can help them execute a wire fraud or other financial scam. As the attack proceeds, threat actors add their own MFA devices to the compromised accounts. That way, if they get locked out, they can regain access to the account without MFA.

The Principal DFIR Consultant also discussed the difference between token interception and token theft. In token interception, the token never makes it to the user, which is what happens in AiTM attacks. The user simply logs in, and the threat actor intercepts the communication and compromises the user’s credentials to gain access. In token theft, the threat actor actually steals the authentication token from the user’s browser, which is much more difficult than token interception. 

To prevent an AiTM attack, user training can help employees identify suspicious emails and web pages and know when to report an incident to the security or IT department. The team suggests that a branded login page can help an employee identify whether an email is legitimate. Also, a password manager, especially one tied to a URL, is beneficial because it can autofill a user’s credentials in most instances but not on a phishing site.

Vulnerabilities and Trends

The Vulnerability Management Program (VMP) Team Lead reviewed notable vulnerabilities from June and July. As many as 3,400 vulnerabilities were disclosed, and 15 of those vulnerabilities were high risk. Of those 15, four of the vulnerabilities had publicly available proof-of-concept codes on the internet, and six were known to be exploited in the wild on products including Google, Microsoft Windows, Linux, Check Point, Veeam, SolarWinds, MOVEit, and Zyxel. The VMP Team Lead talked in detail about a few of these vulnerabilities:

• The PHP for Windows vulnerability (CVE-2024-4577) is a remote code execution vulnerability that had a grand-scale patch released on June 6. Over the next few days, proof-of-concept scripts appeared on the internet. Then, almost immediately, scanning was observed for vulnerable servers. This vulnerability was successfully exploited using TellYouThePass ransomware, where the victim saw a VBScript executed in memory, and then, formation of a successful command and control connection was used to deliver additional malware, encrypt the files, and exfiltrate them. 
• The path traversal vulnerability (CVE-2024-28995) impacted the SolarWinds Serv-U file transfer product. A patch was released on June 5, and a week later, proof-of-concept codes appeared on the internet. The exploitation occurs with a GET request that references internal directory and internal file. Typically, a GET request would use a forward slash on a Linux device and a backslash on a Windows device. However, this exploit attempt uses a backslash on a Linux device and a forward slash on a Windows device. When the path traversal filter sees this request, it allows it to go through rather than block it. A few steps later, the code looks at the GET request, sees that the slashes are incorrect, and corrects them, allowing the exploitation.
• The SSH vulnerability (CVE-2024-6387), nicknamed regreSSHion, is a remote code execution vulnerability that impacts specific Open SSH versions — particularly early versions and later versions — and could allow the threat actor to get root privileges on the affected system. The threat actor initiates thousands of connection attempts during the SSH authentication process, triggering a race condition. Then, there’s a repeated setting and resetting of the LoginGraceTime. Eventually, the memory layout becomes corrupted, leading to potential heap corruption and code execution.

This SSH vulnerability attack is difficult for threat actors to execute for a few reasons. It’s a time-intensive attack that can require up to 10,000 attempts and can take days to complete. In addition, the attack is more difficult on a 64-bit system due to the larger memory, the attack is harder to execute on a system that has denial-of-service and brute-force protections operating on it, and the attack can only occur when Open SSH is running on a Linux system that’s used in a specific C library. For these reasons, the team expects that this vulnerability will be exploited only in targeted attacks rather than as a mass exploitation event.

The SOC Analyst talked about recent trends that the SOC team observed in June and July. He started by discussing activity from Storm 1811, an advanced persistence group that uses Quick Assist with social engineering to leverage its victims’ systems. The attack initiates by getting the victim to install the Quick Assist application and furthers as the threat actors establish persistence and command and control. The team has seen a huge uptick in these types of cases and has diligently addressed these incidents on a case-by-case basis. Typically, the team blocks Quick Assist as a best security practice.

In addition, the SOC Analyst discussed the top three alert drivers that the SOC observed in the 30 days prior to the webinar.

• Unfamiliar sign-ins. The SOC escalated 329 instances of unfamiliar sign-in cases to Scope. This alert triggers when something unusual occurs in a particular factor of a login, such as an IP, geolocation, or current agent. The best practice is to ensure that even familiar logins are challenged. Organizations should always enable MFA and limit geolocations that indicate specific IPs that are accepted.
• Clicking on malicious links. The SOC escalated 93 of these cases to Scope. The best way to prevent this type of attack is user training that teaches employees not to click or open an email or document that is unexpected and to reach out to the SOC or appropriate communication channel if an email or document looks suspicious.
• Password spray. The SOC escalated 43 of these cases to Scope. A password spray is triggered when a large number of users are served from a single IP address in an atypical behavior. The team emphasizes the importance of social engineering training, recommends MFA combined with strong password policies, and stresses how important it is not to use default credentials or reuse passwords. 

The Technical Advisor of SOC Engineering discussed a few ways the SOC is addressing phishing, AiTM, and business email compromise (BEC) attacks.

As an important new way to prioritize threats, the SOC has developed a composite scoring rule by creating multiple queries within an alert rule that pivot off of known bad tactics, techniques, and procedures (TTPs). These known bad TTPs are gathered from threat intel sources, the DFIR team, and the SOC’s own logs. As the intel sources and DFIR team encounter phishing, AiTM, and BEC cases, they provide the SOC with specific indicators of compromise, such as specific user agents, and other indicators that can be flagged as malicious.

Once the SOC has a good grouping of known bad TTPs, the team assesses them and rates the severity of the alerts based on multiple indicators. That way, the SOC can identify the priority level of each event and properly address the most severe threats first. For example, if a single alert comes in with a score of 20, it may not reach a threshold that requires action. But if a single alert reaches a score of 50, the team may mark it as a priority 3 event, and analysts will address it at that priority level. If an alert has a score of 175, the team will mark it as a priority 1 event to be addressed immediately because an account has likely been compromised. This new composite scoring rule allows the team to efficiently address threats in the order of importance to keep clients protected.

Another way the SOC can hone in on attacker activity is the use of Axios, a user agent employed in AiTM campaigns that can be used to identify an indicator of an attack. In particular, the team uses KMSI or “keep me signed in” as an indicator that an attacker is attempting to maintain persistence on a system. Also, a session ID — or any compromised session — is a good way to detect malicious AiTM activity using Axios. When the team sees KMSI or a session ID appear in Axios, it factors that into the composite score to prioritize the threat.

As always, the team asks clients to share their important hosts, significant IP addresses, VIP lists, honey tokens, and anything distinct to the network that can help it protect against threats.

The Pondurance team will host another webinar in August to discuss new cybersecurity activity. Check back next month to read the summary.