From d558cea9ae42bc44714172cf349843f69c9f201c Mon Sep 17 00:00:00 2001 From: eric-forte-elastic Date: Wed, 19 Mar 2025 20:03:55 -0400 Subject: [PATCH] Revert "Add new ML detection rules for Privileged Access Detection (#4516)" This reverts commit 2ff8d1bb567aa1360febad2688074d26b959afbb. --- .github/workflows/react-tests-dispatcher.yml | 1 - .../etc/integration-manifests.json.gz | Bin 15863 -> 15578 bytes .../etc/integration-schemas.json.gz | Bin 5145013 -> 5141685 bytes detection_rules/schemas/definitions.py | 2 +- pyproject.toml | 2 +- ...unt_privileged_process_events_by_user.toml | 99 --------------- ..._process_command_line_entropy_by_user.toml | 99 --------------- ...l_linux_rare_process_executed_by_user.toml | 98 --------------- ..._high_sum_concurrent_sessions_by_user.toml | 103 --------------- ...access_ml_okta_rare_host_name_by_user.toml | 99 --------------- ...cess_ml_okta_rare_region_name_by_user.toml | 99 --------------- ...access_ml_okta_rare_source_ip_by_user.toml | 98 --------------- ..._group_application_assignment_changes.toml | 108 ---------------- ...okta_spike_in_group_lifecycle_changes.toml | 103 --------------- ...kta_spike_in_group_membership_changes.toml | 103 --------------- ...okta_spike_in_group_privilege_changes.toml | 108 ---------------- ..._in_user_lifecycle_management_changes.toml | 102 --------------- ...ws_high_count_group_management_events.toml | 105 ---------------- ...ndows_high_count_special_logon_events.toml | 102 --------------- ...gh_count_special_privilege_use_events.toml | 104 --------------- ..._count_user_account_management_events.toml | 104 --------------- ...access_ml_windows_rare_device_by_user.toml | 99 --------------- ...ss_ml_windows_rare_group_name_by_user.toml | 119 ------------------ ...ndows_rare_privilege_assigned_to_user.toml | 104 --------------- ...s_ml_windows_rare_region_name_by_user.toml | 99 --------------- ...ess_ml_windows_rare_source_ip_by_user.toml | 98 --------------- 26 files changed, 2 insertions(+), 2156 deletions(-) delete mode 100644 rules/integrations/pad/privileged_access_ml_linux_high_count_privileged_process_events_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_linux_high_median_process_command_line_entropy_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_linux_rare_process_executed_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_high_sum_concurrent_sessions_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_rare_host_name_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_rare_region_name_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_rare_source_ip_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_spike_in_group_application_assignment_changes.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_spike_in_group_lifecycle_changes.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_spike_in_group_membership_changes.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_spike_in_group_privilege_changes.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_okta_spike_in_user_lifecycle_management_changes.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_high_count_group_management_events.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_high_count_special_logon_events.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_high_count_special_privilege_use_events.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_high_count_user_account_management_events.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_rare_device_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_rare_group_name_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_rare_privilege_assigned_to_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_rare_region_name_by_user.toml delete mode 100644 rules/integrations/pad/privileged_access_ml_windows_rare_source_ip_by_user.toml diff --git a/.github/workflows/react-tests-dispatcher.yml b/.github/workflows/react-tests-dispatcher.yml index 4418edc8a63..7e871429c8f 100644 --- a/.github/workflows/react-tests-dispatcher.yml +++ b/.github/workflows/react-tests-dispatcher.yml @@ -22,7 +22,6 @@ on: - '!rules/integrations/o365/*.toml' - '!rules/integrations/okta/*.toml' - '!rules/integrations/problemchild/*.toml' - - '!rules/integrations/pad/*.toml' jobs: dispatch: diff --git a/detection_rules/etc/integration-manifests.json.gz b/detection_rules/etc/integration-manifests.json.gz index df76b3ea8a3cdf69ae3dfe7fee6cca49ba9cf2df..4cc6c08403c999e516fa527ba52e0dd34eeeef5e 100644 GIT binary patch literal 15578 zcmZX*WmH^U6EzqtxVwem4#C~srE!Pg?ykX|Ai>?8;4T3IH0~DMX$bB%O`dnYnKkpL z_O04gyXqVkt8d?Xnj{(y?(1lt1>~ERy{nmpv$3m{gFU02vAvbKnTx9nleLS3{fEDd1(>T6_uRi1F@8GJ?(#zNuJlpDGQZ%Ump;&F`~7+It3W6k zpx2Vd3T(pQBdV8%pi%R)*|R&C7<+r&U-Nyn*Xep-H}usqNGUwdeEa@<$K}j)u=2`I z&zu?H{oH((%+}0&~ z*|J(mkxNy1Hxi&Yx@XNQYtU6`UU_vZdZpBG)Jepp`4E3>eL;fS^Exe*)zsqqT05eC z^)T(rnZw@l)0Skrf43kjEF4kP}C)qGawyRmEtfRa-^I zdW0@_D!{V^sUa>ab{1qC6jt}?xxU>`9p6OZ9lt)hPKO)I*f9BMq=A z)g;I@DXFXaE)Q+$zA2}Wd8>zoR3Iq{W0R^$6lhAot8Y1+rp|Bg6!~YBijyLl)5^5! zJNs43@_mVE;PeQTTu9Pamo~g;ca2s$Yau+#jmTz^luUYleQomufhCG71^t&XCxE zC6|Ai;(x3cO}ovPxUN7e@v{_O8S-9)#ZiX~PKq;STD@pmdI$6ggm#f@w~@f9i{L;( zx)iz)Ok%;hupvDcaqiOZl2n1`@SoA)h4EB?1#}Q0#!>tgZlxjUkz{lbaKWhk5zv;m zlP3-ajh!`C6w$}l-C6>L1N8^vLc~M+xqjv!K4o1lln2@XN6vbv-)L4|^5c4S)4k{k z9fnREh7QgIzotoTGWvF=q;nbjZKrwhajxgIz25rXcmT)vD3`A}%W|vO&S$gs%H)l#9XP*W`e{TA3 z?wl#(*mt;8+1P25O#6E#{OMhMl_aOOyk5Gog7GEu%X=O3kI^g4DTh;th~BX%UCw!_ zhjdv95<@dyWaVwvUh2&r9BtqCZ%cX}o)#|cQeD5)tS>C`*i3b2PY5xdmC;O>(@>Wd zNNVETb<7a~Byh8%p7b-~$_wHZ2NQ}p#M zGfv&Ue<+Faa-|Dn_&L_59#i9jIn^Q)kH!{VgMd^9(NO4^y3~pYb$3V*ohN?x^?x22 zXAf)@JxyG%A0FXd;2w1Ue`$gqJZC(MI|(snPr*N~GA%EINDw<=TZ9oMpnc&+_-bs#o!#9@MYiljgr*hZ*i-@i`I}@qvFAwtH zG{)`h9nJ)elvWW1^uB}-DZ}B>af^jo&}^D%!vX69Q_VK6ii2xBNi10SADyBgsCrAVV)c4i*wjRzBJnHODa7 z-l-rq*K?%s&6_Q>9znJ9whxqPh|1@9RTu+C*!;J}urYpiTsLVS=+ z4r(CmK~vry-KL%jXz@VF%E3Xm?SCSODCPX$1bBYcL!1i-qAoE#M11Khg?b6BpTFDG4Sj$xt32zo(C%_<$M$7oV9v6K z$?d!ag12GBrnbsn-LWc$oDNmc>y+4n@&gzIs5Q>L=yU5$upO(C6>#od^CrOq2ofJ& zm2#t9Bm`3 zlOw5!6nmB&4_X^atm%}w2aD0B8r6d1xFm_kUtiYuX486npFv7?^7c>s>E`L`R|72% zOyj!$J|Oc*1=95mn{k=ZQpsbQM z4GkiXS#e&~ZZa{9*^p%0>$SF*8%MUTXotmt9 zeRrJIspcIVsAuQfE3YCvui{F*7B^O(;X%giR(09vLV@?+m`Rw>r8dcxeX-)=MK7FS zcW05>j#De+@`#XV1RNzAVQ7%czlS|RQMTrpPUhXNz*^ZGI*uT4X%A9Xj+tV&aBhAw z02OX=VCh7f5M8=EKa6n~c@;yQ7;b2e8`M;cnqGHjbyfa|#fq-TqN*G*yJ3HLw9gPSE=(HNh2=tR&s7sw3xSMD7z|@Q ze1h9DAVokF4+@nAWWX#%0wGoIP=5{;3Jv~rbkoxlK-8T4t*+IIfUwwLC4g~%TGh6& z`mlY8B4=h?e#ij$ahbE7e0QLYfGBs(Ix%CX`saI5Vk^t%L|5(**>B2D=)4#qDA=T< z%0pWVp$vrt@iEHMXb4QAlpa1F72!q4@B>kZ_F^zkL~!&`S8s;E0YQ zgN8zi&Z)^L;fZ-lQ_-> zg&Ez-ervz_bZ&|$~a+_P1qOxn9__crI*&{sqWPeOJ1P09@eE%x$> zhn9&tbo2VG!=+QnOl_mHb@1aS(9KT}G2bh{_RAzFdcw!Gs^?_CHlgu|vH7aatFD`K z6q~~Om#D(`GFn&;5xV?es-k9hQKukD@eWbKkj6x3VKvAQ**X^pcXR|~5!4#rv2Dyzw% zV$L5su|dKh$dr*6Q43#(#N@zU=9FH2QVx*^@Olf2u#F!cLJUr`Q~zV*av-Mx+};Wp z>!xY~u#*sdE_&yIqT2*$7`SVK3^U{cc{FVw#YYB-({nydWAb_ zIQUcE69VR=?*@IkHw+9GlyrVld{EdEK08g`cRv(l1j{eVfx#F=%8)Kf1-ORUq;?q&E2oe?Un=1SNK0&j+VR5 zpX`{j=Wsn5k0LI-o?z{mmh|YvlJhds$~TE-mwm4233HBVv|c7Lw;d zw*Zo6(Nb^A^Te>-h#MVu8y`oq3m-~(56KGDU-j*z&{p*S-bs;ZGjpaUOWOG{k{cnP zqg!$g{^|lEgBkb)(wOwBh1C5_w2@;?1#$=ht0^v$x%^-sVfy=zT|gchga( zq4c{l6SY&vSK5Htx~XKo!#b;zAhu$U^iaR)eFlhU!??nN1yRb6j#Yxe-Wa z*&DK%mUcBc&`uJ_Np6&xR6mY7)ZAir_UI|3i1P=A`Y$Q%Us8H|(m}?o))cH3lkN31 zWT6ux3$en}drNw&fwH%8K2*_6cE_TZ+HxK^`YYV3$cBqpPO>W6Kga6fswK$m z%!{!O|AJ31-|}hwO^)X5r7v_SHg{u|_y#ag(v+D6)aJIPvh$+mN-hGH4vpkfDs-m& z+pS@XM(3nlOxNAi*4_Tu8`Je0we|n3!boRky=TkAkNMs4g3gSXE3V4B=nB0q{BdUH z(PbB12Z5(s#t^N5di@f%Y(?u|h1S)>wIE!7EkjnXo5!IEYkm*I$!@gfwT1o7mj=h% zhA9Rr#t?<*@QxgD$}niEq^`O@O{1)f`U9QWWF2(4mHQj++<%UyA=AsQk@Y1ozjrg4 z`(+=2zAh|gb_?#`F6N3pbsSX{NZCvmByu4Ourh!0Ye>5pm*3zw_q&=ZTClv1^>Uqi z!h!NZkr?1lbTZW$;6FYG+drZ5BaIPl9jV`~&|MZ8sAmfzw4%SsM;j05AeA>xMU-ZH za0h-#oGujP{YJ;+wzoS!A2C0lq`4?jRm11xM!D^-so1>+j;RB+J8oHmK&)m6T z3VvSyySL_|hgiWhwZDAhyFlQnGYaS|iZ@R!bZAAQ1cf1=q;w_{YzL$`G^)u zK%)2n?~q5$J0~bdsyLN(N{;mCC@^mvdAUaiMO+E*5S~uJEU&ceng~iDTy~Oe>MHFT z4^mC!>6|1ahjj{|<{cN5(_c)DbS><|kkjY$Y2N4EF8Tn4l~j&+K6>YM?Iq{0%c+36 z{{PTYdsh!NeT8(*Pt_HZKM$vM;)Umpl#WNx$ba?aIwZ(oQtJ6uBAzr}!pAUf1y>-9 zABXtcj0+N5qJ5xjJSpoLbZX9*seW6IKThOVBP~6zmqS7n0c9F{9>g*q#gC!|y_v6~ z_m)j>-BoG=JWXI}!h{>HdhbIZas#)&!rirDE%+hr7^Fh%V1D$4j8?)wr=<}LtBW2r zMr0QIGq_h5no4@Uji7ahjr5m3aIF;SUO5vbtTmUg0B8N2^sG-K(x*uMCWln{7z(nu zzkex~RP`7JheQmc0aeDtUZa>OkVK52!K3vVkF02Y=kjaB#l!WNXZx0ywl(j=5xW2b zNg&$Y6+XVIu`r#uG(M!BV5u{$*wpBODU7Z+lzMZW@*%a|1K zAtjCiM~Z3tf0G;q0*jF@TGh(*fM|tsVkWK-Hl^O8K(uB#;{RLnTVXk>fZ79%H2!w6 zm28+AUIGHPs+n*FxLd)am8AMPzUY*dVrVjHYbuVZbSOl*GAX#T{5Yl<94~QL4y-E$ zxUE`Q0v(iUvFI^g0xw-r4n+BZ2(S*1QH=MAo}6ZWxjEFkr{? zwLG*dC27A{f}WDE!Y|5KHTe==S0AfK;thLtWbC<8J71ovUS@I%Gh14SF$$Byk?(Mj z?ALA^$L--?_EK+~emf?q%&$4ckBlswdc-n;@DBc<7f^pYj7PZ`6ifB<9O37lO3?R- z`=AyPh#)wXJe*G(ECwJ8FCjuvC(DaMWhbY*#25QM85y{bB#cOw2Lm-liatdOt4s<> zha{W=N8?XlyTvbd7x}WfSbHd};-f_Uhw?ffDu+N7O110RSe|RM9Eam`2S^wzbU3;z zS7m`*g0z4p4=ZIj8UZ9BB|hD!N)c6330p!Vj->*UC}?dfsWYHJkO<2P^#2?selb*+ zG=(bqo#t@qEqz@;6^ksYtQt|Jv-u5k=BeN?!i4uFH+h{oe zfvaAu&C-x`4x3IbIr2&BS^Dt*30iHf7oM~hEKB#=j;ihrjeKzCNY=%YbE zmk25@6UV~-Q9xdBXhiEx7WL_eiL5vaOtCap@eQplp+Y13QfZwXyGqq+|L=AXA0~Jy z1{4`A=XGo!#bf0NnvbS)JpN9*WN^3Sgr5M`YdRiZK{?w0eL>3k_XN>4x@Fd0FBAC> zf8zO6>ir=-s$Xnu_xT(@hT(W2|22o;V_bN5^!M)nL&kUStL>zJ%-n{`wTO4X|uGC{M(z|-jx{8Bo0;(nFcfXFeJ!%E)#p1kGc1vG+`+c8) z{PVK!(-UHg^SZ4)?cs2NKcl&4GXK1qRFwL^=cyemE83}b1Y~+nTAjy8Ke0-7Lv+WJ74hr`O95q|f^QB(VJ&rzL32Y7n8P*~H0m499YW zT2PRiRU;v;QSQZNZ5_vD23cf}RUBnLRC%*yOwhd|b zpTkc;_Ru6{Dmx}bPy_x2UWVqUEDbez{%<;CqmW#MUs^tF1bbfu7viF$Rjak0Xar@O zW~Aq3^XHFQ1b;}-8M)Iz?te!}%Z&@fC=YZdfJ7l@4C=>Br||AXD6RZ<7I=fG+a$(K zl)9U;te)bF6Cjwc74z zK{7KR_QNI3-l&p9H<|21)Ra1@@1;!grOfpu2Nz2hkx&DS%9Skap#Ljv8=Vvh&_lgG zgL_uGWWoe!}eKN5n$?D~|1dncaHI59Aj)LHV$9<#o4KaJb zFVQrs@QS)ELGTy%nwuqdM1LNEjvQZPOvEp=L1e{JKCxaoY#cNp5;JDFwM z*}5%8q3dKSz1p2`)Y$B)m@j?U?q_|t0JT2J#EciOzJ(&WU1greSTevp}!bG6k)gHSZ>*=7y-o&vTOrYNZ-=eLV9am^@Eiv=JDzfL`E+WXblc zofEOl1~u;1sgsDrPPzBlh(D#~o86h0ZjQp`orou|XuwAbQj&xNd%w!kyzyfP{>o|J ze4;1?;h$}rn^WsQ+Y%lYp-eFKY=`XudbSAB3XX{7A8=Ls7>gkFq+wbT5S&S2>}6rv z7_oPck=y+NMvhTP6A;0OYcQvuH~GJC$0ISpd`u+^9u4d>8{Tv_a^zucg~ZbfLb8WL zviJPp*k!l5I}zmLK1|FvNPIzm9%1Mt^^Cy3t+|QbgECCVzxg>3fmja0oYs^9JFWOv z9Y3L_=Ip}(728`?R_vtxetM6i_}^(7qkiVr(gheHwP6Ao6d=k)CE};@2!AGu{tqCXKj)Z>@9{!0E#j-RO$3g*NvhWn zf02?Jn1*sGIue2mA168wp>uQ{68j3?4agV;r=MFBVo<2DfK5>ZehkGRMB4LSE*Pew z-lH@gN78X8L@N|MX_r5u8Bn;Yn{ykGtqG9SuPDYpz5X=az54cIJY2WRUHA>FKJTcg z=|us>rngjG`LP6;Bql{w9CdNGtn{H<+|Y9tB%HdWlb$lSZ*c*MuO=OB?V~f9vC|}{ zOViyr(ANhemMn%78#RfK7}@Zg8;h@J^52>d6Jj&pnv`Z|-H%ZDmZhjDTZ^Da0N+k% zCCG}0i-<62!xdx`q#+gopGE+mmj7pI6H8T1mCU4zSWQ)VFv{2Os*jS?g2XF?sW`;R zIH0MDrO9_+TN)2jlRtmQ&{O^A-5w@k&A_$2DPTNOgtCkN4Im7mmcD5ojN~`?6`yh$1=;3^HP zl&}ep&oA*!YJO#3`1dFj3e;ck3Fr8&4@DXUOFPqZU1XS_O(~cFpG|>*Nae7syEJLi zFL9(&ed5P<(5{>)>@771+(|y(f<^=={DS(=X@?=m*&p)72&EV+C6cONk$7OpO2v1v z%3A64oYv$O1BcZIgSCq2Wu%Zr7vp}ohG&~ybmT0N)VKQPil;}a)lviFm zlPP`}-=}sgIDKGP&71i)v%|)MVGESV7Fn4mbV}r=V7;_EMVeE}Hc~B?gD7ywsEny8H!Pi9EDRXEXPKbu=RXHyA>ZK62^#O#E#x$KhQO_#BKLv7@2d zR6iCzBeWmE&Ut1tK`)7h8%jS6ZJiH(jab?>n5p_zbv5)^F*9eZHwQRN+pp-xdzRKO zuEVhwuX%Uv*=FgbM4L6a19ImAyP7~_OY3DkaklOH2cEaX@nk`>g^!ai_YRBmzkGJ7 ziJq}iNMs(|%ASd!da#ShE$)&sOLa z4;FXk3$o;Uo^Q+bV%J;luG^?sNetPAG;tY|tcy+!XKzVL_x1)`CD`aS&yGg}=!9B! zf1hTi*1WvgzKja3_8iw{Fj9ML_;xXDsE?zP)Ji&(UMYb{ESRI7UDF_SWLPNq=pW9} zGU8O%5wlz|YHW}_q<)JC!!n<0^_}WYuXeqVRD#wSG_NEWw=%8V3SILyZwzyREvH;# zwVLY3zZlT8GEhx|5(;c_mR2B9Q;9xn3q!Rpm)ZrbKGmwHRsTZT3Isu0xcxFfX6ez& zX>t(i$eN_OQQ#2HSv@5g#nS)~jpKc4{e7PTar=Q0959HB+F+inIHv|EmycCtlq**NN-m*otzv^=p}j+ zgP_YONFRxDdSL^6$QBVXo8ZS=*_W&Ekt!X<9~~=_fp%ZV(W~sRmN*w!`&NEKto}~7 zQ?}a)vfCNwENhktvP;SU`$-V1RBWqxD^#$}3ii!GjjJDdcLruk`_w+Gmp#XEHS zDcxN&zVqWb%&~Ir^>L88QscbC3lIibH4|0AcEk|PacOP|)rGwa%a0!jEf#q4+=%Mj zvb15Bc|R@ju2%)y5N{G|vu`c|8YW1q$$J;j8&K-qu$Fii6vCS0pqk^{lJcu}f~vo+ znOcI1dKYBg)kgxWlhWNBtCJv6Cjf+5Uv;GdtG@=jSb}Kk+-x0D?1*7)i3ziybYVSf z1;$&>K%NZ~oD1av*<(L6n-Z@EYXmWjNFpC1eoG;okaLhs-w#7P4X4LT`$Bi>rs6CJ zkzIcO@HG4=#V@F8M56r`F(ieuB()%9a)ExX=*;`4J0LkdK5ma3;`V!5Jh$&|pog?0 zRAsy+xZLL(=G8Q*pW55y-*&y2p~cF{j&uZ1Lzq%?It>7PU3t}kxHTONXG%sno&roK zSB%TT^Un;~Kn1gLlJat_CAEd;?-@XdOknyy{(HpLLa7Ny%7;wgqgqjksu4gtH)>7| z1)Nt(#*qTcnZgBd$^h%BTbG!yW1lNxGZ~denWN{YAK#Z?7y%;Fqo&pH9Tifv6$Y*8 zAUIRz|5GVXkD7f~nUEi}qC>T%b12znS4Xg|m;?J2NK0zz?>tXkxicGfX*q%s0Nb2S z5r7<|z`+h+$w2Tt&`8x4&z@IX~R2N8{he=_>U%RRaZk2UFZah}w`1 zZ&F{oTGz?SW=>t3Nq29VgArTxF5P4s#g<2uDS8Z{x+sdUC{xF>3{%)bZHCVXg|wa1 z41#E((?no22O~ci$9Ji@7@XjDDM&?Qx-rW@NleeeNPNcsQNJD7Q8!$@ZFqOSWb_h_ zXH3wJK0rUZ>|G-3{itt_oEDT=mY>UG>TzStN%E;WH3x5n`wi zLIwzH@z$|utN8;wd$ds$<^5gG{Tqm~(w_IhO)GuBUh0B(VDuqs!~wr^gW-VwQ%_%R zcw*F`Sixmx@6-4;Da(TbIP)R_T(S9%p3ffx#Ql+3Q8~ z;FwDA{-EAoO^q|G9qL)v7tbAV$zn5zZ zVl-yF9Gw?C;4|aGV!`Ih$2a$CHLDRLOSLXYa z|0miCX1#F%|I6$;TXlG?Ro8r@`AT>Rw&$#lf=!8^kxnRAb!^XA<>w|Z{%|R5q8Jp%RG@S%KD*EkVjow@Oa-OFP?vF zDsLtDl8^|g$6c}uEZ8~S2YF@$l1K~Y;?de7uKKT*&l8ro!LkmHb-^BWZ2#5t^DSlmug0tsKsb{AK1u+>KcV+^)+~Ab zZzxUZwz>Bm*)+Pp!D9MX&a1UaY|BQlzo~$t;R(AM6UKAz1>0Y1<v?BZK z(6O})?sAHFWHuE|w;~H_<-ji3xodDIQ1hW$R*>ITD9Yh9W9Bn z2XKHx)2SsmtF`hRnUa=(czb{YCr4&Z=^>}Wc!~M!71CNs`ttRz9YT-Q(-fqt`K*qr zNJ}|Pk>W~8toWIv=BZo8+U;Mdk_^q}8ynEH(B#2ciTb73Rp2Y;@zzy_4Cf`iub`2 zfu_HpH27%7gA`k+GoEAAZw08jVyWH|%cbNGnPM)Pg^rm%Q*IEwRM1QO1e_#+jC>xj zL;qOaD2`^)KN8h?B*Z$h*#vWKjpqDmW+vR%c}xqD9R`sUWB0F02)mB!C`e~FP=1|p z@jV0Gk-rx`0#p=7mk;-2x$W2D;3^sn=7|6AG5s|m`mXOpL zX_m}UVVZLTz?IQ@2pmp&JLb_6&-(I_+eBN>igYl!zbWoQwIWyG#Xa2_d7EfSn`K%4 zj`&%Y>F>ysW!d(QFjTZJATyU25qWEOA?pXF_G?4~x^mm=VC zC}YYw!k=ZjPO-|MjXYZzx+v*Z1@#T_)pFsN3u=*n(P2)J6?f_UbVu(jd zvcszZy00$nnPs$%W#y3sR29O}bX3Q;1)`ig;!#)-DGh21QqL4PLdquG9{{>I@FF%&P%G!$Rn>}uDof53 zA4REs+XF);-AVW{@8fzQ8SBz|JK&MB6%MmfHrHTqEQ6|{Jup2x`F(^8Ybq|5>vepy zVk-8CBe8W%I3hh#@OU+syednc614Ito1?rfBJ-2_^@W{Vxs&d@2d1AnP?{8+k%`H_;sp%!+s3a!* z8qI_%uq-REREW4&;zK4MwDc^MZ%GCFAL-{mU_ zba;F22c0D{6Mt8rYxd}9iprcsv(E9bNF1LZ4bW$UmuePYFwP${e(0pHE=YXl!WVbPKnhBE=Zicv{&lHW%}53)N-w?zZ%48B*k;|tZt-gDuijTM%%p| zQNAiY+-~(=4M$Ll4%`F?bK3t6Bf7lu`Z2yki(wN>;1(9b8%^LA7s4A);1(3p9)ZuH z_NMqTf4N~JAQqd`LEFIaPseh!vv$u+3)&5)VOM}mHs9BBE<+|)H}wtiXwZ1aBb8uE z?h{Jj!WS4>9TuynWR1Kc?4)KPD{NUE4y&i61rZsL{K{+5jq;3lQZus^b_HQ^ez_pk z=~pY_(S^p!`10VdC~G>6Dx3_;^!~1nVZSJZ;9@|IQ7f-jrSX~)!nw2mmH<{to*k>=!_qbcQwd3yg6 z;}0d+KB7gvK%k+F!qhNfPPIx(0i zKEe_Log8Z%FlFab)`@dSdE1}UWmExy2obwfG71oMtg2}gU=nR)ih?J61&_tZaNxv} zFPO;lV#5Ve)Gi<`Gf)>1u4%-$_fvQ%JdHGD6ntw_U=&4O1~`700PRY(xxj}fdiYj4dO^f!s1v=T&ssPQ~Hxq7CKk;iAG5&}g;#!sUk1Dr?Y`E9-9% zK=*JFHx_NJrXZ*>TGZuSzwThccvtbdtCX~S;{ckZ4$zt7y0GfLSME`*NnGJFb5>{4 z7?eW1XbZ=B0-*KyX!^`Qno&{D$ifCZk<)_H?G`Ll0yzaD&|fm68(tib8v$bdmA4()l{y|Im~}>GymEL3QHAbA8rWqKCR) zri~TwsKd)o^Ncyk;qCrFbAz(wVMgYqdGZP*!CI+NO$0vnmqQ&;{puy4%`Qt-YXjMY zmpZaGa9T=Pe%AGX`Qz$|Qn3~O@B1M`XV5|T5ZTZ-#oKtr0@v)54Yw$5Bd%}L3ESK! zb*?+dl10_<2&5uGWMv`H*im`p6o+|m-lE@LTcI-})7+P}IRrbh)(fzHQAwbz7P;o^ zdq>rv&0zbsk8=p>8M1$Eyumx_$vxCw_Yz}9)MT!lH(_nZSARWY##NG>1(^w~>j=W% zf)xHduoU&D)dH4tNhml|b2Ta*?5DCAHE-lBxVT>S3`Z+v8Wddx4(;FetXbYpuNIYJ z*EM%QN7;*@Rb57ckI@Z$J2y9QPy4r;O{AbyzHG|ZYguVCRi;De2CWnqc_0tquj022 zrqI9PO`@Rr=RMo!0@aby$L8*cmkRrCjf2(l)U%62VKh>Q)YCJH%CAZD=~YVhPVAM% zFIoaWr>6_ql|8>lcWb^4RaVu}(wErcnuXh%xm%hwSJwY3sY+R90v-oejUD#_ZMn=s z6_x|bO8Hd47uqal9ki9UzzW(`32n2=SRca)%-Z*gw0iwyH(Rp>?exe&5J(KZ7tSnn_ad7EwVx#0LqA9s_@Mt?Y&0NvF!mXcFW zQ&N)DG?tUq0nO3%w#%%FV%9seYG9^mrM0jgSW-3rI~!aO>^xz;V-Ku18|8NRud>M< zJglvkGE)=ls)BYiKTT?S{o23GHrn@qExsmrc`4YOX4SCsGTO~q2waW-XIfmd<*)|- z@YwyYtKpL*LN;U%w~L0a_u;#!^A*qba->kKG*N&oi#uCaN%49~3tSFgP6`f`yCjvAE z9G*cITObajV)nmSp2_ihgBiDQKvHu<<1eb}w8rcrvuNB>(u?gR{xs_M%eH^1o=!Sh z1&!H?re}Gax^O(m@T5L~4)x4xkqL&1XEimRuhDcCQ1p#kp+6X>vLeg7qE~*EG^efP zTQ`ien_8Rs;5LOS*wL@@l~vnXSC$i3aIOxR;IRHo%UEf#M$B9>u@0{o=WNLGqF>#z zZcyN~C@&|j;nbIBXKV6M(OsHrcK3m8N>Q-mXzHJLx3%U2@afr2mNauUiOrjjasiz| z#i5nsKfWbnm)tVF>n%{DYGg8QF%ar3qiAGSFHh_!aj!BN-j`oDWHG)lkZ7T!F#m$8 z-*0O(2Jk7{HRpI3W8aQqbLztSfL?ECqks$XpLAr_XsoXsuTU#FV0i+ThO7;bKc5&L z-%$$rcU>nDaNyd!c`W!(FSOe#K3Y566qg!m6oLj#Zyu^1tD6_AvT_8>oZ*YkK~E!> z(b{Kv-1yagJ@N}=HK(tsnU(gt6jNEEr_Q>l?CQPhZCV;OUqIelh*`VyAQC>!4|jPm z?UjJ?v(((cOH2%Z1fY`4J&&?~+_&7og#c02H+ahzYKoh82O~k*`HLljj-}WFH!)g9 zpeUxECCZ!?%CglbtPH8JAKygfe&)l|uy67*Lb>To1+9b!Q{_!Tq9|kq;e2=|_9@E* zUenSb$>2G1F{s#&R#9NKE+3zjeTt=he|SoG=uqc_7!#P2~KLtak7KcK|gGU)N4d4r3A!DEcl`bI|TCVT}|->s3eubSOy2u5{<{cu$Y_T zxyZ-x5KHzA&{*Pe-FP6#v)u-u?HJIau+XBUn_!}_QGq64<;n5F@r&I=R947U)#Rgq z64S=2u6kGkR1%YtDqm^^eU3Q^E7bA;S=v=LGL8p+K`Q&bWA@ zvLCUUa9Ee zn+w-^+x{+d>*;LSJ$&)U?&J++qR_gY34PIB_w%d6DN4c9YR%p2*SnqhaGz6=LN`-O z0aP8O(AzB}h%Y+JI~tQuBC7%VeE5v}qYta|P{V!@IIO+Ek6LXXP;Zs_PEs8YKcZ{| zAV+YWX@PH>ed6A4o1KjwMWqZ23YcB5DajsXr3?%6Yh5|wCDpFDc^{d`9&_Tl<0JfK zrG#Q5{3WG?q9gnjrG(<6x~Hb&OL~+Rx76y5DD-n@zC)CNI3L#_pfo6Qs=+@(f?Xpu zQ|82Hm>_L}C)fKm6Eam24*lT;MEHX-0Mx31a}xB>YSXW0;xAvt=Dv0u)4d?Wt(U zx{9>&17*vN=#eG(gAPdvpNtt!NY0>3yE%k1H{WdT$X1484_4H+SO;Mck-)cXo znfTO#JA^B~jU#>pJ>3f9hz2o`oi_w{Spj1uLy;`NU|bYtS*`qbwso-ni6$H zylz6WVgkFp2rI8heJjk!5%kDc9ExJX@FJ&pG1Yb_X@WcM|J!A4r=ySV00Q50aK#Uy zBioT_4`rp%J>cCJRb7ooRlN=(eg1V_62eD!-AvR zVVrCS`?n~=|6VXyd-C|s6$djN=SVVz*NvdNm`UJnju$Wy{k)``IxT69+vEzwc*_8Xsqprw(xLb;5Q}eZN0{$*l&;_+5eD779Hd)Yf*(fzJiSCp`ws z_}nyT`vFKQO`QaE6__gb=hYdVTyjqjq*`)wpDPKd|96Ud!J8=;=lU<>##6CCm@P>B z#AN43`Q5#%*1hk7ztPLUWY*D-K}O+^%)*~qKJc`DKs_)b$NX&c>$Vrt@((0U&viuljK}AITj|D2akRhs$S128!2^48bA&3Bx;hAvUjQ|WZQZ`Ku5NwyQG9vEJH-D> zdt62hR4J(Z$lI}no;XACr)ID+tOT2D^RF=+?`&i@Tb`j?yNQ!kqScl;(nmC3Ro?2LIvz0<0rlM*si- literal 15863 zcmZYlWmH^Eum%bTmta8yK?1?u-5r7jcXxMpx8Odw!(hRk!QI_mf(L@z9rB*@o$s#u zr=Bk9s_I(3*52J+L{aeY{u8rikZ%^Y&L(D#2F@0CwsbZIwic!)PR>sBmQHrIAI`G0 zoW2b<6un7@WbeVp!+Du4z+5k+#PVgt$6%!xJ~JA)VFp;T7Yq5rf@~XNUp7n1Ke%2` z2Jxcy`q6cwyD^R@Y4}I0n4MKi_dU(jTt)a?n&~ z=<)fkx(#zgS!yPa-i(@DM>#a$(~&O%hrJh`ubv*9HGirOJNvfCY|tI34d<)?N&PxH zq^~S$J#(H9>$R)M3--oM*tD{ma5DTdWDob7TSokp7o*U6D_? zKGj}YT4-t~SlwA8g0j)|qr_c#Op%&GB+|rQq$biN6FRw{;zqB}My)In)VgFdf{|ij z-xJ{}6a?PrB;?uHr9)O;=3!yi2R9~v*kpgXJBZ+LUU8$fqd(^x5NoN><7$VFzD;Q+ zRS-sCrANTegQllP;LU^Pr$;Z#VAmrA=rmc!>!qjykCmqvngdqP>lC!87>^hnN(yJ zaC_?`$F>}V+sl3XDf3|)Ly!dBpD{m4Oa&6Y7t=%eL=NE_x|lK~8Z1%hCxoffoaN1S za}T9iN$mL>?_Zwc5hjxWKkk@ufv2$#yqx=$N)U@liGD9M4_?#fs4mbOBV$_2?mVV` zJp6ulxV^lPcH6s^W9AM35YSu59bM+cl|AIxEo`}f-3h%qe#xg+ z8@|bZR5z+(xYS{;%ILD~vU#=ER#_ZAVm1^J>S`I(uKcsd$u z7m7|YSUS$s=WZ6<#gY8nSRyI4UXEC^N6JVVkJ&Ro%IPvniqd@XlKkw}9 z$TaGM>9WtYeawfdOsx~Lf}7-g!eg|p)Qq{XV=+BChP(7gYXw%cf#~b8-T!e>OV5Ng zRk@sycLvsLP$?KlvH#5O*Y?{FwPQt?Q_fH|Cpf0}phU1uhtNN8@gW);gwkThB`*&L zeEb>nK_iX$BZ9F>Xa!~*fs@OpT3Z?cNaIN)uCK)U_Lu`bW9pwjmyGet;d*N`-fc$4 z&7Q_|bGELv`OopVL7z{Xj6QUxqMk*y^$qBNS~zl)eKk8fN(Z7Ijzqi~27k4;T`U=< zuK|EpIoBFjPd9qxYS#{IvgCEK*FV}UtvgWVg1j7*M(tI|)aEUja9#Ac-3~j?eTmSg ztY-C{56A7!6IOadqsI?pu&?EJO^}a88sbl;x!c<85LQx;o~m()nh;ZtLh7c3}t=KZrKp3eFOf?~+ z97S0RivfiZX68}orvX2B0!3=?^NROmj0Owy+p>^7>AMhjB8TuLQmylq&Y+q6=L!3Q!L!oc6TntPB`a6kL>g5O&b#&Ok43=lA6L6{yhGX&0REsQ)+>lkE@ZMj*=J6a6;n3WB z`(wyeY$-v@Y5YRuRNd|?-%?NhL~}nD<&>HH;T|*Ky5c=8dqWlbijj!<03(-Z_3lFi zoe_ zPlhn42>1RrNhkCgSJi%G66)+92;nawR>_Dyk>5M#5-Bu35_$s}1#+!#`0iE&(fs!S8I6SSZCCKTFO{bk)}jFhD&o0jp#HH$wkp~s_umsQ(m(D ze?XsG5>NE0&aD5mY{52ufR%T&!uFa9M@3_E&)9WYS9F4?>d)h&C)|NRY60rLNpi)( zu(5U`p#3S+yG2kjMl~_^=7ls-5R7Qq%HYm{|O`2 zM=q11+={(sIi`6kM&7PP+JMs;f&9ExldY*8lPi%-^T$N?c3B?FhW6 zyPb6k5~%@;dpYRUOcY;kZJBi{+qh%HIWF8Y++JG7yJ`r<6Jb|z|3HOT-(PK`J3#Y8 z_DgKvQ(_Xi3G$D}0exGJ;YYgtXQ0$Xwftw|@GP1I6aqg=-y&I7`@|jG!lYK%C#q=I zj>xDwSV5g{H}K=>isU6z4iI0Et4&6WWTu_EXVs9cDlZvcbenzt_$8~o-NpVo_en}j zRE!b?uVGCY)ESF*j+I{{h^ZdVTBPBhRZ5HI@`mQc`>2HfQEjk)zRv!}T00~Jm}}1m zSojvOIgw%20br;)uTjQMiJV|Ip}L@w^YF_qs;LoW*ri=3?8#vuud1eXxTE0J`A3G>QVe~UMuSnn!c$*{7=9S9tRKC8jexc&C z8&=k9Ufym#xWtP;z-G6zVOZ4FM7f$G{@!Wghgu2eVJ@b~EfC&uT?13-<#Dw0LvD^R zy9Hj#9PjijVjoQ&zqZ*iR=y(4-LT)okS}I2xWxdAGc zFIEbd{uH)nj;E?HXDl|Uy`tW z!a$3>5OPt`Q-o~&y=Zf4mp4(i(_J%!ioJPUx``q1%cyug92Yy}<6aE>Rxfqhiq_NA3rW&Y!HJRymO_6?hRjnmR)$pm z;HBp?#Xt=sTy#_l4WF!Ep!iieGI|68OE665gVI-JD)w?Dc$Ltf)NsPdMg`RV3Rp{} zp@OBMQ>B2ih9H~D#e~Cj zoDi6jbcEOb`xl>_gZOBv)#!HhM%#V~frzKufI|BebI@(%fG4bX;?plH0Y|2;G*z{N zyTsp4B}|)M-<#?VQ?7rHd(s3+giXD0J}jNavHRW8Yjjj65CPWFI$s<*AOE;XwP?=U z>G^UcS7rEQ(jL?SVSTSskBK-E#TsNr_72A(9ER5uce7It&pS4sh)*#a7=FcV6##Za zsGh>8D0XDHf?4)OGpWKHinHNm);VPO;$h)mBrnvr+RtPW1s^!6eRnzP5KWed=Ve>P6>n zr!UU@@vytgHJlwbQ9=$*gXZjUEgprPc!6b$jPEip=s+}*edLMsfrrTR?g@mfsE4Av z=>vK>RYM46G=}@`ryq>E_+h*&0zj`Bms~c5wsul%eAr&PZ9LT>x)>Y|Y}@MNBkkui?x!nk4#8+j*in^P zV=(PS>_Pd@4nj%NWw|KL%L*Lzxwsamnz^7DzlL<@A!@7GbcA zXWVb%kZSFPO)c*UtNy?TYj4b!gJ%`|?x8$q%g!9U8E?#7qw_8(PZz9^>Mu;Djh^Jt^2rr3Qx`}dD;Cvgn~ zI^M1=Xiawdd?a4*Tc)2)m!n|Y{?VYiw|Mh$vzj5j{ox^O!jjibZ?Y4uaeZO5`^jwk z)GSX!MiU-@jq1i1A&rC}L+)kLVwGxA)fVo-Bj&0@uR4C=%DMJ?8Zy1~FS3ppMtmo| zsZZAL6QhMiKqvpf?P8Ab)6Yqbbt~AidLL?C~H^s&e}1%k@#| z9Ubf~eq^`@>F!W{xX0Y~aD8~o$Mgh?Pfl(O-)2b;sx;(^#XkMQhDpcn4R83YXp#3x zp69~;g8^xQgpV_{iuUoyFcA0&2&Aa4ic;5c+c}o*JFCj{ZhMy%+xB%(^F8P$M>U_e zD$%!%%hC!koP2R7-}k&WEOA2fwb*<*w)k}N-L?~&ukK&34)3sD;GJ}}ey&>X%opaVFFP|Bu%3a^ z^0-G-)O>@2lX)}ONPl^$JCXu)5vAneplxi2UgsUZdiDs)EBvN{;u9-6{Cvcv?3o>q zJylrCM$utFZMpuG# zqZ_GtQS|?TR-cYkg79p!+(V|{CP4B-r2*f>8A(L0wXe_btF(17^=;s`H)ZPo%)tuGJ zuG4x7>lEiD0>?B(7mpXD;xwAk+26op6zZFB!Wmz)`oQzFT+ zfl0)=8O6quArNH>#450b(%@+2Ii|`mImFOe2g;JTfnF9up~|1*5V63KN9K5$f^%mL zjywb-nr|)Wn6MV9udb(x@;^w zzr%8hn}VPcH5u2GM3wwKxw}YuUolj{F-0P~0sgktJ`g!kE_mOEl;FPphDQ zV3IK0`ig7BVupn0`ztDwFi=Q=%1BWdC7~Y{BM!J|N1F<+F?fIe?no$+YTR? zMsdYI`#+d~Qof+vBMR*p!~-J{o7^Yfo1)9^KK zb&gN@M-k%w#1bIFaIl1Nk8~*roOvXqbi6q}fn&vaHzndHF=YmHv2VgLl>BI7`R1ZS zLj7l+`0+!t;ZQjv^>M)g!4s^#c+M;IPg<2|bS^E9<`@B?s~MmW2Cx)qkelc>n4|{|)(HrT1R~R3987 zpGlF;K?#BVyqp0Ef!(|uG10Dv<~KFn4ll2cv}()f$3bDT=#ZHCn1^hFXk~&#ZV!VP;G9zQpB)LIF2kuYD z&qP*({bFUR6+W0mMVc0cmPJ#RH=l_{Nw64supq7_VaDVo1S6CMxsV~k;!{A|5i;m} zx*@YF-QV?JdQ{KQPzK4|RSC5Cxv(Bsr62w}??CnkfzRNZb8 zB>@~Bd_>7nt?CRq&{KzJIa9!5Uwc2cHxM$62kN~a)Af4$AZ4U;C4Wy#Hax|y+e+Mm zzgq1YCAZw5n(MS%2!&Wp%AgOhXGUymM1tE;lwPn)+D+~B4CJ$qGXT@W#QohmAg@g4NDh zDH2DkOdecMf5+ULeaeCm1yW}{u1qy)F7^K1K^UYzU%ITlkPaNooV^K$wmz7)?V5=o zp8dRwKcI_U>40KdZaw2B#XvT8{Br#GFz%Q2@{rofN?$I&Ur$w9H*DFNHb#FT+MWG@ zv#N1bD@h>y7^sG|rdWRZJW}k0HjIFf}Md+5ThM2OPz2 zy23zh$pC<&knMMv7SEunP0Y`kBtcG~Enzny9(Ybvq=|1q-vhdfhPIgX?Qxl#@jq+F zAXR;URr?zB1v2Oh;RkKIFPtq-TiFDTgK`cM&xpJ`YHOdmAY<>b-21AbY7tR6;d6xt z75z03algZumNC*!4$R*;zqSmI3DB7B){XOCu)aua)ucmZE5O8@yPI1FM#=jBqM~PC^Dy7ab3g=FK%$4r zo*0Jkz8DmO$w|NhM_{^!xwRu>!tw`;jx;C{ZBIyeE2Fj=>3e2dDXVZS9Q~BmUJa#Z^sG75 z+%#I3Kfg@J5S&>F3HoJ3V_)w-uTz&XOsDH#dz`&ZkeWxKcsN{l-CB6A(7zZ^JPj2> zrzU;%kdEUkk}SkbPZA;7uaQDPr`qxy`Q|b5&Feo(Eq0|Gd0K`Pp&TkhEkQE>)XC

