log4j Vulnerability Response
Orbital contains two exploratory queries, Linux Log4j Monitoring (
linux_log4j_monitoring) and Windows Log4j Monitoring (
windows_log4j_monitoring), which can potentially identify servers, environmental variables, processes, other Java programs, and/or other entities that may be affected by the
Currently, these queries operate on Linux and Windows.
Note: These queries can take quite a while to return results, due to YARA’s scans and its path collection on Windows.
Orbital Linux Node 1.17, 2021-12-01
Orbital node support for Linux, shipping with
osquery version 4.8.0. See the supported platforms for details on specific versions.
The new machine: prefix can be used for endpoint selection on the Query page and endpoint search on the Endpoints page to identify the Linux endpoint with the given machine ID.
The new anyconnectudid: prefix can be used for endpoint selection on the Query page and endpoint search on the Endpoints page to identify the Linux endpoint with the given AnyConnect UDID.
Orbital 1.17, 2021-11-29
Added a Save Empty Results toggle to the Schedule Orbital Job form, on the Query page. This function allows the user to only send the results that have rows to a remote data store. In the Query API the related field is set with the
RequireRowsparameter, which defaults to
false, preserving the legacy behavior of sending all results to the Remote Data Store.
Added the ability to rename scheduled queries from the context menu on the Jobs page. Clicking on the vertical ellipsis menu will display the Jobs context menu from which you can select the new Rename menu command.
Added the Run Once radio button to the Schedule Orbital Job form, on the Query page. This function allows you the same functionality as that of specifying a zero (0) value for the Scheduled query’s interval parameter. Refer to the Scheduled Query’s Run Once function section for more information.
Added the ability to type an existing query’s
queryId, if there are more than one queries with the same name) as a value for the
link:parameter is typed into the Endpoints field on the Query page.
Orbital 1.16, 2021-10-19
Linked Queries are new to Orbital in release 1.16. They allow you to use the node list from one or more existing queries as the node list or lists for a new query, provided that the existing query or queries return results that are not empty. For more information, refer to Linked Queries.
The ellipsis menu () and the related Random Endpoints menu on the Query page have been replaced with individual icons. The new icons are:
- - This is the Clear Endpoints icon. Clicking this icon will remove any endpoints listed in the Endpoints field.
- - This is the Copy Endpoints icon. Clicking this icon will copy all of the endpoints listed in the Endpoints field.
- - This is the Linked Endpoints icon. Clicking this icon will display a list of existing queries that can be used by the Linked Queries feature.
- - This is Add Random Endpoints icon. Clicking this icon will display the Add Random Endpoints menu, from which you can specify how many randomly selected endpoints will be added to the Endpoints field.
An Operating System Filter popup has been added to Orbital’s Query page, under the left-side of the Endpoints field. This popup will help you narrow the endpoints to a specific operating system and is related to the
allowosprefix introduced in Release 1.15. The Operating System Filter popup is accessed by clicking the Operating System Filter icon .
Known Issues in 1.16
There is an issue in version 4.8.0 and onwards of
osquery that can cause an error to be returned when running queries against the
windows_eventlog table. The error triggers only when certain log data is present in the Windows Event Log. Subsequent custom queries run against an affected node will return results without issue. Subsequent Orbital catalog queries will also return results but will return an error alongside the query:
bookkeeping osquery failed. This will not affect the returned results, however the error will persist until the Orbital node service is restarted on the endpoint.
If this issue is encountered, the WMI class table
Win32_NtLogEvent can be used as a workaround for affected queries.
Orbital 1.15, 2021-08-25
- Organizational Catalog (called
Organization Queriesin UI) - users may save custom queries
- My Recent Queries
- My Favorite Queries
- Organizational Catalog (called
Netmask prefix support in endpoint search
allowosprefix (see Specifying Nodes as Subjects of Queries)
Features to support beta release of macOS Orbital node (see below)
- Added support for
- Ability to select random macOS nodes
- Added support for
Orbital Node, 2021-08-26
Orbital node support for macOS version 10.15 or later.
Note: Customers must be running Secure Endpoint (formerly AMP for Endpoints) Connector version 1.16.0 and enable the Orbital policy. Customers are advised that this release should be considered an in-field Beta and refer to the macOS Troubleshooting page for any issues.
- Support for Forensic Snapshots initiated in Secure Endpoint
- Support for 41 macOS-specific and 46 cross-platform queries
Support for Apple’s current beta of their next major release - Monterrey (v.12) - is not supported at this time.
Orbital Node 1.14, 2021-07-26
Orbital now supports the use of proxy settings that users configure in their Secure Endpoint policy settings.
Note: Secure Endpoint Connector version 7.4.1 or later must be installed before you can use proxies. Refer to your Secure Endpoint users' guide for more information on configuring your Secure Endpoint connector policy settings.
OSQuery version 4.8.0 is included in the Orbital Node 1.14 update.
An Orbital node version policy has been implemented. This policy allows nodes to be identified by Orbital as being Supported, Unsupported, or Rejected.
Supported nodes are those nodes that are up-to-date or are only one version behind the current node version. These nodes will be identified in green and are allowed to connect to Orbital.
Unsupported nodes are those nodes that are two or more versions behind the current version (current version and one version older than the current version). These nodes are identified in yellow. They are still allowed to connect to Orbital and be queried by Orbital, but should be updated.
Rejected nodes are those nodes that are old enough that they are no longer supported by the Orbital service. These nodes are identified in red and will not be allowed to connect to the Orbital service.
Refer to the Support Policy for Orbital Node Versions of the Nodes topic for more information on the node version policy
Orbital 1.14, 2021-06-29
Orbital 1.14 provides a number of bug fixes, internal improvements, and user facing features:
Assetspage renamed to
Ability to add labels to custom SQL stanzas to better identify results.
Display human readable hostnames when random nodes are selected for a query.
Historical data is now easier to visualize with mini line charts for organization metrics, and results line charts.
Endpoints can now be targeted in queries with a netmask prefix. Several prefixes now support wildcards in both query targeting and node search.
Previously, each time an S3 Remote Data Store (RDS) was created or associated with an Orbital Query, a small ping file was created in the user’s bucket to verify connectivity and write access. Now, S3 RDS pings update a single file named
orbital-rds-ping.json, which can be safely removed at any time.
Soon, Secure Endpoint users will have more control over when they upgrade their node. Orbital will categorize nodes into three states according to their version:
rejected. A range of node versions will be
supported, which means they contain the latest features. A range of nodes will be
accepted, which means that while they can still connect to the service with the same functionality they’ve always had, they no longer support the latest functionality. The final category are those nodes that are refused connection to Orbital. Rejected nodes must upgrade in order to connect again.
- A Node version status tile is provided on the dashboard to display a summary for the organization.
currentnode version, as well as the minimum
acceptednode versions are available in the /ok endpoint.
- Node version and version status is displayed in the Endpoints table and Endpoint Details view.
- Nodes that have not connected in 90 days will no longer be displayed on the Endpoints page.
Orbital 1.13, 2021-05-04
Orbital 1.13 provides a number of improvements and bug fixes.
A powerful new way to target endpoints in a query, and search for endpoints on the Endpoints page. Note that endpoints that have not connected to the Orbital service for many months may lack the necessary metadata to be accessible through the nodeversion and osqueryversion prefix.
Query page displays featured queries and other queries to explore.
The Query Catalog has been expanded and updated.
Orbital 1.12, 2021-04-03
Orbital 1.12 provides a number of internal changes in preparation for supporting SecureX.
Orbital 1.11, 2021-01-06
Orbital 1.11 provides a number of bug fixes and improvements.
New Job Results page displays details for up to 25 endpoint responses per page; the first 500 endpoint responses can be downloaded. See Jobs for more information.
Orbital offers increased time ranges for metrics data: Last hour, Last 24 hours, Last 7 days, Last 30 days, Last 60 days, and Last 90 days.
Orbital 1.10, 2020-10-30
Orbital now supports sending results via Remote Data Store to Splunk and Amazon S3, with a choice of internal payload formats.
Orbital 1.10 also provides a number of bug fixes and internal improvements, and several user facing features:
Orbital will provide announcements via the UI.
Results sent to the Private Intelligence Data Store can be searched by Job ID.
Endpoints can be searched by any identifier prefix.
Orbital provides visibility into multiple endpoints configured with identical Secure Endpoint Computer GUIDs by automatically giving those endpoints new and unique internal identifiers. These nodes will be identified on the UI as clones. Endpoints in this situation that have not updated to Orbital endpoint (node) version 1.10 will remain connected but unable to process queries until they update. For more details see the FAQ. FAQ.
Orbital 1.9, 2020-09-08
Orbital 1.9 provides a number of bug fixes and internal performance and infrastructure improvements.
Beginning with Orbital 1.9, scheduling a Job with a Remote Data Store will ping the data store to verify it exists and can be authenticated to before allowing the query to proceed. This will prevent avoidable result delivery failures.
This release also begins the process of discovering when multiple endpoints are configured with identical Secure Endpoint Computer GUIDs, so each of those nodes can be uniquely identified. In 1.9, nodes in that scenario will not be allowed to run queries.
Orbital 1.8, 2020-07-10
Orbital 1.8 provides a number of bug fixes and internal improvements.
The Query API allows specifying a random set of nodes as targets for a query.
Orbital 1.7, 2020-06-10
Orbital 1.7 moves our installers from S3 to our own update servers, so Orbital can be installed on hosts under Secure Endpoint host isolation. This lets you investigate a host while it is isolated without having previously enabled Orbital. This change also makes it possible to add Orbital’s installation servers to firewall policies by IP address. (See Required Server Addresses for Proper Secure Endpoint & Threat Grid Operations for more information.)
This update also integrates information from WMI in osquery. This lets us disable our osquery event subscriptions, which were causing performance issues on hosts that had unusually high volumes of Windows events.
The following tables are available in Orbital 1.7 on Windows, in addition to those in osquery, using WMI classes. (The table names are taken directly from their associated WMI classes.)
AntiVirusProduct– Installed Windows Antivirus products.
FirewallProduct– Information about installed firewall products.
Malware– Malware sightings reported to SecurityCenter by antivirus products.
Win32_DeviceGuard– Status of Windows DeviceGuard on Windows 10 Professional and Server endpoints.
Win32_NtEventLogFile– Information about Windows Event Log files.
Win32_NtLogEvent– Windows log events.
Win32_OptionalFeature– Status of installed Windows features.
Win32_OSRecoveryConfiguration– Windows recovery configuration.
Win32_Printer– Installed printers.
Win32_Registry– Information about Windows registry files.
Win32_ShortcutFile– Information about Windows shortcuts.
Win32_Tpm– Is a Trusted Platform Module active and enabled?
Win32_UserAccount– Lists user accounts registered with Windows.
Win32_WinSat– Windows System Assessment scores.
In addition, we have added the following tables:
dns_cache– Access to the Windows DNS cache for identifying recent domain name lookups.
We have also had to remove the following tables, which depended on the osquery eventing framework and were nonperformant on hosts with high volumes of Windows log events:
orbital_powershell_events, which uses the same data source but uses WMI instead of the eventing framework.
We regret this change, since it may disrupt existing queries and requires changing
orbital_powershell_events when using queries from the osquery community.
Orbital 1.6, 2020-05-04
Orbital 1.6 makes some subtle changes in how we identify the type of observable values in query results. Previously, we used a set of regular expressions to make an educated guess about whether a value was a SHA-256 hash, domain name or network address so we can use Cisco Threat Response (CTR) to provide context and actions. Now, Orbital 1.6 will look at the column name infer the type based on some simple rules:
- Is the column name the same as one of the CTR observable types, like: domain, sha256 or ip? If so, that is the type.
- Does the column name start with one of the observable types, like domain_1? If so, use that.
- Otherwise, does the column name end with one of the observable types, like dst_ip? If so, we use that.
This change does not affect our catalog of stock queries, which already contain metadata that specifies the observable type for each column. With this change, you can now send the results of your custom queries to your CTR Private Intelligence repository. (Previously, you could only send the results of stock queries, which carries metadata that identifies the observable types.)
Frequently Used Observable Types
CTR and the Cisco Threat Intelligence Model (CTIM) define a large number of observable types, here are a few that are frequently used:
- sha256 – The SHA-256 hash of a file or other entity, in hexadecimal encoding. (See also md5 and sha1 for other hashes.)
- ip – A IPv4 network address. (See ipv6 for IPv6 addresses.)
- domain – A DNS domain name.
- hostname – A computer host name.
For an exhaustive list, see Observables in CTIM Sightings.
Orbital 1.5, 2020-04-07
Orbital 1.5 lets customer administrators authorize other users to use Orbital and introduces support for Windows Server 2016 and later. We have also started aggregating metrics for Cisco SecureX components and APIs. There are a lot of changes below the waterline this release that we are eager to share when SecureX is ready for beta.
- Orbital for Non-Administrators. Administrators can manage access to Orbital for other users in their organization.
- Windows Server Support. We now support Windows Server 2016 and later.
Orbital 1.4, 2020-03-11
Orbital 1.4 builds on last month’s release by adding Cisco Threat Response (CTR) pivot menus to common observables and provides support for automatically sending results to private intelligence stores. This advanced feature enables configuring periodic queries associated with current threats to CTR so you can monitor for affected hosts.
We have also exposed the Orbital API v0 which lets customers build applications that can run queries and collect results. This feature is important to our objective of exposing information about your endpoints to your security applications.
- API Documentation. Without documentation, it would be very difficult to discover and learn how to use Orbital APIs. We are working on a Python reference module as well.
- Theme support. You can switch Orbital to high contrast, white on black or low contrast greys on blues.
- Orbital Pivot Menus. Orbital can present actions from your CTR modules next to observable types, such as domain names, file hashes and network addresses.
Orbital 1.3, 2020-02-14
Orbital 1.3 adds Cisco Threat Response (CTR) to our user interface. We send common observables while you view results to CTR to identify values that are known malicious or innocuous by your team and intelligence providers. This also adds support for Casebook so you can quickly send observables from your query results to CTR for later investigation.
- Documentation. As Orbital adds more features, it is even more important to show you how they work and inform you about changes.
- Guided UI for new users. Orbital’s live query user interface is unique to our product, and we find it necessary to coach new users on how to specify nodes, use the catalog and schedule queries.
Orbital 1.2, 2020-01-31
Orbital 1.2 introduces independent clouds for EU and APJC customers. We consider your information to be most sensitive, and we want to be sure you can choose the regulatory region that you and your organization can trust. We are growing our operations team to ensure we have coverage around the world in case there are any support issues.
- Threat Grid integration. Threat Grid’s expert system will suggest Orbital queries based on sample analysis to search your environment for hosts that may be at risk.