SOLVED

Users with leaked credentials

%3CLINGO-SUB%20id%3D%22lingo-sub-105112%22%20slang%3D%22en-US%22%3EUsers%20with%20leaked%20credentials%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105112%22%20slang%3D%22en-US%22%3E%3CP%3ECan%20anyone%20tell%20me%20the%20logic%20used%20in%20this%20report%3F%20We%20have%20a%20situation%20where%20I%20need%20to%20prove%20one%20of%20our%20users%20performed%20a%20certain%20action%20as%20listed%20in%20our%20365%20audit%20logs.%20An%20obvious%20argument%20is%20that%20if%20their%20account%20was%20compromised%2C%20it%20may%20have%20been%20done%20by%20a%20third%20party%20using%20their%20credentials.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETheir%20account%20does%20not%20appear%20in%20this%20report%2C%20so%20my%20question%20is%20-%20How%20much%20stock%20can%20I%20put%20in%20the%20fact%20that%20they%20do%20not%20appear%20in%20this%20report%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-313716%22%20slang%3D%22en-US%22%3ERe%3A%20Users%20with%20leaked%20credentials%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-313716%22%20slang%3D%22en-US%22%3E%3CP%3EIn%20this%20statement%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3E%22When%20the%20service%20acquires%20username%20%2F%20%3CSTRONG%3Epassword%20pairs%2C%20they%20are%20checked%20against%20AAD%20users'%20current%20valid%20credentials.%3C%2FSTRONG%3E%20When%20a%20%3CSTRONG%3Ematch%3C%2FSTRONG%3E%20is%20found%2C%20it%20means%20that%20a%20user's%20password%20has%20been%20compromised%2C%20and%20a%20leaked%20credentials%20risk%20event%20is%20created.%22%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EDoes%20this%20mean%20that%20they%20are%20actually%20comparing%20passwords%20%2F%20hashes%20of%20those%20found%20with%20those%20in%20an%20organisations%20AD%2C%20or%20are%20they%20just%20matching%20the%20username%20with%20ones%20found%20on%20lists%2C%20and%20from%20that%20deciding%20the%20creds%20are%20blown%3F%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EIf%20they%20are%20accessing%20an%20organisations%20Azure%20password%20hashes%20that%20sounds%20bad.%26nbsp%3B%20If%20they%20are%20not%20then%20it%20sounds%20like%20a%20pretty%20basic%20service%3F%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-105172%22%20slang%3D%22en-US%22%3ERe%3A%20Users%20with%20leaked%20credentials%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105172%22%20slang%3D%22en-US%22%3E%3CP%3ENot%20sure%20it%20will%20help%20but%20here%20is%20the%20official%20explanation%20of%20leaked%20credentials%20and%20how%20Microsoft%20matches%20one%20of%20these%20users%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%22When%20cybercriminals%20compromise%20valid%20passwords%20of%20legitimate%20users%2C%20the%20criminals%20often%20share%20those%20credentials.%20This%20is%20usually%20done%20by%20posting%20them%20publicly%20on%20the%20dark%20web%20or%20paste%20sites%20or%20by%20trading%20or%20selling%20the%20credentials%20on%20the%20black%20market.%20The%20Microsoft%20leaked%20credentials%20service%20acquires%20username%20%2F%20password%20pairs%20by%20monitoring%20public%20and%20dark%20web%20sites%20and%20by%20working%20with%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CUL%3E%3CLI%3EResearchers%3C%2FLI%3E%3CLI%3ELaw%20enforcement%3C%2FLI%3E%3CLI%3ESecurity%20teams%20at%20Microsoft%3C%2FLI%3E%3CLI%3EOther%20trusted%20sources%3C%2FLI%3E%3C%2FUL%3E%3CP%3EWhen%20the%20service%20acquires%20username%20%2F%20password%20pairs%2C%20they%20are%20checked%20against%20AAD%20users'%20current%20valid%20credentials.%20When%20a%20match%20is%20found%2C%20it%20means%20that%20a%20user's%20password%20has%20been%20compromised%2C%20and%20a%20leaked%20credentials%20risk%20event%20is%20created.%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20from%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Factive-directory-reporting-risk-events%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehere%3C%2FA%3E%26nbsp%3Bby%20the%20way.%26nbsp%3B%20This%20isn't%20foolproof%2C%20it's%20just%20what%20Microsoft%20can%20acquire%20and%20potentially%20match.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

Can anyone tell me the logic used in this report? We have a situation where I need to prove one of our users performed a certain action as listed in our 365 audit logs. An obvious argument is that if their account was compromised, it may have been done by a third party using their credentials.

 

Their account does not appear in this report, so my question is - How much stock can I put in the fact that they do not appear in this report?

2 Replies
best response confirmed by Peter Nicholson (Occasional Contributor)
Solution

Not sure it will help but here is the official explanation of leaked credentials and how Microsoft matches one of these users:

 

"When cybercriminals compromise valid passwords of legitimate users, the criminals often share those credentials. This is usually done by posting them publicly on the dark web or paste sites or by trading or selling the credentials on the black market. The Microsoft leaked credentials service acquires username / password pairs by monitoring public and dark web sites and by working with:

 

  • Researchers
  • Law enforcement
  • Security teams at Microsoft
  • Other trusted sources

When the service acquires username / password pairs, they are checked against AAD users' current valid credentials. When a match is found, it means that a user's password has been compromised, and a leaked credentials risk event is created."

 

This is from here by the way.  This isn't foolproof, it's just what Microsoft can acquire and potentially match.

In this statement

 

"When the service acquires username / password pairs, they are checked against AAD users' current valid credentials. When a match is found, it means that a user's password has been compromised, and a leaked credentials risk event is created."

 

Does this mean that they are actually comparing passwords / hashes of those found with those in an organisations AD, or are they just matching the username with ones found on lists, and from that deciding the creds are blown?

 

If they are accessing an organisations Azure password hashes that sounds bad.  If they are not then it sounds like a pretty basic service?