A manufacturing estate, assessed from a position inside the network by a Security Brigade team. No step in the chain below was a defect in a product. Each one was a decision about where a credential lived, which account carried it and what that account had been granted — and each step names the weakness it maps to and what it handed the next.
The chain, step by step
Each row names the technique, the weakness it maps to and what the step yielded. A finding that hands nothing to the next step is a finding, and belongs in the report rather than here.
| Step | What it yielded | Severity |
|---|---|---|
| 01 · A management function answering anybody | A configuration export naming the deployment share and the service account used to mount it. | High |
| An internal host exposed a management function that returned its stored configuration to a request carrying no session, no key and no credential, reachable from the network segment the engagement started on — CWE-306, Missing Authentication for Critical Function. | ||
| 02 · A password written into a build script | A working password for a service account, and the account name to use it with. | Critical |
| The deployment share the export named held the workstation build script, and the service account’s password was written into it in clear text, readable by any account that could read the share — CWE-798, Use of Hard-coded Credentials. | ||
| 03 · The same password accepted elsewhere | Administrative sessions on hosts beyond the one the share belonged to. | High |
| The recovered credential was tested against the other hosts the account was configured on and authenticated on them — one password, accepted everywhere the account had been deployed — CWE-522, Insufficiently Protected Credentials. | ||
| 04 · A second credential left on an administered host | A second identity, this one holding a directory permission the first did not. | High |
| A scheduled task definition on one of those hosts named a second account and pointed at the file its password was read from, and the account running the task could read that file — CWE-200, Information Exposure. | ||
| 05 · A write permission on a nested group | Domain administrator rights, which is where the scope’s stop line sat and where the run ended. | Critical |
| The second account held write access to a group whose membership was nested inside a privileged directory role, so adding an account to the group conferred the role’s rights without touching the role itself — CWE-284, Improper Access Control. | ||
01 · A management function answering anybody
An internal host exposed a management function that returned its stored configuration to a request carrying no session, no key and no credential, reachable from the network segment the engagement started on — CWE-306, Missing Authentication for Critical Function.
02 · A password written into a build script
The deployment share the export named held the workstation build script, and the service account’s password was written into it in clear text, readable by any account that could read the share — CWE-798, Use of Hard-coded Credentials.
03 · The same password accepted elsewhere
The recovered credential was tested against the other hosts the account was configured on and authenticated on them — one password, accepted everywhere the account had been deployed — CWE-522, Insufficiently Protected Credentials.
04 · A second credential left on an administered host
A scheduled task definition on one of those hosts named a second account and pointed at the file its password was read from, and the account running the task could read that file — CWE-200, Information Exposure.
05 · A write permission on a nested group
The second account held write access to a group whose membership was nested inside a privileged directory role, so adding an account to the group conferred the role’s rights without touching the role itself — CWE-284, Improper Access Control.
The environment
An internal engagement begins from a position an attacker would have to earn. This one was given that position, and the question was what could be reached from it.
The estate was an ordinary one: a directory holding the accounts and the groups, file shares that hold what file shares hold, build and deployment tooling that provisions workstations without anybody watching it, and service accounts created for jobs that are older than the people now administering them. The engagement started from a single authenticated position on the internal network — no administrative rights, no special knowledge, the access a new joiner or a phished user would have — and the scope set a stop line at domain administrator, on the understanding that proving the rights was the point and exercising them further was not. This is also the one kind of work B-52 does that needs something deployed inside the customer network. External network testing and every application class need nothing at all on your side, because the targets answer from outside and that is the premise of the assessment. Internal work has no such premise: it has to start from somewhere inside, so something has to be there to start from. On-premise and customer-VPC deployments both exist for it.
Starting conditions
Each of these is a configuration decision rather than a vulnerability, which is why an estate in this condition reads as clean in a scanner’s output.
Deployment automation needs an account with rights, and that account’s password has to reach the script that uses it. Where it reaches the script in clear text, the file stops being a script and becomes the credential.
A service account running on a fleet is doing precisely the job it was created for. It also means one password is accepted wherever the account was deployed, and every host that accepts it is a place the password can be tried.
SedimentMemberships and delegations get granted for a project and kept afterwards. Nobody revokes what nobody remembers granting, and the directory keeps the grant long after the project that needed it is finished.
Management interfaces get built on the assumption that reaching them is the authentication. That assumption holds exactly until somebody is on the segment who should not be, which is the position this engagement was given.
How it joined up
The table above lists what was done. What it cannot show is the property every row shares.
Every operation in this chain was permitted. The account was allowed to read the share. The password was accepted on the hosts where the account had been configured, because that is what configuring it means. The scheduled task was readable by the identity that ran it. The group was writable by an account that had been given write access to it, once, for a reason. There is no version number anywhere in the chain and nothing to patch, which is why a report of this shape is hard to act on if it arrives as a list: each row, read alone, is defensible, and the person who granted it can say so. What made the sequence an attack was the order, and order is only visible to something that tries the next step.
The junctions
A chain is decided at the joins rather than at the steps. Each rung names the assumption that let one step be carried into the next.
Naming
The configuration that came back was not sensitive in itself. It named a share and it named an account, and neither name grants anything. What it removed was the search: the difference between a foothold and a foothold that knows where the credentials are kept.
Trust
A deployment share has to be readable by the machines being deployed, which in practice means readable by the accounts on them. The permission was correct for the job. The file sitting inside it was what made the permission matter.
Reuse
Nothing was bypassed to move between hosts. The credential was offered and accepted, exactly as it was designed to be. Lateral movement here is not an exploit — it is the intended behaviour of a shared identity, used by the wrong holder.
Grant
Everything before this point was access to hosts. The write permission on the group was the first thing that touched the directory, and it converted a position on the network into a right in the identity system. That conversion is the join worth defending, and it is where the remediation below starts.
What the report carried
Every finding carries a reproducible exploit artefact: the request as sent, the response as returned, the steps that reproduce it, a CVSS v4.0 vector and a CWE. On an internal chain the artefact has to carry the sequence as well, because a step read alone looks like a setting nobody would change.
| Step | What the artefact was | What could be re-run |
|---|---|---|
| 01 · Unauthenticated function | The request as sent to mgmt-01.corp.example and the response as returned, with the fields of the configuration export that mattered marked and the remainder redacted. | Repeat the request from the same segment with no credential attached, and read what comes back. |
| 02 · Password in the script | The path on deploy.corp.example, the permissions on it as read, and the line of the build script with the credential masked. The password itself is not in the report. | Read the same path as an ordinary domain account and open the same file. |
| The masking is a convention rather than a courtesy: a credential written into a report is a credential in every mailbox that report reaches. | ||
| 03 · The same password elsewhere | The host list the credential was offered to, the result per host, and the time of each attempt. | Match the attempt times against the authentication logs and see which of them was recorded. |
| This is the row a detection team reads first. What the report says was done, set against what their own logs saw, is the more useful half of the finding. | ||
| 04 · A stored credential | The scheduled task definition as read, the file path it referenced, and the access control list on that file. | Read the same definition from any account holding the rights that one held. |
| 05 · The nested group | The permission on the group as read from the directory, the nesting between that group and the privileged role, and the rights the role carried. Membership was added and then removed, and both changes are in the artefact with their times. | Re-read the permission and the nesting from any account that can query the directory. |
| Where a step changes something, the report carries the change and its reversal, so the record can be matched against the customer’s own audit trail rather than taken on trust. | ||
01 · Unauthenticated function
02 · Password in the script
The masking is a convention rather than a courtesy: a credential written into a report is a credential in every mailbox that report reaches.
03 · The same password elsewhere
This is the row a detection team reads first. What the report says was done, set against what their own logs saw, is the more useful half of the finding.
04 · A stored credential
05 · The nested group
Where a step changes something, the report carries the change and its reversal, so the record can be matched against the customer’s own audit trail rather than taken on trust.
Measurement
It belongs to the platform rather than to this engagement.
Deliberately excluded
What changed
A retest closes a finding by trying it again. The last row here is the one a retest cannot close, and it is recorded that way rather than counted as done.
| State | What it means | What follows |
|---|---|---|
| The credential out of the file | The password came out of the build script, which moved to fetching it at run time from the secret store the estate already ran. The account was rotated on the assumption that the old password was already public, because a credential sitting in a readable file has to be treated as one. | Confirmed by re-reading the share as an ordinary domain account. |
| Authentication in front of the function | The management function stopped answering unauthenticated requests, and the segment it listened on was narrowed to the hosts that actually administer it. | Confirmed by repeating the original request with no credential attached. |
| The reuse broken | The service account stopped carrying one password across the fleet. Where a per-host identity was not workable, the account’s rights were cut back to the hosts that needed them. | Confirmed by offering the old credential across the same host list again. |
| The delegation removed | The write permission on the group was revoked and the group was taken out of the privileged role’s nesting. This is the change that breaks the chain rather than shortening it: with it gone, everything above still stops at step 04. | Confirmed by walking the path again from the same starting position. |
| The review that has to repeat Terminal | Permissions and delegations accumulate, and a directory that is correct today stays correct only until the next project needs something. What was agreed here is a recurring review of write permissions on groups nested into privileged roles. | No retest closes this one. It is a schedule rather than a setting. |
Order of work
Deleting a password from a script is the easiest change on the list, and it is the first thing anybody does. It also closes step 02 and leaves steps 03, 04 and 05 standing: any other route to that account — a backup of the share, a copy of the script in version control, an administrator who remembers the password — arrives at exactly the same place. Sorting remediation by severity puts that change first because the hard-coded credential is the loudest finding on the page. Sorting it by the chain puts the delegation first, because removing the write permission on the group leaves nothing downstream of it reachable at all. Both orders were in the report, set out as two lists rather than one, and the retest followed the chain order. That is the argument for reconstructing a chain in the first place: severity ranks findings against each other, and only the chain says which finding is holding the others up.
How it ran
All three delivery models cover the same eleven coverage classes and run the same six phases — discovery, planning, scanning, exploitation, reporting, and a QA gate that reads the finished report and can send it back. What differs is who is in the room, and whose signature the report goes out under.
What it needed
Internal work is the one class that starts from a position inside your network. Every other class needs nothing deployed with you.
Internal work starts from a position inside the network, so something has to be there to provide it. On-premise, or inside your own virtual private cloud — both exist, and which one is a scoping question rather than a product tier.
Everything elseExternal network testing and every application class need nothing inside your network. The targets answer from outside, which is the premise of that work, and a pipeline integration is a call out from your runner rather than anything inbound.
ResidencyIndia, the European Union, the United States, or Singapore and Asia-Pacific, chosen by you. An internal engagement produces artefacts that name hosts and accounts, so where they sit is part of the scope rather than an afterthought.
ApprovalsScope sign-off, the stop line and the changes made during the run are recorded rather than remembered. On work that proves privileged rights, the audit trail is what lets the customer tell an assessment from an incident.
Internal network and Active Directory work is scoped rather than bought from a card — the self-serve flow reaches the five application classes. One scan of one application or target is $500 and a paid trial is $299; anything wider than a single target is a scoping call.