Day: August 15, 2017

Posted on

The Curious Case of Notepad and Chthonic: Exposing a Malicious Infrastructure

Recently, I’ve been investigating malware utilizing PowerShell and have spent a considerable amount of time refining ways to identify new variants of attacks as they appear. This posting is a follow-up of my previous work on this subject in  “Pulling Back the Curtains on EncodedCommand PowerShell Attacks”.

In a sample I recently analyzed, something stood out as extremely suspicious which led me down a rabbit hole, uncovering malicious infrastructure supporting Chthonic, Nymaim, and other malware and malicious websites.

Throughout this blog post I present my analysis and thought process during this research, but if you would just like a list of the findings, they are over on our Unit42 GitHub.

One of these things is not like the others…

Most commonly, PowerShell is launched from a Microsoft Office document that uses a VBA macro to launch PowerShell to perform something malicious – typically downloading the “real” malware to run. I focused my hunting on the PowerShell activity with Palo Alto Networks AutoFocus to determine whether it’s worth digging into further based on “uniqueness” and functionality.

In this case, the first sample I looked at stood out for another reason entirely. If you take a look at the below PowerShell, you’ll quickly understand why.

This code downloads a file from the legitimate Notepad++ website. My initial thought was the worst-case scenario – they’ve been compromised and are distributing malware! I immediately downloaded the file from the website, but everything looked normal. Of course, I had to investigate further.

The sample stayed true to the previous outline I laid out for these attacks: the Microsoft Excel document appeared to be a lure about financial information, specifically a VAT invoice written in Polish as shown below.

Looking under the hood we see the VBA code that builds the PowerShell command and launches it but something seemed off. There are a ton of functions that are clearly decoding information from arrays after which it executes an already decoded PowerShell command. I decided to debug the macro and see exactly what it’s doing before I made any decisions.

If you look at the above image, there are five things to note.

1. The variable ‘horrorr’ (double ‘r’) is the result of all of the previously mentioned decoding functions. This builds a PowerShell command.

2.You can see ‘Shelleeeee horrorr, 0’ commented out, I believe this was intended to launch the previous PowerShell command.

3. The ‘Debug.Print horrorr’ prints the content of that variable in the ‘Immediate’ area shown in the screenshot. The domain in this command is NOT ‘notepad-plus-plus.org’ and can be seen below.

4. The ‘MsgBox’ will pop-up and not display anything, because the variable passed is ‘horror’ (1 ‘r’) along with the message ‘Do you really think I’m not a virus?’ in Polish.

5. The hard coded PowerShell command with ‘notepad-plus-plus.org’ will run.

The most likely conclusion that can be drawn here is that an analyst or researcher obtained this file, modified it to see the content (misspelling the variable name along the way) post-decoding, and uploaded it to see what it did in a sandbox. To be sure though, I needed to find other samples and see how they stacked up against this one.

Going back to the PowerShell command, the initial reason I stopped to look at it was due to the way they concatenated variables to form the download command and output. This also provides a perfect pivot point to hunt for samples. Using the below string to search Process Activity in AutoFocus revealed 171 samples.

The dates were all fairly recent, having been received in the past few days since the beginning of August. The documents shared the same themes for lures but the VBA macro and resulting PowerShell were more along the lines of what I expected.

For sample “538ff577a80748d87b5e738e95c8edd2bd54ea406fe3a75bf452714b17528a87” the following is an excerpt from the VBA macro building the PowerShell command.

Along with the subsequent Process Activity using the newly built PowerShell command, which aligns with what was commented out of the first sample analyzed.

Given this, I iterated over all 171 samples and extracted the following URL’s where PowerShell is downloading a payload.

Pass the Chthonic

Going back to the Process Activity, we can see the SHA256 value of each downloaded file and compile a list of hashes for further pivoting as shown below.

After iterating over the 171 samples, we’re left with this list of hashes for the downloaded files. Note that there are fewer payloads than there are samples, indicating many of the documents download the same payload.

