An error occured while starting service ‘sps’ VMware vSphere profile-driven Storage failed to start

This post was originally published on this site

Hello, I am very new to the community.

 

I am working on new installing and configure the VCSA , to get Vsphere running  receiving an error in the process. I am building the VCSA VM on HP Blade Gen 10 6.7EXSI host

 

“An error occurred while starting service ‘sps’ VMware vSphere Profile-Driven Storage failed to start”

 

I will appreciate any help…Thank you

Hostd, vpxa and the vSphere API/SDK – Confusion on where the APIs actually live

This post was originally published on this site

Hi All,

I’m taking the VMware vSphere Deploy, Manage course and was confused about this:

  • In one slide, the instructor showed that vCenter Server communicated with the ESXi host using vSphere APi/SDK (The VMware Host Client also communicated using this)
  • In another slide, the instructor showed that the vCenter Server communicated with a vCenter agent living on the ESXi host (vpxa). This then communicated with another process called hostd, which then executed commands at the hypervisor…

With the second bullet point in mind, where does the vSphere API/SDK fit in? Is hostd the item that houses the vSphere API? Does vCenter communicate with vpxa, which then communicates with hostd using the vSphere API/SDK?

 

Clarification would be much appreciated.

Proper Disposal of Electronic Devices

This post was originally published on this site

Original release date: October 30, 2018 | Last revised: October 31, 2018

Why is it important to dispose of electronic devices safely?

In addition to effectively securing sensitive information on electronic devices, it is important to follow best practices for electronic device disposal. Computers, smartphones, and cameras allow you to keep a great deal of information at your fingertips, but when you dispose of, donate, or recycle a device you may inadvertently disclose sensitive information which could be exploited by cyber criminals.

Types of electronic devices include:

  • Computers, smartphones, and tablets — electronic devices that can automatically store and process data; most contain a central processing unit and memory, and use an operating system that runs programs and applications.
  • Digital media — these electronic devices create, store, and play digital content. Digital media devices include items like digital cameras and media players.
  • External hardware and peripheral devices — hardware devices that provide input and output for computers, such as printers, monitors, and external hard drives; these devices contain permanently stored digital characters.
  • Gaming consoles — electronic, digital, or computer devices that output a video signal or visual image to display a video game.

What are some effective methods for removing data from your device?

There are a variety of methods for permanently erasing data from your devices (also called sanitizing). Because methods of sanitization vary according to device, it is important to use the method that applies to that particular device.

Methods for sanitization include:

  • Backing up data. Saving your data to another device or a second location (e.g., an external hard drive or the cloud) can help you recover your data if your device is stolen. Options for digital storage include cloud data services, CDs, DVDs, and removable flash drives or removable hard drives (see Using Caution with USB Drives and Protecting Portable Devices: Data Security for more information). Backing up your data can also help you identify exactly what information a thief may have been able to access.
  • Deleting data. Removing data from your device can be one method of sanitization. When you delete files from a device—although the files may appear to have been removed—data remains on the media even after a delete or format command is executed. Do not rely solely on the deletion method you routinely use, such as moving a file to the trash or recycle bin or selecting “delete” from the menu. Even if you empty the trash, the deleted files are still on device and can be retrieved. Permanent data deletion requires several steps.
    • Computers. Use a disk cleaning software designed to permanently remove the data stored on a computer hard drive to prevent the possibility of recovery.
      • Secure erase. This is a set of commands in the firmware of most computer hard drives. If you select a program that runs the secure erase command set, it will erase the data by overwriting all areas of the hard drive.
      • Disk wiping. This is a utility that erases sensitive information on hard drives and securely wipes flash drives and secure digital cards.
    • Smartphones and tablets. Ensure that all data is removed from your device by performing a “hard reset.” This will return the device to its original factory settings. Each device has a different hard reset procedure, but most smartphones and tablets can be reset through their settings. In addition, physically remove the memory card and the subscriber identity module card, if your device has one.
    • Digital cameras, media players, and gaming consoles. Perform a standard factory reset (i.e., a hard reset) and physically remove the hard drive or memory card.
    • Office equipment (e.g., copiers, printers, fax machines, multifunction devices). Remove any memory cards from the equipment. Perform a full manufacture reset to restore the equipment to its factory default.
  • Overwriting. Another method of sanitization is to delete sensitive information and write new binary data over it. Using random data instead of easily identifiable patterns makes it harder for attackers to discover the original information underneath. Since data stored on a computer is written in binary code—strings of 0s and 1s—one method of overwriting is to zero-fill a hard disk and select programs that use all zeros in the last layer. Users should overwrite the entire hard disk and add multiple layers of new data (three to seven passes of new binary data) to prevent attackers from obtaining the original data.
    • Cipher.exe is a built-in command-line tool in Microsoft Windows operating systems that can be used to encrypt or decrypt data on New Technology File System drives. This tool also securely deletes data by overwriting it.
    • Clearing is a level of media sanitation that does not allow information to be retrieved by data, disk, or file recovery utilities. The National Institute of Standards and Technology (NIST) notes that devices must be resistant to keystroke recovery attempts from standard input devices (e.g., a keyboard or mouse) and from data scavenging tools.
  • Destroying. Physical destruction of a device is the ultimate way to prevent others from retrieving your information. Specialized services are available that will disintegrate, burn, melt, or pulverize your computer drive and other devices. These sanitization methods are designed to completely destroy the media and are typically carried out at an outsourced metal destruction or licensed incineration facility. If you choose not to use a service, you can destroy your hard drive by driving nails or drilling holes into the device yourself. The remaining physical pieces of the drive must be small enough (at least 1/125 inches) that your information cannot be reconstructed from them. There are also hardware devices available that erase CDs and DVDs by destroying their surface.
    • Magnetic media degaussers. Degaussers expose devices to strong magnetic fields that remove the data that is magnetically stored on traditional magnetic media.
    • Solid-state destruction. The destruction of all data storage chip memory by crushing, shredding, or disintegration is called solid-state destruction. Solid-State Drives should be destroyed with devices that are specifically engineered for this purpose.
    • CD and DVD destruction. Many office and home paper shredders can shred CDs and DVDs (be sure to check that the shredder you are using can shred CDs and DVDs before attempting this method).

For more information, see the NIST Special Publication 800-88 Guidelines for Media Sanitization.

How can you safely dispose of out-of-date electronic devices?

Electronic waste (sometimes called e-waste) is a term used to describe electronics that are nearing the end of their useful life and are discarded, donated, or recycled. Although donating and recycling electronic devices conserves natural resources, you may still choose to dispose of e-waste by contacting your local landfill and requesting a designated e-waste drop off location. Be aware that although there are many options for disposal, it is your responsibility to ensure that the location chosen is reputable and certified. Visit the Environmental Protection Agency’s (EPA) Electronics Donation and Recycling webpage for additional information on donating and recycling electronics. For information on recycling regulations and facilities in your state, visit the EPA Regulations, Initiatives, and Research on Electronics Stewardship webpage.

This product is provided subject to this Notification and this Privacy & Use policy.

DSC Resource Kit Release October 2018

This post was originally published on this site

We just released the DSC Resource Kit!

This release includes updates to 9 DSC resource modules. In the past 6 weeks, 126 pull requests have been merged and 79 issues have been closed, all thanks to our amazing community!

