IGMP membership query

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
IP Version 4, Header length 24 bytes, (6 32 bit words)

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
0xc0 = 1000 0000 Type of service  ECN capable Not ECT
0x0020 Total length  = 32 bytes
0X0000 IPID  

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
0X40 = 0100 0000 FLAGS = DO NOT FRAGMENT
0X00 = NO FRAGMENT OFFSET
0X01 = TTL OF 1

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
0X426D HEADER CHECKSUM - DID NOT VALIDATE
0Xc0a80101 SRC IP 192.168.1.1
0xe0000001 DEST IP 224.0.0.1 MULTICAST

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
0X9404 = 1100 0100 IP OPTION - ROUTER ALERT If the Router Alert option is not set and should be set with protocol using the Router Alert, (RSVP or IGMPv2), will be adversely affected since the protocol relies on the use of the Router Alert option to more closely scrutinize the packet.

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
0X11 MEMBERSHIP QUERY
0X64 MAX RESPONSE TIME = 100 DECIMAL TENTHS OF A SECOND 10SEC
0XEE9B HEADER CHECKSUM - CORRECT

46c00020000040000102426dc0a80101e0000001940400001164ee9b00000000
MULTICAST ADDRESS

IPv6 DNS query

60097aef004b11fffe800000000000006e4008fffe91dd48ff0200000000000000000000000000fb14e914e9004bf4df0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001

IPv6 Header
60097aef004b11fffe800000000000006e4008fffe91dd48ff0200000000000000000000000000fb

Version,                    Traffic class,          Flow label
6                   00       97aef
NOTE: anything other than 0x00 for traffic class would bear investigation

Payload length, Next Header,    Hop Count
004b,(75)  11, (UDP)  ff,(255)

Source address: (abbreviated to fe80::6e40:8ff:fe91:dd48)
fe800000000000006e4008fffe91dd48

Destination address: (abbreviated to ff02::fb)
ff0200000000000000000000000000fb

Any DNS query for a name ending with ".local." MUST be sent

to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB). DNS top-level domain ".local.", any fully

qualified name ending in ".local." is link-local, and names within

this domain are meaningful only on the link where they originate.

UDP Header
14e914e9004bf4df
Source port 5353 to Destination port 5353

DNS 
0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
Transaction ID 0x0000 Flags 0x0000 (Std Query)

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
2 questions

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
0 answers, 0 authority, 0 additional

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
Office jet pro 8600 [C6AC53]._ipp._tcp.local_
0x1b = 27 length of label, 4f = O, 5d = ]

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
            04     p p04       p
0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
                                05 l o c a l00

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
TYPE 33 Server Selection, (SRV) 0x21 = 33
CLASS 0x80 = 1000 0000 (QU Question is true). Multicast DNS defines the top bit in the class field of a DNS question as the unicast-response bit.  When this bit is set in a question, it indicates that the querier is willing to accept unicast replies in response to this specific query, as well as the usual multicast responses.  These questions requesting unicast responses are referred to as "QU" questions, to distinguish them from the more
usual questions requesting multicast responses ("QM" questions).

CLASS = IN

0000000000020000000000001b4f66666963656a65742050726f2038363030205b4336414335335d045f697070045f746370056c6f63616c0000218001c00c00108001
Pointer c00c, Type 0x0010 (16), TXT or Text Strings, CLASS 0x8001

DNS Query Response Decodes

I am getting comfortable doing this again, trying to build up speed. 

450000450a860000ff112d6bc0a80165c0a80101 0x11 UDP
ce2300350031302d Destination port 0x0035 = 53 DNS DEST
1b89 Transaction ID
0100 Standard Query
0001000000000000 1 Query
0665313135353101670a616b616d616965646765036e657400
   e 1 1 5 5 1   g   a k a m a i e d g e  n  e t00 ends label
0001 A record
0001 IN
=============================================================

45000055000040003911bde1c0a80101c0a80165 0x11 UDP
0035ce2300414ee2 DNS SRC
1b89 Transaction ID
8180 Standard Response
0001000100000000 1 Query 1 Answer 0 Auth 0 Addition
0665313135353101670a616b616d616965646765036e657400
   e 1 1 5 5 1   g   a k a m a i e d g e  n  e t00 ends label
0001 A record
0001 IN
c00c Pointer 0xc0, (12 bytes) displacement
0001 A record
0001 IN
00000013 TTL 19
0004 Data Length
48f6a044 72.246.160.68

0xc00c pointer points here |
1b89818000010001000000000665313135353101670a616b616d616965646765036e65740000010001c00c0001000100000013000448f6a044

