Car Dealership Threat Scenario – Wireless Printer Hacking AP Fraud

Today, I wanted to talk about a threat scenario that we have modeled recently. In the scenario, the victim was a car dealership, and the target was to commit accounts payable fraud. The testing scenario is a penetration test against a large group of car dealerships, but our research shows the threat to be valid against any number of organizations. 

Here’s the basics of the scenario:

  • The team found a car dealership with an extensive wireless network. Though the network was encrypted and not available to the public, the team was able to compromise the wireless credentials using a wifi pineapple in a backpack, while pretending to shop for a new car.
  • The team used the credentials to return later, appearing to wait for a service visit and working from the customer lounge. (The coffee and snacks were great! )
  • The team logged into the wireless network and quickly identified many devices, workstations and such available. Rather than focus on the workstations or attempt an attack on the users – the team instead focused on the shared printers.
  • One printer was identified with the name “BackOffice”, and access to the print spool was easily obtained through known default passwords which hadn’t been changed on the device.
  • Our team made notes of attack their recon attack path, and left the dealership.
  • Once away from the dealership a couple of simple social engineering calls were made to the accounts payable folks, pretending to be a vendor that we had observed at work at the facility. Without any real information, the accounts payable team member explained when we could expect payment, because accounts payable checks were processed every Thursday morning. The social engineer thanked them and completed the call.
  • On Thursday morning, the team showed up at the dealership again, pretending to wait for a service appointment. While in the lounge, they accessed the compromised network and printer. This time, taking deeper control of the printer’s file buffer.
  • The team waited for the accounts payable staff to submit their weekly check printing to the printer. Indeed, around 10:45, the printer file showed up in the printer spool, where our penetration testing team intercepted it. 
  • The team quickly edited the file, changing one of the checks in amount (increasing the amount by several thousand dollars) and the payee (making the check payable to a fictional company of our choosing). They also edited the mailing address to come to our office instead of the original vendor. (PS – we alerted the manager to this issue, so that the bill could be paid later — never harm a client while doing testing!!!)
  • The file was then re-sent to the printer and released. The whole process occurred in under 3 minutes, so the AP person never even noticed the issue.
  • One expected control was that perhaps the AP staff would manually reconcile the checks against their expected checks, but this control was not in place and the fake check was mailed to us (we returned it, of course!).

This is a pretty simple attack, against a very commonly exploitable platform. Poor wireless network security and default installs of printer systems are common issues, and often not given much thought in most dealerships. Even when organizations have firewalls and ongoing vulnerability scanning, desktop controls, Anti-Virus, etc. – this type of attack is likely to work. Most organizations ignore their printers – and this is an example of how that can bite you.

These types of threat scenarios are great examples of our services and the threat modeling, fraud testing and penetration testing available. If you’d like to learn more about these kinds of activities, or discuss how to have them performed for your organization – get in touch. You can contact us via web form or give us a call at (614) 351-1237. You can also learn more about our role and services specific to car dealerships here.

Thanks for reading and let me know if you have any questions – @lbhuston on Twitter.

ClawBack Insights :: A Conversation with MicroSolved, CEO, Brent Huston

I recently got interviewed over email by one of my mentees. I thought their questions were pretty interesting and worth sharing with the community. This session focused on ClawBack™ and was done for a college media class assignment. I hope you enjoy the interview as much as I did giving it. 

Q: What is ClawBack?

ClawBack is a platform for helping organizations detect data leaks. It’s a cloud-based engine focused on three specific kinds of leaked data – source code, device and application configurations and credentials. It systematizes many of the manual efforts which mature organizations had been doing either partially, or in an ad hoc fashion, and makes them ongoing, dependable and available to organizations of any size and technical capability.

The engine lets the customer pick monitoring terms, and yes, we have a very nice guide available in the online help to guide them. Once the terms are chosen, the engine goes to work and begins to scour the sites most commonly associated with these types of leaks. At first, it does historical searches to catch the client up to the moment, and then, periodically, it provides ongoing searching for signs of leaked data.

Once a leaked dataset is found, the user is alerted and can view the findings in the web portal. They can take immediate action from the takedown advice we provide in online help, or they can choose to archive the alert or mark it as a false positive to be ignored in the future. Email alerts, team accounts and alert exports for SEIM/SOAR integration are also available to customers at the advanced levels.

