Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Today we're announcing the release of Packer v1.16.0, which introduces native support for generating, signing, and verifying SLSA provenance attestations for every image Packer builds. Machine images are the foundation every workload runs on, and a compromised or tampered image can silently propagate to every instance launched from it. Until now, tracking down the origin of a problem meant digging through build logs that may no longer exist. With this release, Packer provides a cryptographic, tamper-evident record of every build without requiring any separate provenance tooling.
This release also ships a handful of HCL2 improvements that make day-to-day template authoring easier.
In this post, we cover the new provenance post-processor, the packer verify-attestation command, SLSA build levels, and the smaller quality-of-life improvements also included in this release.
Why provenance matters for machine images
The SLSA framework (Supply-chain Levels for Software Artifacts) defines progressively stronger guarantees about how software artifacts are produced. Until now, SLSA tooling has largely focused on application packages and containers. Machine images have received less attention than many supply-chain security workflows.
A provenance attestation is a signed, machine-readable statement that records the origin of an artifact. It captures the Git commit the build ran from, the repository and ref it came from, the CI pipeline that triggered the build, and the timestamps for when it ran. For local artifacts, attestation is bound to the SHA-256 digest of the artifact file. For cloud artifacts without local files, Packer derives the attestation subject from a canonical identity record. This record always contains the builder ID and artifact ID, and optionally includes the artifact's registry state (such as an HCP Packer registry URI) when the builder provides it.
Packer generates attestations as in-toto statements carrying an SLSA Provenance v1 predicate. This is the vendor-neutral format that supply-chain security tooling already knows how to consume and verify.
The provenance post-processor
Adding provenance to an existing build requires a few lines of HCL:
build {
source "amazon-ebs" "my-image" { ... }
post-processor "provenance" {
signing_mode = "keyless"
upload_tlog = true
keyless_identity = var.keyless_identity
keyless_oidc_issuer = var.keyless_oidc_issuer
output_dir = "attestations/"
}
}
After the build completes, Packer writes a signed attestation envelope to the attestations/ directory as a plain JSON file. Store it in S3, a container registry, an artifact store, or alongside the artifact itself.
For local artifacts, every attestation captures the artifact name and its SHA-256 digest. For cloud artifactswithout local files, it captures a digest of the canonical artifact identity. It also records available Git and CI metadata, the builder identity, and build timestamps.
Signing modes
We built four options so teams can adopt provenance without overhauling their key management setup first:
Mode
How signing works
Best for
none
Unsigned JSON statement
Getting started; storing in a trusted internal system
key
Local PEM private key
Air-gapped environments; teams with an existing PKI
kms
Cloud KMS or HashiCorp Vault
Production workloads withcentralizedkey management
keyless
Sigstore Fulcio with optionalRekor
GitHubActions and CI pipelines with no long-lived key
<p></p>
For kms mode, the provider is selected automatically from the URI:
Credentials are read from the environment in the standard way for each provider.
SLSA build levels
SLSA defines a ladder of trust rather than a single pass/fail threshold. Here is how each level maps to what Packer provides.
Build L1: Signed provenance exists
Add the provenance post-processor to generate a record that identifies the artifact by digest and describes how it was produced. Signing is optional at L1: signing_mode = “none” writes an unsigned JSON statement. The provenance must be distributed with the artifact to satisfy L1.
Build L2: A hosted service generates and signs the provenance
Run Packer on GitHub Actions or another hosted CI platform and sign using keyless mode. The CI job's OIDC identity becomes the signer, so there are no static credentials to manage or rotate. Upload the attestation to the Rekor public transparency log to add auditable transparency log evidence. A ready-to-use reference workflow is included at examples/ci/github-actions-l2-keyless.yml. This pattern supports L2 only when the hosted build platform and provenance-generation controls meet the SLSA L2 requirements.
Build L3-compatible: Provenance generation is isolated from the build
The build job publishes only the artifact digest. A separate, isolated signing job handles the attestation and never shares a process space with the build steps. The reference workflow at examples/ci/github-actions-l3-delegated.yml uses slsa-framework/slsa-github-generator to demonstrate an L3-compatible delegated signing pattern. It does not establish L3 on its own; L3 also depends on hardened-platform and build isolation controls.
Verifying attestations with packer verify-attestation
Provenance is only useful if it gets checked before an image is used. The new packer verify-attestation command is designed to sit inside a deployment pipeline or pre-flight script:
If any check fails, the command exits non-zero, and the deployment is blocked. You can enforce as much or as little as your environment warrants: At minimum, verify the signing identity and the artifact digest; for L2, add -require-rekor and -require-timestamp.
This directly enables several common use cases:
Deployment gates: Block any image that cannot produce a valid signed attestation from your trusted CI pipeline
Incident response: When a CVE drops, correlate the affected commit with images built from it and, when integrated with the inventory and deployment records, the running instances that may be affected
Compliance and audit: Provide signed provenance evidence that can support SOC 2, FedRAMP, or internal security-control reviews; the attestation does not establish compliance by itself
Shadow build detection: Verify that golden images came from approved pipelines rather than ad hoc builds
Other improvements in v1.16.0
continue_on_error for provisioners
The new continue_on_error meta-argument lets you mark a provisioner as non-fatal. When it fails, Packer logs a warning and continues to the next step rather than halting the build. This is useful for optional diagnostics, telemetry, or cleanup scripts that should not block image delivery. The option applies to HCL2 templates.
provisioner "shell" {
inline = ["run-diagnostics.sh"]
continue_on_error = true
}
Provisioners without this flag behave exactly as before.
optional() in object-type variables
Object variables now support the optional() modifier for per-attribute defaults. Callers only need to provide required fields; optional fields fall back to their declared defaults. This makes it easier to evolve shared variable schemas without updating every caller at once.
variable "image_config" {
type = object({
name = string
region = optional(string, "us-east-1")
encrypt = optional(bool, true)
})
}
New timestamp template functions
rfc3339_parse() parses an RFC 3339 timestamp into a structured object, including a unix field. unix_timestamp_parse() parses a Unix epoch integer into a structured object, including an rfc3339 field. Both are useful for stamping image names and tags with build-time date components without reaching for a shell script.
Get started
Think: Packer now gives you a signed, verifiable record for builds configured with the provenance post-processor.
Feel: Confident that your image supply chain is auditable and defensible.
Do: Upgrade to v1.16.0 and add the provenance post-processor to your next build.
The new features described here are opt-in, and existing templates require no changes to continue building with Packer v1.16.0.
Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms.
The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live.
The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends.
Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms.
Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East.
JWR phishing framework, a likely variant of the Outsider
JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint.
Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers.
The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE, which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server.
If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe.
In standalone mode, the application fully owns its WebSocket connection.
In pluginIframe mode, it has no direct link to the network at all and instead sends everything upward to an embedding plugin frame.
In hostIframe mode, it defers entirely to a parent page already running as the relay bridge.
Regardless of which of these three modes or through the Host Bridge is used, the data is either sent to C2 as plain text in JSON format with the DEV_MODE flag set, or it is passed to the JwrCrypto module, which encrypts it with a newly generated key before sending it to the C2 server.
The script engine includes a background worker module that maintains the connection with C2, keeping it alive independently of page navigation for the remainder of the session. In a live session activity, the script continuously streams the victim’s keystrokes to the actor's C2 server as captured data, while that the actor continuously sends the next instruction to be executed from the C2 server. Each incoming instruction is checked by the client engine against a brief history to ensure that nothing already executed runs twice, then routed by the Instruction Handling module to one of two outcomes including, redirecting the victim to a different phishing page or updating the current page's state and displayed status, awaiting the actor’s next instruction. This execution loop repeats until the actor decides to keep the session alive, and when the actor chooses to close the session, the accumulated data is transmitted to the C2 one last time, and the victim is redirected.
JWR Client’s host bridge mode
In host bridge mode, the IIFE establishes a persistent WebSocket connection to the actor's server, manages the victim's session identity, excludes repeating incoming instructions, and proxies all communication between the server and the phishing child iframe.
Every victim is assigned a unique session token the moment the bridge initializes. It first checks persistent storage for an existing JWRCID value if the victim has visited the page before, and if true, the same token is reused, allowing the actor to correlate multiple visits from the same device. If none exists, a new token is generated in the format JWRCVV-{Date.now()}-{random1}-{random2}, with both random segments being 13-character base-36 strings, and this token becomes the victim's permanent identifier for the entire C2 communication.
The module then spawns a Web Worker from a separate script located at static/js/ws-worker.js, which isolates the WebSocket from the main JavaScript context, allowing the connection to persist during navigation within the phishing flow. The WebSocket connection path is constructed as webSocket/QT/{sessionId}/khkjsahfjkwhakjlsdwdddddd88, where the alphanumeric suffix is likely a server-side authentication token that ensures the connection originates from a deployed kit instance.
The host bridge incorporates an anti-analysis check, which serves as a one-time execution guard that performs a self-referential .toString().search() call against a backtracking regex. This check detects whether a debugger has attached the function to modify its apparent source. Additionally, a decoy variable is scattered throughout the code to mislead static-analysis tools.
Moreover, it maintains a JSON array named JwrExecutedInstructions in sessionStorage to prevent the same operator instruction from executing more than once. Before relaying any instruction into the phishing iframe, it verifies the instruction ID against a list. If a match is found, it discards the repeating instructions. If it is a new instruction, it sends an acknowledgment back to the C2 server in the format {type:"instructionAck", instruction_id:, cvv_id:}. The list is limited to 50 entries and is trimmed to retain the most recent 30.
Figure 3. Deobfuscated view of JWR client’s instruction handling and acknowledging functions of Host bridge mode.
Content Mode operation (Vue.js application), the real-time capture
The Vue.js victim application developed by the JWR developer is a single Vue 2.X instance, window.vm = new Vue ({el: ‘#app’, ...}), mounted on a Document Object Model (DOM) element with the id “#app”. This application serves as the phishing page that the victim sees and interacts with. It is responsible for rendering the checkout forms, collecting and streaming input to the C2, executing the actor’s instructions, and performing the exfiltration function.
When the Vue instance is constructed, the created function is executed, processing the data passed from the fake webpage the victim visited, but without attaching the page. It generates the session ID and clears any sensitive fields leftover from a prior page visit if the victim had previously accessed the same fake page. It also restores any previously saved session state from “sessionStorage” if it exists. Then, it redirects the victim from any page other than index/login/home that lacks a session ID to a_index.html, ensuring the victim enters the phishing flow. Finally, the Vue takes the rendered output and attaches it to the #app element in the page's DOM, making the interface visible and interactive to the victim.
Once the DOM is ready, Vue executes the mounted function asynchronously, at which point the victim becomes visible to the actor. It determines the engine’s execution mode and then executes two functions: getIPInfo() to geolocate the victim’s IP address and getSyncSettings() to pull the actor’s configuration from the C2 server. Next, it initializes the communication channel, captures the victim's action, and creates a CVV form with the victim's device fingerprint data. This includes the victim's current form of state, such as device type, browser, language, time zone, and geolocation, which are encrypted and sent to the actor's C2 server.
Figure 4. Deobfuscated view of JWR client’s Vue app’s initialization and mounting functions.
One of the key features of the JWR kit is its near-real-time input streaming. Each input element in the phishing form is transmitted to the actor’s console, allowing the actor to view partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button. This mechanism enables the actor to see the victim's data and determine which instruction to send to the client's engine from the C2 before the victim even submits the form.
Before the Vue instance is created, the client engine establishes an instruction mapping table that correlates over 40 actor command names with specific HTML page filenames, thereby granting the actor remote control over the victim browser session.
Figure 5. Deobfuscated view of JWR client’s Vue app’s initialization and mounting functions.
The JWR client script includes a C2 command dispatcher. When the actor sends an instruction, the client receives, decrypts, and forwards it to the dispatcher function, which routes it to the appropriate handler based on the instruction type. The table below displays the actors' instructions from C2, facilitated by the JWR client kit.
Instructions
Purpose
to_index
Send victim to the landing/entry page
to_login
Send victim to site-login page
to_password
Prompt for account password
to_info
Collect PII
to_card
Send victim to card-entry page
to_qr
Show QR code for scan-based verification
to_sms
Request SMS OTP
to_sms_login
Request SMS OTP for login step
to_sms_bank
Request SMS OTP for bank verification
to_2fa
Request 2FA code
to_text_verify
Request custom text/code verification
to_email
Request email OTP
to_pin
Request card PIN
to_app
Request bank-app push approval
to_login_app
Request app-based login approval
to_bank_login1
Step 1 of multi-stage bank login
to_bank_login2
Step 2 of multi-stage bank login
to_bank_login3
Step 3 of multi-stage bank login
to_custompage
Route to a custom/template-defined page
to_shop
Show fake storefront/shop page
to_paypal_login
Collect PayPal login credentials
to_paypal_card
Collect card data via PayPal-branded flow
to_paypal_card_verify
Request card verification text (PayPal flow)
to_paypal_sms
Request PayPal-linked phone OTP
to_paypal_email
Request PayPal-linked email OTP
to_paypal_pin
Request PayPal PIN
to_paypal_app
Request PayPal app-approval verification
to_apple_login
Collect Apple ID login
to_apple_sms
Request Apple-linked SMS OTP
to_apple_email
Request Apple-linked email OTP
to_apple_card
Collect card data via Apple-branded flow
to_apple_verify
Request generic Apple verification step
to_klarna_login
Collect Klarna login credentials
to_klarna_sms
Request Klarna-linked SMS OTP
to_klarna_email
Request Klarna-linked email OTP
to_klarna_pay
Collect Klarna payment details
to_klarna_pin
Request Klarna PIN
to_success
Sends full data to the C2 and redirect victim to a real site
to_redirect
Redirect victim out to an operator-supplied URL
tip_fail
Show generic declined/invalid error, force re-entry
tip_custom_fail
Show an operator-authored custom error message
to_page_custom_fail
Route to a custom failure page defined per template
tip_change_card
Fake card-declined prompt to extract a second/different card
updata_img
Push a new imagelikely arefreshed QR codewithout navigating
updata_2fa
Silently inject/display an OTP code supplied by the operator
text_updata_verify
Push custom verification text to display, without navigating
submitResult
Operator pushes a corrected or enriched copy of the victim's form data back into the session
The JWR client engine has a data exfiltration schema. Its scope extends well beyond payment data, and includes full identity information (name, gender, date of birth, Social Security Number, passport, driver's license, medical record number), address, email and email password, up to three sets of website credentials, PayPal login, complete card data (PAN, expiry, CVV, PIN, brand, issuer, issuing country), front and back card images, photos of identity documents, and an automatically captured browser fingerprint, including IP, device, language, time zone, user agent, cookies, and geolocation.
Upon submission, the client normalizes the submission types, triggering a full-screen non-interactive overlay over the page. For credit card submissions, a Lottie animation is displayed that corresponds to the card brand detected from the first two BIN digits. After exfiltration, when the actor closes the WebSocket, terminate the worker and POST the entire cvvformobject to the C2 endpoint at api/open/the_final_interface. Once the actor confirms, the victim is redirected to the actual site.
Talos discovered that the primary mode of C2 communication for the JWR kit is via a binary WebSocket connection. The WebSocket path follows the format shown below, where the JWRCID and JWRCVV segments encode the victim’s unique session token, and the trailing alphanumeric suffix is likely a server-side authentication token.
Figure 6. Sample C2 connection initiation function of JWR client.
Alongside the WebSocket, the JWR client registers five Representational State Transfer (REST) endpoints which are used as an alternate communication method, between the C2 and the victim browser. In this case, a session opens with api/open/addClick, executed once from within the mounted function after the phishing page becomes visible to the victim. It reports the victim's IP address, country, the specific phishing page they landed on, the referring or storefront URL, and a bundle of device and operating system (OS) metadata to the actor's console with a live "new visitor" entry before a single instruction has even been sent by the actor from the C2 server. Running alongside it is api/open/getSyncSettings, which pulls inbound configuration from the actor's server rather than exfiltrating anything, letting the actor change error messages, default contact placeholders, currency display, and other behavior on the fly without redeploying the client engine. For the victim’s environments where a persistent WebSocket connection is unavailable or blocked, api/open/pollInstruction provides an HTTP long poll fallback that delivers the same operator instruction objects the socket would otherwise push, keeping the actor's remote control functional even under restrictive network conditions. The session closes with api/open/the_final_interface, the client engine terminal exfiltration call. Once the actor issues a release instruction, the WebSocket connection and background worker are closed, and the entire accumulated cvvform object, every field collected across the full victim session — card data, identity documents, credentials, and fingerprint alike — is sent via HTTP POST to the C2 endpoint.
The below table represents the endpoints and the purpose.
Endpoint
Purpose
api/open/addclick
Victim arrival beacon with fingerprintingdata sentto C2
api/open/getSyncSettings
Gets actor-controlled settings from the C2
api/open/the_final_interface
POSTs the entirecvvform–exfiltrationendpoint
api/open/pollInstruction
Gets the actor’s instructions from the C2
api/open/addCvv
Exfiltration endpoint
The JWR client has purpose-built integrations for two major e-commerce platforms Shopify and WooCommerce. For Shopify deployments, the client reads the cart_data URL parameter which is a signed JSON blob that Shopify passes between checkout steps and extracts the checkout domain to use as the WebSocket base URL. This makes the WebSocket connection seem to originate from a legitimate Shopify domain. The initShopifyProductInfo() and initWordPressProductInfo() functions reconstruct the victim's shopping cart from the Shopify cart data, populating the phishing page with accurate product names, quantities, unit prices, and order totals making the fake checkout indistinguishable from the real one.
Figure 7. Shopify platform integration function of JWR client.
The operator facing status messages of the JWR framework are entirely written in Simplified Chinese and read as a professional admin dashboard notification feed phrases like "正在填写PayPal登录账号" (filling in PayPal login account), "进入2FA验证页, 请发送验证, 等待用户提交" (entering 2FA verification page, please send verification, waiting for user submission), and "均失败" (all failed), indicating that a Chinese-speaking actor is operating this scam campaign.
Figure 8. Deobfuscated view of JWR client’s program with hardcoded status messages in Simplified Chinese.
JWR phishing framework’s card stealing scenario
When the victim lands on the fake page, their browser sends an arrival beacon, indicating to the actor that a new visitor is present. From there, the actor takes over, sending a to_info instruction that directs the victim to a personal details page. While the victim types, the actor sends no further instructions but monitors the data stream live. Once the actor has assessed the victim's personal information, they issue a to_card instruction, moving the victim to the card entry page, where the same stealth live streaming occurs as the card number is typed in digit by digit.
If the actor isn't keen on the typed card details, tip_fail or tip_change_card instructions are sent, which deliver a fake "your card was declined" message to the victim and returns them to the card page to try a different one. This loop can repeat as many times as the actor wants, each attempt aimed at harvesting another card from the same victim. If the card is accepted instead, the operator sends one of the instructions: to_sms, to_2fa,to_pin, orto_app, directing the victim to a verification page to confirm their identity with a one-time code. For the rejected code, the actor sends the tip_fail instruction, which prompts the victim to re-enter it, while an accepted one leads to the final instruction, to_success, which redirects the victim to the real website, concluding the session with the actor now having the victim’s data that was typed.
Figure 8. Payment card stealing scenario of the JWR client engine.
The ongoing scam campaign
Cisco Talos observed an attacker utilizing an SMS phishing technique, sending SMS related to toll or road-pricing fees, postal or courier fees lures that contain a malicious URL targeting potential victims. When victims click on the URL, it opens a fake webpage that executes embedded JavaScript, which then renders and loads the client-side JavaScript engine of the JWR phishing framework.
Figure 9. Sample SMS phishing messages.
Figure 10. Phishing page which renders and loads the JWR client enabling the HOST mode.
The victimology of this scam campaign illustrates a broad, multi-country SMS phishing (smishing) operation rather than a single targeted campaign. Most of the malicious URLs impersonate a national land transport authority and its vehicle services or road toll payment portal, consistent with an "unpaid toll or road pricing fine" lure in Singapore. A second set of malicious URLs impersonates a national postal service, aligned with a "parcel held pending a customs or delivery fee" lure, alongside a smaller cluster mimicking an electronic toll collection system in the UAE. The third set of URLs impersonates a regional courier brand utilized across several Southeast Asian countries, again centered around the undelivered parcel or cash on delivery fee theme.
Talos discovery of the similarities in the client engine script of the JWR framework used in the current campaign with that of the Outsider PhaaS platform and additionally, we observed that in June 2026, the FBI had announced the technical takedown operation against Outsider platform (PhaaS) that has been in operation since 2023, through a joint operation “Ghost Hook.” However, the Outsider PhaaS was sold as a self-servicing product in the actor’s Telegram channels, according to the external researcher report, indicating the likely existence of variants of the Outsider PhaaS kit employed and operated by other Chinese-speaking threat actors.
Comparing JWR with other Chinese PhaaS platforms
Figure 11. Comparison of a few features of Chinese PhaaS kits.
Following the discovery of several similarities in the client-side scripts of the JWR and The Outsider kit, Talos conducted a comparative assessment of the JWR client script against other phishing kits operating within the Chinese-speaking criminal ecosystem.
Talos found that JWR shares no code-level implementation with Lucid, Darcula, or Lighthouse. Its C2 communication protocol, encryption module, and message envelope are all independently engineered. At the behavioral level, JWR aligns closely with those kits. All four share the operational signature that defines this PhaaS lineage including live operator puppeteering, card capture paired with OTP/2FA interception, and multi-brand templating at scale. Several additional characteristics place JWR within the same family, highlighting a tradecraft consistency across the developers of the phishing kits embedded in the Chinese-speaking criminal ecosystem.
Coverage
The following ClamAV signature detects and blocks this threat:
Js.Phishing.JwrFramework-10060456-0
The following Snort2 and Snort3 (SIDs) rules detect and block this threat:
66924
66925
66926
66927
66928
IOCs
The IOCs for this threat are also available at our GitHub repository here.
from Cisco Talos Blog https://ift.tt/JiQ0Mkr
via IFTTT
Threat actors have begun to exploit a newly disclosed Microsoft SharePoint vulnerability following the release of a proof-of-concept (PoC) code.
The vulnerability in question is CVE-2026-55040 (CVSS score: 9.1), which refers to a critical security feature bypass that stems from weak authentication. It was patched by Microsoft as part of its July 2026 Patch Tuesday updates.
"The authentication feature could be bypassed as this vulnerability allows impersonation," Microsoft said in an advisory for the flaw last month. "Exploiting this vulnerability could allow an attacker to disclose files and modify data, but the attacker cannot impact the availability of the system."
According to Defused Cyber, threat actors are leveraging a PoC exploit released by Rapid7 earlier this week, once again indicating fresh flaws are being abused in real-world attacks.
Successful exploitation of CVE-2026-55040 can allow an unauthenticated attacker to sidestep authentication on a vulnerable SharePoint server and perform arbitrary operations as a SharePoint site user or administrator. The vulnerability, per Rapid7, is due to "several issues" in the JWT token validation pipeline.
Specifically, it chains four different weaknesses to allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user. Rapid7 said the issue resides in two different classes that implement the token parsing and validation logic for Bearer service-to-service (S2S) tokens -
SPJsonWebSecurityTokenHandlerV2
SPJsonWebSecurityBaseTokenHandlerV2
The entire chain can be exploited by an attacker as follows -
Attacker sends a JWT with "alg: none" in the outer header, so no signature is required in the outer token.
The actor token's x5t header contains SharePoint's own STS certificate thumbprint, making it possible to resolve a signing key with no verification.
The resolved certificate is not in TrustedSecurityTokenServices, allowing the issuer to be accepted.
The actor token's signature is a non-empty value, e.g., AAAA, which is never verified.
Rapid7's Python-based PoC uses the forged JWT token to query a target's domain controller, enumerate users by SID, and auto-locate the SID for the user to find a site administrator.
As of writing, it's unclear who is behind the exploitation activity or what their end goals are. Telemetry data captured by KEVIntel shows that a total of 12 exploitation attempts were recorded since July 19, 2026. Out of these, eight took place on August 12 and 13, 2026, indicating that the release of the PoC has played a role in these efforts.
The 12 exploitation attempts have originated from eight unique IP addresses corresponding to five countries and regions, including Hong Kong, Japan, the Netherlands, Taiwan, and the U.S. In light of a spike in active exploitation, SharePoint users are advised to keep their instances up-to-date for optimal protection.
from The Hacker News https://ift.tt/UViqef3
via IFTTT
A newly disclosed flaw in the way OpenAI, Anthropic, and Google carried hidden AI reasoning between API calls let researchers recover internal reasoning and secrets from session logs, including API keys and passwords.
The weakness affected encrypted reasoning objects used by the providers' reasoning APIs, where a block created in one session could be replayed into another and, during testing, even handed to a weaker model in the same provider family to make it reveal the hidden content.
The team behind the paper Stealing Reasoning Traces from Proprietary LLM APIs demonstrated four abuse paths: stealing proprietary reasoning for model distillation, extracting private data from other users' published traces, recovering harmful content concealed behind a safe visible answer, and hiding prompt injections inside opaque reasoning blocks.
Across 6,708 public agent trajectories, the team decoded 315,320 thinking blocks. After excluding benchmark sources, it counted 704 distinct privacy artifacts from genuine user sessions, including 62 API keys, 33 passwords, 24 access tokens, and seven private keys.
The cross-user attack did not provide arbitrary access to private chats. It required obtaining an encrypted reasoning block, such as one published in an agent log, and API access to a compatible model from the same provider.
The researchers disclosed the findings to the affected model providers, Microsoft and Hugging Face, and say the demonstrated attacks stopped working after mitigations. Their reproducibility statement says the main extraction attack is no longer reproducible as of August 2026.
The report does not document malicious exploitation in the wild. Developers are advised to strip reasoning blocks and opaque reasoning fields from shared traces and avoid committing raw API transcripts even when the visible text has been sanitized.
The problem starts with a design meant to preserve reasoning across API calls when conversation state is managed manually or statelessly. OpenAI can return encrypted reasoning items that applications replay with manually managed history, Anthropic carries full reasoning in an encrypted signature, and Google uses encrypted thought signatures. These objects preserve reasoning state without exposing the underlying plaintext directly to the client.
The encryption itself was not cracked, and the attack did not require obtaining an encryption key. It relied on intact opaque blocks being accepted and processed by the provider.
During testing, the paper found those objects portable across sessions, users, and models, allowing a weaker compatible model to act as what the authors call a "fuzzy" decoder: Claude Haiku 4.5 for Claude traces, GPT-5.6 Luna for GPT traces, and Gemini Robotics ER-1.6 for Gemini traces. The decoder was prompted to transcribe reasoning produced by a stronger model.
That cross-user behavior turns published agent logs into the sharper security problem. Of the 704 non-benchmark artifacts the team recovered, 64 appeared only in hidden reasoning and nowhere in the visible trace. Sanitizing the readable conversation could therefore leave secrets inside an opaque block that another account was able to replay.
The exposure the study demonstrates is bounded: it lands on developers who published raw agent logs with the reasoning objects intact, one identifiable group rather than every API user, and not necessarily the only one at risk.
The same portability also enabled an invisible prompt-injection proof of concept. The team crafted an opaque reasoning block that carried a malicious instruction and later replayed it into an unrelated task, causing the receiving model to add an attacker-directed upload action without putting the injected instruction in visible text.
The authors caution that they do not have ground-truth plaintext for the proprietary reasoning, so they cannot guarantee every reconstructed trace is an exact copy. Their fidelity checks relied on reasoning-token counts and qualitative comparisons, with extracted lengths generally tracking the providers' reported thinking-token counts.
Current vendor documentation shows that encrypted reasoning remains part of these APIs, but handling has changed. OpenAI still tells developers to replay encrypted reasoning items when manually managing stateless history, while Google says its backend manages thought compatibility when a session switches models.
Anthropic now says thinking blocks are tied to the model that produced them and should be stripped when switching models because other models ignore them.
Several questions the disclosure raises are left open by the public record. No public acknowledgment of the flaw from any of the three providers has surfaced so far, and none has tied its current documentation to this research, so the account that the demonstrated attacks no longer work rests on the researchers' own reproducibility statement rather than on vendor confirmation.
The same record shows the team decoded hundreds of thousands of reasoning blocks already sitting in public repositories, yet it does not address whether those already-published blocks remain decodable, a separate question from whether fresh attacks still succeed.
The work builds on May research by Johns Hopkins cryptographer Matthew Green, who showed that encrypted reasoning blocks could be replayed across sessions and accounts but stopped short of a reliable secret-extraction technique.
Green says he reported the replay behavior to OpenAI and Anthropic through their bug-bounty programs; in his account, OpenAI called the report unreproducible and Anthropic said it did not see security implications in the replay or side-channel behavior.
The new paper turns that replay behavior into a broader extraction method and documents the privacy consequences at scale.
from The Hacker News https://ift.tt/oGh5vbI
via IFTTT
Enterprise defenses are tuned to catch the attacks that make noise. This year's data shows attackers winning by making none.
According to Picus Labs' new Blue Report 2026, which measured more than 338 million real attack simulations across actual client production environments in the first half of 2026, defenses are having one of their strongest years yet. Average prevention effectiveness climbed from 62% to 69%, matching its 2024 peak, and logging reached a four-year high of 58%.
The good news: The recovery is real. The bad news: It's taking place almost exclusively at the perimeter.
The report's sharper finding is what happens after that perimeter is crossed. Inside, the picture inverts: defenses that look strong from the outside turn soft, and are the softest of all against the quiet moves, the reconnaissance and credential theft that precede every serious breach.
This is a fault line that runs through the entire report.
A vulnerable interior behind a recovering perimeter
For the first time, Picus Labs measured post-compromise prevention with autonomous penetration testing: what controls actually break the attack chain once an adversary is already operating inside the network as an authenticated user. The Post-Compromise Prevention Rate was a meager 37%.
The perimeter now blocks roughly two attacks out of three; inside, defenses stop barely one in three.
But that average hides the more useful pattern. The interior does not fail evenly. It fails along one clean line. Here too, noisy actions get caught, while quiet ones don’t.
Malicious behavior running code or jumping between machines was blocked most of the time: lateral movement through service execution, using techniques like Sharp-ServiceExec and SMBExec, was stopped around 90% of the time, and UAC-bypass privilege escalation was almost as successful at around 85%.
That’s EDR doing its job, and years of assume-breach investment showing up, as hoped, in the numbers.
Meanwhile, the quiet work runs almost unopposed.
Reconnaissance, mapping the domain and enumerating shares and sessions, was the least-prevented category of all, only being stopped a paltry 10% of the time. Defenses did a little better at detecting credentials being quietly read out of memory at around 22%, and one variant, pulling secrets straight from the registry, was stopped in less than 1% of attempts.
An attacker can map the environment, harvest sessions, and read credential material with almost no resistance, getting their proverbial ducks in a row before taking any noisier action that would trip a control.
A signature catches the famous attack, not the behavior
One result captures why. The same credential-theft tool, Mimikatz, was run at the same objective three ways, and the prevention scores could not have been further apart.
Dumping credentials the classic, heavily signatured way, straight from LSASS process memory, was blocked almost every time. Pulling them from other memory locations, or reading them from the registry, was almost never blocked at all.
Same tool, same goal, same environment.
The only variable between these three was how conspicuous the route was. The LSASS path is loud in a way tools can match: a process opens a handle to lsass.exe and reads its memory, an event vendors have instrumented for years. Reading the registry never touches lsass and looks like ordinary privileged activity, so a control built for the first event has nothing to fire on for the second.
Alarmingly, that 94% is even softer than it sounds, because it was measured against one known build of an open-source tool whose recognizability lives in how it was compiled, not in what it does.
Rename the strings a signature keys on and the hash is new.
Load it in memory and nothing lands on disk to scan.
Or skip Mimikatz altogether and take the same dump with a Microsoft-signed utility already on the box.
Each path ends with credentials in hand; only the thing the signature was watching for changed. A prevention score built on signatures tells you how well you catch what you have already seen, not whether you’re actually stopping the behavior underpinning it.
The data shows stealth pays off for attackers
And that gap isn’t confined to one tool.
The Red Report 2026 found attackers deliberately shifting toward stealth, and the Blue Report shows this behavior is working for them across the board. The single least-prevented technique in the entire dataset was hiding command history, stopped just 1% of the time. The behaviors defenders miss are exactly the low-noise ones that today’s evasion-minded attackers rely on.
Malware defense is slipping for the same reason.
The IOC-Based Prevention Rate, or how often security controls block known-malicious files delivered as downloads, fell to 50% this year, from 60% last year and 71% in 2024.
Signatures alone can’t keep up: VirusTotal takes in close to two million new files a day, and repacking a payload makes the indicator stale while the behavior underneath stays the same.
Indicator-based testing still matters, it’s the fastest way to confirm the edge stops what is already known, but on its own it only ever checks the paths someone already wrote a signature for. It has to be paired with behavioral testing that asks whether the action itself is being stopped.
Organizations can see the attacks they can’t stop
So far this is a story about prevention, about what gets stopped. Detection is the fallback: when a control fails to block an action, an alert is supposed to bring a human in. This year, this critical fallback barely fired.
Logging rose to a four-year high of 58%, but the alert score stayed frozen at 14%. Fewer than one in seven simulated attacks produced an alert. Read that again. Today, teams are collecting more telemetry than ever but are converting almost none of it into action.
The gap between what gets logged and what gets alerted is now a detection-engineering problem, not a collection one.
This year's leaders were last year's laggards
Last year's leaders slipped and last year's laggards climbed, often by wide margins.
Education fell 30 points in a single year to become the least-protected industry, while the sector that had been weakest a year earlier posted the largest gain in the dataset. The report's own line for it is blunt: strong performance is rented, not owned, and it lasts only as long as the validation behind it.
Rising averages also masked where defenses lost ground against specific adversaries.
Even as the overall score climbed, prevention fell against nine of the ten hardest-to-stop threat groups, and every one of the top ransomware families was blocked less than 38% of the time, with Play collapsing from 50% to 13%.
These are well-documented actors with published playbooks, which is kind of the point: broad control improvement does not automatically translate into coverage against the specific, evolving groups that are most likely to come for you.
What the numbers are telling us
The recovery is itself the proof. Prevention climbed seven points because organizations re-tested controls that had drifted and fixed what the tests exposed, while the sectors that regressed are the ones that stopped testing. Validation’s no longer an annual audit; it’s the difference between this year's winners and losers, and it only holds while it runs.
That points to three moves:
Validate exposure, not inventory. Prove which exposures are actually exploitable in your environment instead of spinning your wheels cataloging theoretical ones.
Harden the interior against quiet actions. Test discovery, share and session enumeration, and passive credential access as rigorously as lateral movement, with detection that triggers on what an action does, not which signature it matches.
Treat detection rules as engineering. Write them against current behavior, confirm they fire, tune out the noise, and re-validate as things change, so logs finally become alerts.
None of this is particularly exotic, and that itself is an important point. The defenses in this report already recovered the moment someone tested them.
The attacks still slipping through are the quiet ones, the reconnaissance and credential reads that never trip a signature and, this year, rarely trip an alert either.
Read the full report
The 94% and the 3% are one finding from one experiment. The Blue Report 2026 runs the same test across the whole attack surface: prevention and detection broken down by industry and region, the MITRE ATT&CK techniques defenders block least, and the threat groups and ransomware families that prevention lost ground to this year even as the overall average rose.
If the loud-versus-quiet split in this article looks familiar, the report is the fastest way to find where that gap sits in an environment like yours, and which quiet actions you should be looking for today.
Download the Blue Report 2026 to see where your defenses are likely to hold, and where the quiet gaps are most likely to be.
Note: This article was written by Sıla Özeren Hacıoğlu, Security Research Engineer at Picus Security.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/HeI8gN9
via IFTTT
