Home Tags RBS

Tag: RBS

Hacking group RTM able to divert bulk financial transfers with malware

Attacks of great concern to Russian financial institutions Cybercrime group RTM is deploying complex malware based in the Delphi programming language to target Remote Banking Systems (RBS), a type of business software used to make bulk financial transfers.…

‘Tesco Bank’s major vulnerability is its ownership by Tesco,’ claims ex-employee

Links to supermarket's systems may have exposed vulnerability A former techie at Tesco Bank reckons the recent high-profile breach may be down to security shortcomings at the bank's parent supermarket. Earlier this month Tesco Bank admitted that an estimated £2.5m had been stolen from 9,000 customer accounts in the biggest cyber-heist of its kind to affect a UK bank.

The National Crime Agency (NCA), with technical support from the newly established UK National Cyber Security Centre (NCSC), is leading a criminal investigation into the breach. NCSC issued a statement saying it was "unaware" of any threat to the wider UK banking sector. Tesco Bank's security procedures were solid but the bank was exposed because of Tesco's "not-very-secure-at-all systems" – a weakness hackers might well have exploited, our informed source (who requested anonymity) speculates. TB [Tesco Bank] use all the standard security processes, and have significant numbers of ex-RBS staff.
Security architecture is sound, and vulnerabilities are patched in a timely manner.

Fraud monitoring systems are industry standard.

A full breach is very unlikely, and there are much bigger and better targets if a gang has access to relevant zero-days. All staff are vetted as per standard processes – TB is no more vulnerable to an internal breach than anyone else.

Again, bigger and better targets are available.

TB does have a problem with retaining experienced staff, and hoping that junior staff will step up when they leave, but that's not uncommon. TB had one breach when they first opened Current Accounts – someone in the card printers got a list of card numbers and sold them.
It was caught in time, and cards were destroyed. Presumably security at the printers has been improved, but I'd consider that to be a continuing possible vulnerability. However, TB's major vulnerability is its ownership by Tesco, and the links between its secure systems and Tesco's not-very-secure-at-all systems.

There was no evidence of patching and monitoring occurring in Tesco systems that we linked to at all.
I strongly suspect that the Clubcard system has been breached and a list of TB account numbers farmed from there.
I also suspect that nothing will be done to trace that possible route – TB has no influence over Tesco at all, due to relative scale, and the apparent bad relations between the chief executives. In a follow-up email the former Tesco Bank worker, who worked in IT for the bank and at one time on its anti-fraud system, offered more details on security failings at the parent retailer. I worked on a TB project that had to verify certain customer information on Tesco systems.

The Tesco system would fall over on a regular basis, and we would have to tell Tesco it was down – they wouldn't monitor it.
It later became clear that it was an app server running on a very outdated piece of middleware, completely unpatched.

This was standard for Tesco systems. [The] only exception was the credit card payment system, which was secure because it was regulated.
Separately I was aware of an effort to tie some TB systems more closely to Clubcard. However, it had to be abandoned once the architects discovered how insecure Clubcard itself was. Various theories about what might have caused the breach at Tesco Bank have already been suggested.
Security watchers have variously blamed credential stuffing, an inside job, and exploitation of a third-party supplier retail partner for the breach. Around 136,000 customers hold current accounts with Tesco Bank. Holders of other accounts were not affected by the breach. Security intelligence firm Digital Shadows recently applied techniques for the Analysis of Competing Hypothesis (ACH) to assess the likelihood of the various competing explanations on offer.
It concluded that either payment system compromise or the cash-out of cloned cards were the two theories that best matched the available facts.

Cash-out of cloned cards would likely have been simpler to execute than payment system compromise, according to Digital Shadows, prompting the firm to lean towards this theory while not ruling out other possibilities. El Reg ran insights from the former Tesco Bank techie past Digital Shadows.
In response, Digital Shadows said that it had seen nothing so far which would suggest security problems at Tesco supermarket was behind the breach before conceding that it was still investigating the breach. Ken Munro, a director at security consultancy Pen Test Partners, described the former Tesco staffer's theory as all too plausible, based on his years of experience in the IT biz rather than any direct knowledge of the supermarket's systems. "So often it's the incidental systems that cause issues," Munro told El Reg. "One builds a secure app, but then has to hook it up to an existing access/authorisation system, or something similar.
I remember a pen test a few years back of a network that was pretty much bulletproof – up to date, pretty well configured, reasonable passwords etc. "Then we found an old fax server that was on the same domain.
It didn't take long to compromise that flaky fax box and from there the domain controller.

All the good work was undone by some failed oversight of one box. "You're probably only as secure as your least secure system," Munro concluded. Tesco Bank provided this statement: "On 5 and 6 November, Tesco Bank was targeted by fraud, which affected 9000 of our customers and cost us £2.5m. "We identified the fraud quickly and communicated immediately with our customers, the Financial Conduct Authority and National Crime Agency.

This remains a criminal investigation. "We refunded each customer account in full and have taken steps to help reassure our customers that they can bank safely and securely at Tesco Bank." ® Sponsored: Customer Identity and Access Management

The Hunt for Lurk

In early June, 2016, the Russian police arrested the alleged members of the criminal group known as Lurk.

The police suspected Lurk of stealing nearly three billion rubles, using malicious software to systematically withdraw large sums of money from the accounts of commercial organizations, including banks.

For Kaspersky Lab, these arrests marked the culmination of a six-year investigation by the company’s Computer Incidents Investigation team. We are pleased that the police authorities were able to put the wealth of information we accumulated to good use: to detain suspects and, most importantly, to put an end to the theft. We ourselves gained more knowledge from this investigation than from any other.

This article is an attempt to share this experience with other experts, particularly the IT security specialists in companies and financial institutions that increasingly find themselves the targets of cyber-attacks. When we first encountered Lurk, in 2011, it was a nameless Trojan.
It all started when we became aware of a number of incidents at several Russian banks that had resulted in the theft of large sums of money from customers.

