Home Tags SHA1

Tag: SHA1

Watershed SHA1 collision just broke the WebKit repository, others may follow

"Please exercise care" with colliding PDFs, researchers advise software developers.

At death’s door for years, widely used SHA1 function is now...

Algorithm underpinning Internet security falls to first-known collision attack.

Breaking The Weakest Link Of The Strongest Chain

Around July last year, more than a 100 Israeli servicemen were hit by a cunning threat actor.

The attack compromised their devices and exfiltrated data to the attackers’ C&C.
In addition, the compromised devices were pushed Trojan updates.

The operation remains active at the time of writing this post.

Already on probation, Symantec issues more illegit HTTPS certificates

EnlargeOwn Work reader comments 16 Share this story A security researcher has unearthed evidence showing that three browser-trusted certificate authorities owned and operated by Symantec improperly issued more than 100 unvalidated transport layer security certificates.
In some cases, those certificates made it possible to spoof protected HTTPS-protected websites. One of the most fundamental requirements Google and other major browser developers impose on CAs is that they issue certificates only to people who verify the rightful control of an affected domain name or company name. On multiple occasions last year and earlier this month, the Symantec-owned CAs issued 108 credentials that violated these strict industry guidelines, according to research published Thursday by Andrew Ayer, a security researcher and founder of a CA reseller known as SSLMate.

These guidelines were put in place to ensure the integrity of the entire encrypted Web. Nine of the certificates were issued without the permission or knowledge of the affected domain owners.

The remaining 99 certificates were issued without proper validation of the company information in the certificate. Many of the improperly issued certificates—which contained the string "test" in various places in a likely indication they were created for test purposes—were revoked within an hour of being issued.
Still, the move represents a major violation by Symantec, which in 2015 fired an undisclosed number of CA employees for doing much the same thing. Even when CA-issued certificates are discovered as fraudulent and revoked, they can still be used to force browsers to verify an impostor site.

The difficulty browsers have in blacklisting revoked certificates in real-time is precisely why industry rules strictly control the issuance of such credentials.

