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

I think what's really scratching an itch for me with the home theatre thing is that it's this whole geeky world of stuff that I always knew was out there, but I'd just never really understood. For example, I mentioned waveforming in the video, and I'd never even heard of that let alone understood that there may be science where sound waves are smashed into each other in opposing directions in order to cancel each other out. And I'm sure I've got that completely wrong, but that's what's so fun about this! Anyway, that's all just part of the next adventure, and I hope you enjoy hearing about it and sending over your thoughts because I'm pretty sure there's a gazillion things I don't know yet 🙂

References

1. Sponsored by: Report URI: Guarding you from rogue JavaScript! Don’t get pwned; get real-time alerts & prevent breaches #SecureYourSite
2. We're going down the home theatre rabbit hole! (check out some of the work these guys have done, just amazing)
3. We're seriously considering booting resellers off HIBP altogether (0.86% of our customers who come through them are consuming the same amount of support time as the entire remaining 99.14% 😲)

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

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|

It's hard to find a good criminal these days. I mean a really trustworthy one you can be confident won't lead you up the garden path with false promises of data breaches. Like this guy yesterday:

For my international friends, JB Hi-Fi is a massive electronics retailer down under and they have my data! I mean by design because I've bought a bunch of stuff from them, so I was curious not just about my own data but because a breach of 12 million plus people would be massive in a country of not much more than double that. So, I dropped the guy a message and asked if he'd be willing to help me verify the incident by sharing my own record. I didn't want to post any public commentary about this incident until I had a reasonable degree of confidence it was legit, not given how much impact it could have in my very own backyard.

Now, I wouldn't normally share a private conversation with another party, but when someone sets out to scam people, that rule goes out the window as far as I'm concerned. So here's where the conversation got interesting:

He guaranteed it for me! Sounds legit. But hey, everyone gets the benefit of the doubt until proven otherwise, so I started looking at the data. It turns out my own info wasn't in the full set, but he was happy to provide a few thousand sample records with 14 columns:

1. customer_id_
2. first_name
3. last_name
4. FullName
5. gender
6. email_address_
7. mobile_country_
8. mobile_number_
9. dob
10. postal_street_1_
11. state_
12. postal_code_
13. city_
14. account_status

Pretty standard stuff, could be legit, let's check. I have a little Powershell script I run against the HIBP API when a new alleged breach comes in and I want to get a really good sense of how unique it is. It simply loops through all the email addresses in a file, checks which breaches they've been in and keeps track of the percentage that have been seen before. A unique breach will have anywhere from about 40% to 80% previously seen addresses, but this one had, well, more:

Spot the trend? Every single address has one breach in common. Hmmm... wonder what the guy has to say about that?

But he was in the server! And he grabbed it from the dashboard of Shopify! Must be legit, unless... what if I compared it to the actual full breach of Dymocks? That's a local Aussie bookseller (so it would have a lot of Aussie-looking email addresses in it, just like JB Hi-Fi would), and their breach dated back to mid-2023. I keep breaches like that on hand for just such occasions, let's compare the two:

Wow! What are the chances?! He's going to be so interested when he hears about this!

And that was it. The chat went silent and very shortly after, the listing was gone:

It looks like the bloke has also since been booted off the forum where he tried to run the scam so yeah, this one didn't work out great for him. That $16k would have been so tasty too!

I wrote this short post to highlight how important verification of data breach claims is. Obviously, I've seen loads of legitimate ones but I've also seen a lot of rubbish. Not usually this blatant where the party contacting me is making such demonstrably false claims about their own exploits, but very regularly from people who obtain something from another party and repeat the lie they've been told. This example also highlights how useful data from previous breaches is, even after the email addresses have been extracted and loaded into HIBP. Data is so often recycled and shipped around as something new, this was just a textbook perfect case of making use of a previous incident to disprove a new claim. Plus, it's kinda fun poking holes in a scamming criminal's claims 😊

TL;DR — Email addresses in stealer logs can now be queried in HIBP to discover which websites they've had credentials exposed against. Individuals can see this by verifying their address using the notification service and organisations monitoring domains can pull a list back via a new API.

