Microsoft Warns of Tax-Themed Email Attacks Using PDFs and QR Codes to Deliver Malware

Microsoft is warning of several phishing campaigns that are leveraging tax-related themes to deploy malware and steal credentials.

"These campaigns notably use redirection methods such as URL shorteners and QR codes contained in malicious attachments and abuse legitimate services like file-hosting services and business profile pages to avoid detection," Microsoft said in a report shared with The Hacker News.

A notable aspect of these campaigns is that they lead to phishing pages that are delivered via a phishing-as-a-service (PhaaS) platform codenamed RaccoonO365, an e-crime platform that first came to light in early December 2024.

Also delivered are remote access trojans (RATs) like Remcos RAT, as well as other malware and post-exploitation frameworks such as Latrodectus, AHKBot, GuLoader, and BruteRatel C4 (BRc4).

One such campaign spotted by the tech giant on February 6, 2025, is estimated to have sent hundreds of emails targeting the United States ahead of the tax filing season that attempted to deliver BRc4 and Latrodectus. The activity has been attributed to Storm-0249, an initial access broker previously known for distributing BazaLoader, IcedID, Bumblebee, and Emotet.

The attacks involve the use of PDF attachments containing a link that redirects users to a URL shortened via Rebrandly, ultimately leading them to a fake Docusign page with an option to view or download the document.

"When users clicked the Download button on the landing page, the outcome depended on whether their system and IP address were allowed to access the next stage based on filtering rules set up by the threat actor," Microsoft said.

If access is allowed, the user is sent a JavaScript file that subsequently downloads a Microsoft Software Installer (MSI) for BRc4, which serves as a conduit for deploying Latrodectus. If the victim is not deemed a valuable enough target, they are sent a benign PDF document from royalegroupnyc[.]com.

Microsoft said it also detected a second campaign between February 12 and 28, 2025, where tax-themed phishing emails were sent to more than 2,300 organizations in the U.S., particularly aimed at engineering, IT, and consulting sectors.

The emails, in this case, had no content in the message body, but featured a PDF attachment containing a QR code that pointed to a link associated with the RaccoonO365 PhaaS that mimics Microsoft 365 login pages to trick users into entering their credentials.

In a sign that these campaigns come in various forms, tax-themed phishing emails have also been flagged as propagating other malware families like AHKBot and GuLoader.

AHKBot infection chains have been found to direct users to sites hosting a malicious Microsoft Excel file that, upon opening and enabling macros, downloads and runs a MSI file in order to launch an AutoHotKey script, which then downloads a Screenshotter module to capture screenshots from the compromised host and exfiltrate them to a remote server.

The GuLoader campaign aims to deceive users into clicking on a URL present within a PDF email attachment, resulting in the download of a ZIP file.

"The ZIP file contained various .lnk files set up to mimic tax documents. If launched by the user, the .lnk file uses PowerShell to download a PDF and a .bat file," Microsoft said. "The .bat file in turn downloaded the GuLoader executable, which then installed Remcos."

The development comes weeks after Microsoft warned of another Storm-0249 campaign that redirected users to fake websites advertising Windows 11 Pro to deliver an updated version of Latrodectus loader malware via the BruteRatel red-teaming tool.

"The threat actor likely used Facebook to drive traffic to the fake Windows 11 Pro download pages, as we observed Facebook referrer URLs in multiple cases," Microsoft said in a series of posts on X.

"Latrodectus 1.9, the malware's latest evolution first observed in February 2025, reintroduced the scheduled task for persistence and added command 23, enabling the execution of Windows commands via 'cmd.exe /c .'"

The disclosure also follows a surge in campaigns that use QR codes in phishing documents to disguise malicious URLs as part of widespread attacks aimed at Europe and the U.S., resulting in credential theft.

"Analysis of the URLs extracted from the QR codes in these campaigns reveals that attackers typically avoid including URLs that directly point to the phishing domain," Palo Alto Networks Unit 42 said in a report. "Instead, they often use URL redirection mechanisms or exploit open redirects on legitimate websites."

These findings also come in the wake of several phishing and social engineering campaigns that have been flagged in recent weeks -

• Use of the browser-in-the-browser (BitB) technique to serve seemingly realistic browser pop-ups that trick players of Counter-Strike 2 into entering their Steam credentials with the likely goal of reselling access to these accounts for profit
• Use of information stealer malware to hijack MailChimp accounts, permitting threat actors to send email messages in bulk
• Use of SVG files to bypass spam filters and redirect users to fake Microsoft login pages
• Use of trusted collaboration services like Adobe, DocuSign, Dropbox, Canva, and Zoho to sidestep secure email gateways (SEGs) and steal credentials
• Use of emails spoofing music streaming services like Spotify and Apple Music with the goal of harvesting credentials and payment information
• Use of fake security warnings related to suspicious activity on Windows and Apple Mac devices on bogus websites to deceive users into providing their system credentials
• Use of fake websites distributing trojanized Windows installers for DeepSeek, i4Tools, and Youdao Dictionary Desktop Edition that drop Gh0st RAT
• Use of billing-themed phishing emails targeting Spanish companies to distribute an information stealer named DarkCloud

To mitigate the risks posed by these attacks, it's essential that organizations adopt phishing-resistant authentication methods for users, use browsers that can block malicious websites, and enable network protection to prevent applications or users from accessing malicious domains.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/n8EGKuJ
via IFTTT

Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti Connect Secure Vulnerability (CVE-2025-22457)

