TA18-331A: 3ve – Major Online Ad Fraud Operation

This post was originally published on this site

Original release date: November 27, 2018

Systems Affected

Microsoft Windows

Overview

This joint Technical Alert (TA) is the result of analytic efforts between the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI). DHS and FBI are releasing this TA to provide information about a major online ad fraud operation—referred to by the U.S. Government as “3ve”—involving the control of over 1.7 million unique Internet Protocol (IP) addresses globally, when sampled over a 10-day window.

Description

Online advertisers desire premium websites on which to publish their ads and large numbers of visitors to view those ads. 3ve created fake versions of both (websites and visitors), and funneled the advertising revenue to cyber criminals. 3ve obtained control over 1.7 million unique IPs by leveraging victim computers infected with Boaxxe/Miuref and Kovter malware, as well as Border Gateway Protocol-hijacked IP addresses. 

Boaxxe/Miuref Malware

Boaxxe malware is spread through email attachments and drive-by downloads. The ad fraud scheme that utilizes the Boaxxe botnet is primarily located in a data center. Hundreds of machines in this data center are browsing to counterfeit websites. When these counterfeit webpages are loaded into a browser, requests are made for ads to be placed on these pages. The machines in the data center use the Boaxxe botnet as a proxy to make requests for these ads. A command and control (C2) server sends instructions to the infected botnet computers to make the ad requests in an effort to hide their true data center IPs.

Kovter Malware

Kovter malware is also spread through email attachments and drive-by downloads. The ad fraud scheme that utilizes the Kovter botnet runs a hidden Chromium Embedded Framework (CEF) browser on the infected machine that the user cannot see. A C2 server tells the infected machine to visit counterfeit websites. When the counterfeit webpage is loaded in the hidden browser, requests are made for ads to be placed on these counterfeit pages. The infected machine receives the ads and loads them into the hidden browser.

Impact

For the indicators of compromise (IOCs) below, keep in mind that any one indicator on its own may not necessarily mean that a machine is infected. Some IOCs may be present for legitimate applications and network traffic as well, but are included here for completeness.

Boaxxe/Miuref Malware

Boaxxe malware leaves several executables on the infected machine. They may be found in one or more of the following locations:

  • %UserProfile%AppDataLocalVirtualStorelsass.aaa
  • %UserProfile%AppDataLocalTemp<RANDOM>.exe
  • %UserProfile%AppDataLocal<Random eight-character folder name><original file name>.exe

The HKEY_CURRENT_USER (HKCU) “Run” key is set to the path to one of the executables created above.

  • HKCUSoftwareMicrosoftWindowsCurrentVersionRun<Above path to executable>

Kovter Malware

Kovter malware is found mostly in the registry, but the following files may be found on the infected machine:

  • %UserProfileAppDataLocalTemp<RANDOM> .exe/.bat
  • %UserProfile%AppDataLocalMicrosoftWindowsTemporary Internet FilesContent.IE5<RANDOM><RANDOM FILENAME>.exe
  • %UserProfile%AppDataLocal<RANDOM><RANDOM>.lnk
  • %UserProfile%AppDataLocal<RANDOM><RANDOM>.bat

Kovter is known to hide in the registry under:

  • HKCUSOFTWARE<RANDOM><RANDOM>

The customized CEF browser is dropped to:

  • %UserProfile%AppDataLocal<RANDOM>

The keys will look like random values and contain scripts. In some values, a User-Agent string can be clearly identified. An additional key containing a link to a batch script on the hard drive may be placed within registry key:

  • HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun

There are several patterns in the network requests that are made by Kovter malware when visiting the counterfeit websites. The following are regex rules for these URL patterns:

  • /?ptrackp=d{5,8}
  • /feedrsd/click?feed_id=d{1,5}&sub_id=d{1,5}&cid=[a-f0-9-]*&spoof_domain=[w.d-_]*&land_ip=d{1,3}.d{1,3}.d{1,3}.d{1,3}
  • /feedrsd/vast_track?a=impression&feed_id=d{5}&sub_id=d{1,5}&sub2_id=d{1,5}&cid=[a-fd-]

