Digital Research Team Announces Hack of 11 Websites Across Spain, Catalonia & Venezuela, Offering To Patch Site Vulnerabilities w/ Each Leak

Over the course of the last 24 hours a new group of hackers going by the name of “Digital Research Team” has announced the release of a wide-ranging series of hacks and leaks effecting different Government agencies across Spain and Venezuela, as well as a variety of public and private colleges/universities in Spain and Catalonia. In statements made available to Rogue Media Labs, the hackers claimed that all of their hacks were “Ethical,” not malicious, and they would therefore not be disclosing any of the files or databases uncovered by the hacks to the general public – believe me, because I tried. Instead, the hackers released redacted screen shots of each and every database they managed to penetrate, tagging the effected victims with each leak to serve as proof that the hacks were in fact real.

What makes this weekends release unique was the fact that, as the hackers announced their leaks on social media, they simultaneously tagged their victims with each posting – offering to teach them how their websites and servers had been hacked, as well as how to patch them in the future. The hackers also left behind an email address along with each leak – digitalresearchteam@secmail.pro – asking the victims to reach out to them for this very information. Not much is known about the group, but in a private message with Rogue Media Labs, Digital Research Team leader and founder “Synflod” explained how “we are just reporting vulnerabilities on websites to secure them and repair the errors in their web infrastructure. We leave our email in each publication so they can contact us faster and easier.

Implicated in today’s leaks however are Spain’s Ministry of Justice, Ministry of State, National Institute of Statistics, Institute of Mayors and Social Services, as well as the University of Malaga, Univesity of Huelva, University of CITCEA-UPC, a technological school specializing in energy, power electronics, mechatronics and enertronics, along with Rovira i Virgili University, the University of Pablo Olavide, the website of the official Chess team of the University of Oviedo and lastly, the website of the Bolivarian Government of Carabobo – led by Rafael Lacava in Venezuela.

Targets:

Ministerio de Justicia: hxxp://mjusticia.gob.es
Ministerio de Hacienda: hxxp:/hacienda.gob.es
Universidad de Malaga: hxxp://uma.es
Universidad de Huelva: hxxp://uhu.es
Instituto Nacional de Estadística: hxxp://sede.ine.gob.es/
Instituto de Mayores y Servicios Sociales: hxxp://sede.imserso.gob.es/
CITCEA-UPC: hxxps://www.citcea.upc.edu/
Universitat Rovira i Virgili: hxxp://urv.cat
Universidad Pablo de Olavide: hxxp://upo.es
Universidad de Oviedo: hxxp://uniovi.es/
Gobierno de Carabobo: hxxp://hacienda.carabobo.gob.ve/

Sample Screen Shots from Hack:

Ministerio de Justicia:

No photo description available.

Ministerio de Hacienda:

No photo description available.

Univerisdad of Malaga:

No photo description available.

Universidad d Huelva:

No photo description available.

Instituto Nacional de Estadística:

No photo description available.

Instituto de Mayores y Servicios Sociales:

No photo description available.

CITCEA-UPC:

No photo description available.

Universitat Rovira i Virgili:

No photo description available.

Universidad Pablo de Olavide:

No photo description available.

Universidad de Oviedo:

No photo description available.

Gobierno de Carabobo – Rafael Lacava en Venezuela:

No photo description available.

Exclusive: Remembering Ukraine’s Attempted Cover Up of Susan Rice & The UAE’s Illegal Weapons Shipments To Libya

Earlier this week I featured a report originally published by Amnesty International, discussing how various War Crimes are currently being carried by forces representing the United Arab Emirates in Yemen – primarily enabled by weapon shipments made available to them by the United States and European allies. As the report was quick to point out, nearly all of these arms transfers constitute violations of international law and various internationally negotiated treaties surrounding the delivery of weapons into War zones, especially in light of how these weapons ultimately wind up being used.

Now, I’m not exactly sure why it didn’t dawn on me until hours after publishing the original article, but the whole ordeal reminded me of a separate instance involving the UAE in 2017 – in which various international partners were co-conspirators in the violation of international law, also involving the illegal transfer of weapons and munitions from Western allies/powers to the UAE. For those of you whom do not remember, back in June of 2017 the UAE’s ambassador to the United States, Yousef Otaiba, had his emails hacked and leaked online by an unknown group hackers flying under the flag of “Global Leaks” – allegedly with close ties to Russia. Most notably exposed within the leaked material, at least in my opinion, were exchanges between Otaiba and then National Security adviser to Barack Obama, Susan Rice, discussing the arrival of “military equipment” to Libya in 2014 – equipment originally shipped from the United States but arriving in Libya via cargo planes from the UAE.