Below is a table with the compile date and some PDB strings found within a few of the binaries. Most of the compile times are within the past two months, with 6 in August and a couple from as recently as two days ago at the time of this writing.

SHA256 Compile Date PDB String
29c7740f487a461a96fad1c8db3921ccca8cc3e7548d44016da64cf402a475ad 2016-12-10 01
d5e56b9b5f52293b209a60c2ccd0ade6c883f9d3ec09571a336a3a4d4c79134b 2016-12-10 03 C:\RAMDrive\Charles\heaven\reams\Teac.pdb
dd5f237153856d19cf20e80ff8238ca42047113c44fae27b5c3ad00be2755eea 2016-12-10 16 C:\Cleaner\amuse\rang\AutoPopulate\la.pdb
a5001e9b29078f532b1a094c8c16226d20c03922e37a4fca2e9172350bc160a0 2016-12-20 18
8284ec768a06b606044defe2c2da708ca6b3b51f8e58cb66f61bfca56157bc88 2017-07-05 10
f0ce51eb0e6c33fdb8e1ccb36b9f42139c1dfc58d243195aedc869c7551a5f89 2017-07-09 20 C:\TableAdapter\encyclopedia\Parik.pdb
145d47f4c79206c6c9f74b0ab76c33ad0fd40ac6724b4fac6f06afec47b307c6 2017-07-10 08 C:\ayakhnin\reprductive\distortedc.pdb
dc8f34829d5fede991b478cf9117fb18c32d639573a827227b2fc50f0b475085 2017-07-11 01 C:\positioning\scrapping\Szets\thi.pdb
7fe1069c118611113b4e34685e7ee58cb469bda4aa66a22db10842c95f332c77 2017-07-11 02 C:\NeXT\volatile\legacyExchangeDNs.pdb
5edf117e7f8cd176b1efd0b5fd40c6cd530699e7a280c5c7113d06e9c21d6976 2017-07-12 23
2a80fdda87127bdc56fd35c3e04eb64a01a159b7b574177e2e346439c97b770a 2017-07-13 00
a9021e253ae52122cbcc2284b88270ceda8ad9647515d6cca96db264a76583f5 2017-07-18 00
dd639d76ff6f33bbfaf3bd398056cf4e95e27822bd9476340c7703f5b38e0183 2017-07-18 00
e5a00b49d4ab3e5a3a8f60278b9295f3d252e3e04dadec2624bb4dcb2eb0fada 2017-07-24 17
6263730ef54fbed0c2d3a7c6106b6e8b12a6b2855a03e7caa8fb184ed1eabeb2 2017-07-24 22 C:\Snapshot\Diskette\hiding\ROCKMA.pdb
43bfaf9a2a4d46695bb313a32d88586c510d040844f29852c755845a5a09d9df 2017-07-25 06
b41660db6dcb0d3c7b17f98eae3141924c8c0ee980501ce541b42dc766f85628 2017-07-25 06 C:\mdb\Changed\Container\praise.pdb
9acdad02ca8ded6043ab52b4a7fb2baac3a08c9f978ce9da2eb51c816a9e7a2e 2017-07-25 07
2ddaa30ba3c3e625e21eb7ce7b93671ad53326ef8b6e2bc20bc0d2de72a3929d 2017-07-25 20 C:\helpers\better\Expr\Eight\DS.pdb
b836576877b2fcb3cacec370e5e6a029431f59d5070da89d94200619641ca0c4 2017-07-26 12 C:\V\regard\violates\update\AMBW\a.pdb
0972fc9602b00595e1022d9cfe7e9c9530d4e9adb5786fea830324b3f7ff4448 2017-07-26 20
2c258ac862d5e31d8921b64cfa7e5a9cd95cca5643c9d51db4c2fcbe75fa957a 2017-07-27 01 C:\executablery\constructed\IIc.pdb
dd9c558ba58ac81a2142ecb308ac8d0f044c7059a039d2e367024d953cd14a00 2017-07-27 02
cb3173a820ac392005de650bbd1dd24543a91e72d4d56300a7795e887a8323b2 2017-07-31 14 C:\letterbxing\EVP\Chices\legit.pdb
a636f49814ea6603534f780b83a5d0388f5a5d0eb848901e1e1bf2d19dd84f05 2017-07-31 18 C:\Biomuse\moment\705\cnvincing.pdb
677dd11912a0f13311d025f88caabeeeb1bda27c7c1b5c78cffca36de46e8560 2017-07-31 21
fdedf0f90d42d3779b07951d1e8826c7015b3f3e724ab89e350c9608e1f23852 2017-08-01 21
142bf7f47bfbd592583fbcfa22a25462df13da46451b17bb984d50ade68a5b17 2017-08-02 09
6f4b2c95b1a0f320da1b1eaa918c338c0bab5cddabe169f12ee734243ed8bba8 2017-08-02 12 C:\cataloging\Dr\VarianceShadows11.pdb
fd5fd7058cf157ea249d4dcba71331f0041b7cf8fd635f37ad13aed1b06bebf2 2017-08-04 02 C:\dumplings\That\BIT\Warez\loc.pdb
5785c2d68d6f669b96c3f31065f0d9804d2ab1f333a90d225bd993e66656b7d9 2017-08-07 12 C:\Lgisys\hypothesized\donatedc.pdb
675719a9366386034c285e99bf33a1a8bafc7644874b758f307d9a288e95bdbd 2017-08-07 17 C:\work\cr\nata\cpp\seven\seven\release\seven.pdb