To steal the money, the unknown criminals used a hidden malicious program that was able to interact automatically with the financial institution’s remote banking service (RBS) software; replacing bank details in payment orders generated by an accountant at the attacked organization, or even generating such orders by itself. In 2016, it is hard to imagine banking software that does not demand some form of additional authentication, but things were different back in 2011.
In most cases, the attackers only had to infect the computer on which the RBS software was installed in order to start stealing the cash. Russia’s banking system, like those of many other countries, was unprepared for such attacks, and cybercriminals were quick to exploit the security gap. We participated in the investigation of several incidents involving the nameless malware, and sent samples to our malware analysts.

They created a signature to see if any other infections involving it had been registered, and discovered something very unusual: our internal malware naming system insisted that what we were looking at was a Trojan that could be used for many things (spamming, for example) but not stealing money. Our detection systems suggest that a program with a certain set of functions can sometimes be mistaken for something completely different.
In the case of this particular program the cause was slightly different: an investigation revealed that it had been detected by a “common” signature because it was doing nothing that could lead the system to include it in any specific group, for example, that of banking Trojans. Whatever the reason, the fact remained that the malicious program was used for the theft of money. So we decided to take a closer look at the malware.

The first attempts to understand how the program worked gave our analysts nothing. Regardless of whether it was launched on a virtual or a real machine, it behaved in the same way: it didn’t do anything.

This is how the program, and later the group behind it, got its name.

To “lurk” means to hide, generally with the intention of ambush. We were soon able to help investigate another incident involving Lurk.

This time we got a chance to explore the image of the attacked computer.

There, in addition to the familiar malicious program, we found a .dll file with which the main executable file could interact.

This was our first piece of evidence that Lurk had a modular structure. Later discoveries suggest that, in 2011, Lurk was still at an early stage of development.
It was formed of just two components, a number that would grow considerably over the coming years. The additional file we uncovered did little to clarify the nature of Lurk.
It was clear that it was a Trojan targeting RBS and that it was used in a relatively small number of incidents.
In 2011, attacks on such systems were starting to grow in popularity. Other, similar, programs were already known about, the earliest detected as far back as in 2006, with new malware appearing regularly since then.

These included ZeuS, SpyEye, and Carberp, etc.
In this series, Lurk represented yet another dangerous piece of malware. It was extremely difficult to make Lurk work in a lab environment. New versions of the program appeared only rarely, so we had few opportunities to investigate new incidents involving Lurk.

A combination of these factors influenced our decision to postpone our active investigation into this program and turn our attention to more urgent tasks. A change of leader For about a year after we first met Lurk, we heard little about it.
It later turned out that the incidents involving this malicious program were buried in the huge amount of similar incidents involving other malware.
In May 2011, the source code of ZeuS had been published on the Web and this resulted in the emergence of many program modifications developed by small groups of cybercriminals. In addition to ZeuS, there were a number of other unique financial malware programs.
In Russia, there were several relatively large cybercriminal groups engaged in financial theft via attacks on RBS.

Carberp was the most active among them.

At the end of March 2012, the majority of its members were arrested by the police.

This event significantly affected the Russian cybercriminal world as the gang had stolen hundreds of millions of rubles during a few years of activity, and was considered a “leader” among cybercriminals. However, by the time of the arrests, Carberp’s reputation as a major player was already waning.

There was a new challenger for the crown. A few weeks before the arrests, the sites of a number of major Russian media, such as the agency “RIA Novosti”, Gazeta.ru and others, had been subjected to a watering hole attack.

The unknown cybercriminals behind this attack distributed their malware by exploiting a vulnerability in the websites’ banner exchange system.

A visitor to the site would be redirected to a fraudulent page containing a Java exploit.
Successful exploitation of the vulnerability initiated the launch of a malicious program whose main function was collecting information on the attacked computer, sending it to a malicious server, and in some cases receiving and installing an extra load from the server. The code on the main page of RIA.ru that is used to download additional content from AdFox.ru From a technical perspective, the malicious program was unusual. Unlike most other malware, it left no traces on the hard drive of the system attacked and worked only in the RAM of the machine.

This approach is not often used in malware, primarily because the resulting infection is “short-lived”: malware exists in the system only until the computer is restarted, at which point the process of infection need to be started anew.

But, in the case of these attacks, the secret “bodiless” malicious program did not have to gain a foothold in the victim’s system.
Its primary job was to explore; its secondary role was to download and install additional malware.

Another fascinating detail was the fact that the malware was only downloaded in a small number of cases, when the victim computer turned out to be “interesting”. Part of the Lurk code responsible for downloading additional modules Analysis of the bodiless malicious program showed that it was “interested” in computers with remote banking software installed. More specifically, RBS software created by Russian developers. Much later we learned that this unnamed, bodiless module was a mini, one of the malicious programs which used Lurk.

But at the time we were not sure whether the Lurk we had known since 2011, and the Lurk discovered in 2012, were created by the same people. We had two hypotheses: either Lurk was a program written for sale, and both the 2011 and 2012 versions were the result of the activity of two different groups, which had each bought the program from the author; or the 2012 version was a modification of the previously known Trojan. The second hypothesis turned out to be correct. Invisible war with banking software A small digression. Remote banking systems consist of two main parts: the bank and the client.

The client part is a small program that allows the user (usually an accountant) to remotely manage their organization’s accounts.

There are only a few developers of such software in Russia, so any Russian organization that uses RBS relies on software developed by one of these companies.

For cybercriminal groups specializing in attacks on RBS, this limited range of options plays straight into their hands. In April 2013, a year after we found the “bodiless” Lurk module, the Russian cybercriminal underground exploited several families of malicious software that specialized in attacks on banking software.

Almost all operated in a similar way: during the exploration stage they found out whether the attacked computer had the necessary banking software installed.
If it did, the malware downloaded additional modules, including ones allowing for the automatic creation of unauthorized payment orders, changing details in legal payment orders, etc.

This level of automation became possible because the cybercriminals had thoroughly studied how the banking software operated and “tailored” their malicious software modules to a specific banking solution. The people behind the creation and distribution of Lurk had done exactly the same: studying the client component of the banking software and modifying their malware accordingly.
In fact, they created an illegal add-on to the legal RBS product. Through the information exchanges used by people in the security industry, we learned that several Russian banks were struggling with malicious programs created specifically to attack a particular type of legal banking software.
Some of them were having to release weekly patches to customers.