The Leak

While the emails have since been taken down, copies of the exchange between Rice and Otaiba read “MBZ asked me to inform you that we will be sending ‘equipment’ to our friends in the western part of Libya in the next 2-3 days. They will arrive in a UAE cargo aircraft and will be escorted by a UAE military contingent, just to insure safe passage. He just wanted me to give you a heads up this will be happening so that no one is caught off guard.” To which Susan Rice simply responded “Roger. Thanks.

As a report from Middle East Eye about the leaked material in question also outlined at the time, “while the words “weapons” or “arms” were not specifically mentioned, the 2014 correspondence roughly tracks a UN Security Council report leaked to MEE in June saying the UAE had illegally shipped weapons to rebels loyal to military leader Khalifa Haftar.” Explaining how “the UN has kept Libya under an arms embargo since the 2011 uprising that drove then leader Muammar Gaddafi from power, but the Security Council report details a “general increase in direct foreign support to armed factions in Libya” – including from the United States, the highest ranking member of the UN Security Council.

A later report presented to the United Nations in 2017 documented the arrival of 9 helicopters, 4 of which were heavily armed and designed for combat, a Mi-24 Hind gunship, a AT-802i single-engine light attack plane, as well as more than 500 military vehicles – including 90 armored personnel carriers. The report also details how, after its initial arrival, the AT-802i aircraft, originally designed to fight fires, had been re-fabricated and made into “a counter-insurgency and strike aircraft.” Moreover, following the conclusion of these initial deliveries, investigators also documented the delivery of 48 additional aircraft into Libya, all directly shipped to the country from the UAE between the years of 2014-2017.

As for where the ‘equipment‘ was actually delivered and to whom, the report indicates that the Libyan National Army (LNA) was the primary recipient – largely stationed throughout Eastern Libya, but heavily concentrated in the Eastern city of Tobruk. This is also particularly interesting to note because the country of Libya had been under a complete arms embargo by both the United Nations and NATO dating back to 2011 – quite literally making these shipments violations of international law.

Download Full 2017 Arms Report Presented To UN: https://anonfile.com/0db9idt1bd/pax-report-under-the-radar-arms-trade_pdf
2011 Arms Embargo from United Nations: https://www.legco.gov.hk/yr08-09/english/hc/sub_com/hs02/papers/hs02cb1-2642-1-e.pdf
2011 Arms Embargo from NATO: https://www.nato.int/nato_static_fl2014/assets/pdf/pdf_2011_02/20110927_110226-UNSCR-1970.pdf

The Cyber Attack Which Followed

Around that time, in September 2017, what I remember standing out to me most was coming under heavy assault from Ukrainian hackers – presumably for hosting screen shots of the leaked material well after Global Leaks had their domain shutdown and all of the content from it was scrubbed offline. I say this because the attackers attempting to launch cyber attacks against my website were all trying to leverage a single URL address, a URL address featuring my reporting on/of the leaked material described above. To this day, no one has ever gotten closer to hacking any one of my websites or social platforms than those Ukrainian hackers did that week, the week of September 15th 2017.

To accomplish this, hackers launched something known as an Edge Side Includes (ESI) attack in order to execute a CrossSite Scripting (XSS) attack via the syndicated connection between my WordPress publishing dashboard and Twitter account. In fact, if not for the legacy No Script browser extension installed on my Mozilla Firefox, first alerting me to the attempted attack, the hackers would have actually been successful in getting through. What’s perhaps even more interesting to note is that I managed to absorb and mitigate these attacks a little less than 9 months before they were first “discovered” by researchers working for GoSecure in April 2018.

Fortunately though, as fate would have it, there was no soup to be had for those Ukrainian hackers/dick eaters, and not a single one of them ever managed to get through or take down my site. Still though, I contend that I learned more about website security/vulnerabilities that week than any week prior. So, in a messed up kind of way, I guess I should almost thank them for what they did – though I never could quite figure why Ukrainians were trying so hard to cover for Susan Rice? I also wish I could remember or that I had saved it somewhere at the time, because I distinctly remember tracing one of the IP’s behind the attack directly back to a mayor’s office/address in Ukraine – though I can not accurately specify which or to whom accurately here today.