At least one of the binaries compiled in August had a PDB string I was able to locate online in a collection of other PDB files, so they may be introducing their malicious code into these files before compiling someone else’s project.

Once the file has been downloaded and executed, the new process will launch a legitimate executable, such as “msiexec.exe”, and inject code into it. This code will then download further payloads through a POST request to various websites. This pattern is shared across the original samples.

These HTTP requests match known patterns for a banking Trojan named Chthonic, which is a variant of Zeus. A good write-up from 2014 on the malware can be found in this writeup from Yury Namestnikov, Vladimir Kuskov, Oleg Kupreev at Kaspersky Lab here and indicates that the returned data is an RC4 encrypted loader that sets-up the main Chthonic module which can download additional modules or malware.

A dab of Nymaim

Iterating once again over the 171 samples and scraping out the HTTP POST requests, I ended up with the below set of domains.

Using this as the next pivot, we have 6,034 unique samples that get returned in AutoFocus having made POST requests to these sites. Additionally, we can see there were at least 3 very large campaigns where Palo Alto Networks saw activity to these sites in July.

From these distribution sites, we can see that 5,520 samples are making HTTP requests to them and these samples have been identified as another downloader Trojan named Nymaim.

The majority of the overall samples came from the following four sites.

The ‘ejtmjealr[.]com’ domain is particularly interesting due to a similar domain, ‘ejdqzkd[.]com’ being discussed by Jarosław Jedynak of CERT.PL in this analysis of Nymaim from earlier in the year. They go on to discuss how Nymaim uses a static configuration to contact that domain, which will return IP’s that go into a DGA and output the actual IP addresses needed for C2 communication. Ben Baker, Edmund Brumaghin and Jonah Samost of Talos have a fantastic write-up of this process here.

Raising the dead – Infrastructure Archeology

To continue my analysis, I shifted focus to Maltego so as to visually graph the infrastructure. For this task, I used PassiveTotal’s Passive DNS and AutoFocus Maltego transforms. We see below the passive resolutions for these domains and how it reveals a number of IP addresses being shared between the four domains identified above.

All of the 707 IP addresses can be found here. Note that while these IP’s have been found to be hosting malicious content, this could change in the future.

