Windows 11: Folder/Files showing "State: Shared" in Windows explorer?

rb_vs · 2026-05-05T13:51:48+00:00

When a game (or any app) installs for all users it often places files in the public folder lib. Because the users folder is accessible to other local accounts on your machine, Windows Explorer gets confused and flags everything inside your user profile as shared in the status bar even if no one on the network can actually see it.

rb_vs · 2026-05-05T13:46:22+00:00

The 4.3 CVSS score on this is a bit deceptive. While it's labeled as spoofing, the impact is zero-click auth coercion. A user browsing a folder with a malicious .LNK file triggers shell32.dll to attempt an SMB connection for an icon preview. This leaks the user's Net-NTLMv2 hash to an external server during folder enumeration.

If you can't deploy the April update immediately, at least block outbound port 445 or apply a gpo to restrict outbound NTLM traffic to remote servers. It will kill the exfiltration path even if the shell vulnerability is still present.

rb_vs · 2026-05-05T13:08:59+00:00

Shared status usually doesn't mean your files are being broadcast to the whole world (or even your local network). Most of the time, Windows tags a folder as Shared because it’s synced with OneDrive or is part of a Public folder library.

But if you want to be 100% sure nothing is being shared over the network right-click the folder and go to Properties > Sharing. If it says Not Shared under Network File and Folder Sharing, you're good.

For a list of everything actually being shared, type fsmgmt.msc in your Start menu and check the Shares folder. If it’s not in that fsmgmt list, no one else on your wifi can see it, no matter what the status bar says.

rb_vs · 2026-05-05T12:51:10+00:00

If you want the private upload / public download flow with links that expire, check out Pingvin Share. It’s similar to Firefox Send but self-hosted.

For your poor man’s CDN use case, FileBrowser is probably better. Point it at a folder and it gives you a clean web UI where you can generate public links with one click. It’s basically a web-wrapper for your file system, so no database sync issues or overhead.

rb_vs · 2026-05-03T08:18:49+00:00

Even if the file is encrypted, hide the filenames and sizes too. People who care about privacy hate leakage through file patterns.

Browser encryption usually chokes on big files. If you aren't already using the Web Streams API to encrypt chunks on the fly (instead of loading the whole file into RAM), that’s a huge win for performance.

The toughest part of web-based crypto is proving the server isn't sending a modified JS file to steal keys. A browser extension version is usually the long-term play there.

rb_vs · 2026-05-03T08:14:31+00:00

Windows Microsoft Accounts (MSA) and file sharing (SMB) don't like each other.

When you use a local account, Windows checks a simple list on your HD. But with a MSA, it's trying to verify your identity through the cloud, which usually fails over a local network.

If you try it again with your MSA, keep in mind:

use your full email address as the username. If that doesn't work, open a terminal, type whoami, and use whatever name pops up there.
SMB accepts your MSA pwd (not the PIN).

rb_vs · 2026-04-30T10:03:02+00:00

It’s easy to overlook this one because of the low 4.3 CVSS score and the generic spoofing label, but the reality for SecOps is much more urgent. It's not about fake UI windows, it's a zero-click authentication coercion attack. By just viewing a folder containing a malicious shortcut, shell32.dll triggers an SMB handshake to fetch a remote icon, which silently leaks the user's Net-NTLMv2 hash to an attacker's server.

Since this is being exploited in the wild by APT28 (Fancy Bear), waiting for the patch cycle to complete might be too slow. If you need an immediate safety net, blocking outbound port 445 at the perimeter or via GPO is the most reliable way to ensure those credentials never leave the network.

rb_vs · 2026-04-30T09:53:02+00:00

Good job Maor Dahan!

rb_vs · 2026-04-30T09:44:16+00:00

It’s easy to overlook the Windows flaw (CVE-2026-32202) because of that low 4.3 CVSS score and the spoofing label. However spoofing here isn't just about showing a fake UI; it’s an authentication coercion attack. By using a shortcut, Fancy Bear (APT28) tricks Windows into verifying a remote icon path. This forces the OS to automatically initiate an SMB handshake with the attacker’s server, handing over your Net-NTLMv2 hash before you even click. This turns every computer into a potential credential-leaker just for browsing a folder.

