Suspected Threat Actors: Phosphorus APT (aka Charming Kitten)
The targets of this spear-phishing operation included former Israeli officials, high-ranking military personnel, research fellows in research institutions, think tanks, and Israeli citizens. Attackers leveraged custom phishing infrastructure and numerous fake email accounts to impersonate trusted parties. By gaining the trust of new targets, the attackers took over the victim’s email accounts and hijacked existing email conversations between the target and a trusted party. To disguise the phishing links, they used a fake URL shortener Litby[.]us, and utilized a legitimate identity verification service validation.com.
Researchers observed the primary motive of this campaign appeared to be securing access to inboxes, theft of Personally Identifiable Information (PII), and theft of identity documents of victims. The high-profile individuals targeted in this operation included:
The campaign signaled various characteristics which lead researchers to believe it to be an Iranian-backed effort, which included:
Analyzing the source code of one of the phishing pages led researchers to the possibility that the same HTML page was previously used by threat actors in a different attack. The domain de-ma[.]online in the source code was leveraged for credential harvesting by the Iranian Phosphorus APT group according to Microsoft. In addition, the APT group has been known for a long history of conducting high-profile cyber operations in the interest of the Iranian state and targeting Israeli officials.
Internet infrastructure provider Cloudflare reported they recently detected and mitigated the largest HTTPS DDoS attack observed so far. During this attack, the website of one of its customers was subject to 26 million requests per second (RPS). The attacker appeared to be originated majorly from Cloud Service Providers instead of Residential ISPs, which lead them to believe the possibility of it being carried out by leveraging a hijacked virtual machine and powerful server as opposed to IoT devices which are considerably weaker.
The company traced the attack back to a powerful botnet of 5,067 devices with each of them generating approximately 5,200 RPS at the peak. According to the company, the attack stands out in terms of resources leveraged at scale. Within 30 seconds, over 212 million HTTPS requests from over 1,500 networks in 121 countries were generated by the botnet. The top source countries included Indonesia, the United States, Brazil, Russia, the French-based OVH (Autonomous System Number 16276), the Indonesian Telkomnet (ASN 7713), the US-based iboss (ASN 137922), and the Libyan Ajeel (ASN 37284) were identified as top source network of this attack.
Source: Surface Web
The company is tracking another much larger botnet in terms of size which is consisting of over 730,000 devices, although less powerful. This botnet generates merely 1.3 requests per second on average per device which is far lesser than the botnet observed in the current attack. Despite having less number of devices the smaller botnet averaged 4000 times stronger thanks to the use of virtual machines and powerful servers.
According to a recent DDoS Trends report, while most of the attacks are small, the size and frequency of larger ones are growing. These types of attacks remain short and rapid. The attackers behind these attacks tend to concentrate the botnet’s power for a “single knockout blow” strategy which also helps them swiftly achieve their objective and remain undetected.
The Dutch Institute for Vulnerability Disclosure (DIVD) has found multiple vulnerabilities in products of ITarian – a remote access and IT management solutions provider. The affected products and associated vulnerabilities are as follows:
Affected Products
Vulnerabilities
Researchers highlight that these vulnerabilities may result in severe consequences. An attacker who is able to chain the additional XSS vulnerability present in the helpdesk function with the CVE-2022-25152 vulnerability in ITarian SaaS / on-premise platform could create a service desk ticket in theory. This ticket, when viewed by a user with a valid session token, would execute a workflow on all clients with superuser privileges.