Basically, ClawBack is a tool to help developers find code that accidentally slipped to the Internet, network admins and security teams find configurations and credentials that have escaped into the wild. We wanted to make this easy, and raise the maturity level of data leak detection for all organizations. We think we hit the mark with ClawBack, and we hope you do too.

Q: Why did your team create ClawBack and why now?

This is a great question! For many years now, we have been working a variety of security incidents that all tie back to attackers exploiting leaked data. They routinely comb the Internet looking in these common repositories and posting locations for code, configs and credentials. Once they find them, they are pretty quick to take advantage.

Take for example, a leaked device configuration from a router. The global paste bins, code repositories and forums are full of these kinds of leaks. In many cases, these leaked files contain not just the insights the attacker can gain from the configuration, but often, logins and passwords that they can use to compromise the device. Many also give up cryptographic secrets, network management credentials and other significantly dangerous information. The attackers just harvest it, use it and then spread into other parts of the network – stealing as they go.

At MSI, we just got tired of seeing organizations compromised the same way, over and over again. Time after time, the clients would say they had no idea the data had been exposed. Some had ad hoc processes they ran to search for them, and others had tools that just weren’t getting the job done. We knew we had to make something that could help everyone solve this problem and it had to be easy to use, flexible and affordable. Nothing like that was on the market, so we built it instead.

Q: How does ClawBack address the issues of leaked critical data?

As you read above, we wanted to focus on the things that hurt the most – leaked code, configs and credentials. These three types of leaks are at the core of more than 90% of the leak-related incidents we’ve worked over the last several years. We didn’t try to solve every problem with this new tool – or make it a swiss army knife. We focused only on those 3 kinds of leaks.

Today, ClawBack monitors the most common sites where these leaks often occur. It monitors many of the global pastebins associated with leaks, forums and support sites where folks often accidentally expose data while getting or giving help and work repositories where many of these items often end up from inadvertent user errors or via misconfigured tools.

ClawBack provides the dependable process and ongoing vigilance that the most mature firms have access to – and it brings that capability to everyone for less than a fancy cup of coffee a day.

Q: How is it different than DLP solutions?

For starters, there’s no hardware, software or agents to deploy and manage. The cloud-based platform is so simple to use that most customers are up and monitoring in less than 5 minutes. You simply register, select your subscription, input monitoring terms and ClawBack is off and running. It’s literally that easy!

Now, DLP is a great tool. When it’s properly configured and managed, it’s very capable. Most of our ClawBack clients have DLP solutions of some sort in place. The problem is, most of these data leaks occur in ways that render the DLP unable to assist. In most cases, the data leaks in the incidents we have worked have occurred outside of the corporate network that the DLP is monitoring. When we traced back the root of the incident, most of them came from workers who were not using the corporate network when they made their grave mistake.

Additionally, of those that did use the corporate network, often the DLP was either misconfigured, the alert was missed or the transaction was protected by cryptography that circumvented the DLP solution. A few of the incidents came from users who routinely handle code and configuration files, so the anomaly-based DLP tools assumed the leak was normal, usual traffic.

Sadly, the last group of incidents that had DLP in place went undetected, simply because the DLP solution was configured to meet some regulatory baseline like HIPAA, PCI or the like and was only searching for leaked PII that matched those specific kinds of patterns. In those cases, source code, configurations and even dumped credentials were far outside of the protection provided by the DLP.

ClawBack takes a different approach. It lets users know when this type of data turns up and lets them respond. It’s easy, plain language monitoring term management makes it trivial to define proper terms to tackle the 3 critical types of leaks. We provide a very detailed set of suggested terms for customers in our online help, which most folks master in moments.

Q: If an organization doesn’t have any in-house development or code, what can ClawBack do for them? Same question for organizations that outsource their device management – how can they get help from ClawBack?

Organizations that don’t do any development or have any source code are few and far between, but they still gain immense capability from ClawBack. Nearly every organization has device and application configurations and credentials that they need to monitor for exposure. Even if you outsource network management, you should still use ClawBack as a sanity check to watch for data leaks. We’ve seen significant numbers of leak-related security breaches from networks managed by third parties.