There's no indication that the unauthorized certificates were ever used in the wild, but there's also no way to rule out that possibility, however remote it is. "Chrome doesn't [immediately] check certificate revocation, so a revoked certificate can be used in an attack just as easily as an unrevoked certificate," Ayer told Ars. "By default, other browsers fail open and accept a revoked certificate as legitimate if the attacker can successfully block the browser from contacting the revocation server." ("Fail open" is a term that means the browser automatically accepts the certificate in the event the browser can't access the revocation list.) The nine certificates issued without the domain name owners' permission affected 15 separate domains, with names including wps.itsskin.com, example.com, test.com, test1.com, test2.com, and others.

Three Symantec-owned CAs—known as Symantec Trust Network, GeoTrust Inc., and Thawte Inc.—issued the credentials on July 14, October 26, and November 15.

The other 99 certificates were issued on many dates between October 21 and January 18.
In an e-mail, a Symantec spokeswoman wrote: "Symantec has learned of a possible situation regarding certificate mis-issuance involving Symantec and other certificate authorities. We are currently gathering the facts about this situation and will provide an update once we have completed our investigation and verified information." This is the second major violation of the so-called baseline requirements over the past four months.

Those requirements were mandated by the CA/Browser Forum, an industry group made up of CAs and the developers of major browsers that trust them.
In November, Firefox recommended the blocking of China-based WoSign for 12 months after that CA was caught falsifying the issuance date of certificates to get around a prohibition against use of the weak SHA1 cryptographic hashing algorithm. Other browser makers quickly agreed. Ayer discovered the unauthorized certificates by analyzing the publicly available certificate transparency log, a project started by Google for auditing the issuance of Chrome-trusted credentials. Normally, Google requires CAs to report only the issuance of so-called extended validation certificates, which offer a higher level of trust because they verify the identity of the holder, rather than just the control of the domain.

Following Symantec's previously mentioned 2015 mishap, however, Google required Symantec to log all certificates issued by its CAs. Had Symantec not been required to report all certificates, there's a strong likelihood the violation never would have come to light.

Hacker claims FBI CMS zero day hack, dumps 155 purported logins

Amnesty nobs Plone CMS bug A hacker is claiming to have breached the FBI's content management system, dumping email addresses and SHA1 encrypted passwords with salts online. The hacker using the handle (@cyberzeist) claims to have breached the Plone CMS using a zero day flaw allegedly for sale on an unnamed dark web site. The Register has contacted the FBI to confirm the allegations. It was not immediately available for comment, however an operative was aware of the claimed incident. Cyberzeist claims to have conducted the hack last month and has posted to Twitter what they claim are screen captures showing the FBI patching against the vulnerability, which appeared to permit public access. The hacker dumped the 155 purported stolen credentials to online clipboard pastebin, claiming a vulnerability resides in a Plone Python module. They said the websites of the European Union Agency for Network and Information Security and the National Intellectual Property Rights Coordination Center are also vulnerable. Cyberzeist also claimed the FBI contacted the hacker requesting a copy of the stolen credentials, which they declined to provide. The hacker reckoned the CMS was hosted on a virtual machine running a custom FreeBSD. They said they will tweet the zero day flaw once it is no longer for sale. FBI trying to patch-up their Plone CMS #0day at https://t.co/IRhqdQjNbp, too late!! #ComingSoon #NewYearsEve pic.twitter.com/u7KOXNO3qV — CyberZeist (@cyberzeist2) December 31, 2016 The FBI is a confirmed user of the Plone CMS, as is Amnesty International. The latter organisation acknowledged a warning from Cyberzeist that its CMS was exposed. The hacker claimed the FBI's site was offline on New Year's Eve, but none of the dozen WayBackMachine site captures of the FBI's homepage on 31 December and 1 January indicated it was unavailable. ® Sponsored: Want to know more about Privileged Access Management? Visit The Register's hub

Security! experts! slam! Yahoo! management! for! using! old! crypto!

Suits should have done more to protect users, rather than user numbers ANALYSIS Fallen web giant Yahoo! has been branded negligent for failing to tackle the prodigious challenge of upgrading its MD5 password security before some one billion accounts were stolen. The security-battered organisation revealed today that attackers had stolen more than a billion accounts in August 2013 in history's biggest breach. Hackers stole names, addresses, phone numbers, and MD5 hashed passwords in a coup for social engineers who could use the information to compromise the very identity of users. That eye-watering news followed the company's September admission that 500 million accounts had been stolen in seperate attacks by alleged state-sponsored hackers in 2014, an incident that came two years after staff became first aware of the hack. Yahoo! has since replaced its MD5 hashing with the far superior bcrypt, moving from the world's worst password protection mechanism to the best. Yet it is little comfort for those who use legitimate personal details when signing up to Yahoo!'s service, including scores of American subscribers to major cable and DSL telcos including AT&T which use Yahoo! for its default email services, along with Kiwi carrier Spark which ditched the service in September. It is not known if the MD5 hashes were salted, since Yahoo! did not mention the critical additive in its statement.

Doing so would mitigate much risks from using MD5, says Jeffrey Goldberg, security guru at AgileBits, makers of the 1Password credential vault. "What is most important is whether the hashes, be they MD5, SHA1, or SHA256, are salted," Goldberg says. "There is absolutely no excuse to use unsalted hashes." But that the Purple Palace was even using the algorithm has drawn steep criticism from established security boffins. "The MD5 hashing algorithm has been considered not just insecure, but broken, for two decades," says Ty Miller, director of Sydney-based security firm Threat Intelligence, noting that MD5 collision vulnerabilities were found in 1996 with practical attacks developed in 2005. "I consider it negligent of an organisation such as Yahoo!, which has an obligation to protect the private data of over one billion users, to be using such an outdated and ineffective control to protect the passwords of its customers." The gossamer thin algorithm is a joke in security circles. Rainbow table databases serve as directories that transform hashes into cleartext passwords, and the internet is now littered with free and paid services that can reveal logins within seconds. Image: Kenneth White David Taylor, principal security consultant with Perth-based Asterisk Information Security, offered a similar opinion: "Yes, it would be pretty poor form on their part [to be] still using MD5 for hashing in 2013," he says. "There has been numerous issues reported for MD5 dating back to the mid 2000s." Board director with the lauded Open Web Application Security Project (OWASP) Andrew van der Stock, also chief technology officer at Threat Intelligence, is an advocate of baking security into the development process and sees shortcomings in Yahoo!'s security models. "This breach clearly shows that Yahoo!'s previous approach to security was less than ideal, and it's obvious that the Paranoids (Yahoo!'s security team) were unable to move the needle sufficiently with management to upgrade password hashing from an outdated and insecure algorithm to something more modern and acceptable," he says. "That it (MD5) is still commonly found in many of the worst breaches is an indication that the continued use of MD5 is correlated with other poor security practices." The breach comes at a notably poor time for Yahoo!: The company will soon be acquired by Verizon, possibly at a damaged-goods discount, and is conducting a security recruitment drive in Australia in a bid to attract local security talent, van der Stock says. "We all understand that without a complete revamp of senior management support for security and alignment with customer desires for privacy and security of their data, there is no point in taking on a position at Yahoo!," he says. Take this with a pinch of salt Administrators were salting password hashes in the 1980s, but many still fail to apply the complexity additive today.