These updates would fix the immediate security problems, but the mysterious hackers “on the other side” would quickly release a new version of malware that bypassed the upgraded protection created by the authors of the banking programs. It should be understood that this type of work – reverse-engineering a professional banking product – cannot easily be undertaken by an amateur hacker.
In addition, the task is tedious and time-consuming and not the kind to be performed with great enthusiasm.
It would need a team of specialists.

But who in their right mind would openly take up illegal work, and who might have the money to finance such activities? In trying to answer these questions, we eventually came to the conclusion that every version of Lurk probably had an organized group of cybersecurity specialists behind it. The relative lull of 2011-2012 was followed by a steady increase in notifications of Lurk-based incidents resulting in the theft of money.

Due to the fact that affected organizations turned to us for help, we were able to collect ever more information about the malware.

By the end of 2013, the information obtained from studying hard drive images of attacked computers as well as data available from public sources, enabled us to build a rough picture of a group of Internet users who appeared to be associated with Lurk. This was not an easy task.

The people behind Lurk were pretty good at anonymizing their activity on the network.

For example, they were actively using encryption in everyday communication, as well as false data for domain registration, services for anonymous registration, etc.
In other words, it was not as easy as simply looking someone up on “Vkontakte” or Facebook using the name from Whois, which can happen with other, less professional groups of cybercriminals, such as Koobface.

The Lurk gang did not make such blunders. Yet mistakes, seemingly insignificant and rare, still occurred.

And when they did, we caught them. Not wishing to give away free lessons in how to run a conspiracy, I will not provide examples of these mistakes, but their analysis allowed us to build a pretty clear picture of the key characteristics of the gang. We realized that we were dealing with a group of about 15 people (although by the time it was shut down, the number of “regular” members had risen to 40).

This team provided the so-called “full cycle” of malware development, delivery and monetization – rather like a small, software development company.

At that time the “company” had two key “products”: the malicious program, Lurk, and a huge botnet of computers infected with it.

The malicious program had its own team of developers, responsible for developing new functions, searching for ways to “interact” with RBS systems, providing stable performance and fulfilling other tasks.

They were supported by a team of testers who checked the program performance in different environments.

The botnet also had its own team (administrators, operators, money flow manager, and other partners working with the bots via the administration panel) who ensured the operation of the command and control (C&C) servers and protected them from detection and interception. Developing and maintaining this class of malicious software requires professionals and the leaders of the group hunted for them on job search sites.

Examples of such vacancies are covered in my article about Russian financial cybercrime.

The description of the vacancy did not mention the illegality of the work on offer.

At the interview, the “employer” would question candidates about their moral principles: applicants were told what kind of work they would be expected to do, and why.

Those who agreed got in. A fraudster has advertised a job vacancy for java / flash specialists on a popular Ukrainian website.

The job requirements include a good level of programming skills in Java, Flash, knowledge of JVM / AVM specifications, and others.

The organizer offers remote work and full employment with a salary of $2,500.
So, every morning, from Monday to Friday, people in different parts of Russia and Ukraine sat down in front of their computer and started to “work”.

The programmers “tuned” the functions of malware modifications, after which the testers carried out the necessary tests on the quality of the new product.

Then the team responsible for the botnet and for the operation of the malware modules and components uploaded the new version onto the command server, and the malicious software on botnet computers was automatically updated.

They also studied information sent from infected computers to find out whether they had access to RBS, how much money was deposited in clients’ accounts, etc. The money flow manager, responsible for transferring the stolen money into the accounts of money mules, would press the button on the botnet control panel and send hundreds of thousands of rubles to accounts that the “drop project” managers had prepared in advance.
In many cases they didn’t even need to press the button: the malicious program substituted the details of the payment order generated by the accountant, and the money went directly to the accounts of the cybercriminals and on to the bank cards of the money mules, who cashed it via ATMs, handed it over to the money mule manager who, in turn, delivered it to the head of the organization.

The head would then allocate the money according to the needs of the organization: paying a “salary” to the employees and a share to associates, funding the maintenance of the expensive network infrastructure, and of course, satisfying their own needs.

This cycle was repeated several times. Each member of the typical criminal group has their own responsibilities. These were the golden years for Lurk.

The shortcomings in RBS transaction protection meant that stealing money from a victim organization through an accountant’s infected machine did not require any special skills and could even be automated.

But all “good things” must come to an end. The end of “auto money flow” and the beginning of hard times The explosive growth of thefts committed by Lurk and other cybercriminal groups forced banks, their IT security teams and banking software developers to respond. First of all, the developers of RBS software blocked public access to their products.

Before the appearance of financial cybercriminal gangs, any user could download a demo version of the program from the manufacturer’s website.

Attackers used this to study the features of banking software in order to create ever more tailored malicious programs for it.

Finally, after many months of “invisible war” with cybercriminals, the majority of RBS software vendors succeeded in perfecting the security of their products. At the same time, the banks started to implement dedicated technologies to counter the so-called “auto money flow”, the procedure which allowed the attackers to use malware to modify the payment order and steal money automatically. By the end of 2013, we had thoroughly explored the activity of Lurk and collected considerable information about the malware.

At our farm of bots, we could finally launch a consistently functioning malicious script, which allowed us to learn about all the modifications cybercriminals had introduced into the latest versions of the program. Our team of analysts had also made progress: by the year’s end we had a clear insight into how the malware worked, what it comprised and what optional modules it had in its arsenal. Most of this information came from the analysis of incidents caused by Lurk-based attacks. We were simultaneously providing technical consultancy to the law enforcement agencies investigating the activities of this gang. It was clear that the cybercriminals were trying to counteract the changes introduced in banking and IT security.

For example, once the banking software vendors stopped providing demo versions of their programs for public access, the members of the criminal group established a shell company to receive directly any updated versions of the RBS software. Thefts declined as a result of improvements in the security of banking software, and the “auto money flow” became less effective.

As far as we can judge from the data we have, in 2014 the criminal group behind Lurk seriously reduced its activity and “lived from hand to mouth”, attacking anyone they could, including ordinary users.