While I did have to blacklist the entire country of Ukraine to seal off portions of the attack at one point, Rogue Security Labs recently mitigated a similar Varnish Cache attack in October 2018 – essentially utilizing many of the same methodologies to mitigate the attack as I once did for Ukraine’s ESI and XSS attacks in 2017. If you would like to read more about these strategies, as well as how to implement them for yourself, you are invited to learn more through the threat analysis and security tutorial provided below.

Learn More – Advanced Caching Attack Spotted Targeting WordPress Owners: https://roguesecuritylabs.ltd/cache-attacks-wp-trashbin/

Browser Security Strategies – Including Mozilla: https://roguesecuritylabs.ltd/building-selecting-safer-web-browsers/

Team PARANOID CODEIN Releases Database Leaks Along with XSS & SQLi Vulnerabilities Effecting 7 Brasilian Websites

Every now and again I come across some truly unique leaks, such as was the case yesterday. This is when I cam across a string of leaks posted by a hacker going by the name of “Etico Kartovy,” uncovered by a group of hackers going by the name of “Team PARANOID CODEIN” – aka “PCOD Team.” The leaks provided below are unique in that only some provide any actual data uncovered from within websites, instead choosing to publish the vulnerabilities of certain websites and how they can be exploited via “Cross-Site Scripting Attacks” (XSS) or “SQL Injection” (SQLi). These are the first such leaks of their kind I have ever come across, and there were se7en of them at that.

Effected by the data breaches provided below are the Hospital of Santa Casa, the Institute of Lands of the State of Piauí, Ligas Acadêmicas of the Federal University of Uberlandia, the Union of the Administrators of the Federal District of Sinda, the website of Support for Aquaculture, Brasil, the Federal Saving Bank of Caixa and the Interlegis Program, a Brasilian based political news outlet.

Website: hxxp://santacasacm.org.br
Raw Data Leak:

Website: hxxp://www.interpi.pi.gov.br
Raw Data Leak:

Website: hxxp://cardioliga.famed.ufu.br
Raw Data Leak:

Website: hxxp://www.sinda.org.br
SQL Injection Methodology:

Website: hxxp://sc-aqua.com.br
SQL Injection Methodology:

Website: hxxps://sidmfextrato.caixa.gov.br/
XXS Vulnerability:

Website: hxxp://www.interlegis.leg.br
SQL Injection Methodology:

Centro Qualifies Poeta Joaquim Serra do Aepjs Hacked, Site Databases Leaked Online

On December 2nd 2018, a hacker going by the name of “Knushh” claimed responsibility for a hack of the Centro Qualifies Poet Joaquim Serra do Aepjs, an adult education/vocational training website located in Brasil. Knushh, whom is also said to live in Brasil, performed the hack to raise awareness on behalf of and in protest of Articles 13 and 11, controversial new Copyright directives recently put forth by the European Union in November 2018 – joining a much larger pool of international hacktivists also protesting the initiative.

Learn More About Articles 13 & 11 Here: https://www.wired.co.uk/article/what-is-article-13-article-11-european-directive-on-copyright-explained-meme-ban