Pivoting off the five highlighted IP’s above with a shared infrastructure, I pulled the reverse DNS to see what other sites may be present. The below is a sampling of the domains returned through this process.

The “idXXXXX.top” pattern immediately stands out and may suggest a pattern in the static configuration for the initial domains used by the DGA for Nymaim since the previous two started with “ejX.com.

Given the level of overlap already, I proceeded to grab all of the passive DNS available for each of the 707 IP addresses. A full list of the domains can be seen here. The below Maltego graph is used to simply illustrate the two distinct clusters of infrastructure that appeared and their interconnectedness.

From the first cluster on the left, if we sort by incoming links per node a pattern stands out in the domain names looking similar to the previously mentioned Nymaim ones. In the below image, the top domains are sorted by incoming links on the right side. Each link is a corresponding IP address and show that these domains have been rotated quite a bit between the infrastructure.

A quick search with the AutoFocus transform to pull tag information shows these are specifically related to Nymaim, most likely for the DGA seed; however, looking at domains with less links, other malware families begin to emerge.

The cluster on the right is actually collapsing one collection of entities due to the sheer size of it. Below is the collection expanded in all of its glory.

Below are the domain names linked to the singular IP address in the center.

All of these connected domains follow a pattern similar to phishing attacks masquerading as legitimate services – in this case “online.verify[.]paypal” (588) and “hmrc.secure[.]refund” (1021).

In addition to domains of that type, there is evidence of other malware distribution being carried out on this infrastructure. Collapsing the collection back down, note the two domains “brontorittoozzo[.]com” and “randomessstioprottoy[.]net” that fall outside of the collection due to more infrastructure connections.

A quick search for these domains will land you on fellow Unit 42 researcher Brad Duncan’s malware-traffic-analysis (MTA) site for post “2017-06-22 – LOCKY MALSPAM – PDF ATTACHMENTS WITH EMBEDDED .DOCM FILES” in which he lists out URL’s found within malicious Microsoft Word documents that download Locky as shown below.

In some of the other smaller clusters, you’ll find groupings of like malicious sites.

For example, there is a group with gems like “premarket[.]ws” like you see below being hosted on this shared infrastructure, which is a forum for less than legal services.

Along with sites like “slilpp[.]ws” which is another less than reputable site as shown below.

Which ironically has a Twitter support account that specifically states the following.

And yet another here below…

There are 632 people happily following along with relatively easy to track down accounts and usernames. A substantial amount of these accounts, on quick review, appear to follow the typical Nigerian cybercrime patterns detailed in other blogs.

Finally, there were multiple clusters of domains used by the Hancitor malware dropper to host the initial check-in and tracking as shown here.

Which can be seen as having been used in a campaign on July 03, 2017 via a post on MTA below.

Conclusion

By pivoting off of one sample we were able to zoom out and identify a sizable infrastructure of what appears to be 707 IP’s and 2,611 domains being utilized for malicious activity.

As such, these findings represent a collection of compromised websites, compromised registrar accounts used to spin up subdomains, domains used by malware DGA’s, phishing kits, carding forums, malware C2 sites, and a slew of other domains that revolve around criminal activity.

Hopefully this analysis has been helpful in understanding how truly connected some of these infrastructures can be and how with a little digging, you can uncover a substantial amount of operationally useful indicators to protect you and yours.

AutoFocus users can identify and track these threats using the Chthonic, Nymaim, and NotepadInfrastructure tags.

[Palo Alto Networks Research Center]

Posted on

Physical and Logical Security: Joining Forces to Manage your Enterprise Security Risk

Just a decade ago, as security professionals, we could talk reasonably about physical security and logical security requiring different approaches. Five years ago, we might have found ourselves having conversations about the blurring lines between the two types of security discipline, and could have easily pointed to aspects of both physical and logical security that crossed over each other.

Today? In organizations that have embraced even the least cutting-edge aspects of operational and information technological advances (consumer IoT, industrial IoT, cloud hosted services, etc.), we can no longer rationally discuss a strictly “physical” or “logical” approach to managing security risks to the enterprise.

