Stealing the Neighbor's Internet: A Tech Mystery

Last weekend, we moved into a lovely new apartment with much more space and much better sound insulation than the last one. We also upgraded our internet service to 300mbps downstream which is a HUGE improvement over the "standard" package we used to have! Speedtest confirmed that, in fact, we were often getting above 300mbps. Dreams of super-high-quality streams and next to no latency in raids were dancing through my head.

Unfortunately, the active coaxial port was not located near enough to our computer desks -- Ben and I both require an ethernet connection directly to the modem, so going wireless wasn't an option. The kids' computer was in their room and so would never be close enough to the router for a hardwired connection, but we planned to use a powerline adapter to bring the internet in for them. In the meantime, I connected using a powerline adapter myself until a tech could come out to switch the active port to one in the same corner as our desks, which is exactly when the trouble would begin.

The problem

The internet was working after the tech left, but it was much slower than it had been before. A quick check on Speedtest showed that not only were we only getting somewhere around 16mbps down, we also had AT&T as our internet service provider -- which was extremely strange, considering that our ISP is actually Cox.

A false positive

Commence contact #1 to tech support. The representative confirmed that he could see the modem and was able to issue a reset from his end, meaning it was definitely connected to Cox's network; Cox could see us, but we couldn't see them. He did notice that the IP address I was seeing on my computer didn't match the IP address he had listed for us. After about an hour of working with him I noticed that the ethernet cable for my computer was loose in the modem port, and when pushing it back in, the problem seemed to resolve itself. I very sheepishly apologized and gave him permission to use me as an "idiot customer" story on his lunchbreak and figured everything was fine.

Alas, it was fine for about five minutes. Note that I'm still not sure why this seemed to temporarily fix the issue, but I was never able to reproduce this fix, even when unplugging and plugging it back in.

Enter Ricky and Vicky

It was at this point that we also noticed we were unable to reach the router on our local network via the typical address. We were, however, able to access the address listed as the default gateway in my ipconfig results, which brought us to the control page for an AT&T network owned by "Ricky and Vicky." GeoIP initially showed this as being a network located in Georgia. Frighteningly enough, this page listed plaintext passwords for their network, the MAC addresses and IPs for every device connected to it, and the ability to control those devices. In a previous life, I would have had lots of fun running a MitM attack to monitor keystrokes and maybe score some sweet banking credentials or just cause some childish mayhem. Luckily for Ricky and Vicky, my hat has faded a few shades in the wash.

The theory, developed with lots of help from my telecom friends on Twitter, was now that the equipment used to belong to Ricky and Vicky had been wiped improperly, possibly because an AT&T tech had overridden the base configuration of the modem to pull down the MD5 from the same TFTP every time -- they're not necessarily supposed to do it, but it's still a fairly common practice. As to how the modem then ended up in Cox's leasing pool was anyone's guess, but probably they switched ISPs at some point and it got taken to the wrong place.

Ruling out devices

Contact #2 involved going to the Cox store, giving a very high-level overview of the problem, and retrieving a brand-new, never-before-leased modem. If the problem was indeed an improperly wiped device, this would be an immediate fix.

No such luck. Upon setting up the new modem and plugging everything in, Ricky and Vicky were once again flashing up on the screen. It was statistically possible that we'd been given two bad modems from the same location back to back, but very, very improbable.

The issue was confirmed to be showing up on both computers on the hardwired connection, ruling out any strange DNS or proxy settings on one machine or the other. Virus scans came up clean. The final evidence that the computers themselves were not the culprit would come during the next tech's visit, when upon plugging his laptop directly into the modem, he saw the same exact behavior.

Plugged into the wall below Ben's desk, a small white box sat quietly, innocently, going largely unnoticed during the troubleshooting process.

Renew and release: an exercise in futility

Contact #3 was another hour or two on the phone to a customer support representative who was just as stumped as everyone else was. He insisted there couldn't possibly be anything wrong because he could see our modem and issue remote commands to it; we informed him as patiently as we could that we were aware of this, but that we were still getting AT&T's service through a Cox router. 

This is where I'd like to make a controversial statement: ipconfig /release and ipconfig /renew have never once solved anyone's problem. Ever. I have been using, fixing, and building computers for more than three quarters of my life and renew/release has never once been the solution. 