The modules updated in this release are:

  • ComputerManagementDsc
  • SharePointDsc
  • StorageDsc
  • SqlServerDsc
  • xActiveDirectory
  • xExchange
  • xFailOverCluster
  • xHyper-V
  • xWebAdministration

For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.

xPSDesiredStateConfiguration is also in the pipeline for a release, but the xArchive resource is failing its tests, so that module is currently on hold and will be released when all the tests are passing once again.

Our latest community call for the DSC Resource Kit was on October 10. A recording will be available on YouTube soon. Join us for the next call at 12PM (Pacific time) on November 21 to ask questions and give feedback about your experience with the DSC Resource Kit.

The next DSC Resource Kit release will be on Wednesday, November 28.

We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!

Please see our documentation here for information on the support of these resource modules.

Included in this Release

You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or CHANGELOG.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).

Module Name Version Release Notes
ComputerManagementDsc 6.0.0.0
  • ScheduledTask:
    • Added support for Group Managed Service Accounts, implemented using the ExecuteAsGMSA parameter. Fixes Issue 111
    • Added support to set the Synchronize Across Time Zone option. Fixes Issue 109
  • Added .VSCode settings for applying DSC PSSA rules – fixes Issue 189.
  • BREAKING CHANGE: PowerPlan:
    • Added IsActive Read-Only Property – Fixes Issue 171.
    • InActive power plans are no longer returned with their Name set to null. Now, the name is always returned and the Read-Only property of IsActive is set accordingly.
SharePointDsc 2.6.0.0
  • SPFarm
    • Fixed issue where Central Admin service was not starting for non-english farms
  • SPManagedMetadataServiceApp
    • Added additional content type settings (ContentTypePushdownEnabled & ContentTypeSyndicationEnabled).
    • Fixed issue where Get method would throw an error when the proxy did not exist.
    • Fixed an issue where the resource checks if the proxy exists and if not, it is created.
  • SPSearchContentSource
    • Fixed issue with numerical Content Sources name
    • Fixed issue where the code throws an error when the content source cannot be successfully created
  • SPSearchManagedProperty
    • Added a new resource to support Search Managed Properties
    • Fix for multiple aliases
  • SPSearchResultSource
    • Added a new ScopeUrl parameter to allow for local source creation
  • SPSearchTopology
    • Updated Readme.md to remove some incorrect information
    • Fixed logic to handle the FirstPartitionDirectory in Get-TargetResource
  • SPSelfServiceSiteCreation
    • New resource to manage self-service site creation
  • SPServiceAppSecurity
    • Added local farm token.
    • Fixed issues that prevented the resource to work as expected in many situations.
  • SPSite
    • Added the possibility for creating the default site groups
    • Added the possibility to set AdministrationSiteType
    • Fixed test method that in some cases always would return false
    • Fixed a typo in the values to check for AdministrationSiteType
    • Fixed an access denied issue when creating default site groups when the run as account does not have proper permissions for the site
  • SPTrustedIdentityTokenIssuer
    • Added parameter UseWReplyParameter
  • SPUserProfileServiceApp
    • Fixed issue which was introduced in v2.5 where the service application proxy was not created.
    • Updated resource to grant the InstallAccount permissions to a newly created service application to prevent issues in the Get method.
  • SPUserProfileSyncConnection
    • Fixed issue where empty IncludedOUs and ExcludedOUs would throw an error
  • SPWebAppClientCallableSettings
    • New resource to manage web application client callable settings including proxy libraries.
  • SPWebAppPropertyBag
    • New resource to manage web application property bag
  • SPWebAppSuiteBar
    • Fixed incorrect test method that resulted in this resource to never apply changes.
    • Enable usage of SuiteBarBrandingElementHtml for SharePoint 2016 (only supported if using a SharePoint 2013 masterpage)
SqlServerDsc 12.1.0.0
  • Changes to SqlServerDsc
    • Add support for validating the code with the DSC ResourceKit Script Analyzer rules, both in Visual Studio Code and directly using Invoke-ScriptAnalyzer.
    • Opt-in for common test “Common Tests – Validate Markdown Links”.
    • Updated broken links in README.md and in ExamplesREADME.md
    • Opt-in for common test “Common Tests – Relative Path Length”.
    • Updated the Installation section in the README.md.
    • Updated the Contributing section in the README.md after Style Guideline and Best Practices guidelines has merged into one document.
    • To speed up testing in AppVeyor, unit tests are now run in two containers.
    • Adding the PowerShell script Assert-TestEnvironment.ps1 which must be run prior to running any unit tests locally with Invoke-Pester. Read more in the specific contributing guidelines, under the section Unit Tests.
  • Changes to SqlServerDscHelper
    • Fix style guideline lint errors.
    • Changes to Connect-SQL
      • Adding verbose message in Connect-SQL so it now shows the username that is connecting.
    • Changes to Import-SQLPS
      • Fixed so that when importing SQLPS it imports using the path (and not the .psd1 file).
      • Fixed so that the verbose message correctly shows the name, version and path when importing the module SQLPS (it did show correctly for the SqlServer module).
  • Changes to SqlAg, SqlAGDatabase, and SqlAGReplica examples
    • Included configuration for SqlAlwaysOnService to enable HADR on each node to avoid confusion (issue 1182).
  • Changes to SqlServerDatabaseMail
    • Minor update to Ensure parameter description in the README.md.
  • Changes to Write-ModuleStubFile.ps1
    • Create aliases for cmdlets in the stubbed module which have aliases (issue 1224). Dan Reist (@randomnote1)
    • Use a string builder to build the function stubs.
    • Fixed formatting issues for the function to work with modules other than SqlServer.
  • New DSC resource SqlServerSecureConnection
    • New resource to configure a SQL Server instance for encrypted SQL connections.
  • Changes to SqlAlwaysOnService
    • Updated integration tests to use NetworkingDsc (issue 1129).
  • Changes to SqlServiceAccount
    • Fix unit tests that didn”t mock some of the calls. It no longer fail when a SQL Server installation is not present on the node running the unit test (issue 983).
StorageDsc 4.2.0.0
  • Disk:
    • Added PartitionStyle parameter – Fixes Issue 137.
    • Changed MOF name from MSFT_Disk to MSFTDSC_Disk to remove conflict with Windows built-in CIM class – Fixes Issue 167.
  • Opt-in to Common Tests:
    • Common Tests – Validate Example Files To Be Published
    • Common Tests – Validate Markdown Links
    • Common Tests – Relative Path Length
  • Added .VSCode settings for applying DSC PSSA rules – fixes Issue 168.
  • Disk:
    • Added “defragsvc” service conflict known issue to README.MD – fixes Issue 172.
  • Corrected style violations in StorageDsc.Common module – fixes Issue 153.
  • Corrected style violations in StorageDsc.ResourceHelper module.
xActiveDirectory 2.22.0.0
  • Add PasswordNeverResets parameter to xADUser to facilitate user lifecycle management
  • Update appveyor.yml to use the default template.
  • Added default template files .gitattributes, and .gitignore, and .vscode folder.
  • Added xADForestProperties: New resource to manage User and Principal Name Suffixes for a Forest.