Quite simply, in a world where:

  • Every camera and door lock in a facility has an individual IP address
  • All security investigations must happen in the real and virtual worlds at the same time
  • Even the most visibly “physical” of protective measures – security officers – are networked via trackers and devices to provide instant information and communication
    … there are few, if any, areas left that do not require attention to a holistic and comprehensive view of all security disciplines at once.

What does this mean for the personnel and management teams that are tasked with providing security in this borderless environment? How do we, as practitioners who may have long histories in a single discipline, protect the organization in a security environment where the risks and mitigation tactics have converged, regardless of whether our organizational structures have evolved to match them?

The answer: Enterprise Security Risk Management (ESRM).

ESRM is a risk management model that allows all functional areas tasked with mitigating security risk to operate under a converged philosophy and approach to more efficiently and effectively mitigate security risk across the enterprise, regardless of the physical or logical nature of the asset, or the vector of the potential threat.

Recognizing the Role
ESRM allows security personnel to work together to effectively protect the enterprise from a broad spectrum of security risks by first recognizing that it is the role of the security organization, at root, to manage security risk in conjunction with the business, and to protect assets from harm in line with business tolerance.

The tasks we perform to mitigate risks might be different, but the process of identifying the assets to be protected, recognizing and prioritizing the risks to those assets, and then mitigating the assets to within acceptable levels of business tolerance, are the same. Take a look at the table below, excerpted from the forthcoming book, Enterprise Security Risk Management: Concepts and Applications (Allen & Loyear, 2017). It shows a quick side-by-side of the kinds of tasks that security groups do, and how they are essentially mitigation responses to the same security risks.

The overarching risks cannot be effectively mitigated by only a single tactical function. Working together, under a common risk management framework, all security personnel can more effectively protect the enterprise environment against security risk.

The Benefits of ESRM and Cross-Functional Risk Management Collaboration
Managing all security risks in partnership and under a common ESRM approach can bring the enterprise significant gains in efficiency and effectiveness, even with multiple groups participating in the security partnership. A few to note include:

  • Unified security awareness messaging
    • A partnership approach under an ESRM philosophy allows for the creation of a single, unified, security message that include all facets of security awareness.
  • Single security point-of-contact
    • When all security teams operate under the risk-management approach with the same defined processes, any security incident can be reported to a single point in the company and escalated and directed as needed to the appropriate response team.
  • Operational efficiency
    • Employees with different skill sets can more easily collaborate on incident response processes.
    • Information sharing enables cross-department cooperation during security investigations that require both physical and logical forensics.
    • Streamlined processes save hours and money, allowing diverse security risks to be managed by a single process.
    • Consolidated metrics reporting to business management save time and effort.
  • Optimized risk profile
    • All security risks are identified and managed in an overarching program, making the risk identification and mitigation process more robust and decreasing the potential of overlooked risk.

How Do We Get There?
So, how do we get to the point of converging under a common philosophy, regardless of reporting lines and department structures?

All leaders in the organization with any security responsibilities can align with a risk-management approach by asking themselves:

  • Does my team have clear risk management goals aligned with business risk tolerance?
  • Does my team work with other department stakeholders in the risk decision-making process?
  • Do the members of my team work together with other security teams in situations that cross boundaries of scope?
  • Am I communicating to all areas of the business that my role, and the role of all other security teams, is to manage security risks holistically?

When all the security functions in the enterprise choose to embrace a risk management – ESRM – approach, the outcome is that:

  • All security teams follow a formal and consistent process for security risk decision-making.
  • All security teams follow the same incident response approach, including postmortem investigations and root cause analysis to continually improve the security risk situation of the enterprise.
  • All security teams work in partnership with one another, ensuring open communications and collaboration across department lines.
  • All security teams have the transparency, independence, authority and scope needed to do their work in the right way.
  • All security risks, no matter which team mitigates the risks, are considered part of the holistic security risk management program.
  • All security teams, no matter who they report to, understand that security risk management is everyone’s role.