Written by: John Wolfram, Michael Edie, Jacob Thompson, Matt Lin, Josh Murchie

---

On Thursday, April 3, 2025, Ivanti disclosed a critical security vulnerability, CVE-2025-22457, impacting Ivanti Connect Secure (“ICS”) VPN appliances version 22.7R2.5 and earlier. CVE-2025-22457 is a buffer overflow vulnerability, and successful exploitation would result in remote code execution. Mandiant and Ivanti have identified evidence of active exploitation in the wild against ICS 9.X (end of life) and 22.7R2.5 and earlier versions. Ivanti and Mandiant encourage all customers to upgrade as soon as possible. 

The earliest evidence of observed CVE-2025-22457 exploitation occurred in mid-March 2025. Following successful exploitation, we observed the deployment of two newly identified malware families, the TRAILBLAZE in-memory only dropper and the BRUSHFIRE passive backdoor. Additionally, deployment of the previously reported SPAWN ecosystem of malware attributed to UNC5221 was also observed. UNC5221 is a suspected China-nexus espionage actor that we previously observed conducting zero-day exploitation of edge devices dating back to 2023.

A patch for CVE-2025-22457 was released in ICS 22.7R2.6 on February 11, 2025. The vulnerability is a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability. We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

Ivanti released patches for the exploited vulnerability and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Post-Exploitation TTPs

Following successful exploitation, Mandiant observed the deployment of two newly identified malware families tracked as TRAILBLAZE and BRUSHFIRE through a shell script dropper. Mandiant has also observed the deployment of the SPAWN ecosystem of malware, as well as a modified version of the Integrity Checker Tool (ICT) as a means of evading detection.  

Shell-script Dropper

Following successful exploitation of CVE-2025-22457, Mandiant observed a shell script being leveraged that executes the TRAILBLAZE dropper. This dropper injects the BRUSHFIRE passive backdoor into a running /home/bin/web process. The first stage begins by searching for a /home/bin/web process that is a child process of another /home/bin/web process (the point of this appears to be to inject into the web process that is actually listening for connections). It then creates the the following files and associated content:

• /tmp/.p: contains the PID of the /home/bin/web process.

• /tmp/.m: contains a memory map of that process (human-readable).

• /tmp/.w: contains the base address of the web binary from that process

• /tmp/.s: contains the base address of libssl.so from that process

• /tmp/.r: contains the BRUSHFIRE passive backdoor

• /tmp/.i: contains the TRAILBLAZE dropper

The shell script then executes /tmp/.i, which is the second stage in-memory only dropper tracked as TRAILBLAZE. It then deletes all of the temporary files previously created (except for /tmp/.p), as well as the contents of the /data/var/cores directory. Next, all child processes of the /home/bin/web process are killed and the /tmp/.p file is deleted. All of this behavior is non-persistent, and the dropper will need to be re-executed if the system or process is rebooted.

TRAILBLAZE

TRAILBLAZE is an in-memory only dropper written in bare C that uses raw syscalls and is designed to be as minimal as possible, likely to ensure it can fit within the shell script as Base64. TRAILBLAZE injects a hook into the identified /home/bin/web process. It will then inject the BRUSHFIRE passive backdoor into a code cave inside that process.

BRUSHFIRE

BRUSHFIRE is a passive backdoor written in bare C that acts as an SSL_read hook. It first executes the original SSL_read function, and checks to see if the returned data begins with a specific string. If the data begins with the string, it will XOR decrypt then execute shellcode contained in the data. If the received shellcode returns a value, the backdoor will call SSL_write to send the value back.

SPAWNSLOTH

As detailed in our previous blog post, SPAWNSLOTH acts as a log tampering component tied to the SPAWNSNAIL backdoor. It targets the dslogserver process to disable both local logging and remote syslog forwarding.

SPAWNSNARE

SPAWNSNARE is a utility that is written in C and targets Linux. It can be used to extract the uncompressed linux kernel image (vmlinux) into a file and encrypt it using AES without the need for any command line tools.

SPAWNWAVE

SPAWNWAVE is an evolved version of SPAWNANT that combines capabilities from other members of the SPAWN* malware ecosystem. SPAWNWAVE overlaps with the publicly reported SPAWNCHIMERA and RESURGE malware families.

Attribution

Google Threat Intelligence Group (GTIG) attributes the exploitation of CVE-2025-22457 and the subsequent deployment of the SPAWN ecosystem of malware to the suspected China-nexus espionage actor UNC5221. GTIG has previously reported UNC5221 conducting zero-day exploitation of CVE-2025-0282, as well as the exploitation CVE-2023-46805 and CVE-2024-21887. 

Furthermore, GTIG has also previously observed UNC5221 conducting zero-day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations, and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on various edge appliances. 

GTIG assesses that UNC5221 will continue pursuing zero-day exploitation of edge devices based on their consistent history of success and aggressive operational tempo. Additionally, as noted in our prior blog post detailing CVE-2025-0282 exploitation, GTIG has observed UNC5221 leveraging an obfuscation network of compromised Cyberoam appliances, QNAP devices, and ASUS routers to mask their true source during intrusion operations.

Conclusion

