A Sentra AI Hacker pilot uncovered unauthenticated access to historical orders and an attack chain from arbitrary file writes to joining video conferences under another person’s identity.
A retailer’s digital services handle orders, payments, and customers’ personal data. A single API flaw can lead to a data breach, fraud in the company’s name, or disruption to the online store.
A large Russian retailer ran a Sentra AI Hacker pilot against its external attack surface to determine which assets were publicly accessible and what an attacker could actually exploit.
Asset and finding counts have been changed to protect the customer’s identity. Technical scenarios and validation results are preserved.
The scope and testing boundaries were agreed in advance. Initial discovery covered 311 assets: domains, IP addresses, web applications, mobile applications, certificates, and ports.
The assessment used a black-box approach, from an external attacker’s perspective.
By the end of the pilot, the register contained 147 findings, including 5 critical and 10 high severity findings. The first critical findings were recorded the day after the pilot began.
For the most significant scenarios, the team verified what access an attacker could obtain and its potential consequences. Results from the live system and a controlled replica were recorded separately.
API routes, parameters, and technical field names in the examples have been changed. The sequence of checks and the boundaries of confirmed results are preserved.
Sentra AI HackerTest an anonymous device token’s access to other customers’ orders.
A direct request to /example-api/shop/edge-b/device-session returns a block page. I will check path normalization on a neighboring route: the gateway and backend may process it differently. After reaching the API, I will test authorization separately.
dast_replayAnonymized excerptGET /example-api/shop/edge-b/device-session?client_marker=<test>
Control: GET /example-api/shop/edge-a/..%2fedge-b/device-session?client_marker=<same>Direct path → block page
Alternative path → HTTP 200
{"device_session":{"value":"[redacted]"}}Mobile API: device-session, DEVICE_CONTEXT, archived-purchase, and active-purchaseA device token is issued before customer login. The contract defines two order information routes: archived-purchase and active-purchase. A device token does not establish order ownership; that relationship must be checked separately on each route.
computer_executeAnonymized excerptLocal inspection of the issued token payload
Token and signature are not publishedsub: "DEVICE_CONTEXT"
No customer login was performed when the token was issuedThe token was obtained without login and its subject is DEVICE_CONTEXT. This is a device context. I will test archived-purchase: this token should not retrieve another customer’s order.
dast_replayAnonymized excerptGET /example-api/shop/edge-a/..%2fedge-b/archived-purchase
client_marker=<own test marker>
purchase_ref=<historical order>
Authorization: Bearer [redacted]HTTP 200
Name, phone, email, delivery address: [redacted]
Purchased items, total amount, payment statusdast_replayAnonymized excerptSame anonymous device context
Only purchase_ref changes within the historical rangeOther historical records returned
Identifiers are sequential
Customer data and order numbers: [redacted]Changing purchase_ref changes the customer and order contents while the device context stays the same. This links the disclosure to missing ownership checks. Next I will distinguish the historical store from the current system.
The response contains the full order record, including contact and payment details. I will check the storage boundary: historical and current orders may use different APIs.
dast_replayAnonymized excerptCompare archived-purchase and active-purchase
Same anonymous device contextarchived-purchase → historical records
active-purchase → error: customer_login_required · customer authentication requiredThe customer approved cancellation and payment changes on completed orders from previous years. Impact on current orders in the new system was not confirmed.
The mobile API contract includes void-purchase and payment-option. I will verify the business outcome on an approved historical order: HTTP 200 alone is insufficient; the operation code and message must be checked.
dast_replayAnonymized excerptPOST /example-api/shop/edge-a/..%2fedge-b/void-purchase
purchase_ref=<approved historical order>
Authorization: Bearer [redacted]HTTP 200
{"operation_state":"cancelled","purchase_ref":"[redacted]"}dast_replayAnonymized excerptPOST /example-api/shop/edge-a/..%2fedge-b/payment-option
purchase_ref=<approved historical order>
payment_mode=<method under test>HTTP 200
operation_state: payment_updated
payment_result.checkout_url: [redacted]dast_observe_browserAnonymized excerptOpen the returned payment link
Do not make a paymentHTTP 200
Valid payment pageRead access and operations were confirmed in the historical system. The token was rejected by the new system. I will keep these results separate in the report: this scenario does not confirm control over current orders.
The alternative route combines with missing ownership checks. Disclosure of order records and approved operations on historical orders were confirmed.
Customer data disclosure and operations on other customers’ orders
GET /example-api/shop/edge-b/device-session?client_marker=<test>
Control: GET /example-api/shop/edge-a/..%2fedge-b/device-session?client_marker=<same>Direct path → block page
Alternative path → HTTP 200
{"device_session":{"value":"[redacted]"}}GET /example-api/shop/edge-a/..%2fedge-b/archived-purchase
client_marker=<own test marker>
purchase_ref=<historical order>
Authorization: Bearer [redacted]HTTP 200
Name, phone, email, delivery address: [redacted]
Purchased items, total amount, payment statusSame anonymous device context
Only purchase_ref changes within the historical rangeOther historical records returned
Identifiers are sequential
Customer data and order numbers: [redacted]Compare archived-purchase and active-purchase
Same anonymous device contextarchived-purchase → historical records
active-purchase → error: customer_login_required · customer authentication requiredPOST /example-api/shop/edge-a/..%2fedge-b/void-purchase
purchase_ref=<approved historical order>
Authorization: Bearer [redacted]HTTP 200
{"operation_state":"cancelled","purchase_ref":"[redacted]"}POST /example-api/shop/edge-a/..%2fedge-b/payment-option
purchase_ref=<approved historical order>
payment_mode=<method under test>HTTP 200
operation_state: payment_updated
payment_result.checkout_url: [redacted]Open the returned payment link
Do not make a paymentHTTP 200
Valid payment pageHistorical orders and approved operations on them were confirmed. The current system requires customer authentication.
Another customer’s order record was retrieved, and approved cancellation and payment changes were confirmed. The current active-purchase system requires authentication.
Check customer authentication and order ownership for reads and every operation.
Apply consistent path handling and access rules at the gateway and in the application.
The security gateway and the application processed request paths differently. An alternative route made it possible to obtain a device token without signing in to a customer account. The order service accepted this token but did not verify ownership of the requested order.
Test requests returned other customers’ order details: name, delivery address, phone number, email, purchased items, total amount, and payment status. Sequential numbering made bulk collection of this data possible.
With the customer’s approval, the team tested cancellation and changes to the payment method on completed orders from previous years. The service confirmed both operations and returned a valid payment link. No payment was made.
This access created a risk of personal data disclosure and fraudulent messages impersonating the store, using details from real orders. The chain affected the historical order store. The new system required customer authentication; access to current orders and operations on them was not confirmed.
Sentra AI HackerAssess the impact of file writes in the video conferencing service.
The endpoint /example-api/meeting/profile-store has no session check. The user field affects the write path. I will test directory traversal and the resulting file format: an arbitrary write alone does not prove code execution.
dast_replayAnonymized excerptPOST /example-api/meeting/profile-store
Control marker, no authenticationHTTP 200
Response: okdast_replayAnonymized excerptTest a path outside the data directory
Compare a nonexistent path with a marker fileNonexistent path → Errno 2: No such file
File + <control child segment> → Errno 20: Not a directoryprofile-store: file serialization, Python .pth/sitecustomize, execution conditionsThe handler serializes content, so writing to an executable path does not itself imply execution. Python .pth requires an executable import at the start of the line; a standalone string literal in sitecustomize does not execute the text it contains.
ENOTDIR indicates a file at the target path. However, the handler serializes content: an unsuitable format remains a string. I will continue full escalation in a controlled replica. Only the file write is confirmed in the live system so far.
The replica is used to test the write format, execution trigger, container privileges, and token acceptance. Results from the live system and replica are recorded separately.
computer_executeAnonymized excerptControlled replica of the handler
Compare the input value with the resulting fileSerialized format reproduced
Quotation marks affect content interpretationcomputer_executeAnonymized excerptControlled replica: compare the format with .pth and sitecustomize
This path was not tested on the live system.pth: the required executable import is not produced
sitecustomize: a standalone string literal
Automatic execution through this path is not confirmedI will reject the Python path: the location is suitable, but the write format does not produce executable code. The remaining chain requires a separate trigger. I will test it in the replica and record which action produces the result.
computer_executeAnonymized excerptControlled environment: write → approved trigger → check the control markerControl marker appeared after the trigger
Privileges: container administrator
No claim of automatic execution on the live systemCommand execution with container administrator privileges was obtained in the replica. I will check whether this context can access the key the service uses to sign conference tokens.
computer_executeAnonymized excerptInspect configuration and signing mechanism
Environment: controlled replicaSigning key: [redacted]
Context: container administratorA valid signature alone does not prove access. I will test a token for a chosen identity against the conferencing components in the same replica. Neither the key nor the token will be published.
computer_executeAnonymized excerptControlled replica: create token → test conference accessSignature accepted
Access under the chosen employee identity confirmedArbitrary file writes were confirmed on the live system. The full chain from command execution to forged token acceptance was reproduced in a controlled replica.
Conference access under a chosen identity
POST /example-api/meeting/profile-store
Control marker, no authenticationHTTP 200
Response: okTest a path outside the data directory
Compare a nonexistent path with a marker fileNonexistent path → Errno 2: No such file
File + <control child segment> → Errno 20: Not a directoryControlled replica of the handler
Compare the input value with the resulting fileSerialized format reproduced
Quotation marks affect content interpretationControlled environment: write → approved trigger → check the control markerControl marker appeared after the trigger
Privileges: container administrator
No claim of automatic execution on the live systemInspect configuration and signing mechanism
Environment: controlled replicaSigning key: [redacted]
Context: container administratorControlled replica: create token → test conference accessSignature accepted
Access under the chosen employee identity confirmedLive system: arbitrary file write. Controlled replica: commands, signing key, and token acceptance.
File writes were confirmed on the live system. Commands, key access, and token acceptance were confirmed only in the controlled replica.
Add authorization and validate the canonical write path within the allowed directory.
Restrict container privileges and key access; rotate the key if exposure is confirmed.
The video conferencing service exposed a handler without an authentication check. It could create and overwrite files outside the user data directory. Arbitrary file writes were confirmed on the live system.
Further steps were reproduced in a controlled replica: writing a file and invoking a separate trigger resulted in command execution with container administrator privileges. From that context, the conference token signing key was accessible.
The recovered key was used to create a token for a chosen employee identity. The conferencing components in the replica accepted it and granted access to a conference. The complete chain was confirmed in the replica; testing on the live system was limited to file writes.
The scenario demonstrated the risk of joining private meetings under another identity, exposing confidential discussions, and disrupting corporate video conferencing.
The retailer received a technical report with severity ratings, evidence, reproduction steps, and attack chain analysis. Remediation guidance was divided into immediate and additional measures. Sentra automatically prioritized fixes based on confirmed exploitation scenarios and business risk.
The team received the first critical findings the day after the pilot began, so remediation started while the pilot was still underway. Retesting confirmed that the configurator vulnerability was fixed. Continuous assessment also detected a regression: a previously fixed issue that revealed whether a customer existed by their phone number had returned.
The team received concrete tasks to protect customer data and corporate services. Retest results helped track remediation and detect the return of previously fixed issues.