Requesting the key device configurations from your vendor and inputting identifying data into ClawBack is easy and makes sure that those configurations don’t end up somewhere they shouldn’t – causing you pain. Identifying unique account names and such, and using those as ClawBack monitoring terms can give you early warning when attackers dump credentials, hashes or other secrets that could cause you harm. Being able to change those passwords, kill accounts, increase monitoring and claw back those files through takedown efforts can mean the difference between a simple security incident and a complete data breach with full legal, regulatory and reputational impacts.

Q: Several people have said you are leaving money on the table with your pricing model – why is the pricing so affordable?

The main reason that the product costs under $200 per month at the highest level, currently, is that I wanted not-for-profit firms to be able to afford to protect themselves. Credit unions, charities, co-op utilities and the like have been huge supporters of MicroSolved for the last 30 years, and I wanted to build a solution that didn’t leave them out – simply because they have limited funds. Sure, we could charge larger fees and only target the Fortune 500 or the like, and make a lot of money doing it. The problem is, the security incidents we built this to help eliminate happen to small, mid-size and less than Fortune 500 companies too and there are a LOT MORE of those firms than 500. They need help, and they need to be able to afford the help they require.

Secondly, we were able to get to such an affordable price point by really focusing on the specific problem. We didn’t build a bunch of unneeded features or spend years coding capabilities to address other security problems. ClawBack detects leaks of critical data. That’s it. It provides basic alerting and reporting. We based the monitoring technology off our existing machine learning platform and re-used much of the know how we have developing past products and services like TigerTrax™ and SilentTiger™. What saves us money and resources, saves our clients money and resources.

Lastly, at MSI, we believe in making more value than we harvest. We want to provide significant levels of value to our clients that way over scales what they pay for it. We can do that using technology, our expertise and by building solutions that focus on significant problems that many feel are untenable. We’ve been doing it for almost 30 years now, so we must be getting something right…

Q: What’s next for ClawBack? Is there a road map?

We are talking about adding some forms of risk determination to the findings. We are currently in discussion with clients and experts about how best to do that and communicate it. We are discussing using some additional machine learning techniques that we developed for our social media monitoring and threat intelligence platforms. That’s the next step for us, that we can see.

We’re also looking at user feedback and curating what folks are asking about and thinking about when using the product. That feedback is being ranked and added to the road map as we create it. We’ve got some ideas of where we want to go with ClawBack, but honestly, the tool addresses the problem we built it to help with. That’s the core mission, and anything outside of that is likely to fall out of the mix.

Q: You have a history of designing interesting products – what is on the horizon or what are you playing with in the lab these days?

I wish I could tell you about the things we are playing with, because it is fascinating. We are exploring a lot of new capabilities in TigerTrax with different machine learning models and predictive techniques. We’re working on updates to HoneyPoint™ and SilentTiger that will bring some very cool new features to those capabilities.

We’re also continuing to gather, analyze and deliver specific types of threat intelligence and data analytics of hostile data sets. We’re studying adversarial use of machine learning techniques, attacks against different AI, IoT and cloud platforms and we’re diving deep into cyber-economics and other factors related to breaches. I’m also working on a pretty interesting project with some of my mentees, where we are studying the evolution, use and capability growth of various phishing kits in use today. The mentees are learning a lot and I’m getting to apply significant amounts of machine learning techniques to new data and in new ways that I haven’t explored before. All in all, pretty cool stuff!

I’ll let you know what we come up with. Thanks for interviewing me, and thanks to the readers for checking this out. Give me a shout out on Twitter – @lbhuston and let me know if you have questions or feedback on ClawBack. I’d love to hear your thoughts!

Zelle…quick, easy, and…problematic?

Measuring risk

With the increasing adoption of PayPal, Venmo, and other instant payment services…it’s no surprise that the financial services industry entered the arena. The concept is simple – P2P payments via phone or email. At least one entity – sender or recipient – needs to have a bank account with a bank that supports Zelle. The other entity can simply link a supported debit card to enable the exchange.

Continue reading

BEC #6 – Recovery

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Discover. Part 3 covered the next checkpoint – Protect. Part 4 continued the series – Detect. Part 5 addressed how to Respond.

Continue reading

How to Respond – BEC Series #5

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Identify. Part 3 covered the next checkpoint – Protect. Part 4 continued the series – Detect.

Now we’ll move along to one of the most important parts of the checklist – Respond.

