mrmoor/cyber-threat-intelligence huggingface dataset:
The main idea of this protection mechanism is to delay the freeing action so that the intruder is unable to determine when they can occupy the freed object using controlled data.
In this new patch, every time Internet Explorer tries to free an object, it is not freed immediately.
Instead, the block to be freed is marked and filled with 0x00 data and added to a pool.
When the size of the pool hits a predefined threshold, which is currently 100k (0x186A0 as highlighted in figure 3), it performs the real freeing operation (ReclaimUnmarkedBlocks).    Figure 3.
C++ style pseudo code of ProtectedFree function
Microsoft stores the to-be-freed blocks in a structure called st_ProtecFreeManageHeap.
This structure is created in the function MemoryProtection::CMemoryProtector::ProtectCurrentThread and is used to manage deferred free heap blocks.
Figure 4 shows an example of the structure in memory.
Figure 4. st_ProtecFreeManageHeap  Figure 5 provides an alternate view of the structure in a C style code block.
Figure 5. C style code of st_ProtecFreeManageHeap
If we were able to make the size of the current heap block in this structure larger than the threshold of 0x186A0 bytes and trigger CMemoryProtector::ProtectedFree, it is still possible to force a true freeing action and occupy the freed object with other data as we show in the following piece of javascript code in figure 6.    Figure 6. Javascript proof of concept to force freeing  When creating the anchor element, the debug logs are shown in figure 7.
The address of the anchor element is 0x0c3b3f98.
Figure 7:
Before free  We then manually decrease the reference number, so the CMemoryProtector::ProtectedFree function will fill the block with 0’s, but the object is still not freed.
Figure 8: decrease the reference number, not yet freed
Finally we make the size of the CMemoryProtector::ProtectedFree management structure larger than 0x186a0 forcing the freeing operation.
Figure 9: field “TotalMemorySize” of st_ProtecFreeManageHeap is greater than threshold
The anchor element is now actually freed as shown in figure 10.
Figure 10: object is in the free list now
From a researchers' point of view, deferred free created a few problems, one of the major ones being that the page heap feature may not work correctly.
Page heap is a useful feature for debugging.
When page heap is turned on, the system allows only one object in one memory page.
Once this object is freed the whole page is marked as invalid.
So the next time IE tries to access a freed object an invalid address exception would be raised.
This mechanism is extremely helpful when researchers are trying to find use-after-free bugs.
With the introduction of the deferred free patch the object is no longer truly freed, so the page still exists.
In this situation the researcher is no longer able to determine whether a use-after-free behavior has occurred because no exception would be thrown out.
To reduce the impact of the deferred free patch, a research may consider patching the mshtml.dll in memory.
For example, you can call MemoryProtection::CMemoryProtector::UnprotectProcess before you perform any fuzzing tasks.
The recent patches and introduction of isolated heap and deferred free are strong signs that Microsoft plans to address the fundamentals of use-after-free exploitation in a preventative manner rather than to passively patch the vulnerabilities as they are discovered.
From the results of our research, applications of such methods can effectively stop unpatched use-after-free attacks.
It can also make the exploitations of heap overflows or type confusion bugs significantly more difficult.
But this is not the end.
For the foreseeable future, Microsoft may introduce more defensive mechanisms against use-after-free bugs or even heap fengshui to reduce the risk of being exploited.
Could it be game over for use-after-free exploitation, or it is just the beginning of another cat and mouse game?
Today we’re releasing a new Unit 42 white paper titled “Credential-Based Attacks: Exposing the Ecosystem and Motives Behind Credential Phishing, Theft and Abuse.”
In this paper, we look at the problem of credential theft by exploring how it happens, what attackers do with credentials once they’ve stolen them, and what you can do to help prevent credential-based attacks.
Credentials and authentication have become synonymous, with valid credentials allowing access to sensitive resources.
Adversaries are increasingly stealing and using credentials as part of their playbooks; impersonating legitimate users to access a company’s most sensitive information, erase data on servers, and reconfigure them so that they can’t boot; and undertake other malicious activities.
Stolen credentials underpin some of the most critical and damaging attacks out there; both Shamoon 2 and the Sofacy threat actor group, for example, have made detailed use of credential theft.
Credential theft today can happen in many ways, but the most notable are through credential phishing and the use of malware like keyloggers (both staples of the Sofacy group), as well as password reuse.
The impact of a successful credential theft is, ultimately, access and authorization.
Attackers will use credential theft for remote access to an organization, to access cloud-based resources (which may have weaker credential protections than network-based resources), or to move laterally within an organization once they’ve gained entry.
The most sophisticated attacks can – and do – blend these actions together, sometimes using multiple stolen credentials to penetrate networks, move laterally within them, elevate privileges, and then access and steal data.  Prevention of credential theft is too often overlooked.
Organizations should continue with user education to help users better spot and not fall for phishing and spam attacks.
You and your employees can also use password managers to make unique, complex passwords for each site not just a goal but a reality.
Technology is also catching up; recent advances in two-factor/multi-factor authentication (2FA/MFA) and one-time passwords (OTP) represent the best long-term approaches to preventing credential theft.
(Our newest release, PAN-OS 8.0, also includes protections to significantly limit or eliminate password reuse.)
Get your copy of our white paper here.
Ignite '17 Security Conference: Vancouver, BC June 12–15, 2017  Ignite '17 Security Conference is a live, four-day conference designed for today’s security professionals.
Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry.
Visit the Ignite website for more information on tracks, workshops and marquee sessions.
This post is also available in:      日本語 (Japanese)  In January 2020, during the first Patch Tuesday of the new year, Microsoft released patches for 17 new vulnerabilities including one for CVE-2020-0601 known as Curveball.
The vulnerability exists in the Windows CryptoAPI (Crypt32.dll) and specifically relates to the method used for Elliptic Curve Cryptography (ECC) certificate validation.
At the time of release, Microsoft affirmed that they had not yet seen the vulnerability exploited in the wild (ITW).
Researcher Tal Be’ery released a blog titled “Win 10 Crypto Vulnerability: Cheating in Elliptic Curve Billiard 2” that does a fantastic job at explaining this bug.
The patch provided by Microsoft included the typical release of operating system patches, but this time a new Application Programming Interface (API) function was added.
The new CveEventWrite function can be used to publish events when an attempt to exploit security vulnerabilities in user-mode applications occurs.
Analysts can collect alerts on the Application Message “CVE-2020-0601” as a means to hunt for attempted exploitation of this vulnerability on patched systems.
We also recommend users of the Chrome browser to update to version 79.0.3945.130 as they recently released an update to fix the TLS issue.  Palo Alto Networks customers running Traps are now safeguarded from the Windows CryptoAPI Spoofing vulnerability, regardless of whether they are running an unpatched Microsoft Windows 10 system.
Additionally, Palo Alto Networks offers multiple, additional complementary protections:
As a member of the Microsoft Active Protections Program (MAPP) program, Palo Alto Networks received early details of the vulnerability, providing greater understanding of the threat, which helps us implement strong product coverage.
As always, we recommend keeping your Microsoft products up to date with the latest patches to mitigate this vulnerability.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.  CVE-2020-0601: The ChainOfFools/CurveBall Attack Explained POC  Win10 Crypto Vulnerability: Cheating in Elliptic Curve Billiards 2  NSA Cybersecurity Advisory  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!
In the months since the WanaCrypt0r/WannaCry and the Petya/NotPetya attacks, security researchers have delved into the nuts and bolts these incidents and the malware involved.
One key thing that research into these security incidents shows is that these attacks used a relatively new and unknown technique called kernel APC attacks as part of their toolkit.
Kernel APC attacks occur in a way that increases the “stealth” factor and makes standard detection and prevention very difficult.
And kernel APC attacks do this while still maximizing the power and control that the code has on the target system.
While kernel APC attacks aren’t well known and can be hard to understand, their proven success in WanaCrypt0r/WannaCry and the Petya/NotPetya make them an important threat to understand because proven attack techniques are quickly adopted widely.
And understanding is a first step to prevention.
To understand what makes kernel APC attacks so dangerous, it’s important to understand what they are.  The kernel is the heart of the operating system.
When talking about operating systems with security permissions and controls like Windows or UNIX/Linux, the kernel operates with the highest level of control.
Because of this, attacks against the kernel are used to gain complete control over a system, generally as part of an “elevation or privilege” (EoP) or “privilege escalation” attack.
Typically, attacks against the kernel are used in conjunction with code execution attacks so that an attacker can target a limited privilege user but ultimately gain full control over the system.
Privilege escalation attacks against the kernel have been around for some time and are well-known and can be well protected against.  Kernel APC attacks however are a different class of attack.
These don’t attack the kernel to gain privileges.
Instead kernel APC attacks already have kernel privileges and use them to further carry out their attack.
In this case by making legitimate programs execute malicious code rather than their own legitimate code.
Kernel APC attacks do this using their control over the kernel to redirect APCs: “Asynchronous Procedure Calls”.
APCs can basically be thought of as places in line for the CPU that the kernel gives access to.
In a kernel APC attack, the attacker gives a legitimate program’s place in line to the attacker’s code.
The crux of what makes this attack technique so important is how the technique uses this level of control to have legitimate programs run illegitimate commands.
It’s easier to detect and prevent illegitimate programs (malware) from executing commands.
But when legitimate programs execute illegitimate commands, it’s harder to detect and prevent: it’s not always clear whether a command is legitimate or not, and interfering with commands from legitimate programs can have significant (sometimes catastrophic) unintended consequences.
And finally because of ways that kernel APC attacks are carried out, it doesn’t leave the usual fingerprints you find after an attack making detection harder still.
Taken altogether, these make kernel APC attacks an effective and sophisticated technique.
And while this technique alone isn’t solely responsible for the damaging power of WanaCrypt0r/WannaCry and Petya/NotPetya it is certainly an important contributing factor.
Perhaps more importantly, it’s a piece of those attacks that has escaped relative notice outside of some specialized parts of the research community.
New effective attack techniques that escape notice are always inviting for other copycat attackers.
A good way to defend against this is to understand and be aware of the thread: forewarned is forearmed.
If you want a more detailed understanding of kernel APC attacks as they occurred in WanaCrypt0r/WannaCry, two good resources are Microsoft’s MMPC blog “WannaCrypt ransomware worm targets out-of-date systems” and Countercept’s “DOUBLEPULSAR Usermode Analysis: Generic Reflective DLL Loader”.
In recent years, ransomware families are often glamorized as being some of the most dangerous types of malware.
They’ve certainly caused a wealth of damage to end users with some of the more prominent malware families, such as CryptoLocker, CryptoWall, TorrentLocker, and TeslaCrypt infecting millions of users overall.
For readers that might be unfamiliar with ransomware, it’s a type of malware that is responsible for encrypting a user’s files with a key known only to the attackers.
Examples of files that might be encrypted include financial documents, home movies, photos, or business-related files.
In order to decrypt these files, the victim must provide a ransom, or payment, to the attacker, often in the form of a digital currency.
While ransomware is often thought to be bullet-proof, it is certainly not always the case.
In early 2015, Emnisoft identified a new family of malware named PClock.
At the time, the malware was riddled with issues, specifically in the way it encrypted files.
It used a simple XOR encryption routine with a static key, allowing victims to easily recover their files without paying a ransom.
In August, we started detecting updated copies of PClock, which has been improved upon by the malware author.
We set out to determine if this updated version of PClock holds up to some of the more prominent families.
For the sake of clarity, I will refer to this newer version of PClock as PClock2 going forward.
The following sample is used for analysis:  Figure 1.
PClock2
analysis sample  PClock2 is written in Visual Basic.
For a copy of this file’s IDA Pro database (idb), please refer here.
When initially executed, PClock2 performs a very simple anti-analysis check where it will sleep for a random amount of time and compare the time spent sleeping against a set value.
This check is essentially looking for sandbox systems where the sleep function accelerates analysis.
Figure 2. Check by PClock2 for hooking of sleep function  A simple check is performed to determine if the malware is running with administrative privileges.
Once completed, the malware sends the result via an HTTP POST request to a remote server.
All data sent via HTTP POST requests is sent in the clear.
Figure 3. HTTP POST request containing administrative privileges
The ‘P0’ is statically set by the malware in the above request.
The ‘1828’ represents the thread ID (TID) of the malware, while the ‘rnd’ GET variable is randomly generated.
Throughout the runtime of PClock2, it makes multiple HTTP POST requests to a remote server using the same characteristics, including the ‘PO[TID]’ and the current time.
Additionally, the user-agent used by the entire PClock family, including PClock2, is consistent across samples.
PClock2 proceeds to copy itself with the name “winjab.exe” in the following path.
While this particular sample is seen installing itself to the %ALLUSERSPROFILE% path, other samples have been witnessed using %APPDATA% instead.
PClock2 also enables persistence by setting the following registry key.
All instances of the entire PClock family have been found to use this particular registry key.
After installation is complete, the malware makes another HTTP POST containing the various file paths it used.
Figure 4. HTTP POST request containing file paths of malware  After installation, PClock2 will also set the following registry key with a value of ‘INSTALL_OK’.
This particular registry key is used to hold the latest state of the malware.
Other messages that might be present in this key include the following.
The following registry keys are also used within the CLOCK sub-path by PClock2:  PClock2 proceeds to use the API from blockchain.info to generate a unique Bitcoin (BTC) wallet identifier, which is configured to automatically forward payments to a hardcoded wallet identifier of ‘1MRfkK134ErfbcadUSoSUCBahngCqoBKju’.
The following HTTPS request accomplishes this.
PClock2 will also make a request to the following blockchain.info address to determine the current value of BTC.
This information is stored in the ‘\BData\B’ registry key as previously stated.
The malware proceeds to generate a unique key that will be used in subsequent file encryption using the following data:  This data is concatenated to form a string similar to the following:  Figure 5.
Data collected to be used in formation of unique key  This data is then hashed using the SHA256 algorithm to generate a unique key.
This key is stored in the ‘\CData\C’ registry key as previously stated.
This key is also sent via a HTTP POST request.
Figure 6.
HTTP POST request containing unique SHA256 key  PClock2 scans the file system of the victim in order to identify files that are to be encrypted.
The following paths are ignored:  Additionally, for a list of targeted file types, please see the following link.
Once files are identified, PClock will begin encrypting them, one-by-one.
Unlike the original version of PClock, this variant has forgone the simple XOR encryption routine in place of using RC4.
The RC4 key is generated by concatenating the SHA256 value previously generated with the path to the file being encrypted.
250dd811187959220220574a185ccf669e06c0ee3926773a7cb94750c401812cC:\Documents and Settings\Administrator\Desktop\Form1.cs
It should be noted that PClock takes a very long time to encrypt these files.
On a test sandbox, the malware took upwards of 20 minutes to complete encryption, which is less than ideal for an attacker as it gives the victim time to notice the infection and stop it.
By comparison, the latest version of the CryptoWall malware family takes roughly 1-3 minutes to complete its encryption routine.
It’s also interesting to note that each time PClock2 scans a directory or encrypts a file, it makes an HTTP POST request to the C2 server.
Figure 7. HTTP POST request indicating a folder is being scanned  This resulted in over 1,000 requests being made on a sandbox machine, which contained little data of interest.
After it finished the encryption routine, PClock2 generates a VBScript file in the following directory:
This script file contains the following commands, which will delete shadow copies on the Windows operating system.
Set UAC = CreateObject("Shell.Application") UAC.ShellExecute "vssadmin", "Delete Shadows /All /Quiet", "", "runas", 1  On Windows XP, the following dialog box appears to the victim when this script runs, making it fairly apparent that something suspicious is occurring:  Figure 8.
Dialog box that appears to victim when VBS attempts to run
After running the clean up script the malware overwrites the ‘\CData\C’ registry key with a value of zero, which removes the unique SHA256 key.
Finally, the malware changes the victim’s wallpaper and generates a GUI instructing the victim how they can provide payment and retrieve their files.
This dialogue mimics the more-capable “CryptoLocker” malware family and provides instructions in both English and Spanish.
Figure 9.
Ransom demand
I originally wished to determine if the new version of PClock, PClock 2, included enough improvements to compete with some of the larger ransomware malware families, such as CryptoWall, TeslaCrypt, or TorrentLocker.
In truth, this version has made a number of improvements, such as adding more file types to target, ignoring certain directories, and using a better encryption routine.
However, a number of strong issues still plague this malware family, such as the following:  While this version is an improvement, it still lacks many of the features and stealth that are currently present in the larger ransomware families.
While ransomware is a large problem for users, it’s important to realize that not all malware families are created equal.
Like most things in life, malware comes in many shapes and forms, from the more elegant and robust solutions, to those that come up lacking.
All PClock malware family samples are properly classified as malicious by WildFire.
AutoFocus users can find more information on samples and indicators related to this attack by viewing the PClock tag.
Mobile app creators are often looking for ways to monetize their software.
One of the most common ways to do this is by displaying advertisements to users or by offering in-app purchases (IAPs).
Mobile monetization platforms create software libraries that authors can embed into their apps to start earning money quickly.
We previously highlighted the dangers of installing apps that enable IAPs using SMS messages, as these apps typically have access to all SMS messages sent to the phone.
While not all SMS-based IAP applications steal user data, we recently identified that the Chinese Taomike SDK has begun capturing copies of all messages received by the phone and sending them to a Taomike controlled server.
Since August 1, Palo Alto Networks WildFire has captured over 18,000 Android apps that contain this library.
These apps are not hosted inside the Google Play store, but are distributed via third party distribution mechanisms in China.
Background  WildFire captures many samples of mobile malware that intercept and upload SMS messages.
Most of these are created by malware authors who set up command and control (C2) servers with third party hosting providers and frequently update their locations to avoid detection.
Among these malware we have found many that are created by “mobile monetization” companies who distribute apps that provide little value but have a high cost to the user.
These apps are often installed by tricking users into clicking a pop-up, only to find later that a charge has appeared on their phone bill.
Antivirus programs typically identify these apps as malware, the topic of this blog is something different and harder to detect.
Taomike is a Chinese company that aims to become the biggest mobile advertisement solution platform in China.
They provide an SDK and services to help developers display rich advertisements with a high pay rate.
Taomike has not previously been associated with malicious activity, but a recent update to their software added SMS theft functionality.
The apps this library is embedded in may be legitimate and have significant functionality, but their developer’s choice to use this library has put them at risk.  Technical Details:
SMS Theft
Not all apps that use the Taomike library steal SMS messages.
Our analysis indicates that only samples that contain the embedded URL, hxxp://112.126.69.51/2c.php have this functionality.
This is the URL to which the software uploads SMS messages, and the IP address belongs to the Taomike API server used by other Taomike services.
We have captured around 63,000 Android apps in WildFire that include the Taomike library but only around 18,000 include the SMS theft functionality.
We believe there are different versions of the Taomike SDK and only some of them include SMS uploading behavior.
Based on our data, the version that contains the SMS stealing functions is newer and was released around August 2015.
Apps that use earlier versions of the library appear to be safe.
The Taomike library is called “zdtpay” and is a component of Taomike’s IAP system.  Because Android apps are required to list the permissions they need in their manifest file, we can see that this library requires both SMS and network related permissions.