Login
The last few years have proved to be a catalyst for digital transformation for many of our enterprise customers. Application modernization and adopting multicloud are the foundational building blocks for digitizing business. Customers employ CI/CD (continuous integration, continuous delivery) to modernize their applications, building them on a cloud infrastructure. This evolution has given rise to new application security challenges in terms of speed, scale, as well as new and unfamiliar control points – not to mention siloed organizations and tools.
To address these security challenges, Cisco Secure Workload delivers zero trust microsegmentation in an infrastructure, location, and form factor agnostic way. It safeguards application workloads, wherever they live across the hybrid and multicloud environment. The recent release of Secure Workload 3.7 introduces “policy as code” support – delivering security at the speed of DevOps. It enables Secure Workload to be integrated with the customer’s choice of CI/CD toolchains, such as Jenkins or GitLab, and ingest the application security policy during the build phase of the application. Secure Workload then renders the policies onto the relevant workloads when the application goes live.
As the graphic below illustrates, Secure Workload ingests policies using Terraform or Ansible, which are widely adopted tools used by the DevOps team to automate infrastructure related tasks. Secure Workload integrates with the CI/CD toolchains using a YAML (.yml) manifest to ingest the policy. It then programs the same policies to the relevant enforcement point to achieve least privilege access for the newly built or upgraded application.
Policy as code helps customers automate policy deployment at the speed and scale of modern applications. It also simplifies collaboration between DevOps/DevSecOps and NetSec teams. The policies are written in the application language and give appropriate controls to developers to write their requirements into the application while the NetSec team ensures full compliance to the infosec policies dictated by the CISO organization.
In summary, Secure Workload removes the barriers to achieving automated application deployment across highly distributed multicloud environments, without compromising security, compliance, or user experience. The result – stronger security, faster application deployment, and more efficient collaboration.
For more information on policy as code, contact your Cisco Account Team or Partner Account Manager.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Geez we've been getting hammered down here: Optus, MyDeal, Vinomofo, Medibank and now Australian Clinical Labs. It's crazy how much press interest there's been down here and whilst I think some of it is a bit hyperbolic, bringing the issue to the forefront and ensuring it's being discussed is certainly a good thing. Anyway, let's see what happens between now and next week's video, at this rate there'll be at least one more major Aussie breach to talk about!
Vernon has been our Manager of Technical Accounting for more than two years, but that doesn’t mean he’s busy with spreadsheets and numbers all day.
It’s been an amazing ride so far. My team touches on several areas of responsibility, including financial period closing, financial reporting, and accounting for complex transactions.
The most rewarding part of my role is definitely the variety and complexity – they really go hand-in-hand and I enjoy asking questions and figuring out the solutions, even when there is not always a textbook answer. I enjoy the challenge of working collectively with a team to find solutions by applying research and experience to a set of facts.
It’s also rewarding to be able to collaborate with auditors and other stakeholders who would be interested in the results.
My favorite thing about working at McAfee is the team. We have an amazing team. It’s full of really smart people. I’ve seen some companies try and find the best talent they can, but McAfee has just taken that to a whole different level. Everyone in their respective areas is really tuned in to the broader effort and we work well together. At McAfee, we enjoy both a high level of talent and collaborative effort. You don’t often find both in the same place.
I really believe that each person brings certain strengths to the table, and they should be able to exercise those strengths to develop and expand their capabilities. Once those natural roles are established, it’s best to trust them to determine how best to perform in their roles and collaborate with the team in achieving results that add value to the broader group.
First, expect the unexpected – consider each new experience an opportunity for personal growth.
Secondly, get involved in projects. If you have the opportunity to do something different or work with a cross-functional team, do it. It builds your own skill base, which opens the door for greater future opportunities and you get to meet people outside of your own department and develop relationships that may prove valuable over time.
The post For some, accounting is more than just spreadsheets! Vernon’s McAfee Journey appeared first on McAfee Blog.
With passwords and MFA out of the way, let’s next look at connected apps or services that are tied to our priority accounts. When you log into other sites on the web through Facebook, Google, or another social account, as well as when you install social media apps or games, you are sharing information about those accounts with those services. This may be as limited as the email address and username on file, or may include much more information like your friends list, contacts, likes/subscriptions, or more.
A well-known example of this data-harvesting method is the Cambridge Analytica story, where installing a social media app opened up access to much more information than users realized. (Note: as mentioned in the linked article, Facebook added protective measures to limit the amount of data available to app developers, but connected accounts can still present a liability if misused.)
With this in mind, look under the Security or Privacy section of each of your account’s settings, and review where you have either used this account to log into a third-party website or allowed access when installing an app. Here are some handy links to some of the most common services to check:
If you aren’t going to use the app again or don’t want to share any details, remove them. Once you’ve checked your accounts, repeat this process with all the apps installed on your phone.
Just like connecting a social account to a third-party game can share information like your contact info and friend’s list, installing an app on your mobile device can share information including your contacts, camera roll and more. Fortunately, mobile OSes have gotten much better at notifying users before installation on what information is shared, so you should be able to see which apps might be nosier than you’re comfortable with.
Finally — and this is really for the nerds and techies out there — check if you have any API (short for “application programming interface”) keys or browser extensions connected to your accounts. API keys are commonly used to let different apps or services “talk” between one another. They let you use services like Zapier or IFTTT to do things like have your Spotify favorites automatically saved to a Google Sheet, or check Weather Underground to send a daily email with the forecast.
Browser extensions let you customize a web browser and integrate services, like quickly clicking to save an article for review on a “read it later” service like Instapaper. Even if you trust the developer when installing these apps, they may pose a risk later on if they are recovered or taken over by an attacker. These “zombie extensions” rely on a broad install base from a legitimate service which can later be misused to gather information or launch attacks by a malicious developer.
We’ve made great progress already, and taken steps to help defend your accounts from prying eyes going forward – now it’s time to lock down your previous activities on social media. Rather than enumerate every option on every service, I’ll highlight some common tools and privacy settings you’ll want to check:
Before moving on to email, I’ll add another plug for the NYT Social Media Security and Privacy Checklists if you, like me, would rather have a series of boxes to mark off while going through each step above.
Security experts know that you can’t erase the possibility of risk, and it can be counterproductive to build a plan to that expectation. What is realistic and achievable is identifying risk so you know what you’re up against, mitigating risk by following security best practices, and isolating risk where possible so that in the event of an incident, one failure doesn’t have a domino effect affecting other resources. If that seems a bit abstract, let’s take a look at a practical example.
Tech journalist Mat Honan was the unlucky victim of a targeted hack, which resulted in a near-complete lockout from his digital life requiring a Herculean effort to recover. Fortunately for us, Mat documented his experience in the Wired story, “How Apple and Amazon Security Flaws Led to My Epic Hacking,” which offers an excellent summary of exactly the type of domino effect I described. I encourage you to read the full article, but for a CliffsNotes version sufficient for our needs here:
Honan’s article goes into much more detail, including some of the changes made by the services exploited to prevent similar incidents in the future. The key takeaway is that having a couple of emails without strong authentication tied to all his most important accounts, including the recovery of these email accounts themselves, meant that the compromise of his Amazon account quickly snowballed into something much bigger.
We’re going to learn from that painful lesson, and do some segmentation on our email channels based on the priority and how public we want that account to be. (“Segmentation” is an industry term that can be mostly boiled down to “don’t put all your eggs in one basket”, and keep critical or vulnerable resources separate from each other.) I would suggest setting up a few different emails, listed here from least- to most-public:
For all of the above, of course, we’ll create strong passwords and set up 2FA. And speaking of 2FA, you can use the same split-channel approach we followed for email to set up a dedicated verification number (using a VOIP service or something like Google Voice) when sending a passcode by SMS is the only option supported. Keeping these recovery numbers separate from your main phone number reduces the risk of them being leaked, sold, or captured in an unrelated breach.
Good news: We’re almost done with doxxing ourselves! In the next section, we’ll sweep out those unused accounts to avoid leaving data-filled loose ends and take a look at how data brokers profit off of your personal information and what you can do to opt-out.
You’ve made it this far so maybe you’re passionate like we are about developing innovative ways to make security accessible. We’d love for you to join our mission.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Just a few years ago when the topic of supporting offsite workers arose, some of the key conversation topics were related to purchase, logistics, deployment, maintenance and similar issues. The discussions back then were more like “special cases” vs. today’s environment where supporting workers offsite (now known as the hybrid workforce) has become a critical mainstream topic.
Now with the bulk of many organization’s workers off-premise, the topic of security and the ability of a security vendor to help support an organization’s hybrid workers has risen to the top of the selection criteria. In a soon to be released Cisco endpoint survey, it’s not surprising that the ability of a security vendor to make supporting the hybrid workforce easier and more efficient was the key motivating factor when organizations choose security solutions.
Today, when prospects and existing customers look at Cisco’s ability to support hybrid workers with our advanced security solution set and open platform, it’s quite clear that we can deliver on that promise. But, yes, good tools make it easier and more efficient, but the reality is that running a SOC or any security group, large or small, still takes a lot of work. Most organizations not only rely on advanced security tools but utilize a set of best practices to provide clarity of roles, efficiency of operation, and for the more prepared, have tested these best practices to prove to themselves that they are prepared for what’s next.
Knowing that not all organizations have this degree of security maturity and preparedness, we gathered a couple of subject matter experts together to discuss 5 areas of time-tested best practices that, besides the advanced tools offered by Cisco and others, can help your SOC (or small security team) yield actionable insights and guide you faster, and with more confidence, toward the outcomes you want.
In this webinar you will hear practical advice from Cisco technical marketing and a representative from our award winning Talos Threat Intelligence group, the same group who have created and are maintaining breach defense in partnership with Fortune 500 Security Operating Centers (SOC) around the globe.
You can expect to hear our 5 Best Practices recommendations on the following topics;
Check out our webinar to find out how you can become more security resilient and be better prepared for what’s next.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Just over 3 years ago now, I sat down at a makeshift desk (ok, so it was a kitchen table) in an Airbnb in Olso and built the authenticated API for Have I Been Pwned (HIBP). As I explained at the time, the primary goal was to combat abuse of the service and by adding the need to supply a credit card, my theory was that the bad guys would be very reluctant to, well, be bad guys. The theory checked out, and now with the benefit of several years of data, I can confidently say abuse is near non-existent. I just don't see it. Which is awesome 😊
But there were other things I also didn't see, and it's taken a while for me to get around to addressing them. Some of them are fixed now (like right now, already in production), and some of them will be fixed very, very soon. I think it's all pretty cool, let me explain:
A little more background will help me explain this better: in the opening sentence of this blog post I mentioned building the original authenticated API out on a kitchen table at an Airbnb in Oslo. By that time, everyone knew I was going through an M&A process with HIBP I called Project Svalbard, which ultimately failed. What most people didn't know at the time was the other very stressful goings on in my life which combined, had me on a crazy rollercoaster ride I had little control over. It was in that environment that I created the authenticated API, complete with the Azure API Management (APIM) component and Stripe integration. It was rough, and I wish I'd done it better. Now, I have.
In the beginning, I pushed as much of the payment processing as possible to the HIBP website. This was due to a combination of me wanting to create a slick UX and frankly, not understanding Stripe's own UI paradigms. It looked like this:
Cards never ended up hitting HIBP directly, rather the site did a dance with Stripe that involved the card data going to them directly from the client side, a token coming back and then that being used for the processing. It worked, but it had numerous problems ranging from lack of support for things like 3D Secure payments, no support for other payments mechanisms such as Google Pay and Apple Pay and increasingly, large amounts of plumbing required to tie it all together. For example, there were hundreds of lines of code on my end to process payments, change the default card and show a list of previous receipts. The Stripe APIs are extraordinarily clever, but I couldn't escape writing large troves of my own code to make it work the way I originally designed it.
Two new things from Stripe since I originally wrote the code have opened up a whole new way of doing this:
Rolling to these services removed a huge amount of code from HIBP with the bulk of what's left being email address verification, API key management and handling callbacks from Stripe when a payment is successful. What all this means is that when you first create a subscription, after verifying your email address, you see these two screens:
That's the embeddable pricing table following by Stripe's own hosted payment page. I left the browser address bar in the latter to highlight that this is served by Stripe rather than HIBP. I love distancing myself from any sort of card processing and what's more, everything to do with actually taking the payment is now Stripe's problem 😊 If you're interested in the mechanics of this, a successful payment calls a webhook on HIBP with the customer's details which updates their account with a month of API key whilst the screen above redirects them over to the HIBP website where they can grab their key. Easy peasy.
I silently rolled this out a week ago, watched it being used, made a few little tweaks and then waited until now to write about it. The rollout coincided with a typical email I've received so many times before:
First of all I would like to thank you for the wonderful service that helps people to keep track of their email breaches. I was trying to build a product to provide your services via my website, something similar to Firefox, avast and 100's of other companies doing. We were trying to do it according to the guidelines mentioned in the website. However I am not able to renew my purchase due to payment gateway failures at stripe payment. Requesting you to kindly check the same and advise me on alternate methods for making the payment.
The old model often caused payments to be rejected, especially from subscribers in India. The painful thing for me when trying to help folks is that Stripe would simply report the failed payment as follows:
However, going back to the individual who raised the query above after rolling out this update, things changed very dramatically:
To the title of this section, I simply wasn't "Striping" right. I'm sure there's a way with enough plumbing that it's feasible, but why bother? I cut hundreds of lines of code out just by delegating more of the workload back to them. Further, with ever tightening PCI DSS standards (read Scott's piece, interesting stuff) the less I have to do with cards, the better.
This was a "penny drop" moment for me and it's already made a big difference in a positive way. But there's another penny that dropped for me at the same time: one-off keys were an unnecessary problem.
It was at the moment I was ripping out those hundreds of lines of code that I wondered: why do I have all the additional kludge to support the paradigm of a one-off key that only lasts a month? Why had I built (and was now maintaining) server side code to handle different types of purchases and UX paradigms to represent one-off versus recurring keys? My gut feel was that most payments formed part of an ongoing subscription but hey, who needs gut feels when you have real data?! So I pulled the numbers:
Only 7% of payments were one-offs, with 93% of payments forming part of ongoing subscriptions.
And so I killed the one-off keys. Kinda, because you can still have a key for only one month, you just purchase a monthly subscription then immediately cancel it via the Stripe Customer Portal:
That's linked into from the API key dashboard on HIBP and it'll take all of 5 seconds to do (also note the ability to change payment method directly on the Stripe site). I've added text to that effect on the HIBP website (you may have spotted that in the earlier screen cap) so in practice, the ability to purchase a one-off key is still there and the main upside of this is that I've just killed a trove of code I no longer have to worry about 🙂 Because this is the internet, I'm sure someone will still be upset, but if you only want a key for a month then that capability still well and truly exists.
All of this so far amounts to doing the same things that were always there but better. Now let's talk about the all new stuff!
The title is self-explanatory and "very soon" is in about 2 weeks from now 😎
Let me illustrate the first part of that title with a message I received recently:
Is there a way to procure a 10 year API key? Our client wants to use the Have I been Pwned plugin for [redacted service name]; however, the $3.50 monthly subscription is too small to go through procurement.
What's that saying about no good deed going unpunished? In my naivety, I made the pricing low with the thinking that was a good thing, yet here we are with that posing barriers! This was a recurring message over and over again with folks simply struggling to get their $3.50 reimbursed. I should have seen this coming after years of living the corporate life myself (I have vivid flashbacks of how hard it was to get small sums reimbursed), and filling out an untold number of expense reports. Speaking of which, this was another recurring theme:
Is there a way to pay yearly for HIBP API access vs monthly? Monthly adds overhead in paperwork.
And again, I get it, this is a painful process. It somehow feels even more painful due to the fact the sum is so low; how much time are people burning trying to justify $3.50 to their boss?! It's painful, and this likely explains why the request for annual payments is the second most requested idea on HIBP's UserVoice. The comments there speak for themselves, and I'm having corporate PTSD flashbacks just reading them again now!
Sticking with the UserVoice theme, the 5th most requested feature is for different pricing on different rate limits. This is mostly self-explanatory but what I wasn't aware of until I went and pulled the stats was just how many people were hacking around the rate limit problem. There are heaps of API accounts like this:
FreshRSS 
hibp+1@domain.com
hibp+2@domain.com
hibp+3@domain.com
...Because there can only be one key per email address, organisations are creating heaps of unique sub-addressed emails in order to buy multiple keys. This would have been a manual, laborious process; there's no automated way to do this, quite the contrary with anti-automation controls built into the process. Further, each key has it's own rate limit so I imagine they were also building a bunch of plumbing in the back end to then distribute requests across a collection of keys which, yeah, I get it, but man that seems like hard work! When I say "a collection of keys", I'm not just talking about a few of them either; the largest number of active in-use keys by a single organisation is 112. One hundred and twelve! The next largest is 110. I never expected that 🤯 (Incidentally, these orgs and the others obtaining multiple keys are all precisely the kinds I want using the API to do good things.)
Building the mechanics of annual billing and different rate limits is only part of the challenge and most of that is already done, the harder part is pricing it. I'm pulling troves of analytics from APIM at present to better understand the usage patterns, and it's quite interesting to see the data as it relates to requests for the API:
There's no persistent logging of the actual queries themselves, but APIM makes it easy to understand both the volume of queries and how many of them are successful versus failed, namely because they exceed the existing rate limit or were made with an invalid (likely expired) key. So, that's what I need to work out over the next couple of weeks when I'll launch everything and write it up, as always, in detail 🙂
The HIBP API has become an increasingly important part of all sorts of different tools and systems that use the data to help protect people impacted by data breaches. The changes I've pushed out over the last week help make the service more accessible and easier to manage, but it's the coming changes I'm most excited about. These are the ones that will make life so much easier on so many people integrating the service and, I sincerely hope, will enable them to do things that make a much more profound impact on all of us who've been pwned before.
Go and check out how the whole API key process works, I'd love to hear your feedback 😊
As package delivery scams that spoof DHL, USPS and other delivery companies soar, here’s how to stay safe not just this shopping season
The post Parcel delivery scams are on the rise: Do you know what to watch out for? appeared first on WeLiveSecurity
Today we’re examining some of the revelations in the Q3 Cisco Talos Incident Response Trends Report. This document is an anonymized look at of all the engagements that the Cisco Talos Incident Response team have been involved in over the previous three months. It also features threat intelligence from our team of researchers and analysts.
To start, take a watch of this episode of ThreatWise TV which explores how these trends have evolved since the previous quarter. Our guests also talk about incidents and cyber-attacks that they themselves have consulted on recently, including a particularly interesting insider threat case.
Ransomware returned as the top threat this quarter, after commodity trojans narrowly surpassed ransomware last quarter. Ransomware made up nearly 18 percent of all threats observed, up from 15 percent last quarter. Cisco Talos Incident Response (CTIR) observed high-profile families, such as Vice Society and Hive, as well as the newer family Blast Basta, which first emerged in April of this year.
Also noteworthy is the fact that CTIR saw an equal number in ransomware and pre- ransomware engagements this quarter, totalling nearly 40 percent of threats observed. Pre-ransomware is when we have observed a ransomware attack is about to happen, but the encryption of files has not yet taken place.
Pre-ransomware comprised 18 percent of threats this quarter, up from less than 5 percent previously. While it’s difficult to determine an adversary’s motivations if encryption does not take place, several behavioral characteristics bolster Talos’ confidence that ransomware may likely be the final objective. In these engagements adversaries were observed deploying frameworks such as Cobalt Strike and Mimikatz, alongside numerous enumeration and discovery techniques.
Commodity malware, such as the Qakbot banking trojan, was observed in multiple engagements this quarter. In one engagement, several compromised endpoints were seen communicating with IP addresses associated with Qakbot C2 traffic. This activity coincides with a general resurgence of Qakbot and its delivery of emerging ransomware families and offensive security frameworks that we have not previously observed Qakbot deploy. This comes at a time where competing email-based botnets like Emotet and Trickbot have suffered continued setbacks from law enforcement and tech companies.
Other threats this quarter include infostealers like Redline Stealer and Raccoon Stealer. Redline Stealer was observed across three engagements this quarter, two of which involved ransomware. The malware operators behind Raccoon introduced new functionality to the malware at the end of June, which likely contributed to its increased presence in engagements this quarter.
As infostealers have continued to rank highly in CTIR engagements, let’s explore them in a bit more detail.
Throughout the incidents discussed over the last few quarters, and CTIR engagements in general, information stealing plays a big part of the attackers’ TTPs.
From a high level, infostealers can be used to gain access a variety of sensitive information, such as contact information, financial details, and even intellectual property. The adversaries involved often proceed to exfiltrate this information and may then attempt to sell it in dark web forums, threaten to release it if a ransom isn’t paid, among other things.
While these instances can and do crop up in CTIR engagements, many of the infostealers seen in this space are used for accessing and collecting user credentials. Once an attacker has gained an initial foothold on a system, there are many places within an operating system that they can look for and collect credentials through the practice of credential dumping.
These stolen credentials may be offered up for sale on the dark web, alongside the stolen information mentioned above, but they can also prove to be a key weapon in an attacker’s arsenal. Their usefulness lies in one simple concept—why force your way into a system when you can just log in?
There are several advantages for bad actors that use this approach. Probably the most oblivious of these is that using pre-existing credentials is far more likely to go unnoticed than other more flagrant tactics an attacker can use. If part of the goal of an attack is to remain under the radar, activities carried out by “known users” are less likely to trigger security alerts when compared to tactics such as exploiting vulnerabilities or downloading malware binaries.
Adversaries tend to seek credentials with higher privileges, allowing them further control over the systems they compromise, with those including administrative access being the crown jewels.
User credentials can not only provide an attacker with means to elevate privileges and establish persistence on a system, but also to move laterally through a network. Some credentials, especially those with administrative privileges, can offer access to multiple systems throughout a network. By obtaining them, many more options become available to further an attack.
There are several threats involved in information stealing that appear repeatedly in CTIR engagements over the last few quarters.
Perhaps the most notorious is Mimikatz—a tool used to pull credentials from operating systems. Mimikatz is not malware per-se and can be useful for penetration testing and red team activities. But bad actors leverage it as well, and over the last few quarters CTIR has observed it being used in ransomware-as-a-service attacks, as well as pre-ransomware incidents.
CTIR has also observed Redline Stealer being utilized by adversaries in CTIR engagements across quarters. This infostealer has grown in popularity as a supplementary tool used alongside other malware. On more than one occasion, CTIR has identified stolen credentials on the dark web that claimed to have been obtained via Redline Stealer.
Other information stealers seen across the last few quarters include the Vidar information stealer, Raccoon Stealer, and SolarMaker, all of which have been used to further an adversary’s attacks.
Over the last several months, Talos has seen an increasing number of engagements involving insider threats. In one engagement this quarter, passwords were reset through a management console of a perimeter firewall that a disgruntled employee had access to.
The organization’s team changed all associated passwords but overlooked one administrative account. On the following day, someone logged in using that account, deleted all other accounts and firewall rules, and created one local account, likely to provide persistence.
You’ll hear Alexis Merritt, Incident Response Consultant for Cisco Talos, talk about this more in the ThreatWise TV episode.
To help protect against this threat when an individual leaves an organization, steps like disabling accounts and ensuring that connections to the enterprise remotely through VPN has been removed can be very valuable. Implementing a mechanism to wipe systems, especially for remote employees, is important as well.
For more on this topic, Cisco Secure recently put together a white paper on the Insider Threat Maturity FrameWork.
In several incidents over the last few quarters that involved information stealers, multi-factor authentication (MFA) was not properly implemented by the organizations impacted, providing adversaries an opportunity to infiltrate the networks. MFA tools like Cisco Secure Access by Duo can prevent attackers from successfully gaining access.
And finally, Cisco Advisory CISO Wolfgang Goerlich has created this storytelling video, to help people think about incident response in a new way:
Join the Cisco Talos Incident Response team for a live debrief of the Q3 report on 27th October.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Last week, I was privileged to participate in an important national summit on IoT Security convened by Anne Neuberger, Deputy National Security Advisor for Cyber and Emerging Technologies.
Representatives from across the US government, industry, and academia were invited to the White House to discuss a National Consumer IoT Security Labeling program.
In short, we were all there to solve the same problem: how do we raise awareness of the IoT security challenge among all consumers? Cisco appreciates the Biden administration’s efforts to drive better security into the consumer space given how interconnected our world is. We also underscored the importance of intelligent, intuitive networks in securely connecting the “things” being brought online daily—and in managing the billions of smart devices already in our homes and offices.
Consumer devices—from televisions and cameras to drones and baby monitors—have become attack targets as we have embraced connectivity without necessarily following proper security measures. This has been demonstrated by attacks that access cameras within these smart devices. But this issue extends beyond attacks and includes breaches of privacy too. If improperly secured, capabilities intended to enable smart features and accessibility, or improve user experience, can be abused by hackers to steal identities, generate data breaches, facilitate device failure, or even serve as stepping-stones to broader attacks on critical infrastructure.
A prominent example of how security flaws in consumer devices can lead to broader disruption was demonstrated by the Mirai botnet in 2016. What appeared initially as a targeted attack, quickly spread and caused global havoc. Fueled by compromised connected consumer devices—like cameras, DVRs and home routers—a Distributed Denial of Service attack (DDoS) impacted its customers’ sites such as Twitter, Netflix, and CNN to name a few. Mirai highlighted how consumer devices connecting to the network can go beyond the walls of a consumer’s home to breach larger institutions and services—all the while being unknown to the consumer and without impact the devices’ functions.
So how do we raise consumer awareness about these breaches? And how do we protect users and prevent these breaches in the future? The discussion at the White House focused on now best to effectuate the national program for IoT security labeling, which was required by President Biden’s executive order last May. Key stakeholders presented potentially promising new ideas for device certification, labels for secure devices, and ways to incentivize adoption of these standards.
Though the focus was on consumer IoT devices, we also discussed the broader implications of the need to raise awareness among consumers about the devices they use at home and in the office. This is where the importance of visibility and network security becomes a strong protector: once these devices can be identified, the network can provide the right access controls (e.g., segmenting the network so that such devices do not infiltrate the main network).
As the IoT market continues to evolve and mature, we look forward to working with the US government, policymakers, industry forums, and partners to drive open, standardized holistic IoT security and privacy practices. Accomplishing this will help more power a more secure, connected future for all.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
A new ransomware threat is currently sweeping its way across home computers. And what’s making it extra tricky is that it’s disguised as an operating system update.
Be on the lookout for this new ransomware scheme and protect yourself from ransomware with a few of these tips.
Magniber is a new type of ransomware that is disguised at almost every touchpoint until it seemingly pops out of nowhere demanding money. The attack begins when someone visits a fake Windows 10 update website owned by the Magniber cybercriminal group. Once someone clicks on a malicious link on that site, file-encrypting malware downloads onto the device.
Another stealth maneuver of Magniber is that the encryption malware downloads as a JavaScript file straight to the memory of the device, which can often slide under an antivirus’ radar. This malware allows the criminal to view, delete, and encrypt files and gain administrator access of the device. Usually, before the person even knows their device is in danger, Magniber reveals itself and demands a ransom payment in exchange for releasing the documents and giving back control of the computer. If the device owner refuses to pay, the criminal threatens to delete the files forever.1
For the last several years, large companies fell left and right to breaches. Hacker groups infiltrated complex cybersecurity defenses, got ahold of sensitive company or customer information, and threatened to release their findings on the dark web if not paid a hefty ransom. The reasons cybercriminals targeted corporate databases versus personal devices wasn’t just because they could demand multiple millions, but because companies were better equipped to make ransom transactions anonymously. Often, cryptocurrency transactions are untraceable, which allows criminals to remain at large.
Now that more everyday people are proficient in cryptocurrency, ransomware may shift to targeting personal devices. Though the ransom payments won’t be as lucrative, there also won’t be corporate cybersecurity experts hot on the cybercriminal’s tail.
To avoid ransomware schemes similar to Magniber, adopt these three habits to better protect your device and digital privacy:
If a cybercriminal gets in touch with you and demands a ransom, immediately contact your local FBI field office and file a report with the FBI’s Internet Criminal Complaint Center. From there, the authorities will advise you on how to proceed.
Something you can start with now to defend against ransomware is to invest in McAfee+ Ultimate. It provides the most thorough device, privacy, and identity protection, including $25,000 in ransomware coverage.
1ZDNET, “This unusual ransomware attack targets home PCs, so beware”
The post Ransomware Masquerading as Microsoft Update Targets Home Computers appeared first on McAfee Blog.
Authored by SangRyol Ryu
Cybercriminals are always after illegal advertising revenue. As we have previously reported, we have seen many mobile malwares masquerading as a useful tool or utility, and automatically crawling ads in the background. Recently the McAfee Mobile Research Team has identified new Clicker malware that sneaked into Google Play. In total 16 applications that were previously on Google Play have been confirmed to have the malicious payload with an assumed 20 million installations.
McAfee security researchers notified Google and all of the identified apps are no longer available on Google Play. Users are also protected by Google Play Protect, which blocks these apps on Android. McAfee Mobile Security products detect this threat as Android/Clicker and protect you from malware. For more information, to get fully protected, visit McAfee Mobile Security.
The malicious code was found on useful utility applications like Flashlight (Torch), QR readers, Camara, Unit converters, and Task managers:
Once the application is opened, it downloads its remote configuration by executing an HTTP request. After the configuration is downloaded, it registers the FCM (Firebase Cloud Messaging) listener to receive push messages. At first glance, it seems like well-made android software. However, it is hiding ad fraud features behind, armed with remote configuration and FCM techniques.
| Attribute name | Known meaning of the value |
| FCMDelay | Initial start hours after first installation |
| adButton | Visivility of a button of Advertisement |
| adMob | AdMob unit ID |
| adMobBanner | AdMob unit ID |
| casOn | Whether CAS library works or not |
| facebookAd | FaceBook Ad ID |
| fbAdRatio | Ratio of FB AD |
| googleAdRatio | Ratio of AdMob |
| is | Decide BootService to run or not |
| urlOpen | to open popup or not when starts PowerService |
| popUrl | URL for PowerService |
| popUpDelay | Delay time for PowerService |
| liveUrl | URL for livecheck service |
| pbeKey | Key for making unique string |
| playButtonList | URL for other service |
| reviewPopupDialog | ‘y’ it shows review dialog |
| tickDelay | Delay time for TickService |
| tickEnable | Value of TickService enabled |
| tickRandomMax | Value of TickService random delay |
| tickRandomMin | Value of TickService random delay |
| tickType | Set the type of TickService |
| updateNotiVersion | Value for showing update activity |
The FCM message has various types of information and that includes which function to call and its parameters. The picture below shows some of FCM message history:
When an FCM message receives and meets some condition, the latent function starts working. Mainly, it is visiting websites which are delivered by FCM message and browsing them successively in the background while mimicking user’s behavior. This may cause heavy network traffic and consume power without user awareness during the time it generates profit for the threat actor behind this malware. In the picture below there is an example of the network traffic generated to get the information required to generate fake clicks and the websites visited without user’s consent or interaction:
So far, we have identified two pieces of code related to this threat. One is “com.click.cas” library which focuses on the automated clicking functionality while “com.liveposting” library works as an agent and runs hidden adware services:
Depending on the version of the applications, some have both libraries working together while other applications only have “com.liveposting” library. The malware is using installation time, random delay and user presence to avoid the users from noticing these malicious acts. The malicious behavior won’t start if the installation time is within an hour and during the time the user is using the device, probably to stay under the radar and avoid being detected right away:
Clicker malware targets illicit advertising revenue and can disrupt the mobile advertising ecosystem. Malicious behavior is cleverly hidden from detection. Malicious actions such as retrieving crawl URL information via FCM messages start in the background after a certain period of time and are not visible to the user.
McAfee Mobile Security detects and removes malicious applications like this one that may run in the background without user’s knowledge. Also, we recommend having a security software installed and activated so you will be notified of any mobile threats present on your device in a timely manner. Once you remove this and other malicious applications, you can expect an extended battery time and you will notice reduced mobile data usage while ensuring that your sensitive and personal data is protected from this and other types of threats.
liveposting[.]net
sideup[.]co[.]kr
msideup[.]co[.]kr
post-blog[.]com
pangclick[.]com
modooalba[.]net
| SHA256 | Package name | Name | Downloaded |
| a84d51b9d7ae675c38e260b293498db071b1dfb08400b4f65ae51bcda94b253e | com.hantor.CozyCamera | High-Speed Camera | 10,000,000+ |
| 00c0164d787db2ad6ff4eeebbc0752fcd773e7bf016ea74886da3eeceaefcf76 | com.james.SmartTaskManager | Smart Task Manager | 5,000,000+ |
| b675404c7e835febe7c6c703b238fb23d67e9bd0df1af0d6d2ff5ddf35923fb3 | kr.caramel.flash_plus | Flashlight+ | 1,000,000+ |
| 65794d45aa5c486029593a2d12580746582b47f0725f2f002f0f9c4fd1faf92c | com.smh.memocalendar | 달력메모장 | 1,000,000+ |
| 82723816760f762b18179f3c500c70f210bbad712b0a6dfbfba8d0d77753db8d | com.joysoft.wordBook | K-Dictionary | 1,000,000+ |
| b252f742b8b7ba2fa7a7aa78206271747bcf046817a553e82bd999dc580beabb | com.kmshack.BusanBus | BusanBus | 1,000,000+ |
| a2447364d1338b73a6272ba8028e2524a8f54897ad5495521e4fab9c0fd4df6d | com.candlencom.candleprotest | Flashlight+ | 500,000+ |
| a3f484c7aad0c49e50f52d24d3456298e01cd51595c693e0545a7c6c42e460a6 | com.movinapp.quicknote | Quick Note | 500,000+ |
| a8a744c6aa9443bd5e00f81a504efad3b76841bbb33c40933c2d72423d5da19c | com.smartwho.SmartCurrencyConverter | Currency Converter | 500,000+ |
| 809752e24aa08f74fce52368c05b082fe2198a291b4c765669b2266105a33c94 | com.joysoft.barcode | Joycode | 100,000+ |
| 262ad45c077902d603d88d3f6a44fced9905df501e529adc8f57a1358b454040 | com.joysoft.ezdica | EzDica | 100,000+ |
| 1caf0f6ca01dd36ba44c9e53879238cb46ebb525cb91f7e6c34275c4490b86d7 | com.schedulezero.instapp | Instagram Profile Downloader | 100,000+ |
| 78351c605cfd02e1e5066834755d5a57505ce69ca7d5a1995db5f7d5e47c9da1 | com.meek.tingboard | Ez Notes | 100,000+ |
| 4dd39479dd98124fd126d5abac9d0a751bd942b541b4df40cb70088c3f3d49f8 | com.candlencom.flashlite | 손전등 | 1,000+ |
| 309db11c2977988a1961f8a8dbfc892cf668d7a4c2b52d45d77862adbb1fd3eb | com.doubleline.calcul | 계산기 | 100+ |
| bf1d8ce2deda2e598ee808ded71c3b804704ab6262ab8e2f2e20e6c89c1b3143 | com.dev.imagevault | Flashlight+ | 100+ |
The post New Malicious Clicker found in apps installed by 20M+ users appeared first on McAfee Blog.
