DAST vs SAST – Dynamic Application Security Testing vs Static

Outsmart Malicious Hackers


In security testing, much like most things technical there are two very contrary methods, Dynamic Application Security Testing or DAST and Static Application Security Testing or SAST.

Dynamic testing relying on a black-box external approach, attacking the application in its running state as a regular malicious attacker would.

Static testing is more white-box looking at the source-code of the application for potential flaws.

DAST vs SAST - Dynamic Application Security Testing vs Static


Personally, I don’t see them as ‘vs’ each other, but more like they compliment each other – it’s easy to have SAST tests as part of your CI/CD pipeline with tools like Code Climate.

DAST – Dynamic Application Security Testing

There are also pros and cons for each methodology, with DAST you aren’t bound to any particular technology or language – but on the downside, you are also limited to the parts of the application visible to the outside World.

An example of such a tool would be:

Wikto Scanner Download – Web Server Security Tool
Spaghetti Download – Web Application Security Scanner

It’s always good to simulate attacks from the outside with the kind of access a real World attacker would have, but it doesn’t give you full visibility of the potentials flaws in your system.

SAST – Static Application Security Testing

For SAST a big con is the toolset you are using needs to be language and even framework specific, for example tools we’ve mentioned before such as:

Brakeman – Static Analysis Rails Security Scanner
RIPS – Static Source Code Analysis For PHP Vulnerabilities

The upside to this is that you get full oversight of the app, libraries, dependencies and parts not visible to the outside World.

IAST – Interactive Application Security Testing

There is actually a combination of the two, a form of ‘greybox’ testing that combines the DAST approach with the the SAST tooling by installing a sensor into the application itself.

A great example of this is Acunetix AcuSensor which is installed on the back-end and relays information during the DAST testing phase (so it acts as a whitebox DAST component).

You can read more in depth about this subject here:

DAST vs SAST: A Case for Dynamic Application Security Testing


Topic: Security Software

Cr3dOv3r – Credential Reuse Attack Tool

Outsmart Malicious Hackers


Cr3dOv3r is a fairly simple Python-based set of functions that carry out the prelimary work as a credential reuse attack tool.

Cr3dOv3r - Credential Reuse Attack Tool


You just give the tool your target email address then it does two fairly straightforward (but useful) jobs:

  • Search for public leaks for the email and if it any, it returns with all available details about the leak (Using hacked-emails site API).
  • Then you give it this email’s old or leaked password then it checks this credentials against 16 websites (ex: facebook, twitter, google…) and notifies of any successful logins.

So how would this Credential Reuse Attack Tool work?

Just imagine this scenario:

  1. You check a targeted email with this tool.
  2. The tool finds the email address involved in a leak so you open the leakage link.
  3. You get the leaked password after searching the leak details.
  4. You return to the tool and enter the password to check if there’s any website the user uses the same password in it.
  5. PROFIT

How to use Cr3dOv3r for a Credential Reuse Attack

Another useful tool could be:

credmap – The Credential Mapper

You can download Cr3dOv3r here:

Cr3dOv3r-master.zip

Or read more here.


Topic: Hacking Tools

Mr.SIP – SIP Attack And Audit Tool

Outsmart Malicious Hackers


Mr.SIP was developed in Python as a SIP Attack and audit tool which can emulate SIP-based attacks. Originally it was developed to be used in academic work to help developing novel SIP-based DDoS attacks and defence approaches and then as an idea to convert it to a fully functional SIP-based penetration testing tool, it has been redeveloped into the current version.

Mr.SIP - SIP Attack And Audit Tool


Mr.SIP – SIP Attack Features

Mr.SIP currently comprises of four sub-modules named SIP-NES, SIP-ENUM, SIP-DAS and SIP-ASP. Since it provides a modular structure to developers, more modules will continue to be added by the authors and it is open to being contributed to by the open-source developer community.

  • SIP-NES needs to enter the IP range or IP subnet information. It sends SIP OPTIONS message to each IP addresses in the subnet and according to the responses outputs the potential SIP clients and servers on that subnet.
  • SIP-ENUM outputs which SIP users are valid according to the responses in that network by sending REGISTER messages to each client IP addresses on the output of SIP-NES.
  • SIP-DAS (DoS Attack Simulator) is a module developed to simulate SIP-based DoS attacks. It comprises four components: spoofed IP address generator, SIP message generator, message sender and scenario player. It needs outputs of SIP-NES (Network Scanner) and SIP-ENUM (Enumerator) along with some pre-defined files.
  • SIP-DAS basically generates legitimate SIP INVITE message and sends it to the target SIP component via TCP or UDP. It has three different options for spoofed IP address generation, i.e., manual, random and by selecting spoofed IP address from subnet. IP addresses could be specified manually or generated randomly. Furthermore, in order to bypass URPF filtering, which is used to block IP addresses that do not belong to the subnet from passing onto the Internet, we designed a spoofed IP address generation module. Spoofed IP generation module calculated the subnet used and randomly generated spoofed IP addresses that appeared to come from within the subnet.