=================================================================
=================================================================
713a Transaction ID
0100 Standard Query
0001000000000000 Query 1 Answer 0 Auth 0 Addition 0
01640764726f70626f7803636f6d00
   d . d r o p b o x . c o m00 terminates string
0001 A
0001 IN

713a0100000100000000000001640764726f70626f7803636f6d0000010001

===================================================================

713a8180000100030000000001640764726f70626f7803636f6d0000010001c00c00050001000000a4000601640176c00ec02b000100010000002400046ca0acc1c02b000100010000002400046ca0ace1

0xc00e pointer points here     |
713a8180000100030000000001640764726f70626f7803636f6d00

713a ID
8180 Standard Response
0001000300000000 Query 1 Answer label 3 Auth 0 Addition 0
01640764726f70626f7803636f6d00
00010001 A IN
c00c Pointer to RNAME
0005 Type canonical
0001 IN
000000a4 TTL 164
00
0601640176 d.v
c00e pointer offset 14
c02b pointer offset 43
00010001 A IN
00000024 TTL 36
0004 RDATA Length
6ca0acc1 108.160.172.193
c02b Pointer to RNAME
0001000100000024 A IN TTL 36
0004 RDATA Length
6ca0ace1 108.160.172.225

====================================================================
====================================================================
01a301000001000000000000 ID 01a3 Standard Query, 1 Question
036c6f670a67657464726f70626f7803636f6d00 log.getdropbox.com
00010001 A IN

====================================================================
Let's do some labels. Very clever how the label length becomes the dot.
====================================================================
036c6f670a67657464726f70626f7803636f6d00 
03  log 0a getdropbox         03 com  00

0a67657464726f70626f7801760764726f70626f78c01b 
0a  getdropbox        01v 07 dropbox       pointer


036c6f670a67657464726f70626f7803636f6d00
03 log  0a getdropbox         03 com  00

066e732d37373309617773646e732d3332036e657400
06   ns-773   09 awsdns-32        03 net  00


11617773646e732d686f73746d617374657206616d617a6f6ec01b
11   awsdns-hostmaster              06 amazon     pointer   

DNS AAAA Query Response Decode

DNS Query

This is the Wireshark display of the IP packet containing a DNS query. The tenth byte, (often called byte 9 from offset zero by geeks), contains the embedded protocol.

It is a hex 11 or 0x11 which is 17 decimal. Three common embedded protocols are:
0x01 = ICMP
0x06 = TCP
0x11 = 17 decimal = UDP. This packet is UDP.

This diagram shows the fields in the IP Header. The protocol field is highlighted.

The next highlight is the UDP layer. It starts immediately after the IP layer ends.

The first two fields are the source and destination port, they are 16 bit fields. Source is 0xccc4 and Destination is 0x0035. 35 hex is 53 decimal, this packet is destined to go to a DNS server.

The next highlight is the DNS query. It starts immediately after the UDP header ends and is decoded from the beginning to the end.

Below we have a DNS Packet Header diagram. You can get the SANS TCP Cheat sheet here, it will be much easier for you to download, print it and use it as a reference.

The first field is the Query ID sometimes called the Transaction ID. This 16 bit field uniquely identifies this query. When the response comes back we expect it to have the same Query ID. In this case it is 0x9332, which again, means nothing except that it is assigned to this query. The next query from this host will be a different value. On this Macintosh client it will be a very different value.

The next field is also 16 bits and it is called the flags. There are ten different flags as you can see from the header diagram. The value of the field is 0x100 and as Wireshark says, it is a standard query.

This is followed by four 16 bit fields. Query count, Answer count, Authority record count and additional records count. The highlight below shows 0x0001 which is the question count, the sets of three 0x0000 cover Answer, Authority and Record.

The name of the system the query wants to look up is log.dropbox.com. The query name or QNAME begins with 0x03 and ends with 0x00. The 0x03 says there are three labels:

• log
• dropbox
• com

0x00 is always the end of the QNAME.

We can use an ASCII table to convert the letters from hex to ASCII. The first byte in the QNAME is 0x6c which is an ASCII "l" and the last, (just before the 0x00), is 6d which is "m".

Two remaining fields to go, they are TYPE, (or QTYPE), 0x001c or 28 decimal, the client wants an IPv6, or AAAA, or "QuadA" name. This is becoming more common as the use of IPv6 is increasing. One other very common QTYPE is 0x0001, which is the A record, or IPv4 record name.

The very last field in this packet is CLASS, (or QCLASS) 0x0001. This is very standard, I have never seen a DNS query with anything else. It means this is an Internet query.

