వ్యాసం వివరించే token replay ఇలస్ట్రేషన్: MFA తో ఆమోదించిన సైన్-ఇన్, దాని తర్వాత వచ్చే session token, Huntress నివేదించినట్లు సుమారు 10 వారాల పాటు దాడిచేసేవారు ఆ token ను మళ్లీ వాడటం. ఇది భావనాత్మకమైనది, నిజమైన లాగ్ లేదా స్క్రీన్‌షాట్ కాదు.
MFA ఇప్పటికే దాటిన సెషన్‌లను దాడిచేసినవారు దొంగిలించి, అద్దె సర్వర్‌ల నుంచి మళ్లీ వాడి, ఆ తర్వాత బాధితుల MFA పద్ధతులను మార్చేశారు. ఇది ఎలా పనిచేస్తుందో, ఏమి తనిఖీ చేయాలో ఇక్కడ ఉంది.
MFA ఇప్పటికే దాటిన సెషన్‌కు మళ్లీ MFA అవసరం లేదు
multifactor authentication ఇప్పుడే ఆమోదించిన సెషన్‌ను దాడిచేసేవారు దొంగిలిస్తే, MFA తనిఖీ చేయడానికి ఇక ఏమీ మిగలదు.
Microsoft 365 ఖాతాలపై జరిగిన ఒక ప్రచారం గురించి సెక్యూరిటీ సంస్థ Huntress ఇచ్చిన నివేదిక ఇదే వివరిస్తుంది. 14 July నుంచి 22 September 2026 మధ్య, తన కస్టమర్ల వాతావరణాల్లో 200,000 కంటే ఎక్కువ విఫలమైన సైన్-ఇన్ ప్రయత్నాలను, కనీసం 497 విజయవంతమైన వాటిని అది చూసింది. ఈ కార్యకలాపం 79 సంస్థలను తాకింది.
ఈ వ్యాసం Microsoft 365 ను నడిపే లేదా దానికి మద్దతిచ్చే వారి కోసం: అడ్మినిస్ట్రేటర్లు, సెక్యూరిటీ సిబ్బంది, IT మేనేజర్లు. token అంటే ఏమిటో, దాడిచేసేవారు వాటిని ఎలా తీసుకున్నారో, తర్వాత ఏమి చేశారో, ఏ Microsoft నియంత్రణలు సహాయపడతాయో ఇది వివరిస్తుంది. ఆ నియంత్రణలు ఎక్కడ ఆగిపోతాయో కూడా చెబుతుంది, ఎందుకంటే ఆ భాగాన్ని గమనించకపోవడం సులభం.
token అంటే ఏమిటి, replay అంటే ఏమిటి
మీరు Microsoft 365 లో సైన్ ఇన్ చేసినప్పుడు, పాస్‌వర్డ్‌తో, రెండో factor తో మీరు ఎవరో నిరూపిస్తారు. తర్వాత Microsoft మీ డివైస్‌కు ఒక token ఇస్తుంది, అది “ఈ యూజర్‌ను ఇప్పటికే తనిఖీ చేశారు” అని చెప్పే చిన్న డిజిటల్ పాస్. ప్రతి క్లిక్‌కూ సైన్ ఇన్ చేయాల్సిన అవసరం లేకుండా, మీ యాప్‌లు ఆ పాస్‌ను Exchange, SharePoint, Teams కు చూపిస్తాయి.
token replay అంటే వేరొకరి పాస్‌ను వాడటం. దాడిచేసే వ్యక్తి చెల్లుబాటయ్యే token ను కాపీ చేసి మరో మెషీన్ నుంచి చూపిస్తే, సర్వీస్‌కు నిజమైనదిగా కనిపించే పాస్ కనిపిస్తుంది. పాస్‌వర్డ్‌ను, రెండో factor ను ఇంతకు ముందే తనిఖీ చేశారు కాబట్టి, వాటిని మళ్లీ అడగరు.
అందుకే ఈ దాడిని గుర్తించడం కష్టం. ఏదీ ఊహించి ప్రయత్నించలేదు, విజయవంతమైన సైన్-ఇన్‌లలో ఏదీ విఫలం కాలేదు. పాస్‌ను కేవలం తప్పు వ్యక్తి వాడాడు.
Huntress ఏమి గమనించింది
ప్రచారం సుమారు పది వారాలు నడిచిందని Huntress చెబుతుంది. పైన ఇచ్చిన సంఖ్యలతో పాటు, బాధితుల Entra డైరెక్టరీలలో నమోదైన 48 నకిలీ డివైస్‌లను అది కనుగొంది. కనీసం 19 సంస్థల్లో, బాధితుల ప్రస్తుత MFA పద్ధతులు తొలగించబడి, మొదటి సైన్-ఇన్ నుంచి మూడు గంటల్లోపు కొత్తవి చేర్చబడ్డాయి.
దాడిచేసేవారు రెండు అంచెల్లో పనిచేశారు. ఒక సెట్ సర్వర్‌లు బాధితుల నుంచి సెషన్‌లను పట్టుకున్నాయి. ఒక జర్మన్ హోస్టింగ్ ప్రొవైడర్ అడ్రస్ పరిధిలోని వేరే అద్దె సర్వర్‌ల సెట్ ఆ సెషన్‌లను మళ్లీ వాడింది. replay దశను, password spraying తో పోలిక చేస్తూ, Huntress token spraying అంటుంది.
ఆ రెండు అంచెలు వేరువేరు కాబట్టి, ఒకదాన్ని ఆపితే రెండోది ఆగదు.
వేగం ముఖ్యమైంది. 21 July న MFA ప్రాంప్ట్‌కు, హైజాక్ అయిన సెషన్‌కు మధ్య 12 నిమిషాలను, 22 September న నాలుగు నిమిషాలను Huntress కొలిచింది. ఈ ఫలితాలను 26 October న నివేదించిన The Hacker News ఏ threat actor పేరునూ చెప్పలేదు, Huntress కూడా చెప్పలేదు. వేరే చోట కనిపించే ఏ ఆపాదననైనా నిర్ధారితం కానిదిగా పరిగణించండి.
సంఖ్యల గురించి ఒక గమనిక: అవి Huntress కస్టమర్ల వాతావరణాల నుంచి మాత్రమే వచ్చాయి. అసలు స్థాయి కనీసం ఇంత, బహుశా ఇంకా ఎక్కువ. ఒకే September విస్ఫోటనానికి Huntress పేజీ రెండు వేర్వేరు సంఖ్యలను కూడా ఇస్తుంది, కాబట్టి మేము వాటిలో దేన్నీ ఉటంకించం.
దాడిచేసేవారు token లను ఎలా పొందారు
Huntress, The Hacker News మూడు మార్గాలను వివరిస్తాయి.
మొదటిది adversary-in-the-middle phishing, సంక్షిప్తంగా AiTM. బాధితుడు తనకూ, అసలు Microsoft పేజీకీ మధ్యలో ఉండే నకిలీ సైన్-ఇన్ పేజీకి చేరతాడు. అది వారి పాస్‌వర్డ్‌ను, MFA కోడ్‌ను Microsoft కు చేరవేసి, తిరిగి వచ్చే token ను ఉంచుకుంటుంది.
బాధితుడికి సాధారణ సైన్-ఇన్ కనిపిస్తుంది. దాడిచేసే వ్యక్తి చేతిలో పనిచేసే సెషన్ ఉంటుంది.
రెండోది device code phishing. TV లేదా command-line టూల్ వంటి కొన్ని డివైస్‌లు పూర్తి సైన్-ఇన్ పేజీని చూపలేవు, కాబట్టి Microsoft వాటిని ఒక చిన్న కోడ్ చూపించి, యూజర్ దాన్ని మరో డివైస్‌లో ఎంటర్ చేసేలా సైన్ ఇన్ చేయనిస్తుంది. దాడిచేసే వ్యక్తి ఆ ప్రక్రియను మొదలుపెట్టి, నమ్మదగిన కథతో బాధితుడికి కోడ్ పంపి, బాధితుడు ఆమోదించినప్పుడు token ను అందుకోగలడు.
మూడోది చట్టబద్ధమైన సైన్-ఇన్ సమయంలో జరిగే సాధారణ social engineering. నివేదికలు దీని గురించి తక్కువ వివరాలు ఇస్తాయి, కాబట్టి ఆచరణలో అది ఎలా పనిచేసిందో మాకు తెలియదు.
దాడిచేసేవారు లోపలికి వచ్చాక ఏమి చేశారు
మొదటి replay తర్వాత ఒక స్థిరమైన నమూనాను Huntress కనుగొంది. దాడిచేసేవారు తమ సొంత authenticator యాప్‌ను చేర్చారు, లేదా బాధితుడి MFA పద్ధతులను తుడిచేసి కొత్తదాన్ని నమోదు చేశారు. 21 July న జరిగిన ఒక సందర్భంలో, దాడిచేసేవారు చేర్చిన “iPhone 13” అనే పద్ధతి, రిలే సెషన్‌ను పట్టుకున్న సుమారు 50 నిమిషాల తర్వాత క్రియాశీలమైంది.
వారు Entra లో నకిలీ డివైస్‌లను కూడా నమోదు చేశారు, అవి ఎవరైనా తొలగించే వరకు డైరెక్టరీలో ఉంటాయి. ఒకే చుక్క లేదా “sss” వంటి పేర్లతో దాచిన ఇన్‌బాక్స్ రూల్స్ సృష్టించి, payroll, డిపాజిట్లు, బోనస్‌ల గురించిన మెయిల్‌ను తరలించారు లేదా తొలగించారు. ఒక సంఘటనలో దాడిచేసే వ్యక్తి payroll గురించి బయటి అకౌంటెంట్‌కు ఈమెయిల్ చేసి, సమాధానాలను దాచిపెట్టాడు, ఇది business email compromise నమూనా. మరొకదానిలో, Entra ID Protection ఖాతాను అధిక ప్రమాదంగా గుర్తించే వరకు, ఒక మెయిల్‌బాక్స్‌ను వందలాది బయటి గ్రహీతలకు స్పామ్ పంపడానికి వాడారు.
ప్రతి దశ చొరబాటుదారును తొలగించడం కష్టతరం చేస్తుంది. కొత్త MFA పద్ధతి అంటే దాడిచేసేవారు తర్వాత మళ్లీ సైన్ ఇన్ చేయగలరు. నకిలీ డివైస్ కూడా అదే చేస్తుంది. దాచిన రూల్ బాధితుడికి సమాధానాలు కనిపించకుండా చేస్తుంది.
MFA ఒక్కటే ఎందుకు సరిపోలేదు
MFA సైన్-ఇన్ క్షణాన్ని కాపాడుతుంది. AiTM దాడిలో ఆ పనిని బాధితుడే దాడిచేసేవారి కోసం చేస్తాడు. నిజమైన కోడ్ దాడిచేసేవారి రిలే ద్వారా నిజమైన Microsoft సర్వీస్‌కు వెళ్తుంది, ఫలితాన్ని దాడిచేసేవారు ఉంచుకుంటారు.
కొన్ని MFA పద్ధతులు ఇతరాల కంటే బాగా తట్టుకుంటాయి. authentication strengths పై Microsoft డాక్యుమెంటేషన్ Windows Hello for Business, FIDO2 security keys, certificate-based authentication ను “phishing-resistant” సమూహంలో ఉంచుతుంది. ఈ పద్ధతులను, పద్ధతికి, సైన్-ఇన్ ఉపరితలానికి మధ్య పరస్పర చర్య అవసరమయ్యేవిగా అది నిర్వచిస్తుంది. Microsoft Authenticator phone sign-in ఒక passwordless పద్ధతి కానీ ఆ సమూహంలో లేదు, కోడ్‌లు, push ఆమోదాలు ఆ రెండిటిలో దేనిలోనూ లేవు.
ఆ నిర్వచనంపై మా అవగాహన ఏమిటంటే, నిజమైన సైన్-ఇన్ ఉపరితలం కాని రిలే పేజీకి ఈ పద్ధతులను పూర్తి చేయడం చాలా కష్టం. అది మా ఊహ, AiTM గురించి Microsoft ప్రకటన కాదు, ఎందుకంటే Microsoft పేజీ AiTM ను అసలు ప్రస్తావించదు. Huntress బాధితులు ఏ MFA పద్ధతులు వాడుతున్నారో కూడా మాకు తెలియదు, కాబట్టి phishing-resistant పద్ధతులు ఈ ప్రచారాన్ని ఆపేవో లేదో చెప్పలేము.
Microsoft నియంత్రణలు ఏమి కవర్ చేస్తాయి, ఎక్కడ ఆగుతాయి
token దొంగతనానికి వ్యతిరేకంగా అనేక నియంత్రణలు సహాయపడతాయి. వాటిలో ఏదీ ఒక్కటే సంపూర్ణ సమాధానం కాదు. Microsoft ప్రస్తుత డాక్యుమెంటేషన్ ప్రకారం ప్రతిదీ ఏమి చేస్తుందో, ముఖ్యమైన పరిమితి ఏమిటో ఈ పట్టిక చూపిస్తుంది.
| నియంత్రణ | ఇది ఏమి చేస్తుంది | తెలుసుకోవాల్సిన పరిమితి |
|---|---|---|
| Phishing-resistant authentication strengths | ఎంచుకున్న సైన్-ఇన్‌లకు FIDO2 keys, Windows Hello for Business లేదా certificate-based authentication ను తప్పనిసరి చేస్తుంది. | Conditional Access మొదటి authentication దశ తర్వాత మూల్యాంకనం అవుతుంది, కాబట్టి ఆ అవసరం వర్తించే ముందు యూజర్ ఇంకా పాస్‌వర్డ్ టైప్ చేయవచ్చు. |
| Token protection | సైన్-ఇన్ సెషన్ token లను డివైస్‌కు కట్టేస్తుంది, కాబట్టి దొంగిలించిన token మరో డివైస్ నుంచి పనిచేయకూడదు. replay ను “తగ్గించడానికి ప్రయత్నిస్తుంది” అని Microsoft చెబుతుంది. | మద్దతున్న ప్లాట్‌ఫాంలలో Exchange Online, SharePoint Online, Teams వంటి ఎంపిక చేసిన native యాప్‌లను కవర్ చేస్తుంది. బ్రౌజర్ మద్దతు preview లో ఉంది, Azure Resource Manager ను చేరే ఎంపిక చేసిన వెబ్ యాప్‌లకు పరిమితం. ప్రతి ప్లాట్‌ఫాం ప్రస్తుత స్థితి కోసం పేజీని చూడండి. |
| Continuous access evaluation | password reset, నిలిపివేసిన ఖాతా, రద్దు చేసిన సెషన్ లేదా అధిక యూజర్ ప్రమాదం వంటి సంఘటనల తర్వాత, గడువు ముగిసేలోపే Exchange, SharePoint, Teams token ను తిరస్కరించేలా చేస్తుంది. | మద్దతున్న యాప్‌లతో మాత్రమే పనిచేస్తుంది. లొకేషన్ తనిఖీలు IP ఆధారిత named locations ను మాత్రమే కవర్ చేస్తాయి. సంఘటన ఆలస్యాలు 15 నిమిషాల వరకు ఉండవచ్చని Microsoft పేర్కొంటుంది. |
| Block device code flow | ఇది అవసరం లేని యూజర్ల కోసం device code సైన్-ఇన్ మార్గాన్ని నిరోధించే Conditional Access విధానం. | ముందుగా ప్రస్తుత వాడకాన్ని ఆడిట్ చేయాలని Microsoft సిఫార్సు చేస్తుంది, మీరు మినహాయించిన ఖాతాలు ఆ విధానాన్ని దాటవేస్తాయి. Service principals ను యూజర్ విధానాలు కవర్ చేయవు. |
Microsoft పేజీ ప్రకారం, Outlook on the web లేదా SharePoint కు బ్రౌజర్ ఆధారిత సెషన్‌లు token protection జాబితాలో లేవు. ఇది AiTM దాడులకు ఒక ఖాళీ అని మా ఊహ, ఎందుకంటే అవి సాధారణంగా బ్రౌజర్ సెషన్‌లను పట్టుకుంటాయి. Microsoft పేజీ అలా చెప్పదు, కాబట్టి దీన్ని వాస్తవంగా కాకుండా, మీ సొంత tenant లో పరీక్షించాల్సిన విషయంగా పరిగణించండి.
అన్ని యూజర్లకు, అన్ని cloud apps కు, అన్ని client app రకాలకు బేషరతుగా MFA ను తప్పనిసరి చేసే లేదా యాక్సెస్‌ను నిరోధించే Conditional Access విధానాలను కూడా Huntress సిఫార్సు చేస్తుంది. అది విక్రేత సలహా, బేస్‌లైన్‌గా అర్థవంతమే. అది పై నియంత్రణలకు ప్రత్యామ్నాయం కాదు.
దొంగిలించిన సెషన్‌పై అనుమానం ఉంటే ఏమి చేయాలి
ఒక విషయంలో Huntress స్పష్టంగా ఉంది. password reset ఒక్కటే సరిపోదు. దాడిచేసేవారి MFA పద్ధతులు, నకిలీ డివైస్‌లు అలాగే ఉంటాయి, access token గడువు ముగిసే వరకు పనిచేస్తూ ఉండవచ్చు, అది సుమారు 90 నిమిషాలని Huntress చెబుతుంది (Microsoft డిఫాల్ట్ 60 నుంచి 90 నిమిషాలు). ఈ దశలను క్రమంలో పూర్తి చేయండి.
- యూజర్ సెషన్‌లను రద్దు చేయండి, ఆ తర్వాత పాస్‌వర్డ్ రీసెట్ చేయండి. ప్రచారంలో, పాస్‌వర్డ్ మార్పు వంటి కారణాలతో ఇకపై చెల్లుబాటు కాని సెషన్‌లను మళ్లీ వాడటానికి దాడిచేసేవారు చేసిన తర్వాతి ప్రయత్నాలు Microsoft యొక్క “SsoArtifactRevoked” ఎర్రర్ (AADSTS50133) తో విఫలమయ్యాయి.
- యూజర్ MFA పద్ధతులను సమీక్షించండి. సైన్-ఇన్ తర్వాత త్వరగా, ముఖ్యంగా కొన్ని గంటల్లోపు, చేర్చిన లేదా తుడిచిన పద్ధతులను చూడండి.
- Entra లో నమోదైన డివైస్‌లను ఆడిట్ చేయండి. ఒక డివైస్‌ను తొలగించే ముందు అది చట్టబద్ధం కాదని నిర్ధారించుకోండి. నకిలీ వాటి పేర్లు “DESKTOP-” తో మొదలై ఎనిమిది hex అక్షరాలు ఉన్నాయని Huntress గమనించింది, ఇది Windows డిఫాల్ట్‌కు భిన్నం, అలాగే ఎనిమిది hex అక్షరాలతో కూడిన “Device-“, “Work Pc” ఉపసర్గలను కూడా అది జాబితా చేస్తుంది.
- ఇన్‌బాక్స్ రూల్స్‌ను, కొత్త enterprise applications ను తనిఖీ చేయండి. చిన్న లేదా విరామచిహ్న-మాత్రమే పేర్లు, payroll లేదా బ్యాంకింగ్ సందేశాలను తాకే రూల్స్ దగ్గరి పరిశీలనకు అర్హమైనవి.
- బయటి ప్రభావం కోసం చూడండి. బయటి పక్షాలకు పంపిన మెయిల్‌ను, ఆమోదించిన లేదా మార్చిన చెల్లింపు వివరాలను తనిఖీ చేయండి.
threat hunting కోసం, Huntress తాను చూసిన ఖచ్చితమైన సైన్-ఇన్ నమూనాలను, client ID లను, అడ్రస్‌లను జాబితా చేస్తుంది. వాటి కోసం దాని నివేదికను వాడండి, ఎందుకంటే అవి త్వరగా మారతాయి, సాధారణ పాఠకుల కంటే hunt టీమ్‌లకు ఎక్కువ ఉపయోగకరం.
మనకు ఏమి తెలుసు, ఏమి తెలియదు
| లేబుల్ | ప్రకటన |
|---|---|
| వాస్తవం | 14 July నుంచి 22 September 2026 వరకు కార్యకలాపాన్ని, తన కస్టమర్లలో కనీసం 497 విజయవంతమైన సైన్-ఇన్‌లను, 48 నకిలీ Entra డివైస్‌లను Huntress నివేదిస్తుంది. |
| పరిశోధకుల నివేదిక | token లను పొందడానికి దాడిచేసేవారు AiTM రిలేలను, device code phishing ను, social engineering ను వాడి, వాటిని అద్దె సర్వర్‌ల నుంచి మళ్లీ వాడారు. |
| పరిశోధకుల నివేదిక | కనీసం 19 సంస్థల్లో, మొదటి సైన్-ఇన్ నుంచి మూడు గంటల్లోపు MFA పద్ధతులు మార్చబడ్డాయి. |
| మా ఊహ | Phishing-resistant పద్ధతులు, డివైస్‌కు కట్టిన token లు ఈ దాడి ఖర్చును పెంచుతాయి. token protection ఉన్నా బ్రౌజర్ సెషన్‌లు AiTM కు గురయ్యే అవకాశం ఉండవచ్చు. |
| తెలియదు | ప్రచారాన్ని ఎవరు నడిపారు. ఏ బాధితుడైనా phishing-resistant MFA వాడారా. Huntress పరిధి వెలుపల ఎన్ని సంస్థలు ప్రభావితమయ్యాయి. ప్రచారంపై Microsoft సొంత అంచనా. |
దీన్ని ఎంత లోతుగా నేర్చుకోవాలి?
తెలుసుకోండి: ప్రతి Microsoft 365 యూజర్, మేనేజర్ ఒక ఆలోచనను అర్థం చేసుకోవాలి. MFA సైన్-ఇన్‌ను కాపాడుతుంది, దాని తర్వాత వచ్చే సెషన్‌ను కాదు. మీరు స్వయంగా తెరవని పేజీలో కోడ్ ఎంటర్ చేయమని ఒక సందేశం అడిగితే, ఆగి నివేదించండి.
వాడండి: అడ్మినిస్ట్రేటర్లు, హెల్ప్ డెస్క్ సిబ్బంది సెషన్‌లను రద్దు చేయగలగాలి, MFA పద్ధతులను, నమోదైన డివైస్‌లను సమీక్షించగలగాలి, దాచిన ఇన్‌బాక్స్ రూల్స్‌ను కనుగొనగలగాలి, Conditional Access విధానాన్ని చదవగలగాలి. password reset ఒక్కటే పూర్తి ప్రతిస్పందన ఎందుకు కాదో మీకు తెలియాలి.
నైపుణ్యం సాధించండి: సెక్యూరిటీ ఆర్కిటెక్ట్‌లు, ఐడెంటిటీ యజమానులు token దొంగతనానికి అనుగుణంగా డిజైన్ చేయాలి. అంటే authentication strengths ఎంచుకోవడం, ముందు report-only పరీక్షతో token protection ను అమలు చేయడం, device code flow ఎవరికి నిజంగా అవసరమో నిర్ణయించడం, సైన్-ఇన్ లాగ్‌లను చొరబాటుదారు మార్చలేని చోటికి పంపడం.
ప్రస్తుతానికి మీరు పట్టించుకోనవసరం లేనివి
Huntress నివేదికలోని IP అడ్రస్‌లను, user agents ను, client ID లను మీరు గుర్తుంచుకోనవసరం లేదు. అవి hunter ల కోసం సూచికలు, పాతబడిపోతాయి. నిలిచేది నమూనా: సాధారణ సైన్-ఇన్, ఆ తర్వాత త్వరలో MFA మార్పు, ఒక కొత్త డివైస్, ఒక దాచిన మెయిల్ రూల్.
ఒక ఆచరణాత్మక తదుపరి అడుగు
మీ సైన్-ఇన్ లాగ్‌లను తెరిచి, తెలియని ప్రదేశం నుంచి సైన్-ఇన్ చేసిన కొన్ని గంటల్లోపు కొత్త MFA పద్ధతిని నమోదు చేసిన ఖాతా ఏదైనా ఉందేమో చూడండి. ఆ తర్వాత మీ tenant device code flow ను అనుమతిస్తుందో లేదో తనిఖీ చేయండి. అది మీకు ఎప్పుడూ అవసరం కాకపోతే, ముందు report-only మోడ్‌లో నిరోధక విధానాన్ని సృష్టించి, ఫలితాలను చదివాక దాన్ని ఆన్ చేయండి.
మరింత లోతుగా
నివేదికలు, కవరేజ్
- Token spray and replay in Microsoft 365, Huntress, Andrea Hatcher, Susannah Matt, Matt Poto and Andrew Schwartz, October 22, 2026, పూర్తి కాలక్రమం, టూలింగ్, సూచికలు.
- The Hacker News on the Huntress findings, The Hacker News, Ravie Lakshmanan, October 26, 2026, ఒక చిన్న సారాంశం.
Microsoft డాక్యుమెంటేషన్
- Token protection in Conditional Access, Microsoft Learn, మద్దతున్న ప్లాట్‌ఫాంలు, అమలు దశలు.
- Continuous access evaluation, Microsoft Learn, సంఘటనలు, జీవితకాలాలు, పరిమితులు.
- Block device code flow, Microsoft Learn, విధాన దశలు.
- Authentication strengths, Microsoft Learn, phishing-resistant సమూహం.
ఈ వ్యాసంలోని వాస్తవాలను 26 October 2026 నాడు తనిఖీ చేశారు. Microsoft ఫీచర్లు, Huntress నివేదిక మారవచ్చు, కాబట్టి చర్య తీసుకునే ముందు పై మూలాలతో నిర్ధారించుకోండి.
ఈ వ్యాసం Huntress, Microsoft చెప్పేవాటిని మా ఊహ నుంచి వేరు చేస్తుంది.
TechiesJournalలో సంబంధిత రచనలు
- Phishing Attacks, TechiesJournal, ప్రాథమికాలు.
- విశ్వసనీయ క్లౌడ్ అప్లికేషన్ దాడి మార్గంగా మారినప్పుడు, TechiesJournal, Microsoft 365 కు సంబంధించిన భిన్నమైన ఐడెంటిటీ ప్రమాదం.