Even if the attack could bring in no more than a few tens of thousands of rubles, they would still descend to it. In our opinion, this was caused by economic factors: by that time, the criminal group had an extensive and extremely costly network infrastructure, so, in addition to employees’ salaries, it was necessary to pay for renting servers, VPN and other technical tools. Our estimates suggest that the network infrastructure alone cost the Lurk managers tens of thousands of dollars per month. Attempts to come back In addition to increasing the number of “minor” attacks, the cybercriminals were trying to solve their cash flow problem by “diversifying” the business and expanding their field of activity.

This included developing, maintaining and renting the Angler exploit pack (also known as XXX).
Initially, this was used mainly to deliver Lurk to victims’ computers.

But as the number of successful attacks started to decline, the owners began to offer smaller groups paid access to the tools. By the way, judging by what we saw on Russian underground forums for cybercriminals, the Lurk gang had an almost legendary status.

Even though many small and medium-sized groups were willing to “work” with them, they always preferred to work by themselves.
So when Lurk provided other cybercriminals with access to Angler, the exploit pack became especially popular – a “product” from the top underground authority did not need advertising.
In addition, the exploit pack was actually very effective, delivering a very high percentage of successful vulnerability exploitations.
It didn’t take long for it to become one of the key tools on the criminal2criminal market. As for extending the field of activity, the Lurk gang decided to focus on the customers of major Russian banks and the banks themselves, whereas previously they had chosen smaller targets. In the second half of 2014, we spotted familiar pseudonyms of Internet users on underground forums inviting specialists to cooperate on document fraud.

Early the following year, several Russian cities were swamped with announcements about fraudsters who used fake letters of attorney to re-issue SIM cards without their owners being aware of it. The purpose of this activity was to gain access to one-time passwords sent by the bank to the user so that they could confirm their financial transaction in the online or remote banking system.

The attackers exploited the fact that, in remote areas, mobile operators did not always carefully check the authenticity of the documents submitted and released new SIM cards at the request of cybercriminals. Lurk would infect a computer, collect its owner’s personal data, generate a fake letter of attorney with the help of “partners” from forums and then request a new SIM card from the network operator. Once the cybercriminals received a new SIM card, they immediately withdrew all the money from the victim’s account and disappeared. Although initially this scheme yielded good returns, this didn’t last long, since by then many banks had already implemented protection mechanisms to track changes in the unique SIM card number.
In addition, the SIM card-based campaign forced some members of the group and their partners out into the open and this helped law enforcement agencies to find and identify suspects. Alongside the attempts to “diversify” the business and find new cracks in the defenses of financial businesses, Lurk continued to regularly perform “minor thefts” using the proven method of auto money flow. However, the cybercriminals were already planning to earn their main money elsewise. New “specialists” In February 2015, Kaspersky Lab’s Global Research and Analysis Team (GReAT) released its research into the Carbanak campaign targeting financial institutions.

Carbanak’s key feature, which distinguished it from “classical” financial cybercriminals, was the participation of professionals in the Carbanak team, providing deep knowledge of the target bank’s IT infrastructure, its daily routine and the employees who had access to the software used to conduct financial transactions.

Before any attack, Carbanak carefully studied the target, searched for weak points and then, at a certain moment in time, committed the theft in no more than a few hours.

As it turned out, Carbanak was not the only group applying this method of attack.
In 2015, the Lurk team hired similar experts. How the Carbanak group operated. We realized this when we found incidents that resembled Carbanak in style, but did not use any of its tools.

This was Lurk.

The Lurk malware was used as a reliable “back door” to the infrastructure of the attacked organization rather than as a tool to steal money.

Although the functionality that had previously allowed for the near-automatic theft of millions no longer worked, in terms of its secrecy Lurk was still an extremely dangerous and professionally developed piece of malware. However, despite its attempts to develop new types of attacks, Lurk’s days were numbered.

Thefts continued until the spring of 2016.

But, either because of an unshakable confidence in their own impunity or because of apathy, day-by-day the cybercriminals were paying less attention to the anonymity of their actions.

They became especially careless when cashing money: according to our incident analysis, during the last stage of their activity, the cybercriminals used just a few shell companies to deposit the stolen money.

But none of that mattered any more as both we and the police had collected enough material to arrest suspected group members, which happened early in June this year. No one on the Internet knows you are a cybercriminal? My personal experience of the Lurk investigation made me think that the members of this group were convinced they would never be caught.

They had grounds to be that presumptuous: they were very thorough in concealing the traces of their illegal activity, and generally tried to plan the details of their actions with care. However, like all people, they made mistakes.

These errors accumulated over the years and eventually made it possible to put a stop to their activity.
In other words, although it is easier to hide evidence on the Internet, some traces cannot be hidden, and eventually a professional team of investigators will find a way to read and understand them. Lurk is neither the first nor the last example to prove this.

The infamous banking Trojan SpyEye was used to steal money between 2009 and 2011.
Its alleged creator was arrested 2013, and convicted in 2014. The first attacks involving the banking Trojan Carberp began in 2010; the members of the group suspected of creating and distributing this Trojan were arrested in 2012 and convicted in 2014.

The list goes on. The history of these and other cybercriminal groups spans the time when everyone (and members of the groups in particular) believed that they were invulnerable and the police could do nothing.

The results have proved them wrong. Unfortunately, Lurk is not the last group of cybercriminals attacking companies for financial gain. We know about some other groups targeting organizations in Russia and abroad.

For these reasons, we recommend that all organizations do the following: If your organization was attacked by hackers, immediately call the police and involve experts in digital forensics.

The earlier you apply to the police, the more evidence the forensics will able to collect, and the more information the law enforcement officers will have to catch the criminals. Apply strict IT security policies on terminals from which financial transactions are made and for employees working with them. Teach all employees who have access to the corporate network the rules of safe online behavior. Compliance with these rules will not completely eliminate the risk of financial attacks but will make it harder for fraudsters and significantly increase the probability of their making a mistake while trying to overcome these difficulties.

