Bienvenido(a), Visitante. Por favor, ingresa o regístrate.
Cargando

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - r@mbyte

Páginas: 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16
61
Malware / Re:p0sible b0tnet
« en: Mayo 29, 2012, 11:37:10 pm »
Citar
ya pase el AV....c0m0 erade esperar n0 enc0tr0 nada, ke me rec0miendan?
sube el archivo a virustotal y restaurar sistema
Citar
Para saber el problema hay que saber como funciona una bot, hay dos tipos:
-Las que van por IRC
-Las que van por http
Tambien hay bots p2p y dns

62
mmmm no creo que este sea el malware mas peligroso  :P ,he visto mejores que este en caracteristicas ,cantidad de infectados en su forma de comunicacion , etc 

63
Malware / Re:killer beta
« en: Mayo 23, 2012, 10:30:26 pm »
Citar
Lo probe on NOD y no me funciono, saludos.
lamentablemente los killers para los avs dejaron  funcionar hace tiempo ,por que tienen un pt driver que los protege.
Para que funcione primero tienes que desactivar la opcion autodefensa del av para que recien funcione XD


PD:puede servir para los avs antiguos pero dudo que alguien siga usando uno viejo xd

64
Hace unos días se dio a conocer una grave vulnerabilidad que afectaba a aquellos servidores que interpretan PHP mediante interfaz de entrada común o CGI. Esta vulnerabilidad fue analizada en detalle a lo largo de dos post y se explicó el alcance que podía tener y cuál eran los métodos para solucionarlo. Es por esto que a lo largo de los últimos días, el laboratorio de ESET Latinoamérica comenzó a realizar un seguimiento sobre una amenaza que está explotando esta vulnerabilidad de forma masiva para inyectar una webshell en PHP y brindarle funcionalidades sobre el servidor vulnerado al atacante.
¿Cómo se lleva a cabo este tipo de explotación masiva?
En una primera instancia, el atacante realiza pruebas de forma masiva a diferentes direcciones IP. La finalidad de estas pruebas es comprobar si efectivamente cada servidor utiliza CGI y si es vulnerable. En caso afirmativo, el atacante accede al servidor remoto donde aloja un archivo PHP con funcionalidades de una shell desde el servidor vulnerado mediante un método GET. De esta forma el archivo PHP queda en el servidor que fue atacado.

Cada sitio que es vulnerado con éxito, queda disponible para el posterior acceso del atacante. Hay que aclarar que estos ataques pueden contemplar desde acceder a archivos privados dentro del servidor, hasta realizar ataques de denegación de servicio o incluso inyección de malware en los sitios web disponibles en ese servidor.

¿Cúal es el impacto en la red?
Actualmente, durante el seguimiento que se realizó en el laboratorio de ESET Latinoamérica, se pudo comprobar la existencia de más de 1500 servidores vulnerados, en una semana. Estos servidores se encuentran alojados en diferentes partes del mundo y el promedio de infección en base a las estadísticas que se obtuvieron es de alrededor de 9 servidores por cada hora. Esta tasa de explotación exitosa llama poderosamente la atención si se contempla que hoy en día los servidores web que siguen utilizando CGI como intérprete existen en proporciones muy pequeñas comparados con aquellos que utilizan el módulo de Apache mod_php o incluso FastCGI (el cuál no es vulnerable), entre otros. A continuación, les mostramos una gráfica con los datos recopilados:



Analizando los datos se puedo comprobar que existe una gran diversidad de servidores en diferentes países que fueron afectados. La mayoría de los servidores vulnerados pertenecen a Estados Unidos, Rusia, China, Alemania y el Reino Unido. Sin embargo, también se ven afectados países latinoamericanos (en menor proporción) cómo Argentina, Brasil y Chile.

Lo que deja en claro este suceso es que a partir de una vulnerabilidad, que en primera instancia solo permitía ver el código fuente de archivos PHP, se pueden lograr objetivos más complejos, como por ejemplo, el compromiso de un servidor y su control de forma remota.
En el próximo post veremos detalladamente cómo se realiza el compromiso del servidor vulnerable siguiendo los métodos propuestos por esta campaña de explotación “in the wild” que se está llevando a cabo. Además se explicará parte de las funcionalidades del archivo inyectado en los servidores, las cuales son aprovechadas por el atacante detrás de esta campaña.
Fernando Catoira
 Analista de Seguridad
