This post was originally published on this site

[This is a Guest Diary by Jackie Nguyen, an ISC intern as part of the SANS.edu BACS program]

The ISC internship didn't just teach me about security, it changed how I thought about threats entirely. There's something intriguing about watching live attacks materialize on your DShield Honeypot, knowing that somewhere across the world, an attacker just made a move. And the feedback loop of writing detailed attack observations, then having experienced analysts critique and refine your analysis? That's where real learning happens. One attack observation in particular stands out as a perfect example of what makes this internship so powerful. Let me show you what I discovered!

The Beginning…

On November 10, 2025, my honeypot captured very interesting activity that really demonstrates how evolved modern threat actors are getting. What initially appeared to be a simple, but successful SSH brute force attempt quickly revealed itself as something far more concerning, a deployment of an advanced trojan designed for long-term persistence and evasion.

What happened?

Suspicious activity was detected when the IP address 103[.]148[.]195[.]161 successfully SSH’d into my honeypot using the credentials username “root” and password “linux”. The bad actor maintained access to the honeypot for 1 minute and 45 seconds but ultimately ran no commands. Instead, the attacker uploaded a single file, a trojan binary named “sshd” designed to evade security detections by pretending to be the OpenSSH daemon. It was an Executable and Linkable Format (ELF) binary (7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d) that was classified as malicious by VirusTotal and Hybrid-Analysis.

We won’t be able to see what the Trojan did on my honeypot at this time, however, I found the hash on Hybrid-Analysis and got a good idea of what the trojan does.

A screenshot of the cowrie output using Jesse La Grew’s cowrieprocessor [4]

Trojan File Analysis

MITRE ATT&CK MAPPING

•    T1078 – Valid Accounts
•    T1110.001 – Brute Force
•    T1204.002 – User Execution
•    T1036.005 – Masquerading
•    T1554 – Compromise Client Software Binary
•    T1548.001 – Abuse Elevation Control Mechanism
•    T1027 – Obfuscated Files or Information
•    T1497 – Virtualization/Sandbox Evasion
•    T1480 – Execution Guardrails
•    T1003.008 – OS Credential Dumping

Prevent Similar Attacks

1.    Disable Password Authentication and utilize SSH keys instead
2.    IP Allowlisting
3.    IDS/IPS/EDR
4.    Threat Hunting
5.    MFA

What does this show?

This really shows how much effort sophisticated attackers would put in for long-term persistence and advanced evasion. Attacks from a government IP address doesn’t always mean it’s the government; it more than likely would mean that they were compromised. If you think about it logically, why would a nation-state threat actor use their actual government IP address to execute attacks?

Importance?

It’s important when working on a high performing security team to not attribute attacks to the wrong threat actor. Politically, this may cause problems, especially if the company you’re working for has a large media presence. Problems including wrongful retaliation and political tension could arise from making this mistake.

This attack also shows how threat actors use legitimate processes to blend in with normal ones. We must remember that the goal of this attacker is most likely long-term so they will do everything they can to evade your defenses.

Actionable Intelligence for Defenders

Threat hunting is a critical part of any security program and having concrete Indicators of Compromise (IOCs) like file hashes, malicious IP addresses, and more would give teams actionable intelligence to use immediately. This observation also helps defenders understand what to look for. Brief sessions without commands can be just as dangerous as those with suspicious activity.

Key Takeaways

This attack really shows how threat actors are getting more sophisticated. By uploading a legitimate looking trojan instead of running commands, the attacker could have avoided the typical red flags most monitoring tools look for. The use of a government IP address also teaches us an important lesson not to immediately jump to conclusions solely based on IP block owner since it might have been compromised. For analysts out there, what seems to be a quiet session can sometimes be the most dangerous.

[1] https://www.virustotal.com/gui/file/7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d/detection
[2 ]https://www.abuseipdb.com/whois/103.148.195.161
[3] https://hybridanalysis.com/sample/7a9da7d10aa80b0f9e2e3f9e518030c86026a636e0b6de35905e15dd4c8e3e2d/6542c8b6abeb51c5ee0bbf2a
[4] https://github.com/jslagrew/cowrieprocessor
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

[This is a Guest Diary by James Woodworth, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].

In July 2025, many of us were introduced to the Microsoft SharePoint exploit chain known as ToolShell. ToolShell exploits the deserialization and authentication bypass vulnerabilities, CVE-2025-53770 [2] and CVE-2025-53771 [3], in on-premises SharePoint Server 2016, 2019, and Subscription editions. When the exploit chain was initially introduced, threat actors used payloads that attempted to upload web shells to a SharePoint server’s file system. The problem for threat actors was that the uploaded web shells were easily detectable by most Endpoint Detection and Response (EDR) solutions. So the threat actors upped the game and reworked their payloads to execute in-memory. This new technique made it more difficult for defenders to detect the execution of these new payloads [4].