Although this representative was surprisingly hesitant to send out a tech, I finally put on my sternest Mom voice, explained that I was four days into not being able to work reliably -- the reason that there was no blog post last week, in fact -- and that the 20 minutes of dead air punctuated with "ummmmm" and "I don't know" indicated to me that he had done all he could to help and that the next step was sending a tech out to look. He finally agreed.

A networking nightmare

My next theory was that the issue had something to do with the cabling. I was confident it wasn't an issue with the main line, since multiple representatives had confirmed there were no outages in the area and no similar reports had come in from anywhere, let alone our apartment complex. This was actually good news, as an issue with the main line takes a lot more time and manpower to fix. It seemed like two cables were resting against each other somewhere in such a way that they were causing AT&T to override Cox with regards to the information being sent to the modem. Or, more likely, the first tech had grabbed the wrong cable from the box when switching the active port.

When the second tech showed up, he helped me rule out the "wrong cable" theory by explaining that AT&T isn't actually cable internet, it's DSL, and thus doesn't use the coaxial port like Cox does. This actually made the entire situation even stranger, as if the modem wasn't receiving information from Cox, it should have just shut off completely. We also noticed that somehow, even when the modem was restarting, I still maintained a connection to Ricky and Vicky's network, which was now showing up in the list of available wireless networks -- GeoIP was incorrect when it told us Georgia. It now seems that they're either our upstairs or downstairs neighbors.

The issue persisted even when running the cable line straight from the external box into the modem. After two hours, the tech brought another brand-new modem up from his truck as a last ditch effort to solve the problem. To our shock, it worked. I was back on Cox and getting my blazing fast speeds. My connection persisted through a computer restart and power-cycling the modem.

Must have been that statistical improbability of two bad modems, we thought. As he was packing up his tools, I noticed that my computer was the only one hooked into the modem. Ben's computer and the powerline adapter for the boys' room were unplugged.

The powerline adapter.

Not wanting to keep the tech out any longer than the poor guy had already been held captive, I saw him out, then came back to the computer area and plugged the powerline adapter in.


I unplugged it again.

Cox. All without having to even restart the modem or my computer.

Unexpected answers

Telecom Twitter to the rescue again as I explained the ultimately nonsensical situation -- although I don't have a way to crack open the wall to verify, it's most likely that we have poorly shielded copper wires in the wall where our computers and the newly-activated port reside. Cross-talk is occurring between the electrical and phone lines, and then when the adapter is plugged straight into the modem, it's allowing it to use the modem for the DSL line instead of the cable while still maintaining a connection to the Cox network.

As to why the wires are not shielded correctly, it's a front wall and our computers are in what would usually be a dining nook. I'm sure it wasn't planned that people would be using this area of the apartment for heavy-duty telecommunications. There's also a very good possibility that the wires were initially shielded just fine, but ants -- of which we have many due to all of the trees and plants around -- have chewed through the physical shielding. The destructive power of ants is often underestimated, but we had a main cable line in one of my previous residences actually go completely down because of an ant infestation that had taken hold.

It's something that is incredibly unusual, but I guess we're just that lucky. At least the solution didn't require ripping out drywall or anything else messy, expensive, and difficult; we can just go with a wireless card for the boys' computer. Even still, I wanted to make sure to document the process for anyone in IT or customer service who may have a customer with the same issue, as everyone I spoke to along the way stated that this was the first time they'd ever heard of such a thing, even those who had been working in the industry for 10+ years.

I've also done some research regarding the particular modem we have, manufactured by Arris, and found that there are multiple complaints of incorrect IP addresses being assigned by them (although not as far as incorrect ISPs). I'm frankly a bit surprised that Arris wouldn't have included something in their firmware to prevent this kind of override. I'm also shocked at AT&T for the ease with which I was able to access my neighbor's sensitive information -- there was no initial login page, just an automatic connection to their network controls.

At any rate, it looks like this is the end of our adventures with Ricky and Vicky, until such a time that I muster up the courage to knock on their door and give them a quick lesson in network security.


Bunny's Kitchen: Making a Basic Curry

When I'm not gaming, I'm usually in the kitchen testing out a new recipe or tinkering with ones I already know by heart to make them easier and better. I've tormented everyone on Twitter and Facebook with photos of the results, usually ending in requests for the recipe.

Let's be honest, curry isn't always the most photogenic of foods.

