March 2019
The trail of documents leaked by Wikileaks continues. After having published almost 9,000 documents about "Vault 7" , which contain information on spy tools used in Smart TVs, smartphones, computers and even cars, Wikileaks returns to the attack with details about how the Mac and iPhone have been spied by the CIA for several years .

WikiLeaks leaked 12 new documents that provide a more in-depth look at the hacking techniques that the CIA allegedly used to hack Apple devices, such as Macs and iPhones. This leak, which WikiLeaks identifies under the code name Dark Matter, is part of a series of dumps called Vault 7, which WikiLeaks claims are hacking tools obtained from the CIA. 

The first leak, called Year Zero, came to light in early March and included wiki pages from the CIA intranet, with documentation for some of the CIA's cyber weapons.

In this original leak, documents related to the CIA's supposed arsenal of OS X and iOS hacking tools were included. Today's Dark Matter dump provides 12 new documents that contain much more information about those tools. 

Wikileaks had promised that those 9,000 documents were just the beginning, and that's how it was. Today they are unveiling the project "Dark Matter", which belongs to "Vault 7" and which consists of espionage tools for Apple devices. These would be able to directly infect the computer's firmware, which means that neither reinstalling the operating system would eliminate the infection.

Dark Matter


For example, Sonic Screwdriver is a hacking tool that CIA operators can deploy from an Apple Thunderbolt adapter to Ethernet.

This hacking tool allows the operator to execute malicious code from a USB, CD, DVD or portable hard drive, during the boot of a Mac, even if the firmware of the Mac is password protected . 

Another tool, called DarkSeaSkies , "is an implant that persists in the EFI firmware of an Apple MacBook Air computer, installs a Mac OSX 10.5 implant and executes a user space implant." 

In addition, DarkSeaSkies includes smaller components. 

DarkSeaSkies consists of three different tools:

  • 1. DarkMatter : An EFI controller that persists in the firmware and installs the other two tools.
  • 2. SeaPea: A Mac OSX implant for the space of the kernel that executes, and provides stealth and privilege to the implants of the user's space.
  • 3. NightSkies : A Mac OSX implant for the user's space that goes to a listening post and provides control and command.

The other two tools, Triton and DerStarke , are related. Triton is an automated implant for Mac OS X, while DerStarke is a diskless, EFI-persistent version of Triton. 

As you can see, all the tools are directed to the EFI / UEFI (Unified Extensible Firmware Interface ) specification, which is a software component that helps with the initialization of hardware components while the operating system, the old BIOS, is started. 

The placement of malicious code in EFI / UEFI assures an attacker the possibility of executing that malicious code on each boot, even if users re-install their operating system.

"Sonic Screwdriver"

These new documents detail how the CIA has been infecting MacBook Air devices over the past few years using something they have dubbed "Sonic Screwdriver", yes, in honor of the famous Doctor Who weapon. This tool can be placed on all types of USB devices, peripheral cables and adapters , such as the Thunderbolt to Ethernet that is widely used in this notebook, which when connected to the computer install spyware programs, regardless of whether it is protected by a password. 

This malicious code is installed during the boot of the computer and is stored permanently in the kernel, so access credentials or some other data is not needed, and it remains even if the entire device is formatted. The worrying thing about this is that the documents reveal that the CIA has continued using this tool during 2016, and they have even updated it for new Mac computers, regardless of whether they are portable or desktop. 

Within "Dark Matter" we also find other spy initiatives such as "NightSkies 1.2", which is used since 2008 to infect new iPhoneIt should be noted that this tool, which is a "beacon / loader / implant" has also been updated over time, but unlike the Mac, it is designed to be installed on new devices. This means that the CIA has intercepted iPhone orders and directly attacked production lines to place this malware on the devices, something they have been doing at least since 2008. 

Wikileaks notes that the Mac tool is very specific for well-located targets, where They have placed modified cables and adapters with the idea of ​​spying on certain groups in different parts of the world. But the case of the iPhone is different, since here the entire production chain had to be attacked, which means that many iPhone have this malware installed without the user knowing.

CIA pointed to iPhones one year after its launch

Although it does not appear prominently in the description of the tool, the DarkSeaSkies NightSkies module also comes with support for iPhone devices. 

A July 2008 document, one year after the launch of the iPhone , details how NightSkies could provide "upload, download and execution capability" on Apple iPhone 3G v2.1 devices. 

The document says that CIA operators needed physical access to install the NightSkies implant , but once installed, NightSkies would only work when it detected user activity on the device, hiding traffic between the user's actions. This provides an attacker sponsored by the state as the CIA with the advantage that all APTs want more, which is stealth.

Although the leaked documents do not mention this detail, WikiLeaks states that NightSkies "is expressly designed to be physically installed on fresh factory iPhones," and that "the CIA has been infecting the iPhone supply chain of its targets since at least 2008. " 

