Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
The proliferation of data analytics in the world of internal audit has been a boon to some companies and a disappointment to others. Companies using analytics effectively are auditing with fewer resources and getting better coverage; reducing fraud, waste and abuse by the millions; and providing executives the ability to make smarter, data-driven business decisions.
But far too often, audit functions are launching data analytics that sputter, flame out and waste precious resources, and most immature data analytics programs are stumbling over the same few hurdles. Here are the five main hurdles and how to clear them.
Get Executive Buy-In From the Start
Data analytics is a disruptive technology, particularly for internal audit functions, and switching to data-driven decision making can be jarring for executives accustomed to basing decisions on intuition and business acumen alone. Preventing new data analytics initiatives from being stymied early on requires investment, agreement and evangelists at the top of the organization.
To win the hearts and minds of your executives, cherry pick a few analytics projects that promise a high return on investment through cost recovery or an increase in internal audit efficiencies. Audits of financial processes like T&E reporting or accounts payable often yield big returns from easy-to-access data. Demonstrate the value of a modest investment in analytics, and get your executives on board.
Plan for the Data Overload
With the quantities of data collected in most corporate environments today, sifting through all of them can be a headache. But byfront-loading your time—spending more time planning, identifying requirements and cleansing data—you can drastically improve the likelihood of a successful project and reduce the time spent on downstream analysis and review.
A key objective during the planning phase should be to identify all possible data streams that could impact the result of your planned analytic. Document those data streams, where they are stored, who the owners are, what related data might be relevant and what permissions will be needed to access them. By investing in an accurate inventory of the relevant data upfront, you can launch the project with confidence and avoid unexpected roadblocks or delays during the project.
Build a Data Analytics Team that Works
A recent Sunera survey of Fortune 50 to Fortune 2000 companies highlighted two key success factors for companies building internal analytics teams. First, companies with mature internal audit data analytics programs typically have resources dedicated specifically to data analytics. Second, program maturity correlates with the size of the data analytics team in relation to the overall internal audit function. A mature program often requires an investment of 10-15 percent of the overall internal audit budget. But with salaries skyrocketing and a high demand, it can be hard to snag the right professionals for your data analytics teams.
Using a strategic approach, you can build a skills-based team that fits the needs of your organization. Start by targeting individuals who have skills across a few key areas like business analysis, project management and data analysis. From there, look to add roles like IT specialist and data hygienist. These resources ensure you have the infrastructure support to scale your analytics programs. And finally, when you are ready for your data analytics program to really take off, consider adding individuals with graphic design skills for visual analytics and predictive analytics capabilities.
Fight Back Against Dirty Data
More than 25 percent of critical data in Fortune 1000 companies are “dirty,” meaning they are inaccurate, incomplete or duplicated. Dirty data can plague your data analytics initiative at any stage, derailing your budget, generating misleading results and potentially causing project failure.
The best (and only) way to fix the dirty data problem is through better institutional data governance. Proper data governance means clearly communicated objectives, processes and metrics; data quality controls and issue resolution processes; clear and documented data conventions; well-understood roles and responsibilities for analytics resources; and data governance training. Developing a robust system of data governance is worth the investment to ensure that quality data are available to your team.
Make Data Accessible With Visual Analytics
What good is data analytics if executives do not understand the results? That is the central question driving the spread of visual analytics platforms through audit functions nationwide. Visual analytics allows for meaningful exploration through analytic results, giving executives the ability to discover cost-saving or efficiency-improving trends, opportunities and relationships in the data.
Visual analytics gives executives and auditors a powerful tool to ensure that data deliver strategic and significant value to the organization. As you undertake each data analytics project, consider how the output can be visualized to communicate data in the language of your executives, speaking directly to the business challenge at the heart of the analytics initiative. With proper planning and a modest investment in tools and expertise, your organization can provide a far greater level of insight to executives making critical business decisions.
Cliff Stephens is a director in Sunera’s Data Analytics practice where he develops analytics to improve clients’ internal audit functions and provide value to executives. Before joining Sunera, Cliff created and led the Internal Audit Data Analytics team at Home Depot. To read Cliff’s full white paper on this topic, please visit https://sunera.com/data-analytics-pitfalls/.
We recently discovered 22 Android apps that belong to a new Trojan family we’re calling “Xbot”. This Trojan, which is still under development and regularly updated, is already capable of multiple malicious behaviors. It tries to steal victims’ banking credentials and credit card information via phishing pages crafted to mimic Google Play’s payment interface as well as the login pages of 7 different banks’ apps. It can also remotely lock infected Android devices, encrypt the user’s files in external storage (e.g., SD card), and then ask for a U.S. $100 PayPal cash card as ransom. In addition, Xbot will steal all SMS messages and contact information, intercept certain SMS messages, and parse SMS messages for mTANs (Mobile Transaction Authentication Number) from banks.
So far the malware doesn’t appear to be widespread, and some markers in its code and faked app interfaces indicate, at least for now, it mainly appears to target Android users in Russia and Australia. Of note, of the seven bank apps it is seen to imitate, six of them belong to some of the most popular banks in Australia. However, Xbot was implemented in a flexible architecture that could be easily extended to target more Android apps. Given we also observed the author making regular updates and improvements, this malware could soon threaten Android users around the world.
Xbot primarily uses is a popular attack technique called “activity hijacking” by abusing some features in Android. The apps Xbot is mimicking are not themselves being exploited. Starting with Android 5.0, Google adopted a protection mechanism to mitigate this attack but other attack approaches used by Xbot are still affecting all versions of Android.
Xbot’s Evolution and Spreading
We believe Xbot is a successor to the Android Trojan Aulrin that was first discovered in 2014. Xbot and Aulrin have very similar code structures and behaviors, and some resource files in Aulrin are also in Xbot samples. The main difference between them is that Xbot implements its behaviors using JavaScript through Mozilla’s Rhino framework, while Aulrin used Lua and .NET framework. The earliest sample of Xbot we found was compiled in May 2015 and while comparing Xbot to Aulrin, it seemed to us the author re-wrote Aulrin using a different language and framework. The author has also progressively made Xbot more complex; the most recent versions use Dexguard, a legitimate tool intended to protect Android apps by making them difficult to reverse engineer or be tampered with.
We are not clear how Xbot spreads in the wild. However, using VirusTotal we found samples that were hosted on the below URLs over the past several months:
hxxp://market155[.]ru/Install.apk
hxxp://illuminatework[.]ru/Install.apk
hxxp://yetiathome15[.]ru/Install.apk
hxxp://leeroywork3[.]co/install.apk
hxxp://morning3[.]ru/install.apk
There are several things that imply the developer of Xbot could be of Russian origin. The earlier versions of Xbot displayed a fake notification in Russian for Google Play phishing, there are Russian comments in its JavaScript code, and the domains we’ve uncovered were registered via a Russian registrar. Xbot will also intercept SMS messages from a specific bank in Russia and parse them for bank account information, which it will exfiltrate if found. While later versions use English instead of Russian for the notification, the language was not changed elsewhere.
Figure 1. Xbot’s JavaScript code commented in Russian.
Phishing for Credit Cards and Bank Accounts
After being installed on an Android device, Xbot will start communicating with its C2 server. When certain commands are received it will launch phishing attacks at users of Google Play and certain Australian bank apps. We observed three different phishing approaches and one use of activity hijacking. The four approaches with their commands are shown in Figure 2.
Figure 2. Xbot’s phishing commands.
If the C2 command is “cc_notify”, Xbot will display a fake system notification to the victim with the Google Play logo and the text “Add payment method” in either Russian or English (Figure 3). This imitates an actual popup the official Google Play app will show a user that has registered for the service but not yet provided a credit card. However, Xbot will display this whenever it receives the command, regardless of whether the Google Play app already has a credit card tied to it.
Figure 3. Code to display the fake notification in Russian or English.
If a victim clicks the fake notification, Xbot connects to its C2 server to download a webpage and display it with WebView. The page looks like Google Play’s actual interface for credit card information (Figure 4). Its user interaction procedures are also almost exactly the same as the legitimate version. All information input into this page will be uploaded to its C2 server (Figure 5). The information it asks for includes:
credit card number
expiration date
CVV number
card holder’s name
card holder’s billing address
card holder’s phone number
VBV (Verified by Visa) or McSec (MasterCard SecureCode) number
Figure 4. Fake Google Play payment pages.
Figure 5. JavaScript code for uploading credit card information.
If the C2 command is “cc_dialog”, the fake notification step will be skipped and the fake Google Play webpage will be directly displayed to victims.
If the C2 command is “enable_inject”, Xbot will begin to monitor currently running apps via the getRunningTasks() API in Android. If the app running in the foreground is Google Play or one of several Australian bank apps (which is specified by the C2 server via the “add_inject” command), and immediately popup another interface on the top of running app (Figure 6). This is a classic attack technique called “activity hijacking”. Note that Android 5.0 implemented a security enhancement to keep apps from getting running app information through the getRunningTasks() API. So this attack won’t be effective on devices running Android 5.0 or later.
Figure 6. Code for hijacking Google Play and banking apps.
In the activity hijacking attack scenario, the faked app interfaces are also webpages downloaded from a C2 and displayed by WebView. So far we’ve found 7 different faked interfaces. We identified 6 of them – they’re imitating apps for some of the most popular banks in Australia. The interfaces are very similar to these banks’ official apps’ login interfaces. If a victim fills out the form, the bank account number, password, and security tokens will be sent to C2 server (Figure 8).
It’s worth noting that, since Xbot’s C2 server can remotely decide which faked app webpage to display, it would be easy to expand this attack to more apps without even having to update the code.
Figure 7. Example of an Xbot banking app phishing interface.
Figure 8. JavaScript code for uploading bank login information.
Locking, Encrypting, and Ransoming
After being installed, Xbot asks the user to authorize it as a device administrator. Then, if the C2 server sends the command “killon”, it will change the phone to silent mode, reset the password to “1811blabla”, then toggle the device screen to activate the new password.
Figure 9. Code to change the device password.
If the C2 command is “enable_locker”, Xbot will display a ransom webpage claiming to be Cryptolocker, still using WebView, from either “hxxp://23[.]227.163.110/locker.php” or another address specified by the C2 server. When we analyzing the sample, the webpage came from its C2 server, as seen in Figure 10:
Figure 10. Xbot ransom page.
Xbot will also start the onBackPressed(), onDestroy() and onPause() callback methods to prevent the user from exiting. Xbot will also encrypt the victim’s files in external storage (Figure 11). Currently, the encryption algorithm is pretty simple: just XOR each byte in all files by the fixed integer number 50.
Figure 11. Code to encrypt files in external storage.
According to the ransom webpage, the victim has to purchase a U.S. $100 PayPal My Cash Card from http://www.paypal-cash[.]com, and input the card number within 5 days. The webpage also says it’s impossible to decrypt the files by yourself, which is obviously not true for existing samples.
It should be noted that since the ransom page comes from a remote server, the attacker can update it to change the payment method and/or the amount of money at any time.
Information Stealing
Xbot has some additional capabilities. It will collect all contacts’ names and phone numbers and upload them to its C2 server, as well as all new SMS messages. In some samples, Xbot will also intercept and parse specific SMS messages. It parses all SMS messages sent by a specific premium rate SMS short number in an attempt to collect the victim’s account and confirmation numbers from a bank in Russia, and then uploads the information to its C2 server.
Figure 12. Code to steal SMS messages from a bank in Russia.
Conclusion
While Android users running version 5.0 or later are so far protected from some of Xbot’s malicious behaviors, all users are vulnerable to at least some of its capabilities. As the author appears to be putting considerable time and effort into making this Trojan more complex and harder to detect, it’s likely that its ability to infect users and remain hidden will only grow, and that the attacker will expand its target base to other regions around the world. We’ll continue to watch and report on this threat as the attacker introduces new versions. We also want to re-emphasize that the banking apps imitated by Xbot are not themselves being exploited.
Customers of Palo Alto Networks are protected with our WildFire, URL filtering, and IPS services. An AutoFocus tag has also been created to identify this family and its variants. Customers can also refer to IPS signature (13997) for details about Xbot C2 traffic information.
Acknowledgments
We greatly appreciate the help from Rongbo Shao, Yi Ren, Bowen Jiao, Michael Scott, Jen Miller-Osborn, Chad Berndtson, Chris Clark, and Ryan Olson from Palo Alto Networks in working on the analysis and coverage of Xbot family.
As the speed and volume of threats today shows no abatement, there is much discussion that the only way to keep pace is through automation and self-learning. Although the answer sounds simple, the tough part is figuring out how we achieve this.
Most attackers look at the broad dossier of attack techniques today and, like any playbook, take some of what has been done before and try to sprinkle in a hint of their personalization to make it unique. In today’s world this is no longer about simply creating a bad binary object and emailing it around with a smart, socially engineered subject line.
Take, as an example, Cryptowall v3.0. Ransomware is a simple concept; but, to succeed at that, attackers have had to leverage multiple campaigns with over 4,000 iterations of the attack binary using multiple exploits, including exploit tools such as the Angler exploit kit, compromising large numbers of public WordPress sites and building a complex array of over 800 command and control sites, just to name some of the aspects of the overall attack. Once compromised, payments could hop through up to 80 bitcoin wallets before reaching their final destination. Why is all of this so important? The more we can map out attackers, the better we can find and block future iterations of their attacks.
In the physical world, criminals typically look just like every other person; and, today, with over 7 billion people on the planet, finding them can seem like an impossible task. Over the years, law enforcement experts have built techniques to uniquely identify criminal, such as photofits and, now, DNA. Such techniques not only uniquely identify criminals but also help link them to the crimes they have committed.
The same concepts apply in cyber, but today under a less mature guise. We rely on tools to identify unique characteristics much like looking for eye or hair color. The challenge being, when you look at any such characteristics in isolation, such as looking for a bad email characteristics or a certain hair color, the level of false alerts can be unreal. The once unique binary is like a face with makeup, so many different permutations are quickly achieved. As such we need to look at all the attributes and try to see the whole face of the attack – better still, the DNA of the attack. If we can do this, we can start to see existing attacks more accurately, allowing us to automate. The more we can automate the quicker we can detect. And, if we can gather the whole DNA, we can start to identify new attacks as they happen by their genetic links.
Source: Wikipedia
Going back to CryptoWall, when v4 came out, it had some enhancements. Of course the email messages delivering it changed, as did the binary, requiring many traditional approaches to need an update. However, most of the underlying infrastructure stayed the same. In the sci-fi film Jurassic Park, they filled in the DNA gaps to rebuild dinosaurs. Here we have the ability to make fiction into fact by mapping out the whole attack lifecycle (the DNA of the attack), which includes all of the indicators aligned to it (rather than just the indicators we see as compromising the victim), we can better detect and block not just the current attack but all future instances, forcing the attack to effectively create a whole new dinosaur. Effectively, we use the broader attack architecture DNA to fill in the gaps created by the dynamic components, such as the changing binary and delivery wrapping.
Why don’t we all do this today? DNA analysis happens in one lab; most security solutions simply look for an element of the attack. Much like the criminal photofit, they look at maybe the eyes or the nose or the hair — perhaps all three. But they typically don’t see the whole face, and they certainly don’t gather the entire DNA. It’s like having a bunch of labs looking at different atoms trying to join together the strands, which was not historically their goal. Their goal was to block the attack, not understand what makes the attack function in the broader sense.
To identify the DNA, we need to be able to join the right elements together. This means analyzing and correlating these characteristics; looking at the known and mapping against the unknown, we need to pull this into a single point of analysis so we can see the big picture. To achieve this at a vendor level, you need solutions that were nativity designed to talk the same language; otherwise they are not comparing like for like.
No vendor spans all the security requirements today. This is why protocols such as STIX, TAXII and Cybox have been developed to allow multiple vendors to collaborate in a virtual common lab, such as the Cyber Threat Alliance, acting as the interpreter to automatically exchange big data through a common translation structure to support better mapping of the attack DNA. Through this approach, the Cyber Threat Alliance worked collaboratively to uncover CryptoWall 3.
There are many ways of trying to keep pace with today’s threats; each has its own advantages and disadvantages. The challenge, however, is that most are still looking to improve the identification of a characteristic. To better spot the criminal among the billions of faces, we need to leverage every aspect we can to make them stand out as unique and at the same time identify commonality. What’s more important is that, with big data tools and common frames of reference, we can then look for these attributes to find their future faces. At the end of the day, you can easily change individual aspects of your appearance, but it’s extremely hard to change your DNA.
Organizations battle daily with social engineering-based cyberattacks and unfortunately often find themselves on the losing side. What can be done? To determine this, we need to step back from our technological tools and start with the psychological basis of why social engineering works and why it is a tactic of choice for cyber attackers. Armed with that knowledge, organizations can begin to mount a more effective defense.
When people think of social engineering they tend to think of phishing, which is a huge problem. According to the 2015 Verizon Data Breach Incident Report (DBIR), 23 percent of phishing recipients open messages, and 11 percent click on attachments. The 2013 DBIR reported 95 percent of incidents attributed to state-sponsored actors used phishing, and more than two-thirds of cyber-espionage incidents involved phishing.
A cybercrime campaign of only 10 emails yields a greater than 90 percent chance that one person will click on a malware link. Fifty percent of users open emails and click within the first hour of receiving.
Going Beyond Phishing But the social engineering problem goes well beyond phishing.
It is no wonder hackers use social engineering techniques; they work. Hackers are in business and are looking for a return on investment. Whether it is stolen identities, bank account numbers, intellectual property or just notoriety, they are looking for a return for their time.
Think of it this way: If you had a choice to spend hundreds of hours scanning networks, identifying operating systems and applications in use, determining vulnerabilities, and crafting malware, or making one phone call pretending to be from the help desk and talking a user out of his/her password, which would you do? Social engineering provides a greater return on investment.
Social engineering is not an invention of the information or even the industrial age; it has been around throughout history—look at the original Trojan horse. There is a psychological basis for why social engineering works. All of the following can be turned against a target to gain a goal:
Trust
Sense of urgency
Desire to be helpful
Curiosity
There are many tools available to cybercriminals to conduct social engineering and gain valuable information from individuals, including Google and other search engines, dumpster dives, simple phone calls to just ask, burner phones (prepaid cell phones replaced frequently to avoid leaving a trail), caller ID spoofing, doppelganger domains, fake public Wi-Fi access points, and, yes, phishing email.
Fighting Back Against Social Engineering So how do you block this path of least resistance and prevent attacks, detect attacks sooner and lessen impact? First, it is critical to know what information hackers are looking for in social engineering attacks and how to protect it. Having some technical security controls in place is critical, as well. And, finally, awareness training—making your people social engineering attempt detectors—will go a long way in addressing the weakest link in these sorts of attacks—humans.
Douglas Rausch is President of Aurora Cybersecurity Consultants, and an assistant professor of cybersecurity at Bellevue University, Bellevue, NE. His expertise centers on providing risk management, cybersecurity, governance and awareness training expertise to organizations worldwide. He brings 25 years of experience as a cyber operations officer in the US Air Force, leading risk management activities, assessing cybersecurity, and recommending cybersecurity policy and technologies for Department of Defense and Air Force terrestrial and space systems. He was recently appointed to the National Initiative for Cybersecurity Education (NICE), Training and Certification Sub-Working group.
Rausch will present a webinar, Social Engineering: Placing Obstacles on the Path of Least Resistance, on Tuesday, 23 February, at 11AM Central Standard Time. To sign up, click here.
Douglas Rausch, CISSP President Aurora CyberSecurity Consultants, Inc.
Ransomware persists as one of the top crimeware threats thus far into 2016. While the use of document-based macros for ransomware distribution remains relatively uncommon, a new family calling itself “Locky” has borrowed the technique from the eminently successful Dridex to maximize its target base. We first learned of Locky through Invincea and expanded on qualifying this threat with the help of PhishMe. Locky has also gained enough traction to find its way onto Dynamoo’s Blog and Reddit.
Using Palo Alto Networks AutoFocus, Unit 42 observed over 400,000 individual sessions containing the Bartallex macro downloader, which in turned dropped Locky ransomware onto victim machines. Researchers suspect there is a link between the Dridex botnet affiliate 220 and Locky due to similar styles of distribution, overlapping filenames, and an absence of campaigns from this particularly aggressive affiliate coinciding with the initial emergence of Locky. This blog post explores this threat further and offers recommendations on mitigating its impact.
Delivery and Installation
Palo Alto Networks telemetry showed that Locky focuses primarily on e-mail delivery through massive phishing campaigns with Microsoft Word document attachments. The subjects for these malicious messages adhere to the following convention:
ATTN: Invoice_J-< 8-digits>
The naming convention of respective malicious Word document carrier files match the e-mail subject line portion after the “ATTN: “, switch the “i” in invoice to lowercase, and append a “.doc” extension. An example follows:
Our analysis revealed that this ransomware requires command and control (C2) communication for a key exchange, prior to encrypting victim files. It performs its key exchange in memory for this process. This is interesting, as most ransomware generates a random encryption key locally on the victim host and then transmits an encrypted copy to attacker infrastructure. This also presents an actionable strategy for mitigating this generation of Locky by disrupting associated C2.
Unfortunate victims unable to mitigate this threat would see the following ransom demand.
And a subsequent visit to the referenced Locky payment portal site would reveal the following options for victims.
Threat Volume and Targeting
We observed approximately 446,000 sessions for this threat, over half of which targeted the United States (54%). For comparison, the next most impacted countries, Canada and Australia, only accounted for another nine percent combined.
Industry analysis for targeting reveals expected indiscriminant distribution within impacted countries; however, Higher Education, Wholesale and Retail, and Manufacturing make up over a third of observed targeting.
Pairing this volume with the “decryption cost” advertised for Locky victims, it is clear why ransomware in general continues to thrive in the threat landscape. Using some napkin math furnished by our friends at PhishMe, even if one assumed a 50% efficacy / infection rate for these 446,000 sessions and a 1% payment rate of 0.5 bitcoins (BTC) from victims, the currently observed activity alone yields several hundred thousands of dollars in profits for Locky’s malicious actors.
Conclusion
Locky is aiming high in an effort to join the ranks of other big name ransomware families. Despite some weaknesses in its current implementation, we can expect to see further developments for this threat in the future. Ultimately, successes experienced by one attacker group embolden and inspire others. It goes without saying that cybercrime adversaries will continue to advance efforts to commoditize the already lucrative extortion of victims through encryption-based extortion.
Defending against ransomware first requires a focus on the basics of a strong security posture: security awareness and the hardening and patching of systems. Ransomware can be especially damaging in enterprises, where this class of threat commonly targets network shares and other media attached to corporate assets. To further reduce associated risks, layered preventive controls are a must.
Palo Alto Networks customers are protected through our next-generation security platform:
WildFire successfully detects this threat as malware
AutoFocus identifies this threat under the Unit 42 “Locky” tag
The C2 domains and files mentioned in this report are blocked in our Threat Prevention product