Rachelle Loyear, CISM, MBCP, AFBCI, PMP, Partner, Security Risk Governance Group

[ISACA Now Blog]

Posted on

IoT Cybersecurity Act of 2017: A Necessary But Insufficient Approach

The Mirai botnet attack on the DYN network in October 2016 highlighted to many policymakers the potential problems associated with IoT devices. The compromise and concerted use of thousands of webcams and DVRs to disrupt key Internet services focused attention on the poor implementation of security controls on millions of devices newly connected to the Internet.

The introduction of the IoT Cybersecurity Improvement Act of 2017 by a bipartisan group of US senators seeks to address the inherent threat IoT devices pose to federal government services. This bill builds on recent efforts, including the Trump administration’s new executive order on cyber security for federal networks and critical infrastructure.

The IoT Cybersecurity Improvement Act would require the Office of Management and Budget Director to confer with various cabinet and agency officials to define implementation guidance to ensure contracts that enable IoT installation in federal systems meet standards that allow for regular identification and patching of vulnerabilities found in deployed IoT devices across the federal government. The central concept of the bill is the requirement for contractors and agency heads to own the evolving security footprint of IoT devices deployed in their network. This approach is consistent with the Trump administration’s guidance for agency heads to be held responsible for the protection of their networks and critical systems and to include these devices as part of an overall assessment of risk.

While the bill requires contractors to assess deployed “internet connected devices” against vulnerability databases and recommend patching strategies, it does allow agency heads to apply for waivers in cases where devices with “severely limited functionality,” defined as Internet-connected devices with limited data processing and software functionality, can be exempted from the requirement if the executive agency deems it “economically impractical.”

For example, if an agency has deployed 10,000 smart lightbulbs and a vulnerability is found, the head of the organization would be able to request a waiver noting that those lightbulbs have limited functionality and would represent an “undue burden” to replace them with newer models (or push out a patch). It is reasonable for the government to carve out this exception. However, it does raise a fundamental issue. If most IoT devices, including small sensors, lightbulbs, etc., are individually cheap by design (e.g., to be competitively viable as compared to traditional devices), does the introduction of those devices pose an unacceptable risk to the federal agency? Or, in other words, is the agency willing to allow devices that could be used as a relay in a cyber campaign because the devices have “severely limited functionality”?

The bill addresses this problem through the requirement of a risk assessment. In this case, the bill attempts to leverage the current requirement for agencies to develop comprehensive risk frameworks as laid out in the May 11, 2017 US Cybersecurity Executive Order. Those requirements ensure agencies follow the NIST Cybersecurity Framework, which provides organizations with a set of best practices to identify and reduce their cybersecurity risk. This makes sense, yet neither the bill nor the NIST framework provide methodologies for conducting the actual risk assessment. Instead, agencies are left to design and implement their own approaches, which is useful but ultimately problematic, as an inconsistent set of definitions and criteria can be applied.

If IoT devices are structurally incentivized to not integrate robust security controls, and agencies can apply for exemptions to found vulnerabilities, and our application of risk assessment is immature to not fully grasp how those devices can be leveraged by hackers, how can we embrace evolving technology while at the same time protecting the most critical services provided by federal agencies?

The IoT Cybersecurity Improvement Act of 2017 would be a good piece of legislation, as it serves to move the ball forward in highlighting an area of weakness in federal network security. However, the inconsistent and immature processes by which we assess risk to our core services undermines its effectiveness.

Editor’s note: Prior to Dr. Harry’s appointment at the University of Maryland, he spent more than 14 years working in the federal government.

Dr. Charles Harry, Director of Operations, University of Maryland Global Initiative in Cybersecurity, Associate Research Professor in the School of Public Policy

[ISACA Now Blog]

Posted on