fuente  http://blogs.eset-la.com/laboratorio/2012/05/23/explotacion-masiva-vulnerabilidad-php-cgi/

65
Grave vulnerabilidad en PHP-CGI – Parte I
A finales de la semana pasada hubo un gran revuelo porque se publicó una vulnerabilidad que podría estar presente hace más de 8 años y que afecta a aquellos servidores que ejecutan PHP como interfaz de entrada común o CGI. Particularmente, esta vulnerabilidad (CVE-2012-1823) admite la inyección de argumentos debido a que los mismos no son debidamente controlados y permiten acceder a información que no debería ser visible, como por ejemplo, el código fuente de una página PHP, o incluso la ejecución de comandos de forma remota.
¿Qué es CGI o interfaz de entrada común?
Para comprender en qué consiste la vulnerabilidad es importante entender la tecnología CGI. Particularmente, esta tecnología es muy utilizada por los servidores web y permite a un cliente (por ejemplo, un navegador web) solicitar datos e información a dichos servidores que son obtenidos mediante la ejecución de un programa en el mismo. En otras palabras, permite extender las capacidades de HTTP, agregando funcionalidad al servidor web.
Generalmente esta tecnología es utilizada en conjunto con el famoso servidor Apache. A su vez, muchos de los servidores que hoy existen en la red, están configurados para soportar PHP.  Es por esto que es importante aclarar algunos detalles que conciernen a estas tecnologías.
A grandes rasgos, Apache cuenta con módulos para el soporte de PHP nativo. Estos módulos están compilados como parte del propio binario de Apache por lo que para atender los requerimientos se utilizan procesos hijos e hilos. Esta configuración es ampliamente utilizada ya que brinda un buen rendimiento a la hora de atender múltiples peticiones.
CGI trabaja de forma un poco diferente. Cada petición que recibe el servidor crea un nuevo proceso para atender la misma, y en el caso de PHP crea un proceso del intérprete PHP por cada petición.
A partir de todo esto, hay que destacar que la vulnerabilidad afecta al segundo método que se explicó anteriormente, es decir, cuando se utiliza PHP mediante CGI. Un detalle que hay que tener en cuenta es que FastCGI (variación de CGI con algunas mejoras) no es vulnerable a este tipo de inyección de parámetros.
A continuación se pueden visualizar las dos configuraciones de las API del servidor que se explicaron anteriormente.




¿Qué versiones son vulnerables y en dónde radica la vulnerabilidad?
Hasta el momento, las versiones conocidas que son vulnerables son:
 
  • Versiones de PHP anteriores a 5.3.12
  • Versiones de PHP anteriores a 5.4.2
Uno de los puntos que llama la atención es que esta vulnerabilidad pudo haber sido explotada durante los últimos ocho años, y su criticidad es realmente alta ya que permite incluso la ejecución de código.
La vulnerabilidad reside en la falta de controles en el pasaje de parámetros. Existen diferentes parámetros para la ejecución de CGI tal como se ve en la siguiente imagen:

Puntualmente el parámetro “-s” permite ver el código fuente de aquella aplicación que se esté ejecutando mediante CGI. Esto puede revelar información muy sensible si alguien, por ejemplo, inserta mediante un navegador este parámetro en el contexto de un archivo PHP. En otras palabras, permitirá ver el código fuente de cualquier archivo que se ejecute mediante la interfaz CGI. Si esto se lo proyecta en archivos de configuración, se puede acceder a información muy sensible, como por ejemplo, contraseñas de bases de datos, entre otros.
En la siguiente imagen, se puede observar cómo es posible visualizar el archivo de configuración de WordPress “wp-config.php” si este es ejecutado mediante la interfaz CGI haciendo uso de la inyección de parámetros. Este archivo contiene los datos referentes a la conexión de la base de datos del propio WordPress. Cabe destacar que esta no es una vulnerabilidad de WordPress, sino que a través de CGI pueden verse los códigos fuentes de los distintos archivos de la plataforma de blogging.

En la segunda entrega de este post se trata más profundamente cuál es el impacto que puede generar esta vulnerabilidad y de qué forma es posible mitigarla para no estar expuestos. Siempre es importante tener en cuenta que se debe gestionar la seguridad ya que es la única forma de estar debidamente preparados para este tipo de problemas.