The cryptography measure introduces random data into one-way functions preventing the use of rainbow tables by ensuring identical passwords have unique hashes. Goldberg points to the 2012 breach at LinkedIn to demonstrate the importance of salting, something the security boffin wrote about at the time. "LinkedIn had used SHA1, an improvement over MD5 in general, but it really didn’t matter that it was SHA1 instead of MD5," Goldberg tells The Register. "What mattered is that it was not salted.
I argued in 2012 that it was irresponsible for LinkedIn to have used unsalted hashes, and so that certainly applies to Yahoo! using unsalted hashes in 2013, if indeed, their hashes were unsalted." Put simply, a bland salt-free password earns the "contempt" of Goldberg and his kin, while the use of slow hashes like bcrypt, PBKDF2, or the upcoming Argon2 wins their praise. Attackers can guess salted passwords, whereas bcrypt and friends slow the rate at which those guesses can be made. "With a simple cryptographic hash function [like] SHA256, MD5, etcetera, an attacker might be able to make 10 million guesses per second on a single hash.

But with the 'slow hashing' functions, that might be reduced to a few tens of thousands of guesses per second," he says. The decreased rate gives users a window to change their passwords; yet even that may not have helped Yahoo! "But after four years, the details of the hashing scheme don’t really matter.

Any guessable password will have been guessed by now," he says. Not easy Yahoo!, like so many other companies offering free technology services, wants to attract the highest possible number of subscribers and has been criticised for perceived attempts to kneecap fleeing users. That mindset may have dissuaded the company from more efficiently jettisoning MD5 hashing for passwords prior to the 2013 pillaging. "The only practical way to speed up the conversion process (to bcrypt) is to force a password reset, maybe across the board, but more likely on a web property by web property basis," says noted cryptologist and director of the Open Crypto Audit Project's Kenneth White. "And therein lies the problem: there is often a very real tension between the business to be able to claim the highest user count, versus the reality that a years-old email reminds millions of people to log in to an account they had long ago forgotten." Using Yahoo! to find Yahoo! MD5 hashes, here revealing 'Password1'.
Image: Ty Miller. An email shipped to users asking them to log in so their passwords may be upgraded from MD5 hashing to bcrypt risks a "virtually overnight mass exodus of users" and a social media complaint storm that sends more rats from the burning Palace, he says. Bcrypt is the powerful hashing function designed to slow decryption attempts while minimising legitimate use performance overheads, and is favoured, along with PBKDF2 (Miller prefers the latter with hashes bearing 100,000 iterations), by each of the security boffins The Register has spoken to for this story, and many more in the broader security community including OWASP . Yet migrating to the top notch function is not as simple as just "switching to bcrypt", White says. A bootstrapping process can be followed, but it requires users to log in for bcrypt or PBKDF2 to be called and saved to a new column. Moreover, White says Yahoo! is a patchwork of web properties bearing decades-old Perl, PHP, and C code and so cannot be compared to the ease of upgrading a purpose-built modern web app. "Consider the legacy managed business mail systems," White says. "The myriad e-commerce shopping cart apps, ad accounts, to say nothing of Flickr, Yahoo! IM, and the hundreds of millions of webmail users who hadn't logged in for years, and you begin to see the scope of the engineering challenge." Van der Stock, acknowledging his outsider's position, reckons Yahoo! should immediately deploy two factor verification for all of its services, and again reset passwords, noting that the use of mere usernames and passwords puts users at "serious risk" and that leaving accounts exposed would be a "serious breach of trust". yahoo pic.twitter.com/LSxdm1wNdx December 15, 2016 Yahoo! could take a leaf from Microsoft's Xbox Live endeavours and deploy similar authentication smarts, if it has not already done so. "… I would strongly recommend some sort of real time authentication intelligence around compromised accounts, so that the authentication system itself assigns a risk score to logins to ensure that unusual patterns of abuse, such as brute force attacks, logging in from a distant country, or popping out of multiple IPs is blocked or alerted to the user for further action." Burning questions remain, not least how it took the technology giant three years to disclose that such a massive share of its accounts have been breached. "It's baffling why it's taken so long to fully scope and disclose the extent of their breach," White says. ® Sponsored: Want to know more about PAM? Visit The Register's hub

