My account got beamed and I'm not sure how to get it back

Question

I've logged into a separate account to write this post, as my problem revolves around me not being able to get into my main Microsoft account.

When trying to log in, I get told that the password I'd entered is wrong, and get prompted to reset it in case I forgot it. Standard procedure; i get prompted to type in a code I got on my authenticator app, I unlock my phone to check the app, it doesn't work (this isn't unusual, but not what my problem is right now.)

The other option is to get a password reset code on my email. I open this and, the next step asks me to fill in the first half of the email address (before the @) to prove it belongs to me, and also gives me the first two letters of said email address.

The problem is that I do not recognize said address at all. The latter part of the address says "@get-beamed.lol" which I assume is set up that way to taunt whoever they might successfully hack. (the starting two letters of this @get-beamed.lol email address were 'is' by the way, if that helps)

With no way to get a code sent to the email address I had actually set my account on (and purchased a product with my own money on), I followed the guide on this article: https://account.live.com/acsr?mkt=en-US , and after having filled in as much as I could from the information asked from me, I got told, the email I got back (on a different account I wrote to get contacted via) stated that because I had set up 2-factor-authentification with my account, my submission has been ignored. If the second factor is an email address, I have either never gotten the option to type it in and use it to reset my password, OR the second factor email address in question is the beam one that I do not own anyway. In the case it is meant that the second factor is my authenticator app, like stated above, it doesn't work.

I here write you a question because I don't know how to reach someone on the live support team in regards to resetting it in this specific situation.

Hope to hear from you soon!

Answer 1

Title: Escalation Request: Verified Account Takeover – 2FA Hijacked – Recovery Blocked Despite Evidence

Hello,

I am requesting escalation of a Microsoft account takeover that has resulted in complete loss of access, despite clear evidence of unauthorised activity.

Summary of incident:
My Microsoft account was compromised following a social engineering incident involving a one-time verification code. Immediately after this, the attacker:

• Changed the password
• Added their own authenticator (2FA)
• Replaced the recovery email with: gh***@get-beamed.lol**

I now have no access to any verification methods.

Key issue:
Microsoft has acknowledged unusual or unauthorised access, yet recovery has been denied on the basis that security details have been changed — the very changes made by the attacker.

This creates a situation where:

• The compromise is recognised
• But remediation is not possible
• Leaving the legitimate account holder permanently locked out

Impact:

• Loss of primary email account
• Loss of OneDrive data (personal files and photos)
• Loss of Xbox account (Gamertag: Ghazi2007)
• Disruption to services linked to this identity

Actions taken:

• Multiple recovery attempts (blocked due to attacker-controlled 2FA)
• Contact with Microsoft support (no resolution)
• Formal report submitted to Action Fraud (UK) with crime reference
• Submission of locked account review form

Concern:
The current process appears unable to distinguish between:

• A legitimate user locked out due to malicious changes
• And an attacker controlling verification methods

In particular, the presence of a clearly unauthorised recovery email domain (get-beamed.lol) should reasonably trigger further scrutiny.

Request:
I am asking for:

• Manual review of this case by a specialist team
• Consideration of historical account ownership and usage patterns
• Guidance on any pathway where 2FA changes made under compromise can be reviewed

I fully appreciate the importance of strong security controls. However, in this instance, the process appears to prioritise system rigidity over resolution of a confirmed compromise.

I would be grateful for any meaningful escalation or direction beyond standard automated recovery responses.

Kind regards,
A Ali