Last Updated: 2013-10-02 18:42:15 UTC
by Johannes Ullrich (Version: 1)
As Adrien mentioned, we are trying to focus on "interesting" logs during October to celebrate "Cyber Security Awareness Month". For security professionals is is important to be aware of what your logs are trying to tell you. We are no looking for ground breaking new events, but just the "stuff you always wondered about what it meant".
I am starting today with a couple of DNS logs. If you haven't seen logs like this yet: You are not doing your job well protecting your network ;-)
I kept the logs as original as possible, but masked out a few IP addresses using "X" and some hostnames with 'example.com'.
1 - RFC 1918 Response
Oct 2 14:32:36 nsint named: client X.X.X.X#50873: RFC 1918 response from Internet for 22.214.171.124.in-addr.arpa
In this case, one of my internal hosts tried to reverse reolve the address 10.64.10.1. 10.0.0.0/8 is however reserved address space per RFC 1918, so this lookup just doesn't make much sense. The DNS server (named) is warning me about this lookup.
2 - FORMERR
Oct 2 14:16:01 nsint named: error (FORMERR) resolving 'ocsp.verisign.net/AAAA/IN': 126.96.36.199#53
One of my hosts tried to connect to ocsp.verisign.net. "OCSP" is a web service used to check if certifiates are valid. You will see connections to this host name from your browser as you visit some HTTPS sites. My network is dual stack, so hosts will attempt IPv4 (A) as well as IPv6 (AAAA) address lookups. Looks like Verisign doesn't support IPv6 and doesn't know what to do with AAAA queries so it is sending a format error (FORMERR) back. This caught my eye because of the security relevance of OCSP. But then again, there is nothing I can or have to do about this error.
3 - DHCP Dynamic Updates
Oct 2 14:27:25 nsint named: client X.X.X.X#38155: signer "dhcpkey" approved Oct 2 14:27:25 nsint named: client X.X.X.X#38155: updating zone 'example.com/IN': deleting an RR at laptop.example.com TXT
My DHCP server is configured to update DNS whenever it sees a new host. To authenticate and encrypt these updates, it uses a key (I call it "dhcpkey"). Since the request came from the DHCP server (masked IP address) and was approved, all is well and this is normal. I would be concerned if these requests get rejected and/or came from an IP address different then the DHCP server.
Here is a log entry for a denied update:
Oct 2 14:03:40 nsint named: client 10.5.0.254#53419: update 'lexample.com/IN' denied
In this case it turned out to be a misconfiguration of the respective zone. Remember: Watching your logs not only keeps attackers out, but also makes your network perform better!
4 - REFUSED
Oct 2 12:47:53 nsint named: error (unexpected RCODE REFUSED) resolving 'example.com/A/IN': 188.8.131.52#53
Here a name server I connected to to lookup example.com refused the query. Odd, as the domain was valid. Could be a misconfigured DNS server, or a network device (Anti-DoS?) interfering with the query.
Got any other DNS logs?
Last Updated: 2013-10-02 15:04:42 UTC
by John Bambenek (Version: 1)
In the last 24 hours, DomainTools reported to us that over 50 domains related to the US Government Partial Shutdown have been registered. About a third of those are partisan oriented, most of the rest are parked. During the same time period, ver 40 domains were registered relating to the Affordable Care Act (colloquially known as Obamacare). So far, no spam has shown up on either subjects which was surprising to many of us that monitor these trends.
While those specific data points are US-oriented, the lesson generally is not. Whenever there is a major event there is usually a corresponding uptick in new domains registered related to those events and spam campaigns. The advice to users is the same, don't click on random emails and if you want to do business online, always affirmatively type in the URLs of known entities instead of using email or website links. The federal insurance exchange website is healthcare.gov, for instance. Other sites proclaiming they are *the* federal exchange are likely less than honest, especially if they are anything other than a .gov.
What makes these campaigns successful is an uptick in media coverage and popular awareness, especially if there is a visual component. One of the most successful campaigns of this type was a spam campaign related to the capture of Osama Bin Laden and links the purported to be pictures or videos of the event. The Boston bombing is another example. What makes the potential for Obamacare related scams to work is stability of the new site combined with some confusion to the details of the new law. Where there isn't clarity, fraud is possible.
The awareness type for those that support users is that any time something like this happens is to review with users the same tips: don't click on links, go only to known websites and let them know online miscreants will use popular interest in subjects to infect them with malware.
bambenek \at\ gmail /dot/ com
Last Updated: 2013-10-02 04:16:32 UTC
by Mark Hofman (Version: 1)
Most of us are familiar with the "microsoft support" call. A phone call is received, the person states they are from "microsoft support" and they have been alerted that your machine is infected. The person will assist you by having you install a remote desktop tool such as teamviewer or similar (we have seen many different versions).
Previously they would install software that would bug you until you paid the "subscription fee". As the father of a friend found out the other day, when he received a call. They now install ransomware which will lock the person out of their computer until a fee has been been paid. In this instance it was done quite early in the "support" call so even disconnecting when smelling a rat it was to late.
The ransomware itself looks like it replaced some start up paramters to kick in the lockout rather than encrypting the drive or key elements of the machine. However for most users that would be enough to deny access.
So in the spirit of Cyber Security Awareness Month make this month one where you let your non-IT friends and family know two things. Firstly, BACKUP YOUR STUFF. Secondly, tell them "when you receve a call from "microsoft support", the correct response is to hang up.".