Risky event Logging discrepancies

%3CLINGO-SUB%20id%3D%22lingo-sub-285699%22%20slang%3D%22en-US%22%3ERisky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-285699%22%20slang%3D%22en-US%22%3E%3CP%3EI%26nbsp%3Bhad%20an%20external%20attacker%20using%20a%20rotating%20proxy%20to%20attempt%20to%20logon%20to%20multiple%20accounts.%20The%20attacker%20would%20have%20between%2060-100%20logon%20attempts%20to%20each%26nbsp%3Baccount.%20No%20more%20than%20one%20or%20two%20events%20from%20any%20one%20location%20scattered%20across%2040%20or%20so%20countries.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20risky%20log%20showed%20a%20couple%20of%20successful%20sign-ons%20from%20an%20unfamiliar%20place%20for%20users%20who%20were%20scanned.%20While%20the%20sign-on%20log%26nbsp%3Bshowed%20the%20same%20logon%20event%20matched%20on%20time%2C%26nbsp%3Bip%20address%20to%20have%26nbsp%3Bfailed%20as%20the%20account%20was%20disabled%20due%20to%20the%20high%20number%20of%20invalid%20logons%20locking%20the%20account.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20would%20be%20interested%20to%20know%2C%20if%20the%20successful%20logons%20logged%20in%20the%20risky%20report%20occurred%20because%20the%20attacker%20did%20successfully%20guess%20the%20users%20password%20and%20passed%20the%20first%20check%2C%20but%20was%20blocked%20on%20the%20second%20check%20of%20the%20password%20being%20available.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESecondly%20i%20would%20be%20interested%20to%20know%20if%20there%20would%20be%20any%20different%20in%20responses%2C%20response%20times%2C%20etc%20that%20may%20provide%20an%20attacker%20with%20any%20form%20of%20indication%20that%20the%20successful%20response%20was%20different%20from%20the%20failed%20responses.%20As%20i%20worry%20that%20the%20attacker%20was%20smart%20enough%20to%20use%20rotating%20proxies%2C%20perform%20dictionary%20attackes%2C%20etc%2C%20i%20would%20have%20thought%20they%20would%20also%20have%20spaced%20these%20events%20out%20so%20as%20to%20not%20trigger%20account%20lockouts.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-286312%22%20slang%3D%22en-US%22%3ERe%3A%20Risky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-286312%22%20slang%3D%22en-US%22%3E%3CP%3EThank%20you%20for%20your%20response%2C%20Yes%20i%20tend%20to%20go%20on%20the%20side%20of%20caution%2C%20but%20others%20may%20say%20what%20is%20there%20to%20worry%20about%20the%20connection%20did%20not%20happen.%20I%20would%20prefer%20to%20have%20my%20caution%20backed%20up%20by%20facts%20what%20is%20the%20logic%20behind%20getting%20a%20successful%20authentication%20event%20immediately%20followed%20by%20an%20unsuccessful%20authentication%20due%20to%20the%20account%20being%20locked.%20Did%20the%20attacker%20actually%20guess%20the%20users%20password%20in%20their%20dictionary%20attempt.%20If%20so%20maybe%20next%20time%20the%20will%20succeed.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-286307%22%20slang%3D%22en-US%22%3ERe%3A%20Risky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-286307%22%20slang%3D%22en-US%22%3ENo%20much%20information%2C%20unfortunately.%20The%20customer%20told%20us%20that%20the%20mailbox%20never%20existed%20at%20all%2C%20and%20even%20that%20there%20was%20a%20clear%20login%20into%20their%20logs%20from%20overseas.%20No%20other%20activities%2C%20such%20as%20account%20creation%2C%20deletion%2C%20etc.%2C%20only%20a%20successful%20login.%20Not%20sure%20if%20logs%20may%20have%20mixed%20between%20tenancies%20or%20what.%20Microsoft%20is%20still%20trying%20to%20figure%20out%20what%20happened.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-286304%22%20slang%3D%22en-US%22%3ERe%3A%20Risky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-286304%22%20slang%3D%22en-US%22%3E%3CP%3ENow%20that%20is%20a%20worry%2C%20as%20somewhere%20there%20is%20a%20piece%20of%20logic%20that%20allowed%20that%20to%20happen.%20It%20if%20allowed%20it%20to%20happen%20once%20it%20could%20very%20well%20let%20it%20happen%20a%20lot%20more%20often.%20Something%20to%20think%20about.%20was%20there%20anything%20else%20specific%20about%20this%20that%20you%20can%20share%20so%20that%20we%20can%20see%20if%20we%20have%20had%20similar%20events.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-286294%22%20slang%3D%22en-US%22%3ERe%3A%20Risky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-286294%22%20slang%3D%22en-US%22%3E%3CP%3EThat%20it%20is%20interesting%20as%20I%20had%20a%20customer%20which%20logs%20indicates%20a%20login%20from%20overseas%20to%20an%20account%20it%20never%20existed!%20when%20we%20opened%20the%20ticket%20at%20Microsoft%20to%20find%20out%20how%20it%20was%20possible%20to%20have%20a%20successful%20login%20from%20overseas%20to%20an%20account%20it%20does%20not%20exist%20in%20the%20tenancy%20they%20started%20to%20scratch%20their%20head.%3C%2FP%3E%3CP%3EBTW%20we%20still%20have%20the%20ticket%20opened%20and%20they%20are%20trying%20to%20figure%20out%20what%20was%20going%20on%20.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-285750%22%20slang%3D%22en-US%22%3ERe%3A%20Risky%20event%20Logging%20discrepancies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-285750%22%20slang%3D%22en-US%22%3E%3CP%3EAs%20long%20as%20you%20see%20a%20%22success%22%20event%20from%20an%20IP%20you%20don't%20recognize%2C%20consider%20this%20account%20compromised.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

