From Social Engineering to a Technical Test: Agree on the Handoff

A social-engineering exercise reaches an interesting point: someone approves an account change, opens a support connection, or follows an instruction. The next team asks, “What could that access do?” Before continuing, they need a precise starting state and permission for a specific operation.

A technical follow-on test is a separately authorized check of what a defined starting state permits. It may continue from an outcome the exercise demonstrated, or begin with access supplied for the test. Keeping those origins distinct is essential to an honest finding.

The example below follows one protected read through authorization, execution, and cleanup.

Decide what the first team actually established

A call transcript may show that a support agent agreed to a reset. It does not establish that the account changed. A directory change record may establish a modification, but it does not establish that an application accepted the resulting access. Start the handoff with the last supported observation.

For example, “the agent agreed to change the test account” and “the account’s authentication method changed” are different starting states. If the technical team needs the latter, the identity owner must supply evidence of the change or explicitly create an assumed starting condition.

Use these two labels consistently:

• Demonstrated starting state: evidence from the preceding exercise establishes the condition being carried forward.
• Assumed starting state: the assessment team or customer supplies the condition to examine downstream behavior. The earlier compromise is not claimed.

Both can answer useful questions. An assumed account session lets an application team test a permission without staging a help-desk call first. It cannot establish that an impersonator could obtain that session through the help desk.

Agree on the operation before testing

NIST SP 800-115 recommends documenting assessment scope, authorized activities, exclusions, contacts, data handling, and incident procedures. Its assessment-plan guidance and rules-of-engagement template also cover stopping and resuming work. The contract below applies those planning principles to one handoff. NIST SP 800-115, section 6.5 and appendix B

Specify the operation as a sentence: “Using the approved test identity and session, request Test Document Seven from the designated training portal once.” Avoid a broad instruction such as “see what is accessible.” It leaves the next operator to invent the target and stopping point.

The operation should answer a real control question. If the test identity is meant to be denied the document, a returned document may demonstrate a failed authorization boundary. If that identity is meant to read it, success establishes the permitted path and the exercise’s observed reach, not necessarily an application defect.

Our authentication and authorization explainer covers that distinction. Here, the task is to carry it safely between the campaign operator, identity owner, application owner, and observer.

An example: one protected document read

The names, references, and outcomes below are fictional.

Alder Workshop creates Test User A and a training portal containing Test Document Seven, a harmless record with the agreed marker TRAINING-SEVEN. The account is not supposed to read that document from the selected test context. The application owner records that expected outcome before testing.

The earlier recovery exercise produced an approval but no verified account change. Alder chooses to continue from an assumed test session issued by the identity owner. The following record prevents that choice from becoming a false claim about successful recovery abuse.

The session reference points to restricted evidence storage. It is not a copy of a usable cookie or token. OWASP recommends excluding raw session identifiers from logs and using an appropriate correlation reference instead. OWASP: session lifecycle logging

Confirm readiness on both sides of the handoff

The receiving operator should repeat the contract’s identity, operation, and stopping point before proceeding. The application owner confirms that the test record exists, contains no production data, and can be distinguished from a login page or generic success message. The observer confirms which evidence can be collected.

If an expected record is unavailable, resolve that before starting or narrow the claim the exercise can support. Do not promise to correlate an application request later if nobody has confirmed that the application retains a suitable record.

Specify whether defenders know the timing. A coordinated test can establish collection and response mechanics; an unannounced exercise asks a different operational question. Record any test exclusions, alert suppression, or allowlisting that change what the defender sees. If alerts were deliberately suppressed, the result cannot establish normal alerting behavior.

Make the request and check the response

The operator performs the initial approved read. For this fictional example, the response returns the expected training marker. The application owner matches it to a record for Test User A, the selected document, and the test window.

That establishes a successful read in the assumed context. It also differs from the contract’s expected refusal, so the application owner has a specific authorization question to investigate. The result does not prove the original call created access, and it does not establish access to another document.

Compare three other possible observations:

An HTTP success status alone is insufficient: inspect the expected protected content. Likewise, a screenshot of an already open page might show old content. OWASP notes that sensitive data can remain in a browser cache after a session ends. Use a fresh operation and server-side evidence where available. OWASP: web content caching

Review detection separately. Record the named monitoring system and observation window, whether the event was collected, whether an alert appeared, and whether an analyst responded. A successful read and an alert can coexist. Neither replaces the other in the result.

Stop cleanly when the contract no longer fits

If the test unexpectedly returns real customer data, reaches another service, or produces a service-health concern, stop the operation and notify the named contact. Record the deviation through the approved evidence-handling process. Do not continue exploring to make the finding more impressive.

If the team needs a different identity or broader permission to answer the next question, amend the plan and obtain the required authorization. Keep the original denied or inconclusive outcome in the record. Changing conditions without recording them would make the two attempts look comparable when they are not.

The approver for resuming work should be named in advance. NIST’s rules-of-engagement template explicitly includes halt criteria and a process for reinstating the test team. NIST SP 800-115, appendix B, incident handling

Close the access, not just the ticket

After the operation, the identity and application owners complete the agreed cleanup. For the fictional case, they end the supplied test session and remove any temporary test grants. An authorized fresh request then verifies the intended restriction. If the cleanup procedure does not permit a behavioral check, retain administrative evidence and state that access was not retested.

Keep evidence retention separate from access cleanup. The team may need to preserve the request record while removing the test credential. Deleting every artifact immediately would make the finding harder to verify; leaving usable test access active would leave the exercise unfinished.

Our identity containment review covers session, method, device, and grant checks in more depth. Apply only those relevant to the test state, with an owner for each unfinished item.

State how the test access was obtained

The fictional case can close with this statement:

Starting from an assumed session for Test User A, the approved read returned Test Document Seven although the selected context was expected to be refused. The application owner confirmed the matching operation. The prior recovery exercise did not establish how an attacker would obtain this session. Cleanup and the agreed access restriction were verified; other resources were not tested.

Add the separate detection result and any cleanup exception to that finding. Download the technical handoff contract to prepare the same record for your own authorized exercise.