Learn Penetration Testing And Ethical Hacking Online.


  • Facebook
  • Popular Posts

    Advanced XSS attacks and exploitation examples

    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 "victima.com"
    • Automatic injection (test all vectors)
    xsser -u "victima.com" --auto
    • Injection with customized payload
    xsser -u "victima.com" --payload = "> "
    • Operation in local
    xsser -u "victima.com" --Fp = " "
    • Remote operation
    xsser -u "victima.com" --Fr = " "
    • Using dorking
    xsser -d "inurl: admin / echo" --De "google" --Fp = " "
    • Using proxy and HTTP header spoofin Refer
    xsser -u "victima.com" --proxy http: // localhost: 8118 --refer "666.666.666.666"
    • Use of hexadecimal encoding
    xsser -u "victima.com" --Hex
    • Multiple injection with 5 threads and coding with mutation
    xsser -u "victima.com" --Cem --threads "5"
    • Using the crawler with depth 3 and 4 pages
    xsser -u "victima.com" -c3 --Cw = 4
    • Exploitation through POST
    xsser -u "victima.com" -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.
    Continue Reading
    Phishing NG. Bypassing 2FA with Modlishka. and Evilginx 2

    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 github.com/drk1wi/Modlishka 

    $ cd $ GOPATH / src / github.com / 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 breakdev.org on Vimeo . 


    #Instalación de dependencias
    pacman --needed -Syu go dep git
    #Descarga de evilginx2
    go get -u github.com/kgretzky/evilginx2
    #Compilación de evilginx2
    cd $HOME/go/src/github.com/kgretzky/evilginx2
    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).

    https://github.com/ drk1wi / Modlishka 
    Continue Reading