This week, we briefed our clients on the importance of practicing and documenting the process of pulling logs—it can be more challenging than it sounds.
KEY TAKEAWAYS
Where the Wild Logs Are – practice gathering logs from network devices and servers and document log retention to help with incident response.
CISA and NSA issue guidance on securing on-prem Exchange servers.
Almost two years ago, PacketWatch CTI published an article titled "Where The Wild Logs Are". The article begins with the following scenario that is meant to be a thought experiment to assist IT admins and security personnel in dealing with a potential security incident. Even those organizations that went through this thought experiment back then are encouraged to revisit and review documentation to ensure it is up to date.
Scenario: You are the IT administrator for a small to medium-sized business. On a Monday morning you arrive to work only to find that all of your production servers have been encrypted with ransomware. You hire an Incident Response (IR) firm to assist in removing the threat actor from your environment and help restore your network back to working order. To assess the totality of the intrusion and identify the full extent of threat actor activity in your network, the IR firm requests logs from multiple devices, including the firewall, the virtual machine environment, and several servers, including domain controllers and file servers. Due to limited budgets, your organization does not have central logging, so logs are to be found on each individual device. How do you pull useful logs from all of these devices?
The scenario described above is, unfortunately, very common. In many environments, central logging does not exist, and logs are stored on each individual device. This can lead to many pitfalls and headaches during an IR engagement. First, most devices only store logs for a short period of time (1 - 7 days). In a lot of cases, this is too small of a time window to store relevant data for the incident. If the threat actor has a dwell time in the environment exceeding the log retention time, that data is simply lost, and the investigation will never be able to accurately paint the picture of threat actor activity. Second, many devices from a wide range of manufacturers have extremely poor documentation, especially when it comes to manually retrieving logs. This is further exacerbated when the device is end-of-life and no longer has support from the manufacturer.
How to Protect Your Organization
The simple answer is practice. For example, many organizations regularly take data backup snapshots. It is rare, however, for organizations to practice restoring from those snapshots. Understanding if and how the process works before an incident can save valuable time and give the organization confidence that they can restore data in the event of a ransomware attack.
This same level of preparation can be done with logs. Take the time to gather documentation from your vendors. Practice pulling logs from critical devices such as your firewall, web gateway, ESXi (or other virtualization) servers, Windows and Linux servers. Pulling large quantities of logs from firewalls can be especially tricky, depending on the vendor. Make sure to document what the log retention is for each of these devices. This can greatly assist prioritizing which devices to get logs from first in during incident response. Understand what type of data can be gathered from these devices. If the available logs are not sufficient to your needs, work with the vendor to find an appropriate solution. Taking the time to document and practice these procedures before an incident will greatly reduce the impact, stress, and time-to-containment of a major security incident.
On October 30, CISA and the NSA issued a joint advisory called "Microsoft Exchange Server Security Best Practices". This advisory comes on the heels of many Exchange Server versions becoming end-of-life on October 14. The document gives detailed guidance on security on-prem exchange environments, including restricting administrative access, implementing multifactor authentication (MFA), enforcing strict transport security configurations, and adopting zero-trust security model principles. Any organization that still runs on-prem Exchange servers are strongly encouraged to thoroughly review this document and implement the protections outlined.
Resources:
https://www.cisa.gov/news-events/news/cisa-nsa-and-global-partners-unveil-security-blueprint-hardening-microsoft-exchange-servers
https://www.nsa.gov/Portals/75/documents/resources/cybersecurity-professionals/CSI_Microsoft_Exchange_Server_Security_Best_Practices.pdf?ver=9mpKKyUrwfpb9b9r4drVMg%3d%3d
Vulnerability Roundup
Last week, Microsoft released an out-of-band patch for a critical vulnerability for Windows servers running Windows Server Update Services (WSUS). The vulnerability is tracked as CVE-2025-59287, and successful exploitation allows an unauthenticated attacker to run malicious code with SYSTEM privileges. It should be noted that this vulnerability only affects Windows servers with the WSUS server role enabled, which is not enabled by default. The issue does affect Windows Server 2012 through Windows Server 2025. Security updates for each of the Windows versions can be found in the Microsoft Security Update page here. Proof-of-concept code is in the wild, and this vulnerability has been added to the Known Exploited Vulnerability Catalog by CISA. Administrators are urged to patch or mitigate the vulnerability as soon as possible.
https://support.microsoft.com/en-us/topic/october-23-2025-kb5070883-os-build-17763-7922-out-of-band-860bc03c-52fb-407c-89b2-14ecf4893c5c
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287
https://www.esentire.com/security-advisories/critical-windows-vulnerability-exploited-cve-2025-59287
QNAP recently disclosed a critical vulnerability affecting their NetBak PC agent. Per the QNAP security advisory, the issue is related to the recently disclosed vulnerability in Microsoft's ASP.NET Core library. The NetBak PC Agent depends on those ASP.NET Core components during setup. The vulnerability is tracked as CVE-2025-55315, and successful exploitation can allow the attacker to bypass security controls via HTTP Request Smuggling, leading to unauthorized access to sensitive data and the ability to modify files on the server. Steps for mitigating the vulnerability can be found on the QNAP advisory page here. Administrators are urged to patch as soon as possible.
Motex Lanscope Endpoint Manager is an endpoint management and security tool that works with desktop and mobile devices and is offered as an asset management option in AWS. Per the vendor Motex, the critical vulnerability is tracked as CVE-2025-61932 and allows an unauthenticated attacker to execute arbitrary code on the system. The vulnerability only affects the on-prem version of the tool, not the cloud version. The vulnerability affects versions 9.4.7.1 and earlier. Administrators are urged to patch as soon as possible, as CISA has added this vulnerability to the Known Exploited Vulnerabilities catalog.
https://www.bleepingcomputer.com/news/security/cisa-warns-of-lanscope-endpoint-manager-flaw-exploited-in-attacks/
The following vulnerabilities were added to CISA's Known Exploited Vulnerabilities Catalog in the last 2 weeks:
This report is provided FREE to the cybersecurity community.
Visit our Cyber Threat Intelligence Blog for additional reports.
Subscribe to be notified of future Reports:
NOTE
We have enhanced our report with data from SOCRadar. You may need to register to view their threat intelligence content.
DISCLAIMER
Kindly be advised that the information contained in this article is presented with no final evaluation and should be considered raw data. The sole purpose of this information is to provide situational awareness based on the currently available knowledge. We recommend exercising caution and conducting further research as necessary before making any decisions based on this information.