And this will help law enforcement agencies and IT security experts in their work. P.S.: why does it take so long? Law enforcement agencies and IT security experts are often accused of inactivity, allowing hackers to remain at large and evade punishment despite the enormous damage caused to the victims. The story of Lurk proves the opposite.
In addition, it gives some idea of the amount of work that has to be done to obtain enough evidence to arrest and prosecute suspects. Unfortunately, the rules of the “game” are not the same for all participants: the Lurk group used a professional approach to organizing a cybercriminal enterprise, but, for obvious reasons, did not find it necessary to abide by the law.

As we work with law enforcement, we must respect the law.

This can be a long process, primarily because of the large number of “paper” procedures and restrictions that the law imposes on the types of information we as a commercial organization can work with. Our cooperation with law enforcement in investigating the activity of this group can be described as a multi-stage data exchange. We provided the intermediate results of our work to the police officers; they studied them to understand if the results of our investigation matched the results of their research.

Then we got back our data “enriched” with the information from the law enforcement agencies. Of course, it was not all the information they could find; but it was the part which, by law, we had the right to work with.

This process was repeated many times until we finally we got a complete picture of Lurk activity. However, that was not the end of the case. A large part of our work with law enforcement agencies was devoted to “translating” the information we could get from “technical” into “legal” language.

This ensured that the results of our investigation could be described in such a way that they were clear to the judge.

This is a complicated and laborious process, but it is the only way to bring to justice the perpetrators of cybercrimes.

Alleged Russian Hacker Seleznez Goes On Trial In US

A RUSSIAN CHAP is on trial for his alleged involvement in $170m worth of fraudulent credit card purchases. Roman Seleznev is the son of a Russian lawmaker, which might make things awkward.

The US wants him, and is starting a jury trial this week. Seleznev faces a 40-count indictment for allegedly masterminding a multi-company hacking organisation that took millions of dollars from many victims. He was indicted in 2014 along with Sergei Nicolaevich Tšurikov and others.

Tšurikov has already been sentenced. "A leader of one of the most sophisticated cyber crime rings in the world has been brought to justice and sentenced," said US attorney Sally Quillian Yates in an FBI report at the time. "In just one day in 2008, an American credit card processor was hacked in perhaps one of the most sophisticated and organised computer fraud attacks ever conducted. "Almost exactly one year later, the leaders of this attack were charged.

This prosecution was successful because of the efforts of the victim, and unprecedented cooperation from various law enforcement agencies worldwide." The credit card processor was RBS WorldPay, and the mayhem lasted for a month.

Financial outfits usually lose that kind of money only when it comes to dishing out worker bonuses. Seleznev was injured in an explosion at a café and has undergone some years of surgery and recovery. We bet he felt really positive about the future when he was given the all clear from the doctors.
Still, at least he will be well used to institutional food. He now faces a federal jury trial, to which 11 further counts have been added since 2014's proceedings. Associated Press reported that the trial is expected to last for two weeks, but Seleznev is low on English and will need an interpreter, so we can probably add a day or two to that estimate. Others from the same gang have already felt the pinch of the law on their collars. µ

Alleged Russian Hacker Seleznev Goes On Trial In US

A RUSSIAN CHAP is on trial for his alleged involvement in $170m worth of fraudulent credit card purchases. Roman Seleznev is the son of a Russian lawmaker, which might make things awkward.

The US wants him, and is starting a jury trial this week. Seleznev faces a 40-count indictment for allegedly masterminding a multi-company hacking organisation that took millions of dollars from many victims. He was indicted in 2014 along with Sergei Nicolaevich Tšurikov and others.

Tšurikov has already been sentenced. "A leader of one of the most sophisticated cyber crime rings in the world has been brought to justice and sentenced," said US attorney Sally Quillian Yates in an FBI report at the time. "In just one day in 2008, an American credit card processor was hacked in perhaps one of the most sophisticated and organised computer fraud attacks ever conducted. "Almost exactly one year later, the leaders of this attack were charged.

This prosecution was successful because of the efforts of the victim, and unprecedented cooperation from various law enforcement agencies worldwide." The credit card processor was RBS WorldPay, and the mayhem lasted for a month.

Financial outfits usually lose that kind of money only when it comes to dishing out worker bonuses. Seleznev was injured in an explosion at a café and has undergone some years of surgery and recovery. We bet he felt really positive about the future when he was given the all clear from the doctors.
Still, at least he will be well used to institutional food. He now faces a federal jury trial, to which 11 further counts have been added since 2014's proceedings. Associated Press reported that the trial is expected to last for two weeks, but Seleznev is low on English and will need an interpreter, so we can probably add a day or two to that estimate. Others from the same gang have already felt the pinch of the law on their collars. µ

Flaws in Symantec products expose millions of computers to hacking

A Google security researcher has found high severity vulnerabilities in enterprise and consumer products from antivirus vendor Symantec that could be easily be exploited by hackers to take control of computers. Symantec released patches for the affected products, but while some products were updated automatically, some affected enterprise products could require manual intervention. The flaws were found by Tavis Ormandy, a researcher with Google's Project Zero team who has found similar vulnerabilities in antivirus products from other vendors.

They highlight the poor state of software security in the antivirus world, something that has been noted by researchers. Most of the new flaws found by Ormandy are in the Decomposer component of the Symantec antivirus engine.

This component handles the parsing of various file formats, including archive files like RAR and ZIP. Furthermore, the Decomposer runs under the system user, the most privileged account on Windows systems. Symantec didn't immediately respond to a request for comments on the vulnerabilties. Security researchers have criticized antivirus vendors many times for performing risky operations like file parsing with unnecessarily elevated privileges. Historically, such operations have been a source of many arbitrary code execution vulnerabilities in all sorts of applications. Ormandy found vulnerabilities in the Symantec code used to handle ZIP, RAR, LZH, LHA, CAB, MIME, TNEF, and PPT files. Most of these flaws can lead to remote code execution and are wormable, meaning they can be used to create computer worms. "Because Symantec uses a filter driver to intercept all system I/O [input/output operations], just emailing a file to a victim or sending them a link to an exploit is enough to trigger it -- the victim does not need to open the file or interact with it in anyway," Ormandy said in a blog post. Even more surprising is the fact that Symantec appears to have used code from open source libraries, but failed to import patches released by those projects over the years. For example, Ormandy determined that Symantec products were using version 4.1.4 of an open-source unrar package that was released in January 2012.

