Paid Advertising
web application security lab

Using DNS to Find High Value Targets

With the impending release of Fierce 2.0 I thought I’d spend a minute talking about finding high value targets. I was working with a company in a specific vertical when I realized they use a very large single back end provider (essentially a cloud-based SaaS). But they aren’t the only large company using that SaaS - there are many hundreds of other companies using them as well. But because I’m not in that particular industry and having not worked much in that vertical, I had never even heard of them before. Frankly, I had no idea that they even existed. Now let’s take a typical Fierce DNS enumeration scan; it can find a lot of non-contiguous IP space, sure. But what about when I launch scans against hundreds of companies in that same vertical? Some interesting results start bubbling up.

Because companies tend to point their DNS to those SaaS providers for white labeling, often you’ll see a convergence of a lot of sub-domains all pointing to a single IP address or set of IP addresses. It doesn’t take a rocket scientist to realize that you don’t need to attack the target you’re interested in, you can attack the SaaS provider and take over not just one but all of those companies in that vertical that use that provider. Even though that may not be obvious by just probing the external network, DNS can sometimes help to uncover those sorts of details. This happens a lot more than most people realize, and in my experience those cloud based SaaS providers aren’t any more secure than anyone else. It’s a lot more interesting to compromise hundreds of companies for the price of one.

4 Responses to “Using DNS to Find High Value Targets”

  1. BD Says:

    @RSnake: Hello, enjoy the information you put out. What a scary world, eh?

    I got a question for you, broadly related to browser security. What are your thoughts on this scenario, very simple:

    Do not surf with JavaScript enabled, ever.

    What percentage of issues do you think that would mitigate?

    Wannabee infosec guy.

  2. RSnake Says:

    @BD - It would solve a lot of issues but definitely not all, and not even a lot of the generic issues that most people worry about regarding client side security. For instance, we can still steal your browser history, do cross site request forgeries, hack your intranet, brute force, do DNS rebinding, clickjacking, etc… etc…

    Meta refreshing, CSS, redirection, chunked encoding, etc… all add levels of variability in the browser that allow an attacker to do most of the same stuff that JavaScript would allow. Now, most of that stuff is theoretical in nature or we have weak proof of concept code, but I’ve seen little to none of it in the wild. The real attacks are almost all based in JavaScript space in reality. Almost none of them opt for the non-JavaScript version. Also, most of the malware out there requires JavaScript to fire to work (not all, certainly - like the old GDI++ vuln as an example, but most). So in the real world, yes, it’s quite a bit safer to turn off JS entirely. Of course that breaks legitimate websites too. It’s definitely a trade-off.

    If you really want to secure yourself, you’ll break any cross domain requests too unless you explicitly allow it (sort of the cross domain equivalent of NoScript). The RequestPolicy plugin for Firefox is a good example of that.

  3. niko Says:


    Took a look at fierce based on your post, have to say im not overly impressed, all its doing is saving me maybe one/two minutes of my time that I would usually do at the start of a test when my coffee pot is brewing.

    Good idea and was hoping it would do a swell job, maybe it just needs time to mature.


  4. RSnake Says:

    @niko - sorry it didn’t live up to the expectations/hype. I’m not sure what you were expecting it to do beyond what it does, but if you have suggestions, I’m 100% sure Jabra will be interested in talking more about it.