xExchange 1.24.0.0
  • xExchangeHelper.psm1: Renamed common functions to use proper Verb-Noun format. Also addresses many common style issues in functions in the file, as well as in calls to these functions from other files.
  • MSFT_xExchTransportService: Removed functions that were duplicates of helper functions in xExchangeHelper.psm1.
  • Fixes an issue where only objects of type Mailbox can be specified as a Journal Recipient. Now MailUser and MailContact types can be used as well.
  • Update appveyor.yml to use the default template.
  • Added default template files .codecov.yml, .gitattributes, and .gitignore, and .vscode folder.
  • Add Unit Tests for xExchAntiMalwareScanning
  • Add remaining Unit Tests for xExchInstall, and for most common setup functions
  • Added ActionForUnknownFileAndMIMETypes,WSSAccessOnPublicComputersEnabled, WSSAccessOnPrivateComputersEnabled,UNCAccessOnPublicComputersEnabled UNCAccessOnPrivateComputersEnabled and GzipLevel to xExchOwaVirtualDirectory.
  • Added GzipLevel and AdminEnabled to xExchEcpVirtualDirectory.
  • Added OAuthAuthentication to xExchOabVirtualDirectory.
  • Updated readme with the new parameters and removed a bad parameter from xExchOwaVirtualDirectory that did not actually exist.
  • Updated .gitattributes to allow test .pfx files to be saved as binary
  • Added Cumulative Update / Exchange update support to xExchInstall resource.
  • Add remaining Unit Tests for all xExchangeHelper functions that don”t require the loading of Exchange DLL”s.
  • Renamed and moved file Examples/HelperScripts/ExchangeConfigHelper.psm1 to Modules/xExchangeCalculatorHelper.psm1. Renamed functions within the module to conform to proper function naming standards. Added remaining Unit tests for module.
xFailOverCluster 1.11.0.0
  • Changes to xFailOverCluster
    • Update appveyor.yml to use the default template.
    • Added default template files .codecov.yml, .gitattributes, and .gitignore, and .vscode folder.
    • Added FailoverClusters2012.stubs.psm1 from Windows Server 2012 and renamed existing test stub file to FailoverClusters2016.stubs.psm1.
    • Modified Pester Describe blocks to include which version of the FailoverClusters module is being tested.
    • Modified Pester tests to run against 2012 and 2016 stubs in sequence.
  • Changes to xCluster
    • Fixed cluster creation on Windows Server 2012 by checking if the New-Cluster command supports -Force before using it (issue 188).
  • Changes to xClusterQuorum
    • Changed some internal parameter names from the Windows Server 2016 version aliases which are compatible with Windows Server 2012.
  • Changes to xClusterNetwork
    • Fixed Set-TargetResource for Windows Server 2012 by removing call to Update method as it doesn”t exist on this version and updates automatically.
xHyper-V 3.13.0.0
  • MSFT_xVMSwitch:
    • Changed “Id” parameter form read only to optional so the VMSwitch ID can be set on Windows Server 2016. This is important for SDN setups where the VMSwitch ID must remain the same when a Hyper-V host is re-installed.
    • Update appveyor.yml to use the default template.
    • Added default template files .codecov.yml, .gitattributes, and .gitignore, and .vscode folder.
xWebAdministration 2.3.0.0
  • Update appveyor.yml to use the default template.
  • Added default template file .gitattributes, and added default settings for Visual Studio Code.
  • Line endings was fixed in files that was committed with wrong line ending.

How to Find Released DSC Resource Modules

To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.

Of course, you can also always use PowerShellGet (available starting in WMF 5.0) to find modules with DSC Resources:

# To list all modules that tagged as DSCResourceKit
Find-Module -Tag DSCResourceKit 
# To list all DSC resources from all sources 
Find-DscResource

Please note only those modules released by the PowerShell Team are currently considered part of the ‘DSC Resource Kit’ regardless of the presence of the ‘DSC Resource Kit’ tag in the PowerShell Gallery.

To find a specific module, go directly to its URL on the PowerShell Gallery:
http://www.powershellgallery.com/packages/< module name >
For example:
http://www.powershellgallery.com/packages/xWebAdministration

How to Install DSC Resource Modules From the PowerShell Gallery

We recommend that you use PowerShellGet to install DSC resource modules:

Install-Module -Name < module name >

For example:

Install-Module -Name xWebAdministration

To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:

Update-Module

After installing modules, you can discover all DSC resources available to your local system with this command:

Get-DscResource

How to Find DSC Resource Modules on GitHub

All resource modules in the DSC Resource Kit are available open-source on GitHub.
You can see the most recent state of a resource module by visiting its GitHub page at:
https://github.com/PowerShell/< module name >
For example, for the CertificateDsc module, go to:
https://github.com/PowerShell/CertificateDsc.

All DSC modules are also listed as submodules of the DscResources repository in the DscResources folder and the xDscResources folder.

How to Contribute

You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones.
See our contributing guide for more info on how to become a DSC Resource Kit contributor.

If you would like to help, please take a look at the list of open issues for the DscResources repository.
You can also check issues for specific resource modules by going to:
https://github.com/PowerShell/< module name >/issues
For example:
https://github.com/PowerShell/xPSDesiredStateConfiguration/issues

Your help in developing the DSC Resource Kit is invaluable to us!

Questions, comments?

If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.

Katie Keim
Software Engineer
PowerShell DSC Team
@katiedsc (Twitter)
@kwirkykat (GitHub)

US Default keyboard on VMWare Windows equivalent

This post was originally published on this site

So this seems to only happen on certain ESXi versions;

 

I know the root password I have set during install, and I have tested it to be sure by using keyboard on host directly. But when trying to add to Vcenter or login from web client it says password incorrect.

 

I have tried changing my windows keyboard and even sopping out special characters with the ones they could be; eg ‘ instead of @ but no joy.

 

Please, I need to add this host to the vcenter. The ESXi version on there is 6.5U2. The other host with 6.7 and exact same root password and even same physical keyboard used to set password works…

 

Host affected: HP DL380 Gen8 ESXi 6.5U2

Working host: HP DL380 Gen10 ESXi 6.7

vCenter Server 6.0 Update 3g/3h Upgrade or Migration Path

This post was originally published on this site

The upgrade and migration path for vCenter Server 6.0 Update 3g and Update 3h has an important note that you may need to consider. There is currently no upgrade or migration path to vCenter Server 6.5 or 6.7 if you deployed vCenter Server Update 3g or 3h with the embedded Postgres DB. We have noted

The post vCenter Server 6.0 Update 3g/3h Upgrade or Migration Path appeared first on VMware Support Insider.

CEO Fraud

This post was originally published on this site

CEO Fraud / BEC is a type of targeted attack. It commonly involves a cyber criminally pretending to be your boss, then tricking or fooling you into sending the criminal highly sensitive information or initiating a wire transfer. Be highly suspicious of any emails demanding immediate action and/or asking you to bypass any security procedures.

TA18-276B: Advanced Persistent Threat Activity Exploiting Managed Service Providers

This post was originally published on this site

Original release date: October 03, 2018

Systems Affected

Network Systems

Overview

The National Cybersecurity and Communications Integration Center (NCCIC) is aware of ongoing APT actor activity attempting to infiltrate the networks of global managed service providers (MSPs). Since May 2016, APT actors have used various tactics, techniques, and procedures (TTPs) for the purposes of cyber espionage and intellectual property theft. APT actors have targeted victims in several U.S. critical infrastructure sectors, including Information Technology (IT), Energy, Healthcare and Public Health, Communications, and Critical Manufacturing.