Many articles have been written on the technical details of the ToolShell vulnerabilities, so I won’t go into an in-depth analysis here. If you want an in-depth analysis, check out the Securelist article, ToolShell: a story of five vulnerabilities in Microsoft SharePoint [5]. What I will present to you in this post is a process using Zeek Network Security Monitor, DaemonLogger, and Wireshark to hunt for in-memory ToolShell exploit payloads and how to decode them for further analysis.

Review Zeek Logs

The first step in the hunt is to review the HTTP requests to our SharePoint server. We will do this by reviewing our Zeek http logs and looking for POST requests that contain the following indicators of a malicious request:

• URLs:
  • /_layouts/15/ToolPane.aspx/<random>?DisplayMode=Edit&<random>=/ToolPane.aspx
  • /_layouts/16/ToolPane.aspx/<random>?DisplayMode=Edit&<random>=/ToolPane.aspx
• Referer headers:
  • /_layouts/SignOut.aspx
  • /_layouts/./SignOut.aspx
• Request Body:
  • Length greater than 0

Zeek log files are rotated and compressed daily. To review the compressed log files over multiple days we use a combination of two tools, zcat and zcutter.py [6]. From the /opt/zeek/logs directory we run the following commands to search all Zeek http logs for August 2025.

zcat 2025-08**/http*.log.gz | ~/bin/zcutter.py -d ts id.orig_h id.resp_p host method uri user_agent request_body_len | grep ToolPane | grep -v ""request_body_len": 0}"

Reviewing the returned http logs entries, we see many matching the indicators of a malicious request. We will focus on the highlighted entries from August 24, 2025.

Figure 1: Zeek http.log file matching indicators of a malicious request.

 

Prepare PCAP Files

Now that we have identified potential http requests to analyze further, our next step in the hunt will be to prepare our PCAP files for packet analysis. For this scenario we are using DaemonLogger to capture packets [7]. Each day DaemonLogger creates two PCAP files.

 

Figure 2: DaemonLogger PCAP files from October 31, 2025.

 

We will need to merge the two PCAP files to ensure we are analyzing all packets that were captured for the day in question. To do this we will use the tool mergecap from Wireshark [8]. The following command will merge the two PCAP files that we identified in Figure 2 above into a new file named 2025-08-24.pcap.

./mergecap ~/pcaps/daemonlogger.pcap.* -w ~/pcaps/2025-08-24.pcap

 

Figure 3: Mergecap command and resulting merged PCAP file.

 

Packet Analysis with Wireshark

We will now analyze the newly created PCAP file using Wireshark. With the following filter we can limit the packets displayed to only those packets containing POST requests to the URL /_layouts/15/ToolPane.aspx.

Filter: _ws.col.info matches "POST /_layouts/15/ToolPane.aspx"

 

Figure 4: Wireshark displaying packets containing POST requests to the URL /_layouts/15/ToolPane.aspx.

 

Analyzing the packet with the timestamp 2025-08-24T04:22:33, we see an HTTP POST request to the URL /_layouts/15/toolpane.aspx/lx?DisplayMode=Edit&lx=/ToolPane.aspx and a Referer header of /_layouts/./SignOut.aspx. The analysis also shows a URL encoded payload being sent via the MSOtlPn_DWP parameter. The parameter contains a property named CompressedDataTable that in turn contains a malicious payload that attempts to exploit the SharePoint deserialization vulnerability.

 

Figure 5: Wireshark HTTP Stream showing malicious POST request

 

Deserialization Vulnerability Payload Analysis

Our hunt is almost complete. Now it is time to decode the malicious deserialization payload to see what it contains. With the Wireshark HTTP Stream window still open, copy the CompressedDataTable property and save to a file named property-encoded.txt. This will include everything between CompressedDataTable%3D%22 and %22+DataTable-CaseSensitive. The property usually starts with the characters H4sI.

 

Figure 6: Wireshark HTTP Stream highlighting the beginning of the CompressedDataTable property.

 

With the CompressedDataTable property copied to a file we can decode the property using the commands below and output the results to the file property-decoded.txt.

cat property-encoded.txt | python3 -c "import sys, urllib.parse as ul; print(ul.unquote_plus(sys.stdin.read().strip()))" | base64 -d | zcat > property-decoded.txt

 

Figure 7: Decoded view of the CompressedDataTable property with the encoded malicious payload.

 

One more copy and decode and we will have our malicious in-memory payload. Open the property-decoded.txt file created in the step above. Copy the MethodParameter string to a new file named method-encoded.txt. The beginning of the string is highlighted in Figure 7 above. We will then run the following commands to decode the method.