If done right, however, it's darn tasty, and the most you'll have to do is some serious chopping. Pictured above is a chicken korma I made this week, but if you master the basic paste that can be used for all varieties of curry, all you have to do is switch up the spices and the meat you use.

Getting Set Up

I use pre-mixed curry spices from Spice Mountain, which is based out of England. If you're on that side of the Atlantic, they have a lovely shop in the Borough Markets, but otherwise, they do ship internationally through their online store!

The recipe I started with was actually also from Spice Mountain, but I made a few tweaks here and there for ease of cooking and availability in the United States. The beauty of this recipe is that it doesn't use roux, meaning that if you use proper substitutes for meat and cream where applicable, it's perfectly suitable for vegetarians and vegans.

Before you start shopping for the paste ingredients, decide what kind of curry you want to make and do some research as to what kind of meats will work best with the flavors. For example, rogan josh works best with lamb or beef. Also determine if the particular curry should be creamy -- korma and tikka masala are best if substituting heavy cream for water. If you're using a dairy-free substitute for the cream, try to avoid coconut milk, as it tends to overpower the rest of the flavors in the dish; especially if you're making korma, cashew or almond milk is really good.

Also, if you plan on doing curries regularly, you may want to invest in a good food processor or blender. I have the Nutri Ninja Professional BL450 and it works wonders for the paste part. Plus, it gives you an excuse to have smoothies and milkshakes whenever you want.

This recipe makes enough for two people to have very generous portions. If you have any remaining, put it in a Tupperware container and store it in the fridge for the next day, then heat it up in the microwave starting with 1 minute 30 seconds on the timer and using an additional 30 seconds as needed. It's still very tasty as leftovers!

Finally, I should note that I'm fairly certain this is more on the British colonial side of curry style versus what you might get in an Indian grandmother's kitchen (note the lack of roux above). It is still really, really delicious in its own right.


  • 1 tbsp extra virgin olive oil
  • 1 large onion
  • 2 garlic cloves (or 1 tsp crushed garlic)
  • 1-inch piece of ginger root (peeled if the skin is very papery, otherwise fine as-is)
  • 2 tbsp tomato paste
  • 2 tomatoes
  • 1 cup water or heavy cream, depending on the type of curry you're making
  • 3 tsp curry spices
  • Salt to taste
  • Desired meat or meat substitute


  1. Roughly chop the onion and the ginger root and add them to the blender bowl.
  2. Chop the tomatoes as finely as you can, put them in another bowl, and set aside.
  3. Chop up whatever meat or meat substitute you're using into bite-sized chunks and set aside.
  4. Add the garlic to the blender bowl and blitz it until all chunks are gone.
  5. Use non-stick spray on a large sauté pan if it doesn't have a non-stick coating before adding the olive oil; if your pan has the coating, just add the oil straight away and heat it.
  6. VERY CAREFULLY pour in the paste from the blender bowl and fry for 10 minutes -- seriously, go slowly, I've nailed myself and the rest of the kitchen with splashback from this more than once. The texture of the fried paste should be similar to chunky applesauce.
  7. Add the water or cream, spices, tomato paste, chopped tomatoes, salt, and meat or substitute. Stir it all up and simmer it for 10 to 15 minutes to thicken it.

Serving Recommendations

  • Research traditional preparations of the specific type of curry you're making and add nuts, sultanas, vegetables, potatoes, or anything else that might be recommended.
  • Serve over basmati rice.
  • Add a couple of scoops of mango chutney to the side.
  • Serve with papadums or naan. 


The Temperature At Which Code Burns

I grew up with my mother's Commodore VIC-20 in the living room. By the time I was five years old, not only did I have a Performa 430 of my very own, but I'd taught myself how the system worked well enough that the teachers at my elementary school called me over the campus IT specialist to fix their computers -- a trend that continued well into high school. At the age of 15 I was reverse-engineering websites and building my own based on the tricks I learned from individual page sources.

I also did some reprehensible stuff that I'm not going to specify due to the fact that none of it was even remotely legal and I haven't been prosecuted for any of it, which is a track record I intend to keep. After a couple of close calls and a dose of maturity, I brought my own experiences as The Jerk On The Other Side Of The Keyboard to my career working for the good guys. After all, who could be better suited to point out potential vulnerabilities in web apps and software than someone who used to exploit them?