At the time of writing the CIA has never officially recognized the authenticity of the leaked WikiLeaks documents. However, motherboard pointed out yesterday that the Agency had asked a judge not to allow documents downloaded by WikiLeaks in a case, as they were "classified content", accidentally acknowledging their authenticity. 

More information | Wikileaks

It is not clear if the CIA has the ability to hackmore modern products and security measures much stricter than those of then, although it is obvious that this is one of your goals. 

It is also clear that Apple is not particularly happy with these revelations, judging from the statement issued by the Cupertino firm:

We have made a preliminary assessment of the WikiLeaks revelations this morning. Based on our initial analysis, the vulnerability only affected the iPhone 3G and was solved in 2009 when the iPhone 3GS was launched. Additionally, our preliminary assessment shows that the alleged vulnerabilities were resolved in all Macs launched after 2013.

We have not negotiated with WikiLeaks to obtain any information. We have provided them with instructions to deliver any information they desire under our normal process under our standard terms. At the moment we have not received any information from you that is not in the public domain. We constantly defend the security and privacy of our clients, but we do not condone the theft or we coordinate with those who threaten to harm our users.

The tone used by Apple is not the usual one. Partly because, although WikiLeaks has offered to collaborate with the companies affected by these tools to cover their security holes, the organization has indicated that it will only do so if the affected firms accept a series of undisclosed conditions. 
An article from  where XSS attacks are discussed beyond the reflected and persistent types. It is intended to provide a broader view of the possibilities within this type of attacks as well as the conditions for their occurrence. It also explores and operates the XSSer tool for launching attacks of this type.
Advanced XSS attacks and exploitation examples


Cross Site Scripting (XSS)

  • The vulnerabilities of XSS included any attack that allows executing "scripting" code in the context of another website. 
  • They can be found in any application that has as its ultimate goal, to present the information in a web browser.
  • Usually the input data that is used in some applications is not validated correctly, allowing to send a malicious script to the application.
  • To work they need an entry point, which is usually the forms. 
  • Through an XSS attack, you can hijack accounts, change user settings, access restricted parts of the site, modify site content, etc.

Types of XSS attacks

