The ThreatFactor NSIA is a website scanner that monitors websites in realtime in order to detect defacements, compliance violations, exploits, sensitive information disclosure and other issues. ThreatFactor detects issues remotely and therefore requires no software to install, does not introduce any latency and will not interrupt business operations.

At it’s core, ThreatFactor uses an advanced analysis engine that is capable of detecting a wide variety of issues and can be modified with custom signatures.

NSIA can be configured perform almost any action once an issue is identified, such as sending a text message (IM, email, SMS) or executing a script. Type of Issues Detected The ThreatFactor solution was designed specifically to help organizations quickly identify issues on your websites that may tarnish your organization’s image or adversely affect your customers, partners and employees such as:

- Website Defacements: Malicious users are trolling the Internet specifically for websites to deface. Oftentimes, these websites contain offensive language or images and likely result in tarnished image.

- Compliance and Privacy Issues: ThreatFactor can detect issues that may adversely affect compliance or user privacy such as: forms that submit passwords unencrypted, pages that accept user information but don’t include a privacy policy, etc.

- Web Exploits: Oftentimes, attackers compromise a website and install exploits to attack the website visitors. These are often classified as silent defacements since the site does not look like it was visually changed. Sophos noted that the vast majority of websites hosting malware (around 80%) are legitimate sites that have been compromised . Furthermore, ThreatFactor can detect websites that have been modified in such a way to send private customer information (such as login information) to a third party.

- Sensitive Information Leaks: Websites can leak sensitive information through detailed error messages, files that were not intended to served to the public and misinformed blogger employees.

- System Failures: ThreatFactor can detect many types of website system problems such as:

  • Broken Links
  • Error and warning messages
  • Poorly configured servers or servers with default configuration
  • Expired SSL certificates
  • Server errors

-Download :
Source :

Finding Malware on your network via cached DNS entries

Posted April 19th, 2010. Filed under DotCom

PDATE: There’s a new version, with 25% less bugs! Use this instead.

As some of you may know, I wear an Incident Response hat within my organization. As I like to be proactive and actively search for issues rather then just be an IDS alert monkey, I love pages like the Malware Domain List, the ZeuS Tracker, and While these are great resources, it is a bit difficult attempting to take the lists and apply them to the environment; most of their usefulness comes from when you have a questionable URL and need to see if someone else has reported it as a bad site. A great service, but not proactive.

While staring at the ZeuS Tracker Domain Block list and trying my usual method of snipe hunting manually entering domains to query the firewalls, a moment of inspiration hit: I don’t care about all the domains, just the domains that people visit. Who knows what domains people visit? The DNS servers! Now it was just a question of trying to coax the information out of the DNS servers. Thankfully, PaulDotCom Security Weekly came to the rescue: They have been talking about getting information out of DNS servers during penetration tests and a simple non-recursive DNS lookup on the local DNS server can tell you if someone queried for the host recently. A couple of quick experiments to verify this fact on my work’s main DNS servers confirmed this fact, and I set to work.

My first attempt was a simple script to take a pre-chewed version of the ZeuS Domain list, feed it through dig and pipe the output through grep. It worked, but I wanted something a touch more automated. Over the next couple of nights on the train, I whipped up a tool to automate the process a little more. The resulting tool is the ZeuS DNS Scraper. It’s a simple script written in Perl and should work straight out of the box with the default modules included in a Perl distribution.
Running the Script

Running the tool is fairly simple, there are only 4 options: –server, specifying which server(s) to query, –file, specifying where to put the downloaded ZeuS Tracker block list (defaulting to /tmp/ztbl.txt) , –download/–nodownload which specifies whether or not the script should attempt to download the block list, and –debug, which specifies the verbosity of the script.

A typical command line would be:

perl –server –server

Which would download the block list, and then proceed to query and for each entry in the block list. You can specify as many as many servers as you like, however, the block list often hovers around a thousand entries, so each additional server adds another thousand or so queries.

Alternatively, once the list is downloaded, the script will download the block list only if the local copy is older then 60 minutes, (don’t worry it doesn’t update that frequently). You can also specify that the script doesn’t download the list again with the –nodownload option:

perl –server –server –nodownload

You can also turn on debugging with the debug option, which will display every step in the process:

perl –server –server –debug

Interpreting Results

When the script is run in default mode, a ‘.’ will appear after each query, while in debug mode it will display the result of the query and whether or not it found an entry.
What You Want To See

NNNN queries made, 0 entries found! Hooray!

In this example, NNNN would be the number of queries sent, remember this increases which each additional server you need to query, and it has found 0 entries, indicating that the DNS servers queried have no cached entries for any of the domains. Congratulations, pat yourself on the back and grab yourself a nice frosty beverage from the refrigerator.
What You Do Not Want To See

NNNN queries made, 4 entries found. Uh Oh.
W.X.Y.Z has an entry in it’s cache for
W.X.Y.Z has an entry in it’s cache for
W.X.Y.Z has an entry in it’s cache for
W.X.Y.Z has an entry in it’s cache for

Well, crap. This time the beverage you need is probably kept in your flask. NNNN is the number of queries the script made and the “4″ in this example is number of results found. In this example, “” was cached with two separate addresses, while “” and “” both have one apiece. The W.X.Y.Z in the above example is the DNS server that responded, and the 10.X.X.X addresses are the IP addresses that the DNS server responded with. These IP addresses are what you are interested in.
My DNS Servers Have Cached Entries! Now What?

This is where some good old detective work comes in. The presence of the cached entries on your DNS server only means that one of the clients on your network asked for the entry in question. Normally, it’s time to start plugging IP addresses in your firewall logs to see who’s been visiting them. Then it’s time to start cleaning.

Now, obviously, this sends a boat load of queries in a very rapid fashion to DNS servers. Make sure that your DNS server and your connection can handle the load and don’t run it against DNS servers that you do not have permission to do so. Also, some of the DNS entries have small enough TTLs that they may expire quickly, meaning that even if the script comes back clean, there could still be infected hosts.

I’d just like to say a big thanks to the folks over at for hosting the ZeuS Tracker. It’s a handy tool and it’s invaluable if you’re running even a moderately sized network.

Source and more info here :

Powered by HaxTor | CopyWrong © 2011