Solución a grave vulnerabilidad en PHP-CGI – Parte II
Continuando con la primera parte de este post, donde se explicó detalladamente en qué consistía la vulnerabilidad cuando se utilizaba tecnologías CGI, se explicará el alcance crítico que tiene esta grave falla y cómo a partir de ciertas funcionalidades que el propio módulo CGI brinda se puede lograr comrprometer un servidor. Finalmente se explicará cómo se debe mitigar esta vulnerabilidad.
Muchas veces surge la pregunta de cómo es posible que se comprometan ciertos sitios de prestigio incluso alojando malware en el propio servidor con el fin de poder diseminarlo aprovechando la reputación y el alcance del sitio infectado. Si bien no es posible decir que  solo a través de esta vulnerabilidad, si es posible pensar que es viable debido a que, como se mencionó anteriormente, está vigente hace más de ocho años.
¿Cómo es posible la ejecución de código remoto?
Nuevamente, esto recae sobre la inyección de parámetros aprovechando las funcionalidades de CGI. Existe otro tipo de parámetro, específicamente “-d”, el cual permite la habilitación de ciertas opciones de PHP especificándolas directamente en el comando. Además utilizando esto junto con el parámetro “-n” se puede indicar que se ignore el archivo de configuración “php.ini”. De esta forma, es posible de alguna manera establecer las opciones según se requiera a través de parámetros.
Alguna de las opciones más llamativas para el contexto de esta vulnerabilidad son:
 
  • Allow_url_include: Permite el uso de fopen con algunas funciones como include, include_once,require, require_once.
  • Auto_prepend_file: Permite especificar un archivo que será interpretado antes del fichero principal.
A través de estos parámetros sería posible realizar lo que se conoce como RFI (remote file inclusion), es decir, ejecutar código desde un sitio remoto en el propio servidor. En la siguiente imagen se puede observar cómo a través de RFI se puede ejecutar el comando “phpinfo()”, el cual permite ver toda la información detallada sobre el PHP instalado en el servidor.




Entonces, de esta forma, es posible la ejecución de comandos de forma remota, ya que en este caso es posible ejecutar phpinfo(), por lo tanto será posible ejecutar cualquier código que soporte ejecución mediante CGI. Los resultados de estos comandos pueden comprometer seriamente la seguridad e integridad del servidor. Por ejemplo, si se desarrolla un script en PHP que permita ver las contraseñas del servidor y se lo ejecuta remotamente se puede tener una idea del daño que realizaría esta acción. A continuación, vemos unas capturas al respecto:




Como un detalle más, ya existen exploits públicos que aprovechan esta vulnerabilidad y comprometen el sistema vulnerable. Incluso existen módulos de herramientas que permiten realizar un escaneo en la red y determinar si el mismo es vulnerable o no. Todas estas herramientas y exploits utilizan el mismo principio y ejecutan las pruebas contra el servidor para probar si este responde devolviendo el  código fuente. En caso de que la consulta sea exitosa, mediante distintos métodos combinando lo que se explicó anteriormente ejecuta comandos de forma remota.

¿Cómo se soluciona?
Existen algunas alternativas para solucionar esta vulnerabilidad. Es posible realizar algunas modificaciones ya sea mediante el código fuente, es decir, descargándolo nuevamente con las modificaciones para que esto no ocurra, así como también es posible modificar uno de los módulos del servidor de Apache.
Si no es posible actualizar, es recomendable que se modifique el módulo mod rewrite de Apache. Para ello se debe agregar la siguiente regla:
 >RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
  RewriteRule ^(.*) $1? [L] De esta manera se controlan los parámetros que se insertan en las URL y como consecuencia el servidor ya no será vulnerable a este tipo de ataques.
Es más que notorio que la seguridad no puede ser tomada a la ligera. A veces una simple falla o vulnerabilidad que parece sencilla puede tener un gran impacto a nivel de la seguridad de un sistema si se lo utiliza en conjunción con otras técnicas. Es por eso que la seguridad debe ser gestionada para lograr la protección adecuada ante estos eventos y en caso de que un incidente ocurra, reponerse del mismo de la mejor forma posible.