DNS Response

Here is the response. We are going to ignore the IP and UDP headers and jump right into the DNS response.

Responses, while quite similar to Queries are a bit more complex, but let's start with the easy parts. The first 16 bits 0x9e32 is the Query ID sometimes called the Transaction ID. This 16 bit field uniquely identifies this query. When the response comes back we expect it to have the same Query ID. In this case it is 0x9332 which it does.

The second 16 bit field is the flags, 0x8180, which in binary is:
10011000. The first 1, (on the left), indicates this is a response, the second, recursion is desired, the third is recursion is available.

Flags in a standard response

The next four fields: 0x01, 0x01, 0x01, 0x00, 1 query, 1 response, 1 authority, 0 additional records.

This takes us to the query. This is the same string as the query. Note that like the query it begins with 0x03, (there are three labels), log, getdropbox, com and then it ends with 0x00 end of labels, 0x001c, this is a TYPE, (or QTYPE), IPv6, or AAAA, or QuadA query. Finally the last field in the query is 0x01, CLASS, (or QCLASS) is Internet.

Query section of response mirrors original query

Easy, so far. Now the response resource record. There are six fields:
NAME: 0xcooc converted to binary 1100 0000 0000 1100. When the first two bits of the NAME are 11 it means we  have a pointer with a value of 12 decimal, (0x0c)
TYPE: 0x0005 It will be a Canonical name
CLASS: 0x0001 Internet or IN
TTL in seconds: 0x0000 09c0 2496 seconds, 41 minutes
RLENGTH: 0x0017, (23 decimal)
RDATA: This is where we find the canonical name 12 bytes into the answer section: getdropbox.v.dropbox.com  The ASCII representation for hex 62 6f 78 is box. We do not need the domain since we already have it: com. We can terminate a name with a pointer and that will lead us to the authority record.

Authority Resource Record

We start with the pointer c0 in binary 1100, the two high order 1s mean the name will be treated as a pointer. The pointer offset is 0x1b = 27 decimal. 

NAME:
TYPE: 0x0006 Start Of Authority. (SOA)
CLASS: 0x0001 Internet or IN
TTL in seconds: 0x0000 0044 = 68 seconds
RLENGTH: 0x0045, (69 decimal)
RDATA: SOA has a defined format:
Primary NS Name of the Primary Master for the domain.
Admin MB The administrator's mailbox.
These are followed by 5 32 bit fields

• Serial Number
• Refresh interval  
• Retry Interval
• Expiration Limit
• Minimum TTL

Primary NS Name of the Primary Master for the domain (MNAME):
ns-773.awsdns-32.net, since we are switching from .com to .net we need to spell it out.
6e 65 74 = net and followed by 0x00 to terminate the label.

Admin MB  The administrator's mailbox.
Note: 0xc0 1b we terminate with a pointer to get the com.

These are followed by 5 32 bit fields. These are guides for other nameservers and since the SOA lists the primary name server this data is used by the secondary servers.

• Serial Number 0x00 00 00 01 = 1
• Refresh interval 0x00 00 1c 20 = 7200 seconds or 120 minutes for the secondaries to update the zone maps. 
• Retry Interval  0x00 00 03 84 = 900 seconds - 15 minutes, (time interval that should elapse before a failed refresh should be retried.)
• Expiration Limit  0x00 12 75 00 1209600 seconds (which is within the range recommended by RFC 1912 14 - 28 days) If this upper limit elapses, the zone is no longer considered authortative.
• Minimum TTL 0x00 00 01 2c = 300 seconds 5 minutes

Next-Generation Vulnerability Assessment and Management (NVAM) by Tasawar Jalali, MBA, CISSP, SCCP, CEH

(This paper was sent to me and I worked with the author a bit before posting it. Full disclosure, I do hold stock in Tenable)

  

  

Stop Building Silos

NG-VAM - A New Approach to Security

By Tasawar Jalali, MBA, CISSP, SCCP, CEH

Abstract

The emergence of a whole new world of cyberspace has, and is more or less like an alien territory today—where there are very few knowns—and mostly unknowns. In this era of interconnected and interdependent technology, the nature and definition of security are going through a fundamental transformation. The revolution in information security technologies is altering everything – from how we secure and design our defense in depth and how we respond to ever increasing threats. A cyber-security system – like any system is made of a number of parts that have the complex level of inter-connectivity and inter-dependencies, designed to achieve the desired goal. In spite of this inter-connectivity and inter-dependencies of these parts, there is currently no culture of a collective approach to identify, detect, respond and protect from the increasing threats. All technologies still tend to work in silos.