This latest activity from UNC5221 underscores the ongoing sophisticated threats targeting edge devices globally. This campaign, exploiting the n-day vulnerability CVE-2025-22457, also highlights the persistent focus of actors like UNC5221 on edge devices, leveraging deep device knowledge and adding to their history of using both zero-day and now n-day flaws. This activity aligns with the broader strategy GTIG has observed among suspected China-nexus espionage groups who invest significantly in exploits and custom malware for critical edge infrastructure.

Recommendations 

Mandiant recommends organizations immediately apply the available patch by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later to address CVE-2025-22457. Additionally organizations should use the external and internal Integrity Checker Tool (“ICT”) and contact Ivanti Support if suspicious activity is identified. To supplement this, defenders should actively monitor for core dumps related to the web process, investigate ICT statedump files, and conduct anomaly detection of client TLS certificates presented to the appliance.

Acknowledgements

We would like to thank Daniel Spicer and the rest of the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE, we would like to specifically thank Christopher Gardner and Dhanesh Kizhakkinan of FLARE for their support.

Indicators of Compromise

To assist the security community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Code Family	MD5	Filename	Description
TRAILBLAZE	4628a501088c31f53b5c9ddf6788e835	/tmp/.i	In-memory dropper
BRUSHFIRE	e5192258c27e712c7acf80303e68980b	/tmp/.r	Passive backdoor
SPAWNSNARE	6e01ef1367ea81994578526b3bd331d6	/bin/dsmain	Kernel extractor & encryptor
SPAWNWAVE	ce2b6a554ae46b5eb7d79ca5e7f440da	/lib/libdsupgrade.so	Implant utility
SPAWNSLOTH	10659b392e7f5b30b375b94cae4fdca0	/tmp/.liblogblock.so	Log tampering utility

YARA Rules

rule M_APT_Installer_SPAWNANT_1
{ 
    meta: 
        author = "Mandiant" 
        description = "Detects SPAWNANT. SPAWNANT is an 
Installer targeting Ivanti devices. Its purpose is to persistently 
install other malware from the SPAWN family (SPAWNSNAIL, 
SPAWNMOLE) as well as drop additional webshells on the box." 
  
    strings: 
        $s1 = "dspkginstall" ascii fullword
        $s2 = "vsnprintf" ascii fullword
        $s3 = "bom_files" ascii fullword
        $s4 = "do-install" ascii
        $s5 = "ld.so.preload" ascii
        $s6 = "LD_PRELOAD" ascii
        $s7 = "scanner.py" ascii
        
    condition: 
        uint32(0) == 0x464c457f and 5 of ($s*)
}

rule M_Utility_SPAWNSNARE_1 {
    meta:
         author = "Mandiant"
        description = "SPAWNSNARE is a utility written in C that targets 
Linux systems by extracting the uncompressed Linux kernel image 
into a file and encrypting it with AES."

    strings:
        $s1 = "\x00extract_vmlinux\x00"
        $s2 = "\x00encrypt_file\x00"
        $s3 = "\x00decrypt_file\x00"
        $s4 = "\x00lbb_main\x00"
        $s5 = "\x00busybox\x00"
        $s6 = "\x00/etc/busybox.conf\x00"

    condition:
        uint32(0) == 0x464c457f
        and all of them
                  
}

rule M_APT_Utility_SPAWNSLOTH_2
{ 
    meta: 
        author = "Mandiant" 
        description = "Hunting rule to identify strings found in SPAWNSLOTH"
  
    strings: 
        $dslog = "dslogserver" ascii fullword
        $hook1 = "g_do_syslog_servers_exist" ascii fullword
        $hook2 = "ZN5DSLog4File3addEPKci" ascii fullword
        $hook3 = "funchook" ascii fullword
    
    condition: 
        uint32(0) == 0x464c457f and all of them
}

from Threat Intelligence https://ift.tt/IskWLVS
via IFTTT

VMware vSphere vSwitch Load Balancing Options: A Complete Guide

Disclaimer: 

This article has been updated with the most recent information relevant to VMware vSphere, including features and functionality as of 2025. It provides an overview of ESXi vSphere vSwitch load balancing options, highlighting their pros and cons. While the content is based on the latest version of vSphere at the time of publication, we recommend consulting VMware’s official documentation or release notes for any updates or changes. The material is intended for informational purposes and serves as an introductory guide. If you have suggestions for improving this guide, feel free to share your feedback! 

Introduction 

Previously, I discussed addressing NIC load balancing issues on an ESXi host and the utility of ESXCLI in that context. Since then, many colleagues have inquired about the differences between various load balancing methods and which one is optimal. Let’s explore and clarify the concepts of network load balancing at the infrastructure level. 

For starters, let’s quickly revisit what load balancing is all about. Here’s the deal: don’t mix up load balancing network traffic with balancing workloads for optimal performance; that’s the job of DRS or Distributed Resource Scheduler.  

NIC teaming technology in VMware combines two or more physical NICs into a single logical interface to increase the bandwidth of a vSphere virtual switch or a group of ports, thereby enhancing reliability. By configuring the failover procedure, you can choose how exactly traffic will be redirected in case of a failure of one of the NICs. Configuring the load balancing policy allows you to decide how exactly a vSwitch will load balance the traffic between NICs. 