This Technical Alert (TA) provides information and guidance to assist MSP customer network and system administrators with the detection of malicious activity on their networks and systems and the mitigation of associated risks. This TA includes an overview of TTPs used by APT actors in MSP network environments, recommended mitigation techniques, and information on reporting incidents.

Description

MSPs provide remote management of customer IT and end-user systems. The number of organizations using MSPs has grown significantly over recent years because MSPs allow their customers to scale and support their network environments at a lower cost than financing these resources internally. MSPs generally have direct and unfettered access to their customers’ networks, and may store customer data on their own internal infrastructure. By servicing a large number of customers, MSPs can achieve significant economies of scale. However, a compromise in one part of an MSP’s network can spread globally, affecting other customers and introducing risk.

Using an MSP significantly increases an organization’s virtual enterprise infrastructure footprint and its number of privileged accounts, creating a larger attack surface for cyber criminals and nation-state actors. By using compromised legitimate MSP credentials (e.g., administration, domain, user), APT actors can move bidirectionally between an MSP and its customers’ shared networks. Bidirectional movement between networks allows APT actors to easily obfuscate detection measures and maintain a presence on victims’ networks.

Note: NCCIC previously released information related to this activity in Alert TA17-117A: Intrusions Affecting Multiple Victims Across Multiple Sectors published on April 27, 2017, which includes indicators of compromise, signatures, suggested detection methods, and recommended mitigation techniques.

Technical Details

APT

APT actors use a range of “living off the land” techniques to maintain anonymity while conducting their attacks. These techniques include using legitimate credentials and trusted off-the-shelf applications and pre-installed system tools present in MSP customer networks.

Pre-installed system tools, such as command line scripts, are very common and used by system administrators for legitimate processes. Command line scripts are used to discover accounts and remote systems.

PowerSploit is a repository of Microsoft PowerShell and Visual Basic scripts and uses system commands such as netsh. PowerSploit, originally developed as a legitimate penetration testing tool, is widely misused by APT actors. These scripts often cannot be blocked because they are legitimate tools, so APT actors can use them and remain undetected on victim networks. Although network defenders can generate log files, APT actors’ use of legitimate scripts makes it difficult to identify system anomalies and other malicious activity.

When APT actors use system tools and common cloud services, it can also be difficult for network defenders to detect data exfiltration. APT actors have been observed using Robocopy—a Microsoft command line tool—to transfer exfiltrated and archived data from MSP client networks back through MSP network environments. Additionally, APT actors have been observed using legitimate PuTTY Secure Copy Client functions, allowing them to transfer stolen data securely and directly to third-party systems.

Impact

A successful network intrusion can have severe impacts to the affected organization, particularly if the compromise becomes public. Possible impacts include

  • Temporary or permanent loss of sensitive or proprietary information,
  • Disruption to regular operations,
  • Financial losses to restore systems and files, and
  • Potential harm to the organization’s reputation.

Solution

Detection

Organizations should configure system logs to detect incidents and to identify the type and scope of malicious activity. Properly configured logs enable rapid containment and appropriate response.

Response

An organization’s ability to rapidly respond to and recover from an incident begins with the development of an incident response capability. An organization’s response capability should focus on being prepared to handle the most common attack vectors (e.g., spearphishing, malicious web content, credential theft). In general, organizations should prepare by

  • Establishing and periodically updating an incident response plan.
  • Establishing written guidelines that prioritize incidents based on mission impact, so that an appropriate response can be initiated.
  • Developing procedures and out-of-band lines of communication to handle incident reporting for internal and external relationships.
  • Exercising incident response measures for various intrusion scenarios regularly, as part of a training regime.
  • Committing to an effort that secures the endpoint and network infrastructure: prevention is less costly and more effective than reacting after an incident.

Mitigation

Manage Supply Chain Risk

MSP clients that do not conduct the majority of their own network defense should work with their MSP to determine what they can expect in terms of security. MSP clients should understand the supply chain risk associated with their MSP. Organizations should manage risk equally across their security, legal, and procurement groups. MSP clients should also refer to cloud security guidance from the National Institute of Standards and Technology to learn about MSP terms of service, architecture, security controls, and risks associated with cloud computing and data protection.[1] [2] [3]

Architecture

Restricting access to networks and systems is critical to containing an APT actor’s movement. Provided below are key items that organizations should implement and periodically audit to ensure their network environment’s physical and logical architecture limits an APT actor’s visibility and access.

Virtual Private Network Connection Recommendations

  • Use a dedicated Virtual Private Network (VPN) for MSP connection. The organization’s local network should connect to the MSP via a dedicated VPN. The VPN should use certificate-based authentication and be hosted on its own device.
  • Terminate VPN within a demilitarized zone (DMZ). The VPN should terminate within a DMZ that is isolated from the internal network. Physical systems used within the DMZ should not be used on or for the internal network.
  • Restrict VPN traffic to and from MSP. Access to and from the VPN should be confined to only those networks and protocols needed for service. All other internal networks and protocols should be blocked. At a minimum, all failed attempts should be logged.
  • Update VPN authentication certificates annually. Update the certificates used to establish the VPN connection no less than annually. Consider rotating VPN authentication certificates every six months.
  • Ensure VPN connections are logged, centrally managed, and reviewed. All VPN connection attempts should be logged in a central location. Investigate connections using dedicated certificates to confirm they are legitimate.

Network Architecture Recommendations

  • Ensure internet-facing networks reside on separate physical systems. All internet-accessible network zones (e.g., perimeter network, DMZ) should reside on their own physical systems, including the security devices used to protect the network environment.
  • Separate internal networks by function, location, and risk profile. Internal networks should be segmented by function, location, and/or enterprise workgroup. All communication between networks should use Access Control Lists and security groups to implement restrictions.
  • Use firewalls to protect server(s) and designated high-risk networks. Firewalls should reside at the perimeter of high-risk networks, including those hosting servers. Access to these networks should be properly restricted. Organizations should enable logging, using a centrally managed logging system.
  • Configure and enable private Virtual Local Area Networks (VLANs). Enable private VLANs and group them according to system function or user workgroup.
  • Implement host firewalls. In addition to the physical firewalls in place at network boundaries, hosts should also be equipped and configured with host-level firewalls to restrict communications from other workstations (this decreases workstation-to-workstation communication).

Network Service Restriction Recommendations

  • Only permit authorized network services outbound from the internal network. Restrict outbound network traffic to only well-known web browsing services (e.g., Transmission Control Protocol [TCP]/80, TCP/443). In addition, monitor outbound traffic to ensure the ports associated with encrypted traffic are not sending unencrypted traffic.
  • Ensure internal and external Domain Name System (DNS) queries are performed by dedicated servers. All systems should leverage dedicated internal DNS servers for their queries. Ensure that DNS queries for external hosts using User Datagram Protocol (UDP)/53 are permitted for only these hosts and are filtered through a DNS reputation service, and that outbound UDP/53 network traffic by all other systems is denied. Ensure that TCP/53 is not permitted by any system within the network environment. All attempts to use TCP/53 and UDP/53 should be centrally logged and investigated.
  • Restrict access to unauthorized public file shares. Access to public file shares that are not used by the organization—such as Dropbox, Google Drive, and OneDrive—should be denied. Attempts to access public file share sites should be centrally logged and investigated. Recommended additional action: monitor all egress traffic for possible exfiltration of data.
  • Disable or block all network services that are not required at network boundary. Only those services needed to operate should be enabled and/or authorized at network boundaries. These services are typically limited to TCP/137, TCP/139, and TCP/445. Additional services may be needed, depending on the network environment, these should be tightly controlled to only send and receive from certain whitelisted Internet Protocol addresses, if possible.