The following is a YARA rule for detecting Kovter:

rule KovterUnpacked {
  meta:
    desc = "Encoded strings in unpacked Kovter samples."
  strings:
    $ = "7562@3B45E129B93"
    $ = "@ouhKndCny"
    $ = "@ouh@mmEdctffdsr"
    $ = "@ouhSGQ"
  condition:
    all of them
}

Solution

If you believe you may be a victim of 3ve and its associated malware or hijacked IPs, and have information that may be useful to investigators, submit your complaint to www.ic3.gov and use the hashtag 3ve (#3ve) in the body of your complaint.

DHS and FBI advise users to take the following actions to remediate malware infections associated with Boaxxe/Miuref or Kovter:

  • Use and maintain antivirus software. Antivirus software recognizes and protects your computer against most known viruses. Security companies are continuously updating their software to counter these advanced threats. Therefore, it is important to keep your antivirus software up-to-date. If you suspect you may be a victim of malware, update your antivirus software definitions and run a full-system scan. (See Understanding Anti-Virus Software for more information.)
  • Avoid clicking links in email. Attackers have become very skilled at making phishing emails look legitimate. Users should ensure the link is legitimate by typing the link into a new browser. (See Avoiding Social Engineering and Phishing Attacks.)
  • Change your passwords. Your original passwords may have been compromised during the infection, so you should change them. (See Choosing and Protecting Passwords.)
  • Keep your operating system and application software up-to-date. Install software patches so that attackers cannot take advantage of known problems or vulnerabilities. You should enable automatic updates of the operating system if this option is available. (See Understanding Patches and Software Updates for more information.)
  • Use anti-malware tools. Using a legitimate program that identifies and removes malware can help eliminate an infection. Users can consider employing a remediation tool. A non-exhaustive list of examples is provided below. The U.S. Government does not endorse or support any particular product or vendor.

References

Revision History

  • November 27, 2018: Initial version

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

Windows 10 1809 Upgrade failes

This post was originally published on this site

Hello,

 

we have about 400 Windows 10 VDIs in use. We are currently trying to install the upgrade Windows 10 1809. Our hard disk controllers are available as SCSI controllers. During the upgrade the virtual machine gets stuck in the boot screen and does a rollback. The failure “The installation failed in the SAFE OS phase with an error during the INSTALL_UPDATES operation” appears.  If I connect the hard disks to the IDE controller, the upgrade works. The latest VMWare tools are already installed (10.3.5). But we wouldn’t like to switch all VDIs to IDE controllers. Is there a general problem?  I hope someone has an another idea. Thanks in advance.

 

With kind regards
Dominik Geb

Is there a recommended value on QFullSampleSize,QFullThreshold on vSAN??

This post was originally published on this site

Configuration

 ・ESXi 6.5 U2

 ・HPE 3PAR StoreServ is connected with iSCSI

 ・vSAN is also connected

 

Question

・We are doing troubleshooting on performance and we are trying to change the value of QFullSampleSize
and QFullThreshold (default is 0,8) to 32,4

・Do we need to reboot before we set up all these stuff

 

Thank you

 

 

HPE Custom Image for ESXi 6.7 + Proliant Microserver Gen10 No IPMI capabilities

This post was originally published on this site

Hi there,

I’m really a newbie, so I may be asking something stupid, but I hope you can help me.

I downloaded and installed the HPE Custom Image for ESXi 6.7 GA Install CD on a HPE Proliant Microserver Gen 10 and everything went smoothly.

The thing now is about monitoring.

On the web client I go to Host > Monitor and the system says: This system has no IPMI capabilities, you may need to install a driver to enable sensor data to be retrieved.

Since here https://www.hpe.com/it/it/servers/hpe-esxi.html you can read (in Italian) “it supports Gen 9 and newer servers”

My understanding was that using this image I would not need to install anything else to monitor stuff like the RAID controller status.

 

Can you help me?

 

The final goal is to get to know ESXi, in order to make a step forward and offer our customers a better service but I am moving my first steps in this V-world and everything is really interesting but overwhelming.

 

Thanks in advance.

Phone Call Attacks

This post was originally published on this site

More and more scams and attacks are happening over the phone. Whenever you get an urgent phone call on the phone pressuring you to do something (such as a caller pretending to be the tax department or Microsoft Tech Support) be very suspicious. It’s most likely a scammer trying to trick you out of money or pressure you into making a mistake. Protect yourself, simply hang up the phone. You are not being rude, the person on the other line is trying to take advantage of you.

Email and Emotions

This post was originally published on this site

Never send an email when you are angry; you will most likely regret it later. Instead, when you are emotional and want to reply to someone, open up an email and write everything you feel, but do not send it. (Be sure there is no name in the TO field so that you do not accidently send it.) After you have vented, save the email and come back an hour later. You only want to reply to any type of emotional situation after you have had time to cool down.

Website Security

This post was originally published on this site

Original release date: November 1, 2018 | Last revised: June 30, 2020

What is website security?

Website security refers to the protection of personal and organizational public-facing websites from cyberattacks.

Why should I care about website security?

Cyberattacks against public-facing websites—regardless of size—are common and may result in:

  • Website defacement,
  • Loss of website availability or denial-of-service (DoS) condition,
  • Compromise of sensitive customer or organizational data,
  • An attacker taking control of the affected website, or
  • Use of website as a staging point for watering hole attacks.

These threats affect all aspects of information security—confidentiality, integrity, and availability—and can gravely damage the reputation of the website and its owner. For example, organization and personal websites that fall victim to defacement, DoS, or data breach may experience financial loss due to eroded user trust or a decrease in website visitors.

What steps can my organization take to protect against website attacks?

There are multiple steps organizations and security professionals should take to properly secure their websites. Note: organizations should talk to their website hosting provider or managed service provider to discuss roles and responsibilities for implementing security measures.

1.    Secure domain ecosystems.

  • Review registrar and Domain Name System (DNS) records for all domains.
  • Change all default password that were provided from your domain registrar and DNS.
    • Default credentials are not secure—they are usually readily available on the internet. Changing default usernames and passwords will prevent an attack that leverages default credentials. (See Choosing and Protecting Passwords for information on creating strong passwords.)
  • Enforce multi-factor authentication (MFA). (See Supplementing Passwords for more information)
  • Monitor certificate transparency logs.

Review CISA Emergency Directive 19-01 and CISA Cyber Insights: Mitigate DNS Infrastructure Tampering for more information.

2.    Secure user accounts.

  • Enforce MFA on all internet-accessible accounts—prioritizing those with privileged access.
  • Implement the principle of least privilege and disable unnecessary accounts and privileges.
  • Change all default usernames and passwords.

Review CISA Cyber Insights: Enhance Email and Web Security for more information.

3.    Continuously scan for—and remediate—critical and high vulnerabilities.

  • Patch all critical and high vulnerabilities within 15 and 30 days, respectively, on internet-accessible systems. Be sure to scan for configuration vulnerabilities in addition to software vulnerabilities.
    • Enable automatic updates whenever possible.
  • Replace unsupported operating systems, applications, and hardware.

Review CISA Emergency Directive 19-01 and CISA Cyber Insights: Remediate Vulnerabilities for Internet-Accessible Systems for more information.

4.    Secure data in transit.

  • Disable Hypertext Transfer Protocol (HTTP); enforce Hypertext Transfer Protocol Secure (HTTPS) and HTTP Strict Transport Security (HSTS).
    • Website visitors expect their privacy to be protected. To ensure communications between the website and user are encrypted, always enforce the use of HTTPS, and enforce the use of HSTS where possible. For further information and guidance, see the U.S. Chief Information Officer (CIO) and the Federal CIO Council’s webpage on the HTTPS-Only Standard. Preload HSTS for all domains, when possible.
  • Disable weak cyphers (SSLv2, SSlv3, 3DES, RC4).

Review CISA Binding Operational Directive 18-01 and CISA Cyber Insights: Enhance Email and Web Security for more information.

5.    Backup data.

  • Employ a backup solution that automatically and continuously backs up critical data and system configurations from your website.
  • Keep your backup media in a safe and physically remote environment.
  • Test disaster recovery scenarios.

6.    Secure web applications. 

  • Identify and remediate the top 10 most critical web application security risks; then move on to other less critical vulnerabilities. (Refer to OWASP Top 10 for a list of the most critical web application security risks.)
  • Enable logging and regularly audit website logs to detect security events or improper access.
    • Send the logs to a centralized log server.
  • Implement MFA for user logins to web applications and the underlying website infrastructure.

7.    Secure web servers. 

  • Use security checklists.
    • Audit and harden configurations based on security checklists specific to each application (e.g., Apache, MySQL) on the system.
  • Use application allow listing and disable modules or features that provide capabilities that are not necessary for business needs.
  • Implement network segmentation and segregation.
    • Network segmentation and segregation makes it more difficult for attackers to move laterally within connected networks. For example, placing the web server in a properly configured demilitarized zone (DMZ) limits the type of network traffic permitted between systems in the DMZ and systems in the internal corporate network.
  • Know where your assets are.
    • You must know where your assets are in order to protect them. For example, if you have data that does not need to be on the web server, remove it to protect it from public access.

What are some additional steps to protect against website attacks?

  • Sanitize all user input. Sanitize user input, such as special characters and null characters, at both the client end and the server end. Sanitizing user input is especially critical when it is incorporated into scripts or structured query language statements.
  • Increase resource availability. Configure website caching to optimize resource availability. Optimizing a website’s resource availability increases the chance that it will withstand unexpectedly high amounts of traffic during DoS attacks.
  • Implement cross-site scripting (XSS) and cross-site request forgery (XSRF) protections. Protect website systems, as well as website visitors, by implementing XSS and XSRF protections.
  • Implement a Content Security Policy (CSP). Website owners should also consider implementing a CSP. Implementing a CSP lessens the chances of an attacker successfully loading and running malicious JavaScript on the end user machine.
  • Audit third-party code. Audit third-party services (e.g., ads, analytics) to validate that no unexpected code is being delivered to the end user. Website owners should weigh the pros and cons of vetting the third-party code and hosting it on the web server (as opposed to loading the code from the third party).
  • Implement additional security measures. Additional measures include:
    • Running static and dynamic security scans against the website code and system,
    • Deploying web application firewalls,
    • Leveraging content delivery networks to protect against malicious web traffic, and
    • Providing load balancing and resilience against high amounts of traffic.

Additional Information

For additional guidance, see:

Subscribe to Cybersecurity and Infrastructure Security Agency (CISA) Current Activities to stay current on the latest website technology vulnerabilities.

Author: CISA

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

Website Security

This post was originally published on this site

Original release date: November 1, 2018

What is website security?

Website security refers to the protection of personal and organizational public-facing websites from cyberattacks.

Why should I care about website security?

Cyberattacks against public-facing websites—regardless of size—are common. An attack to your website could

  • Cause defacement,
  • Cause a denial-of-service (DoS) condition,
  • Enable the attacker to obtain sensitive information, or
  • Enable the attacker to take control of the affected website.

Organization and personal websites that fall victim to defacement or DoS may experience financial loss due to eroded user trust or a decrease in website visitors.

A cyberattack that causes a data breach places your company’s intellectual property and your users’ personally identifiable information (PII) at risk of theft.

Cyber criminals may attack websites because of financial incentives such as the theft and sale of intellectual property and PII, ransomware payouts, and cryptocurrency mining (see Defending Against Illicit Cryptocurrency Mining Activity). Cyber criminals may also be motivated to attack websites for ideological reasons, e.g., to gain publicity and notoriety for a terrorist organization through defacing a government website.

What security threats are associated with websites?

Possible cyberattacks against your website include those commonly reported in the media, such as website defacement and DoS—which make the information services provided by the website unavailable for users (see Understanding Denial-of-Service Attacks). An even more severe website attack scenario may result in the compromise of customer data (e.g., PII). These threats affect all aspects of security—confidentiality, integrity, and availability—and can gravely damage the reputation of the website and its owner.

A more subtle attack—one that may not be immediately evident to the website’s owner or user—occurs when an attacker pivots from a compromised web server to the website owner’s corporate network, which contains an abundance of sensitive information that may be at risk of exposure, modification, or destruction. Once an attacker uses a compromised website to enter a corporate network, other assets may be available to the attacker, including user credentials, PII, administrative information, and technical vulnerabilities. Additionally, by compromising the website platform, an attacker may be able to repurpose the website infrastructure as a platform from which they can launch attacks against other systems.

How can I improve my cybersecurity protection against website attacks?

Organizations and individuals can protect their websites by applying the following the best practices to their web servers:

  • Implement the principle of least privilege. Ensure that all users have the least amount of privilege necessary on the web server (including interactive end users and service accounts).
  • Use multifactor authentication. Implement multifactor authentication for user logins to web applications and the underlying website infrastructure.
  • Change default vendor usernames and passwords. Default vendor credentials are not secure—they are usually readily available on the internet. Changing default usernames and passwords will prevent an attack that leverages default credentials.
  • Disable unnecessary accounts. Disable accounts that are no longer necessary, such as guest accounts or individual user accounts that are no longer in use.
  • Use security checklists. Audit and harden configurations based on security checklists specific to each application (e.g., Apache, MySQL) on the system.
  • Use application whitelisting. Use application whitelisting and disable modules or features that provide capabilities that are not necessary for business needs.
  • Use network segmentation and segregation. Network segmentation and segregation makes it more difficult for attackers to move laterally within connected networks. For example, placing the web server in a properly configured demilitarized zone (DMZ) limits the type of network traffic permitted between systems in the DMZ and systems in the internal corporate network.
  • Know where your assets are. You must know where your assets are in order to protect them. For example, if you have data that does not need to be on the web server, remove it to protect it from public access.
  • Protect the assets on the web server. Protect assets on the web server with multiple layers of defense (e.g., limited user access, encryption at rest).
  • Practice healthy cyber hygiene.
    • Patch systems at all levels—from web applications and backend database applications, to operating systems and hypervisors.
    • Perform routine backups, and test disaster recovery scenarios.
    • Configure extended logging and send the logs to a centralized log server.

What are some additional steps I can take to protect against website attacks?

  • Sanitize all user input. Sanitize user input, such as special characters and null characters, at both the client end and the server end. Sanitizing user input is especially critical when it is incorporated into scripts or structured query language statements.
  • Increase resource availability. Configure your website caching to optimize resource availability. Optimizing your website’s resource availability increases the chance that your website will withstand unexpectedly high amounts of traffic during DoS attacks.
  • Implement cross-site scripting (XSS) and cross-site request forgery (XSRF) protections. Protect your website system, as well as visitors to your website, by implementing XSS and XSRF protections.
  • Implement a Content Security Policy (CSP). Website owners should also consider implementing a CSP. Implementing a CSP lessens the chances of an attacker successfully loading and running malicious JavaScript on the end user machine.
  • Audit third-party code. Audit third-party services (e.g., ads, analytics) to validate that no unexpected code is being delivered to the end user. Website owners should weigh the pros and cons of vetting the third-party code and hosting it on the web server (as opposed to loading the code from the third party).
  • Implement hypertext transfer protocol secure (HTTPS) and HTTP strict transport security (HSTS). Website visitors expect their privacy to be protected. To ensure communications between the website and user are encrypted, always enforce the use of HTTPS, and enforce the use of HSTS where possible. For further information and guidance, see the U.S. Chief Information Officer (CIO) and the Federal CIO Council’s webpage on the HTTPS-Only Standard.
  • Implement additional security measures. Additional measures include
    • Running static and dynamic security scans against the website code and system,
    • Deploying web application firewalls,
    • Leveraging content delivery networks to protect against malicious web traffic, and
    • Providing load balancing and resilience against high amounts of traffic.

For additional guidance, visit the Open Web Application Security Project Top 10 Cheat Sheet on common critical risks to web applications, the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-44: Guidelines on Securing Public Web Servers, and NIST SP 800-95: Guide to Secure Web Services. Subscribe to NCCIC Current Activities to stay current on the latest website technology vulnerabilities.

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