So, what’s the takeaway? Load balancing is essentially the technology of uniting physical interfaces into one seamless logical connection. Although aggregation allows increasing channel bandwidth, you shouldn’t really count on perfect load balancing between all interfaces in the aggregated channel. Put simply, this tech is about smartly directing traffic from virtual machines (VMs) to vSwitches and down to pNICs. Whether it’s a vSwitch, pNIC, or a group of vNICs, there are a few tried-and-true methods to balance traffic:  

• Route based on originating port ID 

• Route based on IP hash 

• Route based on source MAC hash 

• Route based on physical NIC load 

• Use explicit failover order 

Curious? Let’s dig deeper into each method and break them down in simple terms. 

Route Based on Originating Virtual Port ID 

This method is the default option for both standard and distributed vSwitches. It assigns an uplink based on the virtual port ID of the VM’s vNIC. Each VM is connected to a specific virtual port on the vSwitch, and the vSwitch maps this virtual port to a specific physical NIC (pNIC). This method ensures that one vNIC uses only one pNIC at any given time – simple and straightforward. 

Here’s how it works: each VM gets a unique identifier on the vSwitch. In order to assign an uplink port for a VM, vSwitch uses a similar port identifier on a network card or a group of network cards. When an uplink port is assigned, vSwitch distributes traffic for a VM through the same uplink port as long as this VM works on that switch. 

The virtual switch assigns the uplink port only once, a port identifier for a VM is fixed, so if vSwitch assigns a different group of ports to the VM, it generates a new uplink port. 

However, things don’t always stay static — a VM could be migrated, powered off, or even deleted. When that happens, its port identifier on vSwitch becomes available once again. Furthermore, vSwitch stops sending traffic to this port, which, in turn, lowers overall traffic distributed to the uplink port connected with it. However, if the VM is turned on or transferred, it may appear on another port and start using another uplink port.  

If all pNICs in the group are active, they distribute traffic for a VM. 

Now, let’s add a practical touch. Turn off VM 2 and VM 5 and then power on in the following order: VM 8, VM 9, VM 2, and VM 5. Guess what happens? You’ll see that the port identifier on Port Group 1 and Port Group 2 didn’t lose connection with pNIC uplink ports. In turn, VM 8 and VM 9 were connected to the uplink ports previously used by VM 2 and VM 5. It’s like musical chairs but for VMs and uplink ports! 

Pros: 

• Simple physical switch configuration: no need for uplink binding (EtherChannel); only independent ports of the switch require configuration, keeping things simple and manageable. 

• Equal distribution of bandwidth: when the number of vNICs exceeds the number of pNICs, this method ensures that each vNIC gets its fair share of bandwidth. 

• Physical NIC redundancy: even if all pNICs are in active use, when one pNIC fails, the other pNICs in the team continue to balance traffic, ensuring your network stays up and running.  

• Traffic balancing across multiple switches: physical NIC group traffic can be distributed between several physical switches, avoiding hardware failure and improving overall reliability. 

• Beacon probing for failover detection: this load balancing type may use a network failover detection mechanism called beacon probing, enhancing the stability of your network environment.  

• Load balancing in multi-VM environments: in environments with several VMs, the load is distributed across all active network cards, increasing overall performance. 

Cons: 

• Limited Bandwidth per vNIC: A single vNIC cannot use the combined bandwidth of multiple pNICs. For example, if there are four pNICs in a group (1 Gb/s each), a VM with one vNIC can only utilize 1 Gb/s bandwidth through one pNIC. 

• Not suitable for high client request volumes: this method isn’t ideal for virtual servers that handle a lot of requests from different clients when there’s a necessity to load balance traffic of one VM (with one vNIC) between several pNICs;  

• No support for 802.3ad aggregation: this method doesn’t support 802.3ad channel aggregation technology and may cause issues with accessing IP storage (e.g., iSCSI, NFS) since VMkernel can also use only one pNIC to work with different iSCSI targets. 

Route Based on IP Hash 

This load balancing method distributes traffic by creating a hash (a fixed-size value) derived from the source IP address and the destination IP packet. This clever hashing mechanism ensures that traffic between a single VM and multiple clients, including through a router, can be balanced with different vmNICs. To enable this functionality, you’ll need to activate 802.3ad support on the physical switch connected to your ESXi Server. 

Among load balancing algorithms, IP hash is a star performer when it comes to efficiency. However, with great power comes complexity. The server shoulders a significant computational load since it calculates the hash for every IP packet. The hash calculation relies on the XOR algorithm and uses this formula: 