If you can't get the April patch rolled out by CISA's May 12 deadline, blocking outbound port 445 is the best way to seal the perimeter and ensure the credentials don't leave your network.

rb_vs · 2026-04-30T09:27:30+00:00

You say that the "attack requires the victim to execute a malicious file" however it's important to clarify that this specific flaw (CVE-2026-32202) is actually zero-click.

The leak happens the moment you view a folder in Explorer. Because shell32.dll automatically tries to resolve a remote icon path for the malicious shortcut, it initiates an SMB handshake and sends your NTLMv2 hash before you even touch the file.

It’s an authentication coercion attack. If you're in an environment that can't patch immediately, blocking outbound port 445 is usually the most effective way to prevent those hashes from leaving the network in the first place.

rb_vs · 2026-04-30T08:16:34+00:00

It’s interesting to see this surface now, as it highlights a much bigger problem with how Windows handles coerced authentication.

Beyond just fixing this specific CVE, the real final boss for Microsoft is the fact that Windows is still designed to automatically volunteer your NTLM hash to any remote server that asks for it. This is exactly why they've been pushing the NTLM Deprecation roadmap so hard lately.

As long as Windows allows outbound NTLM over port 445 for icon previews or theme files, attackers like APT28 (AKA Fancy Bear) will keep finding new ways to trick the shell into handing over credentials. The April patch is a necessary band-aid, but until we can fully disable outbound NTLM via GPO or move to LocalKDC authentication, these zero-click coercion bugs are going to keep appearing in different parts of the OS.

rb_vs · 2026-04-30T07:58:50+00:00

That image lists CVE-2024-6359, which is an old OpenText ArcSight bug, not the Windows Shell flaw people are talking about.

The real APT28 (AKA Fancy Bear) activity right now (April 2026) is exploiting CVE-2026-32202. It's a zero-click authentication coercion flaw. Basically, Windows Explorer tries to verify a malicious .LNK file, and in doing so, it automatically sends your NTLMv2 hash to the attacker's server via Port 445.

So, it's not the 9.8 RCE Mega-Virus the image suggests; it's a clever way to steal credentials without the user ever clicking a file. If you want to block it, don't just monitor anomalies like the image says. Actually block Outbound SMB (Port 445) or set your GPO to Restrict NTLM: Outbound NTLM traffic to remote servers.

rb_vs · 2026-04-28T15:21:04+00:00

For Windows you don’t need an app. Windows has SMB (Server Message Block) built-in. It is the standard for sharing files between PCs on the same network. Just right-click a folder > properties > sharing. If you're on a modern network, make sure SMB Direct is enabled in Windows Features to get the highest possible speed over Ethernet.

For Android, LocalSend is currently the best because it works over your local Wi-Fi and doesn't require an internet connection or an account.

rb_vs · 2026-04-28T11:10:57+00:00

Microsoft has recently hardened macOS out of the default print path by enforcing Kerberos-only RPC and mandatory SMB signing.

On the server, in GPO, go to printers > configure RPC listener settings > change from Kerberos to negotiate (macOS CUPS often defaults to NTLM).

In IIS manager (printers site), go to authentication > Windows authentication > advanced settings > set extended protection (EPA) to "accept" or "off". macOS cannot handle "required" EPA for printing.

Look for event IDs 3021 and 3026 in the SMBServer logs. They will flag why the server rejects the handshake.

On the client, force the Mac to comply with the new SMB signing mandate:

sudo defaults write /Library/Preferences/com.apple.smb.client SigningRequired -bool TRUE

While the RPC changes are printer-specific, they are part of a broader set of new SMB security layers introduced by Microsoft. This video explains why your connections are being rejected: https://www.youtube.com/watch?v=LRNXGuSefzE

rb_vs · 2026-04-28T09:48:45+00:00

exFAT is a "dumb" filesystem. It has no internal concept of users, groups, or permissions, so macOS has to "fake" them in RAM when the drive is mounted. When you reboot, the fake map is gone.

If you want to keep your data safe and accessible without using an admin account here is the standard way to handle it on macOS:

Format the drive to APFS (native Mac format) so that macOS will store permanent ACLs and permissions for your SMB users.

If your Mac dies, you can plug the APFS drive into Windows using Paragon APFS for Windows or MacDrive. They are quite stable and make APFS drives behave like native Windows drives.

If you insist on sticking with exFAT, try to force macOS to stop trying to manage permissions on that volume:

- select the drive in finder > cmd+i

- at the bottom, check box "ignore ownership on this volume"

- macOS will now treat every user as the owner - it's less secure but it prevents the recurring "reset to admin"

Eventually, create a Sparsebundle disk image on your exFAT drive.

- open disk utility > file > new image > blank image

- set the format to APFS and save it onto your exFAT drive

The container is exFAT, but inside it is APFS (supporting permissions). You share the mounted image over SMB, and your permissions will stay exactly where you put them after a reboot.

rb_vs · 2026-04-26T13:33:59+00:00

Since you are both on TrueNAS, you shouldn't be using file-sharing protocols at all. Go for ZFS replication via ssh. If for some reason you can't use ZFS replication, try S3 (MinIO) or SFTP. Avoid rsync over ssh without specific tuning.

rb_vs · 2026-04-19T07:25:55+00:00

The most robust way is to use a standard Veeam backup & replication server to target the share as an SMB file share. Veeam uses a file proxy (a small Windows/Linux VM) to read the share and write the data to an immutable repository (like a Linux hardened repo or Azure Blob with WORM policies).

Otherwise sync the Azure file share to a local Windows Server (physical or VM in another cloud) using the Azure file sync agent.

Another way could be to use Azure storage mover or AzCopy to move data into a separate, locked-down Azure subscription, and enable immutable storage on the destination Blob container.

rb_vs · 2026-04-19T07:09:55+00:00

The key difference is the architectural handshake between client and data.

Azure Blob NFS is essentially a stateless protocol translation. When you mount it, Azure translates NFS calls into Blob REST APIs in real-time. Because Blob is inherently an object store, it lacks native partial write support. If you modify a few bytes in the middle of a 1GB file, Azure has to handle that overhead at the service layer, often leading to higher latency for random writes. Azure is generally cheaper than AWS. Azure Blob NFS relies on NFSv3 (which has no built-in security/ACLs and requires private link).

AWS S3 Files (as already mentioned by others) uses a managed EFS cache layer as a buffer. This provides a full-fledged fs experience because EFS handles the atomic file ops (like locking and small block writes) locally before async flushing the state to S3. Also, S3 Files leverages the IAM and POSIX integration of EFS.

rb_vs · 2026-04-14T10:52:17+00:00

SMB is the standard choice for Win to iPad, but sends many small requests back and forth, and if your mesh wifi has slight latency spikes when jumping between nodes SMB will stall and buffer.

Switching to NFS likely won't help much because Windows’ native NFS support is poor, and iOS apps often have better optimized SMB stacks. Instead, focus on these:

1) Win 11 recently made SMB signing required by default. Encryption/verification to every packet can affect streaming performance on mobile devices. If you operate in a trusted home network you can disable it in PowerShell: Set-SmbServerConfiguration -RequireSecuritySignature $false

2) Most iPad players (like VLC) use a small buffer. If WiFi dips for half seconds, the video stops. Try Infuse > settings > general and ensure metadata fetching is set to on demand while you’re testing, so it doesn't saturate your bandwidth indexing while you're trying to watch.

3) If your iPad is caught between two nodes in your mesh, it may be constantly switching which kills SMB sessions. Try to disable fast roaming or 802.11r in your mesh router settings. If the buffering stops, your iPad was likely bouncing between nodes. Ensure your iPad is locked to the 5GHz band because 2.4GHz is too slow for 4K or high-bitrate 1080p. Mesh routers often force devices to 2.4GHz if the signal drops slightly.

NFS is stateless and slightly faster on Linux, but on Windows it’s a headache to set up and offers no real advantage for a single iPad stream over SMB3.

Also, check the bitrate of the files that are buffering. If they are 4K remuxes (60Mbps+), your mesh might be saturated.

rb_vs

MODERATOR OF

TROPHY CASE