This post was originally published on this site

Introduction

This diary provides indicators from a Lumma Stealer infection that was followed by Sectop RAT (ArechClient2). I searched for cracked versions of popular copyright-protected software, and I downloaded the initial malware after following the results of one such search. This is a common distribution technique for various families of malware, and I often find Lumma Stealer this way.

In this case, the initial malware for Lumma Stealer was delivered as a password-protected 7-zip archive. The extracted malware is an inflated Windows executable (EXE) file at 806 MB. The EXE is padded with null-bytes (0x00), a technical which increases the EXE size while allowing the compressed archive file to be much smaller. The password-protected archive and inflated EXE file are designed to avoid detection.

Images from the infection

Shown above: Example of a page with instructions to download the initial malware file.

Shown above: Traffic from the infection filtered in Wireshark.

Shown above: Sectop RAT persistent on an infected Windows host.

Indicators of Compromise

Example of download link from the site advertising cracked versions of copyright-protected software:

hxxps[:]//incolorand[.]com/how-visual-patch-enhances-ui-consistency-across-releases/?utm_source={CID}&utm_term=Adobe%20Premiere%20Pro%20(2026)%20Full%20v26.0.2%20Espa%C3%B1ol%20[Mega]&utm_content={SUBID1}&utm_medium={SUBID2}

Example of URL for page with the file download instructions:

hxxps[:]//mega-nz.goldeneagletransport[.]com/Adobe_Premiere_Pro_%282026%29_Full_v26.0.2_Espa%C3%B1ol_%5BMega%5D.zip?c=ABUZ4WkRgQUA_YUCAFVTFwASAAAAAACh&s=360721

Example of URL for file download from site above site impersonating MEGA:

hxxps[:]//arch.primedatahost3[.]cfd/auth/media/JvWcFd5vUoYTrImvtWQAASTh/Adobe_Premiere_Pro_(2026)_Full_v26.0.2_Espa%C3%B1ol_%5BMega%5D.zip

Downloaded file:

• SHA256 hash: c7489e3bf546c5f2d958ac833cc7dbca4368dfba03a792849bc99c48a6b2a14f
• File size: 3,888,051 bytes
• File name: adobe_premiere_pro_(2026)_full_v26.0.2_espan?ol_[mega].7z
• File type: 7-zip archive data, version 0.4
• File description: Password-protected 7-zip archive
• Password: 6919

Extracted malware:

• SHA256 hash: 4849f76dafbef516df91fecfc23a72afffaf77ade51f805eae5ad552bed88923
• File size: 806,127,604 bytes
• File name: appFile.exe
• File type: PE32 executable (GUI) Intel 80386, for MS Windows
• File description: Inflated Windows EXE file for Lumma Stealer, padded with null-bytes

Deflated malware:

• SHA256 hash: 353ddce78d58aef2083ca0ac271af93659cf0039b0b29d0d169fc015bd3610bc
• File size: 7,114,156 bytes
• File type: PE32 executable (GUI) Intel 80386, for MS Windows
• File description: Above appFile.exe with most of null-byte padding removed
• Any.Run sandbox analysis 
• Triage sandbox analysis

Lumma Stealer command and control (C2) domains from Triage sandbox analysis:

• cankgmr[.]cyou
• carytui[.]vu
• decrnoj[.]club
• genugsq[.]best
• longmbx[.]click
• mushxhb[.]best
• pomflgf[.]vu
• strikql[.]shop
• ulmudhw[.]shop

Follow-up malware:

• SHA256 hash: d9b576eb6827f38e33eda037d2cda4261307511303254a8509eeb28048433b2f
• File size: 16,450,560 bytes
• File type: PE32+ executable (DLL) (GUI) x86-64, for MS Windows
• Retrieved from: hxxps[:]//enotsosun[.]pw/NetGui.dll
• Saved to: C:Users[username]AppDataLocalTemp16XBPQ29ZBG94TYNOA.dll
• File description: 64-bit DLL to install and run Sectop RAT (ArechClient2)
• Run method: rundll32 [file path],LoadForm
• Any.Run sandbox analysis
• Triage sandbox analysis

Example of Sectop RAT C2 traffic from an infected Windows host:

• hxxp[:]//91.92.241[.]102:9000/wmglb
• hxxp[:]//91.92.241[.]102:9000/wbinjget?q=66B553A8B94CE37C16F4EBC863D51FCC
• tcp[:]//91.92.241[.]102:443/ – encoded or otherwise encrypted traffic (not HTTPS/TLS)

—
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

One question that often comes up when I talk about honeypots: Are attackers able to figure out if they are connected to a honeypot? The answer is pretty simple: Yes!