AdultFriendFinder hacked: 400 million accounts exposed

Enlargereader comments 29 Share this story AdultFriendFinder has been hacked, revealing the account details of more than 400 million people who would undoubtedly prefer to keep their identities private on the "world's largest sex and swinger community" site. The hacked database—which appears to be one of the largest ever single data breaches in history—apparently contains account details for numerous adult properties belonging to the California-based Friend Finder Network, and includes customers' e-mail addresses, IP addresses last used to log-in to the site, and passwords. According to data breach notification site LeakedSource.com, the passwords were either kept in plain text format, or used the largely discredited SHA1 hashing algorithm.
It claimed to have cracked 99 percent "of all available passwords" which "are now visible in plaintext." Around 339 million accounts were stolen from AdultFriendFinder.com. More than 15 million accounts which users thought they had deleted but which weren't purged from the database were also hit.

Beyond that, 62 million accounts from Cams.com and seven million from Penthouse.com were compromised alongside smaller amounts from other properties. Penthouse.com was sold to Penthouse Global Media in February. The exposed data revealed some interesting habits among swingers: for example, Hotmail is the most popular e-mail account among users of the site, closely followed by Yahoo mail. According to CSO Online, the hack was made via a Local File Inclusion exploit, which "allow an attacker to include files located elsewhere on the server into the output of a given application." In a statement to ZDNet, Friend Finder Networks confirmed that the site had a vulnerability, but dodged attempts to confirm the breach.

Diana Ballou, its vice president and senior counsel, said: Over the past several weeks, FriendFinder has received a number of reports regarding potential security vulnerabilities from a variety of sources.
Immediately upon learning this information, we took several steps to review the situation and bring in the right external partners to support our investigation. While a number of these claims proved to be false extortion attempts, we did identify and fix a vulnerability that was related to the ability to access source code through an injection vulnerability. FriendFinder takes the security of its customer information seriously and will provide further updates as our investigation continues. This is the second data breach at Friend Finder Network in the past 18 months.

The first, in May 2015, uncovered personal details for 3.5 million active users of the site, including questions on their sexual preferences—data which apparently wasn't compromised this time around. This post originated on Ars Technica UK

412 million FriendFinder Network accounts said to be exposed in hack

Over 412 million accounts on dating and entertainment network FriendFinder Networks have reportedly been exposed, the second time that the network has been breached in two years, according to a popular breach notification website. The websites that have been breached include adultfriendfinder.com, described as the “world’s largest sex and swinger community,” which accounted for over 339.7 million of the 412 million accounts exposed, LeakedSource said Sunday. Other network sites that had user accounts exposed were cams.com with 62.6 million exposed, penthouse.com with 7 million, stripshow.com with 1.4 million, icams.com with about 1 million and an unidentified website adding 35,372 users whose accounts were exposed. The sites were hacked in October through a local file inclusion vulnerability on FriendFinder Networks that was reported at about the same time by a researcher.
Soon after disclosing the vulnerability, the researcher, who used the Twitter handle 1x0123 and is also known as Revolver, stated on Twitter that the issue was resolved, and “...no customer information ever left their site,” according to CSO’s Salted Hash. FriendFinder did not immediately comment.