These days, I'm an old lady sitting in her ergonomic desk chair cheering for all the others who've traded in their black hats for grey, at the very least. I haven't kept up with the constantly evolving tech world as much as I used to. I don't need to; there are plenty out there who are much more prolific and involved than I ever was, doing better work than I could ever imagine. I am content here on the sidelines, just following the stories as they happen instead of taking an active role in them.

Imagine my joy when 23-year-old Marcus Hutchins, known on Twitter as MalwareTechBlog, quite literally saved the world from the WannaCry worm just a couple of months ago. All he had to do was register a domain contained in the malicious program's source code, triggering a "kill switch" that stopped the infection dead in its tracks. It was an example of the current generation who'd grown up with far more sophisticated technology than I using their powers for good, stepping up to the same plate I'd stepped down from. We are in excellent hands, I thought, with a sense of pride weighing in just under that of a mother watching her child graduate.

A couple of nights ago, I found myself reading The Virus Underground, an article published in the New York Times back in 2004 by Clive Thompson that would prove to be unexpectedly prescient in its discussion of the legal and moral grey area surrounding code authors and whether they should be held accountable if the code they make available to others for educational purposes is then used for those that are decidedly not.

I was pleased to think that now, 13 years after the article was written, we live in a society of GitHub and Stack Overflow, where code can be easily shared and discussed, a digital version of the Socratic method. It's common knowledge that mixing enough rat poison into a cake will kill the person who eats it. It doesn't mean those of us with that knowledge are murderers, or that an author who writes about such an M.O. is responsible, should the events be imitated in the real world.

Then Hutchins was arrested by the US government. His "crime?" Authoring a hooking engine that was then lifted by an unassociated third party to use in the Kronos malware, which was then sold on the black market along with instructions on its use.

There is no evidence that Hutchins was the one behind the final version of Kronos. There is no evidence that he was the person who put it up for sale. The only evidence in existence is that he wrote something that was later blended with somebody else's code by someone very much not him:
But because Hutchins created something that was eventually used for nefarious purposes -- once again, by a third party -- he sits in a jail cell.

Ask yourself if, then, we should arrest everyone who's ever contributed to a cryptography or hacking reference book. If we should burn every copy of each of the aforementioned volumes, just in case. If anyone who has them sitting on their shelves should be thrown in jail because they might use them for the wrong reasons, or author something that someone else will misuse.

If that's the case, then hey, law enforcement agencies: here's just a few of many more reasons for you to show up at my door and drag me off in handcuffs, too. I'll put on a nice pot of tea when you get here.

By this logic, we can say so long to GitHub and Stack Overflow, farewell to computer science classes being offered on college campuses, auf wiedersehen to effective antivirus software -- because many of the threats that the antivirus program running on your computer right now defends you against are included thanks to multiple white hats who have identified vulnerabilities and notified the appropriate parties to get hotfixes and definition updates pushed out.

Anyone who writes a piece of code that could be used for malicious purposes and posts it, free of charge, in a publicly viewable location, does not do it because they want that code to be unleashed upon the world. The very minute code like that becomes easily available on the internet, those aforementioned defenses start building up. In-house software and security testing can only detect so much; there is no piece of code, let alone an entire, functioning application, that is 100% free of bugs or vulnerabilities, and there never will be.

But you know what gets it anywhere close? Discussion. Knowledge-sharing. Blasting it as loudly as you can to anyone who will listen when a potential landmine is found. The continued prosecution of white and grey hats for innocently pointing out flaws and disasters-to-be will put an end to that alert system; then it will be only the "bad guys" tapping away at their keyboards to let us know the hard way when a lapse is found, because the rest of us will be too afraid to share our findings.

Thankfully, the widespread sentiment is that the case against Hutchins is sufficiently weak, and that he is not the criminal mastermind that the United States government has accused him of being. Maybe the Feds are still sore about the ease with which hackers and security experts at DefCon this year broke into US voting machines. Maybe, given the current administration's attitude towards anyone not of sufficiently "American" pedigree, they're looking for an easy scapegoat. 

What is certain is that even if the case against him is dropped, simply arresting him under such flimsy pretenses sets a dangerous precedent for anyone else who has ever been curious or bored enough to experiment with code, who might just turn out to be the next superhero the world needs for the next malware attack.