How Skype Fixes Vulnerabilities

Short answer: they don't, they don't care. A detailed account of multiple Skype security vulnerabilities that Microsoft refused to fix for years, including mass-report account blocking, weak security codes, and social engineering via support chat.

Short answer: they don't, they don't care.

This article describes my unsuccessful attempts to convince Microsoft employees that their service contains security vulnerabilities, along with the humiliations that Skype users must endure.

TL;DR

  • Anyone can permanently block your account knowing only the account name; Skype usually refuses recovery. Microsoft has known about this for years.
  • The 8-digit Microsoft Security Code mechanism for password recovery is vulnerable; attackers can guess the code.
  • Skype tech support is vulnerable to social engineering attacks, which Microsoft considers normal.
  • Support staff don't understand what actually happens to accounts or why they're blocked.
  • Skype continues revealing IP addresses, including local ones, and potentially exposing family members on the same router.
  • Attackers can hide active sessions using old SDK versions to secretly read victims' messages.

About the Author

I have used Skype for approximately ten years, previously considered myself a Skype fan, actively reported bugs when the public bug tracker (jira.skype.com) was available, documented vulnerabilities like SCW-2778 and SCW-3328, used all Skype products and development tools, purchased premium subscriptions. And now I genuinely hate Skype.

Chronology of Events

Method 1 — Mass Reports (Classical)

Skype automatically blocks accounts after receiving a sufficient number of complaints (reportedly over 20). There is no need to add the account to contacts — users can report via the search and block function. Victims remain completely unaware. This technique has existed for years; VKontakte groups organize coordinated abuse campaigns.

"Boosters" (account blockers) aged 12-19 form clans that engage in verbal duels during group calls, attempting maximum humiliation while recording video.

Some clans release software automating malicious activities. One program demonstrates mass complaint distribution working like a botnet using contact lists.

Standard support response: "Our automatic systems detected activities contrary to Skype Terms and Conditions. Your account has been restricted and will remain restricted."

Method 2 — Tech Support Blocking

In autumn 2015, victims received letters from Microsoft with 8-digit codes from verifyme@microsoft.com with correct DKIM signatures. Investigation revealed the attacker's contact information (ICQ, Skype, Jabber). I ordered account deletion from this service.

Test account conditions:

  • Registered with a fresh email unconnected to the account
  • Complex password, strong cryptography
  • Only trusted contacts added
  • No conference participation, minimal messaging/calls

Within 10 hours of payment, 24 code letters arrived. The attacker eventually guessed the correct code.

The deletion procedure through Live Chat Support (sales.liveperson.net) involved:

  1. Attacker requests: "Delete my account [name] because I created another"
  2. Operator requests a verification code sent to the account email (the operator doesn't mention the email address)
  3. Upon receiving the correct code, account deletion proceeds; the operator allows multiple code attempts

The chat form transmitted the username of the account logged into skype.com, yet operators accepted deletion requests for completely different accounts.

Communication with Microsoft

I posted on Skype community forums — no official response, though other victims appeared. Through contacts, I reached Microsoft employees, providing detailed vulnerability descriptions with screenshots and code listings. They confirmed an internal investigation.

A month later, new attack victims contacted me; Microsoft reported the investigation was continuing.

Writing to secure@microsoft.com (which has a 24-hour response guarantee for critical vulnerabilities) with detailed deletion steps, I received a response that essentially said: "This isn't a vulnerability, you're simply foolish."

Weekly inquiries about investigation progress returned only "no results" for approximately SIX MONTHS.

The attacker knew the correct code, sometimes on the second or third attempt. I couldn't determine the exact mechanism — I initially thought it was time-based generation, but couldn't establish any correlation. The liveperson.net service itself might have been vulnerable.

Recently Skype abandoned liveperson.net; the support chat moved to the microsoft.com domain. Account deletion is now inaccessible to operators — users must use the self-service form.

Experiment — "Die for Your Sins"

One year later, attack victims again contacted me; Security Code letters no longer arrived, suggesting another method had been discovered.

I grew exhausted pleading and humiliating myself for months, requesting vulnerability fixes. Having used Skype for about ten years, with my main account "zhovner" similarly aged, I decided that conducting this experiment fairly meant experiencing the harm myself. I ordered my own account deletion.

Deletion Order Details: Cost: 2,000 rubles (~$30). Three-day completion timeframe stated. After several days, I was logged out and couldn't log back in.

Communication with Skype Support

Immediately after blocking, I wrote to support, assuming mass-report blocking and describing the situation in detail.

Conversation Excerpt:

Me: Why is my account blocked? I suspect mass false reports.

Skype: The automatic system blocked you for Terms violations.

Me: Your system is vulnerable — false reports can block innocent accounts. Mine was blocked this way. Please investigate carefully.

Skype: We checked. The system doesn't make errors. All actions are logged. You violated the rules. Your account won't reopen ever. Create a new account.

Me: The system is susceptible to fraud manipulation. Here's proof.

Skype: No, the system is correct, 100% certain.

Me: Name the specific actions that caused the blockage.

Skype: You already described them. You're right about the blockage causes.

Me: Are you insane? You're confirming that any account can be deleted via sufficient complaints? You don't even know the complaint reasons? These complaints are sent without adding victims to contacts? From accounts that never communicated with the targets? You're confirming such a vulnerability exists. Is this legal? I'm considering court.

Skype: We have provided sufficient information. You're simply trash.

Me: This is a serious vulnerability. You should investigate thoroughly. I have data to reproduce it. We can repeat it on an account you provide — one that definitely hasn't violated any rules, completely controlled by you. I'll pay the attackers to delete it, and you investigate.

Skype: We understand you want the exact deletion reason. We told you — our automatic trash-person detection is very accurate. You're trash. We have recordings!

Me: What if I report a vulnerability? Here's a detailed description...

Skype: We don't care. Go to court or police.

Conclusion

15 days after account blockage, support shows no intention of recovery. I still expect my account to be returned and apologies from Skype for the humiliations endured while attempting to improve their service's security.

Skype represents an enormous, unwieldy bureaucratic machine unable to detect or address problems due to its scale and poor organization. Change seems unlikely.

This article describes vulnerabilities personally known to me. Presumably, countless additional problems exist and are actively exploited.

Critically, such problems affect ANY centralized-management messenger where security depends on trusting the administration. Believing your favorite messenger is safer than Skype because the employees are "good people" represents a major misconception.

People with unlimited access to user information are vulnerable to pressure, blackmail, or deception. Few would accept imprisonment or death to protect user messages. Unlimited access creates perpetual temptation for misuse.

Truly secure messengers require building on specifications that make access impossible, not trusting particular people.