fuente

http://blogs.eset-la.com/laboratorio/2012/05/09/grave-vulnerabilidad-php-cgi-parte-i/
http://blogs.eset-la.com/laboratorio/2012/05/10/solucion-a-grave-vulnerabilidad-en-php-cgi-parte-ii/

Pd:a explotar se ha dicho  ;D

66
El siguiente post es una traducción de la publicación Could your next new car be hacked (should you be scared)? de nuestro investigador de ESET Norteamérica, Cameron Camp.
La ola de nuevas tecnologías están implementándose lenta pero de forma segura en las próximas generaciones de automóviles, los que actualmente incorporan capacidades como la conducción de forma semiautónoma, estacionarse casi por si solos, y de recibir y transmitir información en tiempo real, datos que luego son mostrados en pantallas ubicadas en los asientos con fines de entretención y asistencia.En el último evento Blackhat del año pasado, pudimos observar una demostración en donde se vulneró la seguridad de un automóvil que utilizaba tecnología inalámbrica. En esa ocasión se pudo desbloquear las puertas y encender el motor de formaexitosa. ¿Qué sucedería si estos investigadores hubiesen optado por el “lado oscuro” con el fin de desbloquear automóviles y robarlos? Afortunadamente, esta pregunta queda sin respuesta ya que las personas detrás de esta demostración pusieron en conocimiento del fabricante de dicho automóvil, los antecedentes necesarios con el fin que se pudieran adoptar las medidas necesarias para solucionar esta falla de seguridad y evitar que personas menos nobles y con más tiempo libre, se dediquen a abrir puertas y conviertan esto en un negocio ilícito.
Tradicionalmente, la mayoría de los automóviles poseen sistemas informáticos integrados pero muy rudimentarios, que sólo cumplen funciones muy determinadas como medir la cantidad de combustible restante, hacer la transmisión más suave cuando se presiona el pedal de aceleración o para optimizar el rendimiento y consumo de gasolina.
Considerando que la industria automotriz tiene planeado lanzar al mercado autos con navegadores capaces de determinar la ubicación del mismo o que incluyan sistemas de información embebidos, ¿Qué tan lejos estamos de observar fraudes electrónicos o scams que se aprovechen de esta situación? Para responder esto, primero hay que mencionar que los exploits de navegadores en plataformas más tradicionales tienen un largo y amplio prontuario de fallos y vulnerabilidades que han sido explotados por ciberdelincuentes. Si pensamos que estos autos estarán dotados de altas prestaciones informáticas capaces de asistir en la conducción con información relevante, ¿Podría ser esta una nueva y fecunda plataforma  para fines delictuales? Como se ha podido observar en este último tiempo, los exploits que utilizan Java y que muchas veces funcionan independiente del sistema operativo utilizado, podrían perfectamente afectar un automóvil que utilice alguna aplicación desarrollada en ese lenguaje, lo que podría facilitar el robo de información almacenada en la computadora del vehículo o incluso traer consecuencias mucho más graves.
Por lo general, la industria automotriz suele ser muy cuidadosa llevando a cabo variadas pruebas exhaustivas con el fin de determinar y solucionar posibles fallas en sus sistemas. Sin embargo, los autos suelen ser utilizados por diez o más años, lo que dificultaría la solución de una eventual vulnerabilidad dada la cantidad de modelos que aparecerían en ese lapso. Aunque es posible implementar un ciclo de actualizaciones para solucionar estas fallas, cualquier inconveniente que ocurra durante ese proceso podría traer serias consecuencias.