The most current version of that code is 5.3.11.

A similar situation was also observed for another library called libmspack. "Dozens of public vulnerabilities in these libraries affected Symantec, some with public exploits," Ormandy said. "We sent Symantec some examples, and they verified they had fallen behind on releases." The failure to keep track of vulnerabilities patched in the third-party code used by software vendors and developers in their own projects is a widespread problem. However, there's a natural expectation that security vendors would not make that mistake.

After all, they often preach secure software development and vulnerability management to others. Unfortunately, "when looking at how even a behemoth of a security product vendor like Symantec is bundling ancient code in their products, clearly hasn't subjected this code to security reviews and testing, and to top it off runs this old, unsafe code with SYSTEM/root privileges, it is clear that security vendors don't hold themselves to very high standards," Carsten Eiram, the chief research officer of vulnerability intelligence firm Risk Based Security, said by email. According to RBS' data, 222 vulnerabilities have been reported this year in security products, representing 3.4 percent of all vulnerabilities seen in 2016 so far. "It may not sound like much, but it's actually quite significant," Eiram said. Symantec has published a security advisory that lists the affected products and contains instructions on how to update them.

All Norton products -- the consumer line -- should have been updated automatically.

Cabcharge trip logs exposed by security-free database probe

Taxi payment company knows where you live ... and so can anyone who runs Shodan Researchers from Risk Based Security have Shodanned up a Cabcharge database that was running without security. The taxi fee monopoly has lurched into damage control, telling the Sydney Morning Herald it's contacting the 3,400 Cabcharge Fastcard holders whose details were left lying around in public. RBS's post says the database exposed sensitive information of both customers and drivers. While only the last four digits of credit cards were held, the customer's name, pickup, and dropoff locations and times were all in the database. Driver information included name, ABN, taxi ID, terminal ID, and trip logs. The company sent a statement over to the SMH to the effect that the “old” information didn't put customer payment information at risk, and claiming that the information hadn't been misused. Clearly, Cabcharge doesn't understand the threat of identity theft any better than it understands why Uber is eating its lunch. ® Sponsored: Rise of the machines

Top 10 IT news stories of the week: Barclays wants to...

