Your Ransomware Negotiator Needs Its Own Access Controls

Hire an outside firm to run a ransomware incident and you hand over three things on the first day. An administrative account in the environment that is already under attack. A list of the data the attacker took. Sole custody of the conversation with the people holding it. Most small organizations grant all three on a verbal scope, to a company they first spoke to that morning, because an insurer named it on a panel.

Federal agents arrested Edward Dobrovsky in Philadelphia on October 8. The docket in the Eastern District of Pennsylvania, case 2:26-mj-01973, records a Rule 40 arrest, a government motion for pretrial detention, and a commitment order that sent him to the Eastern District of Texas the next day. KrebsOnSecurity reported that he co-founded a Canadian firm specializing in ransomware negotiation, that the charge summary covers conspiracy to threaten to impair the confidentiality of information with intent to extort money and interference with commerce by threats, and that the case grew out of the FBI investigation into the ShinyHunters extortion group. The complaint is sealed. Nothing has been proven and the defendant is entitled to the presumption of innocence.

The allegation is unproven. The access arrangement it points at is ordinary, undocumented in most small environments, and fixable in an afternoon.

Who this touches, and who it does not

If your incident response is entirely in-house, if no outside firm holds credentials in your tenant, and if nobody off your payroll would ever speak to an extortionist on your behalf, this one is not yours. Close the tab. That describes a small number of organizations and almost none under a few hundred staff.

Everyone else is in scope and most do not know it, because the exposure was created by a contract rather than a config change. It arrives in three forms. You hold a cyber insurance policy that names a panel of approved responders you are expected to use. You pay an MSP or MSSP that would subcontract the forensics. You signed a digital forensics retainer years ago with an access clause nobody has read since. Each one is a standing agreement to grant a third party privileged access on the worst day you will have, under time pressure, with no room left to negotiate terms.

For an owner, the test is a single question. On the day you get the call, who decides what the outside firm may touch, and where is that decision written down? If the answer is that the IT person will work it out at the time, the decision belongs to whoever arrives first.

What the court record actually says

The public file is thin, which is normal this early. The docket shows the October 8 arrest before Magistrate Judge Scott W. Reid, counsel appointed from the federal defenders, and a bail order noting that the defendant stipulated to identity and probable cause and elected to hold his detention hearing in the charging district. He was detained. On October 9 the court committed him to the Eastern District of Texas. The government's case sits in documents the court has sealed.

The useful part is the role, not the person. A negotiation firm holds a position almost no other vendor occupies. It knows what the attacker claims to have taken, it knows what the victim will actually pay, and it knows the hour at which the victim stops arguing. That knowledge is the product, and it is also what an extortionist wants. The victim has no independent way to check how it gets used.

Treasury has treated payment facilitation as a risk to the facilitator for years. The OFAC updated advisory of September 21, 2021 names financial institutions, cyber insurance firms, and companies in digital forensics and incident response as parties that can themselves breach sanctions by helping a victim pay. Krebs reports that charges against principals at other negotiation firms may follow. The practical reading for a defender is that this layer of the response market now attracts legal attention, and an engagement should be built so you can answer questions about it from your own records.

What a large enterprise does with an outside responder

Large security teams settled this years ago under a different label. A responder is a privileged third party, and privileged third parties go through a control stack that looks like this:

• A security review and a vendor tier assigned before any incident, so the due diligence is already done when the phone rings.
• Named accounts for named humans, issued in the client's own directory for one engagement, with an expiry date set at creation.
• Privileged sessions proxied through a jump host that records what was typed and what was read.
• Written data terms: which artifacts may leave the estate, where they are stored, which sub-processors see them, when they are destroyed, and who signs the attestation that they were.
• Separation of duties between the people negotiating and the people holding administrative rights, usually by hiring two firms.
• Two named approvers plus counsel for any payment decision, with sanctions screening of the counterparty before money moves.

That stack costs a privileged access management platform, a vendor risk function, and standing legal support. Small organizations skip all of it and end up with a shared login named something like svc-dfir, a Global Administrator role, and no record of what the account did. Those three handovers are the control that matters, and you can govern them with tooling you already pay for.

The right-sized version: three handovers, three controls

The account: issue it, time-box it, never share it

Refuse a shared account. One cloud-only account per named person in your own tenant, labeled with the person and the firm, so every log line later resolves to a human you can name. Grant the smallest role that does the work, which for triage and log review is a read role rather than a write one. Then make the grant expire on its own, because an account you have to remember to delete is an account that survives the engagement.

Microsoft Entra ID P2 does this directly with Privileged Identity Management, and the assignment can be created from a script through the role eligibility schedule request API.

# Microsoft Graph PowerShell. Creates one responder account and a role grant
# that expires on its own after 72 hours. Requires Entra ID P2 for the
# time-bound assignment.
Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"