There is also:

ohrwurm – RTP Fuzzing Tool (SIP Phones)
SIPcrack – SIP Login Dumper & Hash/Password Cracker
Sipflanker – Locate SIP (VoIP) Device Web Interfaces
SIP Proxy – VoIP Security Testing Tool
SIPVicious SIP Scanner – VoIP Hacking Security Auditing Tool

You can download Mr.SIP here:

Mr.SIP-master.zip

Or read more here.


Topic: Hacking Tools

Uber Paid Hackers To Hide 57 Million User Data Breach

Outsmart Malicious Hackers


Uber is not known for it’s high level of ethics, but it turns out Uber paid hackers to not go public with the fact they’d breached 57 Million accounts – which is a very shady thing to do. Getting hacked is one thing (usually someone f*cked up), but choosing as a company to systematically cover up a breach to the tune of $100,000 – that’s just wrong.

Uber Paid Hackers To Hide 57 Million User Data Breach


57 Million is a fairly significant number as well with Uber having around 40 Million monthly users, of course, it’s not the scale of Equifax with 143 Million (or more).

It includes both riders and 600,000 driver information, Uber says nothing fraudulent appears to have happened since the breach and compromised accounts are flagged in the system for extra monitoring.

By Now, the name Uber has become practically synonymous with scandal. But this time the company has outdone itself, building a Jenga-style tower of scandals on top of scandals that has only now come crashing down. Not only did the ridesharing service lose control of 57 million people’s private information, it also hid that massive breach for more than a year, a cover-up that potentially defied data breach disclosure laws. Uber may have even actively deceived Federal Trade Commission investigators who were already looking into the company for distinct, earlier data breach.

On Tuesday, Uber revealed in a statement from newly installed CEO Dara Khosrowshahi that hackers stole a trove of personal data from the company’s network in October 2016, including the names and driver’s license information of 600,000 drivers, and worse, the names, email addresses, and phone numbers of 57 million Uber users.

As bad as that data debacle sounds, Uber’s response may end up doing the most damage to the company’s relationship with users, and perhaps even exposed it to criminal charges against executives, according to those who have followed the company’s ongoing FTC woes. According to Bloomberg, which originally broke the news of the breach, Uber paid a $100,000 ransom to its hackers to keep the breach quiet and delete the data they’d stolen. It then failed to disclose the attack to the public—potentially violating breach disclosure laws in many of the states where its users reside—and also kept the data theft secret from the FTC.


It’s definitely possible there could be some serious consequences for Uber in a legal context as they’ve certainly breached some federal laws concerning disclosure to the FTC and in general not disclosing a breach that has leaked customer records.

They previously fired their Chief Security Officer, which obviously hasn’t helped much (more of a PR/Blame exercise most likely).

According to Bloomberg, Uber’s 2016 breach occurred when hackers discovered that the company’s developers had published code that included their usernames and passwords on a private account of the software repository Github. Those credentials gave the hackers immediate access to the developers’ privileged accounts on Uber’s network, and with it, access to sensitive Uber servers hosted on Amazon’s servers, including the rider and driver data they stole.

While it’s not clear how the hackers accessed the private Github account, the initial mistake of sharing credentials in Github code is hardly unique, says Jeremiah Grossman, a web security researcher and chief security strategist at security firm SentinelOne. Programmers frequently add credentials to code to allow it automated access to privileged data or services, and then fail to restrict how and where they share that credential-laden software.

“This is all too common on Github. It’s not a forgiving environment,” says Grossman. He’s far more shocked by the reports of Uber’s subsequent coverup. “Everyone makes mistakes. It’s how you respond to those mistakes that get you in trouble.”

It’d be interesting to get a bit more details on what happened, were the credentials accidentally pushed to a Github repo that was public? Or did the hacker(s) actually get access to a private Github repo that contained critical credentials?

Sadly both are pretty common, even with Github having an option to enforce 2FA across an entire organsiation – many people are not using it.

Source: Wired


Topic: Hacking News
RDPY - RDP Security Tool For Hacking Remote Desktop Protocol

RDPY – RDP Security Tool For Hacking Remote Desktop Protocol

RDPY is an RDP Security Tool in Twisted Python with RDP Man in the Middle proxy support which can record sessions and Honeypot functionality. RDPY is a pure Python implementation of the Microsoft RDP (Remote Desktop Protocol) protocol (client and server side). RDPY is built over the event driven network engine Twisted. RDPY support standard […]

Topic: Networking Hacking
Terabytes Of US Military Social Media Spying S3 Data Exposed

Terabytes Of US Military Social Media Spying S3 Data Exposed

Once again the old, default Amazon AWS S3 settings are catching people out, this time the US Military has left terabytes of social media spying S3 data exposed to everyone for years. It’s not long ago since a Time Warner vendor and their sloppy AWS S3 config leaked over 4 million customer records and left […]

Topic: Hacking News