Qubole: did stopping the integration stop access?
Disabling an integration can leave trust relationships that still need review. The Qubole case helps separate new authentication, existing sessions and evidence of data access.
Ler em portuguêsBy Pentesty
The account and the business question
In its November 9, 2026 research, Wiz reports Qubole-associated credentials being used to assume customer roles between October 14 and 26. The account describes secrets and S3 data being taken. Many roles had no other observed legitimate use, but still accepted that trust relationship.
The operational question starts with the business inventory: which integration needed this access, who owned it and which operation justified each permission? Answers should identify concrete resources. Ending a commercial relationship and removing a technical configuration are different events, each requiring an owner and its own record.
Describe the trust before changing it
AWS documentation distinguishes the policy allowing a role to be assumed from the permissions it grants. The external ID helps address the confused deputy problem and AWS does not consider it a secret. Assess it alongside the authorized principal and the conditions governing the relationship.
Map the supplier, external account, role, internal owner and current purpose. Identify integrations with expected activity and those left without an owner. Before restricting a path that remains necessary, agree on a change window and an operational alternative. The inventory should let another person check the decision and when it was made. Give the record a review date and an owner for unresolved dependencies, so the next administrator can distinguish an intentional exception from an integration that was simply forgotten and plan a concrete follow-up.
Separate new sessions from existing ones
AWS documents revoking role session permissions through a deny policy tied to issuance time. Its scope affects sessions for that role and requires care for legitimate users. Do not treat a credential replacement alone as proof that every previously issued access path has ended.
In an authorized assessment, use synthetic identities and resources to record two outcomes: an attempt to start a new session and an attempt to continue an earlier one. Define the expected behavior with the administrator. Keep the change time, test identity and allowed or denied operations, without storing the associated secrets in the report.
Identify what the records can establish
Wiz notes that CloudTrail management events alone do not identify S3 object reads. Suitable records are required. Without that coverage, the investigation must retain an explicit limitation on accessed content.
Connect each suspicious session to reachable resources and records available for the relevant period. Distinguish listing, configuration queries, content reads and permission changes. When a step cannot be reconstructed, record the gap and its consequence for the decision. Preserve existing evidence before beginning changes that would make comparison harder.
Accept recovery against a verifiable outcome
Agree on acceptance criteria before making the change. The team should demonstrate refusal of the retired path, continuity of approved functions and ownership of access that must remain. A partial result may require a documented temporary exception, with an expiry date and a person responsible for reviewing it.
The application secrets analysis complements this work: replacing a secret and reviewing an identity’s authority are related but different decisions. If the role could reach other credentials, include their owners in the plan. Record what the assessment validated instead of promising that a single change ended every possibility.
Make technical retirement a routine
Include technical removal in the process for retiring integrations. The service owner should confirm which operations are no longer necessary; the administrator checks effective access; the security team defines which evidence must be preserved. That agreement reduces the distance between a business decision and a configuration that remains in production.
Repeat the review when the supplier, purpose or permissions change. The result is a dated record of the authorized path, tests performed and limitations found. It provides a concrete basis for retaining, restricting or retiring the integration while respecting business needs and the approved scope.
Frequently asked questions
Does an external ID act as a password?
AWS does not treat it as a secret. It participates in the trust condition and needs to be considered alongside the principal and the role’s permissions.
Does retiring an integration automatically end earlier sessions?
Acceptance needs to verify that outcome separately. AWS provides mechanisms to revoke session permissions, with scope that the administrator should assess.
Do missing reads in management events prove no S3 access occurred?
No. Conclusions about objects require suitable access records or data events; missing coverage limits the investigation.
Does the exercise require access to a Qubole account?
No. The proposal uses the business’s own authorized environment, synthetic identities and expected outcomes agreed with its owners.
Sources and references
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.