This is one of the few times when looking at SMBv2 you will need to use SMBv1 commands. The initial negotiation request will always be sent out as SMBv1. It makes sense when you think about it, SMB does not have ‘backwards compatibility’, instead it relies on negotiating to the lowest common denominator.

To find the initial request use the following SMBv1 command

smb.cmd == 0x72

If the server responds using the SMB2 protocol a second negotiation is sent. This time on SMB2.

To see all SMB2 negotiation and responses you will need the following command

smb2.cmd == 0

During the negotiation you are able to see what capabilities the server has, what the client has and any negotiated authentication/encryption technique. You can also see the time that is set on the server, as well as its Timezone.

Why do I care?

There is a lot of useful information in here to help with Server identification and potentially geographical location. Looking at the capabilities of the server can with OS identification; is it a Windows box, a NAS etc.

Using the SMBv1 filter you are able to see the first communication between the two devices, aiding in timeline building.

Using SMB it is possible to retrieve data that is typically only expected when carrying out host based forensics. The MACB (Modification, Access, Change and Birth) data is sent across regardless of if a file is accessed or not.

With SMB v1 this was a bit of a pain to find, the Wireshark filter required was

smb.cmd == 0x32 && smb.trans2.cmd == 0x0005 && smb.qpi_loi == 1004

with SMBv2 it is simper

smb2.create.action

This command can have a value added after it, however in its current state it is the equivalent of having “exists” on the end.

The output looks different to SMBv1 as you would expect, but the data is the same.

SMBv1

SMBv2

With SMBv2, the simple addition of a column provides us with the path detail that was removed from the SMBv1 command

Why do I care?

As you can see from the screenshots, this shows what files were accessed. If you look closely at the second screenshot you can see that a file named “~$resource-to-share.xlsx” was referenced. When you look at this you can see it talks about a file being created on the share. This tells us two things.

We can see when files are uploaded to an SMB share

The Excel file was opened on the local machine as that is the temporary file Office creates to allow auto recovery on crash

The above is from a Windows Server 2016 VM I have in my home lab, but I have also tested this on my NAS and got the same type of results.

If you want to play along at home, the sample PCAP I will be using for SMB2+ is here, the SMB v1 PCAP is not something I can give away sadly.

Tree Connect Request/Response

When the SMB protocol connects to a resource it needs to know exactly what is there. This is where the OS retrieves the share name. If the share name has a ‘$’ at the end (like IPC$ or C$) this means the share is hidden, typically the system will create hidden shares, but users can also create them. Hidden means that if you were to go to the root of the resource (\\servername\ ) you would not see the hidden shares listed.

Tip. If you are monitoring SMB and see \\servername\exfil$…. might be worth looking at!

SMB v1 looks like this:

SMB v2 on the other hand looks like this:

So what’s the difference?

As you can see there are some cosmetic changes, the ‘andx’ part has been dropped. The biggest difference for me is the addition of the ‘SessionID’ details in v2, this now provides the requesting username* and the requesting client

In the Hex the Flags have been moved and v2 has less Flags. We can still see the path in the details pane.

*It is worth noting that the username is the one used to connect that share, not the one which is logged on locally. This can be entered when the share is initially created, or is prompted for when the user clicks on the link. Bear this in mind during investigations

SMB2 Header

The SMB2 Header will either be ASYNC or SYNC, you need to look this up from the flags. SYNC is the most common header as this can be in the form of a request or a response, where as a ASYNC header will be used for responses to requests processed asynchronously by the server.

Credits

The Credit Charge field appears to be either 0 or 1 and will only be 0 on protocol negotiation (initial communication) after that it will be set to 1.

Credits appear to be a way for the client to control the requests being sent in that session, providing the client has credits remaining, it can continue to communicate. You would expect to see the ‘Credits Granted’ = 1 if the server is answering a request.

NT Status

This will only be seen in responses and will give the status, or error, of the request. ‘STATUS_SUCCESS’ is as it sounds, and will typically be expected from a successful tree connection

Channel Sequence

Channel Sequence is explained by Microsoft as “In a request, this field is interpreted in different ways depending on the SMB2 dialect.”

…which is helpful…

Reserved

This is reserved… no seriously, don’t use it. SMB’s version of the ‘evil bit’?

Command

The command section will have one of the following commands within it:

Flags

The Flags field will be populated thus:

Chain Offset

Microsoft refer to this field as “NextCommand” and say it must be offset from the first header. However every instance I have seen has this set to 0x00000000

Message ID

This field is very useful as it identifies individual messages (conversations) within the SMB protocol. If you follow stream on an SMB conversation in Wireshark you will see a large number of messages, which can get confusing, this way you can see what the request and outcome was to each request.

