In early May, researchers disclosed a Mobile malware campaign by a group focused on Middle Eastern targets. This actor was found to be an evolving and sophisticated group using fake Android apps, namely Telegram, to trick users into installing malicious software. They have been active since 2015 and evolved over several campaigns into 2018. On May 14, a Reddit post linked to LamePT, claiming to have leaked their infrastructure including a database containing victim information.
The current leaked assets include:
- MYSQL database
- Audio recordings
- The old C2 server and assets
- AppData folder (presumably of the C2 server)
- Current C2 server and control panel
Further leaked documents are behind a paywall payable to a fresh bitcoin address. The first payment was made on May 13th, 2018 leaving a balance of $1,110.87. It’s difficult to verify if someone paid to have the first dataset released or the actor paid themselves to appear more authentic. With that said, the authenticity of the data is still in question as we have some significant doubts on at least a portion of the data. For example, the following SMS caught our attention:
“Wife.how she knew the time of murder exactly”.
This text can be found in an SMS spam dataset used for training spam engines. Many other English based SMS messages can also be found here. “will be office around 4 pm. Now I am going hospital” is another example. Universities tend to use these datasets to teach computer science concepts. In this case, the concept is likely related to machine learning techniques for categorizing messages into spam. One university came up often when searching for these messages based on its Computer Science I: Fundamentals homework postings. Other messages could be found in cached websites.
“Credit shuma ka mast jahat ezdiad credit ba hesab tan shumarai 222 ra dair namoda w aba taqeeb aan code 14 raqami ra dakhel nomaed .”
This translates to “Credit card is not available for sale at 222 days or less than 142 days.” and found cached in a language translation site. This particular phrase was being translated from Turkish to Urdu. Not all of the messages were found publicly online. Most of the messages were in Middle Eastern languages presenting its own challenges. Other sources were found such as Facebook posts; however, sources for the vast majority of the SMS message have not yet been located. For these reasons, we remain skeptical of the authenticity of the data.
Other data such as the recordings do not appear to be publicly available. After sampling 100 of these files we’ve found them to sound like authentic recordings. The majority are in 7 minute 59 second .3gpp files. Most appear to be ambient conversations and daily activities and not phone calls as was expected. Searching for public audio is difficult but we can verify that the hashes of the 100 are not publicly indexed by major search engines nor are the file names themselves.
Until we know for certain whether the data is authentic we cannot grantee that this data dump represents ZooPark and its capabilities but we can look at what they could be up to. After reviewing the leaked MySQL database we’ve learned much about the ZooPark’s potential operations.
From the table names alone, we can infer a lot of the access ZooPark had to user devices and the data they were after. Call tracing, phonebook access, and SMS tracking are unfortunately very common to collect amongst malicious app developers. However, audio tracking caught our attention. While we are still analyzing the dataset, the database records indicate over 102,571 recordings have been uploaded to their C2 server between 2015 and 2018. The dump contains approximately 3,887 of these, jeopardizing private and potentially highly sensitive conversations. Our sampling of these files indicate that the audio was recorded in roughly 8-minute blocks. Most, but not all audio files took place with time gaps between them. There was at least one group conversation that continued on for at least 3 recorded blocks. A surprisingly low number of phone numbers generated these recordings. Only eight phone numbers are part of the recording available through this data dump.
Other conversations were also captured such as SMS texts although portions of these have been found publicly in open datasets. Conceivably, these could have been generated by researchers investigating the malicious Android apps but it’s more likely they were generated by the data leaker to sell the dump. The SMS texts contain much of what you expect such as general chat, and advertisements. However, it’s also riddled with embarrassing or explicit texts which could be used against the users should they prove legitimate. Additionally, we’ve found cleartext two-factor authentication messages from major services such as Google and LinkedIn, and popular chat apps such as Telegram. ZooPark could have used these to gain access to additional services unbeknownst to the victims. After attempting and failing to rebuild several English based conversations we have little confidence that the entire data set came from ZooPark. However, It does exemplify the real danger of sensitive conversations being collected by Zoopark and available for their operations.
Another surprising find is in the Appinfotracking table, where there are 1541 unique apps listed, indicating a very large campaign. Here are a few notable ones:
There were relatively few games listed compared to other social and utility apps, perhaps suggesting a more utilitarian or professional target. Approximately, 92 phone numbers are listed in relation to the apps. Of the GPS coordinates we’ve checked the middle east is still the main focus, with a significant footprint in Egypt.
While the data leakers request is for Bitcoin payment, we believe they are primarily interested in acquiring Monero coin. Once payments are made the actors use a popular tool called ShapeShift to turn the Bitcoin into Monero (XMR). Shapeshift allows the actors to pay in from one cryptocoin and receive a payout in another without creating an account for the service. The added Monero features enable them to maintain greater anonymity during the transfer. It is anonymity that usually motivates cybercriminals to move to Monero. Monero coins are of interest due to their improved anonymity and privacy-related improvements, making it difficult to for law enforcement and security researchers to trace.
The actor who leaked this data is obviously motivated by money as evidenced by the requested payment for further data leaks. Fake datasets, especially those that contain credit card information, email addresses and passwords, have been known to be for sale to scam other cybercriminals. It’s a distinct possibility that this could be the case with the current data dump but it has yet to be determined. However, competition also can play a primary motivator. Many times competing bad actors will attempt to sabotage others in the space. Altruism can play a role as well. Some vigilante actors may believe that their motivations are for the greater good regardless of the laws they break and collateral damage. Whatever the motivations are, data leaks like these can be embarrassing, damaging and in some cases dangerous for the victims whose information it may contain.
Other points of interest:
- There are a surprisingly low number of unique victim numbers in the database with only 169.
- The latest URL record is as recent as May 12,2018
- The latest SMS record is as recent as May 8,2018
- 81 unique numbers had 47,784 records of GPS data stored
The post It’s a Zoo Out There! Data Analysis of Alleged ZooPark Dump appeared first on McAfee Blogs.
CPU hardware implementations
On May 21, 2018, new variants of the side-channel central processing unit (CPU) hardware vulnerabilities known as Spectre and Meltdown were publicly disclosed. These variants—known as 3A and 4—can allow an attacker to obtain access to sensitive information on affected systems.
Common CPU hardware implementations are vulnerable to the side-channel attacks known as Spectre and Meltdown. Meltdown is a bug that "melts" the security boundaries normally enforced by the hardware, affecting desktops, laptops, and cloud computers. Spectre is a flaw that an attacker can exploit to force a CPU to reveal its data.
Variant 3a is a vulnerability that may allow an attacker with local access to speculatively read system parameters via side-channel analysis and obtain sensitive information.
Variant 4 is a vulnerability that exploits “speculative bypass.” When exploited, Variant 4 could allow an attacker to read older memory values in a CPU’s stack or other memory locations. While implementation is complex, this side-channel vulnerability could allow less privileged code to
- Read arbitrary privileged data; and
- Run older commands speculatively, resulting in cache allocations that could be used to exfiltrate data by standard side-channel methods.
Corresponding CVEs for Side-Channel Variants 1, 2, 3, 3a, and 4 are found below:
- Variant 1: Bounds Check Bypass – CVE-2017-5753
- Variant 2: Branch Target Injection – CVE-2017-5715
- Variant 3: Rogue Data Cache Load – CVE-2017-5754
- Variant 3a: Rogue System Register Read – CVE-2018-3640
- Variant 4: Speculative Store Bypass – CVE-2018-3639
Side-Channel Vulnerability Variants 3a and 4 may allow an attacker to obtain access to sensitive information on affected systems.
NCCIC recommends users and administrators
- Refer to their hardware and software vendors for patches or microcode,
- Use a test environment to verify each patch before implementing, and
- Ensure that performance is monitored for critical applications and services.
- Consult with vendors and service providers to mitigate any degradation effects, if possible.
- Consult with Cloud Service Providers to mitigate and resolve any impacts resulting from host operating system patching and mandatory rebooting, if applicable.
The following table contains links to advisories and patches published in response to the vulnerabilities. This table will be updated as information becomes available.
|Link to Vendor Information||Date Added|
|AMD||May 21, 2018|
|ARM||May 21, 2018|
|Intel||May 22, 2018|
|Microsoft||May 21, 2018|
|Redhat||May 21, 2018|
- Google Project Zero Blog
- Bounds Check Bypass – CVE-2017-5753
- Branch Target Injection – CVE-2017-5715
- Rogue Data Cache Load – CVE-2017-5754
- Rogue System Register Read – CVE-2018-3640
- Speculative Store Bypass – CVE-2018-3639
- TA18-004A – Meltdown and Spectre Side-Channel Vulnerability Guidance
- May 21, 2018: Initial version
- May 22, 2018: Added information and link to Intel in table
When cybersecurity professionals communicate with regular, non-technical people about IT and security, they often use language that virtually guarantees that the message will be ignored or misunderstood. This is often a problem for information security and privacy policies, which are written by subject-matter experts for people who lack the expertise. If you’re creating security documents, take extra care to avoid jargon, wordiness and other issues that plague technical texts.
To strengthen your ability to communicate geeky concepts in plain English, consider the following exercise: Take a boring paragraph from a security assessment report or an information security policy and translate it into a sentence that’s no longer than 15 words without using industry terminology. I’m not suggesting that the resulting statement should replace the original text; instead, I suspect this exercise will train you to write more plainly and succinctly.
For example, I extracted and slightly modified a few paragraphs from the Princeton University Information Security Policy, just so that I could experiment with some public document written in legalese. I then attempted to relay the idea behind each paragraph in the form of a 3-line haiku (5-7-5 syllables per line):
This Policy applies to all Company employees, contractors and other entities acting on behalf of Company. This policy also applies to other individuals and entities granted use of Company information, including, but not limited to, contractors, temporary employees, and volunteers.
If you can read this,
you must follow the rules that
are explained below.
When disclosing Confidential information, the proposed recipient must agree (i) to take appropriate measures to safeguard the confidentiality of the information; (ii) not to disclose the information to any other party for any purpose absent the Company’s prior written consent.
Don’t share without a
contract any information
All entities granted use of Company Information are expected to: (i) understand the information classification levels defined in the Information Security Policy; (ii) access information only as needed to meet legitimate business needs.
Know your duties for
safeguarding company info.
Use it properly.
By challenging yourself to shorten a complex concept into a single sentence, you motivate yourself to determine the most important aspect of the text, so you can better communicate it to others. This approach might be especially useful for fine-tuning executive summaries, which often warrant careful attention and wordsmithing. This is just one of the ways in which you can improve your writing skills with deliberate practice.
The Daily Threat Brief is our version of the President’s Daily Brief (PDB), focused on cyber threats and tips on being as secure as possible. We provide actionable insights into threat actors and their motivations and also dive into their tactics in ways that will inform your business decisions.
To sign up for the Daily Threat Brief see: CTOvision Newsletter Signups
Our full array of newsletters includes:
- The Monthly CTOvision.com Tech Review provides a recap of the most significant trends sweeping the technology community in the prior month, plus insights into coming events and activities.
- The Daily CTOvision.com Update provides a summary of posts we publish on our blog. If we don’t publish it does not go out, but it is never more than once a day to 6,000 readers. All posts on the site are also shared with the over 14,500 CTOvision twitter followers and over 12,000 of Bob Gourley’s connections on LinkedIn.
- The CTOvision Pro IT Report summarizes enterprise IT developments and concepts. Transmitted to a select list of 700 CTOs and other tech professionals every Tuesday.
- The Weekly Artificial Intelligence, Big Data and Analytics Newsletter is a weekly review of hot topics on the theme of Big Data. This is our fastest growing list with over 1,500 readers receiving the newsletter every Wednesday.
- The Weekly Cyberwar and Cybersecurity Review summarizes enterprise IT security technologies and concepts and the issues you need to track regarding the high end threat actors. Over 6,000 readers receive this report every Thursday.
- The Daily Threat Brief Our version of the President’s Daily Brief (PDB) focused on cyber threats and tips on being as secure as possible. Sent daily to a list of over 4,500 executives seeking insights into threats to business growth. Reports are also shared with over 10,000 Twitter followers of ThreatBrief.
For more and to sign up see: Crucial Point and CTOvision Newsletter Signups
The post The Daily Threat Brief: The President Gets A Daily Brief, Shouldn’t You? appeared first on The Cyber Threat.
Spear phishing attacks are seen as one of the biggest cyber threats to an organization. It only takes one employee to enter their credentials or run some malware for an entire organization to become compromised. As such, companies devote significant resources to preventing credential harvesting and payload-driven social engineering attacks. Less attention, however, has been paid to a non-traditional, but just as dangerous, method of social engineering: OAuth abuse. In an OAuth abuse attack, a victim authorizes a third-party application to access their account. Once authorized, the application can access the user's data without the need for credentials and bypassing any two-factor authentication that may be in place.
Today, I’m releasing PwnAuth, a platform to allow organizations and penetration testers an opportunity to test their ability to detect and respond to OAuth abuse social engineering campaigns. In releasing the tool, we hope to increase awareness about this threat, improve the security community’s ability to detect it, and provide countermeasures for defenders.
Head over to our GitHub to start using PwnAuth.
What is OAuth?
OAuth 2.0 is described as "An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications..." It has become the de facto protocol that major Internet companies such as Amazon, Google, Facebook, and Microsoft use to facilitate granting third-party applications access to user data. An application that accesses your Microsoft OneDrive to allow for easy file sharing is an example of an application that would leverage OAuth.
Let’s use an application accessing OneDrive as an example to define some roles in an OAuth authorization flow:
The Application, or "Client"
The third-party application that is requesting access. In this case, the application that wishes to access your OneDrive files is the "Client."
The API "Resource"
The target application the "Client" wishes to access. In this case, the Microsoft OneDrive API endpoint is the "Resource."
The "Resource Owner"
The person granting access to a portion of their account. In this case, you.
The Authorization Server
The Authorization Server presents the interface that the Resource Owner uses to give or deny consent. The server could be the same as the API Resource or a different component. In this case, the Microsoft login portal is the "Authorization Server".
The Scope is defined as the type of access that the third-party application is requesting. Most API Resources will define a set of scopes that applications can request. This is similar to the permissions that an Android phone application would request on installation. In this example, the application may request access to your OneDrive files and user profile.
OAuth 2.0 provides several different authorization "grant types" to facilitate the different applications that we, as users, interact with. For the purpose of this post, we are interested in the "Authorization Code" grant type, which is used by web applications implementing OAuth. The following is an example authorization flow:
1. A "Consent" link is created that directs the Resource Owner to the Authorization Server with parameters identifying the Application and the scopes requested.
2. The Resource Owner will be presented with an authorization prompt, stating the application name and requested scopes. The Resource Owner has the option to approve or deny this authorization request.
3. Upon approval, the Authorization Server will redirect back to the Application with an authorization code.
4. The Application can then use the authorization code and request an access token from the Authorization Server. Access tokens can be used for a set duration of time to access the user’s data from the API Resource, without any further action by the Resource Owner.
Room For Abuse
OAuth applications provide an ideal vector through which attackers could compromise a target and harvest confidential data such as email, contacts, and files. An attacker could create a malicious application and use the obtained access tokens to retrieve victims' account data via the API Resource. The access tokens do not require knowledge of the user's password, and bypass any two-factor enforcement. Further, the only way to remove an attacker's access is to explicitly revoke access to the OAuth application. In order to obtain OAuth tokens, an attacker would need to convince a victim to click a "Consent link" and approve the application via social engineering. Because all victim interaction is on sites owned by the legitimate Resource Provider (e.g. Microsoft), it can be hard for an untrained user to differentiate between a legitimate OAuth application and a malicious one.
Though likely not the first instance of such campaigns, OAuth abuse first came to the media's attention during the 2016 presidential election. FireEye wrote about APT28's usage of OAuth abuse to gain access to emails of U.S. politicians in our M-TRENDS 2017 report. Since then, FireEye has seen the technique spread to commodity worms seeking to spread across Gmail.
PwnAuth is a web application framework I wrote to make it easier for organizations to test their ability to detect and respond to OAuth abuse campaigns. The web application provides penetration testers with an easy-to-use UI to manage malicious OAuth applications, store gathered OAuth tokens, and interact with API Resources. The application UI and framework are designed to be easily extendable to other API Resources through the creation of additional modules. While any cloud environment that allows OAuth applications could be targeted, currently PwnAuth ships with a module to support malicious Office 365 applications that will capture OAuth tokens and facilitate interaction with the Microsoft Graph API using those captured tokens. The Office 365 module itself could be further extended, but currently provides the following:
- Reading mail messages
- Searching the user's mailbox
- Reading the user's contacts
- Downloading messages and attachments
- Searching OneDrive and downloading files
- Sending messages on behalf of the user
The interface is designed to be intuitive and user-friendly. The first step to using PwnAuth would be to create a Microsoft Application. That information must then be entered into PwnAuth (Figure 1).
Figure 1: Importing a Microsoft App into PwnAuth
Once configured, you can use the generated "Authorization URL" to phish potential victims. When clicked, PwnAuth will capture victim OAuth tokens for later use. An example victim listing is shown in Figure 2.
Figure 2: Listing victim users in PwnAuth
Once PwnAuth has captured a victim's OAuth token, you can begin to access their data. Use PwnAuth to query the victim's mailbox for all messages containing the string "password", for example (Figure 3).
Figure 3: Searching the mailbox of a victim
See the GitHub wiki for more information on usage.
Our FireEye technology stack includes network-based signatures to detect potentially malicious OAuth consent URLs. Attackers tend to include certain scopes in malicious apps that can be detected and flagged. Organizations with social engineering training programs can add OAuth abuse scenarios to their existing programs to better educate users about this attacker vector. Additionally, organizations can take steps to limit the potential impact of malicious OAuth applications and increase their detection capabilities. The options available to an organization vary greatly depending on the API Resource, but, in general, include:
- Limit the API scopes third-party apps can request.
- Disable third-party apps in an organization.
- Implement a whitelist or blacklist for applications.
- Query an organization's user base for all consented applications.
- Log any user consent events and report suspicious activity.
Office 365 in particular offers some options for administrators:
- Organizations with Cloud App Security can make use of the "app permissions" feature to query and block third party applications.
- Administrators can block access to third-party applications globally.
- Administrators can take actions if they believe a malicious app was granted access to an account.
- The Unified Audit Log records whenever a user consents to a third-party application; however, the specific scopes and app information is not recorded in the log.
I have created a collection of scripts to assist administrators in hunting for malicious OAuth applications in cloud environments. Currently there is a script to investigate Office 365 tenants with plans to add other cloud environments.
OAuth abuse attacks are a dangerous and non-traditional phishing technique that attackers can use to gain access to an organization's confidential data. As we move more services to the cloud, organizations should be careful to lock down third-party application access and ensure that their monitoring and detection strategy covers application consent grants. Organizations and security professionals can use PwnAuth to test their ability to detect and respond to this new type of attack.
Head over to our GitHub and start using PwnAuth today.
Save time with a one-click process
ThreatConnect developed the Playbooks capability to help analysts automate time consuming and repetitive tasks so they can focus on what is most important. And in many cases, to ensure the analysis process can occur consistently and in real time, without human intervention.
An automated malware analysis system (AMA) is a requirement in any defender's repertoire. Any time that can be saved during an analyst's process performing what amounts to menial labor can be spent on actual analysis and proactively defending an organization.
This Playbook takes a suspicious or malicious file sample from ThreatConnect's Malware Vault and transmits it to an automated malware analysis system, in this case, VMRay, submitting it for dynamic and static analysis. It turns a manual, multiple-click process into a simple, one-click process, saving a small amount of time, which really adds up over the course of weeks and months.
The Playbook is triggered by a User Action. In this case, the run playbook button is mapped to Documents in ThreatConnect. This generates a button on the Document's details page called "VMRay Analyze".
The Playbook downloads the malware sample and copies the archive password stored in an attribute of the Document. These two, as well as any configuration settings, are submitted to VMRay's REST API. The Playbook checks whether either of two TLPs are marking the sample: TLP:RED or TLP:AMBER. If they are present, the sample is only analyzed by VMRay, it is not additionally checked with third party scanners. Finally, the Playbook checks for errors and returns a nice tooltip with a link to the analysis report in VMRay's portal.
Entire VMRay Submission Playbook
New Playbook Return on Investment Calculator
In the latest release of ThreatConnect, Playbooks now have a Return on Investment (ROI) calculator. By estimating the time saved by running a playbook compared with the time wasted by an analyst performing the process manually, one is able to calculate roughly how much money a playbook is saving a team over time.
The following are a few highlights from certain steps in the Playbook:
A set variable app is first in the sequence of the playbook. This allows the user to set various options used during submission to VMRay.
This step uses an implementation of JMESPath to check if the sample in the ThreatConnect Malware Vault has been marked with a security label. In this case, it is checking for TLP:AMBER and TLP:RED, two designations that are part of the traffic light protocol, a system for governing how data may be shared and with whom. In this case, data that is marked with either of these two restrictive TLPs will be sent only to VMRay and not to any third party system.
This step leverages ThreatConnect's data store to save the API response from VMRay. As you can see, this uses the "Organization" domain of the data store. This allows other playbooks running in one's org in ThreatConnect access to the data that this playbook writes there. Any further operations can then be built out in other playbooks based on the saved data.
The trigger for this playbook is a User Action. This provides a button on the malware vault document that runs the playbook in the context of that Document. After the sample has been submitted for analysis to VMRay, a link back to the report in VMRay's portal is displayed to the user as a tooltip that appears above the button once it has been clicked. If for some reason the analysis failed at the time of submission, the error message is displayed in the same tooltip for the user to view.
The post Playbook Fridays: Conducting VMRay Malware Analysis appeared first on ThreatConnect | Enterprise Threat Intelligence Platform.