diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
index d04f7c1f7..2eb68a660 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
@@ -6,9 +6,9 @@
 
 ### `sts:AssumeRole`
 
-모든 role은 **role trust policy**와 함께 생성됩니다. 이 정책은 **누가 생성된 role을 assume할 수 있는지**를 나타냅니다. **동일한 계정**의 role이 어떤 계정이 이를 assume할 수 있다고 명시하면, 그 계정은 해당 role에 접근할 수 있게 되며(그리고 잠재적으로 **privesc**) 권한 상승이 발생할 수 있습니다.
+모든 역할은 **역할 신뢰 정책**과 함께 생성됩니다. 이 정책은 **누가 생성된 역할을 assume할 수 있는지**를 나타냅니다. 같은 계정(**same account**)의 역할이 특정 계정이 자신을 assume할 수 있도록 허용하면, 그 계정은 해당 역할에 접근할 수 있게 되고(잠재적으로 **privesc**) 합니다.
 
-예를 들어, 다음 role trust policy는 누구나 해당 role을 assume할 수 있음을 나타내므로, 따라서 **어떤 사용자든 해당 role과 연관된 권한으로 privesc할 수 있습니다**.
+예를 들어, 다음 역할 신뢰 정책은 누구나 해당 역할을 assume할 수 있음을 나타내며, 따라서 **어떤 사용자든 해당 역할에 연결된 권한으로 privesc할 수 있다**.
 ```json
 {
 "Version": "2012-10-17",
@@ -23,21 +23,22 @@
 ]
 }
 ```
-다음 명령을 실행하여 역할을 가장할 수 있습니다:
+다음 명령을 실행하는 역할을 가장할 수 있습니다:
 ```bash
 aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
 ```
-**잠재적 영향:** Privesc to the role.
+**Potential Impact:** 역할에 대한 Privesc.
 
 > [!CAUTION]
-> 이 경우 권한 `sts:AssumeRole` 는 공격자가 가진 정책에 있는 것이 아니라 **남용할 역할에 명시되어야 한다.**\
-> 한 가지 예외를 제외하고, 다른 계정의 역할을 **가정하려면** 공격자 계정은 해당 역할에 대해 **또한** **`sts:AssumeRole`** 권한을 가지고 있어야 한다.
+> 이 경우 권한 `sts:AssumeRole` 는 **남용하려는 역할에 표시되어 있어야** 하며 공격자에게 속한 정책에 있어서는 안 된다는 점에 유의하라.\
+> 예외가 하나 있는데, **다른 계정의 역할을 assume하려면** 공격자 계정도 해당 역할에 대해 **`sts:AssumeRole`** 권한을 **보유해야** 한다.
+
 
 ### `sts:AssumeRoleWithSAML`
 
-이 역할의 trust policy는 **SAML로 인증된 사용자가 역할을 대리(impersonate)할 수 있는 접근을 허용한다.**
+이 역할을 가진 신뢰 정책은 **SAML로 인증된 사용자에게 해당 역할을 가장할 수 있는 액세스 권한을 부여한다.**
 
-An example of a trust policy with this permission is:
+이 권한을 가진 신뢰 정책의 예는:
 ```json
 {
 "Version": "2012-10-17",
@@ -58,11 +59,11 @@ An example of a trust policy with this permission is:
 ]
 }
 ```
-일반적으로 role을 가장하여 credentials를 생성하려면 다음과 같이 사용할 수 있습니다:
+일반적으로 역할을 사칭하기 위한 자격 증명을 생성하려면 다음과 같은 것을 사용할 수 있습니다:
 ```bash
 aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
 ```