$domain = "contoso.onmicrosoft.com"
$person = "jdoe"
$firm   = "vendorname"
$hours  = 72

$pw = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 24 | ForEach-Object {[char]$_})

$user = New-MgUser -DisplayName "IR Responder - J Doe ($firm)" `
  -UserPrincipalName "ir.$person.$firm@$domain" `
  -MailNickname "ir.$person.$firm" -AccountEnabled `
  -PasswordProfile @{ Password = $pw; ForceChangePasswordNextSignIn = $true }

$role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Security Reader'"

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest `
  -Action AdminAssign -PrincipalId $user.Id -RoleDefinitionId $role.Id `
  -DirectoryScopeId "/" -Justification "IR engagement, ticket INC-0000" `
  -ScheduleInfo @{
      startDateTime = (Get-Date).ToUniversalTime()
      expiration    = @{ type = "afterDuration"; duration = "PT${hours}H" }
  }

Without P2, the same outcome takes two cheaper steps: set the account to disable on a date you put in a calendar invite, and bind it with a Conditional Access policy that only permits sign-in from the firm's stated source addresses. Neither is as clean as an expiring grant. Both beat a standing administrator.

The evidence: take your own copy before theirs leaves

Whatever the responders collect becomes the record of your incident. An insurer reads it, a regulator asks for it, and you would need it if you ever disagreed with the firm's account of events. NIST SP 800-61 Rev. 3 frames incident response as a risk management function the organization owns, and ownership of the evidence is part of that.

Two steps, both free. Copy triage output, images, and exported logs to storage you control and hash them, so your file can be matched to theirs. Then confirm your audit logging retains data before you grant access. Default retention in many tenants is shorter than the engagement.

The channel: the person talking to the attacker holds no admin

Keep the negotiation and the remediation in different hands. Different firms if you can afford it, different named people at minimum. The person speaking to an extortionist should not be able to read your mail, change your tenant, or see your detection coverage, because that combination lets one party shape both sides of the picture you are making decisions from.

Treat the attacker's inventory claim as a claim. Ask the responders which of your own log sources supports each item on the stolen-data list, then look at those sources yourself. If the only evidence that a dataset was taken is a screenshot relayed by a negotiator, you are paying against an assertion. Finally, write down who may authorize a payment before you need one. Two named approvers and counsel, with sanctions screening, keeps that decision out of the hands of whoever is most tired at 3 a.m.

Verify the engagement from your own logs

The control that makes the rest credible is reconstruction. When the engagement ends you should be able to list every action the vendor's accounts took, in order, from telemetry you own, without asking the vendor for anything. Entra ID keeps both halves of that: audit logs for directory changes and sign-in logs for access. Joined in Sentinel or any Log Analytics workspace, they produce the engagement timeline.

// Everything the responder accounts did, in one timeline.
let responders = dynamic(["ir.jdoe.vendorname@contoso.onmicrosoft.com"]);
let window = datetime(2026-10-10T00:00:00Z) .. datetime(2026-10-13T00:00:00Z);
union
  ( SigninLogs
    | where TimeGenerated between (window)
    | where UserPrincipalName in~ (responders)
    | project TimeGenerated, Action = "sign-in",
              Actor  = UserPrincipalName,
              Target = AppDisplayName,
              Detail = strcat(IPAddress, " / result ", tostring(ResultType)) ),
  ( AuditLogs
    | where TimeGenerated between (window)
    | where tostring(InitiatedBy.user.userPrincipalName) in~ (responders)
    | project TimeGenerated, Action = OperationName,
              Actor  = tostring(InitiatedBy.user.userPrincipalName),
              Target = tostring(TargetResources[0].displayName),
              Detail = tostring(Result) )
| sort by TimeGenerated asc

Reading the output

A clean engagement produces a boring table. Sign-ins from the addresses the firm gave you, read operations against the systems named in the scope, and a short tail of directory changes that each map to something you asked for. Three patterns deserve a question before you close the ticket: access from an address nobody declared, a role or permission change the responders never mentioned, and any sign-in after the date the engagement ended. The last one is the most common finding and the least sinister, because expiry is usually forgotten rather than abused. It is also the one that leaves a vendor-shaped administrator in your tenant for the next year.

Run the same query against your MSP's accounts while you are in there. The access model is identical and nobody set an end date on that one either.

Write the responder access terms before you need them

Draft one page and attach it to the insurance policy and the MSP contract this month. Named accounts for named people. The specific role each will hold. An expiry date. Session logging on privileged access. Your copy of the evidence, hashed, before anything leaves. Data handling, sub-processors, deletion date, written attestation. Who may speak to the attacker, and who may authorize a payment. An afternoon of writing now replaces an argument you would otherwise have with an unvetted firm while your systems are down.

If you want the annex drafted and the response plan tested against it before you need either, that is work we do. We build and exercise incident response playbooks for small and mid-size organizations, including the third-party access terms most plans leave out.