One year ago, I already covered the impact that ICANNs latest money grab was having on security, see ICANN is the organization that rules the Interwebs, and decides which top level domain names can be used. A while back, they decided that they needed more money, and embarked on a manifest destiny like trek to discover domain name lands that they could homestead for free, and then sell to the highest bidder.

Thanks to this, we now have generic top level domains (gTLDs) like .support and .shop and .buy and .smile, in addition to .com, .net co. Some of these new native lands that ICANN offers seem to be rich in gold or silver, since A LOT OF MONEY is changing hands for the privilege to own one of these freshly plowed plots of cyberspace.

The problem is, most newly arriving settlers are outlaws, and there is no sheriff in town! For example, this past week, most of the redirector pages leading to exploit kits were domiciled under the new gTLDs .top and .xyz. To add insult to injury, some of the miscreants that register these domains dont even TRY to hide. They use the same name and email address for six, eight weeks in a row. Once a domain of theirs gets blacklisted by filters, the bad guys already have 10 other domains registered, and they simply relocate.

Two weeks ago, ICANN published their Revised Report on New gTLD Program Safeguards to Mitigate DNS Abuse, suggesting - at least on the surface - that they are aware of what is going on. But let me share a couple of nuggets:

[...] ICANN and its various supporting organizations have some purview over registration issues through the policy-making and enforcement processes, while use issues are more difficult to confront given ICANNs limited authority over how registrants use their domain names. [Translation: Malware TLDs are not our fault]

The ICANN-sponsored survey referenced above reported that consumer trust in new gTLDs is much lower than in legacy TLDs, with approximately 50% of consumers reporting trust in new versus approximately 90% reporting trust in legacy TLDs. [Translation: Well, DUH! Sometimes, consumers are right!]

[...] New TLD domains are more than twice as likely as legacy TLDs to appear on a domain blacklista list of domains of known spammers within their first month of registration. [Translation: We knew this was going to happen, but lets conduct another study while we rake in the dough]

The report goes on to list the Nine Safeguards that ICANN put in place to prevent abuse. All of them make perfect sense. What is glaringly obviously missing, though, is what I would suggest as Safeguard #10: A registrar where more than 1% of their registered domains, or more than 0.01% of the registered domains per TLD, end up on a public blacklist (like Google SafeBrowsing) shall receive a warning, and upon reoccurrence within 3 months, have their license to act as a registrar withdrawn by ICANN with immediate effect.

That whole Oh we cant do anything about how domains are USED cop-out is utter bull. ICANN raked in piles of $$ in the gTLD land grab, and they can afford to hire auditors who compare the zone files against the public block lists, and take decisive action against the registrars that feed on the bottom. Financial institutions have a FTC enforced red flag rule that requires them to know who they do business with, or face the consequences. Why dont registrars?

As as (small) upside, ICANN helpfully publishes a list of all the new gTLD domains. If you are running a corporate web filter, I suggest you simply chuck them all onto the BLACKLIST, no questions asked, and keep them blocked. Fallout will likely be minimal. You can always re-open a specific gTLD once you had 20 or so really worthwhile and business relevant white listing requests for domains under it. Odds are, 95% of the new gTLDs will never reach that threshold. And by blocking them by default, you are bound to keep lots and lots of malware, spam and phishing URLs at bay.

Heres a special shout-out to Charity Baker aka Jaclyn Latonio, who yesterday registered about 200 typo domains like,,, etc, showing how such blatantly obvious abuse is not limited to the new gTLDs. Rather, lack of oversight, accountability and enforcement are the core of the system. Makes one wonder where all that money goes.

You are welcome, ICANN. Consider this my public input to your request for comment.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

A video demonstration of the vulnerability here, using a temporary password. (credit: Kapil Haresh)

This piece first appeared on Medium and is republished here with the permission of the author. It reveals a limitation in the way Apple approaches two-factor authentication, or "2FA," which is most likely a deliberate decision. Apple engineers probably recognize that someone who loses their phone won’t be able to wipe data if 2FA is enforced, and this story is a good reminder of the pitfalls.

As a graduate student studying cryptography, security and privacy (CrySP), software engineering and human-computer interaction, I've learned a thing or two about security. Yet a couple of days back, I watched my entire digital life get violated and nearly wiped off the face of the Earth. That sounds like a bit of an exaggeration, but honestly it pretty much felt like that.

Here’s the timeline of a cyber-attack I recently faced on Sunday, July 24, 2016 (all times are in Eastern Standard):

That’s a pretty incidence matrix

That’s a pretty incidence matrix (credit: Kapil Haresh)

3:36pm—I was scribbling out an incidence matrix for a perfect hash family table on the whiteboard, explaining how the incidence matrix should be built to my friends. Ironically, this was a cryptography assignment for multicast encryption. Everything seemed fine until a rather odd sound started playing on my iPhone. I was pretty sure it was on silent, but I was quite surprised to see that it said “Find My iPhone Alert” on the lock screen. That was odd.

Read 20 remaining paragraphs | Comments


I think almost every one of us working in the IR/Threat Intel area has faced this question at least once: shall we share intel information?

Although I have my own opinion on this, I will try to state some of the most common arguments I have heard in these years, pro and against sharing publicly, as objectively as possible not to influence the reader.

Why not sharing publicly?

  • Many organizations do not share because do not want to give away the information that they (may) have been attacked or breached. On this regard, there are closed trusted groups of organizations within the same sector (e.g. ISAC communities) where the willingness to share in such closed environments increases.
  • Trust is an extremely important factor within the intelligence community, and establishing trust is impossible when sharing publicly. Moreover, by not knowing with whom they are sharing, people are inclined to share less or not to share at all.
  • Part of the community suggests that we should stop providing our adversaries with free audits[1], since in many occasions it has been observed a clear change within the TTP after the publications of analysis results on blogs or reports.

Why sharing publicly?

  • Relegating everything to sub communities may bring the problem of missing the big picture, since this may tend to create silos on the long term, and organizations relying entirely on them may miss the opportunity to correlate information shared from organizations belonging to other sectors.
  • Many small organizations may not always be able to afford getting access to premium intelligence services, nor to enter in any of these closed sub-communities for several reasons.
  • Part of the community believes that we should share publicly because bad guys just dont care and this is also proven by the fact that often times they reuse the same infrastructure and modus operandi.
  • By sharing only within closed groups, those mostly affected would be DFIR people who uses such public information as their source of intel to understand if they have been compromised or not.

What is your view on this?


[1] When Threat Intel met DFIR,

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status