cat method-encoded.txt | base64 -d > method-decoded.txt

Once our payload is decoded, we see that it contains a known malicious .NET Dynamiclink Library (DLL) binary named osvmhdfl.dll. If this in-memory payload was executed successfully on a vulnerable SharePoint server, it could extract machine keys and other system information and return the information in the HTTP response [9].

 

Figure 8: Partially decoded method containing a malicious payload.

 

Additional Payloads Discovered

Using this process, I have discovered security scanner payloads and payloads containing encoded PowerShell commands.

Nuclei Scanner Template CVE-2025-53770

The Project Discovery Nuclei Scanner, when using the http template CVE-2025-53770, sends the payload in Figure 9. This payload contains the .NET Dynamic-link Library (DLL) binary named jlaneafi.dll. If the SharePoint server is vulnerable, an additional HTTP response header of X-Nuclei is returned with a value of CVE-2025-53770 [10].

 

Figure 9: Partially decoded method containing a Nuclei Scanner template CVE-2025-53770 payload.

 

Encoded PowerShell Commands

I have seen variations of the payload in Figure 10 that contain encoded PowerShell commands.

 

Figure 10: Partially decoded method containing an encoded PowerShell payload.

 

Decoding the EncodedCommand value exposes the PowerShell command in Figure 11 below. If this PowerShell executed successfully it could extract system information and send that information to the threat actor’s server on port 40443.

 

Figure 11: Decoded PowerShell command.

 

Conclusion

We have completed our hunt, found our in-memory ToolShell exploit payload, and have seen additional payloads found in the wild. Use this process to hunt for payloads in your own environment and discover what new techniques threat actors are attempting against on-premise SharePoint servers vulnerable to the ToolShell exploit chain.

 

References

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-53770
[3] https://nvd.nist.gov/vuln/detail/CVE-2025-53771
[4] https://www.recordedfuture.com/blog/toolshell-exploit-chain-thousands-sharepointservers-risk
[5] https://securelist.com/toolshell-explained/117045/
[6] https://www.activecountermeasures.com/zcutter-more-flexible-zeek-log-processing/
[7] https://github.com/Cisco-Talos/Daemonlogger
[8] https://www.wireshark.org/docs/wsug_html_chunked/AppToolsmergecap.html
[9] https://www.cisa.gov/sites/default/files/2025-08/MAR-251132.c1.v1.CLEAR_.pdf
[10] https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2025/CVE-2025-53770.yaml

 

—
Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

YARA-X's 1.10.0 release brings a new command: fix warnings.

If you have a rule that would generate a warning with a help section (explaining how to fix it), like this example rule:

 

rule FixableCountWarning
{
    strings:
        $a1 = "malicious"
        $a2 = "badstuff"

    condition:
        0 of ($a*)
}

Then YARA-X from version 1.10.0 on can fix this for you

You will get a warning when you use this rule:

The suggested fix is to replace 0 with none.

This can be done automatically with command fix warnings:

Remark that this command alters your original rule file, and doesn't make a backup of the unaltered file:

 

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Searchlight Cyber today released a blog detailing CVE-2025-61757, a vulnerability they reported to Oracle. Oracle released a patch for the vulnerability as part of its October Critical Patch Update, which was released on October 21st.

Based on Searchlight Cyber's blog, the issue is pretty trivial to exploit: All URLs that end in ".wadl" are exempt from authentication. Adding just ".wadl" to a URL would not work, as this would point to a different, non-existent file. Searchlight Cyber's blog shows that adding ";.wadl" is the solution to access arbitrary URLs. They offer the following PoC:

/iam/governance/applicationmanagement/templates;.wadl

and show how it can lead to remote code execution.

Seeing this PoC, I went over our logs to look for possible uses of this pattern and found one:

/iam/governance/applicationmanagement/api/v1/applications/groovyscriptstatus;.wadl

This URL was accessed several times between August 30th and September 9th this year, well before Oracle patched the issue. There are several different IP addresses scanning for it, but they all use the same user agent, which suggests that we may be dealing with a single attacker.

Attacker IP Addresses:

89.238.132.76
185.245.82.81
138.199.29.153

The User Agent: 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Sadly, we did not capture the bodies for these requests, but they were all POST requests. The content-length header indicated a 556-byte payload.

The participating IP addresses also scanned for these notable URLs/Vulnerabilities:

/o/portal-settings-authentication-opensso-web/com.liferay.portal.settings.web/test_opensso.jsp (CVE-2025-4581)

as well as some scans that appear to be bug bounties and URLs that attempt to exploit Log4j.

 

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.