Most "medium interaction" honeypots, like the one we are using, are just simulating various systems. These simulations are incomplete. For example, we are using the "Cowrie" honeypot to emulate SSH and telnet servers. Once an attacker is connected, any package they are installing will appear to install. In the past, I have written about attackers attempting to install bogus packages. If the install appears to succeed, the attacker knows they are connected to a honeypot. Some attackers look for SSH artifacts, such as the number and types of ciphers supported by SSH.

Today, I noticed one attacker, (IP address %%ip:45.135.194.48%%), using another common trick: Cowrie will often allow attackers to connect "randomly". The effect is that various username and password combinations appear to work. In this case, the attacker used usernames and passwords that are highly unlikely to work. If they succeed, they know they are connected to a honeypot. Here are some of the usernames and passwords used:

username	password
admin	definitely_not_valid_creds
honeypot	indexer
honeypotter	imaginegettingindexed
xXhoneypotXx	P@ssw0rd1337!
youjustgotindexed	getindexedretard

Will we do anything to block these types of requests? Maybe… I am not sure it is important enough to "hide" honeypots. One advantage we have is that many of our honeypots are connected to home networks with dynamic IPs. As a result, any IP address list an attacker will create is somewhat ephemeral. Secondly, we are mostly interested in internet-wide scans. We are not going to detect targeted attacks or zero days. 

—
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

In one of his recent diaries, Johannes discussed how open redirects are actively being sought out by threat actors[1], which made me wonder about how commonly these mechanisms are actually misused…

Although open redirect is not generally considered a high-impact vulnerability on its own, it can have multiple negative implications. Johannes already covered one in connection with OAuth flows, but another important (mis)use case for them is phishing.

The reason is quite straightforward – links pointing to legitimate domains (such as google.com) included in phishing messages may appear benign to recipients and can also evade simpler e-mail scanners and other detection mechanisms.

Even though open redirect has not been listed in OWASP Top 10 for quite some time, it is clear that attackers have never stopped looking for it or using it. If I look at traffic on almost any one of my own domains, hardly a month goes by when I don’t see attempts to identify potentially vulnerable endpoints, such as:

/out.php?link=https://domain.tld/

While these attempts are not particularly frequent, they are generally consistent.

We also continue to see open redirect used in phishing campaigns. Last year, I wrote about a campaign using a “half-open” (i.e., easily abusable) redirect mechanism on Google [2], and similar cases still seem to appear regularly.

But how regular are they, actually?

To find out, I reviewed phishing e-mails collected through my own filters and spam traps, as well as samples sent to us here at the ISC (either by our professional colleagues, or by threat actors themselves), over the first quarter of this year. Although the total sample only consisted of slightly more than 350 individual messages (and is therefore far from statistically representative), it still provided quite interesting results.

Redirect-based phishing accounted for a little over 21 % of all analyzed messages sent out over the first 3 months of 2026 – specifically for 32 % in January, 18 % in February and 16.5 % in March.

It should be noted that if a message contained multiple malicious links and at least one of them used a redirect, the entire message was counted exclusively as a redirect sample, and that not all redirect cases were classic "open redirects". In fact, the abused redirect mechanisms varied widely.

Some behaved similarly to the aforementioned Google-style “half-open” redirects (see details below), while others were fully open. In some cases, the redirectors were part of tracking or advertising systems, while in others, they were implemented as logout endpoints or similar mechanisms. It should be noted that URL shorteners were also counted as redirectors (although these were not particularly common).

As we mentioned, the Google-style redirects are not fully open. They do require a specific valid token to work, however, since these tokens are typically reusable, have a very long lifetime, and are not tied to any specific context (such as IP address or session), they can be – and are – readily reused in phishing campaigns.

An example of such a phishing message and subsequent redirection can be seen in the following images. Though, to avoid focusing solely on Google, it should be mentioned that similar redirect mechanisms on other platforms (e.g., Bing) are also being abused in the same way.

As we can see, although open redirect is commonly considered more of a nuisance issue than an actual high-risk vulnerability these days, it doesn’t keep malicious actors from misusing it quite heavily… Which means we shouldn’t just ignore it.

At the very least, it is worth ensuring that our own applications do not expose endpoints that can be misused in this way. And where any redirection functionality is strictly required, it should be monitored for abuse and restricted as necessary.

[1] https://isc.sans.edu/diary/Open+Redirects+A+Forgotten+Vulnerability/32742
[2] https://isc.sans.edu/diary/Another+day+another+phishing+campaign+abusing+googlecom+open+redirects/31950

———–
Jan Kopriva
LinkedIn
Nettles Consulting

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