Nasty stuff, stealer logs. I've written about them and loaded them into Have I Been Pwned (HIBP) before but just as a recap, we're talking about the logs created by malware running on infected machines. You know that game cheat you downloaded? Or that crack for the pirated software product? Or the video of your colleague doing something that sounded crazy but you thought you'd better download and run that executable program showing it just to be sure? That's just a few different ways you end up with malware on your machine that then watches what you're doing and logs it, just like this:

These logs all came from the same person and each time the poor bloke visited a website and logged in, the malware snared the URL, his email address and his password. It's akin to a criminal looking over his shoulder and writing down the credentials for every service he's using, except rather than it being one shoulder-surfing bad guy, it's somewhat larger than that. We're talking about billions of records of stealer logs floating around, often published via Telegram where they're easily accessible to the masses. Check out Bitsight's piece titled Exfiltration over Telegram Bots: Skidding Infostealer Logs if you'd like to get into the weeds of how and why this happens. Or, for a really quick snapshot, here's an example that popped up on Telegram as I was writing this post:

As it relates to HIBP, stealer logs have always presented a bit of a paradox: they contain huge troves of personal information that by any reasonable measure constitute a data breach that victims would like to know about, but then what can they actually do about it? What are the websites listed against their email address? And what password was used? Reading the comments from the blog post in the first para, you can sense the frustration; people want more info and merely saying "your email address appeared in stealer logs" has left many feeling more frustrated than informed. I've been giving that a lot of thought over recent months and today, we're going to take a big step towards addressing that concern:

The domains an email address appears next to in stealer logs can now be returned to authorised users.

This means the guy with the Gmail address from the screen grab above can now see that his address has appeared against Amazon, Facebook and H&R Block. Further, his password is also searchable in Pwned Passwords so every piece of info we have from the stealer log is now accessible to him. Let me explain the mechanics of this:

Firstly, the volumes of data we're talking about are immense. In the case of the most recent corpus of data I was sent, there are hundreds of text files with well over 100GB of data and billions of rows. Filtering it all down, we ended up with 220 million unique rows of email address and domain pairs covering 69 million of the total 71 million email addresses in the data. The gap is explained by a combination of email addresses that appeared against invalidly formed domains and in some cases, addresses that only appeared with a password and not a domain. Criminals aren't exactly renowned for dumping perfectly formed data sets we can seamlessly work with, and I hope folks that fall into that few percent gap understand this limitation.

So, we now have 220 million records of email addresses against domains, how do we surface that information? Keeping in mind that "experimental" caveat in the title, the first decision we made is that it should only be accessible to the following parties:

1. The person who owns the email address
2. The company that owns the domain the email address is on

At face value it might look like that first point deviates from the current model of just entering an email address on the front page of the site and getting back a result (and there are very good reasons why the service works this way). There are some important differences though, the first of which is that whilst your classic email address search on HIBP returns verified breaches of specific services, stealer logs contain a list of services that have never have been breached. It means we're talking about much larger numbers that build up far richer profiles; instead of a few breached services someone used, we're talking about potentially hundreds of them. Secondly, many of the services that appear next to email addresses in the stealer logs are precisely the sort of thing we flag as sensitive and hide from public view. There's a heap of Pornhub. There are health-related services. Religious one. Political websites. There are a lot of services there that merely by association constitute sensitive information, and we just don't want to take the risk of showing that info to the masses.

The second point means that companies doing domain searches (for which they already need to prove control of the domain), can pull back the list of the websites people in their organisation have email addresses next to. When the company controls the domain, they also control the email addresses on that domain and by extension, have the technical ability to view messages sent to their mailbox. Whether they have policies prohibiting this is a different story but remember, your work email address is your work's email address! They can already see the services sending emails to their people, and in the case of stealer logs, this is likely to be enormously useful information as it relates to protecting the organisation. I ran a few big names through the data, and even I was shocked at the prevalence of corporate email addresses against services you wouldn't expect to be used in the workplace (then again, using the corp email address in places you definitely shouldn't be isn't exactly anything new). That in itself is an issue, then there's the question of whether these logs came from an infected corporate machine or from someone entering their work email address into their personal device.

I started thinking more about what you can learn about an organisation's exposure in these logs, so I grabbed a well-known brand in the Fortune 500. Here are some of the highlights:

1. 2,850 unique corporate email addresses in the stealer logs
2. 3,159 instances of an address against a service they use, accompanied by a password (some email addresses appeared multiple times)
3. The top domains included paypal.com, netflix.com, amazon.com and facebook.com (likely within the scope of acceptable corporate use)
4. The top domains also included steamcommunity.com, roblox.com and battle.net (all gaming websites likely not within scope of acceptable use)
5. Dozens of domains containing the words "porn", "adult" or "xxx" (definitely not within scope!)
6. Dozens more domains containing the corporate brand, either as subdomains of their primary domain or org-specific subdomains of other services including Udemy (online learning), Amplify ("strategy execution platform"), Microsoft Azure (the same cloud platform that HIBP runs on) and Salesforce (needs no introduction)

That said, let me emphasise a critical point:

This data is prepared and sold by criminals who provide zero guarantees as to its accuracy. The only guarantee is that the presence of an email address next to a domain is precisely what's in the stealer log; the owner of the address may never have actually visited the indicated website.

Stealer logs are not like typical data breaches where it's a discrete incident leading to the dumping of customers of a specific service. I know that the presence of my personal email address in the LinkedIn and Dropbox data breaches, for example, is a near-ironclad indication that those services exposed my data. Stealer logs don't provide that guarantee, so please understand this when reviewing the data.

The way we've decided to implement these two use cases differs:

1. Individuals who can verify they control their email address can use the free notification service. This is already how people can view sensitive data breaches against their address.
2. Organisations monitoring domains can call a new API by email address. They'll need to have verified control of the domain the address is on and have an appropriately sized subscription (essentially what's already required to search the domain).

We'll make the individual searches cleaner in the near future as part of the rebrand I've recently been talking about. For now, here's what it looks like:

Because of the recirculation of many stealer logs, we're not tracking which domains appeared against which breaches in HIBP. Depending on how this experiment with stealer logs goes, we'll likely add more in the future (and fill in the domain data for existing stealer logs in HIBP), but additional domains will only appear in the screen above if they haven't already been seen.

We've done the searches by domain owners via API as we're talking about potentially huge volumes of data that really don't scale well to the browser experience. Imagine a company with tens or hundreds of thousands of breached addresses and then a whole heap of those addresses have a bunch of stealer log entries against them. Further, by putting this behind a per-email address API rather than automatically showing it on domain search means it's easy for an org to not see these results, which I suspect some will elect to do for privacy reasons. The API approach was easiest while we explore this service then we can build on that based on feedback. I mentioned this was experimental, right? For now, it looks like this:

Lastly, there's another opportunity altogether that loading stealer logs in this fashion opens up, and the penny dropped when I loaded that last one mentioned earlier. I was contacted by a couple of different organisations that explained how around the time the data I'd loaded was circulating, they were seeing an uptick in account takeovers "and the attackers were getting the password right first go every time!" Using HIBP to try and understand where impacted customers might have been exposed, they posited that it was possible the same stealer logs I had were being used by criminals to extract every account that had logged onto their service. So, we started delving into the data and sure enough, all the other email addresses against their domain aligned with customers who were suffering from account takeover. We now have that data in HIBP, and it would be technically feasible to provide this to domain owners so that they can get an early heads up on which of their customers they probably have to rotate credentials for. I love the idea as it's a great preventative measure, perhaps that will be our next experiment.

Onto the passwords and as mentioned earlier, these have all been extracted and added to the existing Pwned Passwords service. This service remains totally free and open source (both code and data), has a really cool anonymity model allowing you to hit the API without disclosing the password being searched for, and has become absolutely MASSIVE!

I thought that doing more than 10 billion requests a month was cool, but look at that data transfer - more than a quarter of a petabyte just last month! And it's in use at some pretty big name sites as well:

That's just where the API is implemented client-side, and we can identify the source of the requests via the referrer header. Most implementations are done server-side, and by design, we have absolutely no idea who those folks are. Shoutout to Cloudflare while we're here for continuing to provide the service behind this for free to help make a more secure web.

In terms of the passwords in this latest stealer log corpus, we found 167 million unique ones of which only 61 million were already in HIBP. That's a massive number, so we did some checks, and whilst there's always a bit of junk in these data sets (remember - criminals and formatting!) there's also a heap of new stuff. For example:

1. Tryingtogetkangaroo
2. Kangaroolover69
3. fuckkangaroos

And about 106M other non-kangaroo themed passwords. Admittedly, we did start to get a bit preoccupied looking at some of the creative ways people were creating previously unseen passwords:

1. passwordtoavoidpwned13
2. verygoodpassword
3. AVerryGoodPasswordThatNooneCanGuess2.0

And here's something especially ironic: check out these stealer log entries:

People have been checking these passwords on HIBP's service whilst infected with malware that logged the search! None of those passwords were in HIBP... but they all are now 🙂

Want to see something equally ironic? People using my Hack Yourself First website to learn about secure coding practices have also been infected with malware and ended up in stealer logs:

So, that's the experiment we're trying with stealer logs, and that's how to see the websites exposed against an email address. Just one final comment as it comes up every single time we load data like this:

We cannot manually provide data on a per-individual basis.

Hopefully, there's less need to now given the new feature outlined above, and I hope the massive burden of looking up individual records when there are 71 million people impacted is evident. Do leave your comments below and help us improve this feature to become as useful as we can possibly make it.

This week I'm giving a little teaser as to what's coming with stealer logs in HIBP and in about 24 hours from the time of writing, you'll be able to see the whole thing in action. This has been a huge amount of work trawling through vast volumes of data and trying to make it usable by the masses, but I think what we're launchung tomorrow will be awesome. Along with a new feature around these stealer logs, we've also added a huge number of new passwords to Pwned Passwords not previously seen before. Now, for the first time ever, "fuckkangaroos" will be flagged by any websites using the service 😮 More awesome examples coming in tomorrow's blog post, stay tuned!

References

1. Sponsored by: Report URI: Guarding you from rogue JavaScript! Don’t get pwned; get real-time alerts & prevent breaches #SecureYourSite
2. Publicly asking for a security contact ios really not something I want to be doing (it tends to be a last resort after not being able to raise the company via various other channels)
3. Massive kudos to Synology for making the DiskStation rollover process entirely seamless (little bit of work restoring Plex, but at least there was zero data loss)

A super quick intro today as I rush off to do the next very Dubai thing: drive a Lambo through the desert to go dirt bike riding before jumping in a Can-Am off-roader and then heading to the kart track for a couple of afternoon sessions. I post lots of pics to my Facebook account, and if none of that is interesting, here's this week's video on more infosec-related topics:

References

1. Sponsored by: Cyberattacks are guaranteed. Is your recovery? Protect your data in the cloud. Join Rubrik’s Cloud Resilience Summit.
2. The Armenian Government is now the 37th to have free and open access to their domains on HIBP (this gives them API-level domain searches to their gov TLD)
3. After two and a bit years on sale, we're now giving away "Pwned" the book, for free (go grab it in PDF or EPUB format)

I wouldn't say this is a list of my favourite breaches from this year as that's a bit of a disingenuous term, but oh boy were there some memorable ones. So many of the incidents I deal with are relatively benign in terms of either the data they expose or the nature of the service, but some of them this year were absolute zingers. This week, I'm talking about the ones that really stuck out to me for one reason or another, here's the top 5:

References

1. Sponsored by: 1Password Extended Access Management: Secure every sign-in for every app on every device.
2. The Spoutible breach was one of the most bizarre instances of returning unnecessary data via an API I've ever seen (passwords, 2FA secrets and the code used in "magic links" to reset passwords)
3. It's one thing for spyware to be used for stalking partners against their terms and conditions, it was quite another for pcTattletale to explicitly refer to marital infidelity as a use case for the product (this data breach actually killed the company)
4. The "Combolists Posted to Telegram" breach was more significant for the stealer logs than it was the combolists aggregated from other sources (that really brought this class of breach into the spotlight for me)
5. The National Public Data breach was much more significant for the exposure of hundreds of millions of social security numbers than it was for the email addresses that went into HIBP (that's another company that folded as a result of their breach)
6. The Muah.AI breach exposed a trove of requests by users to create CSAM images (the linked thread is a mind-boggling series of tweets about both the content and the justifications offered for not having controls on the images created)