Abusing DLLs EntryPoint for the Fun

https://isc.sans.edu/diary/Abusing%20DLLs%20EntryPoint%20for%20the%20Fun/32562

https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

SANS Stormcast – Monday, December 15 2025

Handler on Duty: Guy Bruneau

---

Topics Covered

• Abusing DLL Entry Points for the Fun

• Apple Patches Everything: December 2025 Edition

• ClickFix Attacks Still Using the Finger

• Denial of Service and Source‑Code Exposure in React Server Components

---

Podcast Transcript

Hello and welcome to the Monday, December 15th, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ullrich, recording today from Jacksonville, Florida. And this episode is brought to you by the SANS.edu Undergraduate Certificate Program in Applied Cybersecurity.



Well, this Monday we have a number of diaries to talk about. The first one comes from Xavier and, as typical for Xavier, is of interest to anybody reverse‑analyzing malware. Xavier is taking a closer look at DLLs. Now DLLs, libraries of course in Windows, are loaded by software in order to provide additional functionality. As any kind of library, there are certain features that are being exposed by the library. But one thing that’s often overlooked here is the entry point. A developer can define an entry point that is executed as the library is being loaded. There are a couple of different ways it can be executed and Xavier is explaining this.



The reason it’s important for malware analysis is that you may see a library being loaded—a DLL being loaded—but then actually no function in that DLL is ever executed. In that case you have to look at the entry point to see if it contains any code of interest, because that code was executed just as the DLL was loaded without any specific function being called.



The next diary comes from Brad. Brad wrote about two particular examples of a recent ClickFix campaign. ClickFix again is where you have the CAPTCHA that tricks you into copy‑pasting PowerShell commands into a command prompt. The part Brad looked at is something we have talked about recently: the use of the *finger* command in these scripts. To obfuscate what’s actually happening, the attacker tricks the victim into posting a command that uses the finger command. The finger command is basically a very simple TCP server: you open a connection and retrieve ASCII data—nothing more. In this case the data coming back is a PowerShell script, which is then piped to CMD on the Windows host. It’s a very simple technique that provides additional obfuscation.



The traffic goes over port 79, which is no longer really used for the finger service. It’s definitely a port you should consider blocking outbound from your network, just like port 445 and other similar ports that you probably shouldn’t allow outbound. You might even want to create a list of ports that are allowed outbound.



On Friday we also got a surprise from Apple: updates to all of Apple’s operating systems fixing a number of vulnerabilities. I counted 48 vulnerabilities being addressed. The most interesting were two WebKit vulnerabilities that can lead to code execution and have already been exploited in the wild before the patch was released, as usual in targeted attacks. Those are definitely something you want to apply over the next week and hope not too many people missed because of the Friday release. Patching on Friday is always a little discouraged, but there wasn’t anything that should have been prioritized beyond your regular patch cycle. These already‑exploited vulnerabilities are only seen in limited attacks and there is no public exploit as far as I’m aware.



There was also an interesting issue in the Compressor utility (part of Apple’s video‑editing suite). The Compressor actually listens for network traffic and can execute arbitrary code when it receives traffic. The advisory states the network traffic only works if it’s on the same local network and you have the utility running. It’s not a service that runs constantly in the background, so the risk is limited, but you still don’t want to miss this update.



Finally, React Server Components keep on giving. This time there are two denial‑of‑service vulnerabilities and a third vulnerability that, in my opinion, is more interesting even though it has a lower CVSS score. The third vulnerability may potentially leak source code. It only applies when you are stringifying user‑submitted data; the function code itself gets stringified and can be returned as part of the response. This affects React Server Components just like the earlier “React‑to‑shell” issue, so if your application was vulnerable to that, it’s probably vulnerable to these new issues as well.



That’s it for today. A quick note: this coming week I’ll be teaching while staying at home on a European schedule, so podcast publishing may be affected and the episode may be released a little earlier than normal.



Thanks for listening. Thanks for liking. Thanks for subscribing and talk to you again tomorrow. Bye.

---

End of transcript.