Eric Humphries

Eric has over 15 years of information security experience including network engineering, UNIX administration, and consulting. Eric specializes in network architecture and device security, secure storage, and virtualization technologies. Eric’s recent projects include administering a heterogeneous virtual environment based on VMware and Hyper-V server which directly supported a large MSSP and numerous Fortune 1000 customers. He also provided network and security administration and support for large multi-tenant networks in ISP and MSSP environments.
More by Eric Humphries
WP_Query Object
(
    [query] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "8"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "8"
                            [compare] => LIKE
                        )

                )

        )

    [query_vars] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "8"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "8"
                            [compare] => LIKE
                        )

                )

            [error] => 
            [m] => 
            [p] => 0
            [post_parent] => 
            [subpost] => 
            [subpost_id] => 
            [attachment] => 
            [attachment_id] => 0
            [name] => 
            [pagename] => 
            [page_id] => 0
            [second] => 
            [minute] => 
            [hour] => 
            [day] => 0
            [monthnum] => 0
            [year] => 0
            [w] => 0
            [category_name] => 
            [tag] => 
            [cat] => 
            [tag_id] => 
            [author] => 
            [author_name] => 
            [feed] => 
            [tb] => 
            [paged] => 0
            [meta_key] => 
            [meta_value] => 
            [preview] => 
            [s] => 
            [sentence] => 
            [title] => 
            [fields] => 
            [menu_order] => 
            [embed] => 
            [category__in] => Array
                (
                )

            [category__not_in] => Array
                (
                )

            [category__and] => Array
                (
                )

            [post__in] => Array
                (
                )

            [post__not_in] => Array
                (
                )

            [post_name__in] => Array
                (
                )

            [tag__in] => Array
                (
                )

            [tag__not_in] => Array
                (
                )

            [tag__and] => Array
                (
                )

            [tag_slug__in] => Array
                (
                )

            [tag_slug__and] => Array
                (
                )

            [post_parent__in] => Array
                (
                )

            [post_parent__not_in] => Array
                (
                )

            [author__in] => Array
                (
                )

            [author__not_in] => Array
                (
                )

            [search_columns] => Array
                (
                )

            [ignore_sticky_posts] => 
            [suppress_filters] => 
            [cache_results] => 1
            [update_post_term_cache] => 1
            [update_menu_item_cache] => 
            [lazy_load_term_meta] => 1
            [update_post_meta_cache] => 1
            [nopaging] => 1
            [comments_per_page] => 50
            [no_found_rows] => 
            [order] => DESC
        )

    [tax_query] => WP_Tax_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => AND
            [table_aliases:protected] => Array
                (
                )

            [queried_terms] => Array
                (
                )

            [primary_table] => wp_posts
            [primary_id_column] => ID
        )

    [meta_query] => WP_Meta_Query Object
        (
            [queries] => Array
                (
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "8"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "8"
                            [compare] => LIKE
                        )

                    [relation] => OR
                )

            [relation] => OR
            [meta_table] => wp_postmeta
            [meta_id_column] => post_id
            [primary_table] => wp_posts
            [primary_id_column] => ID
            [table_aliases:protected] => Array
                (
                    [0] => wp_postmeta
                )

            [clauses:protected] => Array
                (
                    [wp_postmeta] => Array
                        (
                            [key] => new_authors
                            [value] => "8"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                    [wp_postmeta-1] => Array
                        (
                            [key] => new_presenters
                            [value] => "8"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                )

            [has_or_relation:protected] => 1
        )

    [date_query] => 
    [request] => SELECT   wp_posts.ID
					 FROM wp_posts  INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
					 WHERE 1=1  AND ( 
  ( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{994ca9ad916e111636f77e204bdcaccdeba1fc0f207224ae8f1d082bc2f75c2d}\"8\"{994ca9ad916e111636f77e204bdcaccdeba1fc0f207224ae8f1d082bc2f75c2d}' ) 
  OR 
  ( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{994ca9ad916e111636f77e204bdcaccdeba1fc0f207224ae8f1d082bc2f75c2d}\"8\"{994ca9ad916e111636f77e204bdcaccdeba1fc0f207224ae8f1d082bc2f75c2d}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
					 GROUP BY wp_posts.ID
					 ORDER BY wp_posts.post_date DESC
					 
    [posts] => Array
        (
            [0] => WP_Post Object
                (
                    [ID] => 20716
                    [post_author] => 91
                    [post_date] => 2020-12-15 09:41:57
                    [post_date_gmt] => 2020-12-15 09:41:57
                    [post_content] => 

As we write this post, you’ve likely heard about the FireEye and U.S. government agency breaches that occurred over the past week. We know now the breaches have been linked back to a supply chain attack on the SolarWinds Orion Platform, a software platform that manages IT operations and products for over 300,000 organizations, including over 425 of the Fortune 500, all ten of the top U.S. telecommunications companies, all five branches of the U.S. Military, all five of the top U.S. accounting firms, and many, many more.

While FireEye, the U.S. Treasury, and National Telecommunications and Information Administration (NTIA) were the first to report a security breach, the breadth of SolarWinds’ customer base is an indicator that the breaches are seemingly the tip of the iceberg.

For the sake of information sharing, here is an overview of the attacks, immediate steps you can take to identify whether you have fallen victim, and tips for protecting your organization as communicated by FireEye, SolarWinds, and NetSPI. For the full technical deep-dive, we highly recommend the FireEye blog post.

Overview: SolarWinds Orion Manual Supply Chain Attack

On December 13, SolarWinds issued a security advisory alerting to a manual supply chain attack on its Orion Platform software builds for versions 2019.4 HF 5 through 2020.2.1, released between March 2020 and June 2020.

FireEye discovered the attack and suggests it is a state-sponsored global intrusion campaign by a group named UNC2452 - though many industry experts are attributing the attack to APT29, a group of hackers associated with the Russian Foreign Intelligence Service.

  • Attack Origin: UNC2452 gained access to victims via trojan-based updates to SolarWinds’ Orion IT monitoring and management software, distributing malware called SUNBURST. Multiple trojanized updates were digitally signed and subsequently deployed via this URL: hxxps://downloads.solarwinds[.]com/solarwinds/CatalogResources/Core/2019.4/2019.4.5220.20574 /SolarWinds-Core-v2019.4.5220-Hotfix5.msp. The downloaded file is a standard Windows Installer Patch file, which includes the trojanized SolarWinds.Orion.Core.BusinessLayer.dll component.
  • How It Works: The digitally signed SolarWinds.Orion.Core.BusinessLayer.dll file is a component of the Orion Improvement Program (OIP) software framework that contains a backdoor that communicates with third party servers via the HTTP protocol. The malicious DLL gets loaded into the legitimate SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe executables and can run dormant for up to two weeks before beaconing to a subdomain of avsvmcloud[.]com. To avoid possible detection, the C2 traffic between the beaconing server and the victim is made to resemble legitimate SolarWinds communications. This includes HTTP GET, HEAD, POST and PUT requests with JSON payloads in their bodies. The HTTP responses from the C2 server communicating with the victim contain XML data that resembles .NET assembly data used for normal SolarWinds operations. Within the XML, however, is obfuscated command information that is deobfuscated and then executed by the SolarWinds process on the victim’s system.
  • Impact/Result: Following the initial compromise and deployment of SUNBURST, a variety of more capable payloads can be deployed to facilitate lateral movement and data theft. Common payloads include TEARDROP and Cobalt Strike BEACON, both of which can be loaded into memory to improve stealth of operations.

Known breaches include:

FireEye: On December 8, FireEye communicated a state-sponsored security breach through which the attackers accessed FireEye’s Red Team assessment tools used to test customers’ security. Following the breach, the company made its list of countermeasures public. FireEye has now confirmed that this attack was a result of the SolarWinds Orion supply chain attack.

U.S. Treasury and the National Telecommunications and Information Administration (NTIA): On December 13, Reuters reported that Russian-associated hackers broke into the U.S. Treasury and Commerce department’s Microsoft 365 software and have been monitoring internal email traffic. Following a National Security Council meeting at the White House over the weekend, the Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive for all federal agencies to power down SolarWinds Orion.

Organizations are frantically working to figure out if they have been a victim of the attack and how to protect themselves. Here are the immediate steps to take, according to SolarWinds, FireEye, and NetSPI’s team of offensive security experts:

  1. First, determine if SolarWinds Orion is deployed within your environment. If unsure, NetSPI recommends performing a network scan to identify the Orion agent. For example, this can be performed with Nmap by running: nmap --open -sT -p 17778,17790 x.x.x.x/xx, where x.x.x.x is the network address and xx is the subnet mask. If the Orion agent is found, follow SolarWinds’ recommendations.
  2. SolarWinds recommends customers upgrade to Orion Platform version 2020.2.1 HF 1 as soon as possible. It also asks customers with any of the products listed on the security advisory for Orion Platform v2019.4 HF 5 to update to 2019.4 HF 6. Additional suggestions can be found in the security advisory. While upgrading Orion will prevent future backdoored deployments from occurring, it will not remediate the potentially infected deployments that have already taken place via the Orion Platform.
  3. Additionally, FireEye provides a list of recommendations including its signatures to detect this threat actor and supply chain attack. Specific details on the YARA, Snort, and ClamAV signatures can be found on FireEye’s public GitHub page.

Get in Touch: To connect with NetSPI for support with testing efforts related to the SolarWinds Orion attack, email info@NetSPI.com.

[post_title] => FireEye, SolarWinds, U.S. Treasury: What’s Happening in the Cyber Security World Right Now? [post_excerpt] => As we write this post, you’ve likely heard about the FireEye and U.S. government agency breaches that occurred over the past week [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => fireeye-solarwinds-us-treasury-whats-happening-in-the-cyber-security-world-right-now [to_ping] => [pinged] => [post_modified] => 2021-05-04 17:03:39 [post_modified_gmt] => 2021-05-04 17:03:39 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=20716 [menu_order] => 442 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 1737 [post_author] => 8 [post_date] => 2014-10-13 07:00:37 [post_date_gmt] => 2014-10-13 07:00:37 [post_content] => Not enough emphasis is given to IT asset management. This is one of the first things an organization needs to get under control before they can really implement any security program. Yet few people do it well, if at all. How can you possibly protect an environment if you don't know what assets make up that environment? Lets quickly define what I mean by "IT asset." An asset can be any computer, server, network device, application, database, archive of uncompiled code, or whatever that has monetary or perceived value to the business. It's easy to justify why a piece of hardware or software is an asset, as there is a direct cost involved with procurement, management, and maintenance. You also depreciate your hardware investments in your accounting books, so even those with the checkbooks are acutely aware of hardware costs and value. The not-so-obvious items are web applications and databases. Some disagree that a database is an "asset" but what if that database contains your entire customer list? Isn't that important to the business? Essentially, if your IT department spends time working on, fixing, installing, or maintaining it as a part of their day-to-day duties, it's probably an asset. There are some very basic questions you should be able to answer with a high level of precision about your assets and, if you can't, IT assets aren't being managed properly in your organization. Let me give you an example:
  • How many physical servers do you have?
  • How many laptops does the business own?
  • When were assets purchased?
  • How many servers are physical vs. virtual?
  • What operating systems are your systems running (and what are their patch levels)?
  • What MAC addresses are assigned to each system?
  • Who owns each server? How do you get ahold of them? Who is the second point of contact if they're not available?
  • How many web applications do you have?
  • How many licenses of Microsoft Office do you have?
  • What is your total annual maintenance commitment for software?
  • What is the circuit ID of your main Internet connection and what is the best number to call in case of an outage? (You don't want to have to look through years of bills to try and identify this when your business is down.)
You should be able to answer all of those questions pretty quickly by looking at an IT asset management database. You don't have to spend millions on the shiniest box with the prettiest light array. You can do an adequate job with a spreadsheet, SharePoint, and/or a home-grown application. Here are some items you may find useful to track:
  • AssetID
  • Asset type: circuit, server, desktop, laptop, router, switch, web application, standalone application, database, SAN head, NAS head, disk shelf, firewall, bridge, thin WAP, thick WAP, wifi controller, other.
  • Purchased from?
  • Sales contact name
  • Sales contact number
  • Sales contact email
  • Purchase date
  • Purchase order number
  • Purpose
  • Physical location (Minneapolis, 511, rack 12, position 13-15)
  • Unit cost
  • Maintenance cost
  • Deploy date
  • Retirement date / lifecycle information
  • Data classification
  • Server classification
  • Circuit ID
  • Emergency contact name
  • Emergency contact number
  • Emergency contact email
  • Service Level Agreement (SLA)
  • Make
  • Model
  • PSU (single, dual, n+1, n+2, other)
  • CPU
  • Memory
  • IP addresses associated
  • Hostnames
  • MAC addresses
  • Operating system (very specific)
  • Virtual/physical
  • Physical host ID (another AssetID if virtual)
  • Has virtual guests? (is a virtual host)
  • Owner & contact info
  • Secondary owner & contact info
  • Upstream dependencies
  • Downstream dependencies
  • Hardware change history
  • Software change history
  • Failure history
  • Patch history
  • Notes
This is not exhaustive. It's just meant to help organizations get an idea of where to start. The more specific and detailed your asset management database, the more sound the rest of your decisions will be when implementing and enforcing specific company policies. I also like a single database with version control for everything, so you only have a single location where you can find the answers you need. How you normalize your data is up to you, but I prefer a single table for everything. Obviously, if you have tens of millions of assets, this may not be reasonable. From here you should also consider defining:
  • How your organization is going to perform asset discovery;
  • How you plan to capture the data to populate the database;
  • How you plan to keep it up-to-date and verify the integrity of the data;
  • Acceptable use of assets;
  • Your organization's official IT asset lifecycle for each major type of asset; and
  • Data and server classification policies.
There are a ton of other policies you probably need to define here as well, but this discussion could quickly fill a library. Get started today! You'll find that this isn't an easy project to get started with but, the sooner you get started and the more effort you put into the process, the easier things will get over time. If you need standards to lean on, have a look at section A.8 of the ISO/IEC 27001:2013 standard, and section 8 of the ISO/IEC 27002:2013 standard. ISO/IEC 27005 in section 8.2.2 helps identify assets your business should include in its risk assessment. PCI DSS version 3.0, requirement 2.4 requires "maintain an inventory of system components that are in scope for PCI." Cataloging only PCI systems doesn't seem to fulfill the spirit of the requirement, so I think it's safe to say PCI requires IT asset management. Additionally requirement 12.2 states, "implement a risk-assessment that Identifies critical assets, threats, and vulnerabilities, and results in a formal risk assessment." Risk assessments are not possible without first identifying the assets you need to protect. Consider management of all IT assets as a shadow requirement of becoming PCI compliant. [post_title] => IT Asset Management – Where to Start [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => it-asset-management-where-to-start [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:07 [post_modified_gmt] => 2021-04-13 00:06:07 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1737 [menu_order] => 704 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 1130 [post_author] => 8 [post_date] => 2014-02-04 07:00:30 [post_date_gmt] => 2014-02-04 07:00:30 [post_content] => I present you with RFC2142, please take a minute to skim through it for a little context. This RFC aggregates all of the recommended mailbox names that network and computer operators should setup depending on what public services they offer (You did setup and continue to monitor important mailboxes like postmaster, abuse, and so on, right?). The idea behind this is, if someone has a mail issue, they can just email POSTMASTER@domain.tld. If there is an issue with the website, send it to WEBMASTER@domain.tld. Having these predefined mailboxes takes all the thought out of the process, and saves people from having to pick up the phone, or start hunting around the website for a contact form, and just send the message and get on with their day. People have become lazy regarding these best practices, so this blog is also to raise awareness about that particular practice as well. So how does this relate to security, you ask? One of the dumb problems in the security industry is that there isn’t a standard way to disclose vulnerabilities to vendors or to network operators. Unless you have some sort of existing relationship with the company, or they go above and beyond in terms of security responsiveness (which is almost nobody), you start pitching your vulnerability disclosure into various e-mail boxes, snailmail letters, voicemail boxes, etc. More times than not, the information doesn’t make it to the right person, so you end up disclosing. When the bad press happens to catch someone’s attention, they get upset because you didn’t tell them about the problem first. It’s a lose-lose situation for everyone involved. My suggestion is to resurrect good internet stewardship, and start standardizing on the SECURITY@domain.tld for vulnerability and security disclosure. The above RFC was written in 1997 and includes this mailbox under section 4 “NETWORK OPERATIONS MAILBOX NAMES,” so at least there is existing precedent for this naming convention. I suggest we expand the scope a little and use that mailbox for any security related topic. This can include, but is not limited to:
  • Vulnerabilities on a website
  • Vulnerabilities in software distributed by that company
  • Vulnerabilities in services offered by the company
  • Vulnerabilities on a public facing network or system that is maintained by that company
  • Publicly leaked information on a websites like pastebin
  • Sensitive documents blowing in the parking lot
What you do with the mailbox is up to you, but here are some ideas:
  • Have an employee check this box once in a while, and manually distribute the messages to those that need the information.
  • Create a secondary mailbox in Exchange that people can attach to and have your infosec department manage the mailbox.
  • Create a distribution group or mailing list with key members of your organization subscribed.
  • Have a ticketing system monitor the mailbox and create cases or tickets automagically when something comes in.
While we’re talking about standardizing vulnerability disclosure, lets put together some high-level process objectives we could all strive to attain:
  1. All messages received on SECURITY@domain.tld should send an auto-reply back to the user immediately thanking them for their submission, and include a URL to a page with more information about that company’s vulnerability process. (We could even standardize the URL, how about something like www.domain.tld/security/?)
  2. Within no more than 7 calendar days, the vendor MUST send a response back to the vulnerability submitter. The response should contain a case or ticket number they can reference in the future and a means of communication to check up on the status of the vulnerability. This gives the vendor an opportunity to accept the vulnerability as legitimate and issue a case or ticket number, and drop all other spam messages without assigning case numbers to bogus requests or spam messages. If no ticket number is issued within 72 hours for any reason at all, the submitter is free to disclose publically. If the submission is granted a ticket number, a three-month gag order and moratorium starts. The submitter should be reasonable and grant more time if the vendor gives a valid reason. For example, if the vulnerability were so widespread that a vendor would have to rewrite the entire application from the ground up, 3 months wouldn’t be enough time.
  3. Once 3 months (or whatever the agreed upon time frame) is up, the vulnerability submitter is free to speak, blog, tweet about the vulnerability as they see fit. Once the gag timer expires, the submitter’s responsibility is terminated.
I realize this is a lofty idea that will get ignored, but I can dream. Thoughts, comments, and ideas on this are all greatly appreciated. Have you implemented something similar in your organization? Let me know in the comments how it worked for you. UPDATE: since the release of this blog, a couple new standards have been released. ISO 24197, and ISO 30111 have been released for public consumption. I’ve not read either of these standards, but they should be reviewed by organizations when writing their vulnerability disclosure and handling policies. [post_title] => Vulnerability Disclosure Submission Standard? [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => vulnerability-disclosure-submission-standard [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:16 [post_modified_gmt] => 2021-04-13 00:06:16 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1130 [menu_order] => 727 [post_type] => post [post_mime_type] => [comment_count] => 1 [filter] => raw ) [3] => WP_Post Object ( [ID] => 1146 [post_author] => 8 [post_date] => 2013-09-16 07:00:25 [post_date_gmt] => 2013-09-16 07:00:25 [post_content] => Firewalls are a spot of contention for many within the information security community. Many people put too much faith in a network firewall and assume that because there is one on the network somewhere, that they're “hacker proof.” Others do not put enough faith in a network firewall because many are deployed improperly or they're deployed in the wrong spot on the network, or not enough firewalls are deployed to provide adequate protection within their environment. There are seemingly endless technical challenges when it comes to proper deployment, configuration, management, and review of firewalling technology. Regular review of firewall configurations and how they’re deployed is considered a best practice and really helps promote good configuration from the simple act of looking at it from time to time. If best practice isn’t enough reason, regulatory requirements such as PCI require you to perform regular firewall configuration reviews (Requirement 1.1.6).  The firewall isn’t a black box that you setup and walk away from. Many times, this is the heart of your critical network, and to continue smooth operations, it requires maintenance. Improper segmentation and rule set configuration are also likely one of the core reasons you failed your most recent penetration tests, but this is often lost on a lot of people. Sure the initial access vector was MS08-067 on a test server, but why was someone from the user segment able to talk directly to the test network in the first place? Take my word for it, periodic configuration reviews are very important, regardless of the technology. Unless you’re intimately familiar with firewall technologies, performing a useful review of a firewall is quite difficult. Many businesses don’t have the luxury of a dedicated firewall configuration employee or team. There are a lot expensive tools that will look at your configuration and give you some rule set and configuration recommendations, but those require capex and opex budget allotments as well as the expertise to get the most out of the tools to maximize your investment. Unless you’ve mastered the basics, buying a tool isn’t going to be a good use of limited information security budget dollars. If you don’t want a tool, there are a plethora of clumsily put together checklists that attempt to help you solve this problem. However, even the better checklists seem to be a response to regulation and ignore best practice and availability items. So what is my brilliant revelation, you ask? Well, I've created a checklist of course! Before you run to the wood shed and grab the pitchfork, take a look at what I have. My checklist isn’t specific to a product, platform, or regulation. This should be a good general checklist that you can use in any environment and the risky items should become self-evident as you work through the checklist. Here are the goods:
  • Firewall checklist (short) - short and to the point - for use on a regular basis. Use one form per device per quarter (or more frequently if you're able). NetSPI recommends that you look at your firewalls as often as you can, within reason. 
  • Firewall checklist (long) - same as above, but this includes some long form descriptions about why this is on the list, as well as example values. The example can be neutral, positive, or negative. 
So how do I use these documents, you ask? Print out one of the checklists above. The first couple times it may help to use the long form with the explanations so you know what I’m asking and why. Once you’re comfortable, you can start using the short form. Every quarter, or whenever your firewall configuration cycle rolls around, print out a form for each of your firewall and access control devices. Go through the device configuration and fill out the form to the best of your ability. If you get stuck, reach out to any internal network and firewall administrators to help you understand what to write down. When you find an item that needs attention, create an internal project or ticket to correct that configuration or deployment problem. File the form away in a safe place. That’s it! Over time, you should see the overall configuration of the firewalls improve, and you have a review trail that you can give your auditor if they ask about a firewall review requirement. When the business considers buying new firewalls or access control devices, pull out a form and run through it for each proof of concept deployment in your demo environment. If you buy a product and deploy it in demo, run through the checklist before you sign off on the deployment to your production environment. This is version 1 of the document. If you have any feedback, or you know of other useful firewall checklists, please let me know. [post_title] => Firewall Configuration Review [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => firewall-checklist [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:05 [post_modified_gmt] => 2021-04-13 00:06:05 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1146 [menu_order] => 740 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 1201 [post_author] => 8 [post_date] => 2012-07-02 07:00:29 [post_date_gmt] => 2012-07-02 07:00:29 [post_content] => Getting started with virtualization security can be a little daunting. I’m not going to go into a great level of detail, but I do want to point out some sources of information to get you started down the path to securing your virtual datacenters (you did plan the security of the infrastructure before you virtualized, right?). This entire blog entry will be a list of places to find guidance in terms of virtualization security and compliance. It is by no means exhaustive; I’ll leave the rest of the resources out there as an exercise for the reader.

Vendors

The first place to look for security guidance is always the vendors:

Microsoft Hyper-V

Microsoft released Hyper-V as a free hypervisor that runs on top of windows with Windows Server 2008. Here are a couple resources you can use: https://technet.microsoft.com/en-us/library/dd569113.aspx - Hyper-V Security Guide https://www.microsoft.com/en-us/download/details.aspx?id=16650 – Hyper-V Security Guide download

VMware

VMware is the best known, longest running hypervisor out there. Their products have gone through a lot of changes over the years, so it’s pretty important to track the version of VMware/vSphere you’re using closely. Listed below are the hardening guides for each version:

VMware 3 (Seriously? You should update!):

https://www.vmware.com/pdf/vi3_security_hardening_wp.pdf

vSphere 4.0:

https://www.vmware.com/files/pdf/techpaper/VMware_vSphere_HardeningGuide_May10_EN.pdf

vSphere 4.1:

https://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf

vSphere 5 (brand new):

https://communities.vmware.com/servlet/JiveServlet/downloadBody/19605-102-1-26036/HardeningGuide-vSphere50-v1.0.xlsx

Xen

Xen is a very popular open source hypervisor. I couldn’t find any specific hardening documents for Xen, but I believe the standard Linux hardening guides will go a long way. Here is a portal for their documentation: https://xen.org/support/documentation.html

Third Parties

Vendors are great and all, but I think objective third parties provide the most insight into the problem, as they’re not trying to sell you on how great their software is or ram virtual security appliances down your throat.

Defense Information Systems Agency (DISA) STIG:

https://communities.vmware.com/servlet/JiveServlet/downloadBody/9482-102-1-6731/esx_server_stig_v1r1_final.pdf

Cloud Security Alliance:

https://cloudsecurityalliance.org/csaguide.pdf

SANS:

https://www.sans.org/reading_room/analysts_program/vmware-guide-may-2010.pdf

CIS Security Benchmarks:

https://benchmarks.cisecurity.org/en-us/?route=downloads.browse.category.benchmarks.servers.virtualization

Regulatory

Aren’t regulations fun? While not exactly a security data point, regulation guidance is useful at times.

PCI Security Standards Council:

https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf [post_title] => Virtualization Security Resources [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => virtualization-security-resources [to_ping] => [pinged] => [post_modified] => 2021-04-13 00:06:16 [post_modified_gmt] => 2021-04-13 00:06:16 [post_content_filtered] => [post_parent] => 0 [guid] => https://netspiblogdev.wpengine.com/?p=1201 [menu_order] => 800 [post_type] => post [post_mime_type] => [comment_count] => 1 [filter] => raw ) ) [post_count] => 5 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 20716 [post_author] => 91 [post_date] => 2020-12-15 09:41:57 [post_date_gmt] => 2020-12-15 09:41:57 [post_content] =>

As we write this post, you’ve likely heard about the FireEye and U.S. government agency breaches that occurred over the past week. We know now the breaches have been linked back to a supply chain attack on the SolarWinds Orion Platform, a software platform that manages IT operations and products for over 300,000 organizations, including over 425 of the Fortune 500, all ten of the top U.S. telecommunications companies, all five branches of the U.S. Military, all five of the top U.S. accounting firms, and many, many more.

While FireEye, the U.S. Treasury, and National Telecommunications and Information Administration (NTIA) were the first to report a security breach, the breadth of SolarWinds’ customer base is an indicator that the breaches are seemingly the tip of the iceberg.

For the sake of information sharing, here is an overview of the attacks, immediate steps you can take to identify whether you have fallen victim, and tips for protecting your organization as communicated by FireEye, SolarWinds, and NetSPI. For the full technical deep-dive, we highly recommend the FireEye blog post.

Overview: SolarWinds Orion Manual Supply Chain Attack

On December 13, SolarWinds issued a security advisory alerting to a manual supply chain attack on its Orion Platform software builds for versions 2019.4 HF 5 through 2020.2.1, released between March 2020 and June 2020.

FireEye discovered the attack and suggests it is a state-sponsored global intrusion campaign by a group named UNC2452 - though many industry experts are attributing the attack to APT29, a group of hackers associated with the Russian Foreign Intelligence Service.

  • Attack Origin: UNC2452 gained access to victims via trojan-based updates to SolarWinds’ Orion IT monitoring and management software, distributing malware called SUNBURST. Multiple trojanized updates were digitally signed and subsequently deployed via this URL: hxxps://downloads.solarwinds[.]com/solarwinds/CatalogResources/Core/2019.4/2019.4.5220.20574 /SolarWinds-Core-v2019.4.5220-Hotfix5.msp. The downloaded file is a standard Windows Installer Patch file, which includes the trojanized SolarWinds.Orion.Core.BusinessLayer.dll component.
  • How It Works: The digitally signed SolarWinds.Orion.Core.BusinessLayer.dll file is a component of the Orion Improvement Program (OIP) software framework that contains a backdoor that communicates with third party servers via the HTTP protocol. The malicious DLL gets loaded into the legitimate SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe executables and can run dormant for up to two weeks before beaconing to a subdomain of avsvmcloud[.]com. To avoid possible detection, the C2 traffic between the beaconing server and the victim is made to resemble legitimate SolarWinds communications. This includes HTTP GET, HEAD, POST and PUT requests with JSON payloads in their bodies. The HTTP responses from the C2 server communicating with the victim contain XML data that resembles .NET assembly data used for normal SolarWinds operations. Within the XML, however, is obfuscated command information that is deobfuscated and then executed by the SolarWinds process on the victim’s system.
  • Impact/Result: Following the initial compromise and deployment of SUNBURST, a variety of more capable payloads can be deployed to facilitate lateral movement and data theft. Common payloads include TEARDROP and Cobalt Strike BEACON, both of which can be loaded into memory to improve stealth of operations.

Known breaches include:

FireEye: On December 8, FireEye communicated a state-sponsored security breach through which the attackers accessed FireEye’s Red Team assessment tools used to test customers’ security. Following the breach, the company made its list of countermeasures public. FireEye has now confirmed that this attack was a result of the SolarWinds Orion supply chain attack.

U.S. Treasury and the National Telecommunications and Information Administration (NTIA): On December 13, Reuters reported that Russian-associated hackers broke into the U.S. Treasury and Commerce department’s Microsoft 365 software and have been monitoring internal email traffic. Following a National Security Council meeting at the White House over the weekend, the Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive for all federal agencies to power down SolarWinds Orion.

Organizations are frantically working to figure out if they have been a victim of the attack and how to protect themselves. Here are the immediate steps to take, according to SolarWinds, FireEye, and NetSPI’s team of offensive security experts:

  1. First, determine if SolarWinds Orion is deployed within your environment. If unsure, NetSPI recommends performing a network scan to identify the Orion agent. For example, this can be performed with Nmap by running: nmap --open -sT -p 17778,17790 x.x.x.x/xx, where x.x.x.x is the network address and xx is the subnet mask. If the Orion agent is found, follow SolarWinds’ recommendations.
  2. SolarWinds recommends customers upgrade to Orion Platform version 2020.2.1 HF 1 as soon as possible. It also asks customers with any of the products listed on the security advisory for Orion Platform v2019.4 HF 5 to update to 2019.4 HF 6. Additional suggestions can be found in the security advisory. While upgrading Orion will prevent future backdoored deployments from occurring, it will not remediate the potentially infected deployments that have already taken place via the Orion Platform.
  3. Additionally, FireEye provides a list of recommendations including its signatures to detect this threat actor and supply chain attack. Specific details on the YARA, Snort, and ClamAV signatures can be found on FireEye’s public GitHub page.

Get in Touch: To connect with NetSPI for support with testing efforts related to the SolarWinds Orion attack, email info@NetSPI.com.

[post_title] => FireEye, SolarWinds, U.S. Treasury: What’s Happening in the Cyber Security World Right Now? [post_excerpt] => As we write this post, you’ve likely heard about the FireEye and U.S. government agency breaches that occurred over the past week [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => fireeye-solarwinds-us-treasury-whats-happening-in-the-cyber-security-world-right-now [to_ping] => [pinged] => [post_modified] => 2021-05-04 17:03:39 [post_modified_gmt] => 2021-05-04 17:03:39 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=20716 [menu_order] => 442 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 5 [max_num_pages] => 0 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 0743aa6b0eb32e261196eef2f3b09ace [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [allow_query_attachment_by_filename:protected] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X