You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/aws/post_exploitation/iam_rogue_oidc_identity_provider.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,19 +24,19 @@ This technique involves deploying an OIDC web server, creating an OIDC Identity
24
24
25
25
Before we begin, you will need a domain for this technique. AWS doesn't accept as OIDC Identity Providers IP addresses or domains that use self-signed certificates.
26
26
27
-
1. Start an EC2 instance
27
+
### 1. Start an EC2 instance
28
28
29
29
> Environment: attacker
30
30
31
31
You will need a server to deploy the web OIDC Identity Provider (IdP). This server should expose port 443 to the internet.
32
32
33
-
2. Configure a DNS record
33
+
### 2. Configure a DNS record
34
34
35
35
> Environment: attacker
36
36
37
37
Add an A DNS record for a subdomain that will point to the IP of the EC2 instance. For the rest of the article we will assume that the subdomain is named `oidc` and the domain is `example.com`.
38
38
39
-
3. Connect to the instance and download Rogue OIDC IdP server
39
+
### 3. Connect to the instance and download Rogue OIDC IdP server
Verify that `https://odic.example.com/.well-known/openid-configuration` is accessible and reflects the configurations made.
106
106
107
-
8. Create the OIDC provider
107
+
### 8. Create the OIDC provider
108
108
109
109
> Environment: victim
110
110
@@ -114,15 +114,15 @@ This command will be executed using the compromised identity from the victim's a
114
114
aws --profile compromised_user iam create-open-id-connect-provider --url https://oidc.example.com --client-id-list oidc_client
115
115
```
116
116
117
-
9. Persistence
117
+
### 9. Persistence
118
118
119
119
> Environment: victim
120
120
121
121
There are two ways to achieve persistence. The first involves creating a role with a trust policy for the OIDC IdP and attaching a policy to it afterwards. This might be easily detected.
122
122
123
123
The second one involves modifying the trust role policy of an existing role. While this is still a well-known persistence technique, combining it with an OIDC IdP may evade detection by some tools and defenders.
124
124
125
-
9.1 Create a new role with this OIDC Identity Provider in the trust policy
125
+
#### 9.1 Create a new role with this OIDC Identity Provider in the trust policy
126
126
127
127
The trust role policy document can be found below. Make sure it matches the client ID and subject configured in the Rogue OIDC server.
Now you just created an administrator role that can be assumed with the last step from the article. Keep in mind that is enough to create a role, without attaching any policies for doing a PoC.
159
159
160
-
9.2 Modify the role trust policy of an existing role
160
+
#### 9.2 Modify the role trust policy of an existing role
161
161
162
162
With this method you would ideally get the trust policy of an existing role, modify it by adding your OIDC provider and update the role with the new policy document. This way, the role would continue to work, but it would also be backdoored.
163
163
164
164
```bash
165
165
aws --profile compromised_user iam update-assume-role-policy --role-name poc-random-string --policy-document file://policy.json
166
166
```
167
167
168
-
10. Assume the role
168
+
### 10. Assume the role
169
169
170
170
Finally, you can now assume the role at any time. The script for assuming it is in the same repository as the Rogue web OIDC IdP.
0 commit comments