I had an external attacker using a rotating proxy to attempt to logon to multiple accounts. The attacker would have between 60-100 logon attempts to each account. No more than one or two events from any one location scattered across 40 or so countries.

 

The risky log showed a couple of successful sign-ons from an unfamiliar place for users who were scanned. While the sign-on log showed the same logon event matched on time, ip address to have failed as the account was disabled due to the high number of invalid logons locking the account.

 

I would be interested to know, if the successful logons logged in the risky report occurred because the attacker did successfully guess the users password and passed the first check, but was blocked on the second check of the password being available. 

 

Secondly i would be interested to know if there would be any different in responses, response times, etc that may provide an attacker with any form of indication that the successful response was different from the failed responses. As i worry that the attacker was smart enough to use rotating proxies, perform dictionary attackes, etc, i would have thought they would also have spaced these events out so as to not trigger account lockouts.

5 Replies

As long as you see a "success" event from an IP you don't recognize, consider this account compromised.

That it is interesting as I had a customer which logs indicates a login from overseas to an account it never existed! when we opened the ticket at Microsoft to find out how it was possible to have a successful login from overseas to an account it does not exist in the tenancy they started to scratch their head.

BTW we still have the ticket opened and they are trying to figure out what was going on .

Now that is a worry, as somewhere there is a piece of logic that allowed that to happen. It if allowed it to happen once it could very well let it happen a lot more often. Something to think about. was there anything else specific about this that you can share so that we can see if we have had similar events.

No much information, unfortunately. The customer told us that the mailbox never existed at all, and even that there was a clear login into their logs from overseas. No other activities, such as account creation, deletion, etc., only a successful login. Not sure if logs may have mixed between tenancies or what. Microsoft is still trying to figure out what happened.

Thank you for your response, Yes i tend to go on the side of caution, but others may say what is there to worry about the connection did not happen. I would prefer to have my caution backed up by facts what is the logic behind getting a successful authentication event immediately followed by an unsuccessful authentication due to the account being locked. Did the attacker actually guess the users password in their dictionary attempt. If so maybe next time the will succeed.