Authentication, Authorization, and Accounting

Compromised account credentials continue to be the number one way threat actors are able to penetrate a network environment. The accounts organizations create for MSPs increase the risk of credential compromise, as MSP accounts typically require elevated access. It is important organizations’ adhere to best practices for password and permission management, as this can severely limit a threat actor’s ability to access and move laterally across a network. Provided below are key items organizations should implement and routinely audit to ensure these risks are mitigated.

Account Configuration Recommendations

  • Ensure MSP accounts are not assigned to administrator groups. MSP accounts should not be assigned to the Enterprise Administrator (EA) or Domain Administrator (DA) groups.
  • Restrict MSP accounts to only the systems they manage. Place systems in security groups and only grant MSP account access as required. Administrator access to these systems should be avoided when possible.
  • Ensure MSP account passwords adhere to organizational policies. Organizational password policies should be applied to MSP accounts. These policies include complexity, life, lockout, and logging.
  • Use service accounts for MSP agents and services. If an MSP requires the installation of an agent or other local service, create service accounts for this purpose. Disable interactive logon for these accounts.
  • Restrict MSP accounts by time and/or date. Set expiration dates reflecting the end of the contract on accounts used by MSPs when those accounts are created or renewed. Additionally, if MSP services are only required during business hours, time restrictions should also be enabled and set accordingly. Consider keeping MSP accounts disabled until they are needed and disabling them once the work is completed.
  • Use a network architecture that includes account tiering. By using an account tiering structure, higher privileged accounts will never have access or be found on lower privileged layers of the network. This keeps EA and DA level accounts on the higher, more protected tiers of the network. Ensure that EA and DA accounts are removed from local administrator groups on workstations.

Logging Configuration Recommendations

  • Enable logging on all network systems and devices and send logs to a central location. All network systems and devices should have their logging features enabled. Logs should be stored both locally and centrally to ensure they are preserved in the event of a network failure. Logs should also be backed up regularly and stored in a safe location.
  • Ensure central log servers reside in an enclave separate from other servers and workstations. Log servers should be isolated from the internet and network environment to further protect them from compromise. The firewall at the internal network boundary should only permit necessary services (e.g., UDP/514).
  • Configure local logs to store no less than seven days of log data. The default threshold for local logging is typically three days or a certain file size (e.g., 5 MB). Configure local logs to store no less than seven days of log data. Seven days of logs will cover the additional time in which problems may not be identified, such as holidays. In the event that only size thresholds are available, NCCIC recommends that this parameter be set to a large value (e.g., 512MB to1024MB) to ensure that events requiring a high amount of log data, such as brute force attacks, can be adequately captured.
  • Configure central logs to store no less than one year of log data. Central log servers should store no less than a year’s worth of data prior to being rolled off. Consider increasing this capacity to two years, if possible.
  • Install and properly configure a Security Information and Event Management (SIEM) appliance. Install a SIEM appliance within the log server enclave. Configure the SIEM appliance to alert on anomalous activity identified by specific events and on significant derivations from baselined activity.
  • Enable PowerShell logging. Organizations that use Microsoft PowerShell should ensure it is upgraded the latest version (minimum version 5) to use the added security of advanced logging and to ensure these logs are being captured and analyzed. PowerShell’s features include advanced logging, interaction with application whitelisting (if using Microsoft’s AppLocker), constrained language mode, and advanced malicious detection with Antimalware Scan Interface. These features will help protect an organization’s network by limiting what scripts can be run, logging all executed commands, and scanning all scripts for known malicious behaviors.
  • Establish and implement a log review process. Logs that go unanalyzed are useless. It is critical to network defense that organizations establish a regular cycle for reviewing logs and developing analytics to identify patterns.
Operational Controls

Building a sound architecture supported by strong technical controls is only the first part to protecting a network environment. It is just as critical that organizations continuously monitor their systems, update configurations to reflect changes in their network environment, and maintain relationships with MSPs. Listed below are key operational controls organizations should incorporate for protection from threats.

Operational Control Recommendations

  • Create a baseline for system and network behavior. System, network, and account behavior should be baselined to make it easier to track anomalies within the collected logs. Without this baseline, network administrators will not be able to identify the “normal” behaviors for systems, network traffic, and accounts.
  • Review network device configurations every six months. No less than every six months, review the active configurations of network devices for unauthorized settings (consider reviewing more frequently). Baseline configurations and their checksums should be stored in a secure location and be used to validate files.
  • Review network environment Group Policy Objects (GPOs) every six months. No less than every six months, review GPOs for unauthorized settings (consider reviewing more frequently). Baseline configurations and their checksums should be stored in a secure location and be used to validate files.
  • Continuously monitor and investigate SIEM appliance alerts. The SIEM appliance should be continuously monitored for alerts. All events should be investigated and documented for future reference.
  • Periodically review SIEM alert thresholds. Review SIEM appliance alert thresholds no less than every three months. Thresholds should be updated to reflect changes, such as new systems, activity variations, and new or old services being used within the network environment.
  • Review privileged account groups weekly. Review privileged account groups—such as DAs and EAs—no less than weekly to identify any unauthorized modifications. Consider implementing automated monitoring for these groups.
  • Disable or remove inactive accounts. Periodically monitor accounts for activity and disable or remove accounts that have not been active within a certain period, not to exceed 30 days. Consider including account management into the employee onboarding and offboarding processes.
  • Regularly update software and operating systems. Ensuring that operating systems and software is up-to-date is critical for taking advantage of a vendor’s latest security offerings. These offerings can include mitigating known vulnerabilities and offering new protections (e.g., credential protections, increased logging, forcing signed software).

It is important to note that—while the recommendations provided in this TA aim at preventing the initial attack vectors and the spread of any malicious activity—there is no single solution to protecting and defending a network. NCCIC recommends network defenders use a defense-in-depth strategy to increase the odds of successfully identifying an intrusion, stopping malware, and disrupting threat actor activity. The goal is to make it as difficult as possible for an attacker to be successful and to force them to use methods that are easier to detect with higher operational costs.

Report Unauthorized Network Access

Contact DHS or your local FBI office immediately. To report an intrusion and request resources for incident response or technical assistance, contact NCCIC at (NCCICCustomerService@hq.dhs.gov or 888-282-0870), FBI through a local field office, or the FBI’s Cyber Division (CyWatch@fbi.gov or 855-292-3937).

References

Revision History

  • October, 3 2018: Initial version

This product is provided subject to this Notification and this Privacy & Use policy.

TA18-276A: Using Rigorous Credential Control to Mitigate Trusted Network Exploitation

This post was originally published on this site

Original release date: October 03, 2018

Systems Affected

Network Systems

Overview

This technical alert addresses the exploitation of trusted network relationships and the subsequent illicit use of legitimate credentials by Advanced Persistent Threat (APT) actors. It identifies APT actors’ tactics, techniques, and procedures (TTPs) and describes the best practices that could be employed to mitigate each of them. The mitigations for each TTP are arranged according to the National Institute of Standards and Technology (NIST) Cybersecurity Framework core functions of Protect, Detect, Respond, and Recover.