_ zG;+ode!q`JoSf~(AaxgpLA3xay-{y;^ny9-2_;f@X&6*0&*?Xkb-rE^M00aFSX8Qk zJQ!Tw!kRFY-&+Xiyu?8zl9#2LtN26i9v}md&ZNdU6TbhPG^Q7CMyr}JWN>t!31YAe zZXEHAU?@HeM%gCQ9%Y(j$4~!>fq;XB8+P`s1dpy6GjgsoLZZA(v^OH-R5>PcqXXO3{OocWJ1y$OPfG|V5(ij z*-O)pt41|(DeW+z8c9GXG$=N;`{}PXv=VP16-GCHHQhwZ$_`|#ez&;7CA{K|X{b9P zKC_2HU`gMF!sGUdiQYKM=ivQZeDic?{jRMbJaRsnaJv*eXD*EN7imt zfQyvltWu&~Y1zsSI(^2rW5bbMu4=TuR$N8l5BmM% z<&f*S>BMrI?+OFOH*zGl@R?iLHzq(YQqxx{<_eJ4NQ5i#6kl*Py8XbG${;|;;Uyq| zf5cJkOt8w&Rcs^0?p|F!Z^*o&;Nzt7TIai{2aMWFby+e<_kKF4?s`6#%Ds_geY-{f z+?*y;lDKT*)&Kk1v|TeP@pozte=>0T={B2xQS@Lp>fq@(-$e0e{R^{=9~WIU{QzBt zMoVi2!&}+&TEdqmJKfgXx4IkDH}kGJA~r3#^UeoT4PDi74x(y_i{fkf6Fal&$YR$^f0Wgh?pk6XKN$e?q+gl5*t=m^CEK?w(2&;7I6sc=$>c?S|ekSPxRO$*d!E=J(R-;fATYK4HGlVz^~|dC=Rj~HZmUEf_aB_ zZvl^{Iw|NSQtVSmrU*ztpQ(b7%#Oe8&KT)u@;@N*Uq6t-r4;oO)j0`zNMSCIiv0=K zqf<%_u^?_E)6{a?^Fg{lt`XzZLP0iDQ!BZh9g2Q$2F$>e#QmzqPx`CsPS93gU>bim z$ka4CfEpc4zbLP|>#w@kA(z`I>aP~Q^TwdY;W75o#^C^)M1aj#n*yk{=AW?m8k7gg zFCH-NznddHitMUci5ix#iyVgK7JlfTlxn~&bAzI0=hIzkD!+jiKGmVrx?nDGYZ2-1 zj&Z})$3Qj4u$+9=8idjs1i08&LbZR3g2nf;T;M8nfnMS^To7uEfz%po9iCcn04@Bo zWv+MOt#PRUAlYPry_CIs$E|T;u0yGEQQYeGuncmtK7p@sv9?FCA%JO&L7vE~-1V&xO~;B>e#t7F9CV_jfrUbUNXR^@ZcLB5tlv@*Y&4} zSbw*ZnVv@pQGRrNB8|83K?%guZzn{5?uQ_rh8`to`5`x?qP^&5-)Ra}oi&;{` zuqWS?Ny_f~%bNI5D=K;DD|xVBm6U<~6`4|tD?wZ+Z$rA4n`3{) z46&%3KCfI+jIOVwA^V?~j55x5FZ*N4nZ;M2;ww{XIi(^{vGh2YAMuw>P6z9gp#anz zN)8$2AJ|n4ig#G&(Uz1&Sg;Dp{M~F_TEylwWXV9qwc*@lWtdCK*gq)PlA+j>#pbAF zVcJ)LG!^pwmhTz7=L_~+%a8SMUH_JWYE3<=n9Dlf-AM3yJFe&VpcCE@x}YPF(Qr&O zax#4O^VE=aEBR83A-MW1`P^fEVRT`oE=zaTgIP-@HOg`Px9TQ@r`QghYJ8tUJQ9jZ z;;BAs6pW|=YY0b1KU_XzMi3a0z!(O`Px*|Rh<2=65T8P(ncWMP%fl(7Q+mIQt4fO+ z)I)BVH+qsF79el`G^L>?VaxzcB8875_36L6%9u8McclrUk_o{@o-&8DV`VDn{~y); z&x37%oSm#0zBq<^fyOLu$Ta4L`GT{!0V|vxtC@IIw>ja4`9}1BT|K5RW88}Vhd%Rh z7Ck!G8vy8Od;ps1L3aDaR3s?v`C#kC^jk0(!8}w*+H*?x6CF#J*j^L=x`9%R8&|7?^#hw61l%-b_@$!#N>u^=%$jCVhc zn|?OD(n7pwntR5M-(+_0T1FC)@f`)ncsHo@zXOaj_U$zhw{Kd95)*dqU$P*zj5CVv za|Ha;>^4Dm`qEVRMh)3r4vIX0!xDBCH4nntb)eh(NGrcTa{AdFi}ElWZ+QHmI``1G zSn|*>{>viWn}d{sQh^*%iX0&Dm6l*Bjh4ELs(q6dj)J_4%e_kjMNY=|`qH;frIYD_ zF60id@7=%GgtTFoa*Y+cxiu*w)xSghKMRXXdoBiBx=YIVI{ial-yi`~T4YXB>*hm? z@7Jp+z8LOZ5$_f0&aqA925#nGy%+bm>EA@9Yc0|DiB1Pi;qS#g7zfu798$~DH>%$b z_k1K^OcmvCi=%#c8=kpjJKhmz!^kb{l+$JMw=-nTUUZ4xnZBCtb@GG8v^DZ0+qzsc zQClVFCXFE$!lrJwHPYNe@^RrVKfgN|p{JDn@%|2pX3EqX8q?9fmD+lwZb zauAQoSlNLxE{J0rVl;ZZ>=QSZ-&eYYM}U$R5q!H+<&6MwNldEQ#o?$58^4xqh0`Dq z@j}JwZ5(J-&Fx;zeO>O+;2PL-rwWyFT`zB<`*RWqd7;8oouQ^hLD{Z0-)^Z}nYFd` z^kL%hLz1oyy>jQ1!g+r^q@CsoQkum@`a|q=>g!-Ch#XpzpVcIRCKFmH6%4qpLKb2=zXaiyFXvjqf6fnr z+2}SzVTThq(Z6TYJ+1%`ySDW28(5CVyAQT-2xu=+8g+xY?#bY2+JolbgLHSJY;;e& zj~2Qwqxx7Id~3Mw#o#`+2UQaNm&3z0UII~eMv(kK_vP?T1|Vp>n}PE)zmxVyC$K3D zT(4Qo$^Yh?I5NRJxI4V>a@o>ui>9nsKA%dVsMnLzbR;~X#R`{`5QMeSZTVkTa2NV! z|C1_~5WTUOf~i9ghGPwgM}6!)SNw`g6xIJC@VLYA{5SG)hx2+LX~6YXN4r^mJX}@cG~`4h`^w2HRzVP{}y<8LZxl`9`i^)z^!K7JS|Aiv8IP-$&_`hdy?m~ zuPk7+635`Z6qi;j+Mo9HM`d{k-Yd}m-+aUieKt5iP>vJhb8u*rO8TFQk>Jg_xm6GT zKh4O#^2`Ity=eJZ*D4UTivhjk#W2wmfI;nVq-F$^yu4m)+*D zA<`5avDW-feZ=12KPRW3i0F6 z({{Nvd-*lqRd*ZOcx~3n^|+&P!WR2?C3?M**=*hpXvsuVVwSjE-m0B+5^KkxySdt% zbr~yfb&_>qrTy^m^<}O-z3QYu1fLsG3%0gVc#%M^b09DD4kw1FSkXPfN!Ey}5ciZh> zzq!=m3p?^`pfb+IRQF|l;={W8c$h$Kd1DXrH{<24K28`06`nh^=9y%r%wz1gg@P!D zXP`@6fvLfh`+KWXfVsEN9nOAz=1+FJwcwT2=D%ULqs`jMi%}k5$~!w-)E6HAlH%zK zeZn|%nTD2QWt!H-Lar{2NN!j(fuglmUC~XI{bQ_@c*eGTsmuaaj(0~K$kZ>2Ufbt; zV4Sf{D{@XNz9Tc|H1j(;a!xzGBO>QC;yZ@g=OfG3r-~^x*ZdO4XV*RKlTUdmqp&}Y zC|mr&2d8$smPZl4OnPmf;E{N0GOWls49RXGD=)(wkSHTln@YCIxAA7)Z5De~Hhh=h zt$~`n_qsP)(c>-4ACNLhJ*l>*Wd2Zb<^7`*zx4`fX^4}D=>b}kpXot2MLus|De;2r z0r6<0u4d%gZu~-iX>ZxGU4y#!@_X!`jMxU#afquM?&q474kAKM|Kgpd1t%1tNvz3(JOwMipo(VVuc%=$>uPN8dwb=37u4R6zb<$I)!cxl0} z1YbV;HVH6P1CZ((aaLcC*4Zv`T{{t4yo+k)~0YiIiH+sYfKM%&32nI>{|`A-D0H@ualq zkXlWxN1XpTGo?(Fc>Aj!MOxEr=9a2bP>P1!MsLQmRPm&8?v}y^k<7;OKe-i_quq?D zLJ@nNBG@BWQhm$2XPBh=karZJvj|z5{sYVDPFE^uZT)ftMrnqkFU;6@^oG5SJ=qlTsKpgE!_&`7wl3j0dCHN zuk@zzSklI9@pr_vLFmirLmg2_$z*$5si4~xqQH@x%aQ@zxTT!AdmQRdbq-`On{^Fn5?F^nL^yreH-w_f}~^7ekwY{Gtz7xAqkHxAqDK zsBS$5sBr(os?!Z1gz@F(6K-UjXFw|7e`AxfgjH~e8zU{F5`+`w@ga&LnO6bYc=3-i8OP!=16hej6WWrS*3Eb%IOC?(=`b(BNs*wRxU#iUs8Z3GrC+F7fp33UMg?<;4|;I-AR}HYjdgH4!9{U z&$mdMtif(%uT{Gu;h~M^;zfbZbpG$N1z@f12~HrpLB6fh;cvhH#3P38&w5(m^mu+_ z-+SYF=ZmAKYYD0MdfZK6J(@M098fWRWwZNeP*PIAvUBil8t>Ty}~eBI(p}y+?lCYUvcgk2Q;k z9ZJzZC1jBlXk-GFD1wCCKxcE6y?W(Ouqu(W)HK9ql^f({D0)&8Yl-}hnvas<{9$Th z^53z@6!z=$M-ch89W|Lu;41qq#FF^xu}iRc)rtt3oo9upuk@EkfiSj~pE| zg%a^wwKG*q3;pSFdJ|_1!^_34A$CWv(zUn#;5}POKmRqV&6Ky(JYC#B5_y>#w#<$O zs<3I2?LMe*rIV$q_yDXdMt<+NcLML!hMWBEX91gJO%F3tFO8Ge05N8uY9&6n>pGjl zuk6)2yc4iRA#{zvX*0q%$y zms-C?D$@X;Ptl>6g9c$mUlzZ_HgAUy7(Taz2En3&Dq zpIUlGDZ&FVxvUdsJTgwGT7@OmE`PHx-rGA(M^7&p6~6iAn|T}}chG8g{A+<=DSzJ7 zqtA{m<{0&CZ}3JxT?8~=+en5n>6O$92uNDf3skCZT2E!tsoi`x0{~vHRLYMT^(z~RyA#- zrm-H;Og}5FsHFlHTjQ84J5oEFH#n%7gve?DfAUZR!D^c|F^xfRuO)22p>j@Ut@Sdq zoXm372qK`iwxiZDVT2k`YdPZjBZW?Dz(Uf-JL6rW`o&FIbvdbFr8%+I+CyPN!)8rZ zqtP1oQ1-u>3lpx2DRihKMc^E$MpNMSnU%mT0KFL2>|+1B(V`tZ{1PKx|K^>yGtzGGeEU!*ygNHR&Ru05`|S_IOCd> zLZ_Yy3mqjU=YRyL6^l|b`zI?+^L!8ByuLkGct%@U^Zxmxuvp&dw~%bVCq+GwdLP>U zGu6$+E}^t3!C2-g9mf`y6A>QTn6sTXwTfejq87kXnOMpnSq356xaXOCWHmFiyvT2? zDWfZPEnTr@K~C3P-Vn1fP+A?iMX{s-tXNuxm5;OkN(+&pEiS&TT+o*-B@lJ$K1%(}h-!G_u@W%1($STBw6wcvDAD_$NA!xv%ErZt%xpdrM})%5lc(XU zD2)qkPTWeLE|~?Asxxq_sfykn=~SlhnWGjes|x77CESYf#B=*&=HB?EfOFM{bD@vU zY9)%B3<41Q6r|6XNjV9ZPPxzcFai*jZ^4DH7*mh(lE?21>DRnH{VB})sn7}s?ysy6 zA>_?d_@%S>wX?jGtg%RRFd-?1A{YwhAQw&8H#0{Fco5i z2Yv`~QDaHKX;u-awZK*q-k|wpo>6u#ok6%1eCs`8V)A5;rXn9mLNW@CVEWdZW@I?_ zn-P&*T&VY6(XRx=YV-!jbe_C}mbeo~#lFpGRD13XVhwai`=N=0S;R*o)?ZkvjY&W* zHYhf2r1;kw6DE=5M|-0bQ|OwGU@tok=a>wic|z{)k^;!!fQvKcOi<8?jxX#^Fp*vf z+cQu~p7V%`oG;Q7mGzoqm$D_73d9A+H>JH57({r~vrf$0ad4$Z|9vwC=r(WN-lBlv z*0zbX={MQP)80txSI!XsY~U188MpCt`6ST56Mk;jwgG-~k5wZ&Z-D!`5TAF$YtDzY z62<}zGB=6U;=6#ed2=~4u1{k)yii5`dIzIE^nvD!{yrq{lE_(&UQgZ^PVYOmuN&<~ z9!?GyT=XL*FCziJKN9#vM0QS1r-mQV5cvEI?VOqC#rrY7dvw$me&ogd$WQV}MexE( z@`y|DLQC?8RiGK5UZ^ae%4odTOr=8ul%+` zirhjo%`n49(8D{}q$L=nu^Mqnw)hDHd?-@C2Z$}!cK??hJ}R%EJ*TF5x6wh%!yr9o zFU+MO7F#1TmZTVBv=llbM}lZ#`2EM7z398cl+fCK5PiQ8nX6E+TwL0dx-%{c{V{gm zFD%rsRQ%S#y3+0a%O9yIt)*UgE%-g;5@X3&I{q9{twqBH01f zU*~cGk3-AA^3-`Wb~ci#vLoY4z+2MRhE3I@*h3#QZ8Pm2t^uQ zNL>Hyq?Fy=JFDM&FT8d?M&xkK(nV?cBkB6{+Cn(mLl91Mi<1k2g3khArkY_CAR$O? zAsR1~q)H)mc)pv>4xb)0)g9#DT=|t#I@Cj8nR` zIoY|SpfFZTstbqgq^%5lF-l4n_Qx!%t?aDQ9BY);>?tPO`0fI$0F^929-so0zwQrf z0*XDHuOGY;#r6<&0>4)@w(G9bmKRopR4vO2ywypwr%JJ>YJ}O3?!9=o9OM7;v8O@x zL%}sVJTq*N3nR7Ruk0%53rTYV>E^t~Ik)KGqfv7+>f{wio#_>UX8Iqakfj*yr8_H&(EPT*lmz7s?$!^x#`W0t)# zI(umi>TWW-I4dfNZwVu7FZnACGP3PDak{80Iq`4J#mmv%`zyf-xD3H-mj;NiWlWMr zahnckT`0TPPbCzf(6vCQ?*GY5EyG}2_b=$lMcL)rwr6%(DaOF2pkXsM@s}Y;bshPk zL+Rp@hdCc&W_oJjIWm{`8`Fyo-bH~`#EfRlI&X1VVKBwXdh=kcbNrXjcY=I|8ZiAy zlwXHs+88*ln!ZfUt~EHe5KwC)kf&`YusR04R*j#bb{^DGsw$uN@_TTv72k)F0cgx7 zKcG@4B028vt0H&EF$&&|51i?$sVd06tmP@AkE7+U^T$ri>12LcW0u9E7vL8EZV#Ht z9D#}v*Tij#fW@ZyXC5m%_Y-81$nhn&X2Pe=S{F&Ej?PLT{g*K4zHcKZC%+5va&%-l z48hII)dzJ=Hkmu4#h^Ptub17j;p~ClO4q7_t(*P%@nu_%`$d?m#BBCzn^)}OEIO=t zps=7q9s)Il5S;83L7aZ92Pq+5`C)K|u!yWi9wMu0FB~d2z?t@|(@`r6Tm?@K4As=v5V%6&pu)0mACK}0*dLrZjNQ}=-(K(D;4*=C K6OX9~AO0UJ^cF7w diff --git a/detection_rules/etc/integration-schemas.json.gz b/detection_rules/etc/integration-schemas.json.gz index 561bf356dde6e249a4d63674322538eec97d606d..f40e96fdeb5570bcf54fd8e4f6dfd6f6cd53347b 100644 GIT binary patch delta 7553 zcmaLaRaBLYw=QsycxjOC?vM_FMTZ~_i|&?|mRcaZgwhHNL>lStMwUuTr?h}{cW=M{ zK6{VvoQrewT+FL^@r*I&uOYnkNyB!_6M*hL2FAC+oG<_ckU`)H2%vxfDhQx~06GZ# z9b$k0CJ11G05%BVfB-HC;DG=>2oQk4QxG5o0U{6}1_2TfAO!(35FiHu3J{FdK~V)9-xk4~zyy@Ny3bNDM_>GA0gckD)=Dg*qZ6PRAR7f|{CIg%O_C9$nq zep8*vko>Ih)$yo$^Uw{FW&thEVflbVp^)#Fl;o+RsFF-Ig-`amofmGwzFa82{4oB- z0Rv>$Q*mLN#R+xvO1gpNcq*O!Gd=9#Uu|bwid6);(!Nv`nI zQ6h0q*3NAl>Vyspj)`NvtcsGVfDSAbAOHuTTUn=7o$-c?;9||&=_s_b= zHL#h2T-q3;DZ>5t(9d>^r)+=9myW;zqLtGQD#3-+mw72Q)tn;k%77p zU+h?;ELX(hN*Pg6xwMK)l3#ujvGqoTA0KRA5$*(&SdwD-uieT8o@CoY`$J)(^1OBG zjF5!`5*7?E;=tREmosWJ7asR#JF&>|_w0|?!Bx{l_0DSayD zwX?r$Nc)TJ2Bv(_bu&(}_A7UicFfstHGYUrmx&Zm3;7Wo&MWe|yu%wj`Y#WahU2DmoPqLR~(BxqCXg7UAS)1D= z;JV@Ib~AE&d@9p!;-8PhoWW>W)1uobPo&&hHyfSn`Smsk<4cA#4*UKPvP{Vzae|wg zHxJ?CKfUNa+Gkx>lhrF-`c;1|d%pQ=XfL01w^45`>Kg0vq^VGZuW#VeZtW(!=ohc& zL8_g;PMk&J@HDx1iR|XAO;+eABzwWNc}}%T93t!WnYj~&w@+nu-Vh)`_|NP5%@-l)$+_1nmvkLxm`wUdrvV-|yS z={|YPNoy}xKY@;(uakQrUe4&Eb%pk#R;d(1Nb7uqZfK@%WvGI7pPKtf0VpHWFG{(U z*JL_~yT8Ph-5k%h*mDitWjQGqajZ;?mcUB&j_zpQ`%mya=nN??WEnR_&I_IXxpwKN z9#I$h^sS-LgT=;z$hxf51nVKbM%J&5Z(V6vbV?W^i-XcJAn6rZRKuMZMzXk#%D~jF z+z+RfMy%{Ee467>mbeHcUY3xoA;wDLZIrAC9=}1{4j-4 zj9bH;NSoKCR5a%(86!>`0c0xnDgrN)jgp6wZKtz^)1j-^W)*MZq!@8f*Rev_d&ANQ zbn9g4X?r8zFgeA`)y&r!B<>-7=O1yzB?H614SFSgQhVl6h4#nB4@( z2jNQo`$}C~tl#K$jl^bzcumCDQDMG$Ydc^yTZyJhuJ+f85OZlG*b|IWU*EZ;g-apl1(JQAd?1 z0v04gV_(V~6%y2;XFqMN6mM)Uu zO$IJS3~+Nh0LzL+4#%zl_45A{JqH(VESv z?v|#cDwsKt7BN$RcYYQ;pM*gVUz1casBk>5Hi(wZKI2p9oVB?t8t%VL<9}7twc#50 zDHLr?o$dSeJdwj$0_zD%l#1~4>MoYmtjNd^Ok!>_bi&$+$=N?4;B2m5)3QSq*}aBj zn&v_sENIKkY{Ni-ZPb-|?wq??8^S}Z$6l;8nxG_`gcIrJndP>3 z*hGBciGk4fi5wD?Eb00w7MROcs8F@Psb^B22?f8~+sY74>(+{7BW zkCrshEdS%W66xhK}X_+CS?VZ$5W0dy14u9a6ot{G1Li zDhZml`GqG>?Pyq!!W+Q4bo3TU7-uI_B<1Z81P492jO|0nEe@=p>OESrf1ObDoB&0J zitOhkRnY?(BvNhpQG+s8GggSC54wFTvy)a8+EWijG0`&O!B;>GT+{|#P2I+C-`ux% z#B+t*B9|jtFmE|veO4v*RsF&HSDQw+`E~o~i*2^5Ut^eNH%q41Xp8jNkIT zq#azGqBeir&HM-fdmBT`yoJ7-8_SFfJT zU=lNLM&ycwY5RSXug_)v!@@O3yS{(Lk@0E+!nq5rie;1QdUQjy@Y`l?#*K37HrC4r z*oRu%oA#c&2~u2&bBrodbDnl%|MQuRsjrG9f=ox7&Wlf?>>~2TiBkLU6|`i~tK}`E zIu(g%9tIG{tqSc)w=BlaO0S-O)svno`*E~!DfrmNfcEkQora>QUxATeQBarb$t`g>%FglupKU9!5 z!5Rc#Lk9)w37`z6a(ZAfmUfCD$%dNZY7@d8T*m4m3E{dEdB1E-xGhcGNwY?VoX1<3 z6#B`yvXbbA<4kv}XjC&dTTZ%5{zhdvr(;Cjs)tW47e@obwPejtLc@&Opl=#FOLs}m>S(RaL4hxhTs@R>8My5@_vi(oFjD#w3v9$1ui%*js__VdqN)Pb(9+Wv^zv$ zk~Qo~O+8@3f0YZN8Wt&RpwXZB*6<&@O(FFw**&4mfkstyPL(}#z61)n+2FGCx%(`+}R{qBA44CE0W?Oh6CDJ0D` z#yeK!n#~TH4q@+32+24@t%V`xWttKgUfR-o@((xLhcL-v5qs5?y{;W)^I2b;T#fvR z>t`M{NUR&cs4Cm@b}KVVVC3W7Not5NkWm& z6x6K_;>0(d5_|gheKO6Vzs8pppZ;FN#<%4rR@V4H*U%&+FE8vbdY@Jl&5-o0HMhFG zfah|c4mOics#U9Oq$dp#_K9Jz%%wciI`?lmkc4P)ux)+3_P9sqXTr#P9v(>*U7@Q* zPAEJn*z!XJG3~I`BNJBpe!F)(tTSk$Z+l4a#=|{}M6m4?M|w1yBc&Y=;!L|gCgrPI z&oVKQSS}OQ-8vuf!0sC6MXV+k=4nYjkurHE#V4>|VNI}GAt|(4A&0tFAwuxWN1 zClML!C>N?-z^+J|NXKs>Q{}IdaA<`?{_Ya|y(1!^?Ew695EgODSX;pMGT=X95vYQ1 zpQV~m>gJu2_L(#q*LEMvOtx^`z*02zJ)g@tMTh{g`C04unPS@2@|&-UqU!L|3oh7Q z&acuo`)_lZU6?5*gavIE;i4-$KW$BropMbkg{<5Pi|5}x&B|DeWlyeLuX2-HESJvRzFoi`e@BYB5y~}~8_i5}Tugy>wpFovDM=jyo(oBP$w@FXfs^M^ z>me+cTrC#;_s{6pW9SbuE~EBebB6UrMn_oBvD?s2lVuu*VN-F$grJ1XXZ?L;?C>MH zszYgM4Z2(~+evZ_E)FcYp49#PzFqQakCtkitMnQ$~A3{7Z+Ez@s5#376WcX?(^m^!HPi4JM?adiq!-tp`6Wo(C zOBEw-c3+>d7Mfgh=D3;{*_Q{l_J2K>zn*_BUz(Za)NK?9r|sA}FD)}3i`&LGwr-o@ zp5ci_E4IY)8Y?|9p%6W6sJ|4ZeP4Nr=Ob!ST>t8zJCcS^i7pT68FeHL4B~VXkV68ff&5mFiAOE_JB?CZ)CGO1g`{7N5*ox1uv z0N)|F%F}Z|y-a5>9=Z?U)|(j&((x1ZX~81|q?;lP{r|+hrE_UKUMuE8 z@Fi&*K>|PJj&*QGIb5q>pZ6rYwCZ!?hn31ZueM{+!Tde8;|SEEO+VEYI^qxT29-{% z)+}lp4gc+c(iO6!v=!n0`d;hlc$j8aegK_gxH|+)0cJkw}jAwD8->ESXo^*Pu(edEZ((5&+G0^dt}%zNoMn;ueJ0mc{NWHSK975 z%eg>(UUo0@i)^`(MK1JR7q%9%MO)<} zHXM6H@Db}s(>W#v9HIUcW>-;c=1Za;FL0V@YNo16`}u^o*d!w{D6QzQCq1||eDd={ zEKiLpOb;3Rx&POfH+8IaoRVE-!c}9+5n-XG-S`_~1Vq+OA{gJ-X8GI|ermJ(23}w# z(}arsp{Q8R^GJlvQiRSIS3luHGg{xWU@+~8Q$9NvXCP<%8a#?owYWvLXiIL(iM{#h zkKN0t&tEmXO*;rKn9n)>FJH1rBpW~4g)d^pL~+kLONk)g;iA=TuWS6ed= zM`{hF=MNCve~w}!Qpn71j22fuya`|9Yk+O7l)Zi4>P-^2Ra5e=GhOYegZx_p-X$z& zuye^tUGa znTW1`j+ZjEqF@~{=7q)ZYfC}z#T#zR*lLqQKK#p<{pJEH#V`K)681m9l+uwyn_ID? z-gqFe3P+%WxLALYd8KRh?9P1AatB<01-`cL)BlmA#?#}#$rI6`#75EkljRfmvjGaBXdsKaRBJTb^ z6=9AiJ6k%O_$HF=yothr_e=pM{A$sL{M5X)_OT3Cy^7^Xg=zzPgd~eg(%`?5Ntd+A z`R+WJjkq~ODW}qSt7gSW1eQ= z6O7H(E^IH8QZeX*+F4&Eo0D*36M!8@!dsfIuaI2_R~TlUf^7!dV8#lbo(QFk1gOnh zMWf)p_gzsO`A%g{kP|7}F;S?K*b>z(<9Tj7?w%cX=2Ig>=$?wsZ^CLL_}7R!+dVWG zUm2Y+Zk(nH1`DE!hQF%86>xVN=$}+#Y}%(-Ki{W6KCvGP{d*WI7Y7fnjPR(}xP;JN zE1j7nP)o${!{Vlc`S&HAVcw04Ie~CBOtIIfw~|u<3n(cA#01NS@fW7lcoU1}w7SnS z-k|22oio2t{w1(}ta0au!r zgLN6Br08u)k0vNJuiiv_sN#ja$a?CFh)loV%xx2>lKoL%=Tcn=tMt)LxA3+JMnMsN zbv$Wse1BL+ph>wO3DbXiA0nDf_5YIcU&g#2>l3Z*R`wC^=8o}`_paKtbLK+7D2(F2 z;L*T}Xc03Kp>ocPZB!Ak<$B%boCm|D4~xB`Mo)JQOqP%aXRxYB%(?y|bH8b&VLgb2 zuJx|R`%2PV_pwjF%&H%zld6_IlLq^h$B<9EI)x|$4X~>oTH7g`*?sI$AA%}OR;pt? z^c)a`*I^h~eMr7rgS}0TdEYFI#LVH*qMls}&Oh0CfV7>WfClo;yO2LHm}r3|<~CEz z=D;Kk;l0scPA+1%k@@oegUoW{zp^}fZPY;O%d=-Zd){j^lZxv``i_D>*xNdqZ>1ak z@pT|-E?JX%?bPp!Dqq%0C!3F^eoK#T*7{*e^qg0^54d^KQ?*Ecprsm zvbkfFIr||*s0Gs`r*?%aAYD|T)R zJAXW1CfTTfmSOoRVCO#`zu*t3cGRVlP1{`dU=o77xvw<+buhBT(1WM}ZLoVuMnk^SsBzb9KA5JVr<FuEs@Z=GjjgwBU3=ggHc%cB!Ag?me3>L-=g`qB2&vr#m`K>d~BhfzfqtQ zzs9}hK@BH}zl5__*FF)|e+h{_$GqIz=GM|S|1F26RbJTZeEtfsdbSf4+-D(up9uq| zdelmi?+xzzu;<;lCtrErc%8bhYf|=r_DGdueMizr>d*Mpkna9OAR0cb=DKG;oJ{09 zDVYXS?UK3Dbwv63*cM?#mU&>MYHoy;QL_C$)yu#pW`1ON(fjG@3>AG5*I{b`uqQYnVsN8xew57DXGnqvI=LTw~ z0A1xWy*;X|ki)14N{tT|mV91h0Bh5%((Db+B00O3FaN!v_$b^x6;Fc_)~gZIXd6J8 zOtQsi=$A1{_l3tJ{w*e(79NgGYx1Wh<-!gqj&(;$6l*&)+OmBLT`sU}Zq;jPV6fYS z!hB$uFYI%csbuJ-0&U{Hxm-|cAOlJBQ-#HgV=%NQGSxv5Jhb6FY~p- zW;j90wmCV8+o+(&a0j0UY@j1z6mnUMuy28ck*=l)!J^D%|#53IXZ#Onhcs#M(|pb3I?a^@h!a9HE+FNY0zt33 zT=8^Sw+vOG>W+c3;stj#;&9{%SMyk08;KC@7~rx##LSgaCGPor@R|wU;NiILsgD;& ydI2qVJ7~w;^cB;M3Sdaj*Z!8X7Y(#y%d(VG#_~`q7cNk7Gg!*4sfsp+G delta 10949 zcmb`M1ymf{nzoZ5g=-+Vh2VkU4uN2S00}O^p>arXuMns-1PJa$$Pj=60jLo0s}T(X&>;W=0x%%}3j(kq00#naApj2o@F9Qz0tg}CJ_Ha!05JqS zfB+H*AcX)j2q1?53J9Qt04fNeh5#A}poIWB2zUqq^bqg}0vI5G5dxSXfEfZM2;hSNeh3hN06_>4f&gI%5P<+u2oQq+aR_({ z0TK`(2?5U_Knen+AwUKKWFbHf0-i&FJOn5}zzYaatOAsNYJ#>35i>F;LD|n9x;Jjg zme>g1XSJ?MDLXYX@$+SPrS4QAhr{9hw&Us&c8>;=o`61o&Di}y#94ObuH5V)J&x~w zVT0!4Tl$j_C+VT>6o$+E_XEemB`?g;3LVGG>#SwwVcycpQB*H>3lAFPEC-YdOj&VD zx;(a#MtDe%>#D%Z3TyJRAkLAZ*F-(;Dcx2~x^=x48#xCP?H|=p#tcXaLgnZ|j+^5*-M z(PYo(?8m~)-)q(_9GWpTNJ$=!b-**F4peO$%HL?Q+(anRwxnQW*HZhc;$9 zG-29p|5Cy>rQgC)TbmO1!^XVCfkRSJaQj~T5&0(%*_a7|o0oZCjRG@@ZWFQWr%f%~ zE*t}*DNLx%^fp-YjiU`q*fsX%`m`4Ltxcf0VjKWgWckR0@$HiZQA&Nurd0nph;IIj zXB131%8Ad+Xip4dFH?N)#CD2t&z~7x_pnJpHDv8#^TKj0oRZ@3mDGW-fnMI~eZ%Of zH+vx@oJxvU;X}>EuVO99H!3QR09V=T*^Wfj9T%0rIqAsiWQOVDp!3u)bb9*iUJlRs z@0b;}#Z7HT6WCo(uA}|92EJdkGB58ZNo;~svqZklIpG0oDqpUV_SDEi??6A5ke3)j3;qFQOHcU@=d1aeex&Y zNcP;V1ETo6N#ybffp<|n&UeG96RUmXEJtH-na!p*jo2-)cXk8r4PA5c4t0oGm1?Mf z2(d1 zpn%2;X?3qj9B9`HHp%RJ;pzHg3!Pk4a1j&K7+yG1UGNc=d*jg+zD(nwBA@U|F5Cr| zAn-1mL~L;c{{E&jxJuQ$e^Bh}ZCtw(Q04PdT~Z^tdBr3k7yqP83LC!tQbTARU`SE_ z;qd^u0&hU_31%xBaz*pFp+@VP>)7?PJ^XZYJl8#MVcZVv3LbK|Rij)wdwRqxo9cw7 z7p8zIj=RiUcjKG#I8qu0HLW{zDDgiVn6t{q)ikbH5C(Z1*;Jc z@s3?5;As2BuNxoJEyKSuN~WTD(;Wr=Ey&2K{A{*)A}=Rq+WPvi%;7r+Q-Y$b=SVZ= zLp5ft%{()=n9hSK87N+HCmyX|S;)1*V@Uavxqy=i0@Ev8`V+gJ+e44skA+2DVwj(4 zQ-U7I8-XFiW4d{dN{)E3-AA1HN*nOU-9Et1)5n`#_&NKIwjfmK36E)r% za^NM4trugC8^hnG3fVVz`%m#T=+2Mlpp%5nI?)UoqzD{dOafb9#xiv%CJiFqgz7zN zK_*|tL_(P{DtzH69=01+(7!vH|KN&UL`x^&+|?1ayME&=?j+c2D1k$qBNQB^`*_)b zFY+bGMBr{iHnmbNPj? zoQ({5hT2Dl+%E3!x_Kxc(c=dvIkP)F$)Y1eJV{0 zLpDez6?H9?hr*&ZYlO5oTx>7DqYN#RgZd+O`teR5D1tXnpH-ypC8BziviSAx7{L>U?2<~minnXpm!B)_gyyCVKXwNqO0{t`ssJ{!=f@ zyHfptt=ePbAGq_)_W6Cq)Z*RTdEJLaJM+BuyW9SJ+>_DQ90>u6l(Jfv2k)2BjTmea zroi^lqj0Wrc`&!b$v0{swsOlcI=Vt#c?yNNKzKT{Ix>y>_CHrhBn2vu}P6YphiW*5ZZTRs~gU zyIQ@Nj{J9Vi*lLGtwJj9nzPfb%{T-%%YUy&*DvktVbPEIjF^XXYi|da%3G$~aIJEuBRUi1I1JL& zUcHPw#s6-rDiRpd{`PS3TQvM`x}*OfzL4xX#cyFh5MPY*Ju)T%n?D?%O2+LBg5ZxS z8|!Ml(nDCQ1|FjGcj)4zgVcgM@}av(EINyrbbBxV&R39^ie=E7CZ8t%Rw_eCAxjOc zSGu657CJ{ce=O*?{HZ4AOBolcu!iFt_KGjBrx1G7N>1rZs;GjE)z^(v5=V^39@Gav z6BoK9%oaj*A6+(Fu-g?T(yGE+vr`j5vz9R)b|+**az!WbR`ja{WjppeLPpc-h3`4ffC6OAwz=_o_b)+{a&JDMS9CoaGx7!MOB8>x7X-?&4Y8C-ub*bbO~# zN_D-PXCpBTnJ5OVEOs+L(!043}=$!hUl%K@dN=`;GN?0Z$ zLCkYxbxk@@+Pc+B8hJr(f0q_7l4o`j`X1 zwzBc;YtxFEucD4VF>^%B13_td^JXjeZ~_LGwT=}tj^{e?W|;f_=udVIF4t4GGIeBK zkI9kt7?7&^NbER<3LyefscCN*n>ZxUc7^i_JH?a88@&6eHRx3{CVeKY>83QX?45Y- zdz%a-IjQq9+qZmi&1X+=lq2-(jE9DpP|c5; zwNUp#E4TUnxa&eo=!O1HGd%#u&y=IZRp0aJN zx(Yu_gt;$@4@j)_#ZzxeSE3!?TbhcQyO*w)k+QBVX;jvZ2VNj!#}->4qj032X=kSy z2~L(1_HX9vGj&<0P2}Z7t-NJ~^3Mjfsm>L=u`o^b7p`_zg&&5$T00fkLDM0%FiVT} z)j-uDrEo=##!}-tOF}9$=;gq0U)~4-R6YA7C9jEs1%MOy=iI z{wTR?th9*>RXTDp=_}qKWu4QHztVT#3LC~vQ^|P8_fxz z`KN^Xmx801n8JwQy=*(KA@ifFGECDEdx1?#ZT%l-&$1-pk3Lr4*mE^nMy4-r4AE*h z1bat0XO-lBRDa)8uhr_xY62}3h7h?l2vNjUWk;_kceHw)I=P`A`w$ote{}mX`oeQ0 z6&CRk$6m6&gAaYAY?c)bFPq*5amud9o3d4~l>@5Fy1W^X#qZtqa?VOneWwma~OM*oM`zk2O5Ed54(6a6B$1$)} ze}XY;z)#YCq>0n_#BU483F~%5&5KoB@bU6|;V#l3k&TryN2iK9WFNr{54DOEj4U8C zdka<|skc5^*XjP^bs~8FQHj8&X61xhqN5?3U;e4gGvrq`n^CsIZQ(nwY`(lS`Lb3- zt1^9LM3bdNaYtq38;X>V&GZFrmZGj$W|Ufk~W_l1lIA`BF|lM!TyZ&9ajd7Lt=4jp36)6se)exy@;A-Ib%Nwu=;U zSOj>CZBSr|>6&o&dhy_lDXi*E*XB~gldY=1_w1%uI_cb-cL`x}kRDp-4Ywy-H7E!3 z0=87QV%`wK^hL#WxcVLW$q`GNVik{qnio^|y%pq>OS z);}D-kWfe0cD{%SrOl9;>?Yu)D1QcOZ=_MjxoL!K>HT4$cmo$Ye%dIh3+ku1t+M_p z60@zRKSl8P2S#kZ$HUV5fP#pI2R$ zw=&V5hoLwky8C=v(k%EWe?Grt4}O_tn3of?s7>5&PEG{lt23u#6W^FcY>J8trYwF9 z;pNzqCKjxBS`1lFXDP2HyJQRg;Kr`c1o6sf+GoWyjs(5scm8&IM1$Yb3zwq&p275! z2xr7oKNt)@ZM>7QyCGrx>m-<0b*d3{?1;6Wrd>K$9M8b7MH#NTNJdHI-j=UQy)dlW9b2EYA!WrEae z{cUtQeVd+wP8Vqn>{>yTUEZ6G=TwBSnQc3F-Bbp{rw*gO0-*cSz?KPhA(CdK)muaG zd7G$9^c8_k90%5Y8+aKP;`(XxvtsrZZs&3;&%SM?w@dkudxIkU&}MS;l`2D<6YEueAel_tE%L=)Pd1Si?|?n-s(H*@fz@lgYb~F|9%hAOAMpz8 zV8rT;%fRkYX|l4vKu_sY-v=U*_HIV+HieGq&8tx2JxH+Wb(ODAW*BMo^ajF0_-9b1 z>A^@NK3%-T=jp7TG*9opiWt?*w`zD%-(c&Ju)+5#*`o&;&iZ9a`%$8@@TA+hkKDVw zw-$ql>z%WBT#6vg^B_WGFg z{Iub-C{cI2Q%x*9s$YtVc{ICL`gaKh|7M|YW!J6KN+kYap;CADvrzCJQ&+yK3J4K* zyKK&5Y4EwC7|Ns?s;T#!Xl$w=oE|XLJZZ6@<8!7k`q_^e!RQ}fY6-hdw;l|i2=kim z9gi;rnVi*+?48ZVKcH1E@P*pq&)QCP$*H_#@)SE{Qx2|Y*W@QNRg%liuolkkyenZ- z1~-D~QomVabbI`Fe#U;UTJnN$^~AU-#as}R^HTBbS_hha5i5seqsqG5(j`D6+3#G8 z9#}19jKt$#9o7{Fg6%TFenJ?6fz$z|5>AE@&7;9Su=Q2B&h9&Vu?y{=a zTI_u7YYUA~X8IJj z@|n zTxa})wURKOK7NZ`N7V$*3%PWU6uiyX@LdIDN-!vxQ759ByY z41IHzX$D5^+5BS|OF))bzKd;2W2{fuzjKW)z_-8reO&ZL(aCFyroPuE>@nw^C=9g`7`U@;aZF%YUn(XvpI`j_SsR z1+(vMS}$2%NrlJ2?9xI>_-aG=jr0coH6^79dE5lY_G2}x@VPMlRu!D%hF#*5^9syl zZEgh>Im3$(NN@&zvi*CTfzEO2)sy~NBKC_n!a@Bvupgqi=~fEF_H<2NkczZ~;=Js; z8pVBjKAdg@Tvd|_^-nH}FVxK_bJl@Iz$RCU_sc~|78f57Q&l_dtu7rve8u0mLg{Dm z>;?UOz~x$2(PrFS3y34&%d^(Mb35jiD{$(Y`#$%EFmRJCTIG5}Xd}{Vefhz1%`#Sm z@O;X>?mm)jErc_F6fnNMLH{x)wN29fWpQ?*<30=+PW`s!-BV-lLk>iHi`zwS?`}5K zmf3xHL5Z5^V|5dKtub2r75|+r&+s*P`t-9i7XKZkq_8QM%^zR8`F{z3j5^Y8Gxkao zU+8@Mj1ZTqlz%}70f|^ND!Y72K&Z)7YA($Nu91)il*1_XRnb+=`5gDTZbF!(x)=X- zSWK86T{5p8%b|z2AK{g$6psT=gf4SO z(8h6_x+ymw6GwfJdVb6%Z-Zpxo@w{uK2u$s9h=^8EC;iS(4l{GJ-;$KVZ$MEONO|@ z^AVw=sDo*$pI$j3)xk$R46NUbYIih>#dWQhD6~704TU*__t~lD!(Sn)nSD;w*ZvaH$!e~hnV{g_(m?Yz6h8jeKI!67DQ>5fm>A(MGWi7ZUA zK4hOM&Go|%rH^M8_X)DGWW=ZRf9$exh_SqN52O#ozCaVHZj|~ya&(d8x zQ%*;J`95>|8~M2ENUPkpix+2RJ!$`Aye@ z=kUJAOS7z?kY39VB(me%U(Jk}yzf?<2p-O9JXn07w{{FK z?yj?$Jqot$5s`c50DTaBs?&0pgA#S!Fhwz0UD@kmvd6=k;q`TTipF5S5?eumM>@&p zS9&=qDly&3_w$#8&E1zdjyb6ZoS)=B!HBoFYp!#*y|M21q#J^f2U&Aj@1RB}|N4h< zM&7)*uBfm}5VLF-;eBXS$kH4Aq)wMO4p)1M{lq0kX6s(GkpFa)`Igjy!ip*Fv2P;gJ5vqJ z+vfQi{Z*-@s+D*K^UsePMMiTe$RfkhYIaR2vS)Gx3cnWW%=m+ov`?=+2v^*vtzWB; z|M+ZhQO6{`%4et7x)N1i;@=jlvkQF@1P>5hHzZ6ai7(o1d2RkLYZAcd#f35ouk>@Cu3`n z7+tTGK7WTgiD`u^NfhaPmF3KIy2cT*iOZT_`P+*yCoWR`6-xf0 zg^QkR;12q+Cr!;z6l0>FZAX)Wt4Cr67Ic*qU5Pd!?VQh#xgu37!x9>tI8h}Dz;^QGs_umM@e?;}A^{U(+-2x3-Buo+ z1n2&e8$*oH{8!iAT1Ww&K({yxm~%Y5g4dhanaztw{Yf(gpItgA+Bt#~0Q`G{R4#rqvt{2Enw z4B|$2r`(g&Y#H*MRR@H5%jXJ%V5qgY;4CM#iW2^?CHuh}Tr-41p;iAFHv>{p(CL!R z+8vRaV81Ixe?O8_zC^i2NCkB@aUrxl&|H(e-?=vz(8)b}{7iW)uQSvNBtse|1mL!OAy(Taexuri&!#v7y4;81CFzzMU zOt>7{+*NcnizrumJ~Av7rlBF@qA96b04aj1m$rwp#2((_b!Ia!Z}=@=U+;%E?q`M{ zARSX5Bt)>Zwlj>k;qvTf~k%pE*s{}gqs}mj^ z>BE;fj|2=VO0PQ_MnJNDI_z^3x}67GcsVVSBkSC%x>hx}6&`FuKhD7ibEJtQsTZ>7tR`YyD^YZ(+Q7BL0#KB3)=Q?Ms~ zL!c#Bu3pb3x$9r1SKJ-)j$Jn2sCb8WVxa!EbA~`@!}hknOeLizlI7=v=qKTB$s2te zXR)8gZ(-Xd$LZNlfrgAA+gaW=9NEe0wjuja&_>5u$R_>>Lvs1)mk<`))`#CY6xCOi z(N}JFpB+r!KG^t>f(P?xlt&yDz5RUa7e6Tc>BG*_V?|{v4!EKZ5i9;wcOB8UgP_b# zn7naP`>yKbR1{s+NKQzwlWE3-({YQ66C*Db=@B`lho*V<{5-bPpz6=AVd@vT^hKwW z_w$NB`f+QwFnD(5u$}MDGc>jf6K2y?WB9N81pjySjw`G+-VU|_5F?j diff --git a/detection_rules/schemas/definitions.py b/detection_rules/schemas/definitions.py index bca4b212c27..1d8002cf06f 100644 --- a/detection_rules/schemas/definitions.py +++ b/detection_rules/schemas/definitions.py @@ -178,7 +178,7 @@ def validator(value): 'Use Case: Vulnerability' ] NonEmptyStr = NewType('NonEmptyStr', str, validate=validate.Length(min=1)) -MACHINE_LEARNING_PACKAGES = ['LMD', 'DGA', 'DED', 'ProblemChild', 'Beaconing', 'PAD'] +MACHINE_LEARNING_PACKAGES = ['LMD', 'DGA', 'DED', 'ProblemChild', 'Beaconing'] AlertSuppressionGroupBy = NewType('AlertSuppressionGroupBy', List[NonEmptyStr], validate=validate.Length(min=1, max=3)) AlertSuppressionMissing = NewType('AlertSuppressionMissing', str, validate=validate.OneOf(['suppress', 'doNotSuppress'])) diff --git a/pyproject.toml b/pyproject.toml index 70d18547558..05ea663ddf3 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "detection_rules" -version = "0.4.24" +version = "0.4.23" description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine." readme = "README.md" requires-python = ">=3.12" diff --git a/rules/integrations/pad/privileged_access_ml_linux_high_count_privileged_process_events_by_user.toml b/rules/integrations/pad/privileged_access_ml_linux_high_count_privileged_process_events_by_user.toml deleted file mode 100644 index 52fad6ef61e..00000000000 --- a/rules/integrations/pad/privileged_access_ml_linux_high_count_privileged_process_events_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "sysmon_linux"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected an increase in the execution of privileged commands by a user, suggesting potential privileged access activity. -This may indicate an attempt by the user to gain unauthorized access to sensitive or restricted parts of the system. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_linux_high_count_privileged_process_events_by_user" -name = "Spike in Privileged Command Execution by a User" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "bd1eadf6-3ac6-4e66-91aa-4a1e6711915f" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Linux events collected by [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) or [Sysmon Linux](https://docs.elastic.co/en/integrations/sysmon_linux) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add Sysmon Linux integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Privileged Command Execution by a User - -Machine learning models are employed to monitor and analyze user behavior, specifically focusing on the execution of privileged commands. These models identify anomalies that may suggest unauthorized access attempts. Adversaries often exploit valid accounts to escalate privileges and access sensitive systems. The detection rule leverages ML to flag unusual spikes in command execution, indicating potential misuse of privileged access. - -### Possible investigation steps - -- Review the specific user account associated with the spike in privileged command execution to determine if the activity aligns with their typical behavior or job role. -- Analyze the timeline of the command execution spike to identify any patterns or specific times when the activity occurred, which may correlate with known maintenance windows or unusual access times. -- Cross-reference the commands executed with known privileged command lists to assess whether the commands are typical for the user's role or indicative of potential misuse. -- Check for any recent changes in the user's access rights or group memberships that might explain the increase in privileged command execution. -- Investigate any recent login activity for the user, including source IP addresses and devices, to identify any anomalies or unauthorized access attempts. -- Review any associated alerts or logs for the same user or system around the time of the spike to gather additional context or corroborating evidence of potential unauthorized access. - -### False positive analysis - -- Routine administrative tasks by IT staff may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. -- Automated scripts or scheduled jobs that execute privileged commands can be mistaken for anomalies. Identify and whitelist these scripts or jobs to prevent false alerts. -- Users with newly assigned roles that require elevated privileges might cause a temporary spike in command execution. Monitor these users initially and adjust the model's sensitivity or add exceptions as needed. -- Software updates or installations that require elevated permissions can lead to false positives. Document these events and exclude them from the anomaly detection criteria. -- Training or onboarding sessions where users are learning to use new systems with privileged access can result in increased command execution. Temporarily adjust thresholds or exclude these users during the training period. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further execution of privileged commands. This can be done by disabling the account or changing its password. -- Review recent privileged command execution logs to identify any unauthorized or suspicious activities performed by the user. Focus on commands that could alter system configurations or access sensitive data. -- Conduct a thorough investigation to determine if the user's credentials have been compromised. This may involve checking for signs of phishing attacks or unauthorized access from unusual locations or devices. -- If unauthorized access is confirmed, reset the affected user's credentials and any other accounts that may have been accessed using the compromised credentials. -- Notify the security team and relevant stakeholders about the incident, providing details of the detected anomaly and actions taken so far. -- Implement additional monitoring on the affected systems and user accounts to detect any further suspicious activities or attempts to regain unauthorized access. -- Review and update access controls and permissions to ensure that users have the minimum necessary privileges, reducing the risk of privilege escalation in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_linux_high_median_process_command_line_entropy_by_user.toml b/rules/integrations/pad/privileged_access_ml_linux_high_median_process_command_line_entropy_by_user.toml deleted file mode 100644 index 85afe5b4a97..00000000000 --- a/rules/integrations/pad/privileged_access_ml_linux_high_median_process_command_line_entropy_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "sysmon_linux"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusually high median command line entropy for privileged commands executed by a user, suggesting possible privileged access activity through command lines. -High entropy often indicates that the commands may be obfuscated or deliberately complex, which can be a sign of suspicious or unauthorized use of privileged access. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_linux_high_median_process_command_line_entropy_by_user" -name = "High Command Line Entropy Detected for Privileged Commands" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "0cbbb5e0-f93a-47fe-ab72-8213366c38f1" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Linux events collected by [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) or [Sysmon Linux](https://docs.elastic.co/en/integrations/sysmon_linux) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add Sysmon Linux integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating High Command Line Entropy Detected for Privileged Commands - -Machine learning models analyze command line inputs to identify high entropy, which may indicate obfuscation or complexity in privileged commands. Adversaries exploit this by using intricate or encoded commands to mask unauthorized activities. The detection rule leverages this analysis to flag potential privilege escalation attempts, aiding in early threat identification and response. - -### Possible investigation steps - -- Review the command line inputs flagged by the alert to identify any patterns or specific obfuscation techniques used. -- Cross-reference the user account associated with the alert against known valid accounts and recent access logs to determine if the activity aligns with expected behavior. -- Analyze the context of the commands executed, including the time of execution and the systems targeted, to assess the potential impact and scope of the activity. -- Check for any recent changes in user privileges or roles that might explain the execution of privileged commands. -- Investigate any related alerts or logs that might provide additional context or corroborate the suspicious activity, such as failed login attempts or unusual network connections. -- Consult with the user or relevant personnel to verify if the commands were part of legitimate administrative tasks or if they indicate unauthorized access. - -### False positive analysis - -- Legitimate administrative scripts may have high entropy due to complex or encoded commands. Review and whitelist these scripts to prevent unnecessary alerts. -- Automated deployment tools often use obfuscated commands for security reasons. Identify and exclude these tools from the rule to reduce false positives. -- Security software updates might execute encoded commands as part of their process. Monitor and create exceptions for these updates to avoid misclassification. -- Developers and IT staff may use complex command lines for testing or debugging. Establish a baseline of normal activity for these users and adjust the rule accordingly. -- Scheduled tasks or cron jobs with encoded commands can trigger alerts. Document and exclude these tasks if they are verified as non-threatening. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. -- Review and terminate any suspicious or unauthorized processes running under privileged accounts on the affected system. -- Reset passwords for all privileged accounts involved, ensuring they meet strong password policies to prevent unauthorized access. -- Conduct a thorough audit of recent privileged command executions to identify any unauthorized changes or data access, and revert any malicious modifications. -- Implement additional monitoring on the affected system and related accounts to detect any further suspicious activities. -- Escalate the incident to the security operations center (SOC) for a comprehensive investigation and to determine if other systems are affected. -- Update and reinforce endpoint protection measures to detect and block similar obfuscation or high-entropy command line activities in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_linux_rare_process_executed_by_user.toml b/rules/integrations/pad/privileged_access_ml_linux_rare_process_executed_by_user.toml deleted file mode 100644 index 19313bc572e..00000000000 --- a/rules/integrations/pad/privileged_access_ml_linux_rare_process_executed_by_user.toml +++ /dev/null @@ -1,98 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "sysmon_linux"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected an unusual process run for privileged commands by a user, indicating potential privileged access activity. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_linux_rare_process_executed_by_user" -name = "Unusual Process Detected for Privileged Commands by a User" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "5eac16ab-6d4f-427b-9715-f33e1b745fc7" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Linux logs collected by integrations such as Elastic Defend and Sysmon Linux. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Linux events collected by [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) or [Sysmon Linux](https://docs.elastic.co/en/integrations/sysmon_linux) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add Sysmon Linux integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Process Detected for Privileged Commands by a User - -Machine learning models are employed to identify anomalies in process execution, particularly those involving privileged commands. Adversaries may exploit legitimate user accounts to execute unauthorized privileged actions, aiming for privilege escalation. This detection rule leverages ML to flag atypical processes, indicating potential misuse of elevated access, thus aiding in early threat identification. - -### Possible investigation steps - -- Review the specific user account associated with the alert to determine if the account has a history of executing privileged commands or if this is an anomaly. -- Examine the process details, including the command line arguments and the parent process, to identify if the process is legitimate or potentially malicious. -- Check the timestamp of the process execution to correlate with any other suspicious activities or alerts that occurred around the same time. -- Investigate the source IP address or host from which the command was executed to verify if it is a known and trusted location for the user. -- Look into recent authentication logs for the user account to identify any unusual login patterns or access from unfamiliar devices. -- Assess the user's role and permissions to determine if the execution of such privileged commands aligns with their job responsibilities. - -### False positive analysis - -- Routine administrative tasks by IT staff may trigger alerts. Review and whitelist known administrative processes that are regularly executed by trusted personnel. -- Automated scripts or scheduled tasks that perform privileged operations can be flagged. Identify and exclude these scripts if they are verified as part of normal operations. -- Software updates or installations that require elevated privileges might be detected. Ensure that these processes are documented and excluded if they are part of standard maintenance procedures. -- Development or testing environments where privileged commands are frequently used for legitimate purposes can cause false positives. Consider creating exceptions for these environments after thorough validation. -- Temporary elevated access granted for specific projects or tasks can lead to alerts. Monitor and document these instances, and adjust the detection rule to accommodate such temporary changes. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized privileged actions. This can be done by disabling the account or changing its password. -- Review and terminate any suspicious processes or sessions initiated by the user account to contain potential malicious activity. -- Conduct a thorough audit of recent privileged commands executed by the user to identify any unauthorized changes or actions that need to be reversed. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. -- Implement additional monitoring on the affected system and user account to detect any further anomalous behavior or attempts at privilege escalation. -- Review and update access controls and permissions for the affected user account to ensure they align with the principle of least privilege. -- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_high_sum_concurrent_sessions_by_user.toml b/rules/integrations/pad/privileged_access_ml_okta_high_sum_concurrent_sessions_by_user.toml deleted file mode 100644 index bb301ab153f..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_high_sum_concurrent_sessions_by_user.toml +++ /dev/null @@ -1,103 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected an unusually high number of active concurrent sessions initiated by a user, indicating potential privileged access activity. -A sudden surge in concurrent active sessions by a user may indicate an attempt to abuse valid credentials for privilege escalation or maintain persistence. -Adversaries might be leveraging multiple sessions to execute privileged operations, evade detection, or perform unauthorized actions across different systems. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_high_sum_concurrent_sessions_by_user" -name = "Unusual Spike in Concurrent Active Sessions by a User" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "a300dea6-e228-40e1-9123-a339e207378b" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Spike in Concurrent Active Sessions by a User - -The detection of unusual spikes in concurrent active sessions leverages machine learning to identify anomalies in user behavior, particularly those suggesting privilege misuse. Adversaries may exploit valid credentials to initiate multiple sessions, aiming to escalate privileges or evade detection. This rule identifies such anomalies, flagging potential unauthorized access or privilege escalation attempts. - -### Possible investigation steps - -- Review the user's recent activity logs to identify any unusual patterns or deviations from their typical behavior, focusing on the timestamps and systems accessed during the spike in concurrent sessions. -- Check for any recent changes in the user's access privileges or roles that might explain the increase in session activity, ensuring that these changes were authorized and documented. -- Investigate the source IP addresses and geolocations associated with the concurrent sessions to determine if they align with the user's known locations or if they suggest potential unauthorized access. -- Analyze the specific actions performed during the concurrent sessions to identify any attempts at privilege escalation or unauthorized access to sensitive systems or data. -- Correlate the user's session activity with any other security alerts or incidents to assess if this behavior is part of a larger pattern of suspicious activity. - -### False positive analysis - -- High-volume legitimate activities such as system updates or batch processing can trigger false positives. Exclude these activities by identifying and whitelisting known processes or users involved in such operations. -- Users with roles that require multiple concurrent sessions, like system administrators or developers, may naturally exhibit this behavior. Create exceptions for these roles by defining baseline session patterns and adjusting thresholds accordingly. -- Automated scripts or tools that require multiple logins for monitoring or maintenance tasks can be mistaken for suspicious activity. Document and exclude these scripts by associating them with specific user accounts or service accounts. -- Temporary spikes due to legitimate business needs, such as end-of-quarter financial processing, can be misinterpreted. Implement a process to temporarily adjust detection parameters during known high-activity periods. -- Shared accounts used by multiple team members can lead to an increase in concurrent sessions. Encourage the use of individual accounts and implement monitoring to differentiate between shared and individual account activities. - -### Response and remediation - -- Immediately isolate the user account showing unusual concurrent session activity to prevent further unauthorized access or privilege escalation. -- Conduct a thorough review of the affected systems and sessions to identify any unauthorized changes or actions performed during the spike in activity. -- Reset the credentials of the compromised user account and enforce a password change policy to ensure the account is secured. -- Analyze logs and session data to determine the source of the unauthorized access, identifying any potential entry points or vulnerabilities exploited. -- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. -- Implement additional monitoring on the affected systems and user accounts to detect any further suspicious activity or attempts to regain access. -- Review and update access controls and permissions to ensure that only authorized users have the necessary privileges, reducing the risk of future privilege escalation attempts.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_rare_host_name_by_user.toml b/rules/integrations/pad/privileged_access_ml_okta_rare_host_name_by_user.toml deleted file mode 100644 index 3e4041e22dd..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_rare_host_name_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Okta from an uncommon device, indicating potential privileged access activity. -This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_rare_host_name_by_user" -name = "Unusual Host Name for Okta Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "8c9ae3e2-f0b1-4b2c-9eba-bd87c2db914f" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Host Name for Okta Privileged Operations Detected - -Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by using stolen credentials or unauthorized devices to perform privileged operations, potentially leading to privilege escalation. The detection rule leverages machine learning to identify anomalies in host names associated with privileged actions, flagging unusual device usage that may indicate compromised accounts or insider threats. - -### Possible investigation steps - -- Review the alert details to identify the specific user and host name involved in the unusual activity. -- Check the user's recent login history and device usage patterns in Okta to determine if the host name has been used before or if it is indeed uncommon. -- Investigate the geographical location and IP address associated with the unusual host name to assess if it aligns with the user's typical access patterns. -- Examine any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, to identify potential signs of compromise. -- Correlate the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack or insider threat. -- Contact the user to verify if they recognize the device and host name, and if they were performing the privileged operations at the time of the alert. -- If unauthorized access is confirmed, follow incident response procedures to secure the account, such as resetting credentials and reviewing access permissions. - -### False positive analysis - -- Users accessing Okta from new or temporary devices may trigger false positives. Regularly update the list of approved devices to include these new devices if they are legitimate. -- Employees traveling or working remotely might use different devices or networks, causing alerts. Implement a process to verify and whitelist these devices when travel or remote work is expected. -- IT staff performing legitimate administrative tasks from shared or uncommon devices can be mistaken for threats. Maintain a log of such activities and cross-reference with alerts to identify and exclude these benign actions. -- Changes in device naming conventions or system upgrades can result in unusual host names. Ensure that any planned changes are communicated and documented to adjust the detection parameters accordingly. -- Regularly review and refine the machine learning model's training data to minimize false positives by incorporating feedback from security teams on legitimate activities that were incorrectly flagged. - -### Response and remediation - -- Immediately isolate the device associated with the unusual host name from the network to prevent further unauthorized access or potential lateral movement. -- Revoke any active sessions and reset the credentials for the affected Okta account to prevent further unauthorized access. -- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or access. -- Notify the security operations team and relevant stakeholders about the potential compromise for further investigation and monitoring. -- Implement additional monitoring on the affected account and similar privileged accounts to detect any further suspicious activities. -- Review and update access controls and policies to ensure that only authorized devices can perform privileged operations in Okta. -- Consider enabling multi-factor authentication (MFA) for all privileged accounts to add an additional layer of security against unauthorized access.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_rare_region_name_by_user.toml b/rules/integrations/pad/privileged_access_ml_okta_rare_region_name_by_user.toml deleted file mode 100644 index 660d58058d1..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_rare_region_name_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Okta from an uncommon geographical location, indicating potential privileged access activity. -This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_rare_region_name_by_user" -name = "Unusual Region Name for Okta Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "a8f7187f-76d6-4c1d-a1d5-1ff301ccc120" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Region Name for Okta Privileged Operations Detected - -Okta is a widely used identity management service that controls access to applications and data. Adversaries may exploit stolen credentials to perform privileged operations from unusual locations, bypassing security measures. The detection rule leverages machine learning to identify anomalies in user activity, such as access from uncommon regions, indicating potential unauthorized access or privilege escalation attempts. - -### Possible investigation steps - -- Review the alert details to identify the user account involved and the specific unusual region from which the privileged operations were detected. -- Check the user's recent login history and activity logs in Okta to determine if there are other instances of access from uncommon regions or any other suspicious activities. -- Verify with the user or their manager whether the access from the unusual region was expected or authorized, and if the user is currently traveling or using a VPN. -- Investigate any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, to identify potential signs of compromise. -- Correlate the detected activity with other security logs and alerts to identify any related incidents or patterns that might indicate a broader attack or compromise. -- Assess the risk and impact of the detected activity by determining the specific privileged operations performed and whether any sensitive data or systems were accessed. -- If unauthorized access is confirmed, follow the organization's incident response procedures to contain and remediate the threat, including resetting the user's credentials and reviewing access permissions. - -### False positive analysis - -- Users traveling for business may trigger false positives if they access Okta from uncommon regions. To manage this, create exceptions for users with known travel patterns by updating their profiles with expected travel locations. -- Remote employees working from different geographical locations than usual can cause false alerts. Implement a process to regularly update the list of approved remote work locations for these users. -- Employees using VPNs that route through different countries might be flagged. Identify and whitelist common VPN exit nodes used by your organization to prevent these false positives. -- Temporary assignments or projects in different regions can lead to alerts. Establish a communication protocol for employees to notify the security team of such assignments, allowing for temporary exceptions to be made. -- Consider time-based analysis to differentiate between legitimate access during business hours and suspicious activity at unusual times, reducing false positives from legitimate users accessing Okta from uncommon regions. - -### Response and remediation - -- Immediately isolate the affected user account by disabling it to prevent further unauthorized access or privilege escalation. -- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or access. -- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. -- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. -- Review and update access controls and permissions for the affected account to ensure they align with the principle of least privilege. -- Monitor for any additional suspicious activity across other accounts and systems to identify potential lateral movement or further compromise. -- Document the incident details and response actions taken for future reference and to improve incident response processes.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_rare_source_ip_by_user.toml b/rules/integrations/pad/privileged_access_ml_okta_rare_source_ip_by_user.toml deleted file mode 100644 index 8afedb028fb..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_rare_source_ip_by_user.toml +++ /dev/null @@ -1,98 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Okta from an uncommon source IP, indicating potential privileged access activity. -This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_rare_source_ip_by_user" -name = "Unusual Source IP for Okta Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "fbb10f1e-77cb-42f9-994e-5da17fc3fc15" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Source IP for Okta Privileged Operations Detected - -Okta is a widely used identity management service that controls access to applications and data. Adversaries may exploit Okta by using stolen credentials to perform privileged operations from unfamiliar IP addresses, indicating potential misuse or compromise. The detection rule leverages machine learning to identify deviations in IP usage patterns, flagging unusual access attempts that could signify privilege escalation or account compromise. - -### Possible investigation steps - -- Review the source IP address flagged by the alert to determine its geolocation and assess if it aligns with the user's typical access patterns or known locations. -- Check the Okta logs for the specific user account to identify any other recent activities from the same IP address or any other unusual IP addresses. -- Investigate the timing and nature of the privileged operations performed to determine if they align with the user's normal behavior or job responsibilities. -- Correlate the flagged IP address with any known threat intelligence feeds to check for any history of malicious activity associated with it. -- Contact the user to verify if they were aware of the access attempt and if they have recently used a new network location or VPN service. -- Examine any recent changes to the user's account settings or permissions that could indicate unauthorized modifications. - -### False positive analysis - -- Employees traveling or working remotely may trigger alerts due to accessing Okta from new IP addresses. To manage this, maintain a list of known IP ranges for remote work and travel, and configure exceptions for these ranges. -- Use of VPNs or proxy services can result in access from unfamiliar IPs. Regularly update the list of approved VPN or proxy IP addresses and exclude them from triggering alerts. -- Changes in corporate network infrastructure, such as new IP allocations, can cause false positives. Ensure that any changes in network configurations are communicated to the security team to update the detection rule's exceptions. -- Scheduled maintenance or testing activities by IT staff might appear as unusual access. Document and whitelist IP addresses used during these activities to prevent unnecessary alerts. -- Third-party integrations or services that access Okta on behalf of users can be mistaken for suspicious activity. Identify and whitelist these services' IP addresses to avoid false positives. - -### Response and remediation - -- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access. -- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or data access. -- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. -- Notify the security team and relevant stakeholders about the potential compromise for further investigation and monitoring. -- Review and update access logs to ensure all unusual IP addresses are flagged and monitored for any future access attempts. -- Implement network-based restrictions to block the identified unusual IP address from accessing the Okta environment. -- Conduct a post-incident analysis to identify the root cause and update security policies and procedures to prevent similar incidents in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_application_assignment_changes.toml b/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_application_assignment_changes.toml deleted file mode 100644 index 2aa4d26b546..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_application_assignment_changes.toml +++ /dev/null @@ -1,108 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating potential privileged access activity. -Threat actors might be assigning applications to groups to escalate access, maintain persistence, or facilitate lateral movement within an organization’s environment. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_spike_in_group_application_assignment_changes" -name = "Spike in Group Application Assignment Change Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "3278313c-d6cd-4d49-aa24-644e1da6623c" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Group Application Assignment Change Events - -In modern environments, identity and access management systems like Okta manage user access to applications. Adversaries may exploit these systems by altering group application assignments to gain unauthorized access or escalate privileges. The detection rule leverages machine learning to identify unusual spikes in these changes, signaling potential misuse and enabling timely investigation of privilege escalation activities. - -### Possible investigation steps - -- Review the specific group application assignment change events that triggered the alert to identify which groups and applications were involved. -- Analyze the timeline of the changes to determine if there is a pattern or specific time frame when the spike occurred. -- Investigate the user accounts associated with the changes to assess if they have a history of suspicious activity or if they belong to high-risk roles. -- Check for any recent changes in group membership or application access policies that could explain the spike in assignment changes. -- Correlate the events with other security alerts or logs to identify any concurrent suspicious activities, such as failed login attempts or unusual access patterns. -- Consult with the IT or security team to verify if there were any legitimate administrative activities or changes that could have caused the spike. - -### False positive analysis - -- Routine administrative changes in group application assignments can trigger false positives. Regularly review and document these changes to differentiate them from suspicious activities. -- Automated processes or scripts that frequently update group assignments may cause spikes. Identify and whitelist these processes to prevent unnecessary alerts. -- Organizational restructuring or onboarding/offboarding activities can lead to increased group assignment changes. Temporarily adjust the detection thresholds or exclude these events during known periods of high activity. -- Changes related to application updates or migrations might be flagged. Coordinate with IT teams to schedule these changes and exclude them from monitoring during the update window. -- Frequent changes by trusted users or administrators can be excluded by creating exceptions for specific user accounts or roles, ensuring that only unexpected changes trigger alerts. - -### Response and remediation - -- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. -- Revert any unauthorized group application assignments to their previous state to mitigate potential misuse. -- Conduct a thorough review of recent changes in group application assignments to identify any additional unauthorized modifications. -- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised. -- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activity. -- Review and update access controls and group assignment policies to prevent similar unauthorized changes in the future. -- Coordinate with the IT and security teams to ensure that all affected systems and applications are patched and secured against known vulnerabilities.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_lifecycle_changes.toml b/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_lifecycle_changes.toml deleted file mode 100644 index 6b501e7bf02..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_lifecycle_changes.toml +++ /dev/null @@ -1,103 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusual spike in Okta group lifecycle change events, indicating potential privileged access activity. -Adversaries may be altering group structures to escalate privileges, maintain persistence, or facilitate lateral movement within an organization’s identity management system. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_spike_in_group_lifecycle_changes" -name = "Spike in Group Lifecycle Change Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "aa28f01d-bc93-4c8f-bc01-6f67f2a0a833" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Group Lifecycle Change Events - -In identity management systems like Okta, group lifecycle changes are crucial for managing user access and permissions. Adversaries may exploit these changes to escalate privileges or maintain unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on privilege escalation tactics, it helps security analysts pinpoint and investigate suspicious activities. - -### Possible investigation steps - -- Review the specific group lifecycle change events that triggered the alert to identify which groups were altered and the nature of the changes. -- Examine the user accounts associated with the changes to determine if they have a history of suspicious activity or if they have recently been granted elevated privileges. -- Check the timestamps of the group changes to see if they coincide with other unusual activities or known attack patterns within the organization. -- Investigate any recent access requests or approvals related to the affected groups to ensure they were legitimate and authorized. -- Correlate the group changes with other security alerts or logs to identify potential lateral movement or privilege escalation attempts by adversaries. -- Assess the current membership of the affected groups to ensure no unauthorized users have been added or legitimate users removed. - -### False positive analysis - -- Routine administrative changes in group memberships can trigger false positives. Security teams should identify and whitelist these regular activities to prevent unnecessary alerts. -- Automated processes or scripts that modify group structures for legitimate reasons may cause spikes. Exclude these known processes by creating exceptions in the detection rule. -- Large-scale onboarding or offboarding events can lead to a temporary increase in group lifecycle changes. Coordinate with HR or relevant departments to anticipate these events and adjust monitoring thresholds accordingly. -- Changes due to system integrations or updates might be misinterpreted as suspicious. Document and exclude these events by maintaining an updated list of integration activities. -- Regular audits or compliance checks that involve group modifications should be recognized and filtered out to avoid false alarms. - -### Response and remediation - -- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. This can be done by temporarily disabling accounts or removing them from critical groups. -- Conduct a thorough review of recent group lifecycle changes to identify unauthorized modifications. Revert any unauthorized changes to restore the original group structures and permissions. -- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activities. This includes setting up alerts for any new group changes or access attempts. -- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms used by the adversary. -- Review and update access controls and group management policies to ensure they align with the principle of least privilege, minimizing the risk of privilege escalation. -- Coordinate with the IT and security teams to apply patches or updates to any vulnerabilities identified during the investigation that may have been exploited for privilege escalation. -- Document the incident, including all actions taken, and conduct a post-incident review to identify lessons learned and improve future response strategies.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_membership_changes.toml b/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_membership_changes.toml deleted file mode 100644 index 52850c7584a..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_membership_changes.toml +++ /dev/null @@ -1,103 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusual spike in Okta group membership events, indicating potential privileged access activity. -Attackers or malicious insiders might be adding accounts to privileged groups to escalate their access, potentially leading to unauthorized actions or data breaches. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_spike_in_group_membership_changes" -name = "Spike in Group Membership Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "138520d2-11ff-4288-a80e-a45b36dca4b1" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Group Membership Events - -In modern IT environments, group membership management is crucial for controlling access to resources. Adversaries may exploit this by adding accounts to privileged groups, thereby escalating their access rights. The detection rule leverages machine learning to identify unusual spikes in group membership events, signaling potential unauthorized access attempts. This proactive approach helps in mitigating risks associated with privilege escalation. - -### Possible investigation steps - -- Review the specific Okta group membership events that triggered the alert to identify which accounts were added to privileged groups. -- Cross-reference the accounts added with known user roles and responsibilities to determine if the changes align with expected access patterns. -- Check recent activity logs for the accounts added to privileged groups to identify any suspicious or unauthorized actions following the group membership change. -- Investigate the source of the group membership changes, including the user or system that initiated the changes, to assess if it was a legitimate administrative action. -- Analyze historical data for similar spikes in group membership events to determine if this is part of a recurring pattern or an isolated incident. -- Consult with the IT or security team to verify if there were any recent changes in access policies or group management procedures that could explain the spike. - -### False positive analysis - -- Routine administrative tasks may trigger spikes in group membership events, such as scheduled updates or onboarding processes. Users can create exceptions for these known activities to prevent false alerts. -- Automated scripts or tools that manage group memberships for legitimate purposes might cause false positives. Identifying and excluding these scripts from monitoring can reduce unnecessary alerts. -- Changes in group membership due to organizational restructuring or policy updates can appear as spikes. Documenting these changes and adjusting the detection parameters accordingly can help mitigate false positives. -- Frequent legitimate access requests to privileged groups during specific business cycles, like end-of-quarter financial reviews, can be excluded by setting time-based exceptions. -- Regular audits or compliance checks that involve temporary access to privileged groups should be accounted for by creating temporary exceptions during these periods. - -### Response and remediation - -- Immediately isolate the affected accounts by removing them from any privileged groups to prevent further unauthorized access. -- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized additions and remove them as necessary. -- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise. -- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. -- Implement additional monitoring on the affected accounts and privileged groups to detect any further suspicious activity. -- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future unauthorized changes. -- Document the incident and response actions taken, and conduct a post-incident review to identify any gaps in the current security posture and improve future response efforts.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_privilege_changes.toml b/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_privilege_changes.toml deleted file mode 100644 index 7dbba917a9b..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_privilege_changes.toml +++ /dev/null @@ -1,108 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential privileged access activity. -Attackers might be elevating privileges by adding themselves or compromised accounts to high-privilege groups, enabling further access or persistence. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_spike_in_group_privilege_changes" -name = "Spike in Group Privilege Change Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "02b4420d-eda2-4529-9e46-4a60eccb7e2d" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Group Privilege Change Events - -In environments using Okta, group privilege changes are crucial for managing access. Adversaries may exploit this by adding themselves to privileged groups, gaining unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential privilege escalation attempts, thus aiding in early threat detection and response. - -### Possible investigation steps - -- Review the specific group privilege change events identified by the machine learning job to determine which accounts were added to privileged groups. -- Cross-reference the accounts involved in the privilege changes with recent login activity to identify any unusual or suspicious access patterns. -- Check the history of privilege changes for the affected groups to see if there is a pattern of unauthorized access or if this is an isolated incident. -- Investigate the source IP addresses and locations associated with the privilege change events to identify any anomalies or unexpected geolocations. -- Examine any recent changes to the accounts involved, such as password resets or multi-factor authentication (MFA) modifications, to assess if they have been compromised. -- Collaborate with the affected users or their managers to verify if the privilege changes were authorized and legitimate. - -### False positive analysis - -- Routine administrative tasks may trigger spikes in group privilege changes. Regularly scheduled audits or updates to group memberships should be documented and excluded from alerts. -- Automated scripts or tools that manage user access can cause frequent changes. Identify these scripts and create exceptions for their activity to prevent false positives. -- Organizational restructuring or mergers often lead to bulk updates in group privileges. During these periods, temporarily adjust the sensitivity of the detection rule or whitelist specific activities. -- Onboarding or offboarding processes can result in a high volume of legitimate group changes. Coordinate with HR and IT to anticipate these events and adjust monitoring accordingly. -- Changes in security policies or compliance requirements might necessitate widespread privilege adjustments. Ensure these policy-driven changes are communicated to the security team to avoid unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected accounts by removing them from any high-privilege groups to prevent further unauthorized access. -- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized privilege escalations. -- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise. -- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further suspicious activity is detected. -- Implement additional monitoring on the affected accounts and privileged groups to detect any further unauthorized changes or access attempts. -- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation. -- Document the incident, including all actions taken, to improve response strategies and inform future security measures.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_okta_spike_in_user_lifecycle_management_changes.toml b/rules/integrations/pad/privileged_access_ml_okta_spike_in_user_lifecycle_management_changes.toml deleted file mode 100644 index cac477ef970..00000000000 --- a/rules/integrations/pad/privileged_access_ml_okta_spike_in_user_lifecycle_management_changes.toml +++ /dev/null @@ -1,102 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad","okta"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating potential privileged access activity. -Threat actors may manipulate user accounts to gain higher access rights or persist within the environment. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_okta_spike_in_user_lifecycle_management_changes" -name = "Spike in User Lifecycle Management Change Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "178770e0-5c20-4246-b430-e216a2888b23" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration. -- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in User Lifecycle Management Change Events - -User lifecycle management in environments like Okta involves creating, modifying, and deleting user accounts. Adversaries may exploit this by manipulating accounts to escalate privileges or maintain access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on anomalies, it aids in early detection of privilege escalation tactics. - -### Possible investigation steps - -- Review the specific user accounts involved in the lifecycle management change events to identify any patterns or anomalies, such as multiple changes in a short period or changes made by unusual sources. -- Check the timestamps of the change events to determine if they align with normal business hours or if they occurred during unusual times, which might indicate suspicious activity. -- Investigate the source IP addresses and locations associated with the change events to identify any unusual or unauthorized access points. -- Examine the types of changes made to the user accounts, such as privilege escalations or role modifications, to assess if they align with legitimate business needs. -- Cross-reference the user accounts involved with recent security alerts or incidents to determine if they have been previously flagged for suspicious activity. -- Consult with the account owners or relevant department heads to verify if the changes were authorized and necessary for business operations. - -### False positive analysis - -- Routine administrative tasks such as bulk user account updates or scheduled maintenance can trigger spikes in user lifecycle management events. To manage this, create exceptions for known maintenance windows or bulk operations. -- Automated processes or scripts that regularly modify user accounts may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts. -- Onboarding or offboarding periods with high user account activity can lead to spikes. Adjust the detection thresholds temporarily during these periods or exclude specific user groups involved in these activities. -- Integration with third-party applications that frequently update user attributes might result in false positives. Review and whitelist these applications to reduce noise in the detection system. - -### Response and remediation - -- Immediately isolate the affected user accounts to prevent further unauthorized access or privilege escalation. This can be done by disabling the accounts or changing their passwords. -- Review and revoke any unauthorized permissions or roles that were assigned during the spike in user lifecycle management change events. Ensure that only legitimate access rights are restored. -- Conduct a thorough audit of recent user account changes to identify any additional accounts that may have been manipulated. Pay special attention to accounts with elevated privileges. -- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. -- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access. -- Escalate the incident to higher-level security management if the scope of the breach is extensive or if sensitive data may have been compromised. -- Review and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_high_count_group_management_events.toml b/rules/integrations/pad/privileged_access_ml_windows_high_count_group_management_events.toml deleted file mode 100644 index 81252548660..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_high_count_group_management_events.toml +++ /dev/null @@ -1,105 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a spike in group management events for a user, indicating potential privileged access activity. -The machine learning has flagged an abnormal rise in group management actions (such as adding or removing users from privileged groups), -which could point to an attempt to escalate privileges or unauthorized modifications to group memberships. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_high_count_group_management_events" -name = "Spike in Group Management Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "751b0329-7295-4682-b9c7-4473b99add69" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Group Management Events - -The detection of spikes in group management events leverages machine learning to monitor and identify unusual patterns in user activities related to group memberships. Adversaries may exploit this by adding or removing users from privileged groups to escalate privileges or alter access controls. The detection rule identifies these anomalies, flagging potential unauthorized modifications indicative of privilege escalation attempts. - -### Possible investigation steps - -- Review the specific user account associated with the spike in group management events to determine if the activity aligns with their typical behavior or role. -- Check the timeline of the group management events to identify any patterns or sequences that might suggest unauthorized access or privilege escalation attempts. -- Investigate the source IP addresses and devices used during the group management events to verify if they are consistent with the user's usual access points or if they indicate potential compromise. -- Examine recent changes to privileged groups, focusing on additions or removals of users, to assess if these modifications were authorized and necessary. -- Cross-reference the flagged events with any recent support tickets or change requests to confirm if the actions were legitimate and documented. -- Look for any other related alerts or anomalies in the same timeframe that might indicate a broader security incident or coordinated attack. - -### False positive analysis - -- Routine administrative tasks can trigger spikes in group management events, such as scheduled user onboarding or offboarding. To manage this, create exceptions for known periods of increased activity. -- Automated scripts or tools that manage group memberships might cause false positives. Identify these scripts and exclude their activities from the rule's monitoring. -- Changes in organizational structure, like department mergers, can lead to legitimate spikes. Document these changes and adjust the rule's sensitivity temporarily. -- Regular audits or compliance checks that involve group membership reviews may appear as anomalies. Schedule these activities and inform the monitoring team to prevent false alerts. -- High turnover rates in certain departments can result in frequent group changes. Monitor these departments separately and adjust thresholds accordingly. - -### Response and remediation - -- Immediately isolate the affected user account by disabling it to prevent further unauthorized group management activities. -- Review and audit recent changes to group memberships, focusing on privileged groups, to identify any unauthorized additions or removals. -- Revert any unauthorized changes to group memberships to restore the intended access controls. -- Conduct a thorough investigation to determine the source of the anomaly, including checking for compromised credentials or insider threats. -- Reset the password for the affected user account and enforce multi-factor authentication to enhance security. -- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. -- Implement additional monitoring on the affected account and related privileged groups to detect any further suspicious activities.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_high_count_special_logon_events.toml b/rules/integrations/pad/privileged_access_ml_windows_high_count_special_logon_events.toml deleted file mode 100644 index 64756c4dc9b..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_high_count_special_logon_events.toml +++ /dev/null @@ -1,102 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected a surge in special logon events for a user, indicating potential privileged access activity. -A sudden spike in these events could suggest an attacker or malicious insider gaining elevated access, possibly for lateral movement or privilege escalation. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_high_count_special_logon_events" -name = "Spike in Special Logon Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "097ef0b8-fb21-4e45-ad89-d81666349c6a" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Special Logon Events - -Special logon events are crucial for tracking privileged access, often indicating administrative actions. Adversaries exploit these by gaining elevated access to perform unauthorized activities, such as lateral movement or privilege escalation. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse and enabling timely investigation of suspicious privileged access activities. - -### Possible investigation steps - -- Review the user account associated with the spike in special logon events to determine if the account is expected to have privileged access. -- Check the time and frequency of the special logon events to identify any unusual patterns or times that deviate from the user's normal behavior. -- Investigate the source IP addresses and devices from which the special logon events originated to verify if they are known and trusted. -- Examine recent changes or activities performed by the user account to identify any unauthorized or suspicious actions that may indicate privilege escalation or lateral movement. -- Correlate the special logon events with other security alerts or logs, such as failed login attempts or changes in user permissions, to gather additional context and evidence of potential malicious activity. - -### False positive analysis - -- Regular administrative tasks by IT staff can trigger spikes in special logon events. To manage this, create exceptions for known administrative accounts that frequently perform legitimate privileged actions. -- Scheduled automated processes or scripts that require elevated access may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts. -- Software updates or system maintenance activities often involve multiple privileged logons. Document these events and adjust the detection thresholds temporarily during known maintenance windows to reduce false positives. -- Users with roles that inherently require frequent privileged access, such as system administrators or security personnel, may trigger alerts. Maintain a list of such roles and apply exclusions where appropriate to avoid constant alerts for expected behavior. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized access. Disable the account or change its credentials to stop any ongoing malicious activity. -- Conduct a thorough review of recent activities associated with the affected account to identify any unauthorized changes or access to sensitive systems and data. -- If lateral movement is suspected, isolate any systems accessed by the compromised account to prevent further spread of the threat. -- Escalate the incident to the security operations center (SOC) or incident response team for a detailed investigation and to determine the full scope of the breach. -- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to regain access. -- Review and update access controls and permissions to ensure that only necessary privileges are granted, reducing the risk of privilege escalation. -- Enhance detection capabilities by tuning existing monitoring tools to better identify similar spikes in special logon events, leveraging insights from the current incident.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_high_count_special_privilege_use_events.toml b/rules/integrations/pad/privileged_access_ml_windows_high_count_special_privilege_use_events.toml deleted file mode 100644 index 65600aba0ce..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_high_count_special_privilege_use_events.toml +++ /dev/null @@ -1,104 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected an unusual increase in special privilege usage events, such as privileged operations and service calls, for a user, suggesting potential unauthorized privileged access. -A sudden spike in these events may indicate an attempt to escalate privileges, execute unauthorized tasks, or maintain persistence within a system. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_high_count_special_privilege_use_events" -name = "Spike in Special Privilege Use Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "6fb2280a-d91a-4e64-a97e-1332284d9391" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in Special Privilege Use Events - -Machine learning models monitor special privilege use, identifying anomalies that suggest unauthorized access. Adversaries exploit these privileges to escalate access, execute unauthorized actions, or maintain system persistence. The detection rule leverages ML to spot unusual spikes in privileged operations, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Review the user account associated with the spike in special privilege use events to determine if the activity aligns with their normal behavior or job role. -- Examine the specific privileged operations and service calls that were flagged to identify any unusual or unauthorized actions. -- Check for any recent changes in user permissions or group memberships that could explain the increase in privilege use. -- Investigate any corresponding logs or alerts around the same timeframe to identify potential indicators of compromise or related suspicious activities. -- Assess the system or application where the privilege escalation occurred for any signs of exploitation or unauthorized access attempts. -- Correlate the detected spike with known threat intelligence or recent security advisories to determine if it matches any known attack patterns or vulnerabilities. - -### False positive analysis - -- Routine administrative tasks by IT personnel can trigger false positives. Regularly review and whitelist known administrative accounts to prevent unnecessary alerts. -- Scheduled maintenance activities often involve elevated privileges. Document and exclude these activities from monitoring during known maintenance windows. -- Automated scripts or services that require elevated privileges may cause spikes. Identify and exclude these scripts or services from the rule to reduce false positives. -- Software updates or installations can lead to temporary spikes in privilege use. Coordinate with IT to recognize these events and adjust monitoring rules accordingly. -- Frequent legitimate use of privileged operations by certain users or roles should be analyzed. Establish a baseline for these users and adjust the detection threshold to accommodate their normal activity levels. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized privileged operations. Disable the account or change its credentials to stop potential misuse. -- Conduct a thorough review of recent privileged operations and service calls associated with the user account to identify any unauthorized actions or changes made during the spike. -- Revoke any unnecessary privileges or access rights from the affected user account to minimize the risk of future exploitation. -- Implement additional monitoring on the affected system and user account to detect any further suspicious activities or attempts to regain unauthorized access. -- Escalate the incident to the security operations team for a deeper investigation into potential privilege escalation techniques used, referencing MITRE ATT&CK technique T1068. -- Review and update access control policies and privilege management practices to ensure they align with the principle of least privilege, reducing the risk of similar incidents. -- Conduct a post-incident analysis to identify any gaps in detection or response and enhance the machine learning model's ability to detect similar threats in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_high_count_user_account_management_events.toml b/rules/integrations/pad/privileged_access_ml_windows_high_count_user_account_management_events.toml deleted file mode 100644 index b9fa58a1cc4..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_high_count_user_account_management_events.toml +++ /dev/null @@ -1,104 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a spike in user account management events for a user, indicating potential privileged access activity. -This indicates an unusual increase in actions related to managing user accounts (such as creating, modifying, or deleting accounts), -which could be a sign of an attempt to escalate privileges or unauthorized activity involving account management. -""" -from = "now-3h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_high_count_user_account_management_events" -name = "Spike in User Account Management Events" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "37cca4d4-92ab-4a33-a4f8-44a7a380ccda" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Spike in User Account Management Events - -The detection rule leverages machine learning to identify unusual spikes in user account management activities, such as account creation or modification, which may indicate privilege escalation attempts. Adversaries exploit these activities to gain unauthorized access or elevate privileges. By analyzing patterns and deviations from normal behavior, the rule helps detect potential misuse, enabling timely intervention. - -### Possible investigation steps - -- Review the specific user account(s) involved in the spike to determine if the activity aligns with their typical behavior or role within the organization. -- Examine the timestamps of the account management events to identify any patterns or anomalies, such as activity occurring outside of normal business hours. -- Check for any recent changes in user permissions or roles that could explain the spike in account management events. -- Investigate any associated IP addresses or devices used during the account management activities to determine if they are known and trusted within the organization. -- Look for any correlated alerts or logs that might indicate concurrent suspicious activities, such as failed login attempts or access to sensitive resources. -- Consult with the user or their manager to verify if the account management activities were authorized and legitimate. - -### False positive analysis - -- Routine administrative tasks can trigger spikes in user account management events. Regularly scheduled account audits or bulk updates by IT staff may appear as unusual activity. To manage this, create exceptions for known maintenance periods or specific administrative accounts. -- Automated scripts or tools used for user provisioning and de-provisioning can cause false positives. Identify these scripts and exclude their activity from the rule to prevent unnecessary alerts. -- Onboarding or offboarding processes that involve creating or deleting multiple user accounts in a short period can be mistaken for privilege escalation attempts. Document these processes and adjust the rule to recognize these patterns as normal behavior. -- Changes in organizational structure, such as mergers or departmental shifts, may lead to increased account management activities. Update the rule to accommodate these changes by temporarily adjusting thresholds or excluding specific user groups during transition periods. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its password. -- Review recent account management activities for the affected user to identify any unauthorized changes or suspicious patterns. This includes checking for new account creations, modifications, or deletions. -- Conduct a thorough audit of the affected system and network segment to identify any additional compromised accounts or systems. Look for signs of lateral movement or further exploitation attempts. -- Revert any unauthorized changes made to user accounts or system configurations to their original state, ensuring that no backdoors or unauthorized access points remain. -- Notify the security team and relevant stakeholders about the incident, providing them with details of the spike in user account management events and any identified malicious activities. -- Implement additional monitoring and alerting for the affected user account and related systems to detect any further suspicious activities promptly. -- Review and update access controls and user account management policies to prevent similar incidents in the future, ensuring that only authorized personnel have the necessary privileges.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_rare_device_by_user.toml b/rules/integrations/pad/privileged_access_ml_windows_rare_device_by_user.toml deleted file mode 100644 index f0cc44add56..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_rare_device_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Windows from an uncommon device, indicating potential privileged access activity. -This could signal a compromised account, an attacker using stolen credentials, or an insider threat leveraging an unauthorized device to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_rare_device_by_user" -name = "Unusual Host Name for Windows Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "2bca4fcd-5228-4472-9071-148903a31057" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Host Name for Windows Privileged Operations Detected - -Machine learning models analyze patterns of privileged operations in Windows environments to identify anomalies, such as access from uncommon devices. Adversaries may exploit stolen credentials or unauthorized devices to escalate privileges. This detection rule flags such anomalies, indicating potential threats like compromised accounts or insider attacks, by assessing deviations from typical host usage patterns. - -### Possible investigation steps - -- Review the alert details to identify the specific user and host involved in the unusual privileged operation. -- Check the historical login patterns for the user to determine if the host has been used previously or if this is a new occurrence. -- Investigate the host's identity and location to assess if it aligns with the user's typical access patterns or if it appears suspicious. -- Examine recent activity logs for the user and host to identify any other unusual or unauthorized actions that may indicate a broader compromise. -- Verify if there are any known vulnerabilities or security incidents associated with the host that could have facilitated unauthorized access. -- Contact the user to confirm whether they recognize the host and the privileged operations performed, ensuring to rule out legitimate use. - -### False positive analysis - -- Users accessing systems from new or temporary devices, such as during travel or remote work, may trigger false positives. Regularly update the list of approved devices for users who frequently change their access points. -- IT administrators performing maintenance or updates from different machines can be mistaken for suspicious activity. Implement a process to log and approve such activities in advance to prevent unnecessary alerts. -- Employees using virtual machines or remote desktop services might appear as accessing from uncommon devices. Ensure these environments are recognized and whitelisted if they are part of regular operations. -- Changes in network infrastructure, such as new IP addresses or subnets, can lead to false positives. Keep the machine learning model updated with the latest network configurations to minimize these alerts. -- Temporary use of shared devices in collaborative workspaces can trigger alerts. Establish a protocol for logging shared device usage to differentiate between legitimate and suspicious activities. - -### Response and remediation - -- Immediately isolate the affected device from the network to prevent further unauthorized access or lateral movement. -- Revoke or reset the credentials of the compromised account to prevent further misuse and unauthorized access. -- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or actions. -- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. -- Implement additional monitoring on the affected account and device to detect any further suspicious activities. -- Review and update access controls and permissions to ensure that only authorized devices and users can perform privileged operations. -- Consider implementing multi-factor authentication (MFA) for privileged accounts to enhance security and prevent unauthorized access.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" diff --git a/rules/integrations/pad/privileged_access_ml_windows_rare_group_name_by_user.toml b/rules/integrations/pad/privileged_access_ml_windows_rare_group_name_by_user.toml deleted file mode 100644 index 204de8e5076..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_rare_group_name_by_user.toml +++ /dev/null @@ -1,119 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has detected a user accessing an uncommon group name for privileged operations, indicating potential privileged access activity. -This indicates that a user has accessed a group name that is unusual for their typical operations, particularly for actions requiring elevated privileges. -This could point to an attempt to manipulate group memberships or escalate privileges on a system. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_rare_group_name_by_user" -name = "Unusual Group Name Accessed by a User" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "fb5d91d0-3b94-4f91-bf20-b6fbc4b2480a" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Group Name Accessed by a User - -In IT environments, group names often define access levels and permissions. Adversaries may exploit this by accessing or altering uncommon group names to escalate privileges. The detection rule leverages machine learning to identify deviations from a user's typical access patterns, flagging unusual group name access as a potential indicator of privilege escalation attempts. This proactive approach helps in early detection of unauthorized access activities. - -### Possible investigation steps - -- Review the alert details to identify the specific user and the unusual group name accessed. Note the timestamp of the access for further context. -- Check the user's historical access patterns to determine if this group name access is indeed anomalous compared to their typical behavior. -- Investigate the permissions and roles associated with the unusual group name to assess the potential impact of the access. -- Examine recent changes to the user's account, such as password resets or modifications to account settings, which might indicate account compromise. -- Correlate this event with other security alerts or logs, such as login attempts from unusual locations or times, to identify potential indicators of compromise. -- Contact the user or their manager to verify if the access was legitimate and authorized, documenting any explanations provided. -- If unauthorized access is suspected, initiate a security incident response process to mitigate any potential threats and prevent further unauthorized access. - -### False positive analysis - -- Routine administrative tasks may trigger alerts if administrators access uncommon group names for legitimate system maintenance. To manage this, create exceptions for known administrative accounts performing regular tasks. -- Automated scripts or services that require access to various group names for operational purposes might be flagged. Identify these scripts and whitelist their activities to prevent false positives. -- Temporary project groups or newly created groups for specific tasks can appear unusual. Document and monitor these groups, and update the machine learning model to recognize them as non-threatening. -- Cross-departmental collaborations may involve users accessing group names outside their usual scope. Establish a process to review and approve such access, and adjust the detection rule to accommodate these scenarios. -- Changes in user roles or responsibilities can lead to access pattern deviations. Ensure that role changes are communicated to the security team to update access baselines accordingly. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its password. -- Review and audit the group membership changes associated with the unusual group name to identify any unauthorized modifications. Revert any unauthorized changes to restore the original group settings. -- Conduct a thorough investigation of the user's recent activities to identify any other suspicious actions or access patterns that may indicate further compromise. -- Notify the security team and relevant stakeholders about the potential privilege escalation attempt to ensure awareness and coordinated response efforts. -- Implement additional monitoring on the affected user account and the unusual group name to detect any further unauthorized access attempts. -- Review and update access control policies to ensure that only authorized users have access to sensitive group names and privileged operations. -- Consider implementing additional security measures, such as multi-factor authentication, for accessing sensitive group names to prevent unauthorized access in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1069" -name = "Permission Groups Discovery" -reference = "https://attack.mitre.org/techniques/T1069/" - -[rule.threat.tactic] -id = "TA0007" -name = "Discovery" -reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/integrations/pad/privileged_access_ml_windows_rare_privilege_assigned_to_user.toml b/rules/integrations/pad/privileged_access_ml_windows_rare_privilege_assigned_to_user.toml deleted file mode 100644 index 1c98a8dd459..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_rare_privilege_assigned_to_user.toml +++ /dev/null @@ -1,104 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user leveraging an uncommon privilege type for privileged operations, indicating potential privileged access activity. -This indicates that a user is performing operations requiring elevated privileges but is using a privilege type that is not typically seen in their baseline logs. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_rare_privilege_assigned_to_user" -name = "Unusual Privilege Type assigned to a User" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "27569131-560e-441e-b556-0b9180af3332" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Privilege Type assigned to a User - -In modern IT environments, privilege management is crucial for maintaining security. Adversaries may exploit uncommon privilege types to perform unauthorized actions, bypassing standard detection. The detection rule leverages machine learning to identify deviations from normal privilege usage patterns, flagging potential privilege escalation attempts. By analyzing user behavior against established baselines, it helps detect and mitigate unauthorized access risks. - -### Possible investigation steps - -- Review the user's recent activity logs to identify any unusual or unauthorized actions associated with the uncommon privilege type. -- Cross-reference the identified privilege type with the user's role and responsibilities to determine if the usage is justified or anomalous. -- Check for any recent changes in the user's account settings or privilege assignments that could explain the deviation from the baseline. -- Investigate any recent system or application changes that might have introduced new privilege types or altered existing ones. -- Consult with the user's manager or relevant department to verify if there was a legitimate need for the unusual privilege type usage. -- Analyze the timeline of events leading up to the alert to identify any potential indicators of compromise or privilege escalation attempts. - -### False positive analysis - -- Users with multiple roles may trigger false positives if they occasionally use privileges associated with less common roles. Regularly review and update role-based access controls to ensure they reflect current responsibilities. -- Temporary project assignments can lead to unusual privilege usage. Implement a process to document and approve temporary privilege changes, and exclude these documented cases from triggering alerts. -- System administrators or IT staff might use uncommon privileges during maintenance or troubleshooting. Establish a whitelist for known maintenance activities and exclude these from the detection rule. -- Automated scripts or applications that require elevated privileges might be flagged. Ensure these scripts are registered and their privilege usage is documented, then exclude them from the rule. -- New employees or contractors may initially use privileges that seem unusual. Monitor their activity closely during the onboarding period and adjust baselines as their normal usage patterns become clear. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized access or privilege escalation. This can be done by disabling the account or changing its credentials. -- Review and revoke any unusual or unnecessary privileges assigned to the user account to ensure it aligns with their normal operational requirements. -- Conduct a thorough audit of recent activities performed by the user account to identify any unauthorized actions or data access that may have occurred. -- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts. -- Implement additional monitoring on the affected user account and similar accounts to detect any further suspicious activities or privilege misuse. -- Update and reinforce access control policies to prevent similar privilege escalation attempts, ensuring that privilege assignments are regularly reviewed and validated. -- Document the incident details, response actions taken, and lessons learned to improve future incident response and privilege management processes.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1068" -name = "Exploitation for Privilege Escalation" -reference = "https://attack.mitre.org/techniques/T1068/" - -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_rare_region_name_by_user.toml b/rules/integrations/pad/privileged_access_ml_windows_rare_region_name_by_user.toml deleted file mode 100644 index d48ce24dbc0..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_rare_region_name_by_user.toml +++ /dev/null @@ -1,99 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Windows from an uncommon geographical location, indicating potential privileged access activity. -This could suggest a compromised account, unauthorized access, or an attacker using stolen credentials to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_rare_region_name_by_user" -name = "Unusual Region Name for Windows Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "d2703b82-f92c-4489-a4a7-62aa29a62542" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Region Name for Windows Privileged Operations Detected - -The detection leverages machine learning to identify privileged operations from atypical geographic locations, which may indicate compromised accounts or unauthorized access. Adversaries exploit this by using stolen credentials to perform privilege escalation. The rule flags such anomalies, aiding in early detection of potential security breaches. - -### Possible investigation steps - -- Review the alert details to identify the user account involved and the specific geographic location flagged as unusual. -- Check the user's recent login history and patterns to determine if the location is indeed uncommon for this user. -- Investigate any recent changes to the user's account, such as password resets or modifications to account permissions, that could indicate compromise. -- Correlate the alert with other security events or logs, such as VPN connections or remote access logs, to identify any unauthorized access attempts. -- Contact the user to verify if they were traveling or using a legitimate remote access method from the flagged location. -- Assess the risk by determining if the privileged operations performed align with the user's role and responsibilities within the organization. - -### False positive analysis - -- Users traveling for business or personal reasons may trigger alerts when accessing systems from uncommon locations. To manage this, create exceptions for known travel patterns or use a VPN to simulate access from a common location. -- Remote employees or contractors working from different regions might cause false positives. Regularly update the list of approved remote work locations to prevent unnecessary alerts. -- Use of cloud services or VPNs that route traffic through different geographic locations can lead to false positives. Implement a whitelist for known IP addresses associated with these services. -- Scheduled maintenance or administrative tasks performed by IT staff from different locations can be mistaken for unauthorized access. Document and schedule these activities to avoid triggering alerts. -- Employees using personal devices with location services disabled may appear to be accessing from unusual regions. Encourage the use of company-approved devices with location tracking enabled to ensure accurate detection. - -### Response and remediation - -- Immediately isolate the affected user account to prevent further unauthorized access. Disable the account temporarily until the investigation is complete. -- Review recent login activity and privileged operations performed by the affected account to identify any unauthorized changes or actions. -- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security. -- Conduct a thorough review of the affected system and network for any signs of additional compromise or lateral movement by the attacker. -- Notify the security team and relevant stakeholders about the incident for awareness and further action if needed. -- Restore any unauthorized changes made during the incident from backups or logs, ensuring system integrity is maintained. -- Update security policies and access controls to prevent similar incidents, focusing on restricting privileged operations from uncommon geographic locations.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file diff --git a/rules/integrations/pad/privileged_access_ml_windows_rare_source_ip_by_user.toml b/rules/integrations/pad/privileged_access_ml_windows_rare_source_ip_by_user.toml deleted file mode 100644 index d949acd50f7..00000000000 --- a/rules/integrations/pad/privileged_access_ml_windows_rare_source_ip_by_user.toml +++ /dev/null @@ -1,98 +0,0 @@ -[metadata] -creation_date = "2025/02/18" -integration = ["pad", "endpoint", "windows"] -maturity = "production" -updated_date = "2025/02/18" - -[rule] -anomaly_threshold = 75 -author = ["Elastic"] -description = """ -A machine learning job has identified a user performing privileged operations in Windows from an uncommon source IP, indicating potential privileged access activity. -This could suggest an account compromise, misuse of administrative privileges, or an attacker leveraging a new network location to escalate privileges. -""" -from = "now-1h" -interval = "15m" -license = "Elastic License v2" -machine_learning_job_id = "pad_windows_rare_source_ip_by_user" -name = "Unusual Source IP for Windows Privileged Operations Detected" -references = [ - "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", - "https://docs.elastic.co/en/integrations/pad" -] -risk_score = 21 -rule_id = "08be5599-3719-4bbd-8cbc-7e9cff556881" -setup = """## Setup - -The rule requires the Privileged Access Detection integration assets to be installed, as well as Windows logs collected by integrations such as Elastic Defend and Windows. - -### Privileged Access Detection Setup -The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature. - -#### Prerequisite Requirements: -- Fleet is required for Privileged Access Detection. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). -- Windows events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) and [Windows](https://docs.elastic.co/en/integrations/windows) integration. -- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -- To add the Windows integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide. - -#### The following steps should be executed to install assets associated with the Privileged Access Detection integration: -- Go to the Kibana homepage. Under Management, click Integrations. -- In the query bar, search for Privileged Access Detection and select the integration to see more details about it. -- Follow the instructions under the **Installation** section. -- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**. -""" -severity = "low" -tags = [ - "Use Case: Privileged Access Detection", - "Rule Type: ML", - "Rule Type: Machine Learning", - "Tactic: Privilege Escalation", - "Resources: Investigation Guide" -] -type = "machine_learning" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Source IP for Windows Privileged Operations Detected - -Machine learning models analyze network patterns to identify anomalies, such as privileged operations from uncommon IPs. Adversaries may exploit this by using compromised accounts or new network locations to escalate privileges. This detection rule leverages ML to flag such deviations, indicating potential misuse or compromise, aiding in early threat identification and response. - -### Possible investigation steps - -- Review the source IP address flagged by the alert to determine if it is associated with known or trusted locations, such as corporate offices or VPN endpoints. -- Check the user account involved in the alert for any recent changes or unusual activity, such as password resets, privilege changes, or login attempts from other uncommon locations. -- Analyze the timeline of the privileged operations performed to identify any patterns or sequences that may indicate malicious intent or unauthorized access. -- Correlate the alert with other security events or logs, such as firewall logs, VPN logs, or endpoint security alerts, to gather additional context about the source IP and user activity. -- Investigate any recent changes in network configurations or access policies that might explain the unusual source IP, such as new VPN configurations or changes in IP address allocations. - -### False positive analysis - -- Employees working remotely or traveling may trigger alerts due to accessing systems from new IP addresses. Regularly update the list of known IP addresses for remote workers to reduce false positives. -- Use of VPNs or proxy services can result in unusual IP addresses being flagged. Maintain a whitelist of IP addresses associated with approved VPN or proxy services. -- Scheduled maintenance or administrative tasks performed by IT staff from different network locations might be misidentified. Document and exclude these known activities from triggering alerts. -- Cloud service providers often use dynamic IP ranges that can appear unusual. Identify and whitelist IP ranges associated with trusted cloud services to prevent unnecessary alerts. -- Implement a review process for flagged events to quickly identify and dismiss benign activities, ensuring that only genuine threats are escalated for further investigation. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Verify the legitimacy of the source IP by cross-referencing with known IP addresses and geolocations associated with the user. If the IP is confirmed to be malicious, block it at the firewall and update threat intelligence feeds. -- Reset the credentials of the compromised account and enforce a password change for all accounts with similar access levels to prevent further unauthorized access. -- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or data access, and revert any malicious modifications. -- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised. -- Implement additional monitoring on the affected system and user account to detect any further suspicious activity, leveraging enhanced logging and alerting mechanisms. -- Review and update access controls and privilege management policies to ensure that only necessary privileges are granted, reducing the risk of privilege escalation in the future.""" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1078" -name = "Valid Accounts" -reference = "https://attack.mitre.org/techniques/T1078/" - -[rule.threat.tactic] -id = "TA0004" -name = "Privilege Escalation" -reference = "https://attack.mitre.org/tactics/TA0004/" \ No newline at end of file