Direct Attacks
  • The attack of direct form of XSS (also called persistent XSS ), appears when the attacker manages to embed malicious HTML code, directly in the Web sites that allow it.
  • It works by locating weak points in the programming of HTML filters if they exist, to publish content.
  • This type of attack is usually the most common, and the code of the attacker is based on HTML tags (of type or
  • The result shows a window with the text "hello-world".
  • This vulnerability is often used to steal sessions and phishing.


It is a framework that allows:
  • Detect vulnerabilities of type XSS
  • Explore these vulnerabilities locally or remotely.
  • Report in real time the vulnerabilities found.
Among its main features include:
  • Graphic interface
  • Dorking
  • Support for GET and POST (this is important since in tools treated in previous articles you could only perform injections with GET).
  • Crawling
  • Proxy
  • Heuristic analysis
  • Preconfigured exploits
  • Export options.
  • Different bypassers to evade filters
Types of injections allowed:
  • Classic XSS (execution of code in an embedded script)
  • Cookie Injection
  • Cross Site "Agent" Scripting
  • Cross Site "Refer" Scripting
  • Injections in "Data Control Protocol" and "Document Objetct Model"
  • HTTP Response Splitting Induced


  • Basic injection
xsser -u ""
  • Automatic injection (test all vectors)
xsser -u "" --auto
  • Injection with customized payload
xsser -u "" --payload = "> "
  • Operation in local
xsser -u "" --Fp = " "
  • Remote operation
xsser -u "" --Fr = " "
  • Using dorking
xsser -d "inurl: admin / echo" --De "google" --Fp = " "
  • Using proxy and HTTP header spoofin Refer
xsser -u "" --proxy http: // localhost: 8118 --refer "666.666.666.666"
  • Use of hexadecimal encoding
xsser -u "" --Hex
  • Multiple injection with 5 threads and coding with mutation
xsser -u "" --Cem --threads "5"
  • Using the crawler with depth 3 and 4 pages
xsser -u "" -c3 --Cw = 4
  • Exploitation through POST
xsser -u "" -p "target_host = name & dns-lookup-php-submit-button = Lookup + DNS"


 It is a somewhat more intuitive option to use XSSer.

The tool starts with:

xsser --gtk
Thanks to the use of the "Wizard Helper" guided exploitation can be carried out much more easily than by command line


When talking about XSS, we usually keep in mind the two most basic types: reflected or persistent; but there are many more.


Take advantage of a modified active content to take control of a DOM, which allows you to control the flow of that object, but always through its API. This on the one hand makes it easier to avoid anti-XSS filters but on the other it has certain limitations against basic attacks. The elements vulnerable to DOM XSS are usually: "document.location", "document.URL", "document.refer"


It uses the Actionscript language used to program flash applications with the intention of loading unwanted elements into the page. It can be used in combination with DOM XSS to load elements from the domain of the original object. It could even be used to execute an ActionScript in a SWF file, although it is also possible to execute code embedded in an img type tag.


It is an exploitation option that uses a second web to launch the attack on the vulnerable web. In this case the user would open the web page that contains the vulnerable code and this would interact with the vulnerable web in order to carry out the same type of actions as an XSS attack.


The malicious code is injected into an iframe that will be injected in a hidden way in the vulnerable web.


Achieves an escalation of zone privileges in IE due to a vulnerability. The relevance of this attack lies in the possibility of executing a privileged command from an area without privileges. 
IE establishes the following zones: Internet, Intranet, Secure sites, Restricted sites, Local. Therefore this attack is only effective against Windows systems with a vulnerable version of IE.


It allows to carry out the attack thanks to the modification of the value of "User-Agent" in the header of a web application. In the case that some value is obtained dynamically it is possible to modify this value in the browser of the attacker so that when executing the application and acquiring said value, the attack is carried out.


It uses a for type instruction within a script embedded in the page to prevent users from accessing the content. Access to the application is blocked through an infinite loop of alerts. 
To cause the denial in the server instead of the client, it is enough to use a similar logic against said server. In this case, it is usual to exhaust the resources of the server by launching too many requests.

Flash! Attack

Another attack based on Flash that uses Macromedia Flash Plugin and Active X Control to inject malicious code. This code would allow stealing cookies every time a user plays the infected content.

Induced XSS

Unlike the other XSS attacks, this attack takes place on the server side. The possibilities are therefore greater, since the complete HTML content can be altered in a web thanks to the modification of the HTTP response headers of the server. In this case the attacker forces the server to produce a response that will be interpreted as two by the victim, the first with the injection itself and the request to the server and the second as camouflage for the first.

Image Scripting

It exploits the reading of the binary parameters of an image by a server that has not been adequately protected. For this attack to be successful the attacker must upload the image to the server, which will later be accessed by the victim.
The Polish security researcher, named Piotr Duszyński, developed a new tool for penetration tests called  Modlishka, which according to his own words "allows phishing campaigns to be carried out at a higher level and with minimum effort". The tool can be used to impersonate even popular websites like Yahoo or Gmail. For the author of the tool, the only really effective measure is the use of physical keys (hardware)  Fido -  U2F  to safely use the double factor of 2FA authentication . It is not the first tool capable of jumping double factor 2FA since  Evilginx2  is a good proof of that .

Modlishka is a 
reverse proxy tool written in the "Go" programming language
 . The software reinforces the fact that social engineering is a serious threat and can not be treated lightly.

On the next page, I will briefly describe how this tool can be used to bypass most of the 2FA authentication schemes currently used.

Characteristics Modlishka

Some of the main features offered by this reverse proxy tool are: support for most double-factor authentication schemes; the only need to indicate to Modlishka which domain is targeted so that it is automatically manipulated without the need for website templates; absolute control of the source TLS traffic flow that passes through the victim's browser; possibility to easily configure possible phishing scenarios through the configuration options; removal of all encryption websites and security headers; collection of user credentials, among other functionalities.

  • Support for majority of 2FA authentication schemes (by design).
  • No website templates (just point Modlishka to the target domain - in most cases, it will be handled automatically).
  • Full control of "cross" origin TLS traffic flow from your victims browsers.
  • Flexible and easily configurable phishing scenarios through configuration options.
  • Pattern based JavaScript payload injection.
  • Striping website from all encryption and security headers (back to 90's MITM style).
  • User credential harvesting (with context based on URL parameter passed identifiers).
  • Can be extended with your ideas through plugins.
  • Stateless design. Can be scaled up easily for an arbitrary number of users - ex. through to DNS load balancer.
  • Web panel with a summary of collected credentials and user session impersonation (beta).
  • Written in Go.

Recently there were many rumors on this subject on the Internet, despite the fact that this technique has existed and has been exploited for quite some time.

Introduction of "Modlishka"

Through many years of experience in penetration testing, it has been found that "social engineering" is the easiest and most effective way to enter a customer's internal network. many APT groups think the same ... This is all because one definitely does not need to burn a 0-day exploit for all those sophisticated first-class security defenses that are protecting the perimeter, when emails are often few or far between. Telephone calls will work perfectly to compromise the internal infrastructure and the confidential data of the companies. 

Modlishka was written with the aim of making the second approach (phishing campaigns) as effective as possible.

This tool should be very useful for all penetration evaluators, who want to carry out an effective phishing campaign (also as part of their commitments to the red team).

Bypass 2FA

Note: This will be a sample configuration that will run locally on your computer. 

1. Download the tool

$ go get -u 

$ cd $ GOPATH / src / / drk1wi / Modlishka / /

2. Configure the 'autocert' plugin 

This step is necessary if you want to serve the page through a trusted TLS channel for the browser:

$ openssl genrsa -out MyRootCA.key 2048` 

$ openssl req -x509 -new -nodes -key MyRootCA.key -sha256 -days 1024 -out MyRootCA.pem

Replace the const CA_CERT variable with the contents of the MyRootCA.pem file and the CA_CERT_KEY constant with the contents of MyRootCA.key in the 'plugin / autocert.go' file. 

Install and set the appropriate trust level for the CA 'MyRootCA' in the certificate store of your browser and you're done. 

3. Compile and launch "Modlishka"

$ make 

$ sudo ./dist/proxy -config templates / google.com_gsuite.json

The choice of an example service is based exclusively on its popularity and I think it is really well insured. As such, I am not trying to prove that this is not the case (especially because most services can be similarly oriented), but to raise awareness about risk by using one of the most popular services as proof of concept.

4. View the web page in your browser. 

Modlishka in action against an example 2FA (SMS) enabled authentication scheme:

Watch the video

Phishing with Modlishka (2FA bypass)  from  Piotr Duszynski  on  Vimeo .

The following link can be used to view your test page started. You can see how the "ident" parameter is hidden for the user in a first request:

The credentials collected can be found in the file "log" (log) or through one of the included plugins (this includes the impersonation of the session, although still in beta):

5. Customize your configuration 

If you like the tool. You can start adjusting the settings for your chosen domain. Modlishka can be easily customized through a set of available command-line options or JSON configuration files. 

Please check the wiki pages for more descriptions of the functionality.


Then the question arises ... is 2FA broken? 

No, not at all, but with a correct reverse proxy that goes to your domain through an encrypted and reliable browser, the communication channel can really have serious difficulties to realize that something is very wrong. 

Add to the equation different browser errors, which allow the impersonation of the URL bar, and the problem could be even greater ... 

Include the lack of knowledge of the user and, literally, mean deliver your most valuable assets to your adversaries in a silver plate. 

In the end, even the most sophisticated security defense systems can fail if there is not enough knowledge of the user and vice versa.

Currently, the only way to approach this problem, from a technical perspective, is to completely trust the 2FA hardware tokens, which are based on the U2F protocol. You can buy them easily online. However, remember that the correct knowledge of the user is equally important. 

In summary, you should:

  • use  U2F hardware tokens as its second authentication factor.
  • use password managers, which will ensure that the domain name in your browser is correct before you paste the password.
  • Constantly increase users' awareness of current social engineering techniques .

Why are you launching this tool? They believe that without a proof of concept that works, that really proves the point, the risk is treated as theoretical and no real measures are taken to address it.

Evilginx 2

It is a tool for MITM attacks that allows to evade even two-factor authentication 

Evilginx becomes a relay between the real website and the phishing user . The Phishing user interacts with the real website, while Evilginx captures all the data that is transmitted between the two parties. 

Evilginx, being the man in the middle, captures not only user names and passwords, but also captures sent authentication tokens, such as cookies . The captured authentication tokens allow the attacker to bypass any form of 2FA (two-factor authentication) enabled in the user's account (except U2F, more information about it later).

Even if the phishing victim has 2FA enabled, the attacker, equipped only with a domain and a VPS server, can take remote control of his account . It does not matter if 2FA is using SMS codes, mobile authentication application or recovery keys.

 Evilginx 2 - Next Generation of Phishing 2FA Tokens from on Vimeo . 


#Instalación de dependencias
pacman --needed -Syu go dep git
#Descarga de evilginx2
go get -u
#Compilación de evilginx2
cd $HOME/go/src/
sudo ./bin/evilginx -p ./phishlets/ 

After each successful login, the website generates an authentication token for the user's session. This token (or multiple tokens) is sent to the web browser as a cookie and saved for future use. From that point, each request sent from the browser to the website will contain that session token, sent as a cookie. This is how websites recognize authenticated users after successful authentication. They do not ask users to log in, each time the page is reloaded.

This session token cookie is pure gold for the attacker . If you export cookies from your browser and import them into a different browser, on a different computer, in a different country, you will be authorized and have full access to the account, without being asked for user names, passwords or 2FA tokens.

When the victim enters the credentials and is asked to provide a 2FA challenge response, they are still talking to the actual website, with Evilginx relaying the packets back and forth, sitting in the middle. Even while being a victim of a phishing attack, the victim will still receive the 2FA SMS code on his mobile phone, since he is talking to the actual website (only through a relay).

Sources: drk1wi / Modlishka