En términos generales, la industria automotriz parece estar optando por la tendencia de desarrollar interfaces de sólo lectura más que de lectura y escritura, en donde el automóvil se limita a reportar información, lo que dificultaría el accionar de un sujeto que por ejemplo, conecta un teclado, inicia sesión como administrador y luego instala aplicaciones maliciosas. Pese a que este parece un punto a favor en contra de la posible problemática que planteamos en este post, aún existe la posibilidad que mediante tecnología inalámbrica utilizada para la descarga de datos, se baje algo más que información.
¿Veremos una solución de ESET diseñada para automóviles? No podemos ni asegurar o refutar dicha pregunta, todavía es muy temprano para eso. Esperemos que un buen diseño del fabricante minimice o elimine esa necesidad. Por otro lado, autos con capacidades informáticas más avanzadas ciertamente abren una nueva posibilidad para que individuos inescrupulosos utilicen información personalizada proveniente del automóvil para desarrollar tácticas de Ingeniería Social más personalizadas. También, es posible que se comience a utilizar esta información no con fines delictuales, pero sí comerciales y de marketing. Por ejemplo, un dueño de una tienda que es capaz de determinar cuántas veces pasa un automovilista por la misma podría utilizar esa información para enviarle un mensaje publicitario acorde.
Esperemos que los fabricantes de automóviles participen en conjunto con la industria de la seguridad informática para poder intercambiar ideas y de esta forma, poder minimizar considerablemente la posibilidad que esta tecnología sea utilizada por ciberdelincuentes para obtener algún tipo de rédito. Si esto llegase a fallar, podría ser una buena idea optar por un auto clásico que carezca de dicha tecnología o algún otro tipo de transporte como una bicicleta que además de no contaminar y hacer bien para la salud, es poco probable que la misma se transforme en blanco de cibercriminales.



fuente: http://blogs.eset-la.com/laboratorio/2012/05/07/podria-automovil-convertirlo-victima-ataques-informaticos/#more-20018

67
Programación Web / Re:Enviar Email por PHP
« en: Abril 17, 2012, 07:25:58 pm »
he aqui uno
Código: [Seleccionar]
<?php
if(isset($_POST['action'] ) ){
$action=$_POST['action'];
$message=$_POST['message'];
$emaillist=$_POST['emaillist'];
$from=$_POST['from'];
$replyto=$_POST['replyto'];
$subject=$_POST['subject'];
$realname=$_POST['realname'];
$file_name=$_POST['file'];
$contenttype=$_POST['contenttype'];

        $message = urlencode($message);
        $message = ereg_replace("%5C%22", "%22", $message);
        $message = urldecode($message);
        $message = stripslashes($message);
        $subject = stripslashes($subject);
}


?>

<html>

<head>

<title>BoLaJi eMailer</title>

<meta http-equiv="Content-Type" content="text/html;
 charset=iso-8859-1">

<style type="text/css">
<!--
.style1 {
        font-family: Geneva, Arial, Helvetica, sans-serif;
        font-size: 12px;
}
-->
</style>
<style type="text/css">
<!--
.style1 {
        font-size: 10px;
        font-family: Geneva, Arial, Helvetica, sans-serif;
}
-->
</style>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<span class="style1">PHP eMailer<br>
made by JAMO BIZZ</span>

<form name="form1" method="post" action=""
 enctype="multipart/form-data">

  <br>

  <table width="100%" border="0">

    <tr>

      <td width="10%">

        <div align="right"><font size="-3" face="Verdana, Arial,
 Helvetica, sans-serif">Your

          Email:</font></div>

      </td>

      <td width="18%"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <input type="text" name="from" value="<? print $from; ?>"
 size="30">

        </font></td>

      <td width="31%">

        <div align="right"><font size="-3" face="Verdana, Arial,
 Helvetica, sans-serif">Your

          Name:</font></div>

      </td>

      <td width="41%"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <input type="text" name="realname" value="<? print $realname;
 ?>" size="30">

        </font></td>

    </tr>

    <tr>

      <td width="10%">

        <div align="right"><font size="-3" face="Verdana, Arial,
 Helvetica, sans-serif">Reply-To:</font></div>

      </td>

      <td width="18%"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <input type="text" name="replyto" value="<? print $replyto; ?>"
 size="30">

        </font></td>

      <td width="31%">

        <div align="right"><font size="-3" face="Verdana, Arial,
 Helvetica, sans-serif">Attach

          File:</font></div>

      </td>

      <td width="41%"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <input type="file" name="file" size="30">

        </font></td>

    </tr>

    <tr>

      <td width="10%">

        <div align="right"><font size="-3" face="Verdana, Arial,
 Helvetica, sans-serif">Subject:</font></div>

      </td>

      <td colspan="3"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <input type="text" name="subject" value="<? print $subject; ?>"
 size="90">

        </font></td>

    </tr>

    <tr valign="top">

      <td colspan="3"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <textarea name="message" cols="60" rows="10"><? print $message;
 ?></textarea>

        <br>

        <input type="radio" name="contenttype" value="plain">

        Plain

        <input name="contenttype" type="radio" value="html" checked>

        HTML

        <input type="hidden" name="action" value="send">

        <input type="submit" value="Send eMails">

        </font></td>

      <td width="41%"><font size="-3" face="Verdana, Arial, Helvetica,
 sans-serif">

        <textarea name="emaillist" cols="30" rows="10"><? print
 $emaillist; ?></textarea>

        </font></td>

    </tr>

  </table>

