competition-linux-credential-pivot

Name: competition-linux-credential-pivot
Author: zhaoxuya520

8.8kstars1.4kforks

How to install competition-linux-credential-pivot?

zhaoxuya520/reverse-skill/competition-linux-credential-pivot

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-linux-credential-pivot

Installs into the current project.

Summary

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Linux credential artifacts, service tokens, SSH material, cloud and container secrets, socket-level trust, and host-to-host pivot chains. Use when the user asks to trace Linux auth artifacts, accepte

Files · 1

View on GitHub

SKILL.md

1	# Competition Linux Credential Pivot
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive edge is Linux credential material and where that material is accepted.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Separate credential storage from accepted privilege.
12	2. Record user, process, namespace, socket, key file, and service trust boundary before conclusions.
13	3. Keep artifact recovery, replay path, and resulting capability in one chain.
14	4. Distinguish local escalation from lateral host pivot.
15	5. Reproduce one minimal artifact-to-accepted-access path.
16
17	## Workflow
18
19	### 1. Map Credential And Trust Artifacts
20
21	- Record SSH keys, agent sockets, kubeconfigs, cloud tokens, service-account secrets, env vars, config files, and process memory clues.
22	- Note sudoers rules, capabilities, setuid binaries, systemd unit context, and namespace boundaries.
23	- Keep each artifact tied to owner, scope, and expected accepting service.
24
25	### 2. Prove Replay And Pivot
26
27	- Show where key, token, socket, or secret is accepted: SSH, API, Unix socket, container runtime, or control-plane endpoint.
28	- Record host target, protocol, principal, and resulting session or privilege.
29	- Distinguish authentication success from useful capability gain.
30
31	### 3. Reduce To Decisive Linux Pivot Chain
32
33	- Compress to: recovered artifact -> accepted replay path -> pivot host or privilege transition -> resulting capability.
34	- State whether root cause is weak key handling, token leakage, socket trust, sudo or capability abuse, or namespace crossover.
35	- If the chain pivots into kernel exploit boundaries, hand off to kernel container escape skill.
36
37	## Read This Reference
38
39	- Load `references/linux-credential-pivot.md` for artifact checklists, replay matrix, and evidence packaging.
40
41	## What To Preserve
42
43	- Artifact path, owner, scope, accepting service, and resulting principal
44	- Exact pivot order with protocol and target host or namespace
45	- One minimal replayable chain proving capability gain

People who liked this also viewed

6 picks

Type

competition-linux-credential-pivot

8.8kstars1.4kforks

View on GitHub

How to install competition-linux-credential-pivot?

zhaoxuya520/reverse-skill/competition-linux-credential-pivot

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-linux-credential-pivot

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Competition Linux Credential Pivot
2
3	Use this skill only as a downstream specialization after `$ctf-sandbox-orchestrator` is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to `$ctf-sandbox-orchestrator` first.
4
5	Use this skill when the decisive edge is Linux credential material and where that material is accepted.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Separate credential storage from accepted privilege.
12	2. Record user, process, namespace, socket, key file, and service trust boundary before conclusions.
13	3. Keep artifact recovery, replay path, and resulting capability in one chain.
14	4. Distinguish local escalation from lateral host pivot.
15	5. Reproduce one minimal artifact-to-accepted-access path.
16
17	## Workflow
18
19	### 1. Map Credential And Trust Artifacts
20
21	- Record SSH keys, agent sockets, kubeconfigs, cloud tokens, service-account secrets, env vars, config files, and process memory clues.
22	- Note sudoers rules, capabilities, setuid binaries, systemd unit context, and namespace boundaries.
23	- Keep each artifact tied to owner, scope, and expected accepting service.
24
25	### 2. Prove Replay And Pivot
26
27	- Show where key, token, socket, or secret is accepted: SSH, API, Unix socket, container runtime, or control-plane endpoint.
28	- Record host target, protocol, principal, and resulting session or privilege.
29	- Distinguish authentication success from useful capability gain.
30
31	### 3. Reduce To Decisive Linux Pivot Chain
32
33	- Compress to: recovered artifact -> accepted replay path -> pivot host or privilege transition -> resulting capability.
34	- State whether root cause is weak key handling, token leakage, socket trust, sudo or capability abuse, or namespace crossover.
35	- If the chain pivots into kernel exploit boundaries, hand off to kernel container escape skill.
36
37	## Read This Reference
38
39	- Load `references/linux-credential-pivot.md` for artifact checklists, replay matrix, and evidence packaging.
40
41	## What To Preserve
42
43	- Artifact path, owner, scope, accepting service, and resulting principal
44	- Exact pivot order with protocol and target host or namespace
45	- One minimal replayable chain proving capability gain

People who liked this also viewed

6 picks

Type