What Does the Future of Financial Cyber Security Look Like?

Today, we trust banks and other financial institutions to safely handle our money and the bulk of our monetary transactions. Successful breaches are somewhat rare thanks to technologies like multi-factor authentication and heavy investment in cyber security, but hackers are always improving their techniques, and tech is always changing. This leads to an ongoing cycle of improvement on both sides: financial institutions keep building better defenses, and hackers keep trying to overcome those advancements.

So, could the financial industry eventually get ahead of the cybercriminals? What does the future hold for financial cyber security?

Consumer trust
Financial institutions’ most important job is building and maintaining consumer trust. Without that, people won’t be willing to part with their money, and the entire system could collapse. That’s why financial companies are working hard to stay ahead of the curve, to inform their customers proactively about prospective threats, explain what they’re doing to stop them, and of course, give them the proof that what they’re doing actually works. Third parties will always be around to rate banks and lending institutions for the quality of their offers, and security will only grow in importance as a factor in the future.

New threats
These are some of the most important threats we need to prepare for:

  • Botnet attacks. The concept of a botnet is relatively simple; a hacker uses a program to gain access to multiple independent devices, usually connected in a peer-to-peer web-like network, and then coordinate those devices to execute an attack. This could come in the form of a distributed denial of service (DDoS) attack, or to steal data, which can then be used to compromise financial accounts.
  • Self-mutating viruses. Standard computer viruses already have the potential to infect a computer, enabling the virus creator to steal information from the victim’s computer or use it as part of a botnet in the future. However, antivirus software often catches and eliminates these threats based on recognized patterns. Self-mutating viruses go a step further; they have the capacity to evolve, sometimes in response to direct threats, making them notoriously difficult to detect and prevent. Fortunately, these are in the early stages of development, and haven’t had much of an impact as a cyber threat thus far.
  • Biohacking. Biohacking refers to a number of different possible actions, all of which focus on identifying important people and gaining access to the biological features that make them unique. As biometrics start to become more heavily integrated, biohacking will grow in both importance and prominence, giving hackers a way to obtain fingerprints or other forms of personal information to gain access to systems.
  • BYOD manipulation. Thanks to the rise of mobile devices, many businesses have now adopted a bring-your-own-device (BYOD) policy, allowing and sometimes mandating that individual users bring their personal devices to the centralized workplace. For cyber criminals, this represents a wealth of opportunities; all it takes is one breached device on a shared network to bring the entire system down.

New technologies
These are some of the ways financial institutions are protecting themselves:

  • Biometrics. Biometrics are a branch of security standards that rely on personal information, such as fingerprints, speech patterns, or even the shape of your ears, to authenticate identity. There are still a number of kinks to work out – such as how biometrics change with growth or significant life events – but if perfected, it could make it nearly impossible for thieves to replicate this information on their own.
  • Quantum cryptography. Typical encryptions use a “key,” which is usually randomly generated, to encode information that can only be decoded by authorized devices and programs, at least in theory. Dedicated hackers could uncover the key and use it to translate messages, with enough effort. However, quantum cryptography takes encryption to the next level, relying on the wave function of elementary particles and quantum physics to encode information in a way that is basically unhackable. The technology isn’t foolproof yet, but someday, it could encrypt information with absolute certainty.
  • Blockchain. Blockchain, the technology used to power the crypto-currency Bitcoin, is already starting to be used in the financial industry. It relies on a peer-reviewed open ledger to record and remember transactions, making it nearly impossible to record fraudulent transactions or “steal” from other participants in the chain. It’s a technology still in its infancy, but it has massive disruptive potential.

It’s hard to chart an exact course for the development of technology, as cybercriminals are always looking for surprising new angles, developers are working on projects in secret, and all it takes is one new revelation to force changes on both sides. Still, the world of financial cyber security will be interesting to watch in the coming years.

Anna Johannson, Writer

[ISACA Now Blog]

English
English
Exit mobile version