The network, however confirmed to ZDNet that it identifed and fixed a vulnerability that “was related to the ability to access source code through an injection vulnerability.”  LeakedSource said it found that passwords were stored in plain visible format or using the weak SHA1 hashed (peppered) algorithm, increasing the possibility of their misuse. LeakedSource claimed it had cracked over 99 percent of all the passwords from the databases to plaintext. It also found that about 15 million users had an email in the format of: email@address.com@deleted1.com, suggesting that information on users who earlier tried to delete their accounts was still around. The FriendFinder Networks hack, if confirmed, would outstrip that of Myspace in its impact.

The exposure of an estimated 360 million accounts of Myspace users was reported earlier this year.

The FriendFinder hack also has the potential of being more embarrassing for a number of users, because of the sensitive transactions on its sites.

Yahoo Tells SEC It Knew About Data Breach in 2014

Yahoo fessed up in its latest SEC filing that it knew in 2014 that attackers were on its network and stole information from 500 million accounts. The breach was disclosed in September and Yahoo blamed state-sponsored attackers, a claim that was challenged by some experts who instead said a criminal outfit was behind the attack and may have sold some of the data to an Eastern European government. The SEC filing also contains a confirmation from Yahoo that Verizon’s multibillion-dollar acquisition of Yahoo’s core business could be in jeopardy, and that Verizon could seek to terminate or renegotiate the terms of the sale.
Verizon executive vice president Marni Walden said at a Wall Street Journal event 10 days ago that it was still moving forward with the acquisition, but according to the Journal, stopped short of saying that it would not put a halt to the deal if necessary. “What we have to be careful about is what we don’t know,” Walden said. “We’re not going to jump off a cliff blindly so we need to have more information before we can determine, but strategically the deal still makes a lot of sense to us.” Yahoo said that claims in July from hackers that 200 million account credentials were available for purchase on an underground hacker forum prompted a deeper investigation into the security of its network and a broader look at the 2014 intrusion. “In addition, the forensic experts are currently investigating certain evidence and activity that indicates an intruder, believed to be the same state-sponsored actor responsible for the Security Incident, created cookies that could have enabled such intruder to bypass the need for a password to access certain users’ accounts or account information,” Yahoo told the SEC. It added that on Monday, law enforcement shared evidence provided by a hacker that is allegedly legitimate Yahoo account information; Yahoo said it is investigating. Yahoo told the SEC that the stolen information included names, email addresses, telephone numbers, dates of birth, hashed passwords and encrypted and unencrypted security questions and answers. Yahoo reaffirmed earlier statements that no payment card data or bank account information was stolen; that information, Yahoo said, was not stored on the systems that were accessed. News of the Yahoo breach surfaced at a time when large-scale password dumps were being disclosed in waves. Most of the Yahoo passwords were hashed using bcrypt, but some were secured with MD5, a long-outdated algorithm that is considered unsafe and has been deprecated in many corners. Security company Venafi said in late September that data collected from its internal certificate reputation service indicates that Yahoo’s cryptographic practices were a mixed bag of outdated hashes and self-signed certificates, none of which are entirely secure. Beyond simply the use of SHA1 and MD5, for example, Venafi said that it found a wildcard certificate with a five-year expiration data, much longer than the standard 12- to 18-month standard.
It added that 27 percent of certificates on external Yahoo sites were in place since January 2015 and that fewer than 3 percent were issued in the previous 90 days. Weakened certificates have been attacked in the past to redirect traffic or pose as a Yahoo site and steal credentials or intercept traffic. Congress soon interjected and wrote a letter to CEO Marissa Mayer demanding to know why it took Yahoo two years to disclose the attack, expressing dismay that users’ data has been exposed during that period of time.
Vermont Senator Patrick Leahy called the situation “unacceptable.” The breach, Yahoo told the SEC, has also given birth to 23 class-action lawsuits filed against the company making claims of harm and seeking damages and relief. Yahoo said it has spent $1 million in the third quarter of this year related to its breach investigation, but said the breach did not materially impact its business or cash flow for the quarter. Yahoo also admitted in its filing that it does not have cybersecurity liability insurance.

LinkedIn says hacking suspect is tied to breach that stole 117M...

