Sled Meta Blog

Home » Sled Meta Blog

Analyzing a Spear Phishing Email

in Incident Response by Mike Spohn Leave a comment
About every week or so I receive one of those obvious Phishing Emails telling me a package was not deliverable or some such foolishness. After being very careful not to click on the attachment, I typically permanently delete these Emails. When I got another one of these Emails a few days ago, my curiosity got the best of me, so I decided to figure out how the cyber-punks build these social engineering attacks, and how they work.

I documented my analysis in a Research Paper, “Analyzing a Spear Phishing Email.” You can download the report here.
The findings of my research are summarized below:

1. The appearance of the Phishing Email is very primitive, alleging the postal service could not deliver a package. The from Email address was completely unrelated to the signature line. (k(at) karastel,ru, Eugene Lee.

2. The weaponized payload was a JavaScript file that has “.doc.” in its name, embedded in two zip files. This means the recipient has to open two zip files and click on the JavaScript file for the bad guys to win.

3. The JavaScript file uses Microsoft’s ActiveX framework to create an Object to connect to the Internet and download a malicious dropper JavaScript dropper file. This script is run using an Eval() statement. The script also connects to the Internet and downloads a malicious Window PE file.

4. The miscreants compromise legitimate web sites to host the malicious binaries. The scripts contain multiple dowload URL’s to protect against detection of compromised servers.

5. The Malicious PE file is a Cerber Ransomware binary that encrypts files in the logged on user’s Documents folder, and any attached USB devices.

6. There is a sophisticated web site on the DarkNet that instructs a victim how to obtain BitCoins and pay the ransom.

7. The cyber-punks who send out these Emails bank on economies of scale. If they send out 1 million weaponized Emails, if they have a 5% hit rate – that is 50,000 victims.

8. The ransomware problem is not going away anytime soon. In fact, evidence suggests the cyber-crimnals are getting more aggressive in their tactics. Not only are they encrypting files, they are also wiping out the master boot record (MBR) on compromised systems preventing them from booting.

We are continually adding enhancements to the PacketSled Platform to identify advanced ransomeware compromise techniques.

Packetsled UDP and TCP fallback analyzers

in Incident Response by Leo Linsky Comments are off
There are hundreds of protocols that we need to see in detail to have a clear picture of our customers’ networks, and we have developed a suite of proprietary analyzers to address these. There are hundreds — or even thousands — more relevant protocols and services which we need to identify, but which are not significant enough on their own to warrant their own custom protocol analyzers. Added together, however, these protocols become major obstacles to network visibility and security.

Interestingly enough, this problem is not unique to networking — it’s a statistical phenomenon with numerous socioeconomic implications. For example, the disease advocacy group Global Genes has estimated that more than 300 million people worldwide are living with one of the 7,000 diseases they define as rare in the United States. That’s almost 5% of the world population living with a “rare” disease. And yet, treatment for each is wildly different, so it’s less productive and less lucrative to investigate each of these rare diseases.

Unfortunately, there isn’t a universal ‘rare disease treatment,’ but at Packetsled, we *have* developed a ‘universal treatment’ for unidentified UDP/TCP protocols and services. For flows in which we haven’t associated a high level of metadata, we capture key excerpts from the exchange to allow for analysis by Bro scripts or our platform, which, if interesting, can be used to pull the rest of the flow from our network data recorder.

The entries we find are frequently plaintext, or provide protocol preambles that make their nature obvious, such as the potential WinRM vulnerabilities discussed here: https://packetsled.com/analyzing-unknown-protocols-finding-a-piece-of-hay-in-a-hay-stack/

Here’s an example of a UDP log showing a JSON protocol header (note that excerpt sizes are variable, and we could capture the entire JSON object here):
#fields ts      uid     id.orig_h       id.orig_p       id.resp_h       id.resp_p       excerpt excerpt_size    payload_size
#types  time    string  addr    port    addr    port    string  count   count
1486600189.506264       589bb7fd0000000000000003        172.16.0.118    17500   255.255.255.255 17500   {"host_int": 59724991715298692108921997512624305849, "version":         64      365
This is especially useful for IoT protocols, many of which we have fleshed out into more detailed, dedicated analyzers and many of which are facilitated in healthcare. Recent announcements from leading healthcare device manufacturers indicate that IoT is now being used with fetal monitors, electrocardiograms, glucose monitors, and tracking vital health information. We’ve even heard of pressure sensors being used to determine the ratio of empty hospital beds during disasters, such as floods and fires.

However, the thing to remember is IoT is still in a sort of infancy. Some established standards have been developed, but are not widely adopted. This includes communication protocols and methods of properly handling sensitive data. As personally identifiable data could be transferred using protocols such as HL7, it is highly recommended that a close eye be kept on these valuable data streams.

An example shown below:
MSH|^~\&|PIEDMONT||PriorityHealth||||ORU^R01|Q479004375T431430612|P|2.3|
PID|||001677980||SMITH^JOHN||19680219|M||||||||||929645156318|123456789|
PD1||||1234567890^LAST^FIRST^M^^^^^NPI|
OBR|1|341856649^HNAM_ORDERID|000002006326002362|648088^Basic                            Metabolic Panel|||20061122151600|||||||||1620^Hooker^Robert^L||||||20061122154733|||F|||||||||||20061122140000|
OBX|1|NM|GLU^Glucose Lvl|59|mg/dL|65-99^65^99|L|||F|||20061122154733|
As IoT breaks away from traditional data networks, and ways of engaging patients, organizations will find value in how PacketSled dissects these streams of data. This will aid in understanding the risk the organization is accepting with the adoption and implementation of IoT initiatives.

IoT, like Cloud, is extremely disruptive and often noisy and misunderstood. This makes it even tougher to be a Security Professional and unfortunately, executives and board members generally care very little about that. We do.

With the PacketSled platform, it is our goal to perform the following:
  • Reduce the efforts associated with non-contextual, traditional logs by applying Machine Learning and well-researched attack models.
  • Detect multi-staged attacks within ordinary-looking data flows, regardless of protocol type. As most advanced attackers aren’t facilitating 0-days, you need modeling and adaptive baselines that can spot attacks in YOUR network. “One Size Fits All” doesn’t really fit anyone, any longer.
  • Enable you to perform Incident Response at scale. Finding the piece of hay in the haystack is a tough grind and we’re here to help, with event correlation and applied threat data.
It’s time for us to break out of the same problematically applied daily grind, where you are attacked, then respond, then mop up the disaster, then you start all over again.

It’s time to talk to PacketSled.



Co-written by Leo Linsky and Patrick Kelley

Lowering The Poverty Line Of Incident Response

in Incident Response, Security Research by Patrick Kelley Comments are off

Over the years I’ve been part of monumental projects using several forms of technology, including SIEMs, in attempts to offset the talent gaps that plague the Information Security industry and shorten the “dwell” timeframe of attacks.  Taking a moment to define the anticipated goals and define the problem space, I find it necessary to state that properly launching a SIEM and similar technologies isn’t trivial and gaining a meaningful return on the investment is a significant challenge. Personally, I determine that return on investment to be a reduction in MTTD (Mean Time To Detection) and MTTR (Mean Time To Remediate).

The ultimate goal is revealing actionable intelligence that takes into consideration the true risk posed to the business and weights the alerts in that light.  This task cannot be achieved by leveraging and applying “threat intelligence” feeds as the primary form of correlation. Instead, it requires developing context around the core assets, networks, and layers of security controls that comprise the network.

In and of itself, this isn’t an easy problem to solve as businesses and their networks develop organically, as opposed to the more traditional networks created in the past.  This matters as demand for an urgent business needs drives the need for additional computing resources, leaving security as an afterthought.  This makes building contextual solutions around security problems a near impossible feat for most organizations.

Coincidentally, this is where SIEM implementations often fail. The concept of the SIEM is sound, but most implementations make decisions based on single, atomic events that are universally weighted.  This could be the match of an IP address or similar. This fails as security incidents are not singular, but more often contextual and long-playing.  Often I’ve been asked, “If we had signatures for Pass-The-Hash attack binaries and we used UAC, why were we breached? We had controls!”. 

Simply stated. This is a significant problem to solve.

The tough truth is the evolution of our networks and the way organizations communicate accelerate faster that the limited amount of resources the organization has to apply. So, just hire more professionals, right?

Here’s the harsh truth. Developing a proper Security Operations Center takes well over a year on average, and that’s just to nail down the basics.  Once developed, you will need a minimum of 8 well-trained engineers and a Sr. Security Architect to maintain the ability to respond 24/7/365, with ever-evolving breach detections. 

So, what’s the solution?  

In fairness, there isn’t a single one-shot answer for this.  However, I can offer the following advice that can greatly improve the security posture of an organization. 

Maintain a clear understanding that a threat is not just the presence of events, but also the absence of events. A phishing email with a malicious binary is certainly interesting, but so is the failed synchronization of an HA or failure of vMotion Snapshots.

Acknowledging that breaches can remain active for over 100 days, a platform that collects artifacts at the lowest level of ground truth and hold that evidence for hundreds of days, is becoming a requirement.

Threat Intelligence feeds are not the glue that binds together a security platform.  They are simply atomic indicators that can be applied to network flows. That’s not to say there’s no value in these sources of data, but a need to correlate those indicators with other sources.  Additionally, more Threat Feeds isn’t the answer.  It is far more valuable to choose the proper feeds for your environment and prevent as much overlap as possible.

Leveraging platforms, such as PacketSled, that apply multiple sources of enrichment to wire-level data, can provide greater confidence in incident relevance and the reduction of false-positives. For example, a Threat Intelligence match for an Apache attack methodology likely doesn’t represent a true threat when leveraged against a Windows environment.

We need to rely less on signatures and leaning more on User and Entity-based behavioral analytics. This isn’t an easily applied solution, but one that establishes dynamic baselines on observed behaviors with entities, allowing it to determine anomalies.  Anomalies could be determined as user accounts conducting database queries after midnight, which could not symbolize a threat, but an indicator worth additional investigation.

A means of properly prioritizing cases in a meaningful and actionable way. This is a tough problem, but one that will maximize the limited resources an organization has available. 

What’s the overall message in this?  Security is hard. It’s less the process of efficiently identifying the probable state of all enterprise platforms and users, but more so with identifying and understanding the applied risk of all possible operational states of systems and people. 

 

Reach out today and learn what we are doing to help you close the gaps and lower the poverty line in Incident Response.

How your Refrigerator is a Threat and Why you Should Care: Attacks on IoT

in Security Research by Patrick Kelley Comments are off
Last week, Wikileaks dropped an explosive number of documents related to their surveillance and hacking capabilities.  Much of this information included strategies related to IoT and household devices, such as the Samsung TV.  To be clear, the leak of CIA documents and data didn’t readily include usable source or exploit code for leveraged attacks, but was more of an internal wiki which provided information about available attacks and strategies used by the agency.   

In our research, it appeared that most of the exploits reference full-on remote access vulnerabilities, some of which were already known. Many of the documents outlined planned strategies or half-developed exploits, many of which requiring physical access to the device or the supply line.

WikiLeaks, in a statement, was vague about its source. “The archive appears to have been circulated among former US government hackers and contractors in an unauthorized manner, one of whom has provided WikiLeaks with portions of the archive,” the organization said.  

As the data dump is quite lengthy, let’s start with “Weeping Angel”.  This is an attack methodology that was recently published by Wikileaks and outlines that a Samsung TV can be hijacked using vulnerable firmware.  This was developed during a joint workshop between MI5 and BTSS (British Secret Service).  The recent reports disclose how to make the television appear to be powered off but in reality was being used to monitor targets. It describes the television as being in “Fake Off” mode.  Some key things to note is that when the television is compromised, it provides the attacker with a ported and modified TinyShell to provide shell, command execution, and file transfer capabilities.   

This functionality allows the television to be used as a monitoring device, as well as a pivot point for further attacks against devices on the network (persistence).  

The current versions of vulnerable firmware provide the following technical details: 
  • Video capture / Video snapshots
  • Max possible storage usage is 700MB (of 1.6GB).
  • The installation is similar to installing a standard Samsung application.
  • empDownload is the binary that downloads other apps or adverts and is executed by the system.
  • It appears to connect to Dreamhost and supports Telnet and FTP.
  • It has native WPA and iw wireless network capabilities. 
As a longtime security researcher, I tend to believe that these capabilities extend much farther than televisions.

So, you might be asking, “when is he going to tell me about my refrigerator trying to kill me?”. 
Read more

Modeling Multistep Attack Scenarios for Detection

in Incident Response by Troy Molsberry Comments are off
Many incidents that impact an organization’s security involve multiple steps. For example, an alert that a malicious email was transferred over the network is of concern, but there can be many thousands of these per day in a typical environment, and vetting each one out individually is prohibitive. Of more interest to the defender would be information about a malicious email being delivered, followed by a user clicking on a link contained in the email, followed by any downloads initiated by that user from blacklisted servers. In this example, we have an indicator (malicious email) followed by an action (clicked a link), followed by another action (download). In general, a “behavior” or “attack” consists of a sequence of causally related activities. Vetting these complex behaviors out by hand can be tedious at best, and intractable in most cases. You have to manually implement an algorithm known as “forward chaining”. Start with the first step in the sequence, and use attributes from the sensor data to perform a query for the second step using results from the previous query, and continue through the sequence until either a result is found or the trail goes cold. One interesting aspect of the “forward chaining” algorithm is that it explodes in both data and time. Performing this task by hand is more or less impossible, yet we commonly refer to this practice as “incident response”. These “incident responders” rely on a tremendous amount of experience, domain knowledge, and expertise to extract out behaviors that could potentially be security incidents. At Packetsled, we chose to capture that knowledge in a repeatable way.

Capturing knowledge from domain experts into models is a broad research topic, but I think we would all agree that at some point you will need a designer, e.g., a method for users to build models of attacks, so let’s start there. We chose a graphical notation for our models. Domain experts can visually model the causal relationships between queries, and those queries can contain forward- and backward- chaining references, e.g., those queries can depend on the results of previous or future queries. This is the magic.

Let’s create an example model for the example of a user clicking a malicious email link followed by an infection.

Read more

Using Bro to Explore Your Networks, like an AWS WordPress Blog

in Security Research by Leo Linsky Comments are off
My personal WordPress blog was hacked a few weeks ago. I hadn’t checked my simple AWS micro instance in a while, and fortunately, I happened to look at the site just a day after it was compromised. WordPress makes it easy to stand up a pretty website if you don’t want to spend time crafting a front-end yourself, but security is a major question mark. If you keep it up to date and don’t load it with tons of third party content, it’s probably OK for a personal blog. However, I had several WP plugins and themes that were a few weeks behind the last update, as was WP Core. This is likely how the attacker was able to gain write-access to my one and only post on my blog and change the links to point at some sketchy-looking foreign domain websites to improve his SEO. Interestingly enough, the attacker also made some edits in the article, including grammatical fixes and clauses that were consistent with the content (environmental regulations).

Regardless, I updated everything, removed unnecessary plugins, added a plugin to record more detailed WordPress history, secured my active accounts, and reverted the changes (except for one grammatical improvement – thank you attacker). Good WordPress security and statistics plugins are difficult to come by, and they most likely increase the attack surface of the website, so I decided to opt for the tool I use and develop every day: Bro IDS. The visibility provided by Bro goes beyond threat detection and can be used as a more powerful version of netflow, showing what’s running on a system in significant detail.

Monitoring a single web server instance facing external http requests behind a pretty limiting firewall (inbound tcp/80 only, or tcp/22 from my static IP address only) is not our typical deployment for Bro here at Packetsled — limited to basic web requests, and with no honeypot, I didn’t expect a whole lot of interesting attack vectors. However, there were some takeaways after letting Bro run for a few weeks, mostly regarding how my network operates and what kind of requests my site typically sees.

The blog uses basic unverified HTTP (I’m too lazy and cheap to set it up right), so I was unsure why I had at least one ssl log entry every hour:
#fields id.orig_h id.orig_p id.resp_h id.resp_p version cipher curve server_name resumed last_alert next_protocol established cert_chain_fuids client_cert_chain_fuids subject issuer client_subject client_issuer validation_status

172.31.40.119 59718 52.201.183.155 443 TLSv12 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 secp256r1 - F - - F Fb0mOL2796DAoCkRa3 (empty) - - - - -
172.31.40.119 41499 66.155.40.189 443 TLSv12 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 secp256r1 - F - http/1.1 F Fr4ISl3di8C0feHNC4,F2sfO14ZkvhwHhaNb4,F10O3d278YkNUhURTf (empty) - - - - -
Ah of course — after opening up the corresponding x509 certificate log, it’s clear that my device is reaching out to WordPress about twice a day, looking for updates from “CN=*.wordpress.org,OU=Domain Control Validated CN=Go Daddy Secure Certificate Authority – G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com.” More surprisingly though, my instance periodically was reaching out to an Amazon-based address every hour on my exposed network (as opposed to the back channels AWS uses to control instances):
pi@raspberrypi:~ $ whois 52.201.183.155
NetRange: 52.192.0.0 - 52.223.255.255 
CIDR: 52.192.0.0/11 
... 
Organization: Amazon Technologies Inc. (AT-88-Z) 
x509.log
#fields certificate.version certificate.serial certificate.subject certificate.issuer certificate.not_valid_before certificate.not_valid_after certificate.key_alg certificate.sig_alg certificate.key_type certificate.key_length certificate.exponent certificate.curve san.dns san.uri san.email san.ip basic_constraints.ca basic_constraints.path_len
3 07 emailAddress=info@bitrock.com,CN=stats.bitnami.com,O=BitRock Update Services,L=Seville,ST=Seville,C=ES emailAddress=info@bitrock.com,CN=BitRock Update Services,O=BitRock Update Services,L=Seville,ST=Seville,C=ES 1284478570.000000 1599838570.000000 rsaEncryption sha1WithRSAEncryption rsa 1024 65537 - - - - - F -
3 280392F6950C4C CN=*.wordpress.org,OU=Domain Control Validated CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O=GoDaddy.com\\, Inc.,L=Scottsdale,ST=Arizona,C=US 1417824798.000000 1513368681.000000 rsaEncryption sha256WithRSAEncryption rsa 2048 65537 - *.wordpress.org,wordpress.org - - - F -
Read more

Using PacketSled to detect Golden Ticket Attacks

in Network Visibility, Threat Detection by Patrick Kelley Comments are off
2016 was a year of exciting news in Information Security, and unfortunately one of many breaches. As I write this, I’m reading news about continuing leaks from Yahoo and new SCADA attacks.

With over 20 years as a professional in Information Technology, I’m always looking at new methodologies.  However, I’m also looking at the ways things haven’t changed. 

For as long as I remember, privileged account exploitation has always been at the center of targeted cyber attacks. This provides InfoSec Professionals with a constant pattern of events to look for on their networks.

In typical fashion, attackers penetrate the network perimeter using phishing attacks or attacks on mobile devices, hijack credentials and use them to move laterally throughout the network, taking additional credentials and escalating privileges along the way.

During my time as a Penetration Tester, combining privileged accounts with attacks on the Kerberos authentication in Windows domains was a method I always employed, in hopes of compromising the entire network. In fact, my team used to joke that lunch wouldn’t be served until we had “Domain Admin”. During such attacks, my team would target domain administrator privileges, which provide unrestricted access and control of the IT landscape. Armed with these privileges, my team could manipulate Domain Controllers (and Active Directory) and generate Kerberos tickets to obtain unauthorized access.  Our ultimate goal was the “Golden Ticket”!  That’s the ticket that gives us 10 years of unfettered access.



In order to successfully collect one of these tickets, the four things necessary to formulate one is:

·       the account name of a domain administrator

·       the domain name

·       the SID for the domain

·       the password hash of the krbtgt user from the Domain Controller

The good news is that Golden Ticket Attacks are particularly noisy, both in system logs and on the network. With the ability to perform deep packet inspection on Kerberos and DCE-RPC logs, this gives users of PacketSled the ability to look for indicators of these attacks across their entire network, instead of searching through system logs which are often dispersed and not centrally stored while attempting to piece together the pattern for themselves 

In particular, Golden Ticket Attacks require a particular DCE-RPC command on the network, defined as, “DRSGetNCChanges”. This command obtains updates for a specified naming context (NC = partition of the AD database), typically between domain controllers.  This behavior is particularly useful, as knowing that this data would not be transferred between a workstation and a domain controller would be anomalous.



Now, how do you get visibility into these attacks from a central point? Well, deploying a PacketSled sensor to establish a perimeter has never been easier. We have an IR deployment package that can have you up and running in minutes. Provide a SPAN/TAP feed to our sensor(s) and you have perimeter network visibility when you need it most.

Using this approach to develop the security detection moves the security controls from making decisions based on circumstantial, atomic elements and moves towards being more contextual in nature. This can greatly reduce the false-positive rate and make notifications more actionable.

At PacketSled, our researchers are continually pushing the boundaries of using our IRES-based security platform to provide greater value in security notifications. We do so by not just notifying InfoSec Professionals with alarms of potentially malicious behavior, but putting the context of those events in their hands as quickly as possible. 

Let us show you the value of PacketSled network visibility tools. To arrange a product demonstration or talk IR strategies give us a call.

Attacks On Routers and IoT

in Incident Response, Malware, Network Visibility, Security Research by Patrick Kelley Comments are off
Here at PacketSled, we live on the forefront of technological innovation.  Our deployed platform captures multitudes of attacks each day against devices that have just barely made it into the market. To keep up with attacks against “bleeding edge” IoT devices is no small feat.

To understand how to best protect these new assets, it’s best to understand what brought them here.  The adoption of IoT and BYOD has increased with the intent of streamlining technology for the user and easing adoption in the marketplace..  Apps in IoT can become seamless, removing the barrier that a user used to have in determining if they were sharing information with a co-worker or with the Internet.  The more covert we make these transactions, the more risk we are accepting (think tap to pay, passwords transferred through nfc, and magic links as Slack likes to call them).  

Without a clear understanding of standards and services, it’s a challenge to determine how to best approach securing them. In fact, it’s such a challenge that Gartner has claimed that nearly all security vendors will fail at this task. 

Personally, I agree.  

Security budgets are rarely earmarked for efforts around IoT and business scenarios require a delivery mechanism that can also grow and keep pace with security requirements in monitoring, detection, and access control.  Despite this, users continually add more devices to the enterprise network, due to ease of doing so.

Fortunately, PacketSled has been thinking about IoT for quite some time.  Our team has spent many years of focused research on the most common IoT attacks.

One of the most common attacks we witness is authentication bypass. This could be due to poor session handling with predictable IDs or backdoors using hardcoded credentials. Regardless of the means, the outcome is the same – unauthorized access to sensitive information.

A quick search of Shodan will likely provide access to nearly any device, including devices in your infrastructure, an attacker would be interested in. In fact, we need not look further than a recent IoT attack which was seen with Mirai. It worked by scanning the Internet for devices with default credentials and enrolling them into the command and control platform. Once done, all of these devices can be remotely controlled and used to perform nearly any action conceivable. These attacks occurred across a wide spectrum of devices from smart TV’s to routers to really anything with the “smart” monicker attached.

Packetsled is here to help protect by proactively building detections in our platform to look for these behaviors, but our recommendation is to make sure your organization is covering the basics.

Where should you begin? 

Start with the CIS Critical Security Controls with emphasis on the 1st six. 
  1. Inventory of Authorized and Unauthorized devices
  2. Inventory of Authorized and Unauthorized software
  3. Security configurations for hardware and software on mobile and IoT devices
  4. Continuous Vulnerability Assessment and Remediation
  5. Controlled user of administrative or root privileges
  6. Maintenance, Monitoring, and Analysis of Audit Logs
  

With these basics addressed, you will have a more clear understanding of what devices and accounts are in use on your network and how you should expect them to behave.  

Among the many detections that PacketSled provides, you should look for unencrypted credentials present on the network, by issuing the following query in the investigator:

last 24 hours cluster password on [password]





This simple query will provide you with every password observed on the network in the last day.  This list is exportable and can be used to aid in the mitigation of these vulnerabilities.

We also provide extensive support for newer IoT protocols, along with our raw TCP and UDP analyzers, which will allow you to see inside network flows, even when a specific protocol analyzer isn’t available. 

Along with our security platform and the recommendations outlined above, we suggest signing up with each vendor for updates related to security patches, firmware updates and any available alerts provided from the devices, themselves.

 
Written by Patrick Kelley and Chris Mitzlaff 

Analyzing Unknown Protocols – Finding a Piece of Hay in a Hay Stack

in Network Visibility, Threat Detection by Patrick Kelley Comments are off
Over the years, I’ve had the fortune of performing in several differing capacities in the Information Security community.  Some positions have been on “blue teams”, whereas others have been performed more “red team” roles.  One thing that always rings true is the importance of visibility. 

You can’t make decisions around data that you can’t see. 

When PacketSled chose to build our sensors on Bro, we knew that significant effort would be necessary, if we were going to meet our high level of expectations.  Bro provides visibility for around 60 protocols, at this time. Unfortunately, there are literally thousands of protocols. That’s a lot of missed network traffic. 

For those that aren’t aware, WinRM is a remote management service for Windows that is installed in Windows XP and higher versions. Both of these authenticated services are tied to an HTTP or HTTPS SOAP listener and support Kerberos and NTLM authentication by default. It’s important to note that many attacks start with NTLM authentication since it’s already supported in Metasploit.



As our security team began launching live attacks in networks observed by Bro sensors, we realized that many of the Metasploit attacks weren’t being properly observed and tagged.  WinRM traffic is based on HTTP and HTTPS, but isn’t formatted in a manner that is properly recognized and analyzed by Bro. As a company focused on security solutions, we realized that something had to be done to permit our clients to see actionable data in this attack, as well as attacks on other protocols.

Therefore, we built raw TCP and UDP analyzers.  With these analyzers, it’s now possible to build IRES rules or bro-formatted detection scripts to alert on attacks in protocols that aren’t yet supported by the Bro framework.  So, how do you do it? 

By collecting a Packet Capture (pcap) of the attack traffic using our raw analyzers, we were able to extract the associated User-Agents and URI strings associated with these attacks.  

In our case, these were defined as:



User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

URI and Action: POST /wsman HTTP/1.1

Host: 192.168.1.3:5985

Though this was an authenticated session, which later became encrypted, we were still able to see some interesting indicators as the session was established.  The most important being a Mozilla User-Agent connecting to a service that would normally be engaged using a variation WinRM.* as the User-Agent.  Also, we noticed that the listening port was TCP/5985, which is a non-standard HTTP port, and repeated failed authentication attempts.  Knowing this was anomalous and potentially malicious, our team was able to create a simple IRES rule to pull these indicators from our raw TCP analyzed traffic.  By doing so, we were immediately able to recognize a large amount of attacks from Metasploit against WinRM services in our extracted TCP payloads.



The single piece of hay was found in the haystack and what would normally be unrecognizable by standard installations of Bro was quickly brought to the surface.  That is the unmatched power of the PacketSled platform. 

At PacketSled, we’re always striving to provide the greatest visibility with our award-winning platform by continually developing additional protocol analyzers, allowing you to continuously monitor for advanced threats and policy violations missed by other defenses. Allowing you to analyze and remediate in record time. Don’t settle with being an Analyst. Be a Hero!

It’s 10 o’clock; do you know where your data is?

PacketSled Partners with Lyrical Security to Provide Advanced Security Solutions

in Partners by Christina Patten Comments are off
  PacketSled is thrilled to announce a new partnership with Lyrical Security, one of North America’s fastest-growing cyber risk management firms, providing integrated solutions that elevate operations from struggle to success story.  
”We’re excited to take our strategic partnership to the next level,” said Sheldon Malm, Chief Executive Officer of Lyrical Security.  “Packetsled’s innovative platform has become the cornerstone of our Risk Operations Center, enabling our staff to detect threats earlier, accelerate investigations, and manage clients’ risk faster than we could have imagined.  Customer response to the solution has been overwhelmingly positive.”
  Read the Full Release      
Page 1 of 41234

© 2017 PacketSled, Inc.