Recently I have been conducted a lot of interviews for SOC Analysts; one of the questions I ask is as follows:

You are reviewing your DNS logs and find an answer to a DNS query which shows rabbitcoldhotel.evil.com on <AnyExternalIP> with a TTL of 600. The initial Query came from 10.3.22.45.

• Does this seem suspicious (no points for ‘evil.com’)
  • Why?
• What would your next step be?
• Where else could you look for information? (assuming you had access to any internal log source you needed)

From this I am expecting the candidate to talk me through their thought process, if they say this is innocent and give a really good reason why, I will be happy to debate and ask further questions, but they would not be ‘wrong’.

However

What I am finding is people do not understand DNS TTLs. So, I thought perhaps I am being a bit mean as some of these people were coming in for a junior role, so I decided to break the question down into starter questions:

What is an IP TTL, how is it generated and why is it important?

What is the difference between an IP TTL and a DNS TTL?

By asking these two questions first, I can decide whether or not to move onto the bigger question above. I have found however that many candidates do not understand TTLs at all!

So, let’s look at TTLs and then answer the first question last.

What is an IP TTL?

An IP TTL sits on the 8th byte offset of an IP header (if I just lost you, don’t panic, this bit is just for reference), as we can see from the header below (from http://www.securitywizardry.com)

If someone said that in the interview I would assume they either have a photographic memory or knew what question I was about to ask and had googled it; I just had to look it up myself 🙂

So, what is the point to the TTL field?

Well…. it pretty much stops the internet from DoS’ing itself. Routers are interesting devices when it comes to actual routing. If the router doesn’t know where to send the packet it has received it will quite often have a ‘route of last resort’ or ‘gateway of last resort’ or ‘default route’, the terminology isn’t important. Basically, if the router doesn’t recognise the destination network it will dump it out of this one and let another router worry about it.

This means in theory a packet could be sent forever around a load of routers that have no idea where the end network is. This was identified as an issue pretty early on, so some clever people decided that packets should be given a finite life span; a time to live. In the early days, this was measured in seconds (I believe the RFC may still say that… might be wrong… should really google… not going to though), however this was changed at some point to be ‘hops’. A hop would be each time the packet passed a routing device.

We now know that a TTL is the amount of ‘time’ a packet can live and that time is measured in ‘hops’. That is pretty much the first part of the answer.

How is it generated?

This is a little unfair, the question is not asking how does the operating system, or network stack write the value into the 8th offset, it is asking what generates the value that has been assigned. Not all TTLs are created equal.

The operating system in use will determine the TTL value there is a nice list over here

Why is it important? (to a network analyst)

It can aid in detection of an operating system and help to identify spoofing, is the short answer.

Imagine a 3-way handshake. The SYN comes in with a TTL of 60, you see your webserver respond with a SYN/ACK and a TTL of 128 and you see a RST come back with a TLL of 249. This implies that the IP was most likely spoofed in the first place, the different TTLs make up exhibit A and the RST on the 3-way handshake suggests the server was not expecting a SYN/ACK from you; exhibit B. (this is another interview question I have used).

How is an IP TTL different from a DNS TTL?

Short answer: IP TTL is counted in hops, DNS TTL is counted in seconds. IP TTL gives the life span of a packet based on how many routing devices it can pass. DNS TTL shows how long that DNS record can remain on your device.

For the purpose of this article all we need to know about DNS TTL is that it defines the lifespan of that DNS answer on your machine (device, whatever).

Why have a TTL on DNS?

Surely if google.com is on 172.217.6.174 it will always be on that IP? Nope. First off Google most likely has a whole load of IPs set up for ‘google.com’, this can be for load balancing (if too many people connect at the same time it shares the love across multiple IPs) for DDoS mitigation or for maintenance.

Imagine for a second the IP that google.com is hosted on falls down, after all it is only a router on the internet (probably more complex with a whole headache of architecture, but let’s keep this simple). So Google’s router has gone down, 172.217.6.174 is no longer responding to any network requests.

Now what? Well we don’t actually care that 172.217.6.174 is not responding, we care that google.com is not responding. As such a new DNS record can be requested that, for example, may say google.com is now on 172.217.6.175. But how does your device know to send out a DNS request? It already has an answer, and isn’t smart enough to know it’s not responding. A TTL value will mean you will automatically re-request the information when that time expires. You can also manually do it by clearing the DNS resolver cache, but this is about TTLs.

Back to the original question

To answer the first question we need to consider a few more things…

Legitimate sites will typically have longer TTLs to avoid overloading the DNS servers (or nameservers), there are exceptions to this! Sites that may be malicious could have shorter TTLs as this will allow the attackers to avoid bad reputations, blacklists and security researchers.

Does this mean a shorter TTL = evil? No, not at all. A short TTL can be used by dynamic DNS services for example. Malicious sites may also have long DNS TTLs. This is simply an indicator that something *may* be suspicious (not malicious, as currently there is nothing to indicate that!).

So the TTL value of 600, gives this DNS answer a 10 minute lifespan. That is quite short, but not outside the realms of legitimate. So lets put 2 points in suspicious, 1 point in normal (arbitrary scoring mechanism I know, but whatever works for you).

Next we look at the domain rabbitcoldhotel.evil.com. I could just have easily made it klulnvovvslvhsldf.evil.com (random text) but that makes it a little easier. This *could* be a new style of DGA (domain generation algorhythm) where the attacker is using dictionary words together in order to avoid the ‘random’ detection methods. It could also just be a person typing random words in. Evil.com doesn’t count, it could easily be Mom-and-Pops-Bakery.com. In terms of score; if it was random I would put 2 in suspicious, but as its weird I am not so sure. So 1 for suspicious and 1 for normal.

Finally (on the initial read) we see the internal IP. With current evidence 1 and 1 again for the score, we have no idea what that is.

So there we have our first answer, if that’s all you say I wouldn’t be reaching for the cheque book. What I then expect is some actual analysis, or steps you would take to carry out analysis.

Lets do this as a quick to-do list

• First and foremost, was this domain actually visited?
  • Some security devices will do DNS lookups of blacklisted domains, Firewalls are annoying for this as some only block IPs and do not know how to block domains. So will do lookups of domains you have told it are malicious.
  • Can you see proxy logs for this domain?
  • Get the IP from the answer and check Firewall logs
• Use full packet capture to confirm the HTTP response codes (can also be seen on proxy devices, but where is the fun in that)
  • If all the user got were 404 codes and no hidden content was delivered then high-fives all round and have a cup of tea. If however there were 200 OK, or redirects (301, 302) then more work is required
  • Full packet capture can also give the payload/malware of the page
  • Referer may shed light on how they got to that page
  • Look at browsing before/after do they paint a picture? Is this a lone request?
  • Does the user-agent match the other browsing? Could this be an already compromised host?
• Internal DNS logs can show the hostname of the local IP address
  • Is this a workstation or a downstream proxy?
  • Do you need more proxy logs?
• Did any other security appliances alert?
  • Correlation!
  • Network IDS
  • Host IDS
  • etc etc
• Open source int on rabbitcoldhotel.evil.com
  • Google it! It’s amazing how many people don’t do this.
  • Is it an IOC on malware analytical sites (malwr.com malwaredomainlist blogs?)
  • Any blacklists? What are they for
  • VirusTotal score? Needs to be more than 1 or 2, especially if you have never heard of them
  • URLQuery or URL2PNG to view the page (use with caution, if you even slightly suspect inappropriate/illegal images skip this step) does it match the theme of the main page (evil.com)
  • HTTP Viewer by Rex Swain, works as a proxy to view the source code of the page
  • CentralOps (or other similar tools) to view the owner of the domain and IP
• Speak to the user, or get local manager to speak to them
  • Do they recall visiting the page
  • Have they received any unusual emails
  • Any other information you can get

I could probably add more, as can you. This list does not need to be exhaustive, it just needs to show that you do not take information at face value. Analysis is all about questioning what you see. Just because a snort signature fires does not mean something is malicious, and just because your anti-virus doesn’t pop on a downloaded flash file doesn’t make it safe.

I hope this helps some people, if I am interviewing you, you can tell me that you have read this, as that answers a later question regarding research 🙂 This field should be a passion and should be fun (weird right!). I enjoy it and I enjoy the challenges it brings everyday.