EnlargeKlaus with K reader comments 3 Share this story An alleged Russian hacker arrested in the Czech Republic following an FBI-coordinated tip-off is suspected of taking part in a 2012 breach of LinkedIn that resulted in the theft of more than 117 million user passwords, representatives of the professional networking site said Wednesday. "Following the 2012 breach of LinkedIn member information, we have remained actively involved with the FBI's case to pursue those responsible," company officials said in a statement. "We are thankful for the hard work and dedication of the FBI in its efforts to locate and capture the parties believed to be responsible for this criminal activity." Word of the arrest came on Tuesday evening in a brief statement issued by Czech Republic officials. It said an unnamed man was arrested in Prague on suspicion of committing unspecified hacks on targets located in the US. The raid was carried out in collaboration with the FBI. According to The New York Times, the suspect was captured on October 5, about 12 hours after authorities learned he was in the country. His arrest was kept a secret until Tuesday "for tactical reasons," the paper reported. A video of the raid released by police is here: [embedded content] Russian hacking suspect arrested by Czech police A 2012 hack on LinkedIn is believed to have resulted in the theft of data for more than 117 million user passwords and corresponding e-mail addresses. While the passwords were scrambled using what's known as one-way cryptographic hashing, the underlying function—SHA1—was so weak that it was trivial for people to undecipher all but a small fraction of them, security researchers have said. LinkedIn has since transitioned to a much stronger form of protection. The user credentials were available for sale online. Because so many people use the same or very similar passwords to safeguard multiple accounts, the list—and dozens like it from breaches involving other sites—led to even more account compromises. The discovery of the LinkedIn data in May came almost four years after the underlying 2012 breach first came to light. At the time, researchers were aware of only 6 million passwords compromised by the hack. The Russian suspect was apprehended in a raid at a hotel. Before his arrest, he drove around Prague in a luxury car with a girlfriend, the NYT said, citing police. He didn't resist arrest, but it was widely reported that he was briefly hospitalized after collapsing. FBI officials have confirmed the arrest but have yet to provide details. This post will be updated as warranted.

CryPy: ransomware behind Israeli lines

A Tweet posted recently by AVG researcher, Jakub Kroustek, suggested that a new ransomware, written entirely in Python, had been found in the wild, joining the emerging trend for Pysomwares such as the latest HolyCrypt, Fs0ciety Locker and others. This Python executable comprises two main files. One is called boot_common.py and the other encryptor.py.

The first is responsible for error-logging on Windows platforms, while the second, the encryptor, is the actual locker. Within the encryptor are a number of functions including two calls to the C&C server.

The C&C is hidden behind a compromised web server located in Israel.

The Israeli server was compromised using a known vulnerability in a content management system called Magento, which allowed the threat actors to upload a PHP shell script as well as additional files that assist them in streaming data from the ransomware to the C&C and back. A notable point to mention is that the server was also used for phishing attacks, and contained Paypal phishing pages.

There are strong indications that a Hebrew-speaking threat actor was behind these phishing attacks.

The stolen Paypal credentials were forwarded to another remote server located in Mexico and which contains the same arbitrary file upload technique, only with a different content management. It is a known practice for attackers to look for low-hanging fruit into which they can inject their code in order to hide their C&C server. One such example was the CTB-Locker for web servers reported last March. ICON:SHA1: ad046bfa111a493619ca404909ef82cb0107f012MD5: 8bd7cd1eee4594ad4886ac3f1a05273bSize: 5.22 MBType: exe To reverse the executable one should first conduct a number of checks using a convenient debugger.

The universal steps for unpacking an unknown packer start with trying to set a memory breakpoint on popular functions that packers use, such as VirtualAlloc. If the breakpoint hits, the next step involves switching to user mode and setting a hardware breakpoint (on access).

That will assist in inspecting where exactly the program initializes the memory block.
In most cases, an executable magic header (MZ) should appear in the memory block. However, in this case the following screenshot shows the readable data that was allocated to that memory block: After the data was allocated to the memory block, it appeared to be using VM code (python vm) to execute the code.

For those who are not familiar with the term, VM code is the process of creating new instruction sets based on the author’s request.

The CPU uses those instruction sets to understand the instructions. py2exe simply converts the code to x86 assembly, the architecture used on the CPU for communication, and, by loading a python DLLs, loads all the modules into the memory. We found that the executable file was generated using py2exe.