This paper is written for information security professionals who are responsible for developing and implementing security policies and managing risk. I have tried to address shortcomings and risks of operating in information silos and how such deficiencies can be addressed by Next-Generation Vulnerability Assessment and Management (NVAM) Solution.

Introduction

I will be surprised to see any small and midsize enterprise (SME) that does not have cutting edge technology in place to secure its assets. It's not uncommon these days to for such organizations to have state of the art security controls in place like Next Generation Firewall, IDP, IDS, IPS, NAC, PKI, SIEM's, VA Scanners, etc. All these controls work in isolation or silos without communicating with each other. Many organizations realized this problem early on.  To effectively combat network attacks, it was imperative for all such controls to work in conjunction with each other. This lead to a hyper growth of security information and event management (SIEM) market.

Although originally designed and built for compliance, organizations started using SIEM's for data aggregation and data correlation to track breaches and thwart information security threats. SIEM's help enable security teams to detect and respond to internal and external attacks by analyzing machine data streaming from security technologies, such as endpoints, servers, and networks.

Next Generation SIEM's like Splunk provide correlation searches that present a unified view of security across heterogeneous vendor data formats. Splunk does this based on search-time mappings to a common set of field names and tags that can be defined at any time after the data is captured, indexed, and available for an immediate search. This means that you do not need to write parsers before you can start collecting and searching the data. However, you do need to define the field extractions and tags for each data format before reports, and correlation searches will work on that data. These tags and field extractions for data formats are defined in their add-ons, but they pose a new challenge to already data fatigued SOC and IT teams. Organizations will require extremely skilled IT Security Engineers to implement such solutions, and this introduces data fatigue to already short-staffed IT and SOC's teams. Instead of relying on one individual, why not have a dedicated R&D take on this task and provide accurate and detailed reports with relevant information about security attacks and breaches.

Challenges

Despite having multilayer defense-in-depth architecture in place, organizations are experiencing many security breaches every year because of a failure in malware detection and inability to correlate data across the network. The volume of threats is so high that there is only one way to manage that firehose of information. In 2008, the year the Conficker worm infected millions of computers in more than 190 countries, there were estimated to be 1 million known viruses and malware [1]. It is now in the hundreds of millions. Counting has become meaningless as modern malware is customized, polymorphic, and often composed of multiple pieces of independent and unique malware. Ransomware variations have been doubling every year for the past two years.

The traditional reactive approach creates a "window of opportunity," often measured in weeks or months, which uses a distributed model, and the limitations are evident: every day tens of thousands of new signatures must be sent to each and every endpoint.  "The median number of days that attackers were present on a victim's network before being discovered was 146 days in 2015" [2]. Today, with nearly one million new malicious threats detected every day, even the best heuristics, a traditional model cannot keep pace.  The idea of maintaining a "blacklist" of all known bad software is simply not sustainable given these numbers.  The Canada Post example which included a .doc attachment that was detected by only four anti-malware engines (out of 56 checked) upon receipt, illustrates that organizations cannot solely rely on traditional antivirus for malware detection [3].

The growth of targeted attacks has only continued. Attacks today are focused, not opportunistic and driven by human interaction. Advanced cyber-attacks are not just about malware. They are about achieving objectives.

Just deploying top of the line security technologies that operate in silos and provide a dump of raw data into an already strained organization doesn't help to narrow the security problem, it compounds it. Gartner has it right. "Cyber threat intelligence needs to include much more than raw data"[4]. It requires rich contextual information, continuous monitoring ability and tight integration with Cyber Threat Intelligence (CTI).

Traditional defense in depth is not okay anymore. Current AV solutions and Firewalls are not detecting a good percentage of malware and viruses, and reasons are AV, and FW's were created in an era where attacks were widespread and spread across millions of systems. Today attacks are targeted and more focused and more sophisticated and seen on few end points and sometimes in just one organization. We need contextual information, which includes an understanding of the past, present and future tactics, and techniques and procedures (TTPs) of a wide variety of adversaries. It must also include the linkage between the technical indicators (e.g., IP addresses and domains associated with threats or hashes that "fingerprint" malicious files), adversaries, their motivations and intents, and information about who is being targeted. 