Continue reading

Get your magnifying glass – time to detect! BEC Series #4

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Discover. Part 3 covered the next checkpoint – Protect. Now we’re going to move on to the next point – Detect.

Continue reading

Time to protect – BEC Series #3

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Identify.

Continue reading

How do you “identify”…BEC #2

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Continue reading

Lighting up BEC, not Bic – Business Email Compromise…

What’s a bit of spam and a bit of phishing, right? It’s all the cost of doing business…until you look at what it really CAN cost your business.

The latest statistics from the Internet Crime Complaint Center (IC3) are enlightening – taken directly from the IC3 site:

The following BEC/EAC statistics were reported to the IC3 and are derived from multiple sources, including IC3 and international law enforcement complaint data and filings from financial institutions between October 2013 and May 2018:

Domestic and international incidents: 78,617
Domestic and international exposed dollar loss: $12,536,948,299

The following BEC/EAC statistics were reported in victim complaints where a country was identified to the IC3 from October 2013 to May 2018:

Total U.S. victims: 41,058
Total U.S. victims: $2,935,161,457
Total non-U.S. victims: 2,565
Total non-U.S. exposed dollar loss: $671,915,009

The following BEC/EAC statistics were reported by victims via the financial transaction component of the IC3 complaint form, which became available in June 20163. The following statistics were reported in victim complaints to the IC3 from June 2016 to May 2018:

Total U.S. financial recipients: 19,335
Total U.S. financial recipients: $1,629,975,562
Total non-U.S. financial recipients: 11,452
Total non-U.S. financial recipients exposed dollar loss: $1,690,788,278

That’s billions with a B…and the dollars and cents cannot measure the intangible costs like reputation, consumer confidence, etc.

What are the growing targets, and vectors of compromise? Financial transactions of all kinds tend to be the low hanging fruit. Real estate transactions, wire transfers, anything with a routine methodology of process, where information requests are constant, and a change of source or target would not be unusual. What’s another call from the bank, asking to verify your account information for payment? Another wire transfer request from the CFO?

There are also information breaches to consider. Let’s look at DocuSign for a moment – their own statement admits that email addresses were compromised, but indicates that additional personal information was not at risk. This statement is a bit misleading. A threat actor could collate the additional info to make an attack appear legitimate through other sources – and the fact that these emails came from DocuSign means that they would legitimately expect to receive email FROM DocuSign! In sales, that’s a pre-qualified lead, and it’s no less valuable to an attacker.

Another high-profile incident is the indictment of Russian operatives in the DCCC and DNC compromise – MSI has written about that here.

Add the preponderance of mobile devices, webmail, and online portals to your business of all kinds…it’s a risk. And any breach of your business data, client/customer data, and/or employee data is high profile as a risk to YOU. MSI has had a number of clients this year with compromises of Office 365 email accounts, administrative accounts that were externally facing, wire transfer issues, etc. On a personal level, individuals have had fraudulent tax returns filed under their SSN, etc. Size is irrelevant when it’s your data (and money) at risk.

So, what can you do to protect yourself, and your company? Email filtering, mobile device management, and other security measures can help – but the one measure that is consistently most effective against these attacks is MFA – multi-factor authentication. MFA is, at its core, something you know and something you have.

Often, this is an SMS code, or something physical like an RSA hard or soft token. However, do not rule out MFA for less technical transactions. In a situation where the CFO emails in a wire transfer, also add a vocal component – the individual must call and answer a challenge response question.

Are there challenges to implementing MFA? Of course. One of the primary challenges is user resistance – one of my favorite sayings is…change is inevitable, except in vending machines. But humans are wired to see their consistent patterns as a comfort, and you’re asking them to leave their comfort zone.

Another challenge is the technology gap. NIST is no longer recommending SMS as a component of MFA – but if that is all your organization is capable of leveraging, is it better than nothing? That’s a question for your technical and risk staff to consider.

The solution you choose will always NOT work for someone or something in your organization – someone will have a device that is too old, or incompatible, and they’re high enough up the corporate ladder that allowances will be considered. If you use a hardware token, someone will break it at a critical moment – or the USB token won’t work with their new whizz bang device.

And once you begin implementation, your organization won’t go from zero to 100% compliant immediately – in addition to dealing with the outliers, you’ll need a transition plan while implementation is underway.