The first indicator was a stack PUSH instruction to add the string – PY2EXE_VERBOSE: a module that compiles Python scripts to Microsoft Windows executables. PY2EXE module string disclosure A module that reverse the operation of the py2exe can be found in Github and is called unpy2exe.

This module will revert the executable back to its origin Python compiled code (i.e. .pyc file).

From that format, another step will be required to fully revert to the original code. We randomly chose to use EasyPythonDecompiler. Fully decompiled Python scripts In it’s current state, the executable fails to encrypt the file system, simply because the threat actors must have migrated from the current server to another.

By doing so, they deleted the remaining traces of the PHP files they used for data collection from a victim’s machine.

The following is the log file that is generated upon exception: Error log file being generated by the boot_common.py The scripts in Python use two files: Name: boot_common.pymd5: dfd6237e26babdbc2b32fa0d625c2d16SHA1: 38fe7b64113e467375202e2708199b45a22b25a6Size: 3KbThis file throws an “error” to show that the program failed to execute if there is a problem. Name: encryptor.pymd5: 1ed3f127a0e94394ef049965bbc952efSHA1: 73122712b4563fadcc9871eb3fe0efdcf70bb608Size: 9KbThis script encrypts the victim’s files. The ransomware disables the following features from the compromised machine by overwriting the registry policies it disables Registry Tools, Task Manager, CMD and Run. list of registry manipulations It then continues with changing bcdedit to disable recovery and ignore boot status policy. Upon successful encryption, the ransomware will encrypt the following file extensions:*.mid, *.wma, *.flv, *.mkv, *.mov, *.avi, *.asf, *.mpeg, *.vob, *.mpg, *.wmv, *.fla, *.swf, *.wav, *.qcow2, *.vdi, *.vmdk, *.vmx, *.gpg, *.aes, *.ARC, *.PAQ, *.tar.bz2, *.tbk, *.bak, *.tar, *.tgz, *.rar, *.zip, *.djv, *.djvu, *.svg, *.bmp, *.png, *.gif, *.raw, *.cgm, *.jpeg, *.jpg, *.tif, *.tiff, *.NEF, *.psd, *.cmd, *.class, *.jar, *.java, *.asp, *.brd, *.sch, *.dch, *.dip, *.vbs, *.asm, *.pas, *.cpp, *.php, *.ldf, *.mdf, *.ibd, *.MYI, *.MYD, *.frm, *.odb, *.dbf, *.mdb, *.sql, *.SQLITEDB, *.SQLITE3, *.asc, *.lay6, *.lay, *.ms11 (Security copy), *.sldm, *.sldx, *.ppsm, *.ppsx, *.ppam, *.docb, *.mml, *.sxm, *.otg, *.odg, *.uop, *.potx, *.potm, *.pptx, *.pptm, *.std, *.sxd, *.pot, *.pps, *.sti, *.sxi, *.otp, *.odp, *.wks, *.xltx, *.xltm, *.xlsx, *.xlsm, *.xlsb, *.slk, *.xlw, *.xlt, *.xlm, *.xlc, *.dif, *.stc, *.sxc, *.ots, *.ods, *.hwp, *.dotm, *.dotx, *.docm, *.docx, *.DOT, *.max, *.xml, *.txt, *.CSV, *.uot, *.RTF, *.pdf, *.XLS, *.PPT, *.stw, *.sxw, *.ott, *.odt, *.DOC, *.pem, *.csr, *.crt, *.key and wallet.dat to encrypt crypto currency wallets The files are encrypted using AES with CBC mode for the following paths: D:\\E:\\[userhome]\\contacts[userhome]\\Documents\\[userhome]\\Downloads\\[userhome]\\Favorites\\[userhome]\\Links\\[userhome]\\My Documents\\[userhome]\\My Music\\[userhome]\\My Pictures\\[userhome]\\My Videos\\F:\\..Z:\\*userhome - The current user home directory When the encryption step is done, the ransomware will remove the restore points and write the README_FOR_DECRYPT.txt file and execute it.

The following screenshot is the ransom note: CryPy Ransomware Note embedded in the Python code The threat actor behind the attack asks the victim to contact it via email, and to send a request to the following two email addresses to receive the decryption program:(1) m4n14k@sigaint[.]org(2) blackone@sigaint[.]org Note that the ransom note contains mistakes, implying that it has been written by a non-English speaker.