Use the following filter in Wireshark

smb2.msg_id == ##

Where ## equals the message ID you want to track

Process ID

The default value is 0x0000feff

When it is not set to default (or 0x00000000) it can be used to manage broken connections. For example if the server sends a pending response the client can decide send a cancel request to the server to stop that particular message from consuming resource.

Tree ID

Another useful field, within the Tree Connect Response this field will contain an identifier to a share. This means if you are investigating a lot of SMB2 traffic across many shares, this will help you keep track of a specific one.

smb2.tid == <hex value>

Where <hex value> is the hexidecimal value displayed in this field

Session ID

The Session ID will help track a specific user session, similar in usefulness to Tree ID, it will allow you to see if a new username was used. It can also show failed logon attempts, as the value will change with each new authentication attempt.

Signature

This field will be set to 0 if the Signing Flag is set to not signed.

This appears to be used for verification and encryption. Most likely to be seen in environments that utilise SMB encryption

Summary!

We have covered SMB v2 SYNC header. This was mostly based on Tree Connect and Response, as this was the original post!

Why do I care?

If you need to look at SMB on any modern system there are some good artefacts in the SMBv2 header.

SMB

There are currently 3 major versions of SMB version 3 is quite new (2012) and has been implemented on the latest versions of Windows (8, 2012), Samba 4.1+ and macOS 10.10 Yosemite.

I say ‘quite new’ as it takes a while to phase in new protocols like this. At the time of writing I would expect most organisations to be running MS Server 2008 to Server 2016.

The above chart (from here) shows that as different OS’s communicate they drop to the lower version of SMB to enable transfer. From this we can extrapolate that MS Server 2016 will use v3+ with MS Server 2012 upwards.

SMB History

There is a lot out there about SMB History, but the basic takeaway is Micrsoft needed something that allowed the sharing of resources across a network. They were beaten to it by a couple of vendors, but as MS had pretty much cornered the market… well you can guess the rest 🙂

If you want an in-depth history, there are many sites on the ‘net that provide that, I would only be copy/pasting someone else’s work.

SMB v1 was released mid 90’s

SMB v2 was released with Vista (mid 2000’s) and provided a host of updates both security and operations

SMB v3 was released with Server 2012 and is sometimes referred to as SMB2.2. This is most relevant to us when looking at Wireshark filters. There is no filter ‘smb3’ only

smb || smb2

SMB !=CIFS

Well technically SMB2+ != CIFS.

CIFS was a term used for NT4 operating systems, it does not apply to later versions of SMB.

Why do I care?

SMB is the way a Windows environment would open files on a remote server. This means you can actually see the username that opened the file!

Imagine having full packet capture when you get a phone call explaining some sensitive information has just appeared on Pastebin. The management are losing their shit and you could potentially be the one to answer the big question; whodunnit?

I recently created a cloud based virtual machine, the purpose of this will be for an HTTP honeypot, but I thought first off I would leave it for a few days to see what happened. This VM has only port 22 open and the IP has not been published anywhere.

Within 30 minutes the brute force attacks had started!

I decided to keep an eye on what usernames were being used and realised that a lot of people are still setting up their systems with ‘root’ or ‘admin’

Even if your password, or key, are super secure and you are 100% confident they will never be guessed/cracked, there is still logic in creating weird and wonderful usernames. Mine for example is made up of items I saw on my desk, I then saved that username to LastPass for reference.

What logic you ask? Well let me create a scenario….

You create a server and have root as the only user (silly person). You give it a 32 character random password and sit happily in the knowledge it can’t be brute-forced. You then look at your auth log and see several thousand attempted root logins per day, as per below (screenshot after 48 hours). Two questions:

Are you under attack?

Yes.

Are you under a targeted attack?

No idea!

Now let’s keep the same scenario except the username has now been changed from ‘root’ to ‘HOS_Desk_Envelope’, this makes creating an alert so much easier. With only a single failed instance you can say that someone has a higher level of knowledge than they should about your build. Have you had an OpSec leak? Is your username on Pastebin? Or did a staff member simply type an incorrect password. Let’s go back to our questions:

Are you under attack?

Yes.

Are you under a targeted attack?

No.

Such a simple change provides such a huge benefit. No one, company or individual, should be using generic usernames in internet/production systems.

For reference, here are the top 50 usernames along with how many times they were tried in a 48 hour period on a server that isn’t advertised anywhere.

This writeup is to explain how to get the answer (flag) to the Forensic Challenge named “Poor Internet Connection”

