Hackers arrested for guessing thousands of home IP surveillance camera passwords and capturing intimate videos

Four Korean suspects have been arrested for collectively hacking into over 120,000 IP surveillance cameras, allegedly by guessing the simple passwords chosen to protect them. These people acted independently, but they all appeared to have the same motive of capturing sexually intimate videos from cameras installed to monitor the interiors of victim's homes. Two of them were also caught then posting hundreds of these stolen videos for sale on a porn website.

Link to article: https://koreajoongangdaily.joins.com/news/2025-11-30/national/socialAffairs/Four-arrested-for-hacking-surveillance-cameras-to-produce-pornography/2466324 

 

Are Recent Password Guessing Attacks Tied to Devastating Morris Worm?

With recent reports of online password guessing attacks, like those Apple customers may have experienced, is it possible that the Morris worm is responsible?  Yes, I mean the Morris worm from 1988.  The one that impersonated users with weak passwords as part of an attack arsenal that allowed it to spread and overwhelm the then nascent Internet.  Since password guessing was detected shouldn't we assume this worm has resurfaced?

“But Bruce,” you protest, “you're offering no evidence that these things are in any way associated!”  And to you I reply “Well, why should that stop us from speculating?”

Ok, my claim is a bit exaggerated but it was inspired by real news from Namecheap on Monday.  The web hosting company warned customers that they had detected a credential guessing attack, which “likely” matched a recently revealed Russian password collection.  This collection, publicized by security consultant Alex Holden in August, purportedly included 1.2 billion unique credentials stolen by a hacking group nicknamed "CyberVor".  It attracted a lot of attention in the news, along with its own controversy.

So why did Namecheap think the attempted usernames and passwords were associated with CyberVor?  They don't offer a reason in their posted warning.  Furthermore, I don't believe they have a good reason.  The Russian credential cache has not been made public so there are no username or password records for them to compare to the guesses they saw.

My suspicion is that the CyberVor story was still fresh in the mind of someone at Namecheap and they made an assumption that the group's data was involved when faced with their own attack.  Maybe there was also some circumstantial evidence, such as password guesses originating from Russian IP addresses.  Regardless, there's no apparent way for them to know and there's likewise no reason to assume there is a connection.

I can forgive a company for including a seemingly unrelated statement when they aren't accustomed to disclosing details about an attack, but what really bothered me was how a few members of the media failed to question it.

An article by The Register mentioned that the Namecheap news offered "anecdotal evidence" of a CyberVor connection but seems to otherwise present the information as fact.  Infosecurity Magazine's coverage also didn't question how the two events were related, and goes on to wonder if it was the first time the Russian credentials were used in an attack against another site.

I understand that news cycle driven journalism means not being able to fact check every detail being shared, but I feel like the Namecheap claim was important enough to raise a red flag, especially at these two publications.

Meanwhile, IDG News Service did challenge how Namecheap could make this connection and actually took the time to ask Alex Holden (the only person outside of CyberVor known to have a copy of their credential cache) about the claim.  Holden agreed that there wasn't support for thinking CyberVor data was involved.  A SecurityWeek article also questioned whether timing of the two incidents was the only evidence that led to the conclusion, and apparently did try to verify the statement with Namecheap.

In reality, automated password guessing, or brute-forcing, attacks have been a threat long before CyberVor made the news.  The US Department of Defense Password Management Guidelines advised setting minimum password policy standards to combat the threat of login password guessing back in 1985.  Although since the cutting edge technology of that day required passwords to be tried over 1200 baud modems the attacks took a slight bit longer to carry out.

More recently, both web sites and other Internet services have faced increased password guessing attacks.  In 2012 the video game development company ArenaNet (who hosts the Guild Wars 2 MMO) responded to thousands of customer support tickets when criminals successfully guessed player passwords.  Last year, both Konami (PDF) and Nintendo experienced millions of login attempts, taking place over several weeks, aimed at compromising their customer accounts.

One factor these attacks all seemed to share was that the hackers behind them were leveraging usernames and passwords stolen from other hacked sites.  The dangerous and common practice of reusing passwords for different companies can mean that your site is more vulnerable to attack if you have users that also maintain accounts on less secure sites.  If one of those sites is breached and their user database is stolen (possibly with passwords stored in plaintext) it can improve the success that criminals have when attempting to guess credentials on your site.  This likelihood of success probably grows when the hacked site and yours both cater to a similar customer base.

So while it is likely that the credentials tried against Namecheap customer accounts originated from one or more hacked sites, there are plenty of more likely sources for collecting password records other than the CyberVor stash.

On a positive note, Namecheap does deserve praise for having monitoring in place to detect unusual login activity, which allowed them to quickly take steps to protect their customers' accounts.  Instead of the weeks noted above in the Konami and Nintendo cases, Namecheap personnel responded within hours of the attack.  That probably made a big difference in limiting how much damage the attackers were able to do.

Hopefully the company will continue to conduct effective incident monitoring and response just in case the Morris worm does rear its ancient head.

How password policy requirements impact possible password choices