One story towered above all others this week - but you'll have to scroll down to the bottom of the page for confirmation of what it was. Elsewhere, however, the security of the so-called "Internet of Things" received much attention - the problem is that it doesn't appear to have any. At the same time, the user name-password paradigm has come under its regular weekly attack, with Salesforce.com users being specifically targeted by malware and the credentials of five million Gmail accounts being spilled on the usual websites in Eastern Europe. However, Barclays (with the help of some clever chaps from Hitachi) might have a potential solution to that problem. Whether you'd want to use, though, is another matter. 10. IoT: Things could get nasty and Security warning over the Internet of Things Just a day after Computing published an excellent feature (if we says so ourselves...) focusing on the security risks of the Internet of Things, Beecham Research came out with a report which said pretty much the same things. The trouble with the whole concept, is that there are no security standards governing the sector, which in any case could cover anything from a "smart light bulb" to internet-connected thermostats or fridges. Not only would security add to the cost and complexity, many of the developers are in such a rush to get to market (or to get acquired by Google) that security comes a long way down their list of priorities. The message, it seems, is to let other people cut themselves at the "bleeding edge" until all the security risks have been overcome. That's if manufacturers can ever find a compelling reason to connect your fridge to the internet, that is. 9. NHS Spine ‘successfully' rebuilt, says HSCIC  Rejoice! The NHS spine has been successfully rebuilt, according to the Health and Social Care Information Centre (HSCIC). This is excellent news the Spine is about the only part of the ill-fated NHS National Programme for IT (NPfIT) that has emerged from one of the biggest ever disasters in public sector IT. The spine stores patient information and enables electronic messaging across the NHS. 8. RBS among the Salesforce users targeted by 'Dyre' malware Two days after publishing this story, we took a peculiar call from someone representing Salesforce. They weren't happy with the headline. Or the story. Or anything, it seemed. We asked them to put their complaints into an email so that we might have a chance of comprehending exactly what their complaint was and acting on any legitimate complaints. We're still waiting at the time of writing. As users of practically every other internet service has found out in recent years, the old user name/password security combination has become somewhat frayed - especially when the user name is invariably someone's password, making it trivially easy to conduct brute-force attacks in order to break into systems secured in this way. What is disturbing is how such attacks have graduated from Facebook, Twitter and Yahoo's Ymail to corporate services such as Salesforce.com. More disturbing still, perhaps, was the way in which the "Dyre" malware seemed to target Salesforce users in financial services. Salesforce is adamant that it warned users in a timely fashion about the risks posed by this new form of Trojan horse attack, but it is almost certain that it isn't just Salesforce that is being attacked in this way, but all internet-connected services. 7. Backbytes: A year too late, MPs realise that the UK's smart meters are a waste of money Sometimes, a story is just so absurd that a straight news report will not do. The impending disaster of the UK's smart meter roll-out is one such story. The Public Accounts Committee, which has become the Metropolitan Police of government waste (in that it arrives on the scene way too late and just sucks its teeth as it surveys the scene of devastation) has turned its attention to smart meters and made all the criticisms that every one was making last year. However, it's all a bit late as all the multi-billion pound contracts have now all been signed, and electricity and gas bill payers are now stitched up like kippers to pay for a system that is excessively complex, more expensive than it ought to be, and which will oblige householders to buy mysteriously expensive devices in order to read their own meters remotely. 6. 'Staff would just open up Dropbox accounts all over the place' admits US government services CIO  Dropbox is a fantastic utility in an age when people are working from work PCs, home PCs, smartphones, tablets, laptops in coffee shops, etc. It's also fantastically insecure as far as many organisations are concerned: with just one quick drag-and-drop, corporate data can be outside the firewell before the CIO can say "have you read the corporate security policy?" However, getting people to understand the risks of such behaviour - the same people who habitually double-click on dodgy attachments - is invariably a challenge too far. Indeed, the CIO of the US government's General Services Administration pretty much admitted as much during the final day of the BoxWorks conference. "We'd provide these super-secure, highly regulated tools, but people would go around them. We had a perfectly good email platform, but it was a client-based thing - you had to work at a PC - so people would open up Dropbox accounts all over the place and use all kinds of different sites and tools." His solution was to provide a similar service under the umbrella of the company so that they can be properly managed - provided by Box, of course... 5. Backbytes: Use a VPN? You're probably a filthy pirate, BBC tells Australian government It's often said - particularly of lesser sites, such as the Daily Mail, Telegraph Online and the Guardian's Comment is Free - that you should never read the comments if you want to remain sane. However, on www.computing.co.uk, the comments are invariably as enlightening as the articles. The BBC, according to readers, is living in the past if it thinks it can hold back the tide and Computing's wise commenters wondered why it didn't instead just sell advertising on all the various programmes that people around the world want to watch on iPlayer. Good question. 4. Google Gmail users told to change passwords after five million accounts were compromised Apparently, passwords alone are inherently insecure - who knew? Well, every week, it seems, there's a new release of user names and passwords affecting all manner of internet services. The latest is Google's Gmail email service, although some questions were asked not just how the accounts were hacked, but also the age of the accounts. However, pretty much everyone has a Gmail account (many people more than one) so who wouldn't be concerned that there are five million cracked user names with passwords rocking around some dodgy websites in Russia? Of course, every crisis is also an opportunity and such a story presented an excellent opportunity for Google to persuade you to give it your mobile phone number, which it can add it to your file in its Great Big Database of Personal Information, all in the name of two-factor authentication. 3. IBM acquisition of Fiberlink fuelled its own BYOD strategy Intriguingly, when IBM acquired Fiberlink in December 2013, the computer services giant didn't actually have a formal bring your own device (BYOD) strategy. A month later, it did. According to Jim Sheward, the CEO of Fiberlink. In a Computing web seminar, he said: "They acquired us in December and we rolled out [the platform] in January, which was very fast. Currently there are 100,000 users and at one point there were 5,000 users rolling into the system an hour. It typically takes two to three minutes for a user to enrol their device." One of the main reasons why IBM had been slow to formally adopt BYOD was security, he added. With IBM doing so much business in sensitive sectors such as financial services, keeping data secure is key to its business, said Sheward. To watch the full web seminar click here. 2. Barclays unveils blood-reading authentication technology for corporate banking clients Payment fraud has become a particularly thorny problem for many businesses, especially small and medium-sized businesses (SMBs). A little bit of phishing at ACME Construction and before they're even aware of what's happening, an attacker is siphoning off their overdraft to an account in Russia or Turkmenistan, beyond the reach of conventional law enforcement. That's why Barclays has launched its biometric authentication fingerprint reader that will be rolled out to corporate clients in 2015. According to Ashok Vaswani, CEO of Barclays' personal and corporate banking, the device - based on technology developed by the clever chaps at Hitachi - "doesn't capture a fingerprint, it actually captures the photographic view of the blood in the veins of your finger". This, he added, is even more secure than fingerprinting. Vein authentication technology works by scanning the finger with near-infrared (NIR) light. Barclays says it has tested the technology stringently, claiming that it would take a fraudster a million attempts to even have a chance of stealing or redirecting funds. Although that may sound complicated, it would appear to be a good deal simpler to follow than the alternative security advice, at least as far as many SMBs: to only do payment runs on a version of Linux booted and running solely from a USB. Go on, you'll never guess what the most popular story this week was - by a long way. Oh, you have... 1. Apple reveals iPhone 6 and iPhone 6 Plus Yes, Apple surprised the whole world, once again, by unveiling its new smartphones in September, just like last year and the year before. As General Melchett once said: "Doing precisely what we've done eighteen times before is exactly the last thing they'll expect us to do this time." Stephen Fry was at the launch, name-dropping other celebs on his Twitter account, so the above quote is perfectly apt. Like last year, Apple released not one, but two models, with the iPhone 6+, a 5.5-inch screen "phablet" with a battery to match, grabbing the headlines - not least for its hefty asking price. If you want one it'll cost you between £619 for the piffling 16GB device and £789 for the 128GB device. Perhaps more interesting than the devices, though, was the announcement of Apple Pay. The payments industry has been waiting some time for near-field communications (NFC) technology to take off and, with Apple's backing, it might well do so in 2015, when Apple Pay hits the UK. The idea is that smartphone users will load a secure "wallet" with credit and debit card details, as well as tickets and other financial information, and use their phones to pay for things or for keeping concert and theatre tickets. Naturally, Apple intends to take its cut every time you buy your daily super-skinny frappalattacino, although with Apple's iOS continuing to lose worldwide market share to Android it may well be Google that benefits in the long term. However, iPhones may soon have competition for recharging plug sockets at work, with Apple also unveiling an iWatch - reportedly three years in the making, which is also about how long an Apple iWatch has been rumoured. Yes, a decade after most people threw away their watches because they could keep the time perfectly well with their mobile phones, Apple is keen to reintroduce the watch, except it will have to be recharged once a day and will be dependent on an iPhone for you to benefit from all its functions, which reportedly include accurate time keeping. That's if the appearance from U2 didn't put off Apple's otherwise right-on fans.

Dyre malware branches out from banking, adds corporate espionage

Alerts warn that Dyre is collecting credentials to corporate cloud services.

RBS among the Salesforce users targeted by ‘Dyre’ malware