Who or what wrote the file before it was launched? What else was the system doing at that time? As the file may have appeared hours, days or even weeks earlier, answering those questions requires the ability to look back in time, or roll back the tape. Most attacks come from known vulnerabilities or stolen credentials.  The historical and live record is equally important to determine scope—the systems, users and configuration changes that are impacted by an attack. In most advanced attacks, there is rarely just one artifact, one file or one configuration change made by the attacker to establish persistence. They may have left multiple files, even if only one has executed. They may have jumped to other processes to steal credentials or infect other systems in your organization. Given any thread (e.g., a file, a user, a system), unraveling goes in both directions—tracing the activity to its source to identify the root cause, and following the activity to its destinations to determine scope.

Next Generation Vulnerability Assessment & Management (NVAM)

The new paradigm of Vulnerability Assessment and Management (VAM) changes the way Risk Management is achieved by providing the real-time data and necessary correlation needed to unravel and understand how an attack occurs and integrate Actionable Threat Intelligence to provide visibility to unknown zero-day malware and Advanced Persistent Threats (APT's). By viewing the historical activity that is captured on a centralized console, you can quickly determine the root cause.  For example, consider what happens when you discover a C&C traffic originating from your network. If you just terminate the process, re-image the machine, you have only addressed a symptom, not the cause. Who or what launched the process and how? What if there is a process running on your system that was not detected by your Anti-Virus or Anti-malware, which are heavily dependent on signature updates.

NVAM solution must monitor key indicators of compromise like Unusual Outbound Network Traffic, Anomalies in Privileged User Account Activity, Mismatched Port-Application Traffic i.e. DNS over port 80, Suspicious Registry or System File Changes, and DNS Request Anomalies/DNS exfiltration to name few. A key feature of VASM is the ability to correlate all this data from different Attack Surface Components in the environment like "channels, methods, and data items" [5]. For example Channels (e.g., sockets), invokes the system's methods (e.g., API), and sends (receives) data items (e.g., input strings), in real-time and ability to integrate actionable threat intelligence from multiple CTI providers. Threat intelligence combines advanced malware analysis with deep threat analytics and content to empower security teams to defend proactively against attacks and malware outbreaks.

Effective NVAM solution must have following five characteristics:

1.     Identify both types of attack vectors (Exploit driven attacks and unknown/zero-day exploits)

2.     Eliminate silos by data aggregation

3.     Capture Forensic info of attacks

4.     Passive and non-intrusive monitoring

5.     Integrated, timely and actionable CTI

Recommendation

As an attacker to perform a successful attack, you have to go through a list of steps, and you have to be successful in each and every step. For example, the first step might be getting vulnerability exploit into an organization and second phase is exploiting that vulnerability and then maybe downloading malware, install malware, and establish C&C. You need to stop an attacker at one of these steps to foil entire attack, and each of these opportunities where we can halt the attack is called a kill point and set of these kill points is known as the kill chain.  To offer most effective kill chain, we must have a way to aggregate and correlate all the relevant information and data in any given environment.  In my research of different technologies available to assess and manage risk, I evaluated several vendors that included Qualys, Rapid7, and Tenable. All of these vendors have their strengths and weaknesses but to keep this paper brief, and how it addresses cybersecurity challenges faced by organizations that operate in silos, I chose to analyze Tenable Network Security solution.

Tenable Network Security transforms security technology with comprehensive solutions that provide continuous visibility and critical context, enabling decisive actions to protect organizations. Tenable solutions can help can eliminate blind spots, aggregate data, prioritize threats, correlate data with Cyber Threat Intelligence(CTI), and reduce exposure and loss, allowing you to eliminate the silo mode of operation and enable better vulnerability assessment and risk management.

Tenable's SecurityCenter Continuous View™ (SCCV™) offers a true continuous network monitoring platform. SCCV provides the broadest coverage of network environment, the deepest detection of vulnerabilities, misconfigurations, malware and real-time threats, the most advanced analytics, and Assurance Report Cards (ARC) that help CISO's map Security Policy of an organization to an ARC. Information Security Policy is a set of rules enacted by an organization to ensure that all users or networks of the IT structure within the organization's domain abide by the prescriptions regarding the security of data stored digitally within the boundaries the organization stretches its authority. Security Policies help organizations to engage employees, provide visibility in who does what and when, prioritize risk and address threats. Security policy which consists of several elements can get very complex to implement and maintain in a large organization. ARC's provide a quick and easy way to measure whether Security Policy is effectively implemented. 

In fact, Defense Information Systems Agency (DISA) chose SCCV as the Assured Compliance Assessment Solution (ACAS) in 2012. SCCV was selected by DISA because it met DISA's requirements for a fully-integrated vulnerability assessment platform offering. SCCV constitutes of five major components that work in tandem to gather and analyze data across the entire organization.  These are listed below:

1.     Nessus Scanner

2.     Nessus Agents

3.     Log Correlation Engine

4.     Passive Vulnerability Scanner

5.     Connectors

The "Nessus" Project was started by Renaud Deraison in 1998 to provide to the Internet community a free remote security scanner. Nessus is a remote security scanning tool, which scans a computer and raises an alert if it discovers any vulnerabilities that malicious hackers could use to gain access to any computer you have connected to a network.  It does this by running over 75,000 checks (Plugins), testing to see if any of these attacks could be used to break into the computer or otherwise harm it.

According to surveys done in 2009 by sectools.org [6], Nessus™ is the world's most popular vulnerability scanner, taking first place in 2000, 2003, and 2006 security tools survey. With over 10 million downloads since its inception, Nessus is the most popular vulnerability assessment technology in the world.

Tenable Network Security realized that there would be devices that will not always connect to the network like remote users who are using laptops or desktops that will not always stay connected to the corporate network. Nessus Agents increases scan flexibility by making it easy to scan assets without needing ongoing host credentials or assets that are offline, as well as enable large-scale concurrent scanning with little network impact.

Tenable's Log Correlation Engine™ (LCE™) aggregates host data and offers an ability to perform in-depth event correlation. This technology provides a high-performance scripting language named TASL (Tenable Application Scripting Language). There are 9500+ normalization rules (parsed events) out of the box, which can parse data from different sources like Cisco, Fortinet, Netscreen, Snort and other IDS's. LCE can also parse data from sources like Windows event logs that can send and parse data from OS/App logs, Checkpoint Firewall, Splunk Server, CISCO IPS and Events in Motion with TNM (Network Monitor). On top of that are more rules looking for things like continuous activity, statistical anomalies, etc.

Tenable's Passive Vulnerability Scanner™ (PVS™) eliminates network blind spots by continuously monitoring network traffic in real-time to discover active assets, identify cloud applications, and detect anomalous activity. PVS™ monitors and analyzes network traffic continuously to see new assets as they become active on the network. It also identifies an asset's OS, active applications, services, network connections, and associated vulnerabilities. This ability to eliminate network blind spots is unique, especially when compared to traditional vulnerability management which relies solely on active scanning to identify devices, services, applications, and vulnerabilities. Alerting on anomalies related to network traffic is useful for understanding changes in how your network is being used and allows for better situational awareness of which traffic is normal and which atypical sets of traffic are worth investigating to see if there is a security or a compliance impact.

Tenable also has a broad set of connectors, which allow integration with a broad range of vendors to build advanced workflows, simplify configuration management, query MDM solutions to look for vulnerabilities in mobile devices, centralized credential management, and integration with NAC solutions to isolate and quarantine a compromised device in real-time.

Nessus leverages several plugins that analyze millions of malware samples a month, harvested globally, and generates terabytes of rich, actionable content every day, to provide customers unmatched scale, coverage, and protection from global threats. For example, using Nessus plugin 74442 (Microsoft Windows Known Bad AutoRuns & Scheduled Tasks), SecurityCenter users will be able to pinpoint autoruns and/or scheduled tasks that are created by malware. Tenable continuously collects indicators of compromise (IOCs) from leading commercial threat intelligence vendors that enable you to identify emerging threats in near real-time without any additional licensing or configuration costs. You can automatically create a baseline of normal activity and includes built-in anomaly detection. By default, Nessus assesses all running processes against indicators of malware. Not just on Windows, but on OS X and Linux flavors too!

Some of the new techniques attackers have used to evade detection is to encrypt communications with secure socket layer (SSL) encryption. Perimeter security systems like firewalls, intrusion detection systems/intrusion prevention systems (IDS/IPS) or sandboxes are unable to inspect the encrypted traffic payloads. Once a host is compromised, the perimeter defenses are blind to such malicious attacks. "Gartner believes that, in 2017, more than half of the network attacks targeting enterprises will use encrypted traffic to bypass controls, up from less than 5% today" [7]. This new trend has led to the emergence of vendors like Venafi (www.venafi.com). Venafi specializes in securing cryptographic keys and digital certificates, and this solution alone can cost hundreds of thousands of dollars. Nessus has several plugins that can help you upkeep the security of digital certificates. For example, Nessus Plugin#72459 checks for Certification Revocation List Expiry (CRL), Plugin#83298 checks for SSL Certificate Chain Contains Certificates Expiring, Plugin#15901 checks for SSL Certificate Expiry and much more. If your organization can't afford the million-dollar solution, you might want to leverage built-in SSL health check in Nessus.

Summary

To summarize, security is a process that requires the collaboration of systems, knowledge and people.  No security organization should deploy "go-it-alone" solutions, and we are starting to see a new era of cooperation between companies, vendors and the security community at large. Security practitioners need to work together to raise the bar against our adversaries.  Security vendors must enable solutions that provide continuous monitoring and aggregate security data in an environment through collaboration, integration, and sharing of intelligence feeds. The future of security is collective defense, correlation, and integration with actionable Threat Intelligence Data and Continuous monitoring - that's what Tenable does the best.

References

[1] https://en.wikipedia.org/wiki/Conficker

[2] https://www2.fireeye.com/rs/848-DID-242/images/Mtrends2016.pdf

[3] https://www.redscan.com/assets/Q1-Trend-Report_Redscan.pdf

[4] https://www.isightpartners.com/wp-content/uploads/2014/07/iSIGHT_Partners_What_Is_20-20_Clarity_Brief1.pdf

 [5] Pratyusa K. Manadhata and Jeannette M. Wing, “An Attack Surface Metric” in IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. XX, NO. X, MONTH 2010

[6] http://sectools.org  

[7] http://www.infoworld.com/article/2984243/security/the-perils-of-free-digital-certificates.html

Why two queries for the same name?

First, a story.  For a SANS conference, I wanted a unique t-shirt with a packet on the back. I deliberately inserted an error and we had a prize on site for the first person to find and report the error. We did not announce the contest, we simply gave every attendee a t-shirt. 3rd day of the conference a conference worker came into the speaker ready room at lunch wearing the t-shirt. Judy Novak saw the shirt, cocked her head to the side, (let the reader understand), and finally said wait. She said three things, its UDP, its DNS, hey there's an error. Every instructor stood and bowed. We found a live termite in my office here on Kauai and have been cleaning things out before bringing in the orange oil guy and I found one of the t-shirts. There is no prize this time, but drop me a note if you figure it out :)

Now the packets. I like to look at the traffic on my home net from time to time. Today I saw my computer query for the same server name twice and thought it odd. Let's take a closer look.

The IP header, which is blue, starts off with 45 00 00 45 1d db 00 00 40 11. The 0x11 in byte 9 from offset 0 means the traffic is UDP.  At the end of the IP header we see my client, c0 a8 01 65, (192.168.1.101) is talking to the world famous IP address c0 a8 01 01, the most popular router address in the world, 192.168.1.1.

Next we jump into the UDP header, the first eight bytes after the blue. 88 85 00 35 00 31 84 25. 0x8885, the source port is 34949 and destination port is 0x0035, which is decimal 53 or DNS.

So, we consult the handy SANS TCP cheat sheet for a DNS header.

The blue is the entire DNS query:

Now to try to decode the Query ID/Flags. 28 54 01 00, (first four bytes in the blue).

0x2854 is the Query ID, any responses should reference that.

There is a flag set, so we need the flags field explanation from the cheat sheet.

Let's expand 01 00 to binary:

00000001 00000000

The first 0 on the left is the QR field, 0 = Query, 1 = Response, this is a query.

The only flag set is RD Recursion Desired. 0x0100 is often referred to as a standard query. 

Next, how many questions, answers, authority records additional records: 

00 01 00 00 00 00 00 00 breaks down to:

00 01 question

00 00 answers

00 00 authority records

00 00 addition records

On to breakdown our question! The blue is the entire question.

DNS questions have three parts: QNAME, QTYPE, QCLASS in that order. The QNAME has a length followed by the name.

The QNAME begins with 0c and ends with 00.

The 0c, (12 decimal), is the length from the start of the DNS query to the beginning of the question, (remember to start counting from zero).

The 00 says we have reached then end of the name.

0c 73 61 66 65 62 72 6f 77 73 69 6e 67 2e 67 6f 6f 67 6c 65 2e 63 6f 6d 00 

73 61 66 65 62 72 6f 77 73 69 6e 67 2e 67 6f 6f 67 6c 65 2e 63 6f 6d is the ASCII representation of safebrowsing.google.com

We are almost done, the last four bytes 00 01 00 01 make up the QTYPE and QCLASS.

The first 00 01 is the QTYPE. There are many types of Resource Records, but this blog post only covers two: 00 01 A Record and 00 05 Canonical or CNAME. 

The last 00 01 is the QCLASS is this case an Internet Record, often call IN.

Off goes our query!

And we get a UDP DNS response, a big one!.

28 54 81 80, the 0x2854 matches the transaction ID of our query.

0x8180 is sometimes called a standard response.

81 80 becomes
1001 1000
The first 1 on the left is the QR field, this is a response. The other 1 that is the low order bit in the high order nibble, (RD), is for Recursion Desired, but we also need to look at the next bit, RA or Recursion Available and notice that it is set, (the first 1 in the low order nibble. Let's go a bit further.

So we have decooded the Transaction or Query ID and Flags. Next is Query Count, Answer Count, Authority Count and Addition Records Count

28 54 81 80 00 01 00 11  1 question, 0x0011, 17 resource records

28 54 81 80 00 01 00 11 00 00 00 00  0 Authority records, 0 Additional records

The 00 11 indicates the 17 Resource Records

First we get to the question section of this DNS response. It should look very familiar.

Next we get to the Answer component. Answers are made up of:

NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA. The blue is one of the 17 answers.

NAME, this is the tricky part. It can be a LABLE like our query had OR it can be a pointer. The first two bytes of our answer are c0 0c. Sadly, this is not going to be a LABLE. How do we know, first we convert to binary:
c0 0c becomes:
1100 0000 0000 1100
The blue high order bits above are 11 and 11 means interpret as a pointer.

1100 0000 0000 1100
The 1100 above is the pointer value, decimal 12. For it to be valid it must point to a LABLE format and we already know what is 12 bytes into our DNS packet: safebrowsing.google.com.



TYPE. The blue box below 00 05 is the TYPE Canonical or CNAME. Essentially it is an alias. It is used to refer to safebrowsing.google.com.

CLASS Immediately after TYPE 00 05 comes CLASS 00 01 or Internet.

TTL, in blue, is the number of seconds we can safely cache safebrowsing.google.com. 00 08 83 d2 works out to 558034 seconds, (6 days).

RDLENGTH is immediately after the blue TTL above. That is 00 07, the length of our last field, RDATA.

RDATA, the 7 bytes are shown in blue. First we have the 02, no idea what that means. From the Wireshark ASCIIfication, we expect four of them to be sb.l, (73 62 2e 6c), and they are. C0 19 acts like a pointer, (remember the 11 as the two high bits and 0x19 is 25 decimal while is the displacement for the s in safebrowsing.

We will do this one more time to see if we can get an IP address.

NAME: c0 35 pointer to sb.l

TYPE: 00 01 A record

CLASS: 00 01 Internet or IN

TTL: 00 00 00 1d 29 seconds 

RDLENGTH: 00 04 (it is an A record, 4 octets)

RDATA: d8 3a c1 8e 216.58.192.142 and on and on we go with another pointer.

All well and good. But look, another DNS query:

Why am I asking the same question? It is a standard query 0x0100 and also for safebrowsing.google.com. This time the Query ID is 0x24f8. 

81 80 00 01 00 02 Flags are 0x8180, standard response. 1 question, 2 Answer Resource Records.

73 61 66 65 62 72 6f 77 73 69 6e 67 2e 67 6f 6f 67 6c 65 2e 63 6f 6d = safebrowsing.google.com

d8 3a db 03 - 216.58.219.14

Looks like lather, rinse, repeat.

Why did my computer ask the same question twice? My best guess is the short TTL of 29 seconds.

UPDATE: 5/13/16 I just noticed that rfc 2181 says: 

   "Resource Records also have a time to live (TTL).  It is possible for

   the RRs in an RRSet to have different TTLs.  No uses for this have

   been found that cannot be better accomplished in other ways.  This

   can, however, cause partial replies (not marked "truncated") from a

   caching server, where the TTLs for some but not all the RRs in the

   RRSet have expired.

   Consequently the use of differing TTLs in an RRSet is hereby

   deprecated, the TTLs of all RRs in an RRSet must be the same.

   Should a client receive a response containing RRs from an RRSet with

   differing TTLs, it should treat this as an error.  If the RRSet

   concerned is from a non-authoritative source for this data, the

   client should simply ignore the RRSet, and if the values were

   required, seek to acquire them from an authoritative source.  Clients

   that are configured to send all queries to one, or more, particular

   servers should treat those servers as authoritative for this purpose.

   Should an authoritative source send such a malformed RRSet, the

   client should treat the RRs for all purposes as if all TTLs in the

   RRSet had been set to the value of the lowest TTL in the RRSet.  In

   no case may a server send an RRSet with TTLs not all equal."

We clearly have two different TTLs and the second query was almost instant, is it possible my client rejected this DNS response. Wonder where that would be logged?

Stephen Northcutt is an advisor for the SANS Technology Institute and is chair of SANS Boston 2016.