1	<em>((LSB (SrcIP) xor LSB (DestIP)) mod (# pNICs)</em>

The load balancing equitability largely depends on the number of TCP/IP sessions between a host and different clients, also pNIC. When many connections are in play, this method ensures more even traffic distribution and avoids pitfalls inherent to the option based on ID-port. 

However, there’s a catch: if your host connects to multiple physical switches, you’ll need to aggregate all ports into a stack (EtherChannel). Without support for this mode on your physical switches, IP hash won’t be an option. In such situations, you might find yourself connecting all pNICs in the vSwitch to one physical switch. 

Here’s where you need to tread carefully. Relying on a single switch means introducing a single point of failure – if the switch goes down, the entire system follows suit. Think of it in advance. 

Another critical detail: while applying IP hash as a load balancing algorithm, you’ll need to perform configuration on vSwitch, and you don’t have to override it on the ports group level. In other words, ALL devices connected to vSwitch with IP hash load balancing should use IP hash load balancing. 

IP hash works best when there is a significant number of destination IP addresses in play. Otherwise, you’re risking encountering a situation when two or more requests instead of balancing will try to load the same pNIC. 

For instance, consider a scenario where a VM uses an iSCSI-connected disk from two SANs. If these 2 SANs have IP addresses that can be calculated with the same module value (look at the tab), then all traffic will load one pNIC, which, in turn, lowers the efficiency of using IP hash load balancing to a minimum. 

VM	IP VM	DestrIP	XOR (SrcIP, DestIP)	Modul	pNIC
VM 1	x.x.x.10	z.z.z.20	(10 xor 20) = 30 mod 2 = 0	0	1
VM 1	x.x.x.10	z.z.z.30	(10 xor 30) = 20 mod 2 = 1	0	1

This approach works well when there’s a large number of destination IP addresses, but be mindful of the limitations when the distribution of IPs is not as diverse. 

Pros: 

• Improved performance for multi-VM communication: when a VM communicates with multiple other VMs, it can theoretically utilize a bandwidth greater than what a single pNIC supports. 

• Physical NIC redundancy: if a pNIC or uplink fails, the remaining NICs in the group will continue balancing traffic, ensuring uninterrupted network performance. However, synchronization is key – the ESXi host and physical switch must recognize the channel as inactive so that the uplink could work properly. If there is any inconsistency, traffic won’t be able to switch to the other pNICs in the group. 

Cons: 

• Less flexible switch configuration: physical switch configuration demands that ports be set up for EtherChannel static connections, which limits adaptability. Additionally, many switches don’t support EtherChannel across multiple physical switches, confining the pNIC group to a single switch.

Note: exceptions exist, such as specific stacks or modular switches which can actually do that on several switches or modules. Technologies like Cisco vPC (Virtual Port Channel) can address this issue, provided the switches support it. Talk to your vendor to get more information. 

• Lacks beacon probing: this load balancing option lacks beacon probing for error detection. Instead, it relies solely on uplink port failure notifications, which may not provide as comprehensive a failover mechanism. 

Route Based on Source MAC Hash 

Now, let’s talk about a simpler yet equally intriguing load balancing method: Route Based on Source MAC Hash. This approach suggests that vSwitch selects an uplink port for a VM based on the MAC address of the VM. To calculate an uplink port for a VM, vSwitch applies LSB (Least Significant Bit) of the source MAC-address (vNIC MAC-address) according to the module of the number of active pNICs in vSwitch to receive an address in the pNIC array. 

Let’s break it down with an example: consider a setup with two pNICs and a vNIC with the MAC address 00:15:5D:99:96:0B. The LSB of the MAC address is 0x0B or 11 in decimal. In modulo operation, you split (using integer division) LSB MAC in the amount of pNIC (11 / 3), and pick the remainder (in this case, 2) as the modulus of the operation. The physical NIC array is based on 0, which means that 0=pNIC 1, 1=pNIC 2, 2=pNIC 3.  

name	MAC LSB	modul	pNIC
VM 1	:39 = 57	0	1
VM 2	:6D = 109	1	2
VM 3	:0E = 14	2	3
VM 4	:5A = 90	0	1
VM 5	:97 = 151	1	2
VM 6	:F5 = 245	2	3
VM 7	:A2 = 162	0	1

Pros: 

• More balanced load distribution: compared to the “Route Based on Originating Port ID” method, this approach ensures a more equitable load balancing as the vSwitch calculates an uplink port for each packet, ensuring better traffic distribution. 

• Consistent uplink port assignment: all VMs use the same uplink port because their MAC addresses are static, meaning that powering a VM on or off doesn’t disrupt its uplink port assignment. 

• No physical switch changes needed: this method eliminates the need for any configuration adjustments on physical switches, simplifying deployment and reducing setup time. 

Cons: 

• Bandwidth limited by uplink port speed: the speed of the uplink port connected to a specific port identifier determines the bandwidth available to the VM unless the VM utilizes multiple vNICs with different MAC addresses. 

• Higher resource consumption: this method is more resource-intensive than the routing based on originating port ID, as the vSwitch must calculate the uplink port for each packet. 

• Potential uplink port overload: the virtual switch does not monitor the current load of uplink ports, increasing the risk of some ports becoming overloaded while others remain underutilized. 

Route Based on Physical NIC Load 

This load balancing method is exclusive to distributed switches, and while it may seem similar to the routing based on originating port ID, it brings some notable differences to the table. The primary distinction lies in how the pNIC for traffic balancing is selected. Instead of a static assignment, the choice is dynamically determined based on the current load on the pNIC. 

The system evaluates the load on each pNIC every 30 seconds. If the load on a specific pNIC exceeds 75%, the VM port identifier with the highest I/O operations switches to another uplink port of a less-loaded pNIC. Unlike other load-balancing methods where the port remains fixed once assigned, this approach adapts to changing traffic conditions. 

In simpler terms, this method isn’t traditional load balancing. It’s more like a smart failover scenario, redirecting traffic to the least busy uplink port from the list of active pNICs whenever necessary. 

Pros: 

• Low resource consumption: the distributed switch calculates the uplink port for the VM only once, and periodic uplink checks minimally impact performance; 

• Efficient load redistribution: the distributed switch actively monitors the uplink port load and shifts traffic to maintain balance where possible. 

• No physical switch configuration required: this method works seamlessly without needing adjustments on the physical network side. 

Cons: 

• Bandwidth constraints: the available bandwidth for a VM is determined solely by the uplink port connected to the distributed switch. 

Use Explicit Failover Order 

This policy takes a more straightforward approach, although it might come as a surprise to some – it essentially eliminates true load balancing. Here’s how it works: the vSwitch always selects the highest-priority uplink port from the list of available active NICs. If the first uplink port becomes unavailable, traffic shifts to the next one in the list, and so on. 

The failover order parameter is key here, defining the Active/Standby pNIC mode for the vSwitch. While simple, this method sacrifices the flexibility and efficiency of dynamic load balancing in favor of a more rigid, predictable behavior. 

Comparison of Load Balancing Policies

Method	Pros	Cons
Route Based on Originating Virtual Port ID	Simplicity, Even Distribution, Redundancy, Multiple Switches	Bandwidth Limitation, Not Ideal for High Traffic VMs, No 802.3ad Support
Route Based on IP Hash	Enhanced Performance, Redundancy	Complex Configuration, No Beacon Probing, Potential Imbalance
Route Based on Source MAC Hash	Improved Distribution, Consistent Assignment, No Physical Switch Configuration Needed	Bandwidth Limitation, Resource Intensive
Route Based on Physical NIC Load	Dynamic Load Distribution, Automatic Adjustment	vSphere Distributed Switch Requirement, Potential for Frequent Reassignments
Use Explicit Failover Order	Predictability, Simplicity	No Load Balancing, Manual Configuration

Conclusion 

Each load balancing policy comes with its own set of advantages and drawbacks, and the best choice depends entirely on your specific needs. If you’re new to this topic, starting with the originating port ID method (the default option) is a good idea – it’s simple, effective, and a great introduction to how load balancing works. 

As your understanding grows, you can experiment with other methods to find the one that aligns best with your workload and infrastructure requirements. 

I hope this explanation helps clarify these load balancing methods for you. If you’re eager to dive deeper, VMware’s official guides are an excellent next step. And if you have suggestions or ideas for improving this material, feel free to share them – I’m all ears! 

 

from StarWind Blog https://ift.tt/nfxbkL3
via IFTTT

Lazarus Group Targets Job Seekers With ClickFix Tactic to Deploy GolangGhost Malware

The North Korean threat actors behind Contagious Interview have adopted the increasingly popular ClickFix social engineering tactic to lure job seekers in the cryptocurrency sector to deliver a previously undocumented Go-based backdoor called GolangGhost on Windows and macOS systems.

The new activity, assessed to be a continuation of the campaign, has been codenamed ClickFake Interview by French cybersecurity company Sekoia. Contagious Interview, also tracked as DeceptiveDevelopment, DEV#POPPER, and Famous Chollima, is known to be active since at least December 2022, although it was only publicly documented for the first time in late 2023.

"It uses legitimate job interview websites to leverage the ClickFix tactic and install Windows and macOS backdoors," Sekoia researchers Amaury G., Coline Chavane, and Felix Aimé said, attributing the effort to the infamous Lazarus Group, a prolific adversary attributed to the Reconnaissance General Bureau (RGB) of the Democratic People's Republic of Korea (DPRK).

A notable aspect of the campaign is that it primarily targets centralized finance entities by impersonating companies like Coinbase, KuCoin, Kraken, Circle, Securitize, BlockFi, Tether, Robinhood, and Bybit, marking a departure from the hacking group's attacks against decentralized finance (DeFi) entities.

Contagious Interview, like Operation Dream Job, employs fake job offers as lures to attract prospective targets and dupe them into downloading malware that can steal cryptocurrency and other sensitive data.

As part of the effort, candidates are approached via LinkedIn or X to prepare for a video call interview, for which they are asked to download a malware-laced videoconferencing software or open-source project that activates the infection process.

Lazarus Group's use of the ClickFix tactic was first disclosed towards the end of 2024 by security researcher Taylor Monahan, with the attack chains leading to the deployment of a family of malware called FERRET that then delivers the Golang backdoor.

In this iteration of the campaign, victims are asked to visit a purported video interviewing service named Willo and complete a video assessment of themselves.

"The entire setup, meticulously designed to build user trust, proceeds smoothly until the user is asked to enable their camera," Sekoia explained. "At this point, an error message appears indicating that the user needs to download a driver to fix the issue. This is where the operator employs the ClickFix technique."

The instructions given to the victim to enable access to the camera or microphone vary depending on the operating system used. On Windows, the targets are prompted to open Command Prompt and execute a curl command to execute a Visual Basic Script (VBS) file, which then launches a batch script to run GolangGhost.

In the event the victim is visiting the site from a macOS machine, they are similarly asked to launch the Terminal app and run a curl command to run a shell script. The malicious shell script, for its part, runs a second shell script that, in turn, executes a stealer module dubbed FROSTYFERRET (aka ChromeUpdateAlert) and the backdoor.

FROSTYFERRET displays a fake window stating the Chrome web browser needs access to the user's camera or microphone, after which it displays a prompt to enter the system password. The entered information, regardless of whether it's valid or otherwise, is exfiltrated to a Dropbox location, likely indicating an attempt to access the iCloud Keychain using the stolen password.

GolangGhost is engineered to facilitate remote control and data theft through several commands that allow it to upload/download files, send host information, and steal web browser data.

"It was found that all the positions were not related to technical profiles in software development," Sekia noted. "They are mainly jobs of manager focusing on business development, asset management, product development or decentralised finance specialists."

"This is a significant change from previous documented campaigns attributed to DPRK-nexus threat actors and based on fake job interviews, which mainly targeted developers and software engineers."

North Korea IT Worker Scheme Becomes Active in Europe

The development comes as the Google Threat Intelligence Group (GTIG) said it has observed a surge in the fraudulent IT worker scheme in Europe, underscoring a significant expansion of their operations beyond the United States.

The IT worker activity entails North Korean nationals posing as legitimate remote workers to infiltrate companies and generate illicit revenue for Pyongyang in violation of international sanctions.

Increased awareness of the activity, coupled with the U.S. Justice Department indictments, have instigated a "global expansion of IT worker operations," Google said, noting it uncovered several fabricated personas seeking employment in various organizations located in Germany and Portugal.

The IT workers have also been observed undertaking various projects in the United Kingdom related to web development, bot development, content management system (CMS) development, and blockchain technology, often falsifying their identities and claiming to be from Italy, Japan, Malaysia, Singapore, Ukraine, the United States, and Vietnam.

This tactic of IT workers posing as Vietnamese, Japanese, and Singaporean nationals was also highlighted by managed intelligence firm Nisos early last month, while also pointing out their use of GitHub to carve new personas or recycle portfolio content from older personas to reinforce their new ones.

"IT workers in Europe were recruited through various online platforms, including Upwork, Telegram, and Freelancer," Jamie Collier, Lead Threat Intelligence Advisor for Europe at GTIG, said. "Payment for their services was facilitated through cryptocurrency, the TransferWise service, and Payoneer, highlighting the use of methods that obfuscate the origin and destination of funds."

Besides using local facilitators to help them land jobs, the insider threat operation is witnessing what appears to be a spike in extortion attempts since October 2024, when it became public knowledge that these IT workers are resorting to ransom payments from their employers to prevent them from releasing proprietary data or to provide it to a competitor.

In what appears to be a further evolution of the scheme, the IT workers are now said to be targeting companies that operate a Bring Your Own Device (BYOD) policy owing to the fact that such devices are unlikely to have traditional security and logging tools used in enterprise environments.

"Europe needs to wake up fast. Despite being in the crosshairs of IT worker operations, too many perceive this as a US problem. North Korea's recent shifts likely stem from US operational hurdles, showing IT workers' agility and ability to adapt to changing circumstances," Collier said.

"A decade of diverse cyberattacks precedes North Korea's latest surge - from SWIFT targeting and ransomware, to cryptocurrency theft and supply chain compromise. This relentless innovation demonstrates a longstanding commitment to fund the regime through cyber operations."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/ReIksgM
via IFTTT

Cyber Threats & SMBs | Chubb & SentinelOne Expedite Access to Cyber Insurance

In late 2024, Chubb, the largest US commercial cyber insurance provider, entered a partnership with SentinelOne to offer small and medium businesses (SMBs) – organizations with less than $100M in annual revenue – a streamlined means of securing affordable cyber insurance, loss mitigation, and incident response services.

As part of the partnership, SentinelOne customers can quickly obtain qualifications and quotes for cyber insurance through Chubb’s customized platform, which assesses their security posture using an instantly generated Insurance Posture Report from the SentinelOne Singularity platform.

This blog provides some background on the cyber threats and related risks facing today’s SMBs and the types of coverage these companies are looking to add to mitigate financial risk.

Barnaby Page at S1 (BP @S1): What challenges does Chubb see for SMB clients and cybersecurity?

Craig Giuliano at Chubb (CG @Chubb): Smaller businesses are highly vulnerable to cyber incidents. In fact, according to Chubb’s Cyber Index, 58% of cyber claims reported to Chubb in 2023 came from clients with less than $150 million in revenue. Further, 29% were from companies with under $25 million in revenue. For those businesses with $25 million or less in revenue, 74% of cyber incidents were caused by an external threat.

BP @S1: What are the business impacts of cyber attacks on SMB clients?

CG @Chubb: These claims are not only frequent, they can also be severe. According to NetDiligence’s 2024 claims report, first party incident response costs following a cyber event for a small or midsize enterprise are, on average, $325,000, before any business interruption loss or third-party liability costs kick in. Many of the small business claims studied resulted in losses exceeding $1 million. These incidents also disrupt operations and cause reputational damage resulting in customer retention issues and difficulty winning new contracts. Cyberattacks can be catastrophic for SMBs without the right safeguards in place.

BP @S1: Can you provide a general explanation of how insurers assess risk for cyber insurance?

CG @Chubb: There are a number of risk characteristics contemplated when assessing an insured’s cyber exposure including but not limited to revenue size, class of business, record count, claims history and security control posture. From a portfolio management perspective, it’s important to have a diverse mix of industry classes and customer sizes.

We then look at the technical controls present in the organization to determine if they practice strong cyber hygiene: security controls like MFA, phishing training, offline back-ups, patch management, secure remote access for RDP, incident response plans, and use of EDR tools. SentinelOne clients have the option of sharing their “inside-out” telemetry with Chubb and this can speed our analysis of tech controls and risk.

BP @S1: What programs does Chubb have for SMBs?

CG @Chubb: We have a holistic, three-pronged approach to help small businesses manage cyber risk. We pair tailored cyber insurance with pre- and post-breach services, including our complimentary Vulnerability Outreach program. This program provides proactive notification and response services to cyber policyholders if a known, exploited vulnerability is discovered in a customer’s environment.

BP @S1: How will clients know which coverages are most applicable to them:

CG @ Chubb: In today’s evolving threat landscape, it’s more important than ever for SMBs to protect themselves against rising costs following a cyberattack. For example, the SentinelOne threat intelligence teams are increasingly seeing data exfiltration following malware and ransomware attacks. First-party costs like digital forensics and incident response expenses and/or business interruption costs can add up quickly. Also, third-party liability expenses that may arise due to the compromise of sensitive data can be costly. Our core cyber insurance products are customizable to address the specific needs of SMBs, tailored to their industry, organizational size, and unique exposures.

BP @S1: Can you expand on the standard offering? How does Chubb ensure that SMB client critical exposures are managed and their balance sheets secured?

CG @Chubb: Chubb’s robust coverage offering includes first-party and third-party coverages so policyholders can rest assured following an incident. Those coverages include:

First-Party Coverage

• Cyber Incident Response Expenses – Covers legal, forensics, notification, credit monitoring, and public relations fees.

• Business Interruption – Covers loss of net profits and continuing operating expenses necessitated due to interruptions of the insured’s systems. Contingent Business Interruption adds downstream losses due to interruption of outsourced technology providers’ systems.

• Digital Data Recovery – Covers costs to restore or replace lost or damaged data or software.

• Network Extortion – Reimburses extortion payments and reasonable and necessary expenses following a cyber extortion threat.

Third-Party Liability Coverage

• Cyber, Privacy and Network Security Liability – Liability for failure to protect private or confidential information of others or failure of network security.
• Payment Card Loss – Contractual liabilities owed to payment card industry firms due to a cyber incident.
• Regulatory Proceedings – Covers defense for regulatory actions and fines and penalties, where insurable by law.
• Media Liability – Liability arising from printed and online defamation or copyright and trademark infringement costs.

BP @S1: Do Chubb cyber policies distinguish between theft of data and theft of money. If so, how?

CG @Chubb: Yes, SMB clients that are worried about a business email compromise scam or similar can elect to purchase Cyber Crime coverage via endorsement. Coverage includes:

• Computer Fraud – Responds when a third party accesses the insured’s computers to steal money.

• Funds Transfer Fraud – Responds when a bank, acting on fraudulent instructions by a third party, transfers funds from an insured’s account.

• Social Engineering Fraud – Responds when a third party tricks an employee into transferring company assets.

BP @S1: How does Chubb’s partnership with SentinelOne help SMBs secure favorable coverage?

CG @Chubb: We utilize the SentinelOne Insurance Posture Report as an assessment of our policyholders’ cybersecurity posture. Chubb is able to provide SentinelOne customers with favorable terms, as the technology reflects a strong commitment to managing cyber risk and maintaining a strong cyber hygiene.

Chubb’s partnership makes it easy to fortify your cyber risk management plan and secure competitively priced cyber insurance.

BP @S1: How do you recommend SMBs using SentinelOne get started on securing cyber insurance coverage?

CG @Chubb: All companies should review the guidance above for proper technical controls in place (back-ups, MFA, etc.). They can then visit the Chubb site for companies <$100 Mil in revenue for an expedited quoting experience. Request your quote here.

Disclaimers

SentinelOne, Inc. is not an insurance provider, broker, or agent and does not offer, sell, or underwrite insurance policies. The information in this article is for informational purposes only and should not be construed as professional advice, an offer of insurance, or an endorsement of any specific insurance product or provider. Decisions regarding insurance coverage, terms, and conditions are solely determined by Chubb or its affiliated underwriting companies and are subject to Chubb’s independent evaluation, underwriting criteria, and applicable laws. SentinelOne is not responsible for any decisions, actions, or claims related to Chubb’s insurance offerings.

Chubb is the marketing name used to refer to subsidiaries of Chubb Limited providing insurance and related services. For a list of these subsidiaries, please visit our website at www.chubb.com. Insurance provided by ACE American Insurance Company and its U.S.- based Chubb underwriting company affiliates. All products may not be available in all states. This communication contains product summaries only. Coverage is subject to the language of the policies as actually issued. The information contained in this document is intended for general informational purposes only and is not intended to provide legal or other expert advice. You should consult knowledgeable legal counsel or other knowledgeable experts as to any legal or technical questions you may have. Neither Chubb nor its employees or agents shall be liable for the use of any information or statements made or contained in any information provided herein. SentinelOne is a third-party vendor not affiliated with Chubb. The fact that offers and potential discounts may be made available by the third-party vendor is not an indication that insurance coverage is available under any Chubb policy for any particular incident. Discounts on products and services offered by this vendor are available only to Chubb policyholders with current in-force policies and are subject to applicable insurance laws. For products and services provided, the policyholder and third-party vendor would enter into a vendor relationship directly. Chubb will not be involved in the policyholder’s decision to purchase services and has no responsibility for services that may be provided. Surplus lines insurance sold only through licensed surplus lines producers. Chubb, 202 Hall’s Mill Road, Whitehouse Station, NJ 08889-1600.

from SentinelOne https://ift.tt/5ortlC9
via IFTTT