Description

APT actors are using multiple mechanisms to acquire legitimate user credentials to exploit trusted network relationships in order to expand unauthorized access, maintain persistence, and exfiltrate data from targeted organizations. Suggested best practices for administrators to mitigate this threat include auditing credentials, remote-access logs, and controlling privileged access and remote access.

Impact

APT actors are conducting malicious activity against organizations that have trusted network relationships with potential targets, such as a parent company, a connected partner, or a contracted managed service provider (MSP). APT actors can use legitimate credentials to expand unauthorized access, maintain persistence, exfiltrate data, and conduct other operations, while appearing to be authorized users. Leveraging legitimate credentials to exploit trusted network relationships also allows APT actors to access other devices and other trusted networks, which affords intrusions a high level of persistence and stealth.

Solution

Recommended best practices for mitigating this threat include rigorous credential and privileged-access management, as well as remote-access control, and audits of legitimate remote-access logs. While these measures aim to prevent the initial attack vectors and the spread of malicious activity, there is no single proven threat response.

Using a defense-in-depth strategy is likely to increase the odds of successfully disrupting adversarial objectives long enough to allow network defenders to detect and respond before the successful completion of a threat actor’s objectives.

Any organization that uses an MSP to provide services should monitor the MSP’s interactions within their organization’s enterprise networks, such as account use, privileges, and access to confidential or proprietary information. Organizations should also ensure that they have the ability to review their security and monitor their information hosted on MSP networks.

APT TTPs and Corresponding Mitigations

The following table displays the TTPs employed by APT actors and pairs them with mitigations that network defenders can implement.

Table 1: APT TTPs and Mitigations

APT TTPs Mitigations
Preparation
  • Allocate operational infrastructure, such as Internet Protocol addresses (IPs).
  • Gather target credentials to use for legitimate access.

Protect:

  • Educate users to never click unsolicited links or open unsolicited attachments in emails.
  • Implement an awareness and training program.

Detect:

  • Leverage multi-sourced threat-reputation services for files, Domain Name System (DNS), Uniform Resource Locators (URLs), IPs, and email addresses.
Engagement
  • Use legitimate remote access, such as virtual private networks (VPNs) and Remote Desktop Protocol (RDP).
  • Leverage a trusted relationship between networks.

Protect:

  • Enable strong spam filters to prevent phishing emails from reaching end users.
  • Authenticate inbound email using Sender Policy Framework; Domain-Based Message Authentication, Reporting and Conformance; and DomainKeys Identified Mail to prevent email spoofing.
  • Prevent external access via RDP sessions and require VPN access.
  • Enforce multi-factor authentication and account-lockout policies to defend against brute force attacks.

Detect:

  • Leverage multi-sourced threat-reputation services for files, DNS, URLs, IPs, and email addresses.
  • Scan all incoming and outgoing emails to detect threats and filter out executables.
  • Audit all remote authentications from trusted networks or service providers for anomalous activity.

Respond and Recover:

  • Reset credentials, including system accounts.
  • Transition to multifactor authentication and reduce use of password-based systems, which are susceptible to credential theft, forgery, and reuse across multiple systems.
Presence

Execution and Internal Reconnaissance:

  • Write to disk and execute malware and tools on hosts.
  • Use interpreted scripts and run commands in shell to enumerate accounts, local network, operating system, software, and processes for internal reconnaissance.
  • Map accessible networks and scan connected targets.

Lateral Movement:

  • Use remote services and log on remotely.
  • Use legitimate credentials to move laterally onto hosts, domain controllers, and servers.
  • Write to remote file shares, such as Windows administrative shares.

Credential Access:

  • Locate credentials, dump credentials, and crack passwords.

Protect:

  • Deploy an anti-malware solution, which also aims to prevent spyware and adware.
  • Prevent the execution of unauthorized software, such as Mimikatz, by using application whitelisting.
  • Deploy PowerShell mitigations and, in the more current versions of PowerShell, enable monitoring and security features.
  • Prevent unauthorized external access via RDP sessions. Restrict workstations from communicating directly with other workstations.
  • Separate administrative privileges between internal administrator accounts and accounts used by trusted service providers.
  • Enable detailed session-auditing and session-logging.

Detect:

  • Audit all remote authentications from trusted networks or service providers.
  • Detect mismatches by correlating credentials used within internal networks with those employed on external-facing systems.
  • Log use of system administrator commands, such as net, ipconfig, and ping.
  • Audit logs for suspicious behavior.
  • Use whitelist or baseline comparison to monitor Windows event logs and network traffic to detect when a user maps a privileged administrative share on a Windows system.
  • Leverage multi-sourced threat-reputation services for files, DNS, URLs, IPs, and email addresses.

Respond and Recover:

  • Reset credentials.
  • Monitor accounts associated with a compromise for abnormal behaviors, including unusual connections to nonstandard resources or attempts to elevate privileges, enumerate, or execute unexpected programs or applications.
Effect
  • Maintain access to trusted networks while gathering data from victim networks.
  • Compress and position data for future exfiltration in archives or in unconventional locations to avoid detection.
  • Send over command and control channel using data-transfer tools (e.g., PuTTY secure copy client [PSCP], Robocopy).

Protect:

  • Prevent the execution of unauthorized software, such as PSCP and Robocopy.

Detect:

  • Monitor for use of archive and compression tools.
  • Monitor egress traffic for anomalous behaviors, such as irregular outbound connections, malformed or abnormally large packets, or bursts of data to detect beaconing and exfiltration.

 

Detailed Mitigation Guidance

Manage Credentials and Control Privileged Access

Compromising the credentials of legitimate users automatically provides a threat actor access to the network resources available to those users and helps that threat actor move more covertly through the network. Adopting and enforcing a strong-password policy can reduce a threat actor’s ability to compromise legitimate accounts; transitioning to multifactor authentication solutions increases the difficulty even further. Additionally, monitoring user account logins—whether failed or successful—and deploying tools and services to detect illicit use of credentials can help network defenders identify potentially malicious activity.

Threat actors regularly target privileged accounts because they not only grant increased access to high-value assets in the network, but also more easily enable lateral movement, and often provide mechanisms for the actors to hide their activities. Privileged access can be controlled by ensuring that only those users requiring elevated privileges are granted those accesses and, in accordance with the principle of least privilege, by restricting the use of those privileged accounts to instances where elevated privileges are required for specific tasks. It is also important to carefully manage and monitor local-administrator and MSP accounts because they inherently function with elevated privileges and are often ignored after initial configuration.

A key way to control privileged accounts is to segregate and control administrator (admin) privileges. All administrative credentials should be tightly controlled, restricted to a function, or even limited to a specific amount of time. For example, only dedicated workstation administrator accounts should be able to administer workstations. Server accounts, such as general, Structured Query Language, or email admins, should not have administrative access to workstations. The only place domain administrator (DA) or enterprise administrator (EA) credentials should ever be used is on a domain controller. Both EA and DA accounts should be removed from the local-administrators group on all other devices. On UNIX devices, sudo (or root) access should be tightly restricted in the same manner. Employing a multifactor authentication solution for admin accounts adds another layer of security and can significantly reduce the impact of a password compromise because the threat actor needs the other factor—that is, a smartcard or a token—for authentication.