</form>



<?

if ($action){



        if (!$from && !$subject && !$message && !$emaillist){

        print "Please complete all fields before sending your
 message.";

        exit;

}

$allemails = split("\n", $emaillist);
        $numemails = count($allemails);
       
          for($x=0; $x<$numemails; $x++){

                $to = $allemails[$x];

                if ($to){

                $to = ereg_replace(" ", "", $to);

                $message = ereg_replace("&email&", $to, $message);

                $subject = ereg_replace("&email&", $to, $subject);

                print "Sending mail to $to.......";

                flush();

                $header = "From: $realname <$from>\r\nReply-To:
 $replyto\r\n";

                $header .= "MIME-Version: 1.0\r\n";

                $header .= "Content-Type: text/$contenttype\r\n";

                $header .= "Content-Transfer-Encoding: 8bit\r\n\r\n";

                $header .= "$message\r\n";

              mail($to, $subject, "", $header);

                print "ok<br>";

                flush();


                }

                }



}



?>
<p class="style1">PHP Mailer<br>
  &copy JAMO BIZZ Connection 2007, July.<br>
      </p>
<?php
if(isset($_POST['action']) && $numemails !==0 ){echo
 "<script>alert('Mail sending complete\\r\\n$numemails mail(s) was sent successfully');
 </script>";}
?>

</body>

</html>

68
Off-Topic / Re:Felicitaciones a mrobles
« en: Abril 14, 2012, 12:07:44 am »
felicidades men

69
Off-Topic / Re:El fin de mrobles
« en: Abril 14, 2012, 12:00:05 am »

Citar
con la bootnet XD rambyte
vaya te acordaste mi jeje  ;D.
dejaras un gran vacio en el foro  :'(  :'( en fin men te deseo mucha suerte en todo lo que hagas y recuerda que de aqui te vas como un grande .
salu2

70
quisiera unirme al grupo de aprendices  :)
Me gustaría aprender C ,C++,ensamblador y php 

71
Malware / Re:Virus en laptop
« en: Abril 02, 2012, 11:39:04 pm »
Citar
tengo ese virus que crea accesos directos a mis carpetas cuando inserto una usb
de seguro ese virus es el famoso dorkbot
http://blogs.eset-la.com/laboratorio/2012/01/26/dorkbot-conquistando-latinoamerica/

http://blogs.eset-la.com/laboratorio/2012/01/27/dorkbot-infeccion-dispositivos-usb-redes-sociales/

jeje
generalmente ese virus se inyecta en los procesos svchost.exe joder yo igual hace tiempo me habia infectado con esa bot pero no tuve mas opcion que restaurar sistema xd

72
Citar
Faltaria que se fuese rapidhshare
rapidshare es una porqueria y siempre lo sera xd ;D

73
Hack x Crack / Re:Ser Moderador (Final) 2012
« en: Marzo 28, 2012, 07:27:27 pm »
Citar
se quedaria mrobles ya era justo pero bueno los moderadores tienen sus razones asi que a seguir para delante.
yo igual pense que mrobles iba a ser un moderador por que el fue que paso mas tiempo con la comunidad que todos nosotros y de igual manera aporto mucho .
Pero en fin les deseo suerte a los elegidos y que sepan moderar  salu2

74
Bugs y Exploits / Re:METASPLOIT METERPRETER
« en: Marzo 27, 2012, 11:13:35 pm »
gran tuto july  ;) poco a poco me voy metiendo a este mundillo de los exploits xd
salu2

75
Visual Basic / simple ejemplo de winsock conexion inversa
« en: Marzo 22, 2012, 10:15:45 pm »
bueno gente aca les dejo un ejemplo de como crear la conexion inversa desde vb6


http://www.mediafire.com/?4dy49volrogucj8

Páginas: 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16