-하지만 **프로바이더**는 이를 더 쉽게 해주는 **자체 도구**를 제공할 수 있습니다, 예: [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+하지만 **공급자들은** 이를 더 쉽게 하기 위해 **자체 도구**를 제공할 수 있습니다. 예: [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
 ```bash
 onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
 ```
@@ -70,9 +71,9 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --
 
 ### `sts:AssumeRoleWithWebIdentity`
 
-이 권한은 웹 identity provider와 함께 모바일, 웹 애플리케이션, EKS 등에서 인증된 **사용자들**에게 임시 보안 자격 증명 세트를 얻을 수 있는 권한을 부여합니다. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+이 권한은 웹 아이덴티티 공급자와 함께 모바일, 웹 애플리케이션, EKS... 등에서 인증된 **사용자들**이 임시 보안 자격증명 세트를 얻을 수 있도록 허용합니다. [자세히 보기.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
 
-For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like:
+예를 들어, **EKS service account**가 **IAM role을 impersonate**할 수 있어야 한다면, **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`**에 토큰이 존재하고 다음과 같이 **역할을 assume하고 자격증명을 얻을 수 있습니다**:
 ```bash
 aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
 # The role name can be found in the metadata of the configuration of the pod
@@ -85,9 +86,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
 
 ### IAM Roles Anywhere Privesc
 
-AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 certificates를 사용해 IAM roles를 맡을 수 있도록 허용합니다. 그러나 trust policies가 적절히 범위(scope) 지정되지 않으면 권한 상승에 악용될 수 있습니다.
+AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 certificates를 사용해 IAM roles를 assume할 수 있도록 합니다. 그러나 trust policies가 적절히 범위 지정되지 않으면 privilege escalation에 악용될 수 있습니다.
 
-이 정책은 어떤 trust anchor나 certificate attributes가 허용되는지에 대한 제한이 없습니다. 결과적으로, 계정 내의 어떤 trust anchor에 묶인 어떤 certificate라도 이 역할을 맡는 데 사용할 수 있습니다.
+이 공격을 이해하려면 trust anchor가 무엇인지 설명해야 합니다. AWS IAM Roles Anywhere의 trust anchor는 신뢰의 루트 엔터티로, 계정에 등록된 Certificate Authority (CA)의 공개 인증서를 포함하여 AWS가 제시된 X.509 certificates를 검증할 수 있도록 합니다. 따라서 client certificate가 해당 CA에서 발급되었고 trust anchor가 활성화되어 있으면 AWS는 이를 유효한 것으로 인식합니다.
+
+또한 profile은 X.509 certificate의 어떤 속성(CN, OU, or SAN 등)이 session tags로 변환될지를 정의하는 구성이며, 이 태그들은 이후 trust policy의 조건과 비교됩니다.
+
+이 정책은 어떤 trust anchor나 certificate attributes가 허용되는지에 대한 제한이 없습니다. 결과적으로 계정 내의 어떤 trust anchor에 묶여 있는 어떤 certificate라도 이 role을 assume하는 데 사용할 수 있습니다.
 ```json
 {
 "Version": "2012-10-17",
@@ -107,9 +112,9 @@ AWS IAM RolesAnywhere는 AWS 외부의 워크로드가 X.509 certificates를 사
 }
 
 ```
-privesc를 위해 `aws_signing_helper`가 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 에서 필요합니다
+privesc하려면 `aws_signing_helper`는 https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html 에서 필요합니다.
 
-그런 다음 유효한 인증서를 사용하여 공격자는 더 높은 권한의 role로 pivot할 수 있습니다
+그런 다음 유효한 인증서를 사용하면 attacker가 더 높은 권한의 역할로 피벗할 수 있습니다.
 ```bash
 aws_signing_helper credential-process \
 --certificate readonly.pem \
@@ -118,13 +123,13 @@ aws_signing_helper credential-process \
 --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
 --role-arn arn:aws:iam::123456789012:role/Admin
 ```
-The trust anchor은 클라이언트 인증서 `readonly.pem`이 권한 있는 CA에서 발급되었는지 검증합니다. trust anchor를 생성할 때 CA의 공개 인증서가 포함되었고(현재 `readonly.pem` 검증에 사용됨), `readonly.pem` 내부에는 공개 키가 들어 있어 AWS가 해당 서명이 대응하는 개인 키 `readonly.key`로 만들어졌는지 확인하는 데 사용합니다.
+trust anchor는 클라이언트의 `readonly.pem` 인증서가 권한 있는 CA에서 발급되었는지 검증하며, 이 `readonly.pem` 인증서 안에는 AWS가 서명이 대응하는 개인키 `readonly.key`로 만들어졌는지를 검증하는 데 사용하는 공개키가 포함되어 있다.
 
-이 인증서는 또한 신원을 증명하고 CN 또는 OU와 같은 속성들을 제공하며, `default` 프로파일은 이를 태그로 변환합니다. 역할의 trust policy는 이러한 태그를 사용해 접근 허용 여부를 결정할 수 있습니다. trust policy에 조건이 없다면 해당 태그들은 무시되고 유효한 인증서를 가진 누구나 통과할 수 있습니다.
+인증서는 CN 또는 OU와 같은 속성도 제공하는데, `default` 프로파일이 이를 태그로 변환하며 역할의 trust policy는 이 태그들로 접근 허가 여부를 결정할 수 있다. trust policy에 조건이 없다면, 그 태그들은 아무 쓸모가 없고 유효한 인증서를 가진 누구에게나 접근이 허용된다.
 
-이 공격이 가능하려면 trust anchor와 `default` 프로파일 둘 다 활성 상태여야 합니다.
+이 공격이 가능하려면 trust anchor와 `default` 프로파일 둘 다 활성 상태여야 한다.
 
-### References
+### 참고자료
 
 - [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)