Additionally, administrators should disable unencrypted remote-administrative protocols and services, which are often enabled by default. Protocols required for operations must be authorized, and the most secure version must be implemented. All other protocols must be disabled, particularly unencrypted remote-administrative protocols used to manage network infrastructure devices, such as Telnet, Hypertext Transfer Protocol, File Transfer Protocol, Trivial File Transfer Protocol, and Simple Network Management Protocol versions 1 and 2.

Control Remote Access and Audit Remote Logins

  • Control legitimate remote access by trusted service providers. Similar to other administrative accounts, MSP accounts should be given the least privileges needed to operate. In addition, it is recommended that MSP accounts either be limited to work hours, when they can be monitored, or disabled until work needs to be done. MSP accounts should also be held to the same or higher levels of security for credential use, such as multifactor authentication or more complex passwords subject to shorter expiration timeframes.
  • Establish a baseline on the network. Network administrators should work with network owners or MSPs to establish what normal baseline behavior and traffic look like on the network. It is also advisable to discuss what accesses are needed when the network is not being actively managed. This will allow local network personnel to know what acceptable cross-network or MSP traffic looks like in terms of ports, protocols, and credential use.
  • Monitor system event logs for anomalous activity. Network logs should be captured to help detect and identify anomalous and potentially malicious activity. In addition to the application whitelisting logs, administrators should ensure that other critical event logs are being captured and stored, such as service installation, account usage, pass-the-hash detection, and RDP detection logs. Event logs can help identify the use of tools like Mimikatz and the anomalous use of legitimate credentials or hashes. Baselining is critical for effective event log analysis, especially in the cases of MSP account behavior.
  • Control Microsoft RDP. Adversaries with valid credentials can use RDP to move laterally and access information on other, more sensitive systems. These techniques can help protect against the malicious use of RDP:
    • Assess the need to have RDP enabled on systems and, if required, limit connections to specific, trusted hosts.
    • Verify that cloud environments adhere to best practices, as defined by the cloud service provider. After the cloud environment setup is complete, ensure that RDP ports are not enabled unless required for a business purpose.
    • Place any system with an open RDP port behind a firewall and require users to communicate via a VPN through a firewall.
    • Perform regular checks to ensure RDP port 3389 is not open to the public internet. Enforce strong-password and account-lockout policies to defend against brute force attacks.
    • Enable the restricted-administrator option available in Windows 8.1 and Server 2012 R2 to ensure that reusable credentials are neither sent in plaintext during authentication nor cached.
  • Restrict Secure Shell (SSH) trusts. It is important that SSH trusts be carefully managed and secured because improperly configured and overly permissive trusts can provide adversaries with initial access opportunities and the means for lateral movement within a network. Access lists should be configured to limit which users are able to log in via SSH, and root login via SSH should be disabled. Additionally, the system should be configured to only allow connections from specific workstations, preferably administrative workstations used only for the purpose of administering systems.

Report Unauthorized Network Access

Contact DHS or your local FBI office immediately. To report an intrusion and request resources for incident response or technical assistance, contact NCCIC at (NCCICCustomerService@hq.dhs.gov or 888-282-0870), FBI through a local field office, or the FBI’s Cyber Division (CyWatch@fbi.gov or 855-292-3937).