A recent discussion on a SecurityFocus.com mailing list raised a concern about password policies that I hadn't previously given much thought to. The post author commented that he wanted to enforce a policy that required passwords to have lowercase, uppercase, number, and symbol characters. By this he meant every password must have at least one character from each of these characters sets. One reader responded that by requiring the use of all four character sets he would reduce the total number of possible passwords, causing a negative impact on password security.

Instinctively I knew the claim about reducing password possibilities was right, but I dismissed the security impacts as insignificant. After all, with 95 standard characters within that character pool to choose from, the total number of password possibilities is massive. Unfortunately "massive" doesn't really provide much perspective on how negative the impact could be. To quantify the impact I decided to calculate the actual effects on password possibilities.

I started with a set password length of 7 characters, giving us 95^7 (or 6.98 x 10^13) total possible passwords that users can create without any specific character requirements. This gave me the unrestricted total. I then needed to figure out how many of these passwords would meet the restricted requirements of having lowercase, uppercase, number, and symbol characters within them.

Following some different approaches at number crunching I found that there may not be an easy formula for calculating the quantity of restricted password possibilities. The easiest approach seemed to be counting the number of passwords not meeting the criteria and then subtracting them from the unrestricted total. While not math intensive, this approach does take some fancy spreadsheet formulas. If you have a burning desire to see the numbers yourself, you can check out the resulting Excel spreadsheet I created.

When I compared the restricted and unrestricted password possibilities I was in for a bit of a shock. It turns out that for 7 character passwords the restricted requirements would eliminate about 63% (or 4.4 x 10^13) of the total password possibilities! So much for an insignificant impact.

I applied this technique for several different lengths of passwords to see how the length changed the results. The longer the password became, the more the percentage of eliminated passwords shrunk. The restriction eliminated 54% of 8 character passwords. With 10 and 12 character passwords only 41% and 31%, respectively, were eliminated. These losses still amount to sizeable chunks.

This led me to evaluate the impacts of the normal Microsoft Windows password complexity requirements. Enabling this security policy forces users to choose a password made up from only three of the four character types. For a 7 character password this still amounted to a 9% reduction in possible passwords.

So, numerically we've established the impacts of different password policies, but how should these numbers affect our decisions to enforce such policies?

If we consider password cracking our biggest threat then we must consider how knowledge of the password policy might save an attacker time avoiding unacceptable passwords. Fortunately, real-time brute force cracking isn't terribly compatible with this approach. In the time it takes for cracking software to evaluate whether a password guess meets the policy it could have just tried the password. So no effort is eliminated in this scenario.

However, a rainbows tables cracking approach can benefit from policy knowledge. An attacker could create a rainbow table consisting of only the passwords that meet a particular password policy. As a matter of fact, attackers do that today by generating and sharing rainbow tables consisting of the most common password character sets.

While bad guys could technically implement this attack for complex passwords, it would be one of last resorts. So few environments require passwords containing the four different character sets that attackers have little reason to generate the rainbow tables. It is still much more rewarding for them to focus on cracking passwords like "muffins" instead of "b@n4Na5".

More importantly, creating just the rainbow tables needed for our restricted password pool of 7 character passwords would require hundreds of terabytes of disk space. Yes, I did the math. Few attackers have this level of resources available to them.

We have always made sacrifices like this when instituting password policies. By establishing a minimum password length we, by definition, eliminate all possible passwords of a shorter length. Nonetheless, we know we are making a general improvement in overall password security by removing the shorter, and thus easier to crack, passwords.

When it comes to password complexity we have to consider the attack significance along with the mathematical significance. In reality, there are situations where enforcing specific password restrictions is a very bad idea. However, this is the exception rather than the rule.

I don't believe that enforcing either normal Windows password complexity policy or the even more restrictive 4 character set composition requirement should worry you when paired with a minimum password length of 7 characters. The loss of possible passwords in these cases are greatly outweighed by the benefits of eliminating a large number of poor password choices. From my perspective, those changes have a positive impact on security.

We know about password attacks in Kansas

I was making a dent in a sink full of dishes tonight and half listening to the TV when a show caught my interest. Dateline NBC was airing a segment on the disappearance of John Elwin during a business trip. Apparently his girlfriend, Kirsten Flood, wasn't initially having luck interesting authorities in a search for clues about the whereabouts of Mr. Elwin. Frustrated, she engaged a friend, Denise Tripoli, with "experience in Internet security" to help.

The following excerpt comes from the show's transcript:

   If only she could hack into Elwin's e-mail account, they might discover where he was.

   The two women wracked their brains trying to guess at a pass code that would give them access.

   FLOOD: [We tried] his birthday, his social security number. And I just kept going down the list until I hit it.

   FLOOD: And lo and behold, we got into it.

   BOB MORRISON: What did you find there?

   TRIPOLI: We broke into his account at eleven o'clock at night, and I was up till three in the morning, looking through every e-mail. And I was very disturbed by what I saw.

I certainly won't pretend that I would avoid this temptation if one of my friends or family members went missing and I had exhausted other options. Nonetheless, I was a little disturbed by the casual explanation of how these women broke the law to gain access to Mr. Elwin's email account. In my opinion, reporting this part of the story in this manner trivializes the ethical and legal implications of getting into another person's email account.

You would expect that a news organization so eager to expose the secret underworld of hackers would act more responsibly.