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

Spectre and Meltdown and Tigers, Oh my….well, maybe not tigers….

On January 3rd, three new vulnerabilities were disclosed. These vulnerabilities take advantage of how various CPU’s handle processing in order to return a faster result.

The technical details for Spectre and Meltdown are addressed by the papers linked to their names above. And some POC’s from the Project Zero team.

A few observations on how the industry is addressing this issue…and a few points of interest that I’ve found along the way. First, let’s note that the CVE’s for these are 2017…when in 2017? We don’t know. But the catchy domain names were registered around the third week in December, 2017.

The full vendor matrix at CERT – this is always worth watching, and there are some useful tips for cloud implemenations via Amazon and Microsoft Azure:

Operating system manufacturers:

Apple

  • Will release updates for Safari and iOS in coming days. Some speculation that iOS on Mac’s that is 10.13.2 or higher has some protection from one or more variants – not verified
  • https://support.apple.com/en-us/HT208394

Windows

Linux

Some antivirus solutions are causing blue screens after application of these patches:

This is particularly interesting to me – the browsers. I did not expect to see the browser patch bandwagon to be as rapid as it has been:

Firefox

Internet Explorer

Safari

  • Will be addressed in approximately the same timeframe as Apple iOS patches – current ETA unknown

Chrome

The long and short. Is the sky falling? Probably not. If you have solutions that are hosted with a cloud provider, check in with them. What are their recommended mitigations, and have you implemented them? In an enterprise environment, do your due diligence on patches. Patch in your test environment first, and research your antivirus solution for potential impact.

And I believe I’m paraphrasing the excellent Graham Cluley. Calm down, make a cup of tea – although mine is salted caramel coffee. Patch during your normal cadence for critical patches, and keep the ship afloat!

Are You Seeing This? Join a Threat Sharing Group!

Just a quick note today about threat sharing groups. 

I am talking to more and more companies and organizations that are putting together local, regional or vertical market threat sharing groups. These are often adhoc and usually driven by security practitioners, who are helping each other with cooperative defenses and sharing of new tactics and threat patterns (think TTPs (tactics, techniques & procedures)) or indicators of compromise (IOCs). Many times, these are informal email lists or RSS feeds that the technicians subscribe to and share what they are seeing in the trenches. 

A few folks have tried to commercialize them, but in most cases, these days, the sharing is simply free and open. 

If you get a chance to participate in one or more of these open source networks, you might want to check it out. Many of our clients are saying great things about the data they get via the networks and often they have helped contain incidents and breaches in a rapid fashion.

If you want to discuss your network, or if you have one that you’d like me to help promote, hit me up on Twitter (@lbhuston). If you are looking for one to join, check Twitter and I’ll share as folks allow, or I’ll make private connections as possible. 

As always, thanks for reading, and until next time, stay safe out there! 

A SilentTiger™ Look At The Logistics Industry

I was recently asked to discuss how attackers view parts of the logistics industry with some folks from a research group. As a part of that, I performed a very quick OSINT check against a handful of randomly chosen logistics firms set around a specific US geographic area. Using our proprietary SilentTiger™ passive assessment platform, we were able to quickly and easily identify some specific patterns. We allowed the tool to only complete the first step of basic foot printing of the companies and analyzed less than 10% of the total data sources that a full run of the platform would access.

 

This quick approach lets us learn about some of the basic threat densities that we know are common to different industries, and gives MSI a rough idea of comparison in terms of security maturity across a given industry. With a large enough data set, very interesting patterns and trends often emerge. All findings below are based on our small geographic sample.

 

In this case, we quickly identified that our sample set was not as mature in their phishing controls as other industries. There were substantially more overall phishing targets easily identified across the board than other industries we’ve sampled (we mined 312 targets in 60 seconds). However, the platform ranks the threats against the identified phishing targets using basic keyword analysis against the mined email addresses, and in this case, the good news is that only 3 “critical risk” target accounts were identified. So, while the engine was able to mine more accounts in a minute than other industries with similar sized samples, the number of critical accounts mined in a minute was quite a bit less than usual. We ranked their maturity as low, because in addition to the number of mined accounts, the platform also found specific histories of this attack vector being exploited, some as recent as within 3 days of the study.

 

The study set also showed issues with poor DNS hygiene to be prevalent across the study group. Leaking internal IP address information and exposure of sensitive information via DNS was common across the data set. Many of the companies in the data set also exposed several dangerous host names that attackers are known to target to the Internet. Overall, 67 sensitive DNS entries were found, which is again significantly higher than other similar industry datasets. When compared against highly regulated industry data sets of similar size, the logistics industry sample shows an 18% increase versus average with regard to poor DNS hygiene. This likely increases the probability of focused targeting against what is commonly viewed as weaker targets – translating to increased risk for the logistics industry.

 

Lastly, the data set also demonstrated the logistics industry to be plagued with the use of plain text protocols. Telnet and FTP exposures were the norm across the data set. Given the known dependence on flat file, EDI and other plain text operations data across the logistics industry, the maturity of controls surrounding these exposures seems to be relatively low. In some cases, anonymous FTP was also in use and exposed operational data (we have notified the companies of the issue) across the Internet. This is a significant problem, and represents a clear and present danger to the operations of these firms (according to the sources we talked with about the issue). We also identified attacker conversations around this issue, and the presence of these targets on attacker lists of compromised hosts or hosts to use for covert data exchange!

 

Obviously, if you are a security person for a logistics firm, these points should be used for a quick review of your own. If you’d like to discuss them or dive deeper into these issues, please don’t hesitate to get in touch with MSI (@microsolved) or give us a call for a free consultation. As always, thanks for reading, and until next time, stay safe out there!