Users of Salesforce are being targeted by malware dubbed Dyreza or Dyre by anti-virus software specialists. The malware is sophisticated enough to be able to bypass the two-factor authentication deployed by many users to guard against such attacks. The malware first appeared in June, targeting users at major banks, including the Royal Bank of Scotland group (RBS, NatWest and Ulster Bank), as well as US banks Citibank and Bank of America. The nature of the attacks was described as "weird" by Danish security research company CSIS, which was among the first groups to identify the Trojan. Its chief technology officer Jan Kaastrup told SC Magazine that the gang behind the attack was likely commissioned by a customer to harvest Salesforce credentials - or more information about the banks' customers. "The way Salesforce is being targeted is actually very weird. Normally it has only been banks. They have made up a phishing site for Salesforce. They are going direct for Salesforce customers. Now why would they do that? "In theory, all user credentials have a value on the black market. This indicates that Dyreza is growing, and probably they have a customer who has said ‘we would really like Salesforce' and they put it in," said Kaastrup. Although the Trojan first appeared in June, Salesforce only notified customers on Friday, with the following advisory: "On September 3, 2014, one of our security partners identified that the Dyre malware (also known as Dyreza), which typically targets customers of large, well-known financial institutions, may now also target some Salesforce users." Salesforce was quick to assert that none of its customers had been affected. Dyre was first identified in mid-June by CSIS and PhishMe. PhishMe called it "a new strain of malware unseen in the industry until now". Kaastrup told SC Magazine the latest version of the Trojan indicates that the gang responsible for Dyre is trying to expand its reach. "It has evolved and we have seen multiple malware campaigns running," Kaastrup said. "It's still being distributed using email techniques but the back-end infrastructure has expanded." In the latest campaign, the malware sends users to a rip-off of the Salesforce site. It uses key-stroke logging to capture user names and passwords, and can circumvent two-factor authentication by simultaneously logging in when the user does and intercepting their one-time password (OTP).

NatWest lacks basic phishing protection, says security firm Atbash

London-based security firm Atbash has identified a flaw in NatWest’s online banking system which could be exposing unwitting customers to cyber threats. The flaw – in the bank’s current email security system – makes it less likely that phishing emails will be identified and filtered out. Graeme Batsman, director of IT and email security firm Atbash, said: “I was handed a sample of an email from NatWest which slipped past the security system.”  The sample was a phishing email that appeared to come from NatWest, yet the sender domain showed that it was sent from New Zealand.  It informed the recipient that access to their account had been blocked “due to possible errors detected”. The message directed the recipient to click on a link to “restore online access” and review online accounts. The link actually redirected the user to a phishing website. “After inspecting the problem and testing the vulnerability, I identified that the problem was a missing SPF record,” Batsman said. SPF records are used as part of the Sender Policy Framework, an anti-spam approach in which the internet domain of an email sender can be authenticated for that sender. The measure is directed against spam mailers, who routinely disguise the origin of their email, a practice known as email spoofing. SPF and other anti-spoofing initiatives, such as DomainKeys, work by making it easier for a mail server to determine when a message came from a domain other than the one claimed. “To put it simply, NatWest’s email servers are based within the UK, so if someone was sending an email from New Zealand pretending to be NatWest, it should get blocked,” explained Batsman. When an email is sent using SPF, there is a simple check done in the background to see where the email should come from (in this case UK) and where is actually comes from (in this case New Zealand). “If the two do not tie up, then email servers will determine the email to be fake and it will be blocked,” he said. Batsman added that SPF is an open source method of identifying and capturing dangerous and compromised emails that costs nothing to implement and takes just 30 minutes to set up. By integrating an SPF record on the system, NatWest would have increased the chance of email spam filters detecting that the email is a fake, offering better protection to customers, he said. SPF records have been set up for the domain NatWest.com, but the critical domain nwolb.com which is used for online banking login does not, said Batsman. “This leads to cyber criminals being particularly attracted to the nwolb.com domain, which is a major concern to NatWest online banking customers,” he said. Batsman said other major banks such as Metro, Barclays, Santander and Lloyds already have SPF records set up for their domains which relate to online banking login paths. Computer Weekly contacted NatWest to find out why SPF has not been implemented across all its domains, but received only a generic response. A NatWest spokesperson said: “We take our customers’ security very seriously and we’re always looking at additional ways to protect them.   “We will never ask customers to disclose security details or personal information. We urge our customers not to click on any links and attachments within suspicious emails and to report a suspicious email to us. “Customers can contact us by emailing  phishing@natwest.com or phishing@rbs.co.uk.” Email Alerts Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox. By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy Read More Related content from ComputerWeekly.com RELATED CONTENT FROM THE TECHTARGET NETWORK

FCA to probe banking IT

UK financial services regulators are investigating IT at banks following a number of high-profile outages that have left consumers unable to access their money. The Financial Conduct Authority (FCA), Prudential Regulation Authority (PRA) and Bank of England will review how finance firms manage their exposure to IT risks. It will also look at how engaged boards at banks are with the issue of IT resilience and if they have the expertise needed to challenge the IT decisions taken by the executive. Clive Adamson, director of supervision at the FCA, said IT is critical to customers for accessing and managing funds  “We want to make sure that the banks have resilient IT systems in place that are able to cope with consumer demand, so customers aren’t left financially stranded or disadvantaged," said Adamson. The review, which was announced in the FCA’s business plan, will report back in early 2015. This follows up on work undertaken in 2012, when the chairmen of the nine largest banks and building societies were contacted by the regulator, which requested information on what was being done to ensure the overall resilience of critical infrastructure and banking processes. The 2014 review will assess what progress has been made so far by the banks and whether more needs to be done. Earlier this year a PRA director said UK bank IT systems are not robust. The BBC's Sam Woods said: "I feel we are a very long away from being able to sit here with confidence and say that the UK banks' IT systems are robust." In 2012, when RBS had major IT problems, the regulators contacted other banks and they had to provide statements and evidence to show how we would not suffer a similar fate. The problems at the Royal Bank of Scotland (RBS) meant customers were unable to access their accounts for days. The glitch in the CA-7 batch process scheduler ended with 12 million customer accounts being frozen. Customers were unable to access funds for a week or more as RBS, NatWest and the Ulster Bank manually updated all the account balances.  Then, in December 2013, on the busiest shopping day of the year, problems stopped customers making online and card payments. RBS has since admitted that its IT systems needs to be overhauled after decades of under-investment. Email Alerts Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox. By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy Read More Related content from ComputerWeekly.com RELATED CONTENT FROM THE TECHTARGET NETWORK