I will not be posting the flag here as I am giving you all of the instructions to get it yourself!

You start by downloading a PCAP file which has 3 TCP streams. If you do a search for “flag” in Wireshark (select string and search in packet bytes) you get 2 hits. One for flag.txt another for flag.zip.

One common rabbit hole is to assume the flag.txt file is in flag.zip file. It’s not. This may or may not have thrown yours truely for a little while…. we won’t discuss that.

Basically ignore flag.zip and look at flag.txt.

You will need to carve the zip file out manually, this may seem daunting, but it’s really not too hard. First find flag.txt, you will see packet 1139 (left hand column) is highlighted. You can follow the TCP stream (right click menu on the packet) and you will see that there is a lot of text that doesn’t make a lot of sense.

In order to find the file you need to view the Hex of the stream (bottom of TCP Stream screen, change the drop down from ASCII to Hex Dump).

Next we need to know what the header and footer of a ZIP file is….. Google time.

This page shows that the header should be 50 4B 03 04 14 and the footer should be 50 4B 05 06 00 so do a search for the header within the TCP Stream Hex Dump window.

If you don’t get a hit, start deleting characters, the way Wireshark displays the header means there could be a new line or double space in the header, and the search function isn’t that bright

When you get a hit, confirm that ‘flag.txt’ is just below the line you have highlighted. Then look for the footer (either manually or search).

Now for the irritating part, copy out the selection from header to footer and you will notice you get the byte offsets and text conversion too. With a small file you can manually remove these with a text editor, if not use your imagination 🙂

Paste the hex in a hex editor such as HxD and then save the file as a zip file (just name it as one). If you copied only to the footer then you can simply open the zip file, if not it will need to be repaired first (which will look for the footer and remove the extra data).

You now realise that the zip file is password protected, shocker right? A quick way to look for files included in the PCAP is by going to File > Export Objects > HTTP this will pop up another window with all the files Wireshark thinks is included. Ignore the files with a number for a name (never did figure out what they were) and scroll to the bottom, you will see a file named “secret.txt”, extract this and you get the password for the zip file.

You now have all the information you need to get the flag for yourself 🙂

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.

Bit of a change from my typical security related posts. I was hunting around on my machine for a new blog post when I stumbled across a folder full of oddly named files. The files were named as their SHA1 hash value with no file extension.

I opened them in Notepad++ (too lazy to open a Linux VM…. shoot me) and saw they were image files. After I opened them in PhotoViewer I noticed they were the images I see when my screen is locked; Spotlight Images.

So if you are looking for a cool picture that you saw on your Windows 10 Spotlight, look no further than:

Often when analysing attacks, scans or just general traffic it is difficult to identify the specific tool or technique in use. This is simply because there isn’t a reference database for every tool.

So I thought I would upload a nice simple PCAP of OpenDoor Scanner so that if this is being used against you, you have the possibility of spotting it.

Quick disclaimer: this was used with no options, arguments or exclusions. This is the tool used with the default command line:

"python ./opendoor.py --url "http://privateIPaddress/"

One of the first things to note about this tool is that by default it only does “HEAD” requests. This only requests the header from that specific page and not the body (i.e. no data from the page; images, text etc). It also runs alphabetically, which is not uncommon, but certainly helps easily identify a scan.

The User-Agent field changes, in fact it does not appear to be the same for any two requests. This may be an attempt to avoid automatic blocking, or maybe just the author was a little bored 🙂

The ‘accept-language’ and ‘accept-encoding’ fields remain the same throughout. This is probably one of the best identifiers.

Analysing the PCAP

In order to see if you were affected by this I recommend the following filter in Wireshark:

http.request || http.response

This will show all requests (GET, HEAD etc) and all responses (404, 302 etc). You are looking for anything that is not a ‘404 not found’ response.

200 OK – Generally what the attacker is looking for, this means a page was delivered. Bear in mind however, some devices show a custom 404 page, meaning a 200 response is shown, but it is not the page the attacker wants.

30x – Typically a 302, however could be 301, 303 or 307. This will be in place if the page has moved, but may also redirect to a HTTPS version of the page. Watch what the responses are and work with the web dev team to decide if any action needs to be taken. I have seen a 302 give an IP of the internal interface of the webpage. While this isn’t a critical failure, it’s not good.

403/404 – Unauthorised and Not Found respectively. 404 is by far the better option. 403 gives the attacker hope the page is up, but not available to them right now. They may try to pivot back at a later attack stage.

418 – I’m a Teapot. If your server responds with this; either your web dev team have a sense of humour or you’re already screwed 🙂

I hope this helped. Please leave a comment with any constructive feedback and pop back anytime!