Documented policies and procedures will need to be present – create these as you go, it will be a less onerous task than after the fact. In the case of our verbal challenge and response for a wire transfer example, where will those procedures be kept and how will they be protected – they should be safe from easy compromise, but not invalidate the solution when the primary person is out of the office?

Then there’s the issue of critical software that may need to be externally facing, but doesn’t support MFA. What do you do when the developers cannot implement this in a manner to protect your company? “The program wouldn’t do it” will be of little comfort when you’ve been compromised.

Are the challenges overwhelming? We cannot LET them be, folks. Scroll back up to those numbers – that’s billions with a B. Consider the challenges as things to rise up and meet, in the best way for your organization – rather than mountains that you simply cannot climb.

Questions, comments? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.

Move over Intel – here comes AMD…

Following close behind Spectre, Meltdown, et al…CTS-Labs announced on Tuesday, March 13th that it’s researchers had discovered 13 new critical security vulnerabilities with AMD’s Ryzen and EPYC processors. The Israel based company presents the vulnerabilities as allowing attackers to not only access data stored on the processors, but would also allow them to install malware.

Of some note is the fact that it appears that CTS-Labs gave AMD less than 24 hours to respond to the vulnerabilities rather than the customary 90 day notice for standard vulnerability disclosure. As such, there is no readily available information from AMD.

Another item of note is that the domain name “amdflaws.com” was registered February 22, 2018. Presumably this belongs to CTS-Labs or an associate.

Ryzen chips typically power desktop and laptop computers, while EPYC processors are generally found in servers. A quick rundown of the vulnerabilities as presented as of this writing:

RYZENFALL – four variants, affects the Ryzen family of processors: This vulnerability purports to allow malicious software to take full control of the AMD Secure Processor. The resulting Secure Processor privileges could allow read and write in protected memory areas, such as SMRAM and the Windows Credential Guard isolated memory. This could allow attackers to bypass controls such as Windows Credential Guard to compromise credentials, and potentially move laterally through the affected network.

Attackers could also theoretically use this vulnerability in conjunction with MasterKey to install persistent malware on the Secure Processor.

FALLOUT – three variants, affects the EPYC family of processors: This vulnerability purports to allow attackers to read from and write to protected memory areas, such as SMRAM and Windows Credential Guard isolated memory (VTL-1).

Attackers could theoretically leverage these vulnerabilities to steal network credentials protected by Windows Credential Guard, as well as to bypass BIOS flashing protections implemented in SMM.

CHIMERA – two variants, affects the Ryzen family of processors: This vulnerability purports to have discovered two sets of manufacturer backdoors: One implemented in firmware, the other in hardware (ASIC). The backdoors allow malicious code to be injected into the AMD Ryzen chipset.

The chipset links the CPU to USB, SATA, and PCI-E devices. Network, WiFi and Bluetooth traffic often flows through the chipset as well. The attack potential for this vector is significant, and malware could evade virtually all endpoint security solutions on the market.

Malware running on the chipset could leverage the latter’s Direct Memory Access (DMA) engine to attack the operating system. This kind of attack has been demonstrated.

MASTERKEY – three variants, affects both the Ryzen and EPUC families of processors:  Multiple vulnerabilities in AMD Secure Processor firmware allow attackers to infiltrate the Secure Processor.

This vulnerability purports to allow the deployments stealthy and persistent malware, resilient against virtually all security solutions on the market. It also appears to allow tampering with AMD’s firmware-based security features such as Secure Encrypted Virtualization (SEV) and Firmware Trusted Platform Module (fTPM).

As in RyzenFall, this could allow attackers to bypass controls such as Windows Credential Guard to compromise credentials, and potentially move laterally through the affected network.

Another consideration is potential physical damage and bricking of hardware. It could also potentially be leveraged by attackers in hardware-based “ransomware” scenarios.

The full whitepaper is here.

Given the continued impact of the Intel patches on performance and stability, and conflicts with other vendor products – hardware and software – hang on, folks. We’re going to see some chaos in this space.

What are your thoughts? Do you feel the responsible disclosure path is to give manufacturers the customary 90 day window, or is immediate disclosure of risk preferable to you?

Let me know what you think. I can be reached at lwallace@microsolved.com, or on Twitter as @TheTokenFemale