mrmoor/cyber-threat-intelligence huggingface dataset:
The library also registers a receiver named com.zdtpay.Rf2b for both the SMS_RECEIVED and BOOT_COMPLETED actions with highest priority of 2147483647.
Registered receiver for SMS_RECEIVED  The registered receiver Rf2b reads SMS messages whenever they arrive.
The message body and sender phone number are collected as shown in Figure 2.  Figure 2.
SMS body and sender number read
If the device has just booted, it will start the service MySd2e, which then registers a receiver for Rf2b as shown in Figure 3.
MySd2e Service registers receiver for Rf2b
SMS information collected by the receiver is saved in a hashmap with “other” as the key and sent to a method that uploads the message to 112.126.69.51 as shown in Figure 4.
Figure 4. Information uploaded to IP Address used by api.taomike.com
All SMS messages sent to the phone are uploaded, not just those that are relevant to Taomike’s platform.
Figure 5 shows a packet capture of a test message upload.
The message content is “hey test msg” as circled with dashed red box.
SMS uploaded via HTTP in pcap  The Taomike library makes contact with the following URLs, but only the “2c.php” path is used to capture SMS messages.
The rest appear to be used for other parts of the IAP functionality in the library.
Risks and Mitigation
We have captured over 18,000 samples that contain the SMS stealing library since August 2015, meaning the number of affected users is considerable.
We expect the number of affected apps and users to increase as more developers incorporate the newer version of Taomike library.
The infected apps are not limited to a single developer or third party store as many developers appear use the Taomike library.
Some of the infected apps purport to contain or display adult content.
We do not know how Taomike is using the stolen SMS messages, but no library should capture all messages and send them to a system outside the phone.
In version 4.4 of Android (KitKat) Google began preventing apps from capturing SMS messages unless they were defined as the “default” SMS app.
Users outside of China and those that only download apps from the official Google Play store are not at risk from this threat.
To protect Palo Alto Networks customers from the Taomike SMS stealer, we’ve made the following protections available:
Conclusion  Even popular third party monetization platforms are not always trustworthy.
When developers incorporate the libraries into their apps they need to carefully test them and monitor for any abnormal activities.
Identifying monetization and advertising platforms that behave poorly and abuse their users is something that our industry must to do ensure the safety of all mobile devices and their users.
Acknowledgement  We greatly appreciate the help from Rongbo Shao from Palo Alto Networks in working on the Threat Prevention signature.
We would also like to thank Ryan Olson, Benjamin Small, Richar Wartell, and Chris Clark from Palo Alto networks in publishing the discovery.
Related Sample Hash Values  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!
Recently, we found email accounts from top universities across the world being sold on Taobao, the largest consumer-to-consumer (C2C) e-commerce platform in China.
Advertised uses for these accounts included registering for special accounts under software developer programs, receiving student discounts or coupons from retailers, and obtaining access to academic databases.
This post describes the scope, associated risks, and implications of this activity.
Our investigation began with a Chinese language search for "edu mailbox" in Taobao, which returned 99 results related to stolen university email accounts.
The most expensive account was listed at ¥2400 RMB ($390.80 USD), while the cheapest was only ¥0.98 RMB ($0.16 USD).  Figure 1: Results for Chinese language "edu mailbox" search on Taobao.
These accounts, which include an education (EDU) top-level domain email address with valid password, represent 42 of the world’s top universities, across 10 countries:
The descriptions for these items proposed three main uses for buyers:
1. Registering for special accounts under software developer programs:
For example, the most popular account type, which has been bought at least 569 times, was advertised as a Microsoft’s student Windows Phone 7 and 8 developer account.
By using this kind of account, a user can perform a developer unlock on their Windows Phone devices without incurring a fee.
Most reviews of this package were favorable, with comments like "very good to use" or "with seller’s help I can unlock my phone now."
Figure 2: The most popular account type has sold at least 569 times.
2. Receiving student discounts or coupons from retailers:
Some accounts advertised candidacy towards registration for student discount at retailers such as Amazon, BestBuy, Apple, and Dell.
For example, the standard annual fee for Amazon Prime is $99 USD; however, with the student discount, a buyer could enjoy it for free the first six months and then renew at half price for subsequent years.
Figure 3: The seller showed how to register for student discount accounts.
3. Obtaining access to academic databases:
Accounts for big universities (e.g., MIT, Stanford, etc.) are mainly used to access respective library services and resources, "including research help, study spaces, print and electronic books/journals and more."
Figure 4:
A seller advertises how an MIT account can be used to access online library resources.
We talked with some sellers through AliWangWang, an instant message (IM) system developed by Taobao for online trading.
A well-stocked seller told us that every account he sold belonged to an active student at the respective university.
He claimed that once the account was sold, only the one buyer and the legitimate user would have access.
He recommended not changing the account password to avoid detection by the legitimate user.
Another seller offered to provide real identity information for a stolen account so the buyer could change the corresponding password and security questions.
This type of account access was the most expensive and least flexible in terms of customization (i.e., username, institution, etc.).
Additionally, it should be noted that there is value beyond the EDU account itself for password and security question information, in the event they are shared across other online accounts for the legitimate user.
Other sellers were also able to offer customizable email accounts from a specific domain/institution.
Figure 5: A seller advertising a customizable “xxx.edu” email account.
In the above advertisement, the seller describes the ability to choose an account under a subdomain (academia, student, me, email, or contact) of the requested domain.
The price for this custom account was only ¥27 RMB ($4.40 USD); for an extra ¥13 RMB ($2.12 USD), the buyer can request a custom username at any subdomain for the given institution.
To further assess this threat, we purchased a customized, new account from a seller on Taobao.
Four hours later, we received confirmation that the custom email address "claud@student.cnri.edu" was active.
Navigating to CNRI’s webmail page, we were then able to successfully access and send an email from that account.
Figure 6: Sending an email through a newly bought customized EDU account.
Another noteworthy trend we observed was that some sellers provided email addresses with customizable usernames at "californiacolleges.edu".
In fact, anyone can do the same by visiting the California Colleges Create an Account page.
Accounts made through this site "can be used to apply [for] related memberships of Amazon Prime, Microsoft Developer, Adobe and Apple by some secret ways," one seller said.
Figure 7: Using a newly created California Colleges account.
As with most criminal enterprises, not all sellers on Taobao use their real identity, presenting a challenge in tracking down the individuals behind this activity.
In order to sell anything on Taobao, a seller must at least create a valid Alipay account (similar to PayPal) linked to a valid Chinese citizen ID number (similar to a U.S. Social Security number), and then associate it with a valid Chinese bank account under the same citizen ID.
However, identity theft is a global concern and the Chinese citizen ID is no exception, allowing for potential sellers to simply purchase a usable identity online.
Based on our investigation, we believe that stolen accounts for these universities are actively selling on Taobao.
On August 27, we reported our findings to Taobao.
Their response was that they were addressing this issue and have already removed a number of these items, with the remainder requiring further investigation.
However, this malicious seller activity may also reveal a larger scale problem within university systems.
Through the types of accounts advertised on Taobao, an attacker can steal a student or staff account, assume their identity, and gain unauthorized access to standard university resources.
More sophisticated and nefarious uses include leveraging accounts in social engineering/phishing attacks or exploiting access to high-value university systems (e.g., personnel, financial, research) to steal information.
Fortunately, a number of the institutions impacted by this activity have already implemented two-factor authentication for high-value resources, reducing the risk of the latter.
Yet, we believe the residual risk and exposure call for further action.
The following are our suggestions for discovering and mitigating risks associated with this activity:  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!
This post is also available in:      日本語 (Japanese)  Today, Palo Alto Networks Unit 42 researchers are announcing details on a new high- severity vulnerability affecting the Google Android platform.
Patches for this vulnerability are available as part of the September 2017 Android Security Bulletin.
This new vulnerability does NOT affect Android 8.0 Oreo, the latest version; but it does affect all prior versions of Android.
There is some malware that exploits some vectors outlined in this article, but Palo Alto Networks Unit 42 is not aware of any active attacks against this particular vulnerability at this time.
Since Android 8.0 is a relatively recent release, this means that nearly all Android users should take action today and apply updates that are available to address this vulnerability.
What our researchers have found is a vulnerability that can be used to more easily enable an “overlay attack,” a type of attack that is already known on the Android platform.
This type of attack is most likely to be used to get malicious software on the user’s Android device.
This type of attack can also be used to give malicious software total control over the device.
In a worst-case attack scenario, this vulnerability could be used to render the phone unusable (i.e., a “brick”) or to install any kind of malware including (but not limited to) ransomware or information stealers.
In simplest terms, this vulnerability could be used to take control of devices, lock devices and steal information after it is attacked.
An “overlay attack” is an attack where an attacker’s app draws a window over (or “overlays”) other windows and apps running on the device.
When done successfully, this can enable an attacker to convince the user he or she is clicking one window when, in fact, he or she is actually clicking another window.
In Figure 1, you can see an example where an attacker is making it appear that the user is clicking to install a patch when in fact the user is clicking to grant the Porn Droid malware full administrator permissions on the device.
Figure 1: Bogus patch installer overlying malware requesting administrative permissions
You can see how this attack can be used convince users to unwittingly install malware on the device.
This can also be used to grant the malware full administrative privileges on the device.
An overlay attack can also be used to create a denial-of-service condition on the device by raising windows on the device that don’t go away.
This is precisely the type of approach attackers use with ransomware attacks on mobile devices.
Of course, an overlay attack can be used to accomplish all three of these in a single attack:  Overlay attacks aren’t new; they’ve been discussed before.
But until now, based on the latest research in the IEEE Security & Privacy paper, everyone has believed that malicious apps attempting to carry out overlay attacks must overcome two significant hurdles to be successful:  These are significant mitigating factors and so overlay attacks haven’t been reckoned a serious threat.
However, our new Unit 42 research shows that there is a way to carry out overlay attacks where these mitigating factors don’t apply.
If a malicious app were to utilize this new vulnerability, our researchers have found it could carry out an overlay attack simply by being installed on the device.
In particular, this means that malicious apps from websites and app stores other than Google Play can carry out overlay attacks.
It’s important to note that apps from websites and app stores other than Google Play form a significant source of Android malware worldwide.
The particular vulnerability in question affects an Android feature known as “Toast.” “Toast” is a type of notification window that “pops” (like toast) on the screen.
“Toast” is typically used to display messages and notifications over other apps.
Unlike other window types in Android, Toast doesn’t require the same permissions, and so the mitigating factors that applied to previous overlay attacks don’t apply here.
Additionally, our researchers have outlined how it’s possible to create a Toast window that overlays the entire screen, so it’s possible to use Toast to create the functional equivalent of regular app windows.
In light of this latest research, the risk of overlay attacks takes on a greater significance.
Fortunately, the latest version of Android is immune from these attacks “out of the box.”
However, most people who run Android run versions that are vulnerable.
This means that it’s critical for all Android users on versions before 8.0 to get updates for their devices.
You can get information on patch and update availability from your mobile carrier or handset maker.
Of course, one of the best protections against malicious apps is to get your Android apps only from Google Play, as the Android Security Team aggressively screens against malicious apps and keeps them out of the store in the first place.
Mutex analysis is an often overlooked and useful tool for malware author fingerprinting, family classification, and even discovery.
Far from the hypothesized "huge amount of variability" in mutex names, likely hypothesized due to the seemingly random appearance of them, practical mutex usage is embarrassingly consistent.
In fact, over 15% of all collected worms share a single mutex [2gvwnqjz].
This blog was sourced from the data generated by the WildFire Analytics cloud, which processes thousands of samples a day and provides insights into various characteristics and behaviors of malware worldwide.
But before we get into the details, here is a quick overview of mutexes and why they exist in the first place.
The mutex is the fundamental tool for managing shared resources between multiple threads (or processes).
If you think of the threads as a whole bunch of people in a meeting, all trying to talk at once, a mutex is the baton that gets passed from one person to the next so that there’s only one person talking at a time.
The important thing to understand is what the mutex is really protecting.
In the above example, the resource being protected isn’t the right to speak, as many might think, but rather the ability to listen.
Here’s a more technical example.
Lets say you want to update an Internet Explorer (IE) cookie file, adding a unique identifier for use later.
Naively, what you need to do is read the cookie file in, add your data to what you’ve read, and write the file back to disk.
But what if IE is running and also updating that file?
The worst case, for you, is that both you and IE read the file at the same time but you write your edits first.
This is because IE will completely destroy your edits when it writes its new version of the file over yours.
The solution to this problem is to use a mutex to protect the integrity of the cookie file.
A process that has the mutex knows that while it holds that mutex no other process will be accessing the cookie file.
It can then read, tweak, and write the file without fear of any clobbering by other processes.
Since each shared resource can only have a single mutex effectively protecting it, leveraging that mutex is indication that a program will be using said resource.
In the cookie file example above, just referencing the mutex protecting that file indicates, with extremely high probability, that functionality to change the file exists somewhere in the program.
Any given mutex, and protected functionality, can then be thought of as an independent library of sorts.
Note that while the technical implementation may not expose said functionality as a normal library, such exposure is not necessary for the types of analysis performed here.
That library’s usage can be analyzed in terms of who uses it.
Simply put: malware writers leverage malware specific libraries and groups of like actors will reuse these core libraries when able.  The needle in a haystack problem forever plagues malware research: it’s extremely difficult to find reliable information with malware writers constantly working to undermine or eliminate that information.
But, in the case of mutex analysis, the useful information pretty well slapped us in the face.
As can be clearly seen, mutex 2gvwnqjz1 is strongly associated with malware.
In fact, we have only seen it in malware.
As is equally obvious, not all mutexes offer such dramatic insight.
There are many common mutexes shared across both benign software and malware.
What’s more, they don’t all share millions of uses across both sides of the fence.
In cases such as these the common approach is to use sets of the data, in this case sets of mutexes, to create fingerprints of each sample and then leverage those fingerprints to extract higher confidence classification decisions.
While this avenue of research is being pursued, it suffers from all the traditional challenges of big data research.
In other words, it’s slow going.
In parallel, and to inform better hypothesis for the fingerprint generation, research is being done to determine how far single mutex analysis can take us.
The research is ongoing but the initial results are extremely promising.
The number of times any single mutex is used drops rapidly from the millions of samples down to thousands and from there, even further.
Tens of thousands of the mutexes have been seen in only a single sample each.
This results in a few hundred thousand individual mutexes available for further analysis.
What quickly becomes apparent is that a large majority of the mutexes provide no obvious means to automatically classify them as necessarily indicative of good or bad behavior.
And, unfortunately, the ones, which are reasonably easy for a human to identify, are so for significantly different reasons.
For example,  “autoproto_*”  -- More than 20 mutexes share that preface, offering a natural fingerprint.
“global\setup_028746_mutexitem” -- Associated solely with known malware digital signers.
“defined_setnocandy”  -- After reading mutex names for a few hours this just sticks out like a sore thumb.
Only the first of the examples had the mutex associated with a vast majority of malware samples.
This implies that any fully automated association of a mutex to either benign or malware samples will itself require complex fingerprinting and confidence models.
Full automation is always the ideal but it isn’t always necessary.
With the appropriate tools it’s possible to enable a single researcher to continually review and categorize new mutexes.
The initial classifications to be used are “benign”, “malware”, or “statistical”.
Meaning that the mutex either itself indicates a benign or malware sample, or that the mutex alone is not enough to make a determination and the statistical ratio of benign to malware is the best it can offer.
The backlog of already collected mutexes is too great for a small team of researchers to meaningfully tackle without some kind of ranking system.
Luckily, the most objective piece of data collected about each mutex, how many samples were classified benign vs. malware, has all the information necessary to ensure that the researchers’ tackle the low hanging fruit first.
With over hundreds of thousands of malware associations, this specific mutex is associated exclusively with the Net-worm:W32/Allaple malware family which has been around since 2006 but continues to propagate and reinvent itself through the years.
Though the fact that the malware writer obviously named the mutex by rolling their face on the keyboard made it obvious before we'd done any further analysis that we’d found a unique identifier within the binaries.
This malware is well documented as a powerful polymorphic worm that encrypts itself differently every time it propagates.
The evasive nature of this malware family leads to a different file hash, import hash, and only a 20% average SSDeep hash overlap between the samples.
But because the mutex name is set at compile time, the mutex itself offers a common thread between all of the samples we collected and analyzed.
However, this particular mutex was associated with only a recent subset of the Allaple family.
Unlike many other avenues of research and classification, mutex name based associations provides an almost trivial means of uniquely identifying common code blocks and thereby malware families.
The first thing our researchers noticed was the similarity between this mutex name and the previous one.
While programmatic analysis would have a hard time associating the two, it's obvious to a human that the same face rolling technique was used to name this mutex.
The author simply rolled around a bit more.
Quick follow up analysis revealed that this mutex was also associated with the Allaple malware family.
More interestingly, it was another, non-overlapping, subset of the Allaple family.
Several hypotheses followed directly from this observation.
Absolute proof for a few of these hypotheses may never be realized.
However, and lucky for us, the malware author was arrested in 2010 so several of the hypothesis can be verified.
The first is very likely due to the similarities present in the order of keys hit.
Both begin with “jhd”.
“jh” itself is more common than would be expected given that, with fingers on the home row, it requires the right index finger to move and press another key before any other key is struck.
And “jh” is always followed by a key from the left side of the keyboard.
These unique consistencies make it extremely improbable that two different people named these mutexes.
The second mutex appears to be a concerted effort to make the mutex seem “more random” than the first.
It's immediately obvious that the author didn't move his fingers/hands much while typing the first.
It’s obvious enough that the author likely noticed it when reworking this section of code.
It's highly improbable that one would see the second mutex and make a concerted effort to make it appear “less random”.
And, as can be quickly verified by searching through standard virus detection logs, the mutexes did in fact appear in the hypothesized order.
The third is likely due to the lack of overlap between mutex names.
However, the research necessary to conclusively prove this hypothesis would be very time consuming and provide little other benefit.
The fourth is likely due to the mutexes only appearing in a single malware family.
If this functionality were available in some more open source setting, and was of even moderate quality, we would expect to see it used in other malware families as well.