Introduction
On Monday 2026-08-31, I used a link from a malicious Brazilian Portuguese email to infect a Windows host in my lab. This was a Guildma (Astaroth) malware infection.
The link from the email is geofenced for Brazil, meaning that it would only deliver the malware if I checked it from a Brazil-based IP address. Otherwise, it would send a legitimate installer (in this case for Android Studio) and not the malware. Furthermore, my web browser and operating system needed to use Brazilian Portuguese language settings and Brazil regional settings.
The initial downloaded file was a zip archive that contained a Windows shortcut. The shortcut retrieved content from a web server and saved it as an alternate data stream to a file created under the user's AppData\Local\Temp directory. This alternate data stream contained a 64-bit DLL file that doesn't appear to be malicious, but it was used to retrieve and install an AutoIt package for Guildma malware.
Today's diary shares indicators from the activity. Of note, many of the specific indicators like some of the SHA-256 hashes appear to be unique for this particular infection.
Images From the Infection
Shown above: Screenshot of the email.
Shown above: Malicious file downloaded from link in the email.
Shown above: Traffic from the infection filtered in Wireshark.
Shown above: Malware persistent on the infected Windows host.
Indicators of the Activity
Select headers from the email:
Link from the message text:
Downloaded zip archive and extracted Windows shortcut:
SHA-256 hash: cc44782356cb0effc528a7ab22c19ab360a55ebbbe01feb0967031aa191c5869
SHA-256 hash: 47d2908c4dd7f6f5eb4a8ef4306077b10315c44231f4bacd2bb811b245561911
DLL saved as an alternate data stream during the infection, doesn't appear to be malicious:
SHA-256 hash: a6044786991afdb9d42ceb350943987765a7d0e8537369b2092e3f019c0f63ca
Compiled AutoIt script for the persistent Guildma malware:
SHA-256 hash: f62a958faf0491b2b2803be2ee69b664b58e4a1261f64e8530cdc1a3ff666aa4
Domains the infected Windows host communicated with over HTTPS (TCP port 443):
TCP traffic to another domain:
tcp[:]//omzagdmspc.a.pinggy[.]link:21601/
Note: I saw HTTPS traffic to WhatsApp and GitHub domains later during this infection, but those are legitimate domains, so I didn't include them in this write-up. A previous article has noted this campaign abusing GitHub, so I've included the mention here.
Bradley Duncan
brad [at] malware-traffic-analysis.net
One of my internet-exposed inference honeypots was discovered, relabeled with sought-after model names, and incorporated into infrastructure apparently used to provide "free" LLM backends. It then received a real coding-agent session — history, filesystem output, working paths, and the agent's local tool manifest. The honeypot did not request or cause any tool execution; what the request exposed is what a malicious operator in that position could do.
Chasing the "free API key" is not new. What is new is what you get to chase now: not a key, but an agent — a client that arrives carrying its own file-read, file-write, and shell tools, asking a server whose identity and operator it may never have verified to decide what to do next. Point that client at the wrong endpoint and its replies stop being just text: they can request tool calls that the agent, depending on its configuration, may carry out on the machine it runs on.
This is not a classic watering hole — nobody compromised a site or service the users already trusted. It is better understood as a rogue model endpoint: a server that agents are configured to trust as their reasoning backend. In a deliberate campaign an operator could go further and run it as an evil twin of a real provider — sought-after model names, advertised as free — and wait for tool-enabled agents to connect. This diary is one worked example, caught on a honeypot: an exposed endpoint that was scavenged, relabeled, and handed a real agent's session. The lesson underneath it: a model endpoint is not merely a source of text — for a tool-enabled agent, it is part of the control plane.
Start with the payload, because it reframes everything. On 2026-08-30 our honeypot received, 210 times in 91 seconds, a 224 KB request body: an 88-message transcript from opencode, an open-source terminal coding agent, originating from a Windows environment and delivered to us through a China Unicom address in Hebei that was apparently acting as a relay. A person had asked their agent (in Chinese) to study the writing style of two novels sitting in their Downloads folder. Across the earlier messages the agent had listed the directory, copied the files to %TEMP%, unpacked them, written a Python script to extract the text, and begun reading chapters — several PowerShell tool invocations among them. Then the user typed "jìxù" — continue. That request, with the whole history and tool manifest attached, is what landed on our server.
The request labeled the backend as DeepSeek — "model": "fofa-ds-NNNNN" — though the transcript cannot tell us who assigned that label or exactly what the user understood it to mean. Either way, it was reaching a honeypot that scanners had found the month before. Everything the transcript carried — the Windows username, directory listings, tool outputs, and portions of the files it had read — was now in our database, in cleartext, sent by a client presenting Authorization: Bearer free to an endpoint that did not validate it.
The client connecting to the honeypot was not an attacker. It was an ordinary user whose private agent session had been routed to an endpoint they did not control. The rest of this diary examines what a malicious operator could have done from that position.
Our honeypot answers on /v1/models, /v1/chat/completions, an Ollama-style /api/tags and an MCP server — all unauthenticated, advertising four unremarkable local models. It went live 2026-07-18. Here is how it became a DeepSeek:
Login/v1/models reply back into requests — sometimes the entire list pasted as one string, [nomic-embed-text:latest mistral-small:24b …]. Automated inventory, nobody home.opencode/0.2.0 arrives and cycles through model names we never advertised: auto/best-coding, auto/claude-opus, auto/claude-sonnet, auto/best-reasoning. The behavior is consistent with probing which aliases the backend will accept. We answer all of them — HTTP 200, under 100 ms.NodeHealthCheck/1.0 (+local-lab) requests fofa-opus-NNNNN. This suggests the endpoint had been enrolled in a monitored backend pool.opencode/0.2.0 requests fofa-sol-NNNNN, fofa-ds-NNNNN and fofa-opus-NNNNN within three seconds — three aliases for one backend, in a pattern consistent with backend validation. Later the same morning it also tries agentrouter-org/claude-opus-4-8 and bailian/deepseek-v4-flash-0731: names suggestive of other routing or provider-list conventions, pointed at the same IP.Go-http-client/2.0 from a China Unicom (Hebei) address — apparently a relay — sends the opencode transcript 210 times in 91 seconds.The naming scheme strongly suggests the whole arrangement. fofa is FOFA, China's internet-wide search engine — a plausible place the endpoint was found. ds / opus / sol read as aliases for DeepSeek, Claude Opus, and a GPT variant (the gpt-5.6-sol probes three days earlier point to "sol"). And the numeric suffix — the same across all three aliases, masked here as NNNNN — is not a channel id: it matches the endpoint's own public IP octets. The convention is <where I found it>-<what I'll call it>-<octets of its address>: that is how you label entries in a hand-kept list of scavenged endpoints, and it is why we have masked it here.
The scheme appears to have propagated across multiple clients or infrastructure nodes: the same three aliases were exercised from a Vultr host, a Cloudflare egress, and the China Unicom relay, plus a separate health-checker — four vantage points, one naming scheme, one target. And the credential on 247 of the 248 requests was the same: Authorization: Bearer free — the "key" is the word "free". The evidence supports a plausible distribution chain: a scanner indexes exposed endpoints; someone assigns friendly aliases and folds them into a pool of "free models"; that configuration propagates into agent clients or relays. The Go-http-client/2.0 user-agent is consistent with a Go-based intermediary but does not identify a particular product. We did not recover the list or its maintainer — we observed steps consistent with such a chain.
Whoever operates or compromises the endpoint that entry points to receives this, verbatim, with every request:
"model": "fofa-ds-NNNNN",
"messages": [
{"role": "system", "content": "You are opencode, an interactive CLI tool …"},
{"role": "user", "content": "n? fùzé b?ng w? xi? xi?oshu?"},
…
{"role": "assistant", "tool_calls": [{"function": {"name": "bash",
"arguments": "{\"command\":\"Get-ChildItem -LiteralPath \\\"C:\\\\Users\\\\<redacted>\\\\Downloads\\\" …\"}"}}]},
{"role": "tool", "content": "?¼: C:\\Users\\<redacted>\\Downloads …"},
…
{"role": "user", "content": "jìxù"}
],
"tools": [
{"type":"function","function":{"name":"bash","description":"Executes a given Windows PowerShell (5.1) command …"}},
{"type":"function","function":{"name":"write","description":"Writes a file to the local filesystem …"}},
{"type":"function","function":{"name":"edit", "description":"Performs exact string replacements in files …"}},
{"type":"function","function":{"name":"read", … }}, … 11 tools total
],
"tool_choice": "auto"
This is more than prompt leakage. The transcript already contains filesystem-derived data, and the tool manifest exposes potential paths back into the local filesystem and shell, with the user's own OS and paths filled in. The read tool creates a potential arbitrary-file-disclosure path within the paths and permissions available to the agent: a malicious endpoint could reply with a tool_calls asking to read .aws/credentials or an SSH key, and if the agent is permitted to read that path, the contents would return in the next model request. No exploit, no CVE — the client volunteers the capability.
Because the request advertises bash and tool_choice: auto, the operator's reply can become a command-request channel. The following is the relevant core of an OpenAI-compatible tool-call response; unrelated envelope fields (id, object, created, model, index) are omitted:
{"choices": [{"message": {"role": "assistant", "tool_calls": [
{"id":"call_1","type":"function","function":{
"name":"bash",
"arguments":"{\"command\":\"<whatever the operator wants to run>\"}"}}]},
"finish_reason": "tool_calls"}]}
Whether that command runs without the user seeing a prompt depends on the agent's permission model, and here the news is bad. Opencode's current default build agent permits most operations — including bash, read, and edit/write — without approval. The transcript we captured is a build-agent session that had already carried out multiple PowerShell invocations. In that default configuration a malicious reply may execute without an additional user-approval prompt. A user can tighten these permissions, and --auto can further weaken approval boundaries. The important point is that the endpoint cannot know which protections are enabled — and a permissively configured client may carry out the request without intervention. (These defaults are from the current opencode permissions documentation; the exact behavior of the observed opencode/0.2.0 build may differ by version.)
We did not send a tool call. Our honeypot answered all 210 requests with a fixed prose string and finish_reason: stop — which likely explains the 210 retries: a relay expecting a stream, rejecting an answer it could not parse. But "we returned prose" is a choice we made, not a protection the user had. Anyone holding that endpoint could have returned the JSON above instead. Whether it then ran is not something we can assert in the abstract: the transcript proves the commands executed, but it cannot by itself prove no human approved them — any approval prompt lives in the local UI, not in the request sent to the model. What it does show is a build agent carrying out PowerShell invocations, consistent with bash at "allow"; for a session configured that way, a malicious reply can run without a further prompt.
Hypothesis, stated as one: if agents with permissive tool defaults keep arriving at scavenged "free" endpoints, then standing one up is a cheap, targeted way to attract them — a rogue endpoint that needs no phishing and no vulnerability, because the victims come to it, lured by "free". We have the arriving agents and the open door. We do not have proof of an operator weaponizing the reply; we would not run that experiment. The gap between "can" and "did" is the honest boundary of this finding, and it is exactly the gap defenders should close before someone else measures it.
The economics point one way. For the attacker the cost can be modest: an OpenAI-compatible service and enough inference capacity to appear legitimate to selected clients; discovery is done for free by FOFA and Shodan; delivery is done for free by whoever curates and shares the "free models" list. The users come to them, presenting Bearer free and their tool manifest. For the user the incentive is equally clear: frontier models cost money, "free DeepSeek" does not, and an agent config is one baseURL line. The two incentives meet on an exposed endpoint. Our honeypot advertised nothing desirable and still went from first scan to serving a real agent's session in six weeks, and from apparent pool enrollment to live agent traffic in four days. And a deliberately malicious endpoint could return plausible completions for days or weeks and reserve the tool call for a chosen session — until activation, its traffic would look like ordinary inference. Our honeypot did not achieve that (it returned a fixed response that apparently did not satisfy the relay and triggered retries), but such selective activation is well within an operator's reach.
Treat a model baseURL the way you treat curl | sudo bash: it identifies a remote party that may be allowed to request operations from your local shell. Only point agents at inference infrastructure you operate yourself, or at providers whose identity, ownership, and security practices you have verified — paying for a service does not, by itself, make its operator trustworthy.
Review tool permissions before connecting the agent. A permissive configuration for bash, write, and read can turn one malicious model response into a silent local action. Require approval for sensitive tools, restrict filesystem access, and never use --auto with an untrusted endpoint.
Treat the model endpoint as part of the agent's software supply chain. Maintain an allowlist of sanctioned inference providers and alert when an agent connects elsewhere. Useful signals include:
model field, including fofa-*, shodan-*, auto/*, agentrouter-*, or providers your organization does not use.free.tools[], tool_choice, role: "tool" messages, filesystem paths, or command output.When this occurs, identify the affected agent configuration, stop further communication with the endpoint, determine what conversation and tool output were transmitted, and rotate any credentials or secrets that may have entered the session. The model operator has already received the preceding context; changing the endpoint prevents further exposure but does not recover what was sent.
Do not expose an endpoint publicly unless that exposure is intentional, authenticated, monitored, and appropriately rate-limited. An unauthenticated endpoint can be indexed, relabeled, and enrolled as someone else's "free" backend. Signals that this has happened include:
Authorization: Bearer free, or another credential you never issued.tools[], tool_choice, and role: "tool" messages when the endpoint was not intended to serve coding agents.These signals should trigger exposure remediation and careful handling of third-party data — not automatic attribution of the source addresses as attackers. Authenticate or remove the endpoint, investigate how it was indexed or distributed, restrict access to received content, and minimize its retention.
Agent transcripts can also trip naive exploit rules, because they contain strings such as powershell, URLs, and previous shell commands. A tools[] manifest, tool-role messages, and commands in assistant turns support the interpretation that the request carries a relayed agent transcript rather than a direct exploit attempt, but do not prove benign intent. The following were weaker contextual artifacts in this incident and should not be used as standalone indicators: opencode/0.2.0, Go-http-client/2.0, NodeHealthCheck/1.0 (+local-lab), stream_options.include_usage: true, and the auto/* model family.
We are deliberately not publishing the connecting IP addresses. They may belong to users, relays, proxies, scanners, or shared infrastructure, and should not be treated as attacker infrastructure without additional evidence. The portable signal is the behavior: an agent sending its context and tool capabilities to an endpoint it should not trust.
The downstream behavior maps reasonably well to AI Agent Tool Invocation (AML.T0053): a malicious model response could cause the agent to invoke its locally available tools. The initial trust relationship is less clearly represented. In that pattern the model-serving endpoint would itself be the adversarial component: operated by an attacker from the outset, or taken over after legitimate deployment. Our honeypot was neither — it demonstrates the discovery, relabeling, adoption, and data-exposure path such an operator could exploit. AI Supply Chain Compromise (AML.T0010) is the closest existing technique, but its current sub-techniques do not explicitly cover a remote inference service adopted as an agent's model backend. The data-return path is also distinct from Exfiltration via AI Agent Tool Invocation (AML.T0086), which describes exfiltration through write-capable tools; here a file read would return to the rogue endpoint through the agent's normal inference loop.
We are submitting this pattern to the MITRE ATLAS team for consideration — tentatively a Model Serving Endpoint sub-technique, with AML.T0010 as the closest current parent — supported by this real-world honeypot observation. This mapping is a secondary, analytical note: the finding stands on its own regardless of where ATLAS ultimately places it. The honeypot observation demonstrates exposure of real agent context and tool capabilities; it does not demonstrate malicious tool execution, which remains the risk scenario evaluated here, not an observed event.
YARA-X's 1.20.0 release brings 14 improvements and 13 bugfixes.
One new CLI option is --ignore-invalid-rules that allows one to skip rules that fail to compile.
There have also been new releases of YARA:
YARA 4.5.6, YARA 4.5.7 and YARA 4.5.8 with 32 bugfixes in total.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.During my last FOR610 session, a student asked me if I had some statistics in mind about the compilers used to generate malicious PE files? A couple of months ago, I shared some stats about the trend in 64bits VS. 32bits malware[1]. Can we go a bit further? I (vibe-)coded a Python script based on the pefile library[2] to extract some info from the PE headers. Indeed, the PE file format contains a lot of metadata! They can be accessed using a lot of tools, like Detect It Easy:
Note: When you assess a PE file, a gold rule to follow is to never trust what you see because these metadata can be tempered!
I tried to detect the compiler using three techniques:
As said above, there is no official Microsoft documentation for the Rich Header, and no single authoritative mapping of every product-id -> tool/version exists. But they are community references that helps! The well-known "comp_id.txt" is one of them and constantly updated[3].
Now that we have a tool, where can we find fresh meat? Malware Bazaar is a good candidate because it is pretty popular and get new samples daily. They allow (but don't abuse) to download their data set for free! The first step was to download all the archive they offer[4]. I downloaded a total of 1.3 TB of ZIP archives, one archive per day from 2020-02-24 to 2026-07-08.
Because PE files can be embedded into other files and to avoid using to much storage, I rewrote the script:
Here are the stats I gathered after “a few days” of processing!
High level stats
| Total scanned files | 23.501.548 |
| Not PE | 22.580.068 |
| Valid PE | 690.689 |
| Encrypted or unreadable | 227.755 |
| Invalid PE | 1.508 |
| ZIP Bomb | 951 |
| Invalid ZIP | 519 |
| Error | 36 |
| Skipped Nested ZIP (> 3 levels) | 19 |
| File Too Large | 3 |
About the architecture:
| 32 Bits (or other architecture) | 565.179 |
| 64 Bits | 125.510 |
Interesting, this confirms my previous research: 32 bits PE file remain popular.
Rich Header:
| Rich Header Present | 371.103 |
| No Rich Header (Maybe stripping, a non-MSVC toolchain, tempeing,...) | 319.586 |
Top-10 linker versions:
| linker 48.0 | 102.307 |
| linker 6.0 | 91.788 |
| linker 9.0 | 62.070 |
| linker 8.0 | 47.829 |
| linker 2.25 | 36.673 |
| linker 10.0 | 36.549 |
| linker 14.0 | 29.786 |
| linker 11.0 | 25.784 |
| linker 14.29 | 24.655 |
| linker 80.0 | 22.691 |
Top MSVC Rich Header compiler builds (useful for clustering samples built in the same environment/campaign):
| build 26213 | 19.603 |
| build 24213 | 15.389 |
| build 30034 | 14.325 |
| build 26706 | 7.755 |
| build 24215 | 5.253 |
| build 32533 | 5.033 |
| build 33030 | 4.442 |
| build 31823 | 3.738 |
| build 25834 | 3.530 |
| build 27412 | 3.294 |
Finally, and the most interesting status, what tools are used by attackers?
|
Unidentified (no Rich Header, no signature match) |
272.439 |
39.4% |
| Microsoft toolchain (Rich Header present, no recognized C/C++ entry) | 216173 | 31.3% |
| Borland C++/Delphi | 20172 | 2.9% |
| Microsoft Visual C/C++ (Rich Header, compiler build 26213) | 19603 | 2.8% |
| GCC / MinGW | 13804 | 2.0% |
| Go | 6254 | 0.9% |
| Embarcadero/Borland Delphi | 6174 | 0.9% |
| Rust | 1329 | 0.2% |
| Clang/LLVM | 91 | 0.0% |
| Free Pascal (FPC) | 1 | 0.0% |
Interesting to see that arising programming languages like Go or Rust remain exotic in the data set! I expected more popularity!
[1] https://isc.sans.edu/diary/2026+64Bits+Malware+Trend/32718
[2] https://github.com/erocarrera/pefile
[3] https://github.com/dishather/richprint/blob/master/comp_id.txt
[4] https://bazaar.abuse.ch/export/
Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key
As I’ve mentioned before in some of my diaries, from time to time, I like to go over phishing messages that get caught in my various spam traps or sent to us here at the Internet Storm Center.
After looking at enough phishing messages, one quickly gets used to seeing the same lures, the same credential-harvesting pages and, quite often, the same obfuscation techniques over and over again. But even something that seems to be “run-of-the-mill” at first glance can sometimes turn out to be quite interesting.
One such message was recently sent to our handler inbox, and as you can see, there was very little about it that would indicate that it would be worth a deeper look.
The link in the message pointed to a URL with the following, quite usual, structure:
hxxps[:]//addresses[.]performs[.]vu/communications.html?good=[recipient_address]
Nevertheless, what happened after the link was opened was somewhat less usual.
Instead of displaying a phishing page, the browser remained effectively stuck for about 30 seconds, while utilization of one CPU core in the virtual machine I was using quickly rose to 100 %. Since retrieving the HTML source itself was almost instantaneous, it seemed clear that the delay wasn't caused by the server, and instead something in the page itself was preventing the browser from finishing its work.
Although a quick look at the source code showed that almost all of the page consisted of heavily obfuscated JavaScript, the reason for the unusual behavior fortunately wasn't too difficult to identify.
Among other things, the script contained two functions, which are slightly reformatted here for easier readability:
function _il(m) {
for(k=0; 64>k; k++) {
m[_lV(_ie(),k)]=k
}
return m
}
function _YF(m,h) {
var v="";
for(k=m; k<=h; k++) {
v=v+String.fromCharCode(k)
}
return v
}
As you can see, both functions use k as a counter in their for loops. The first function is part of a decoding routine, and its loop counter is expected to go from 0 to 63. The second function is a helper used by the same routine to construct strings from ranges of character codes – it is used (among other places) in the _ie() function, which is called by the first function. The problem is that k isn't declared locally in either one of these functions.
This becomes important because _ie(), which is called during every iteration of the first loop, uses _YF() several times to construct the Base64 alphabet. Its final call is _YF(47,47), which produces the ‘/’ character (ASCII code 47).
Since the counter k used by _YF() is global, this final call also changes the value of k used by the outer loop. _YF(47,47) first sets k to 47, executes its loop once and then increments k to 48. At that point, the condition k <= 47 is no longer true, so _YF() returns with the global value of k left at 48.
Control then returns to the outer for loop, whose own increment changes k from 48 to 49. Since 49 is still smaller than 64, another iteration starts and _ie() is called again. Its final _YF(47,47) call once more leaves k at 48. The outer loop therefore never progresses beyond 49.
The resulting sequence therefore looks roughly like this:
48 -> 49
48 -> 49
48 -> 49
...
This explained both why the page never rendered and why the browser was keeping one CPU core rather busy.
Changing the inner routine to use its own local counter was sufficient to let the decoding process finish. After removing the remaining layers of obfuscation, what emerged was an otherwise completely unremarkable credential-stealing page.
At this point, the most likely explanation seemed fairly straightforward – the authors of the page had simply shot themselves in the foot by using a broken obfuscation mechanism.
Nevertheless, this proved not to be the case, since when I accessed the original URL again a little later, the page loaded normally. Another attempt to load the page was also successful, as were several subsequent ones.
More interestingly, while all of the resulting pages ultimately displayed the same credential-stealing form, their source code wasn't the same.
Function and variable names differed across page loads, functions appeared in a different order, numerical constants were expressed using different arithmetic operations and a large encoded block of code, which contained the actual payload with the form, changed as well. Even the innocuous-looking page title varied between requests using words like "Solution", "Viewer", "Credentials", "Private" and "Authenticate".
It therefore appeared that the first response wasn't a permanently broken copy of the phishing page at all. Rather, the server seemed to generate polymorphic variants of the page and I had simply happened to receive a “broken” one when I first accessed the target URL.
To test this hypothesis, I used a simple script to retrieve the same URL 50 times and, with some help from an LLM, compared the resulting samples.
Among the 50 samples (which all had different SHA-256 hashes), there were 21 different page titles, and, more importantly, 49 deobfuscated successfully while one became stuck in an endless loop – just like the first page I had the luck to land on.
The reason was effectively identical to what happened in the first page I encountered. In this variant, the two relevant functions had different randomized names, but both of their loops had once again been assigned the same undeclared variable k. The inner loop therefore repeatedly reset the value used by the outer one and prevented the decoder from completing.
Once this collision was corrected, the sample decoded normally as well.
The polymorphism wasn't limited to the initial JavaScript wrapper. The 50 page variants (if we include the one I had to manually “fix”) produced 50 different versions of the final phishing HTML. Form and input names, CSS classes, element identifiers and parameters used when loading images were changed, as was the placement of zero-width characters inside visible strings, which were used as a further obfuscation/anti-analysis mechanism. In spite of all these changes, however, the page presented to the user and its basic functionality remained essentially identical.
Polymorphic phishing pages are, of course, not new. The concept has been discussed for well over a decade in academic circles[1], and phishing pages which generate random HTML attribute values for individual visits have been used in the wild for years[2]. It has also previously been shown that JavaScript lends itself quite well to producing multiple versions of source code which look different while performing the same task[3] (which is the basis for the simplest implementation of polymorphism at the code level).
The rationale behind such an approach is fairly obvious – hashes, randomly generated identifiers and many simple string-based signatures become significantly less useful if every request produces what is basically a completely new copy of a malicious page.
Although polymorphism certainly shouldn't be thought of as some universal mechanism for bypassing security controls, as the underlying logic and behavior of the pages remains the same, and many structural characteristics inevitably survive most transformations, it does raise the cost of detection mechanisms which rely too heavily on static artifacts...
Though, in this case, it apparently also raised the cost for the threat actor, since at least some victims would end up with a non-functioning page (at least on a first load), given that of the approximately 56 samples I collected (50 using the script + my original manual attempts), two pages were broken.
Although it would be unreasonable to draw any firm conclusions about the actual failure rate of the mechanisms used, it is clear that the original endless loop wasn't just a “one-off” corrupted response and that whatever generates the code can repeatedly create non-functional pages.
Which brings us to one final question – what was actually generating the code?
Given the current popularity of generative AI, it is tempting to consider an LLM-based backend. This isn't entirely far-fetched either – in January, Unit 42 demonstrated a proof-of-concept in which an LLM was used to generate syntactically different phishing JavaScript in real time, resulting in a unique variant for individual visits[4]. There is, however, nothing in the samples which would prove that an LLM is involved here, and a conventional polymorphic obfuscator seems to be a much more plausible explanation, given that the transformations between individual page copies are quite systematic, and the recurring failure caused by reused global variable names would fit quite nicely with a relatively simple random renaming and reordering mechanism which doesn't properly account for variable scope.
In any case, had the first page loaded normally, I would almost certainly have dismissed it as yet another run-of-the-mill phishing site. As it turned out, though, the obfuscation mechanism intended to make the page more difficult to detect was also capable of making it somewhat ineffective at stealing credentials... which made the sample considerably more interesting than it initially appeared.
And – to end on a positive note – the sample did also provide a good lesson to any aspiring programmers out there – never use undeclared global variables as your loop counters.
[1] https://link.springer.com/chapter/10.1007/978-3-642-02617-1_28
[2] https://www.zscaler.com/blogs/security-research/evolution-phishing-kits
[3] https://www.akamai.com/blog/security/the-tale-of-double-javascript-obfuscated-scam
[4] https://unit42.paloaltonetworks.com/real-time-malicious-javascript-through-llms/
-----------
Jan Kopriva
LinkedIn
Nettles Consulting
A common thing that folks should "worry" about in Entra (or any platform really) is "who has rights to administer"? Who can delete or change key things, or modify them in ways that might not be obvious (accidentally or on purpose). Yes, we trust our people, but if they've moved on to other roles or to other organizations, they change from "our people" to "used to be our people".
Also, it's common to have too many admins. For instance, entry level support folks might need rights to change passwords, but they likely shouldn't have rights to change your intune policies or be global admins. The "too many admins" question is a common one that auditors will zero in on. This is #4 on the CIS Critical Controls v7 as "Control of Admin Privileges". In version 8 of the list it's now at #6 under "Access Control Management"
Let's dig into your Entra ID Directory, you might find some surprises in your admin list.
# first, as always connect to the directory
Connect-MgGraph -Scopes "Directory.Read.All", "RoleManagement.Read.All"
# Get the list of activated directory roles and the count of members
$roles = Get-MgDirectoryRole
foreach ($role in $roles) {
$members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
[PSCustomObject]@{
RoleName = $role.DisplayName
MemberCount = $members.Count
}
}
RoleName MemberCount
-------- -----------
Privileged Authentication Administrator 0
Global Administrator 5
Password Administrator 1
Application Administrator 0
Service Support Administrator 0
Purview Workload Content Writer 1
User Administrator 0
SharePoint Administrator 0
Intune Administrator 3
Purview Workload Content Administrator 1
Azure AD Joined Device Local Adminis... 1
Helpdesk Administrator 0
Office Apps Administrator 2
Directory Readers 0
Billing Administrator 0
Cloud Application Administrator 0
Directory Synchronization Accounts 1
Directory Writers 0
Exchange Administrator 0
Authentication Administrator 2
Groups Administrator 0
Privileged Role Administrator 0
License Administrator 0
Conditional Access Administrator 3
Global Reader 1
Device Managers 0
So this output is OK for a stranger that is looking for a "how many is too many" sort of output. But if you are administering this directory, what you really want is the actual list - you want to know who the people in the list are, and compare that to your understanding of the roles that folks have in your organization. You are not looking for the answer to "does it look about right?", you are looking for the details "is it actually right?". A (really) common finding is to have "that auditor from 3 years ago" still in the list with a "Global Reader" or even "Global Administrator" role. You may also have management or even PMs that aren't as technical as they once were with admin rights, and the power of a collosal accidental delete (though that can be a regular AD issue as well). In this case, that "Global Reader" line above is a shiny, flashing beacon saying "LOOK HERE". Let's list the individual user accounts and what roles they have in Entra:
# init the list to zero
$adminslist = @()
# get the roles
$roles = Get-MgDirectoryRole
# Cycle through each role and get admin list
$adminslist = foreach ($role in $roles) {
$members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
foreach($m in $members) {
$adminuser = get-mguser -userid $m.id
$adminusername = $adminuser.displayname
$adminuseraccount = $adminuser.userprincipalname
[PSCustomObject]@{
RoleName = $role.DisplayName
UserAccount = $adminuseraccount
UserName = $adminusername
}
}
}
$adminslist | out-gridview
Like changing passwords or keys (or planting a tree), the best time to do this is in the past, but TODAY is the second-best time to look at who has admin rights to key things like your Entra or AD directories. Check your list for Entra, let us know in the comments if you found anything unexpected? ( Anonymized of course)
===============
Rob VandenBrink
rob@coherentsecurity.com
It is pretty obvious that hostnames can replace IP addresses. Pretty much any software accepting an IP address will also accept a hostname as an argument. Last week, I wrote about scans for the cloud metadata service listening at 169.254.169.254. These scans attempted to exploit Server Side Request Forgery (SSRF) vulnerability. One way to prevent these types of exploits is to filter requests that contain the string "169.254.169.254" or to add this IP to a blocklist of URLs that should not be accessed.
But as is almost always the case, blocklists are not the solution you are looking for.
In response to last week's diary, Sean wrote that they saw attackers use hostnames instead of IP addresses. In particular:
The last one, as Sean pointed out, is likely linked to the 1u.ms tool. This tool allows attackers to define hostnames "on the fly". It offers numerous options. For example, you can configure the IP address to change after a certain number of lookups or after a certain time. IP addresses can use various encoding/obfuscating formats. The tool can also be configured with a custom domain, but 1u.ms is ready to go.
1u.ms maintains public logs for all requests sent to it, so you can check if it was used against one of your systems. The last 100 requests can be found at http://1u.ms/last and the
Similar hostnames can likely be configured with many dynamic hosting services. If you do retain DNS logs (you should!!), Check whether any resolution resulted in IPs such as 169.254.169.254.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
New malware that uses steganography always gets my attention, but I was disappointed when I looked at the latest DOUBLECUP write-up. It doesn't use real steganography:
You can see the PowerShell payload as cleartext: it has not been encoded into the pixels of the image.
It's even not embedded in the image (like inside the metadata), it's just appended after the PNG file:
Yet there is a clever little trick:
The PowerShell script starts with 0x0D 0x0A, Carriage-Return + Newline: that terminates a line of text in Windows.
That makes that you don't need a custom payload extractor, you can just use the FINDSTR command (Windows' grep) with a unique identifier to extract the script:
And then pipe it into the PowerShell interpreter.
Didier Stevens
Senior handler
blog.DidierStevens.com
In every MFA rollout, there will come a time where you think you are closing in on "done", and some automation to list what's left would be handy. Something quicker than scrolling through the web interface through thousands of accounts ...
This is that method.
Also, remember when we discussed yesterday about the beta graph commands in the Microsoft.Graph.Beta library? We'll use one of those beta commands here!
# import, if it's not already there
Import-Module -Name Microsoft.Graph.Beta.Reports
# with the necessary auditing scope
Connect-MgGraph -Scopes "AuditLog.Read.All", "User.Read.All"
$AllMFADetails = Get-MgBetaReportAuthenticationMethodUserRegistrationDetail -All
# We're only interested in users who are NOT yet registered for MFA
$NonMFAUsers = $AllMFAdetails | Where-Object { $_.IsMfaRegistered -eq $false }
$t = foreach ($User in $NonMFAUsers) {
# user by user, collect account details (primary if it's enabled)
# then construct the userobj record
# note the join adds the object to the list
$UserObj = Get-MgUser -UserId $User.Id -Select Id, AccountEnabled
[PSCustomObject]@{
"UserPrincipalName" = $User.UserPrincipalName
"DisplayName" = $User.UserDisplayName
"AccountEnabled" = $UserObj.AccountEnabled
"MethodsRegistered" = ($User.UserPreferredMethodForSignIn -join ", ")
}
}
$t | Out-GridView -Title "NON-MFA Users"
Note that the last two columns are for MFA methods, so they'll be blank, but we'll use those in a sec.
I'm not displaying the output in this case, as it's essentially a list of actual user accounts.
You can also modify this a bit, for instance if you were tightening up your MFA setup, because your auditor told you to root out folks using SMS for MFA for instance, this is definitely the command set to use. You'd want $_.IsMfaRegistered -eq $true, but then look for "SMS" in the Methods registered or Default MFA columns. Surprisingly in this last check I saw a number of folks with "voiceMobile" (ie a voice callback) as their primary MFA.
Give this a try, let us know in the comments if you find some unexpected folks who skated by the MFA login policy requirements ....
===============
Rob VandenBrink
rob@coherentsecurity.com
One thing that folks never seem to do after "going to the CLOOOOUUUUD" is to look at their logs, logs that they would have checked daily when things were on premise.
One log that really bears looking at is the log of successful and failed logins. the call for that is:
# import needed, if they're not already in place
Import-Module Microsoft.Graph.Reports
# connect with the correct scope
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"
$f = Get-MgAuditLogSignIn
Let's look at one object in the log:
This is an interactive login to OWA, which failed on a conditional access check
What is that under location though - that's likely why this failed. How do we get the "where" from that? And why does the status got a similar string in it instead of an actual status?
The command below shows us pulling only failed logins ("status/errorCode ne 0"), extracting the geo location info, and also the failure reason
Get-MgAuditLogSignIn -Filter "status/errorCode ne 0" -All | Select-Object `
CreatedDateTime,
UserPrincipalName,
IPAddress,
@{Name="City"; Expression={$_.Location.City}},
@{Name="State"; Expression={$_.Location.State}},
@{Name="Country"; Expression={$_.Location.CountryOrRegion}},
@{Name="FailureReason"; Expression={$_.Status.FailureReason}}
Aha! Now we have that otherwise hidden information! It's this sort of list where you'll see password sprays show up. The list below shows part of such an attack, note that the last two lines show the account is locked. The "IP address with malicious activity" alert generally means that this is a rotating proxy service, and the IP's in it have been fully or partially enumerated as "bad".
Or, looking for successful logins from unexpected countries, the command below. Let's also remove the State / City info, normally it's just the country that matters, at least on the first pass through the data.
# set the array of "expected" Countries
$ExpectedCountries = @("CA", "US" )
#Get all successful logins
$f = Get-MgAuditLogSignIn -Filter "status/errorCode eq 0" -All | Select-Object `
CreatedDateTime,
UserPrincipalName,
UserDisplayName,
AppDisplayName,
ResourceDisplayName,
IsInteractive,
IPAddress,
@{Name="Country"; Expression={$_.Location.CountryOrRegion}},
@{Name="FailureReason"; Expression={$_.Status.FailureReason}}
# remove expected countries, and what is left is unexpected
# Just as Sherlock Holmes (or Occam) would say
$f | Where { $_.Country -notin $ExpectedCountries } | out-gridview
It's interesting to see a few IPv6 addresses in the list.
In writing this diary, I found multiple password spray attacks. This helped the client tighten up their conditional access policies, which was one of our goals going in.
Take a run at your Entra logs using the methods above. Let us know in the comments if you found any unexpected (or expected) events or attacks, or if you were able to use your logs to effect a change in your configuration (in conditional access polices for instance)
===============
Rob VandenBrink
rob@coherentsecurity.com
Building on the last diary on Using MS Graph and Powershell, let's look at "Risky" logins.
Risky logins are a derived set of parameters that look at various (you guessed it) risky login parameters. What is considered a risk?
In most cases this is either impossible geography - in other words "we're not expecting to see you at that IP, in that subnet, ASN or country", or unusual device - ie "that's not your regular computer"
There are two groups of commands in this area. You can do Risk Detection in a basic Entra license, but to work with Persistent Risk User accounts you need to bump up your license. So it'll cost you every month to use these commands:
Get-MgRiskyUser
Confirm-MgRiskyUserCompromised
Get-MgRiskyUserHistory
However, you can get a fair way with a basic Entra license and the Get-MgRiskDetection command. Let's focus on just that, since we all have at least that license level (if you're still reading that is).
#first connect to graph with the right Identity Protection scopes
Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All", "IdentityRiskEvent.Read.All"
$riskylogins = Get-MgRiskDetection -all
Note that if you've already done remediation and marked off events as dealt with, you can filter those events out with:
$riskylogins = Get-MgRiskDetection -All -Filter "riskState ne 'dismissed' and riskState ne 'remediated'"
Let's look at some data:
$riskylogins | select userdisplayname, activitydatetime, ipaddress, additionalinfo
hmm, that last field is the key one, it's in JSON format, with more info than we likely want for a summary. Let's look at one record, and convert from JSON:
$riskylogins[2].additionalinfo | convertfrom-json
Key Value
--- -----
riskReasons {UnfamiliarDevice, UnfamiliarEASId, UnfamiliarTenantIPsubnet}
userAgent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0 AnyConnect/5.1.9.113 (win)
alertUrl
mitreTechniques T1078.004
So most likely we'll want that list of risk reasons in our summary report - let's extract that for our test object:
($riskylogins[2].additionalinfo | convertfrom-json)[0].value
UnfamiliarDevice
UnfamiliarEASId
UnfamiliarTenantIPsubnet
OK, now let's pull the list with just that information, using our new best friend - yup, a computed field and a join!
$riskylogins | select userdisplayname, activitydatetime, ipaddress, @{N='Reason';E={ (($_.additionalinfo | convertfrom-json)[0].value ) -join '; '}} | out-gridview
In this case, looking deeper at the IP's, these are login attempts from Malaysia, Colombia and South Korea. Digging deeper into the text, we found a client IP from Warsaw. With another loop you could use something like the ipinfo API to relate those IP's back to geo-locations easily enough - it's always another loop in PowerShell it seems.
That second item and the last one lists the useragent though instead of the risk reasons, let's extract that key-value pair specifically rather than count on it being the first in the list
($riskylogins[4].additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" }
Key Value
--- -----
riskReasons {UnfamiliarDevice, UnfamiliarEASId, UnfamiliarTenantIPsubnet}
Close, but we just want the value:
(($riskylogins[4].additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" }).value
UnfamiliarDevice
UnfamiliarEASId
UnfamiliarTenantIPsubnet
So plugging that back into our single one-liner:
$riskylogins | select userdisplayname, activitydatetime, ipaddress, @{N='Reason';E={ ((($_.additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" })).value -join '; '}} | out-gridview
So the risks in the list above boil down to: you are in an unusual location (IP address, subnet, ASN, Location, or you are using an unfamiliar device.
Hmm - looking at those IP addresses, you're thinking - can I look those up using the APIs for ipinfo or maxmind? No need, it's already there, if you run "$riskylogins | gm", you'll see a "location" object.
$RiskyLogins[4].location
City CountryOrRegion State
---- --------------- -----
Gunseo-Myeon KR Chungcheongbuk-Do
But normally it's just the country that you want, so what we want is
($RiskyLogins[4].location).countryorregion
KR
Which means we need another computed field to make things work in the "report" command:
$riskylogins | select userdisplayname, activitydatetime, ipaddress, @{N='Country';e={($_.location.countryorregion)}}, @{N='Reason';E={ ((($_.additionalinfo | convertfrom-json) | where { $_.Key -eq "riskReasons" })).value -join '; '}} | out-gridview
To just view this in a text table, you could use " | ft " instead of out-gridview, or send it to an excel-readable file wiht "| out-csv"
Please, use our comment form and let us know if you've used these concepts in Graph to find a security event that you wouldn't otherwise have found!
===============
Rob VandenBrink
rob@coherentsecurity.com
Microsoft Graph is a newer API that is meant to replace several others. OK, it's at version 2.3.9, so it's not all that new, but it's new enough that lots of folks (and commercial tools) aren't using it yet. It allows you to Get and Set info from/to M365, Entra Users and Entra managed machines for starters. Let's dig in!
First, some preparation if you don't already have these modules installed:
Install-Module Microsoft.Graph -Repository PSGallery
# the beta likely isn't needed for most installs, but install it if desired
Install-Module Microsoft.Graph.Beta -Repository PSGallery
Next, an import (again, if needed)
Import-Module Microsoft.Graph
Finally, you'll need to connect to your Entra account / directory
Connect-MgGraph -Scopes "User.Read.All
Let's start exploring just by dumping a user table:
$AllUsers = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, AccountEnabled, SignInActivity | Where-Object { $_.AccountEnabled -eq $true }
Note the "-All" - this API has a default "first 100 objects" limit, if you are managing an actual domain you likely will always need a "-All" unless you are testing a script and want it to run faster.
If you want last password change included? You'll need to ask for that in the initial get-mguser call, it's not in the default returned list of results:
Get-MgUser -All -Property DisplayName, UserPrincipalName, LastPasswordChangeDateTime | Select-Object DisplayName, UserPrincipalName, LastPasswordChangeDateTime
Cool, now you have a list of accounts and their last password change, that's worth a sort in Excel (or | Out-GridView) and a few emails. Heck, since your in excel you could automate that right down to the email if you wanted.
What else? Looking at $allusers | gm, we see a property called "assignedLicenses" - let's look at that:
Get-MgUser -UserId $u -Property AssignedLicenses | Select-Object -ExpandProperty AssignedLicenses
DisabledPlans SkuId
------------- -----
{} 05e9a617-0261-4cee-bb44-138d3ef5d965
{} 639dec6b-bb19-468b-871c-c5c441c4b0cb
{} 5b631642-bd26-49fe-bd20-1daaa972ef80
{} a403ebcc-fae0-4ca2-8c8c-7a907fd6c235
{} f30db892-07e9-47e9-837c-80727f46fd3d
hm, just the GUIDs (SkuId) for each license, that's not so useful.
For the real thing (that a human can read), we'll want a whole different command:
get-mguserlicensedetail -userid $u | Select-Object SkuId, SkuPartNumber
SkuId SkuPartNumber
----- -------------
05e9a617-0261-4cee-bb44-138d3ef5d965 SPE_E3
639dec6b-bb19-468b-871c-c5c441c4b0cb Microsoft_365_Copilot
5b631642-bd26-49fe-bd20-1daaa972ef80 POWERAPPS_DEV
a403ebcc-fae0-4ca2-8c8c-7a907fd6c235 POWER_BI_STANDARD
f30db892-07e9-47e9-837c-80727f46fd3d FLOW_FREE
So to add this to a regular one-liner without a powershell loop for each account, we'll need a join, we'll add this to our original get-mguser call (because if this is for a human to read, you don't want the SkuId normally):
@{N='License';E={(Get-MgUserLicenseDetail -All -UserId $_.id).SkuPartNumber -join ';'}}
And to also, just for fun let's also pull the last interactive and non-interactive login dates:
@{N='LastInteractiveSignInDate';E={$_.SignInActivity.LastSignInDateTime}}, `
@{N='LastNonInteractiveSignInDate';E={$_.SignInActivity.LastNonInteractiveSignInDateTime}}
Also, let's pull the list of properties into a variable to make the call simpler (the computed statements are bolded):
$Properties = @('AccountEnabled','City','Country','Department','DisplayName','JobTitle','UserPrincipalName','CreatedDateTime','SignInActivity', 'LastPasswordChangeDateTime')
$Users = Get-MgUser -All -Property $Properties |
Select-Object @{N='AccountEnabled';E={$_.AccountEnabled}}, `
@{N='City';E={$_.City}}, `
@{N='Country';E={$_.Country}},
@{N='Department';E={$_.Department}},
@{N='DisplayName';E={$_.DisplayName }}, `
@{N='JobTitle';E={$_.JobTitle }}, `
@{N='UserPrincipalName';E={$_.UserPrincipalName}}, `
@{N='CreatedDateTime';E={$_.CreatedDateTime}}, `
@{N='LastInteractiveSignInDate';E={$_.SignInActivity.LastSignInDateTime}}, `
@{N='LastNonInteractiveSignInDate';E={$_.SignInActivity.LastNonInteractiveSignInDateTime}},
@{N='License';E={(Get-MgUserLicenseDetail -UserId $_.UserPrincipalName).SkuPartNumber -join '; '}}
This can take a while - for each user, those last 3 lines add time. The two "signindate" fields are an additional lookup, and the license detail line is a whole other command for each line.
So it's essentially another loop, but buried in standard syntax so you don't have to code a less efficient version ....
OK, so we have the last login dates so we can pick off inactive accounts, and license usage. Also accounts that have been explicity disagbled (that firstr "AccountEnabled" field) Dump the whole thing out to a CSV file with "| Out-CSV" , and you're an Excel sort away from a list of MS licenses you can stop paying for and a list of Entra accounts that you can likely disable or delete. Or if you are philosphically opposed to spreadsheets or excel in particular, you can do the same with "| Out-GridView", except emailing your results can be a problem from there ...
But what about a real security thing, something your SOC might alert on? Stay tuned, that's next ...
===============
Rob VandenBrink
rob@coherentsecurity.com
Cloud providers typically expose a REST API at 169.254.169.254 that allows code running on virtual machines to retrieve machine-specific data. Some of the data is more or less harmless, such as the region the machine is running in or its MAC and IP addresses. However, the service may also be used to retrieve credentials for IAM roles and service account tokens.
Why 169.254.169.254, and not, for example, an RFC1918 address or loopback? RFC 1918 addresses are usually used and routed internally by cloud providers. Interfering with them would be risky and add complexity. The loopback interface is often treated differently from a normal interface, particularly in containers, and is not well-suited for traffic that must be controlled by the operating system's packet-filtering mechanisms. 169.254.169.254 is part of the link local address prefix 169.254/16 [RFC3927]. These addresses are specifically not routable, unlike RFC 1918 addresses, which may be routed locally ("The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.").
This unique property of link-local addresses makes them ideal for addresses used multiple times , and that must never be routed. An attacker will not be able to reach out to this address remotely. But there is a "trick": the virtual machine itself can reach the metadata service, and if an attacker uses server-side request forgery (SSRF) to trick the server into sending the request, the address may be reached. The attacker could now use this SSRF vulnerability to retrieve secrets [1].
Probably the best-known breach assisted by the metadata service was Capital One, which led to a huge data leak and later to the prosecution of the attacker. Since then, we have seen attempts to exploit SSRF vulnerabilities in order to access the metadata service. But what I notied today is a widespread scan that appears to be not targeted at a particular vulnerability:
GET /?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: [redacted]
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip
This scan does not appear to target a specific vulnerability; it is a more generic attempt to find "some" vulnerability, and it is not clear which one. If you have any insight, please let me know :)
As far as securing the metadata service goes, Amazon used version 2 of the service following the Capital One breach. A simple "GET" request is no longer sufficient, making SSRF access highly unlikely.
Special IPv6 note: IPv6 uses fd20:ce::254, which is a unique local address, more like an RFC 1918 address instead of an IPv6 link-local fe80:: address.
[1] https://www.sans.org/blog/cloud-instance-metadata-services-imds-
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Apple today released updates for iOS/iPadOS (26 and 18) and macOS 26. This update fixes 108 vulnerabilities and comes about two weeks after the much smaller macOS update that addressed the single screen-sharing vulnerability. This vulnerability did not affect iOS/iPadOS.
None of the vulnerabilities has been exploited so far. There are a few WebKit vulnerabilities, but no standalone Safari patch for older operating systems. 87 of the vulnerabilities affect only iOS 18, making this more of an iOS 18 release than one for the newer operating systems. Only six vulnerabilities affect all three OSs released today. All 6 vulnerabilities affect WebKit.
Apple's vulnerability summary notes that the vulnerabilities patched in today's VisionOS release will be enumerated at a later date.
| iOS 26.6.1 and iPadOS 26.6.1 | iOS 18.7.10 and iPadOS 18.7.10 | macOS Tahoe 26.6.2 |
|---|---|---|
| CVE-2026-28958: An app may be able to access sensitive user data. Affects WebKit |
||
| x | ||
| CVE-2026-28973: A malicious app may be able to break out of its sandbox. Affects libc |
||
| x | ||
| CVE-2026-28984: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-28990: Processing a maliciously crafted image may corrupt process memory. Affects ImageIO |
||
| x | ||
| CVE-2026-28996: An app may be able to access sensitive user data. Affects Storage |
||
| x | ||
| CVE-2026-39868: An app may be able to cause unexpected system termination or corrupt kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-39877: An app may be able to disclose kernel memory. Affects IOSkywalkFamily |
||
| x | ||
| CVE-2026-43661: Processing a maliciously crafted image may corrupt process memory. Affects ImageIO |
||
| x | ||
| CVE-2026-43663: Processing maliciously crafted web content may lead to an unexpected process crash. Affects WebKit |
||
| x | ||
| CVE-2026-43667: An attacker in a privileged network position may be able to cause a denial-of-service. Affects AirDrop |
||
| x | ||
| CVE-2026-43673: Processing a maliciously crafted audio file may corrupt process memory. Affects CoreAudio |
||
| x | ||
| CVE-2026-43676: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-43700: Processing maliciously crafted web content may disclose sensitive user information. Affects WebKit |
||
| x | ||
| CVE-2026-43701: A malicious website may be able to process restricted web content outside the sandbox. Affects WebKit |
||
| x | ||
| CVE-2026-43705: Processing maliciously crafted web content may lead to memory corruption. Affects WebKit |
||
| x | ||
| CVE-2026-43708: A malicious website may exfiltrate data cross-origin. Affects WebKit |
||
| x | ||
| CVE-2026-43711: Processing a maliciously crafted video file may lead to unexpected app termination. Affects CoreMedia |
||
| x | ||
| CVE-2026-43714: A malicious app may be able to access protected user data. Affects Foundation |
||
| x | ||
| CVE-2026-43717: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebRTC |
||
| x | ||
| CVE-2026-43720: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit Canvas |
||
| x | ||
| CVE-2026-43722: An app may be able to leak sensitive kernel state. Affects Kernel |
||
| x | ||
| CVE-2026-43723: An app may be able to gain root privileges. Affects MediaRemote |
||
| x | ||
| CVE-2026-43724: An app may be able to cause unexpected system termination or write kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-43725: A malicious website may be able to process restricted web content outside the sandbox. Affects WebKit |
||
| x | ||
| CVE-2026-43727: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-43729: Processing a maliciously crafted image may corrupt process memory. Affects Model I/O |
||
| x | ||
| CVE-2026-43731: Processing maliciously crafted web content may lead to memory corruption. Affects WebKit |
||
| x | ||
| CVE-2026-43735: A malicious website may exfiltrate data cross-origin. Affects WebKit |
||
| x | ||
| CVE-2026-43738: Processing a maliciously crafted asset catalog may result in disclosure of process memory. Affects CoreUI |
||
| x | ||
| CVE-2026-43742: Processing maliciously crafted web content may lead to an unexpected process crash. Affects WebKit |
||
| x | ||
| CVE-2026-43744: Processing an audio stream in a maliciously crafted media file may terminate the process. Affects CoreAudio |
||
| x | ||
| CVE-2026-43745: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-43754: An app may be able to leak sensitive kernel state. Affects Kernel |
||
| x | ||
| CVE-2026-43757: An app may be able to cause unexpected system termination. Affects Kernel |
||
| x | ||
| CVE-2026-43769: An app may be able to cause unexpected system termination. Affects Kernel |
||
| x | ||
| CVE-2026-43776: Processing a maliciously crafted file may lead to unexpected app termination or arbitrary code execution. Affects AppleDouble |
||
| x | ||
| CVE-2026-43778: An app may be able to cause unexpected system termination or corrupt kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-43794: Processing maliciously crafted web content may lead to memory corruption. Affects WebKit |
||
| x | x | x |
| CVE-2026-43796: An app may be able to read a persistent device identifier. Affects Game Center |
||
| x | ||
| CVE-2026-43797: An app may be able to access information about a user's contacts. Affects Contacts |
||
| x | ||
| CVE-2026-43800: An app may be able to access sensitive user data. Affects Siri |
||
| x | ||
| CVE-2026-43801: An app may be able to access sensitive user data. Affects App Store |
||
| x | ||
| CVE-2026-43802: An app may be able to cause unexpected system termination. Affects CoreVideo |
||
| x | ||
| CVE-2026-43803: A remote attacker may be able to cause unexpected system termination. Affects CoreAudio |
||
| x | ||
| CVE-2026-43807: A malicious accessory may be able to cause unexpected app termination. Affects MobileAccessoryUpdater |
||
| x | ||
| CVE-2026-43810: A remote user may be able to cause unexpected system termination or corrupt kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-43811: An app may be able to modify protected parts of the file system. Affects Books |
||
| x | ||
| CVE-2026-43812: An app may be able to cause unexpected system termination. Affects Pro Res |
||
| x | ||
| CVE-2026-43818: Processing a maliciously crafted image may lead to arbitrary code execution. Affects ImageIO |
||
| x | ||
| CVE-2026-43821: An app may be able to read files outside of its sandbox. Affects WebKit Process Model |
||
| x | ||
| CVE-2026-64692: An app may be able to cause a denial-of-service. Affects Heimdal |
||
| x | ||
| CVE-2026-64693: Processing a maliciously crafted image may lead to a denial-of-service. Affects ImageIO |
||
| x | ||
| CVE-2026-64695: A remote user may be able to cause unexpected system termination or corrupt kernel memory. Affects APFS |
||
| x | ||
| CVE-2026-64700: An app may be able to cause unexpected system termination. Affects Kernel |
||
| x | ||
| CVE-2026-64707: An app may be able to delete files for which it does not have permission. Affects BackgroundAssets |
||
| x | ||
| CVE-2026-64709: An app may be able to disclose kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-64715: Processing maliciously crafted web content may lead to an unexpected process crash. Affects WebKit |
||
| x | x | |
| CVE-2026-64719: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebRTC |
||
| x | ||
| CVE-2026-64721: An app may be able to access sensitive user data. Affects Kernel |
||
| x | ||
| CVE-2026-64722: Processing a 3D model may result in disclosure of process memory. Affects Model I/O |
||
| x | ||
| CVE-2026-64723: An app may be able to access sensitive user data. Affects Kernel |
||
| x | ||
| CVE-2026-64724: An attacker on the local network may be able to cause a denial-of-service. Affects mDNSResponder |
||
| x | ||
| CVE-2026-64725: An app may be able to cause a denial-of-service. Affects Audio |
||
| x | ||
| CVE-2026-64726: An attacker in physical proximity may be able to corrupt process memory. Affects Wi-Fi |
||
| x | ||
| CVE-2026-64732: An attacker with physical access may be able to access sensitive user data during iPhone Mirroring. Affects Accessibility |
||
| x | ||
| CVE-2026-64734: Processing a maliciously crafted contact may leak sensitive data. Affects Contacts |
||
| x | ||
| CVE-2026-64735: A remote attacker may be able to bypass network filters. Affects Kernel |
||
| x | ||
| CVE-2026-64738: A malicious app may be able to break out of its sandbox. Affects Maps |
||
| x | ||
| CVE-2026-64739: An attacker may be able to cause unexpected app termination. Affects Libnotify |
||
| x | ||
| CVE-2026-64740: A malicious app may be able to break out of its sandbox. Affects Game Center |
||
| x | ||
| CVE-2026-64742: An app may be able to access sensitive user data. Affects FrontBoard |
||
| x | ||
| CVE-2026-64743: An app may be able to access sensitive user data. Affects Managed Configuration |
||
| x | ||
| CVE-2026-64744: An app may be able to disclose kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-64746: An app may be able to add contacts without user authorization. Affects Contacts |
||
| x | ||
| CVE-2026-64747: An app may be able to execute arbitrary code with kernel privileges. Affects AVEVideoEncoder |
||
| x | ||
| CVE-2026-64749: An app may be able to cause unexpected system termination or corrupt kernel memory. Affects Kernel |
||
| x | ||
| CVE-2026-64755: An app may be able to access sensitive user data. Affects WorkoutKit |
||
| x | ||
| CVE-2026-64757: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-64760: An app may be able to leak sensitive kernel state. Affects IOSurfaceAccelerator |
||
| x | ||
| CVE-2026-64762: An app may be able to cause unexpected system termination. Affects AVEVideoEncoder |
||
| x | ||
| CVE-2026-64763: Processing a maliciously crafted file may lead to unexpected app termination or arbitrary code execution. Affects SceneKit |
||
| x | ||
| CVE-2026-64764: Processing a maliciously crafted file may lead to unexpected app termination or arbitrary code execution. Affects SceneKit |
||
| x | ||
| CVE-2026-64765: Processing a maliciously crafted file may lead to unexpected app termination or arbitrary code execution. Affects SceneKit |
||
| x | ||
| CVE-2026-64768: A remote attacker may cause an unexpected app termination. Affects Model I/O |
||
| x | ||
| CVE-2026-64769: A remote attacker may be able to cause unexpected application termination or heap corruption. Affects Model I/O |
||
| x | ||
| CVE-2026-64771: A remote attacker may be able to cause unexpected application termination or heap corruption. Affects Model I/O |
||
| x | ||
| CVE-2026-64772: A remote attacker may be able to cause unexpected application termination or heap corruption. Affects Model I/O |
||
| x | ||
| CVE-2026-64774: A remote attacker may be able to cause unexpected application termination or heap corruption. Affects Model I/O |
||
| x | ||
| CVE-2026-64778: Visiting a maliciously crafted website may leak sensitive data. Affects WebKit History |
||
| x | x | x |
| CVE-2026-64779: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit Storage |
||
| x | x | x |
| CVE-2026-64780: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | x |
| CVE-2026-64781: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | x |
| CVE-2026-64782: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | x |
| CVE-2026-64784: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | |
| CVE-2026-64787: Processing maliciously crafted web content may lead to an unexpected process termination. Affects WebKit |
||
| x | x | |
| CVE-2026-64788: Processing maliciously crafted web content may lead to memory corruption. Affects IOGPUFamily |
||
| x | x | |
| CVE-2026-65329: An attacker in a privileged network position may be able to bypass IPSec authentication and intercept network traffic. Affects Telephony |
||
| x | ||
| CVE-2026-65330: An app may be able to cause unexpected system termination or corrupt kernel memory. Affects Kernel |
||
| x | x | |
| CVE-2026-65331: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | |
| CVE-2026-65334: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | |
| CVE-2026-65338: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | x | |
| CVE-2026-65339: An app may be able to leak sensitive user information. Affects Audio |
||
| x | x | |
| CVE-2026-65340: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit |
||
| x | ||
| CVE-2026-65341: Processing maliciously crafted web content may lead to memory corruption. Affects WebKit |
||
| x | x | x |
| CVE-2026-65343: A remote attacker may be able to cause unexpected system termination. Affects Kernel |
||
| x | x | |
| CVE-2026-65346: Processing an image may lead to arbitrary code execution. Affects ImageIO |
||
| x | x | |
| CVE-2026-65347: Processing an image may lead to a denial-of-service. Affects ImageIO |
||
| x | x | |
| CVE-2026-65349: An app may be able to cause unexpected system termination or read kernel memory. Affects Kernel |
||
| x | x | |
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
About 20 years ago, with macOS 10.5 (Leopard), Apple introduced screen sharing. Apple did not invent a new protocol for screen sharing. Instead, it used the established VNC protocol. VNC is a pretty simple, unencrypted protocol using TCP port 5900. Historically, the protocol used a simple global password for authentication. Apple adapted the protocol for its own use, but overall, left the VNC protocol itself alone.
A couple of weeks ago, two severe vulnerabilities exposed issues Apple introduced when it bolted on its own modifications to VNC. Currently, these vulnerabilities are being exploited, and a system with screen sharing exposed should be considered compromised. But here are some tips to improve screen sharing security.
One weakness exposed by these recent vulnerabilities is Apple's support for both "regular" VNC authentication and authentication via Apple's own macOS authentication system.
Apple does allow old-fashioned VNC authentication by defining a VNC password. If this authentication scheme is used, a VNC client is prompted only for a password, not a username. The client may then ask for permission to use the screen, or they will be presented with an OS login prompt. This can be useful if you are trying to provide remote support to a logged-in user. But it does provide access to the system without any strong authentication. Access should still be secured by local user credentials, but the process already runs with elevated privileges to allow access for any user who logs in. This contributed to a recent vulnerability.
Next, you can restrict which users can remotely access the system. This should be restricted to allow only users who need remote access to connect.
Access to screen sharing can also be controlled via macOS's built-in firewall. But the settings are not always clear. Just enabling the firewall is not sufficient.
If "Automatically allow built-in software" is enabled, the firewall will allow access to screen sharing. The same is true for "Automatically allow downloaded signed software". Even if "stealth mode" is enabled, screen sharing is still available. You may also select "Block all incoming connections", which will block everything, even applications you approved in the past.
Here are a few command-line tips to secure the system (this is for macOS 26; prior versions use slightly different syntax)
# use this to check the current firewall state
# /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
# turn firewall on
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on
# turn stealth mode on to not respond to pings
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
# do not allow signed binaries
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setallowsigned off
# disable filesharing
sudo launchctl disable system/com.apple.smbd
# disable screensharing
sudo launchctl disable system/com.apple.screensharing
A script like this is handy if you need to switch from your internal network to a public one. VNC access should always happen via a VPN. SSH forwarding works well with VNC. Other solutions, like Tailscale, are easy to use if you need VNC for remote support.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Wireshark release 4.6.8 fixes 28 vulnerabilities and 25 bugs.
Didier Stevens
Senior handler
blog.DidierStevens.com
In the past few weeks, I have been using Gemma4 as a Large Language Model (LLM) to see how useful it can be to analyze some of the malware hashes uploaded to the DShield sensor over the past 30 days and figure out how its recommendation can be considered useful about the activity my DShield sensor is collecting and tracking. The model I use for this testing is gemma4:e4b [2] using two sites to compare the data against VirusTotal and CyberGordon.
The following questions were submitted to Gemma for information:
Instructions:
1. Determine if we should be concerned with the volumes or suspicious volumes match indicators of compromise (IoC) or tactics mentioned on the two external websites.
2. Provide a concise comparative analysis and recommendations for action to prevent actors/bots to successfully compromise the sensor.
3. Identify what type of malware family (Popular threat label) the top 3 files are associated with.
4. Highlight potential issues with the top 3 inbound hashes (files) downloaded by actors/bots logged in the sensor and which sites have the most information about this activity.
Result from the LLM Analysis
Comparative analysis from Gemma 4 :
As a cybersecurity analyst, I have analyzed the provided data stream concerning files downloaded by actors/bots to the Cowrie sensors.
Analysis of Downloaded Hashes (Top 10 IoCs)
Findings and Analysis
1. Volume vs. IoCs vs. Tactics
The sheer volume of these hashes (126, 110 events) is a major concern. High volumes do not automatically confirm malicious intent, but when coupled with the fact that they are *downloaded* from an interactive sensor like Cowrie, it indicates successful actor persistence and data exfiltration attempts.
Indicators/Tactics
Indicator of Compromise (IoC): The hashes themselves act as IoCs if they resolve to known malware families or C2 infrastructure components. Since the external sites provided no results, the focus must be on the *behavior*—the repeated transfer of these files.
Tactics (MITRE ATT&CK): This activity strongly suggests **Persistence**, **Command and Control (C2)** communication, and potentially **Lateral Movement/Exfiltration**. The actors are not merely querying the system; they are downloading specific files repeatedly.
2. Comparative Analysis & Recommendations
| Aspect | VirusTotal (VT) | CyberGordon (CG) | Conclusion / Action Recommendation |
| :--- | :--- | :--- | :--- |
| Data Depth | High-fidelity, integrated threat intelligence from multiple sources (AV engines). Best for direct identification. | Academic/Historical analysis engine. Useful for deep source tracking and niche observations. | VT is superior for immediate threat context; CG offers supporting research. |
| Reliability | Generally reliable, though sometimes slow or requires paid access for full fidelity. | Utility appears high but the provided output is generic (focusing on JS compatibility rather than results). | **Rely primarily on VT/Commercial Threat Feeds.** Do not treat lack of a result as "safe." |
| Missing Data | The provided snippet was boilerplate ("Please enable JavaScript"), meaning we missed vital IoC intelligence. | The provided snippet was generic browser/engine advice, offering no actionable threat intel. | **Critical Action:** Develop a structured workflow to *ensure* the results page is fully processed and captured for all 10 hashes. |
Recommendations for Action (Preventing Compromise):
1. Immediate Containment: Treat any machine connected through this sensor as compromised. Isolate the host and initiate forensic imaging immediately.
2. Mitigation at Sensor Level: Update Cowrie's logging and alerting capabilities to track file *execution* attempts, not just downloads. Implement stricter egress filtering on the network hosting the sensors.
3. Threat Hunting (Proactive): Utilize the Top 10 hashes to query internal Endpoint Detection and Response (EDR) solutions across the entire enterprise, searching for the hash signatures or file names appearing on any system *outside* of the sensor environment.
4. Hardening: Review user access policies and network segmentation rules. The repeated downloading suggests a persistent gap in perimeter controls.
3. Associated Malware Family (Top 3 Hashes)
Since no specific threat intelligence results were provided for these hashes, this analysis is based on the pattern of high-volume command-and-control behavior.
1. 197c74408e15bd1168105f564f96aace4fd4819961b724630bf5a6be4878daf8: **Botnet/Loader Malware.** The extremely high event count and consistent downloading pattern are classic indicators of a payload being repeatedly delivered, likely by an established botnet or initial access Trojan (RAT).
2. 31d4181843b1ed10a7e7cb3f108f6d6c50a7a4452ee52ddacabe8ca77260615e: **Backdoor/Keylogger.** Similar to the top hash, but potentially representing a specific piece of payload used for data exfiltration (like credentials or session tokens).
3. 94f2e4d8d4436874785cd14e6e6d403507b8750852f7f2040352069a75da4c00: **Credential Stealer/Dropper.** This hash may represent a modular component or a staged payload, designed to "drop" the final malware onto the compromised system after initial access.
4. Potential Issues with Top 3 Hashes & Best Data Source
Potential Issue Highlight (Focusing on Behavioral Risk)
The primary issue is not necessarily what the hashes *are*, but that they are actively being *downloaded* repeatedly by a controlled actor over a sustained period (Top 10). This behavior confirms **successful compromise and established persistence**. The actors have successfully identified data pathways to download their chosen payloads, bypassing existing security controls.
Comparison of Sites for Top 3
Given the critical nature of these files:
VirusTotal (VT): Is the preferred source. Despite the provided boilerplate text, VT's strength lies in its aggregation of multiple vendor signatures (AV engines). It provides the highest likelihood of a quick determination whether the hash is *known malicious*.
CyberGordon (CG): Is useful as a secondary research source or for understanding the historical context of the observed payload type. Its data output, based on observation and academic logging, might reveal more about *how* the file was used in previous compromises, which is valuable for threat hunting.
Conclusion
The most reliable actionable intelligence will be obtained by re-querying both sites multiple times to ensure 100% capture of the IoC data. However, **VT provides the immediate signature risk assessment.**
My own conclusion: I think the information provided by Gemma is a nice summary as long as the right tools (sites) are provided that can be used to gather additional information to use to better answer the questions initially asked in the instructions.
The python script used for this test is available here.
[1] https://en.wikipedia.org/wiki/Large_language_model
[2] https://ollama.com/library/gemma4
[3] https://cybergordon.com
[4] https://www.virustotal.com
[5] https://dshield.org/diary/Using+AI+Gemma+3+Locally+with+a+Single+CPU/32556
[6] https://github.com/bruneaug/DShield-SIEM
[7] https://github.com/bruneaug/DShield-SIEM/tree/main/Ollama
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
A couple of days ago, Xavier posted about Atuin to gain more insight into the command history. Atuin does a great job of better organizing what is usually handled by "bash_history" and collecting meaningful additional data. Our reader David commented that this can also be done quite well with Linux's kernel process accounting feature, and I think he is very right. I really like Linux process accounting for a number of reasons, so here is a quick introduction.
Process accounting is a kernel feature. You will not see a specific process responsible for it. Instead, the "accton" command signals the kernel to start logging process data to a specific location (usually /var/log/account/pacct). Once a process terminates, the kernel will log respective details to the binary log file.
I don't think process accounting is enabled by default on any Linux system. It does add a little additional overhead, but some users may shy away from it because it requires additional disk writes to collect the information. Memory and other CPUs should not be significantly impacted by process accounting. On my not very busy Proxmox system, it uses about 50 MB/day of disk space. So nothing that should be noticeable for most systems.
Installation usually comes down to installing the respective package for your distribution. On Debian based distributions, it is just
apt install acct
This will typically also configure the startup scripts, but it can't hurt to run
systemctl enable --now acct
That is it. Wait a little bit, and you will see the log.
Logs are saved in a binary format. The "lastcomm" command can be used to display the log in a readable format. For example:
ip6tables-save S root __ 0.00 secs Wed Aug 12 06:25
iptables-restor S root __ 0.00 secs Wed Aug 12 06:25
iptables-save S root __ 0.00 secs Wed Aug 12 06:25
check_ssh 100107 __ 0.00 secs Wed Aug 12 06:25
cron F 100000 __ 0.00 secs Wed Aug 12 06:25
sh S 100000 __ 0.00 secs Wed Aug 12 06:25
debian-sa1 100000 __ 0.00 secs Wed Aug 12 06:25
These are a few lines from my Proxmox server. It logs the process name, Flags (S=super user, F=forked process, D=generated core dump, X=terminated by signal), User name (or ID), CPU execution time, and finally the timestamp at which the process was started. The output may be modified slightly depending on the command-line arguments used.
Unlike most Linux logs, these logs are not created by syslog. However, you may still read them with syslog to forward them to a central log collector/SIEM. Syslog-ng for example include a "s_pacct" processor for process accounting logs. You enable it with this configuration:
source s_pacct {
pacct(file("/var/log/account/pacct"));
};
The "sa" command can be used to easily extract summaries from accounting data. For example, a breakdown by CPU time used by different processes
# sa -c | head -10
329063 100.00% 259245.37re 100.00% 70.29cp 100.00% 0avio 24320k
469 0.14% 55.38re 0.02% 52.65cp 74.90% 0avio 124752k ffmpeg
488 0.15% 5.43re 0.00% 4.57cp 6.51% 0avio 5338k apt-get
2820 0.86% 3.60re 0.00% 3.34cp 4.74% 0avio 13295k ceph
1231 0.37% 1.96re 0.00% 1.92cp 2.73% 0avio 1974k ps
312 0.09% 1907.83re 0.74% 1.36cp 1.93% 0avio 88176k named
7 0.00% 39483.07re 15.23% 0.76cp 1.08% 0avio 6348k systemd-journal
123 0.04% 34804.71re 13.43% 0.34cp 0.48% 0avio 20367k ***other*
8 0.00% 0.68re 0.00% 0.27cp 0.38% 0avio 3926k store
366 0.11% 0.58re 0.00% 0.26cp 0.36% 0avio 2235k dpkg-deb*
Process accounting is a kernel feature, and the kernel must be compiled and configured to support process accounting. If you are running Linux containers in Proxmox (the platform I am using), process accounting will not work unless the container is privileged. But it does not have to work. The container processes are logged by the host, which I think is actually better. This way, the logs are more easily centralized, and they can't be tampered with from inside the container.
I think Linux kernel process accounting is a very neat and often overlooked feature. You may be able to do more fine-grained inspection with eBPF, but process accounting is "ready to go and useful" with little work. It does not log command line options, which may be an issue in incident response. But it is a very good supplement to other features like bash_history files, and it captures processes that bash_history would never see.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
This month we got patches for 418 vulnerabilities. Of these, 62 are critical, 1 is being exploited in the wild, and 2 were publicly disclosed as zero-days. Notable fixes include Windows privilege escalation, container tampering, and critical QUIC and DNS Server remote code execution bugs.
A few vulnerabilities worth mentioning:
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability (CVE-2026-68820)
This Important-severity elevation of privilege vulnerability is listed by Microsoft as exploited in the wild but not publicly disclosed, and it has a CVSS score of 7.0. The flaw is a use-after-free issue in the Windows Ancillary Function Driver for WinSock affecting supported Windows client and server versions; a locally authenticated attacker with low privileges could run a specially crafted application to trigger a race condition and, if successful, gain SYSTEM privileges. The CVSS vector reflects local access, low privileges required, no user interaction, and high attack complexity because exploitation requires winning that race condition. Administrators should prioritize applying the relevant Windows security updates, particularly on systems where local code execution by untrusted users is possible, and monitor for suspicious privilege-escalation activity.
Windows User Profile Service Elevation of Privilege Vulnerability (CVE-2026-62832)
Microsoft says this vulnerability has been publicly disclosed but has not been exploited in the wild, making it a zero-day disclosure without confirmed exploitation at this time. Rated Important with a CVSS score of 7.8, this Windows User Profile Service flaw is an improper link resolution, or “link following,” issue that could allow a local authenticated attacker to elevate privileges. To exploit it, an attacker would need credentials for another local account and could run a specially crafted application to load another user’s registry hive; successful exploitation could allow access to or modification of another user’s data and ultimately grant administrator privileges. User interaction is not required. Administrators should prioritize applying the Microsoft security updates across affected Windows 10, Windows 11, Windows Server 2022, and Windows Server 2025 systems, and should also limit local account reuse and monitor for unusual registry hive loading or profile service activity.
Windows Container Isolation FS Filter Driver (unionfs.sys) Tampering Vulnerability (CVE-2026-72971)
This vulnerability was publicly disclosed before Patch Tuesday, making it a zero-day, but Microsoft says it has not been exploited in the wild; it is rated Important with a CVSS score of 5.5. The flaw is an improper link-resolution, or “link following,” issue in the Windows Container Isolation file system filter driver, unionfs.sys, affecting Windows 11 Version 26H1 on x64 and ARM64 systems. A local, authenticated attacker could exploit it with low complexity and no user interaction to tamper with files, resulting in high integrity impact, though Microsoft rates confidentiality and availability impact as none. Administrators should apply the Windows updates that correct the driver’s link-handling behavior, particularly on systems using Windows containers or container isolation features.
Microsoft QUIC Remote Code Execution Vulnerability (CVE-2026-62815)
This Critical Microsoft QUIC remote code execution vulnerability is not listed as exploited in the wild or publicly disclosed. It carries a CVSS score of 9.8 and is a use-after-free flaw that could allow an unauthenticated remote attacker to send a specially crafted packet to an affected service over the network and execute code on the target system, with no user interaction required. Affected platforms include Windows 11 and Windows Server 2022/2025, including Server Core installations. Administrators should prioritize applying the Microsoft update, especially on systems exposing QUIC-enabled services to untrusted networks, and consider limiting network exposure where patching cannot be completed immediately.
Windows DNS Server Remote Code Execution Vulnerability (CVE-2026-62878)
Microsoft reports that CVE-2026-62878 is neither exploited in the wild nor publicly disclosed; it is a Critical Windows DNS Server remote code execution vulnerability with a CVSS score of 9.8. The flaw is a stack-based buffer overflow in Windows DNS that can be triggered remotely by an unauthenticated attacker sending a specially crafted packet to an affected service over the network, with no user interaction required, potentially allowing code execution on the target DNS server. Affected systems include multiple Windows Server releases from 2012 through 2025, as well as listed Windows 10 versions where the vulnerable component is present. Administrators should apply Microsoft’s security updates promptly, especially on DNS servers, and reduce exposure by limiting DNS service access to trusted networks where possible, blocking unnecessary inbound traffic at firewalls, and monitoring DNS servers for crashes or anomalous traffic patterns.
This was a summary of Microsoft’s monthly updates highlighting some important vulnerabilities. Prioritize the exploited WinSock privilege-escalation flaw, then the publicly disclosed User Profile Service and unionfs.sys issues, and patch internet-exposed QUIC services and DNS servers quickly due to remote code execution risk.
A detailed list of this month's vulnerabilities follows below. To search and filter them, visit my dashboard: https://patchlens.io
| Description | |||||||
|---|---|---|---|---|---|---|---|
| CVE | Disclosed | Exploited | Exploitability (old versions) | current version | Severity | CVSS Base (AVG) | CVSS Temporal (AVG) |
| .NET Core Remote Code Execution Vulnerability | |||||||
| %%cve:2026-70354%% | No | No | - | - | Important | 7.8 | 6.8 |
| .NET Denial of Service Vulnerability | |||||||
| %%cve:2026-62901%% | No | No | - | - | Important | 7.5 | 6.5 |
| .NET Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62909%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-58641%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62871%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62886%% | No | No | - | - | Important | 7.8 | 6.8 |
| .NET Framework Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62872%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-65810%% | No | No | - | - | Important | 7.8 | 6.8 |
| .NET Framework Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62897%% | No | No | - | - | Important | 7.0 | 6.1 |
| .NET Information Disclosure Vulnerability | |||||||
| %%cve:2026-62900%% | No | No | - | - | Important | 5.9 | 5.2 |
| %%cve:2026-62902%% | No | No | - | - | Important | 6.5 | 5.7 |
| .NET Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-62899%% | No | No | - | - | Important | 5.9 | 5.2 |
| AMD Zen Information Disclosure Vulnerability | |||||||
| %%cve:2026-59130%% | No | No | - | - | Important | 5.6 | 4.9 |
| %%cve:2026-59131%% | No | No | - | - | Important | 5.6 | 4.9 |
| Active Directory Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-65777%% | No | No | - | - | Important | 5.3 | 4.6 |
| Application Information Services Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61357%% | No | No | - | - | Important | 7.8 | 6.8 |
| Application Insights Profiler Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-49163%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Azure Active Directory Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-50481%% | No | No | - | - | Critical | 9.9 | 8.6 |
| Azure Confidential Ledger Remote Code Execution Vulnerability (no customer action required) |
|||||||
| %%cve:2026-68823%% | No | No | - | - | Critical | 9.1 | 7.9 |
| Azure CycleCloud Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-70340%% | No | No | - | - | Important | 8.1 | 7.1 |
| Azure CycleCloud Information Disclosure Vulnerability | |||||||
| %%cve:2026-65806%% | No | No | - | - | Important | 6.5 | 5.7 |
| Azure Entra ID Spoofing Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62869%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Azure Logic Apps Information Disclosure Vulnerability (no customer action required) |
|||||||
| %%cve:2026-56161%% | No | No | - | - | Critical | 9.6 | 8.3 |
| Azure Monitor Agent Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-47299%% | No | No | - | - | Important | 7.2 | 6.3 |
| Azure SQL Database Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-63522%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-56162%% | No | No | - | - | Critical | 10.0 | 8.7 |
| Azure SQL Managed Instance Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62836%% | No | No | - | - | Critical | 8.7 | 7.6 |
| Azure SRE Agent Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62830%% | No | No | - | - | Critical | 9.9 | 8.6 |
| Azure Service Bus Remote Code Execution Vulnerability (no customer action required) |
|||||||
| %%cve:2026-50515%% | No | No | - | - | Critical | 9.9 | 8.6 |
| Azure Storage Explorer Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-57104%% | No | No | - | - | Important | 8.8 | 7.7 |
| Capability Access Management Service (camsvc) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62892%% | No | No | - | - | Important | 7.0 | 6.1 |
| CoPilot Chat Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-65675%% | No | No | - | - | Important | 7.1 | 6.2 |
| Copilot Cowork Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-59118%% | No | No | - | - | Critical | 9.3 | 8.1 |
| Desktop Window Manager Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65786%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65787%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65788%% | No | No | - | - | Important | 7.0 | 6.1 |
| GitHub Copilot and Visual Studio Code Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-70335%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft 365 Admin Center Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62873%% | No | No | - | - | Critical | 9.8 | 8.5 |
| Microsoft Access Remote Code Execution Vulnerability | |||||||
| %%cve:2026-64906%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64912%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64908%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64914%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64920%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64919%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Azure Kubernetes Service Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-50516%% | No | No | - | - | Critical | 9.4 | 8.2 |
| Microsoft COM for Windows Information Disclosure Vulnerability | |||||||
| %%cve:2026-59136%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Defender for Endpoint for Mac Information Disclosure Vulnerability | |||||||
| %%cve:2026-54123%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Digest Authentication Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62698%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability | |||||||
| %%cve:2026-66301%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Dynamics 365 On-Premises Remote Code Execution Vulnerability | |||||||
| %%cve:2026-65815%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Dynamics Business Central Information Disclosure Vulnerability | |||||||
| %%cve:2026-40375%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Entra Connect Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65673%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Entra Provisioning Service Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-59115%% | No | No | - | - | Critical | 9.9 | 8.6 |
| Microsoft Excel Information Disclosure Vulnerability | |||||||
| %%cve:2026-68802%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-68808%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-68813%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70318%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70327%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-70328%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-68797%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-68799%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Excel Remote Code Execution Vulnerability | |||||||
| %%cve:2026-65807%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-68793%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68794%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-68795%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68796%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68800%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68807%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68806%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68810%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68811%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68815%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68816%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-68798%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68801%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68803%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68804%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-68805%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68812%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68814%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-68817%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Exchange Server Denial of Service Vulnerability | |||||||
| %%cve:2026-62912%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Exchange Server Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62910%% | No | No | - | - | Important | 7.2 | 6.3 |
| %%cve:2026-65813%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62911%% | No | No | - | - | Critical | 8.0 | 7.0 |
| Microsoft Exchange Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62913%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Exchange Server Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-62915%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Exchange Server Spoofing Vulnerability | |||||||
| %%cve:2026-62914%% | No | No | - | - | Important | 7.3 | 6.4 |
| Microsoft High Performance Computing (HPC) Pack Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-59133%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft High Performance Computing (HPC) Pack Remote Code Execution Vulnerability | |||||||
| %%cve:2026-59124%% | No | No | - | - | Important | 9.8 | 8.5 |
| Microsoft Local Security Authority Server (lsasrv) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62784%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Office Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-68792%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Office Graphics Component Information Disclosure Vulnerability | |||||||
| %%cve:2026-63517%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62842%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-66809%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Office Graphics Component Remote Code Execution Vulnerability | |||||||
| %%cve:2026-63513%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-63519%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-65664%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-63526%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-66807%% | No | No | - | - | Critical | 7.8 | 6.8 |
| Microsoft Office Information Disclosure Vulnerability | |||||||
| %%cve:2026-70315%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70314%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70317%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70323%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-63524%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-63529%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-64899%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Office Remote Code Execution Vulnerability | |||||||
| %%cve:2026-63515%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-65657%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-65656%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65661%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-63532%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-63533%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64898%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-64903%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-64904%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64909%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-64910%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-64911%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-70130%% | No | No | - | - | Critical | 8.4 | 7.3 |
| Microsoft Office SharePoint Spoofing Vulnerability | |||||||
| %%cve:2026-57105%% | No | No | - | - | Important | 8.0 | 7.0 |
| %%cve:2026-70306%% | No | No | - | - | Important | 9.3 | 8.1 |
| %%cve:2026-70332%% | No | No | - | - | Critical | 9.6 | 8.3 |
| Microsoft Office Word Information Disclosure Vulnerability | |||||||
| %%cve:2026-63521%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70319%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-63528%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-63530%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-63531%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-64917%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-66806%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-66810%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Office Word Remote Code Execution Vulnerability | |||||||
| %%cve:2026-63518%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-70311%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-63525%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-63527%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64905%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-64907%% | No | No | - | - | Critical | 7.8 | 6.8 |
| %%cve:2026-64915%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft OneDrive for MacOS Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65680%% | No | No | - | - | Important | 6.7 | 5.8 |
| Microsoft Outlook Remote Code Execution Vulnerability | |||||||
| %%cve:2026-70329%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Outlook Spoofing Vulnerability | |||||||
| %%cve:2026-62882%% | No | No | - | - | Important | 4.3 | 3.8 |
| Microsoft Planetary Computer Pro Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-63508%% | No | No | - | - | Critical | 10.0 | 8.7 |
| Microsoft PowerPoint Remote Code Execution Vulnerability | |||||||
| %%cve:2026-70313%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft PowerShell Remote Code Execution Vulnerability | |||||||
| %%cve:2026-70337%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft PowerShell Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-70338%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Purview eDiscovery Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-65668%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Microsoft QUIC Information Disclosure Vulnerability | |||||||
| %%cve:2026-62898%% | No | No | - | - | Important | 7.5 | 6.5 |
| Microsoft QUIC Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62815%% | No | No | - | - | Critical | 9.8 | 8.5 |
| Microsoft Remote Registry Service Denial of Service Vulnerability | |||||||
| %%cve:2026-59138%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-61345%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft SharePoint Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-70324%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft SharePoint Remote Code Execution Vulnerability | |||||||
| %%cve:2026-70321%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft SharePoint Server Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62827%% | No | No | - | - | Critical | 8.8 | 7.7 |
| %%cve:2026-70355%% | No | No | - | - | Important | 7.3 | 7.3 |
| %%cve:2026-64921%% | No | No | - | - | Critical | 8.8 | 7.7 |
| %%cve:2026-70326%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft SharePoint Server Information Disclosure Vulnerability | |||||||
| %%cve:2026-62837%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft SharePoint Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-63514%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-63520%% | No | No | - | - | Important | 8.1 | 7.1 |
| %%cve:2026-65658%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-65663%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-65665%% | No | No | - | - | Critical | 8.8 | 7.7 |
| %%cve:2026-64901%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-66805%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-66808%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft SharePoint Server Spoofing Vulnerability | |||||||
| %%cve:2026-62829%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-63516%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-64922%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-65660%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-64897%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-64900%% | No | No | - | - | Important | 7.3 | 6.4 |
| %%cve:2026-64902%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-64916%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-58639%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62839%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62917%% | No | No | - | - | Important | 4.6 | 4.0 |
| Microsoft SharePoint Server Tampering Vulnerability | |||||||
| %%cve:2026-63512%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Teams Elevation of Privilege Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62896%% | No | No | - | - | Critical | 9.6 | 8.3 |
| %%cve:2026-65667%% | No | No | - | - | Critical | 10.0 | 8.7 |
| Microsoft Teams Remote Code Execution Vulnerability | |||||||
| %%cve:2026-65768%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Teams Spoofing Vulnerability (no customer action required) |
|||||||
| %%cve:2026-62918%% | No | No | - | - | Critical | 7.5 | 6.5 |
| Microsoft Teams for Android and iOS Spoofing Vulnerability | |||||||
| %%cve:2026-65767%% | No | No | - | - | Important | 8.8 | 7.7 |
| Microsoft Teams iOS Information Disclosure Vulnerability | |||||||
| %%cve:2026-65769%% | No | No | - | - | Important | 6.5 | 5.7 |
| Microsoft Windows Cross Device Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-66804%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Windows Search Component Information Disclosure Vulnerability | |||||||
| %%cve:2026-59135%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Windows Storage Port Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65814%% | No | No | - | - | Important | 7.8 | 6.8 |
| Microsoft Word Information Disclosure Vulnerability | |||||||
| %%cve:2026-70310%% | No | No | - | - | Important | 5.5 | 4.8 |
| Microsoft Word Remote Code Execution Vulnerability | |||||||
| %%cve:2026-58651%% | No | No | - | - | Important | 7.8 | 6.8 |
| Power BI Remote Code Execution Vulnerability | |||||||
| %%cve:2026-65811%% | No | No | - | - | Important | 8.8 | 7.7 |
| PowerShell Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-59119%% | No | No | - | - | Important | 7.3 | 6.4 |
| PowerShell Information Disclosure Vulnerability | |||||||
| %%cve:2026-58612%% | No | No | - | - | Important | 7.4 | 6.4 |
| Powerpoint Information Disclosure Vulnerability | |||||||
| %%cve:2026-68809%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70312%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70316%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70325%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70320%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-70322%% | No | No | - | - | Important | 5.5 | 4.8 |
| RPC Runtime Library Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62781%% | No | No | - | - | Important | 8.1 | 7.1 |
| Remote Access API Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65671%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65672%% | No | No | - | - | Important | 7.8 | 6.8 |
| Remote Access Management service/API (RPC server) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-42976%% | No | No | - | - | Important | 7.8 | 6.8 |
| Remote Desktop Client Remote Code Execution Vulnerability | |||||||
| %%cve:2026-59134%% | No | No | - | - | Important | 7.5 | 6.5 |
| %%cve:2026-61352%% | No | No | - | - | Important | 7.5 | 6.5 |
| %%cve:2026-61363%% | No | No | - | - | Important | 7.5 | 6.5 |
| %%cve:2026-62824%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Remote Procedure Call Denial of Service Vulnerability | |||||||
| %%cve:2026-54113%% | No | No | - | - | Important | 7.5 | 6.5 |
| Virtual Hard Disk (VHD) Miniport Driver Elevation of Privilege Vulernability | |||||||
| %%cve:2026-59125%% | No | No | - | - | Important | 7.0 | 6.1 |
| Visual Studio Code Information Disclosure Vulnerability | |||||||
| %%cve:2026-47285%% | No | No | - | - | Important | 6.5 | 5.7 |
| Visual Studio Code Python Extension Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-54981%% | No | No | - | - | Important | 7.8 | 6.8 |
| Visual Studio Code Remote Code Execution Vulnerability | |||||||
| %%cve:2026-59113%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-69320%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-70336%% | No | No | - | - | Important | 8.8 | 7.7 |
| Visual Studio Code Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-58650%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-69278%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-69306%% | No | No | - | - | Important | 8.2 | 7.1 |
| Win32k Information Disclosure Vulnerability | |||||||
| %%cve:2026-62746%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62798%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62743%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62786%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Accessibility Infrastructure (ATBroker.exe) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61358%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Active Directory Certificate Services (AD CS) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62818%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Windows Active Directory Domain Services Remote Code Execution Vulnerability | |||||||
| %%cve:2026-49179%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61348%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-68820%% | No | Yes | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-70307%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Autopilot Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-65783%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65779%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65780%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65778%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65782%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65781%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Backup Engine Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62908%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Bind Filter Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61927%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-61934%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62705%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62722%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62713%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62771%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Common Log File System Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62728%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Container Isolation FS Filter Driver (unionfs.sys) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62772%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Container Isolation FS Filter Driver (unionfs.sys) Information Disclosure Vulnerability | |||||||
| %%cve:2026-62775%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Container Isolation FS Filter Driver (unionfs.sys) Tampering Vulnerability | |||||||
| %%cve:2026-72971%% | Yes | No | - | - | Important | 5.5 | 4.8 |
| Windows DHCP Client Denial of Service Vulnerability | |||||||
| %%cve:2026-65785%% | No | No | - | - | Important | 6.5 | 5.7 |
| Windows DHCP Client Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62755%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62736%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows DHCP Client Remote Code Execution Vulnerability | |||||||
| %%cve:2026-61361%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows DHCP Server Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62812%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62761%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62776%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62803%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62807%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows DHCP Server Information Disclosure Vulnerability | |||||||
| %%cve:2026-62718%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62715%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62716%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62742%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62745%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62720%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62714%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-62814%% | No | No | - | - | Important | 6.5 | 5.7 |
| Windows DHCP Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62823%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Windows DNS Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-70304%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-70330%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-62769%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-62778%% | No | No | - | - | Important | 8.1 | 7.1 |
| %%cve:2026-62881%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-62883%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-65795%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-65797%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-65799%% | No | No | - | - | Important | 6.7 | 5.8 |
| %%cve:2026-65798%% | No | No | - | - | Important | 6.7 | 5.8 |
| Windows DNS Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62787%% | No | No | - | - | Important | 7.5 | 6.5 |
| %%cve:2026-62817%% | No | No | - | - | Critical | 8.8 | 7.7 |
| %%cve:2026-62820%% | No | No | - | - | Critical | 8.1 | 7.1 |
| %%cve:2026-62878%% | No | No | - | - | Critical | 9.8 | 8.5 |
| %%cve:2026-65789%% | No | No | - | - | Critical | 8.1 | 7.1 |
| %%cve:2026-61920%% | No | No | - | - | Important | 6.6 | 5.8 |
| Windows DWM Core Library Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61932%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62894%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62888%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows DWM Core Library Information Disclosure Vulnerability | |||||||
| %%cve:2026-61933%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62703%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Defender Firewall Service Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-61936%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Deployment Services TFTP Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62893%% | No | No | - | - | Critical | 9.8 | 8.5 |
| Windows Device Association Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62747%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62710%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Device Health Attestation (DHA) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-66802%% | No | No | - | - | Critical | 8.1 | 7.1 |
| %%cve:2026-71331%% | No | No | - | - | Critical | 8.1 | 7.1 |
| Windows Display Enhancement Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61923%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Encrypting File System (EFS) Information Disclosure Vulnerability | |||||||
| %%cve:2026-59128%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Event Logging Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-59126%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Event Logging Service Information Disclosure Vulnerability | |||||||
| %%cve:2026-59137%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-61347%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows GDI Information Disclosure Vulnerability | |||||||
| %%cve:2026-65662%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-61360%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows GDI+ Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62890%% | No | No | - | - | Critical | 7.8 | 6.8 |
| Windows GDI+ Information Disclosure Vulnerability | |||||||
| %%cve:2026-62709%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows GDI+ Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62822%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Windows Graphics Kernel Denial of Service Vulnerability | |||||||
| %%cve:2026-62702%% | No | No | - | - | Important | 6.8 | 5.9 |
| Windows Graphics Kernel Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61346%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62774%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows HTTP Protocol Stack Tampering Vulnerability | |||||||
| %%cve:2026-62750%% | No | No | - | - | Important | 6.5 | 5.7 |
| Windows HTTP.sys Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61937%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62753%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62735%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62739%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62741%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62811%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Hello Tampering Vulnerability | |||||||
| %%cve:2026-61928%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Hyper-V Information Disclosure Vulnerability | |||||||
| %%cve:2026-61368%% | No | No | - | - | Important | 5.0 | 4.4 |
| Windows Imaging Component Information Disclosure Vulnerability | |||||||
| %%cve:2026-62740%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Imaging Component Remote Code Execution Vulnerability | |||||||
| %%cve:2026-54984%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Installer Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-59127%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61925%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-70344%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-70345%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-70346%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-70347%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61938%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62768%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65774%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Kerberos Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62754%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62766%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62773%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62752%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Kernel Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61930%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62737%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61929%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62708%% | No | No | - | - | Important | 6.4 | 5.6 |
| %%cve:2026-62749%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62780%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62788%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-65773%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Key Guard Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-66799%% | No | No | - | - | Critical | 7.8 | 6.8 |
| Windows LDAP - Lightweight Directory Access Protocol Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62785%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-62795%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows LUA File Virtualization Filter Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-50472%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows License Manager Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62777%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows MIDI Service Module Elevation of Privileges Vulnerability | |||||||
| %%cve:2026-62688%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62693%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Management Instrumentation Information Disclosure Vulnerability | |||||||
| %%cve:2026-62738%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Management Services Denial of Service Vulnerability | |||||||
| %%cve:2026-70348%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Message Queuing Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62719%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62717%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65790%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Modern Device Management (MDM) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62707%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows NTFS Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62797%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62700%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62880%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows NTFS Information Disclosure Vulnerability | |||||||
| %%cve:2026-61350%% | No | No | - | - | Important | 4.6 | 4.0 |
| %%cve:2026-62796%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-65784%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62793%% | No | No | - | - | Important | 5.5 | 4.8 |
| %%cve:2026-62887%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Narrator Braille Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-56174%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Network Address Translation (NAT) Spoofing Vulnerability | |||||||
| %%cve:2026-56179%% | No | No | - | - | Moderate | 8.3 | 7.2 |
| Windows Network Connection Broker Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61366%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Network File System Denial of Service Vulnerability | |||||||
| %%cve:2026-68819%% | No | No | - | - | Important | 5.9 | 5.2 |
| Windows Package Manager Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-68821%% | No | No | - | - | Important | 7.3 | 6.4 |
| Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62696%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Projected File System Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62751%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Push Notifications Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62690%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62816%% | No | No | - | - | Critical | 8.8 | 7.7 |
| Windows Remote Access Connection Manager Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62783%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62758%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Remote Desktop Client Information Disclosure Vulnerability | |||||||
| %%cve:2026-61924%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-61918%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-61921%% | No | No | - | - | Important | 6.5 | 5.7 |
| Windows Remote Desktop Services Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61356%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61367%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62692%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61364%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61365%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62819%% | No | No | - | - | Critical | 8.1 | 7.1 |
| Windows SMB Client Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62799%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows SMB Client Information Disclosure Vulnerability | |||||||
| %%cve:2026-62782%% | No | No | - | - | Important | 6.5 | 5.7 |
| %%cve:2026-65794%% | No | No | - | - | Important | 6.5 | 5.7 |
| Windows SMBv3 Server Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62800%% | No | No | - | - | Important | 8.8 | 7.7 |
| %%cve:2026-62790%% | No | No | - | - | Important | 8.8 | 7.7 |
| Windows Schannel Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62779%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Schannel Security Feature Bypass Vulnerability | |||||||
| %%cve:2026-62757%% | No | No | - | - | Important | 5.3 | 4.6 |
| Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62889%% | No | No | - | - | Critical | 8.1 | 7.1 |
| Windows Sensor Data Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61355%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Shell Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62770%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Storage Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62695%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-61359%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows TCP/IP Denial of Service Vulnerability | |||||||
| %%cve:2026-59132%% | No | No | - | - | Important | 7.5 | 6.5 |
| Windows TCP/IP Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62792%% | No | No | - | - | Important | 8.1 | 7.1 |
| Windows Telephony Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61353%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62723%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62724%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62748%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62729%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-59122%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62701%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62725%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62726%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62732%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62734%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows USB Driver Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61926%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Universal Disk Format File System Driver (UDFS) Remote Code Execution Vulnerability | |||||||
| %%cve:2026-62699%% | No | No | - | - | Important | 6.8 | 5.9 |
| Windows User Profile Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62832%% | Yes | No | - | - | Important | 7.8 | 6.8 |
| Windows User-Mode Power Service (UMPS) Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62721%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows Win32k Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-62712%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62876%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62877%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65678%% | No | No | - | - | Important | 7.0 | 6.1 |
| %%cve:2026-62711%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62733%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-62885%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65775%% | No | No | - | - | Important | 7.8 | 6.8 |
| %%cve:2026-65776%% | No | No | - | - | Important | 7.0 | 6.1 |
| Windows Wired AutoConfig Service Information Disclosure Vulnerability | |||||||
| %%cve:2026-62730%% | No | No | - | - | Important | 5.5 | 4.8 |
| Windows Work Folder Service Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61349%% | No | No | - | - | Important | 7.8 | 6.8 |
| Windows iSCSI Target Service Denial of Service Vulnerability | |||||||
| %%cve:2026-65681%% | No | No | - | - | Important | 7.5 | 6.5 |
| %%cve:2026-65796%% | No | No | - | - | Important | 5.9 | 5.2 |
| Windows iSCSI Target Service Remote Code Execution Vulnerability | |||||||
| %%cve:2026-65679%% | No | No | - | - | Important | 8.1 | 7.1 |
| %%cve:2026-65791%% | No | No | - | - | Critical | 9.8 | 8.5 |
| Winlogon Elevation of Privilege Vulnerability | |||||||
| %%cve:2026-61939%% | No | No | - | - | Important | 7.0 | 6.1 |
Solana is a crypto platform known for speed. Developers like it to develop distributed applications or to implement crypto payments. To interact with the blockchain, APIs are provided for developers. These APIs will either "speak" JSON or gRPC. One implementation often used for development is "surfpool," which is used to test programs before deploying them to a Solana network.
The requests that we are observing right now look like:
POST /solana HTTP/1.1
Host: [redacted]
User-Agent: HelloScan/1.0
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 45
{"jsonrpc":"2.0","id":1,"method":"getHealth"}
A typical response from Surfpool to this request:
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
content-length: 39
date: Mon, 10 Aug 2026 15:20:54 GMT
{"jsonrpc":"2.0","result":"ok","id":1}
A classical fingerprint request of someone attempting to enumerate Solana API endpoints. The "/solana" path is not required and should just be ignored. Usually, the API listens on port 8899, a port our honeypots are not listening on. The requests we are seeing are going to port 80. But they are likely assuming some form of proxy (for example an API gateway) that will map /solana to the backend API.
Other payloads that were used:
{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}
???????{"jsonrpc":"2.0","id":1,"method":"getVersion"}
The same scanner hitting the "/solana" endpoint also scans for "/jsonrpc", "/rpc", "/v1" and '/' which could possibly be related. It also looks for a few URLs associated with credentials (for example,/.env, /.env.bak /.env.local, and others)
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
UNIX systems (including Linux) are well-known to record a lot of activities in many different locations. But there is one domain where they definitely lack of "modern" logging: shells. Most shells provide an historization of the typed commands through a flat file in the $HOME directory (ex: $HOME/.bash_history). They suffer of multiple problems:
Note that if you use sudo to switch to another user (usually root), events are sent to the classic logging mechanism (syslog or journal):
Aug 05 15:30:48 lab0 sudo[211956]: xavier : TTY=pts/1 ; PWD=/tmp ; USER=root ; COMMAND=/usr/bin/whoami
To search across the history, the shell user can use the “reverse-i-search” feature available in Bash (but also other shells). This is the built-in incremental search through your command history, bound to CTRL-R. You hit it, start typing part of a command you ran before, and bash walks backwards through history showing the most recent match as you type — hence "reverse" (newest-first) and "i" for incremental (it updates on every keystroke).
xavier@lab0:~$ (reverse-i-search)`grep': dpkg -l | grep curl
It’s nice but, again, limited!
There are tools that expand the power of reverse-i-search and the shell history by storing everything into a database. One that became popular is called “Atuin”[1].
It enhances your shell history with a SQLite database, and records extra context for every command:
Even better, it can also sync your history across all of your machines, end-to-end encrypted. The official Atuin server can be used but, of course, it’s possible to deploy your own server (that's what I do in my infrastructure). From a forensic point of view, this tool is both a gift and a trap for the investigator. If you don’t know that Atuin is used, you’ll maybe loose lot of evidences. But if you spot it, it’s for sure a win!
First step to check: Where the artifacts live?
Atuin follows XDG paths[2], so check every user's home directory plus root (per-user install):
| File | Purpose |
|---|---|
| ~/.local/share/atuin/history.db | Primary evidence (SQLite) |
| ~/.local/share/atuin/history.db-wal | Uncommitted records (DO NOT MISS) |
| ~/.local/share/atuin/history.db-shm | |
| ~/.local/share/atuin/key | E2E sync encryption key |
| ~/.local/share/atuin/session | Server session token (API bearer) |
| ~/.config/atuin/config.toml | Config: sync target, filters, custom paths |
Do not assume the default location. The config location can be overridden with $ATUIN_CONFIG_DIR, and the database, key, and session paths are all individually configurable in config.toml. It's recommended to read the config first.
Atuin must be enable at shell level (for every shell, every user). Search for proof-of-activation in the shell RC files:
xavier@lab0:~$ grep atuin $HOME/.bashrc . "$HOME/.atuin/bin/env" eval "$(atuin init bash)"
Second step: Build your timeline
Forensicators love timelines! The main DB table is called “history”:
xavier@lab0:~$ sqlite3 history.db
SQLite version 3.46.1 2024-08-13 09:16:08
Enter ".help" for usage hints.
sqlite> .schema history
CREATE TABLE history (
id text primary key,
timestamp integer not null,
duration integer not null,
exit integer not null,
command text not null,
cwd text not null,
session text not null,
hostname text not null, deleted_at integer, author text, intent text, shell text,
unique(timestamp, cwd, command)
);
CREATE INDEX idx_history_timestamp on history(timestamp);
CREATE INDEX idx_history_command_timestamp on history(
command,
timestamp
);
CREATE INDEX idx_history_active_timestamp on history(timestamp)
where deleted_at is null;
CREATE INDEX idx_history_session_timestamp on history(session, timestamp)
where deleted_at is null;
CREATE INDEX idx_history_cwd_timestamp on history(cwd, timestamp)
where deleted_at is null;
CREATE INDEX idx_history_hostname_timestamp on history(lower(hostname), timestamp)
where deleted_at is null;
sqlite>
The id is a client-generated identifier used for syncing, and deleted_at is a soft-delete marker.
Compared to .bash_history this gives you, per command:
Triage query, read-only:
xavier@lab0:~$ sqlite3 "file:history.db?mode=ro&immutable=1" \
"SELECT datetime(timestamp/1000000000,'unixepoch') AS utc,
hostname, session, cwd, exit, command
FROM history ORDER BY timestamp;" | grep lab0 | head -5
2026-08-05 16:21:05|lab0:xavier|019fd2ba42c7779284d508825c4b2bd4|/home/xavier|0|vi .bashrc
2026-08-05 16:21:16|lab0:xavier|019fd2ba42c7779284d508825c4b2bd4|/home/xavier|0|cat $HOME/.atuin/bin/env
2026-08-05 16:22:53|lab0:xavier|019fd2bc13b174c094100175e489ade5|/home/xavier|0|byobu
2026-08-05 16:22:58|lab0:xavier|019fd2bc264c799196071edfbfe9d452|/home/xavier|0|ll
2026-08-05 16:23:11|lab0:xavier|019fd2bc264c799196071edfbfe9d452|/home/xavier|0|cd footprint
Interesting tips to keep in mind during investigations:
Next step, investigate deleted and residual data:
The "soft-delete" design works is a goldmine: rows deleted via Atuin are marked with "deleted_at" rather than physically purged in many cases. Try to use "WHERE deleted_at IS NOT NULL" to recover "deleted" activity. Standard SQLite carving applies: freelist/unallocated pages and the WAL can hold prior row versions and dropped records (undark, bring2lite, or manual page carving).
A good news, the standard flat history file (~/.bash_history or ~/.zsh_history) is still written alongside Atuin, so cross-reference it.
Finally, don't forget the "sync" feature:
Check the configuration file, if "auto_sync = true" and the user is logged in, history is end-to-end encrypted and pushed to a server (by default: https://api.atuin.sh). If you are authenticated and have the E2E encryption key, history may be pullable back from the server. But a self-hosted server can be used. In this case, more evidences can be found on this server but raw data will also be encrypted.
A final note: The configuration file allows to specify commands that will never be recorded:
## prevent commands matching any of these regexes from being written to history. ## Note that these regular expressions are unanchored, i.e. if they don't start ## with ^ or end with $, they'll match anywhere in the command. ## For details on the supported regular expression syntax, see ## https://docs.rs/regex/latest/regex/#syntax # history_filter = [ # "^secret-cmd", # "^innocuous-cmd .*--secret=.+", # ] ## prevent commands run with cwd matching any of these regexes from being written ## to history. Note that these regular expressions are unanchored, i.e. if they don't ## start with ^ or end with $, they'll match anywhere in CWD. ## For details on the supported regular expression syntax, see ## https://docs.rs/regex/latest/regex/#syntax # cwd_filter = [ # "^/very/secret/area", # ]
Absence of a command in the database is therefore not evidence it wasn't run. Other gaps: non-interactive shells and scripts (no init hook = no capture), and commands in a sh session without the hook.
[1] https://docs.atuin.sh/latest/
[2] https://specifications.freedesktop.org/basedir/latest/
Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key
[This is a Guest Diary by Daryl Jiminez, an ISC intern as part of the SANS.edu BACS program]
Introduction
On May 23, 2026, a threat actor successfully authenticated to my Cowrie SSH honeypot using compromised credentials and, within 22 seconds, injected a backdoor SSH key, changed the root password, attempted to clear host-based access restrictions, and performed automated system reconnaissance. The speed and consistency of the behavior left no room for doubt: this was not a human attacker manually working through a system. This was automated post-exploitation infrastructure executing a pre-scripted playbook the instant it found an open door.
This post documents that intrusion, the broader campaign it belongs to, and what defenders can do about it. The data comes from a self-managed Raspberry Pi 5 honeypot running Cowrie, operating continuously since April 2026 as part of my SANS Internet Storm Center internship. Over the 30-day monitoring period analyzed here, the sensor captured over 112,000 SSH sessions and 72,000+ authentication attempts from 175+ unique malicious source IPs.
The Sensor and Setup
The honeypot runs Cowrie v2.3.0 on a Raspberry Pi 5 with a residential internet connection. Cowrie simulates an SSH server that accepts connections on port 2222 (forwarded from external port 22), logs all attacker activity including commands, file transfers, and credentials, and submits data automatically to ISC DShield. The sensor's logs are archived daily and analyzed for attacker TTPs, campaign patterns, and threat intelligence value.
All data referenced in this post was extracted from raw JSON Cowrie logs using jq queries and cross-referenced against AbuseIPDB, VirusTotal, GreyNoise, ISC DShield, AlienVault OTX, Shodan, and Whois.
The Intrusion: 22 Seconds From Login to Persistence
At 01:06:43 UTC on May 23, 2026, source IP 163.7.8.79 initiated an SSH connection to the honeypot. One second later, the actor successfully authenticated using the credentials root / Aa123123123, a weak password consistent with credentials leaked in past data breaches and commonly cycled through automated attack tools.
What happened next is best understood through the session timeline:
Session Timeline — 163.7.8.79 — May 23, 2026
The SSH key injected into authorized_keys was captured by Cowrie with the following hash:
a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
The actor also removed the existing .ssh directory and recreated it before injecting the key, a technique used to eliminate existing authorized keys and ensure exclusive backdoor access. Changing the root password immediately after key injection further locks out legitimate administrators. Clearing /etc/hosts.deny removes any host-based access restrictions that might block future connections from the actor's infrastructure.
The entire sequence executed in 22 seconds. There was no hesitation, no exploration, no human decision-making visible in the command pattern. This is automation: a pre-scripted playbook executing the moment authentication succeeded.
The Attacker Kept Coming Back
After reviewing the full May 23 logs, I found that 163.7.8.79 returned to the sensor multiple times throughout the day, reconnecting approximately every few minutes and executing the same automated command sequence on each successful session. The consistency across sessions, identical command order, identical timing patterns, identical SSH key material, confirms this is not a human operator adapting to findings but an automated tool running a fixed exploitation script.
When I queried the logs for all successful authentications on May 23, I found 21 successful logins from 21 different source IPs within a single 24-hour period. The logins were clustered heavily between 01:00 and 02:30 UTC, suggesting coordinated wave-based scanning rather than independent actors discovering the honeypot randomly. A sample of the credentials used shows the breadth of the wordlists being deployed:
The presence of 'minecraft / 12345' is particularly noteworthy. Someone compiled a wordlist that includes gaming server default credentials, indicating active scanning for Minecraft or similar game server installations, not just generic Linux systems.
The Campaign Is Not Isolated and Has Not Stopped
To understand whether this was a one-time event or part of a sustained campaign, I cross-referenced the full list of IPs my sensor had observed over 30+ days of operation against a compiled list of IPs associated with the mdrfckr SSH campaign, a persistent automated SSH scanning operation that has been documented across multiple honeypot operators worldwide.
The result: 93 IPs from the mdrfckr campaign list were still actively hitting my sensor weeks after first being documented. This is not a historical observation. These actors did not stop. The campaign has been running continuously throughout the monitoring period.
Additionally, analysis of the top connecting IPs by session volume revealed a coordinated subnet cluster:
80.94.92.184 — high volume connections
80.94.92.186 — high volume connections
80.94.92.171 — high volume connections
Three IPs from the same /24 subnet hitting the sensor simultaneously is not coincidence. This is coordinated scanning infrastructure, either a botnet or a distributed scanning platform, operating multiple nodes from the same network block to maximize coverage while distributing the load.
Threat Intelligence on 163.7.8.79
Cross-referencing the primary actor IP across multiple threat intelligence platforms confirmed its malicious reputation:
AbuseIPDB: 100% confidence of abuse, over 5,700 reported incidents primarily related to SSH brute-force attacks, with recent reports confirming continued active scanning activity.
VirusTotal: Multiple security vendors classify the IP as malicious or suspicious.
GreyNoise: Identified as part of internet-wide SSH brute-force and reconnaissance scanning activity, confirming this is not a targeted attack but systematic exploitation of any reachable vulnerable host.
Whois: The IP is associated with Byteplus infrastructure (AS150436), a cloud hosting provider, consistent with the pattern of actors using cloud resources to scale automated attack campaigns.
MITRE ATT&CK Mapping
T1078 — Valid Accounts: Actor authenticated using compromised credentials from a wordlist.
T1098 — Account Manipulation: Malicious SSH key injected into authorized_keys to establish persistent access.
T1059 — Command Execution: Multiple shell commands executed immediately following authentication.
T1562 — Impair Defenses: /etc/hosts.deny cleared and processes terminated to remove access restrictions.
Why This Matters
The 22-second compromise window is the most important takeaway from this observation. In the time it takes a human to notice an alert, review it, and begin investigation, a fully automated actor has already established a persistent backdoor, locked out legitimate administrators, and completed system reconnaissance. On a real system with no monitoring, the attack would be invisible until the damage was done.
The credential root / Aa123123123 is not sophisticated. It follows a simple pattern: a common word plus repeating numbers plus a capital letter. Millions of systems remain accessible with credentials exactly like this, whether because they were provisioned with weak defaults, never hardened, or left unchanged after initial setup. The actors hitting your honeypot are not targeting you specifically. They are sweeping the internet for anyone who left a door unlocked.
The sustained nature of this campaign, 93 returning IPs still active weeks after first documented observation, reinforces that these actors are not deterred by a single failed attempt. They keep scanning. They keep trying. The math works in their favor when millions of internet-connected systems are in scope.
Who Benefits From This Information
System administrators who are responsible for any internet-exposed Linux system. If your system is reachable on port 22 with password authentication enabled, you are in scope for this campaign right now.
Security operations teams monitoring SSH authentication events. The behavioral signatures documented here, automated command sequences executing within seconds of authentication, consistent credential patterns, recurring source IPs, are detectable with proper log monitoring and should be included in detection rule sets.
Threat intelligence analysts tracking automated SSH campaigns. The mdrfckr campaign correlation data and the coordinated subnet cluster observations contribute to the shared picture of this ongoing threat.
Recommendations (MITRE Mitigations)
M1027 — Password Policies: Enforce strong passwords across all accounts. The credentials used in this campaign, including Aa123123123, follow predictable patterns that password complexity requirements would eliminate. Eliminate default credentials entirely.
M1036 — Account Use Policies: Implement rate limiting and account lockout for SSH authentication failures. Tools like fail2ban can automatically block IPs after repeated failed attempts, dramatically reducing the attack surface for automated scanners.
M1042 — Disable or Remove Feature: Disable SSH password authentication entirely and require public key authentication only. This single configuration change renders the entire credential stuffing attack class ineffective regardless of wordlist quality or campaign scale.
M1030 — Network Segmentation: Restrict SSH access to trusted IP ranges or VPN connections only. Internet-exposed SSH on port 22 is an open invitation to this class of automated attack.
M1047 — Audit: Monitor authentication logs continuously. The behavioral pattern of automated post-exploitation, rapid command sequences executing within seconds of login, is highly detectable with proper alerting in place.
Indicators of Compromise
IP: 163.7.8.79 (Byteplus, AS150436) — primary actor
Credentials: root / Aa123123123
SSH Key Hash: a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
Associated Campaign: mdrfckr SSH campaign (93 confirmed overlapping IPs)
Conclusion
Automated SSH credential stuffing is not a sophisticated attack. It requires no novel exploits, no zero-days, and no targeted intelligence. It requires only an internet-connected system with weak credentials and no rate limiting. The 22-second compromise timeline documented here shows that the window between successful authentication and full backdoor establishment is too short for human response alone. Detection and prevention must be configured before the attack arrives, not after.
The campaign documented here has not stopped. The same infrastructure continues to scan, the same credential lists continue to be deployed, and the same post-exploitation playbook continues to execute the instant a weak system is found. The defenders who have hardened their SSH configuration are invisible to this campaign. The ones who have not are being hit right now.
[1] ISC DShield: https://isc.sans.edu/ipinfo/163.7.8.79
[2] AbuseIPDB: https://www.abuseipdb.com/check/163.7.8.79
[3] VirusTotal: https://www.virustotal.com/gui/ip-address/163.7.8.79
[4] GreyNoise: https://viz.greynoise.io/ip/163.7.8.79
[5] AlienVault OTX: https://otx.alienvault.com/indicator/ip/163.7.8.79
[6] Whois: https://whois.domaintools.com/163.7.8.79
[7] MITRE ATT&CK T1078: https://attack.mitre.org/techniques/T1078/
[8] MITRE ATT&CK T1098: https://attack.mitre.org/techniques/T1098/
[9] MITRE ATT&CK T1059: https://attack.mitre.org/techniques/T1059/
[10] MITRE ATT&CK T1562: https://attack.mitre.org/techniques/T1562/
[11] fail2ban: https://en.wikipedia.org/wiki/Fail2ban
[12] https://www.sans.edu/cyber-security-programs/bachelors-degree/
Note: This blog post was produced with the assistance of Claude (Anthropic) as a writing and organizational tool. All analysis, log data, threat intelligence findings, and conclusions are my own.
-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
When you learn that a compromised package executed on one of your build hosts, muscle memory takes over: revoke the npm token, rotate the GitHub PAT, cycle the cloud keys. That reflex has been correct in almost every supply-chain incident I have worked. In the keyv/cacheable compromise that has been unfolding since yesterday, it is the one thing you should not do first — because revoking the stolen token is exactly what arms the payload.
Let me back up.
What happened
On August 4, 2026, an attacker took over the maintainer account behind the widely used keyv and cacheable npm namespaces — caching libraries that sit near the bottom of a very large number of dependency trees — and published trojanized releases. Socket's Threat Research team, which did the primary analysis, places the first malicious release, keyv@6.0.0, at 09:35 UTC. The poisoned versions ship a preinstall hook:
"scripts": { "preinstall": "node setup.mjs" }
setup.mjs downloads a standalone Bun runtime, runs an obfuscated second stage (Math_Symbol.js, ~728 KB), and harvests whatever it can reach: AWS instance metadata, cloud keys, Vault tokens, Kubernetes service-account tokens, GitHub Actions secrets, npm tokens, plus a generic regex sweep for private keys and bearer tokens on disk. Then — and this is why the campaign grew from roughly ten packages to several hundred within hours — it uses the stolen npm token to inject the same hook into other packages the compromised identity can publish, recomputes the integrity hashes, and republishes. It is a worm. The public IOC lists now cover more than 440 packages across two thousand-plus versions, and they are still moving.
Two properties make this one worth a closer look than the average typosquat.
It does not need npm install
Most teams scope this kind of incident to "who ran npm install in the exposure window." That misses half the population. The source repository also received IDE and agent autostart hooks — a SessionStart entry in .claude/settings.json and a folderOpen task in .vscode/tasks.json — that run the loader when the cloned folder is simply opened. No install, nothing built.
Sit with who that includes. It includes the security engineer who cloned the repository to investigate the incident after reading about it. It includes the AI coding agent that opened the directory to "take a look." I do not think we have seen AI-agent configuration files used as a first-class supply-chain execution vector at this scale before, and it is worth internalizing: a checked-out repository is now an execution surface, and .claude/, .cursor/, and .vscode/ are part of it.
It punishes remediation
Here is the part that should change how you respond. Alongside the credential theft, the payload installs a host-level dead-man's switch. It writes the stolen GitHub token and an attacker-supplied handler command to ~/.config/gh-token-monitor/, then persists itself as a macOS LaunchAgent or a Linux systemd user service with loginctl enable-linger so it survives logout. The systemd unit describes itself, helpfully, as a "GitHub Token Validity Monitor," so at a glance it reads like a developer convenience.
A watcher script polls the GitHub API with the stolen token every 60 seconds. While the token works, nothing happens. The moment the token stops working — an HTTP 4xx, which is precisely what your revocation produces — it evals the remote-supplied handler string, then deletes its own state and exits. It is single-shot and self-clearing, and it also self-destructs after a 24-hour TTL.
What is in the handler? Public analysis cannot say, because it is attacker-controlled text pulled at runtime and can be changed remotely. It could be data destruction, re-implant, or nothing at all. That is the whole problem: the risk is not that the trap does something specific and known — it is that you cannot assess it, and it fires at the exact moment your team believes it is containing the incident and starts to relax.
One consequence is counterintuitive but load-bearing: isolating the host from the network is safe. With no connectivity there is no HTTP response, so there is no 4xx, so the switch does not fire — and exfiltration stops at the same time. Isolate first. Do not power off; volatile memory is evidence.
Why the usual checks miss it
keyv@6.0.0 shipped with a passing SLSA attestation. Provenance attests to build integrity, not source integrity — the legitimate workflow faithfully built already-trojanized code.package.json and two added files. A dist/ comparison shows nothing.eslint → file-entry-cache → flat-cache → keyv. Very few victims installed any of these directly.npm install." See the second section.What to actually do
The order matters more than the individual steps:
~/.config/gh-token-monitor/{handler,token,started_at}, the payloads, the plist/unit, and record hashes. Do not execute the handler; treat it as inert text. started_at bounds your exposure window.loginctl linger, remove the files and the .claude/.vscode hooks, and clear the package caches.started_at window.CI runners and any host with confirmed execution should be rebuilt, not cleaned. Arbitrary code ran; the list of known artifacts is not a completeness guarantee.
A small tool to help with the triage
Enumerating this by hand across a fleet is tedious, and the moving IOC list makes a hardcoded grep obsolete within hours. I wrote a scanner to help with the triage: it checks lockfiles and node_modules for the compromised name/version set (with the transitive chain, so "we don't use keyv" gets answered on the spot), flags the host persistence and the dead-man's switch, and prints the response order above so nobody rotates before cleaning.
It is built to be easy to trust during exactly this kind of incident: one auditable file you can read in fifteen minutes, zero dependencies, zero egress (it never phones home; --update is the only network call and it is explicit), and read-only. It runs offline. It is MIT-licensed and open source, and — disclosure — it comes out of my work at Securest8; the IOC data is not mine but the public research of Socket, Wiz, and Kodem, credited in the repository.
If you only take the tool, take the response order with it. The scanner finds the problem; the order in which you touch credentials is what keeps a bad day from getting worse.
Bottom line
The novel part of this campaign is not the credential theft — it is the two design choices around it: an execution path that does not require installing anything, and a switch that turns your remediation reflex into the trigger. Scope the second vector, isolate before you revoke, and clean the host before you touch a single token.
References
- Socket, "Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack," August 4, 2026. https://socket.dev/blog/popular-npm-packages-in-the-keyv-and-cacheable-namespaces-compromised-in-active-supply-chain
- Wiz Research, public IOC feed (keyv/cacheable). https://github.com/wiz-sec-public/wiz-research-iocs/blob/main/reports/keyv-packages.csv
- Wiz, "keyv and cacheable npm supply chain attack." https://www.wiz.io/blog/keyv-and-cacheable-npm-supply-chain-attack
- Kodem Security, keyv supply-chain attack IOCs and first-hour runbook. https://www.kodemsecurity.com/resources/keyv-supply-chain-attack-shai-hulud-npm-worm-affected-versions-iocs-and-first-hour-response-runbook
--
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.This morning, I noticed specific sources "hunting" for vulnerabilities in URLs that I haven't noticed before. All of these URLs appear to be associated with diagnostic tools:
| URL | Count | Vulnerability |
|---|---|---|
| / | 1 | (simple recon for index page) |
| /apply.cgi | 20 | CVE-2024-12856 Four-Faith router command injection |
| /cgi-bin/adv_ping.cgi | 20 | ? |
| /cgi-bin/diagnostic.cgi | 20 | CVE-2013-7179 Seowon Intech WiMAX SWU-9100 mobile route |
| /cgi-bin/DiagnosticsMsg.cgi | 20 | ? |
| /cgi-bin/ping.cgi | 20 | |
| /cgi-bin/system_mgr.cgi | 20 | |
| /cgi-bin/traceroute.cgi | 20 | |
| /diag_ping.cgi | 20 | CVE-2020-8949 (maybe.. slightly different URL) Gocloud devices |
| /goform/diagTool | 20 | CVE-2024-48419 (maybe..) Edimax Routers |
| /goform/ping | 20 | |
| /ping_test.cgi | 20 | |
| /sys_diag.html | 20 |
The naming of these URLs points to diagnostic tools. I was unable to find any specific vulnerabilities associated with many of the URLs, but the table above reflects those I found. But diagnostic tools often suffer from file inclusion and code execution vulnerabilities.
These tools will often call operating system commands directly, without properly separating user-provided arguments. Here is a sample vulnerability in a ping utility:
response = os.system("ping -c 1 -w2 " + hostname )
The above example is in Python. But most (all?) languages have something equivalent to "os.system" (often called "exec", "shell_exec", "process" ...) Often, proper input validation and output encoding are used to prevent this vulnerability, but, in my opinion, there is a better approach that should always be used in addition to input validation, and I do not see it used much.
As with many other vulnerabilities, the root cause of command injection is the concatenation of user data and commands. Mixing control plane and data plane has been an issue since blue boxing and continues today with prompt injection. The real fix is to avoid this comingling of data and commands and instead properly separate them. Prepared statements in SQL are probably the best-known approach following this principle.
For OS command execution, we do have a very similar solution. The "system" command in your language will typically call the standard C function "exec" [1]. This family of function implements some meant to pass command line arguments: execv ("exec vector"). In addition to the command, it accepts an array of command-line arguments that are then passed to the command, properly separating the command from the arguments.
Python implements execv as part of the subprocess module:
response = subprocess.run("ping", "-c", 1, "-w", 2, hostname )
Using "subprocess.run" eliminates the possibility of command injection in this example.
For example, if you are using "google.com; ls" as a hostname, you get:
ping: cannot resolve google.com; ls: Unknown host
The entire string "google.com; ls" was used as a hostname, and the ";" no longer acted as a separator. Give it a try with other command injection strings, and you will see similar results.
There are a few cases where "execv" is not sufficient. Some operating system commands may execute additional commands passed on the command line. For example, tcpdump offers the "-z" option to execute a "postrotate command". But these cases are rare, and if you are running into them, you are back to proper input validation to use these specific command line options. In most cases, users cannot specify the command-line option itself but only the parameter; using the "execv" API will help.
A while ago, I also made a brief video with more details on preventing OS command injection: https://www.youtube.com/watch?v=7QDO3pZbum8. It also covers some of the issues around Windows, which implements different APIs.
[1] https://man7.org/linux/man-pages/man3/exec.3.html
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Introduction
This diary provides indicators from an Atomic MacOS (AMOS) stealer infection that I generated in my lab on July 31st, 2026. This was distributed through a web page from getmacouscloud[.]com with instructions to paste text into a macOS Terminal window, supposedly for "macOS toolkit," but instead the text is a command to retrieve and install AMOS stealer malware.
Of note, I ran the text in the Terminal window twice, because I wanted to make sure I retrieved copies of files in the host's /tmp directory before entering the user account password. This is why the initial infection traffic is repeated, and also likely why there are two different directories with the AMOS stealer malware persistent on my infected lab host.
Images from the Infection
Shown above: Website with instructions to copy and paste text into a Terminal window, supposedly for a "macOS toolkit" but actually for malware.
Shown above: The malicious text pasted into a Terminal Window on a macOS host.
Shown above: Files from my infected host's /tmp directory, showing data stolen and other info for AMOS stealer.
Shown above: Examples of AMOS stealer persistent on my infected macOS host.
Shown above: Traffic from the AMOS stealer infection filtered in Wireshark.
Indicators of Compromise
Traffic leading to the getmacouscloud[.]com page on Friday 2026-07-31:
URL from the base64 text provided by getmacouscloud[.]com for the initial download:
URLs from extracted from the payload returned from the initial download:
AMOS stealer C2 traffic - HTTP POST requests over TCP port 80:
AMOS stealer C2 traffic - examples of HTTP GET requests over TCP port 80:
SHA-256 hash: b9ec3261d633c289e51c5fa8842af4350efe68446df39cb995de82e0941d0f3c
SHA-256 hash: 13b868b3ea8b492e7fbab1ca04535c53d0930650185b5a082cd59c1974689cd5
SHA-256 hash: 9f25ec533cb23d020e568fb771500d7776b1300f07119ad9d0876f4329ce22ab
SHA-256 hash: 0a03cf18de28017c0ea591dffc380a6b41fedd2acc3a39e901e58d9188c01836
SHA-256 hash: 01a0d5332b09bb299f7784bf0d0c43c4199269ed6a0712377279eeb999847d20
---
Bradley Duncan
brad [at] malware-traffic-analysis.net
Most phishing campaigns rely on the fact that the victim is afraid to loose "something": money, access to information, ... Many brands have been impersonated by campaigns but I spotted some phishing emails that focus on AI services like ChatGPT.
Yesterday, I found this email that was properly designed but also sent with a very good timing: the end of the month when your classic billing process is restarted!
The threat actor is just trying to grab your payment details:
Seeing the importance of AI used by most companies but also residential users, this is a clever move from threat actors! Many people will be afraid to loose their access to ChatGPT.
Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key
I was asked for help with a problem similar to the following.
Here is a ZIP file, analyzed with zipdump.py:
The filename you see, is in Simplified Chinese:
zipdump.py relies on the zipfile or pyzipper Python modules to parse the given ZIP file, and have the metadata (filenames and comments) decoded correctly.
If this ZIP file would be corrupt or malformed, so that it can not be parsed by these Python modules, then you can still try to use zipdump -f option to locate individual ZIP records:
As I don't know which encoding has been used for the metadata (filenames and comments), I display the filename as a Python byte string and not as a string. If the filename is simple ASCII, it will be readable (like the extension .vir here), but if it is utf-8, for example Simplified Chinese, then you'll just see hexadecimal values.
And that is why I added a new option: --metadata_encoding. With this new option, you can specify a codec, that will be used to convert bytes into strings when option -f is used. Like this:
So here I use codec utf-8, because the filename is encoded in utf-8. How do I know this? Well, in the ZIP specification, the metadata is either ASCII (CP437 to be precise) or UTF-8 encoded. So when you check the flags, you'll know which encoding to use:
Flag 0x0800 means that encoding utf-8 is used. I've also added a feature that decodes the flag bits into readable text, as can be seen in the screenshot above.
If you specify another codec, like latin, for this specific ZIP file, the filenames will be decoded incorrectly:
Option --metadata_encoding can also be used when you don't use option -f, however, module pyzipper does not support this (there's a PR) and in module zipfile the flags take precedence.
Didier Stevens
Senior handler
blog.DidierStevens.com