Below you can find the administrator log in credentials for two databases attached to the domain (hxxps://centro-qualifica.espjs.edu.pt/). In a statement available on online, Knushh explains that the website suffers from an “SQL Injection Metodo GET/POST” vulnerability, as well as a “Cross-Site Scripting (XSS)” vulnerability, ultimately allowing him to hack the site and steal/leak data.

Raw Full Leak: https://ghostbin.com/paste/qv278/raw

https://twitter.com/Knushh/status/1069037818071183360

Hackers are Attempting To Exploit HTTP Transports Through Oracle WebLogic

Last night and on through this morning, my site has started coming under heavy attack from all over the world – but mostly out of the Asia Pacific region. More specifically, from Ukraine, Germany, Vietnam, Brisbane and China. What I uncovered was a new hacking technique I had never come across before, attempting to exploit http transports of cloud data services which hackers expected to be connected to my WordPress account. While the incident can be thought of more as a “probe” than an outright “hack,” it did reveal a lot about the strategy they had hoped to employ.

Auditing my firewall logs, it appears as though hackers were first attempting to run XSS attacks against my php file setup, hoping I had made/built custom edits to it through phpMyAdmin (pma) shell at some point or another in the past. When that didn’t work, hackers started probing my site to find out whether or not my account was tied to Oracle WebLogic. For example, hackers repeatedly kept running a string of probes that looked something like this:

No automatic alt text available.

There were over 40 more additional logs just like this made over the course of a 12-14 hour time span, from multiple IP’s. Upon investigation, hackers were attempting to do two things; launch a ClientSide denial of service attacks against my website and/or gain administrative privileges to it by hacking/exploiting 3rd party add-on’s/services tied to my WordPress account. What the hackers did not anticipate however is that I run my website through WordPress.com – not WordPress.org. This is important to understand because Oracle’s services can only be installed through WordPress.org accounts, which require owners to set up and host their own name servers/accounts – often times through Oracle, which just so happens to be one one of the Internets largest companies.

Researching the mechanics behind how Oracle WebLogic works and transports data, while Oracles servers are protected from within and an individual account holders information is “encrypted” by their user name and login, once logged in, as the data/content is transferred from the Oracle cloud to WordPress and vice versa, it is exchanged via http transports.  Using this unsecured connection between the two parties, hackers are attempting to get in the middle of the data exchange by injecting malicious JavaScript into the framework of WebLogic, also built on JavaScript, in order to gain administrator access to the end website. Once inside, hackers can edit, upload and install virtual machines to run within the framework of the existing programs – theoretically intercepting any future data exchanged between the two parties while also gaining access to all previously stored information.

While I do not own a WordPress.org account personally, this is something to watch out for. It is also a good idea to write a rule or install a plugin forcing all network traffic through https. You should also block/ban bad query strings and enforce HSTS security headers for each of your pages sites or article. TLS is also a must in 2018. As of 10/17/2018 this information has been reported to both WordPress and Oracle respectively.

Ads By Google Susceptible To XSS Attacks

Perhaps my mind is a bit scarred from all that I know and have experience, but the other day a friend of mine informed me how he had installed Ads by Google to start generating new revenue for his website, and the first thought that popped into my mind was how wide open to attack Google ads made his security headers and website in general. I know, totally normal thought process – right?

I say this because in order to display an ads content, Google Ads uses a mixture of JavaScript embedded within HTML, inserted into either into the body of a blog post or website security header itself. For example, the code looks something like this:

Image may contain: text

Installing Ads by Google Is A Built In Security Flaw

As Google Ad Automation‘s own web page even states, “Google Ads scripts provide a way to programmatically control your Google Ads data using simple JavaScript in a browser-based IDE.” Adding that “Only entry-level familiarity with JavaScript is needed.” What Google doesn’t explain though, is that these JavaScript requests are sent through http transports and rely on http headers to properly display the ads content. Moreover, these scripts come from 3rd parties completely un-affiliated with your site or site’s security structure/rules, essentially creating a giant backdoor/window into your website completely outside of your control. Moreover, considering that Google utilizes the simplest and most basic structure of JavaScript to form their ads, for the same reason, this also makes the code incredibly easy to compromise – if you are into that sort of string 😉

Granted I go a little overboard with my own security measures, but I’ve made it a point to block bad query strings, specifically to block Cross-Site Scripting (XSS) attacks from effecting my site. I have also taken the additional steps of installing https exclusive security headers through HSTS, while editing my website on Mozilla with the NoScript browser add-on enabled – just in case my firewall doesn’t detect or block every XSS attack. For reasons I have already explained, adding Ads by Google would essentially throw both of these measures right out the window.

Quite simply, the way Google structures their codes in order to enable ads on your website is a built in Cross-Site Scripting (XSS) attack just waiting to happen. Not only do these ads allow hackers to bypass a secured connection through your pages security headers, but the embedded JavaScript within the body of an article post might as well just create a giant hole/window right in the middle of your website – allowing for the direct injection of malicious code/script. Consequently enough, this is also why you will never see Google ads ever featured on this site.

If you are a little less paranoid, not running a security based web business and believe the added revenue may be worth the added security risk, then by all means go make your money – afterall, millions of other people already have. Hell, even I know I’m going to have to suck it up one day and start subscribing to their ads, just not here for this site.

Advanced Caching Attack Targeting WordPress Owners

Doxxing yourself out of the Anonymous Hacker Collective by starting a public security company does come with certain risks, such as the increased likelihood that the number of cyber attacks you are about to absorb is going to skyrocket. To that effect, over the course of the last week I have begun picking up on a new probe/hacking technique I’ve never come across before.

Auditing my firewall logs, it appears as though hackers are attempting to probe the back end of my website by searching for archived blog posts within the contents of my trash can. This is done by attempting to manually search for a hyperlink with “_trashed” added to the end it, indicating that the attacker is not actually looking for the published version of the article itself, but instead for the specific URL assigned to an article once it has been unpublished and transferred into your trash bin.

For example, these people automatically know that every WordPress blog comes pre-installed with at least one published blog post; The Journey Begins. Therefore, roguesecuritylabs.com/the-journey-begins becomes roguesecuritylabs.com/the-journey-begins_trashed. Or roguesecuritylabs.ltd/-encrypted-email-providers becomes roguesecuritylabs.com/encrypted-email-providers_trashed. So on and so forth.

What are They Searching for?

Researching the mechanics of how the trash bin works and how WordPress remembers data, even when a blog post has been unpublished and trashed, your LiteSpeed and Varnish Cache still treat/remember it as though it is a published post, because once upon a time that article actually was published. That is what cache is all about, after-all. But more on that briefly.

Earlier this year I was forced to mitigate a string of attacks originating out of Ukraine, where hackers had begun attempting to launch Cross-Site Scripting (XSS) attacks against cached versions of old blog posts I had once published under a different, but still connected, domain name. What I had uncovered was that the attackers were attempting to use my Varnish Cache in an attempt to enable Server-Side Includes (SSI) Injection of malicious scripts in outdated versions/URL’s of articles they hoped would be less secure than their current versions. While my firewall sealed them off gaining access to wp-Admin dashboard, I was only truly saved by the NoScript browser add on through Mozilla Firefox, which first alerted me to the XSS attack allowing me to block it.

Similarly, as was reported about 1 month after I first mitigated the attack, GoSecure came out with a new threat analysis explaining how “While conducting a security assessment, we noticed an unexpected behavior in the markup language Edge Side Includes (ESI), a language used in many popular HTTP surrogates (reverse proxies, load balancers, caching servers, proxy servers). We identified that successful ESI attacks can lead to Server Side Request Forgery (SSRF), various Cross-Site Scripting (XSS) vectors that bypass the HTTPOnly cookie mitigation flag, and server-side denial of service. We call this technique ESI Injection.” Adding that “through our testing, we’ve discovered a little under a dozen popular products that can process ESI: Varnish, Squid Proxy, IBM WebSphere, Oracle Fusion/WebLogic, Akamai, Fastly, F5, Node.js ESI, LiteSpeed and some language-specific plugins.

View GoSecure‘s Full Report: https://gosecure.net/2018/04/03/beyond-xss-edge-side-include-injection/

Combing my experience earlier this year, along with the new knowledge that trashed articles/URL’s on WordPress are still automatically cached as though they still exist published by default, it appears as though hackers are attempting to probe for cached versions of old articles in order to launch Edge Side Include (ESI) attacks against them.

How To Mitigate The Attack

Step 1: Purge or Remove All Cache. Thankfully, because of my experience earlier this year, I already knew better than to leave all my cache just “innocently” hanging around, and have security measures in place to purge all Varnish cache on a weekly basis. Similarly, you should make it a habit to purge/clear your Varnish cache on a regular basis, or disable the LiteSpeed cache plugin altogether – if you have already installed it. Granted I am a bit of a security freak, but I just don’t want the added security liability of leaving my cache out in the open simply to make my site milliseconds faster for my visitors, the risk/reward just isn’t there for me.

Step 2: Force all traffic through HTTPS. As GoSecure‘s report even elludes to, these sorts of attacks are only successful through bypassing holes in http protocols. Something which can easily be resolved by simply forcing all of your website traffic through the encryption of your SSL.

Step 3: Empty your trash bin. Quite simply, hackers can’t exploit a trashed article or URL if there is nothing inside your trash bin intself. Not only will clearing out your trash bin help free up some of your data and make your site more organized, but it will also prevent this latest hack from finding you.