First, the headline is missing a ‘T’ in “IMPORTAN INFORMATION”.
Second, the sentence “Decrypting of your files…” is syntatically wrong. Native speakers will be able to find additional mistakes. The threat actor claims that files will be deleted every 6 hours, which reflects the approach of more advanced ransomwares. However, it forgets to mention proof of decryption or a channel that can be used in cases where the payment process is not responsive.

This points to the executable being at an early stage of development. The ransomware survives a reboot by adding the following keys to the registry:Software\\Microsoft\\Windows\\CurrentVersion\\Run regkey Software\\Microsoft\\Windows\\CurrentVersion\\Run subkey Adobe_ReaderX data %TEMP%\\mw.exe regkey Software\\Microsoft\\Windows\\CurrentVersion\\Run subkey explore_ data [userhome]\\Appdata\\local\\DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.exe The code for adding the values to the registry is located on the functions autorun() and autorun2(). Right before launching the ransom note, the script calls a delete_shadow() function that takes no arguments, and simply executes the following command line code to remove all shadow copies and prevent recovery from backup: os.system("vssadmin Delete shadows /all /Quiet") Lastly, the file calls autorun2() fuction that copies the ransomware from its current location to C:\\Users\\\\AppData\\Local with hardcoded name:DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.exe The ransomware hides behind an Israeli web server which was compromised using Shell script arbitrary upload written in PHP.

The compromise and upload were possible because the server carried a vulnerable Magento CMS. The executable transfers data over an unencrypted HTTP channel in clear-text.

This allows for easy traffic inspection using a network listener.

The following screenshot is the traffic being sent to the server: Inspecting the Magento exploit and the compromised server, we found that the origin of the upload carries the title Pak Haxor – Auto Xploiter and the email ardiansyah09996@gmail[.]com and that the file was uploaded in August 2016, which aligns with the case in subject.

The following screenshot reveals how attackers are using massive exploiters that scan for vulnerable web servers and exploit the vulnerability, which they later visit to expand their control over the server: Part of such an exploitation technique is dropping additional PHP scripts to refine a more sophisticated attack, such as the CryPy ransomware. A call to one of those scripts script can be found hard-coded in the CryPy Python code, in the form of a GET request.

The request is sent with two parameters to a script that was uploaded using the Auto Xploiter and carries the name victim.php.

By reviewing the Python code it is easier to understand the type of data being presented in Base64 encoding format. As seen in the screenshot above, the configurl parameter accepts a URL querystring where the victim_info input value of the info parameter is derived from the platform module. uname() is used when one wants to return a tuple of system, node, release, version, machine and processor values.

These are encoded with Base64. The next parameter is ip which contains the socket.gethostname() which basically collects an IP address. The querystring is then sent to urllib.urlopen(), which will send a GET request to the selected server and read the reponse content into glob_config. The response contains a JSON format payload which is checked for the following keys:x_ID – the victim’s unique ID to request their decryption keys after payment.x_UDP – Not used; perhaps saved for future use.x_PDP – Not used; perhaps saved for future use. The second call is implemented in a function called generate_file() which is responsible for fetching a unique key for each file before encryption. We have seen in recent lockers that, in order to demonstrate trust and integrity, the victim is able to decrypt one/two files before processing the payment.

This proves decryptor validity.
In order to randomly choose a file, the attacker must first generate a unique token for each one.

The second PHP script found in the code is savekey.php which is described in the following screenshot and is suspected to have the C2 IP in it.
It was however deleted long before we were able to reach it. As for the first call, the second sends two parameters.

The first is the file’s name and the other is the victim ID.
In return, the server responds with two keys:X – Unique key after encryption which will be appended to the file’s header.Y – New filename which will be stored instead of the previous one. These parameters are then sent to an encryption routine, along with the file’s original name. REG Keys HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\SystemHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\ExplorerHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\explore_HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\Adobe_ReaderX Domains hxxp://www.baraherbs[.]co.il/js/owebia/victim.phphxxp://www.baraherbs[.]co.il/js/owebia/savekey.php Hashes 8bd7cd1eee4594ad4886ac3f1a05273b crypy.exe1ed3f127a0e94394ef049965bbc952ef encryptor.py Emails m4n14k@sigaint[.]comblackone@sigaint[.]com