Merge pull request #355 from Hacking-the-Cloud/update/add_cards_user_…

…data_script_persistence

Added cards to user-data-script-persistence and added link to IAM persistence methods article

CONTRIBUTING.md

@@ -84,6 +84,11 @@ If you'd like to use a card, for [example](https://hackingthe.cloud/aws/post_exp
 
     - 
 
+-   :material-link-box-outline:{ .lg .middle } __Technique Article__
+
+    ---
+
+    - 
 </div>
 ```
 

content/aws/post_exploitation/iam_persistence.md

@@ -112,5 +112,14 @@ By maintaining access to an EC2 instance which has a role with the permissions y
     ---
 
     - [Lambda Persistence](https://hackingthe.cloud/aws/post_exploitation/lambda_persistence/)
+</div>
+
+## User Data Script Persistence
+
+<div class="grid cards" markdown>
+-   :material-link-box-outline:{ .lg .middle } __Technique Article__
+
+    ---
 
+    - [User Data Script Persistence](https://hackingthe.cloud/aws/post_exploitation/user_data_script_persistence/)
 </div>

content/aws/post_exploitation/user_data_script_persistence.md

@@ -7,8 +7,22 @@ description: Maintain access to an EC2 instance and it's IAM role via user data
 When using EC2 instances a common design pattern is to define a [user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) script to be run when an instance is first started or after a reboot. These scripts are typically used to install software, download a config, etc. Additionally these scripts are run as root or System which makes them even more useful. Should we gain access to an EC2 instance we may be able to persist by abusing user data scripts via two different methods.
 
 ## Modify the User Data Script
-**Required IAM Permission**: [modify-instance-attribute](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-attribute.html)  
-**Recommended but not required**: [start-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/start-instances.html), [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html), [stop-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/stop-instances.html) (makes things go faster, requires less enumeration. The instance must be stopped to alter the user data)  
+
+<div class="grid cards" markdown>
+-   :material-shield-lock:{ .lg .middle } __Required IAM Permissions__
+
+    ---
+
+    - [modify-instance-attribute](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-attribute.html)
+
+-   :material-shield-plus:{ .lg .middle } __Recommended but not Required IAM Permissions__
+
+    ---
+
+    - [ec2:StartInstances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/start-instances.html)
+    - [ec2:DescribeInstances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html)
+    - [ec2:StopInstances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/stop-instances.html)
+</div>
 
 If we have permission to directly modify the user data scripts, we can potentially persist by adding our own backdoor to it. To do this, we must stop the instance because user data scripts can only be modified when the instance is stopped. You could theoretically wait for this to happen naturally, have a script that constantly tries to modify it, or stop it yourself if you have permissions to do so.