Kaspersky hacked?

happygeek 0 487 Views

It all kicked off last night with a posting to hacker board claiming to have carried out a relatively simple SQL Injection attack on one the world's biggest and best known IT security companies: Kaspersky.

The hacker, currently only know as 'unu' claims that the SQL Injection attack on usa.kaspersky.com has exposed activation codes, user details, bug lists and so on. "Kaspersky is one of the leading companies in the security and antivirus market. It seems as though they are not able to secure their own data bases. Seems incredible but unfortunately, its true. Alter one of the parameters and you have access to EVERYTHING: users, activation codes, lists of bugs, admins, shop, etc" unu says.

If this proves to be true, and Kaspersky has yet to confirm or deny the claims, it will prove to be hugely embarrassing as it exploits one of the simplest of hacking methodologies - the old change a bit of the URL trick. Here at DaniWeb we exposed how an online visa application system fell victim to the same tactic, potentially exposing the personal details, including passport numbers and travel plans, of hundreds of thousands of Indian citizens. Our revelation ultimately led to the UK Foreign Office being found guilty of breaching the Data Protection Act.

So has Kaspersky been hacked? Well Kaspersky is obviously investigating and will no doubt issue a statement sooner rather than later. I would expect for first thing Monday morning at the very latest if it wants to keep a lid on this thing. However, the screen shots that have been posted at the hacker blog certainly seem convincing enough and do tend to suggest that it could be for real.

The Register reports that this is not the first time Kaspersky has been on the wrong end of a SQL injection attack. El Reg says Kaspersky's Malaysian site and some subdomains were defaced by a pro-Turkish hacker in July, and there have been a total of some 36 Kaspersky website defacements since the year 2000.

Gunter Ollmann, the chief security strategist at IBM Internet Security Systems, is certainly in no doubt over the seriousness of the claim, warning "...this type of critical flaw can probably be used to usurp legitimate purchases and renewals of their products - which could include the linking to malicious and backdoored versions of their software - thereby infecting those very same customers that were seeking protection from malware in the first place."

Dani AI

Generated

raised the core concern in this thread: an alleged compromise was posted and supported by screenshots, but vendor confirmation and independent forensic evidence are not present in the thread. The text below supplies practical ways to evaluate claims like this, concrete steps site operators should follow when a web-facing application is suspected of being exploited, and constructive alternatives to the kind of illegal request seen from .

How to judge the credibility of an alleged breach:

  • Look for an official statement from the vendor and timestamped incident notices from trusted security feeds.
  • Verify whether updates or installers still validate correctly (digital signatures/checksums).
  • Search reputable disclosure platforms and CERT advisories for corroboration rather than relying on screenshots alone.
  • Check whether logs, backup snapshots, or IDS alerts show corresponding activity before treating public claims as fact.
  • Treat any public dump or list as actionable only after validation and preserve chain-of-custody for evidence.

Practical incident-response checklist for operators and developers:

  • Isolate affected hosts and preserve full disk and DB snapshots; do not overwrite logs.
  • Rotate credentials, API keys, and any DB service accounts with broad privileges.
  • Apply immediate input-validation and WAF rules to block suspicious requests, then perform a code review and patch root causes.
  • Audit for web shells and unusual outbound connections; engage IR or external forensics if data exfiltration is suspected.

A minimal example of safe DB access (use prepared statements / parameterized queries):

$stmt = $pdo->prepare('SELECT id FROM users WHERE email = :email');
$stmt->execute([':email' => $email]);
$user = $stmt->fetch();

Requests to “crack” products, as in ’s post, are illegal and dangerous. Legitimate alternatives include practicing on intentionally vulnerable labs, participating in CTFs, or using vendor bug-bounty programs and responsible-disclosure channels.

Member Avatar for rayeesmkrayees
rayeesmkrayees 0 Newbie Poster

how to crack kasper2010

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview