Notices by IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)

Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Tuesday, 09-Jun-2026 02:30:44 JST IFIN - The Independent Federated Intelligence Network

FYI: we've removed the NatSec category from the IFIN News Feed. We aren't just about the US.

In conversation about 4 days ago from infosec.exchange permalink
Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Thursday, 04-Jun-2026 05:59:18 JST IFIN - The Independent Federated Intelligence Network

Patches are available for Nginx and Apache against the latest HTTP/2 DoS. Other servers, who knows??
https://discourse.ifin.network/t/cve-2026-49975-http-2-bomb-remote-dos-against-most-major-web-servers/536

In conversation about 9 days ago from infosec.exchange permalink
Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Wednesday, 27-May-2026 00:41:21 JST IFIN - The Independent Federated Intelligence Network

Got Nessus? Got Crowdstrike? You might also have a huge pile of false positives this morning, as Nessus attempted to run a PoC of the "MiniPlasma" exploit proactively, triggering CrowdStrike alerts.
https://discourse.ifin.network/t/crowdstrike-s1-triggering-1000s-of-high-severity-alerts-on-tenable-2026-05-25/500

In conversation about 18 days ago from infosec.exchange permalink
Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Friday, 08-May-2026 01:56:36 JST IFIN - The Independent Federated Intelligence Network

RE: https://infosec.exchange/@wdormann/116533862391306228
We love direct action you can take to confound the adversary! Disable .URL files (and .js files) today.
https://discourse.ifin.network/t/disable-url-files-before-the-baddies-use-them/393
In conversation about a month ago from infosec.exchange permalink
Attachments
1. Domain not in remote thumbnail source whitelist: media.infosec.exchange
  
  Will Dormann (@wdormann@infosec.exchange)
  
  from Will Dormann
  
  Attached: 1 image Let's talk about Windows `.URL` (InternetShortcut) files. Last year there was discussion about a vulnerability in how Windows handles `.URL` files. Specifically, when a `.URL` file specifies a `WorkingDirectory` directive, an otherwise harmless app being launched would load DLLs from the remote (e.g. WebDAV) server specified. You know, being the current working directory of the app being launched and all. This vulnerability was being [exploited in the wild](https://www.virustotal.com/gui/file/e0a44274d5eb01a0379894bb59b166c1482a23fede1f0ee05e8bf4f7e4e2fcc6), and it worked well because it bypassed annoying (to attackers) things like SmartScreen. Sure, it required the victim to click `Open` on a dialog saying `Type: Unknown File Type` (😂), but we all know that users are click-happy, so this is fine. Besides, the file clearly has a `.pdf` extension, so it should be safe (😂). Microsoft recognized the vulnerability and published an [update in the form of CVE-2025-33053](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33053). If we were to believe the [Microsoft documentation at the time](https://web.archive.org/web/20250710095434/https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts), > When the user clicks the icon, the browser is launched and displays the site associated with the shortcut. But wait... How did this `.URL` file cause a program to be launched? The `URL=` parameter specifies a website address to be loaded in the browser. Oh, naive child. Obviously a `.URL` file can directly point to code on a remote (e.g. WebDAV) server. This technique is also [being exploited ITW as well](https://www.virustotal.com/gui/file/93a2d60d1ccfe3e009b1a81951653b559e0cae01c2454244a3a0fbd49a5e4539). I reported this to Microsoft, as this has the **EXACT SAME IMPACT** as CVE-2025-33053. So if that's a vulnerability, then this too is a vulnerability, right? Bless your innocent soul. Per MSRC: > When the Shell invokes an app from a remote share, it's expected that you will see the legacy Windows Security prompt, not the SmartScreen one. SmartScreen Application Reputation (AppRep) evaluation applies to locally downloaded files that bear an Internet Zone mark of the web. It is not meant to apply to execution of files from Network Shares. Okie dokie. I'm sure Windows users surely appreciate this. But what about the [incorrect documentation](https://archive.ph/MgBI8)? After my prodding, they [updated the wording](https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts): > When the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser. Leaving in the quite misleading first sentence: > The Internet shortcut object is used to create desktop shortcuts to Internet sites. (An "Internet site" is a web page, right?) How can CVE-2025-33053 warrant a CVE, while the behavior I described has the exact same trigger and impact is **not** CVE worthy? That's pretty easy. Microsoft assigns CVEs to **updates**, not **vulnerabilities**. They are the decider as to what is a vulnerability and what is not. What can we do about it? At the very least, turn off the Windows feature that hides file extensions, **even if you have the option turned on to see file extensions**. The disdain that Microsoft has for Windows users is tangible here. On what planet would I not want to see the actual extension of a file? Go to `HKCU\InternetShortcut` and delete the `NeverShowExt` value. After this, your `pwned.pdf` file will reveal its true self as being `pwned.pdf.url`. More powerful protection would be to block the ability to receive `.URL` files via email, web browsers, etc. There is no workflow that I can imagine that requires a user to double-click on a `.URL` file that **came from the internet**. Even more powerful than that would be to disassociate `.URL` files from opening in Windows (thx @mttaggart ). This screen recording is a Windows 11 system that has no internet connectivity. The fact that no warning was displayed that SmartScreen cannot be reached is evidence that SmartScreen is not in play at all. And that dialog... `Do you want to open this file?` and `Type: Unknown File Type` Do you think that users are presented with enough information to make an informed security decision? Of course not. But obviously we all know that we can't rely on users making informed security decisions in general. Don't put users in that position.
Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Wednesday, 06-May-2026 23:16:41 JST IFIN - The Independent Federated Intelligence Network

This morning we decided to launch a "Vulnerabilities" category to track vulns without further actionable intelligence besides patching and monitoring. And wouldn't you know it, a crit on Palo Alto's User-ID portal showed up to ring it in!
https://discourse.ifin.network/t/cve-2026-0300-9-3-cvss-pan-os-unauthenticated-user-initiated-buffer-overflow-captive-portal/382
#CVE-2026-0300 #CVE #IFIN

In conversation about a month ago from infosec.exchange permalink
Embed this notice
IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)'s status on Thursday, 30-Apr-2026 07:27:15 JST IFIN - The Independent Federated Intelligence Network

After careful analysis, we believe the best option for remediation is to turn off the computers and go for a nice walk. Maybe call your mother.

In conversation about a month ago from infosec.exchange permalink

Public

Notices by IFIN - The Independent Federated Intelligence Network (ifin@infosec.exchange)

User actions

Following 0

Followers 0

Groups 0

Statistics

Feeds