References

    Revision History

    • October, 3 2018: Initial version

    This product is provided subject to this Notification and this Privacy & Use policy.

    TA18-275A: HIDDEN COBRA – FASTCash Campaign

    This post was originally published on this site

    Original release date: October 02, 2018 | Last revised: October 08, 2018

    Systems Affected

    Retail Payment Systems

    Overview

    This joint Technical Alert (TA) is the result of analytic efforts between the Department of Homeland Security (DHS), the Department of the Treasury (Treasury), and the Federal Bureau of Investigation (FBI). Working with U.S. government partners, DHS, Treasury, and FBI identified malware and other indicators of compromise (IOCs) used by the North Korean government in an Automated Teller Machine (ATM) cash-out scheme—referred to by the U.S. Government as “FASTCash.” The U.S. Government refers to malicious cyber activity by the North Korean government as HIDDEN COBRA. For more information on HIDDEN COBRA activity, visit https://www.us-cert.gov/hiddencobra.

    FBI has high confidence that HIDDEN COBRA actors are using the IOCs listed in this report to maintain a presence on victims’ networks to enable network exploitation. DHS, FBI, and Treasury are distributing these IOCs to enable network defense and reduce exposure to North Korean government malicious cyber activity.

    This TA also includes suggested response actions to the IOCs provided, recommended mitigation techniques, and information on reporting incidents. If users or administrators detect activity associated with the malware families associated with FASTCash, they should immediately flag it, report it to the DHS National Cybersecurity and Communications Integration Center (NCCIC) or the FBI Cyber Watch (CyWatch), and give it the highest priority for enhanced mitigation.

    NCCIC conducted analysis on 10 malware samples related to this activity and produced a Malware Analysis Report (MAR). MAR-10201537 – HIDDEN COBRA FASTCash-Related Malware examines the tactics, techniques, and procedures observed in the malware. Visit the MAR-10201537 page for the report and associated IOCs.

    Description

    Since at least late 2016, HIDDEN COBRA actors have used FASTCash tactics to target banks in Africa and Asia. At the time of this TA’s publication, the U.S. Government has not confirmed any FASTCash incidents affecting institutions within the United States.

    FASTCash schemes remotely compromise payment switch application servers within banks to facilitate fraudulent transactions. The U.S. Government assesses that HIDDEN COBRA actors will continue to use FASTCash tactics to target retail payment systems vulnerable to remote exploitation.

    According to a trusted partner’s estimation, HIDDEN COBRA actors have stolen tens of millions of dollars. In one incident in 2017, HIDDEN COBRA actors enabled cash to be simultaneously withdrawn from ATMs located in over 30 different countries. In another incident in 2018, HIDDEN COBRA actors enabled cash to be simultaneously withdrawn from ATMs in 23 different countries.  

    HIDDEN COBRA actors target the retail payment system infrastructure within banks to enable fraudulent ATM cash withdrawals across national borders. HIDDEN COBRA actors have configured and deployed legitimate scripts on compromised switch application servers in order to intercept and reply to financial request messages with fraudulent but legitimate-looking affirmative response messages. Although the infection vector is unknown, all of the compromised switch application servers were running unsupported IBM Advanced Interactive eXecutive (AIX) operating system versions beyond the end of their service pack support dates; there is no evidence HIDDEN COBRA actors successfully exploited the AIX operating system in these incidents.

    HIDDEN COBRA actors exploited the targeted systems by using their knowledge of International Standards Organization (ISO) 8583—the standard for financial transaction messaging—and other tactics. HIDDEN COBRA actors most likely deployed ISO 8583 libraries on the targeted switch application servers. Malicious threat actors use these libraries to help interpret financial request messages and properly construct fraudulent financial response messages.

    This graphic illustrates the way HIDDEN COBRA actors use compromised switch application servers to approve financial transactions

    Figure 1: Anatomy of a FASTCash scheme

    A review of log files showed HIDDEN COBRA actors making typos and actively correcting errors while configuring the targeted server for unauthorized activity. Based on analysis of the affected systems, analysts believe that the scripts —used by HIDDEN COBRA actors and explained in the Technical Details section below—inspected inbound financial request messages for specific primary account numbers (PANs). The scripts generated fraudulent financial response messages only for the request messages that matched the expected PANs. Most accounts used to initiate the transactions had minimal account activity or zero balances.

    Analysts believe HIDDEN COBRA actors blocked transaction messages to stop denial messages from leaving the switch and used a GenerateResponse* function to approve the transactions. These response messages were likely sent for specific PANs matched using CheckPan()verification (see figure 1 for additional details on CheckPan()).

    Technical Details

    HIDDEN COBRA actors used malicious Windows executable applications, command-line utility applications, and other files in the FASTCash campaign to perform transactions and interact with financial systems, including the switch application server. The initial infection vector used to compromise victim networks is unknown; however, analysts surmise HIDDEN COBRA actors used spear-phishing emails in targeted attacks against bank employees. HIDDEN COBRA actors likely used Windows-based malware to explore a bank’s network to identify the payment switch application server. Although these threat actors used different malware in each known incident, static analysis of malware samples indicates similarities in malware capabilities and functionalities.

    HIDDEN COBRA actors likely used legitimate credentials to move laterally through a bank’s network and to illicitly access the switch application server. This pattern suggests compromised systems within a bank’s network were used to access and compromise the targeted payment switch application server.

    Although some of the files used by HIDDEN COBRA actors were legitimate, and not inherently malicious, it is likely that HIDDEN COBRA actors used these legitimate files for malicious purposes. See MAR-10201537 for details on the files used. Malware samples obtained for analysis included AIX executable files intended for a proprietary UNIX operating system developed by IBM. The IBM AIX executable files were designed to conduct code injection and inject a library into a currently running process. One of the sample AIX executables obtained provides export functions, which allows an application to perform transactions on financial systems using the ISO 8583 standard.

    Upon successful compromise of a bank’s payment switch application server, HIDDEN COBRA actors likely deployed legitimate scripts—using command-line utility applications on the payment switch application server—to enable fraudulent behavior by the system in response to what would otherwise be normal payment switch application server activity. Figure 1 depicts the pattern of fraudulent behavior. The scripts alter the expected behavior of the server by targeting the business process, rather than exploiting a technical process. 

    During analysis of log files associated with known FASTCash incidents, analysts identified the following commonalities:

    • Execution of .so (shared object) commands using the following pattern: /tmp/.ICE-unix/e <PID> /tmp.ICE-unix/<filename>m.so <argument>
      • The process identifier, filename, and argument varied between targeted institutions. The tmp directory typically contains the X Window System session information.
    • Execution of the script which contained a similar, but slightly different, command: ./sun <PID>/tmp/.ICE-unix/engine.so  <argument>
      • The file is named sun and runs out of the /tmp/.ICE-unix directory.

    Additionally, both commands use either the inject (mode 0) or eject (mode 1) argument with the following ISO 8583 libraries:

    • m.so [with argument “0” or “1”]
    • m1.so [with argument “0” or “1”]
    • m2.so [with argument “0” or “1”]
    • m3.so [with argument “0” or “1”]

    Detection and Response

    NCCIC recommends administrators review bash history logs of all users with root privileges. Administrators can find commands entered by users in the bash history logs; these would indicate the execution of scripts on the switch application server. Administrators should log and monitor all commands.

    The U.S. Government recommends that network administrators review MAR-10201537 for IOCs related to the HIDDEN COBRA FASTCash campaign, identify whether any of the provided IOCs fall within their organization’s network, and—if found—take necessary measures to remove the malware.

    Impact

    A successful network intrusion can have severe impacts, particularly if the compromise becomes public. Possible impacts to the affected organization include

    • Temporary or permanent loss of sensitive or proprietary information,
    • Disruption to regular operations,
    • Financial costs to restore systems and files, and
    • Potential harm to an organization’s reputation.

    Solution

    Mitigation Recommendations for Institutions with Retail Payment Systems

    Require Chip and Personal Identification Number Cryptogram Validation

    • Implement chip and Personal Identification Number (PIN) requirements for debit cards.
    • Validate card-generated authorization request cryptograms.
    • Use issuer-generated authorization response cryptograms for response messages.
    • Require card-generated authorization response cryptogram validation to verify legitimate response messages. 

    Isolate Payment System Infrastructure

    • Require two-factor authentication before any user can access the switch application server.
    • Verify that perimeter security controls prevent internet hosts from accessing the private network infrastructure servicing your payment switch application server.
    • Verify that perimeter security controls prevent all hosts outside of authorized endpoints from accessing your system.

    Logically Segregate Operating Environments

    • Use firewalls to divide operating environments into enclaves.
    • Use Access Control Lists (ACLs) to permit or deny specific traffic from flowing between those enclaves.
    • Give special considerations to enclaves holding sensitive information (e.g., card management systems) from enclaves requiring internet connectivity (e.g., email).

    Encrypt Data in Transit

    • Secure all links to payment system engines with a certificate-based mechanism, such as mutual transport layer security, for all traffic external or internal to the organization.
    • Limit the number of certificates used on the production server, and restrict access to those certificates.

    Monitor for Anomalous Behavior as Part of Layered Security

    • Configure the switch application server to log transactions. Routinely audit transactions and system logs.
    • Develop a baseline of expected software, users, and logons. Monitor switch application servers for unusual software installations, updates, account changes, or other activity outside of expected behavior.
    • Develop a baseline of expected transaction participants, amounts, frequency, and timing. Monitor and flag anomalous transactions for suspected fraudulent activity.

    Recommendations for Organizations with ATM or Point-of-Sale Devices

    • Implement chip and PIN requirements for debit cards.
    • Require and verify message authentication codes on issuer financial request response messages.
    • Perform authorization response cryptogram validation for Europay, Mastercard, and Visa transactions.

    Mitigation Recommendations for All Organizations

    NCCIC encourages users and administrators to use the following best practices to strengthen the security posture of their organization’s systems:

    • Maintain up-to-date antivirus signatures and engines.
    • Keep operating system patches up-to-date.
    • Disable file and printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
    • Restrict users’ ability (i.e., permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
    • Enforce a strong password policy and require regular password changes.
    • Exercise caution when opening email attachments, even if the attachment is expected and the sender appears to be known.
    • Enable a personal firewall on organization workstations, and configure it to deny unsolicited connection requests.
    • Disable unnecessary services on organization workstations and servers.
    • Scan for and remove suspicious email attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
    • Monitor users’ web browsing habits; restrict access to sites with content that could pose cybersecurity risks.
    • Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs).
    • Scan all software downloaded from the internet before executing.
    • Maintain situational awareness of the latest cybersecurity threats.
    • Implement appropriate ACLs.

    For additional information on malware incident prevention and handling, see the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-83: Guide to Malware Incident Prevention and Handling for Desktops and Laptops.[1]

    Response to Unauthorized Network Access

    Contact DHS or your local FBI office immediately. To report an intrusion and request resources for incident response or technical assistance, contact NCCIC at (NCCICCustomerService@hq.dhs.gov or 888-282-0870), FBI through a local field office, or the FBI’s Cyber Division (CyWatch@fbi.gov or 855-292-3937).

    References

    Revision History

    • October 2, 2018: Initial version

    This product is provided subject to this Notification and this Privacy & Use policy.