#datatag

All posts are written for everyone, including those with no prior computer science education. If you know how to write an email and have used a computer at least sparingly, you are qualified for understanding these posts. :)

What is a DDoS

What are the types of malware

Vulnerabilities and Exploits (old and somewhat outdated)

Example of how malware can enter your computer

What are botnets and sinkholes

How does passwords work

Guide for getting a safer password

Here are various malware-related posts you may find interesting:

Stuxnet

The North Korean bank heist

5 vintage famous malware

Trickbot the Trickster malware (old and not up to date)

jRAT the spy and controller (old and not up to date)

Evil malware

New to Linux? Here's a quick guide for using the terminal:

Part 1: Introduction

Part 2: Commands

Part 3: Flags

Part 4: Shortcuts

If you have any questions, request for a topic I should write about, or if there is something in these posts that you don't understand, please send me a message/ask and I'll try my best to help you. :)

- unichrome

Welcome back to another episode of An Actual Post. As usual, no prior computer science education needed. Today I'm going to talk about the worst of the worst malware. A lot of things has happened since what the general population consider to be viruses; annoying and maybe steals some money or logins. Unfortunately it's nowadays way way way worse than that so prepare for some uncomfortable reading!

Since the dawn of Stuxnet (which I wrote about here), malware has gotten increasingly more real-life, with real-life complications. It could be the Pegasus spyware, that targets political activists in authoritarian regimes, or disruptive infections that put a stop to Copenhagens metro trains for a few hours. But we're merely in the beginning, because in the last few years, some nasty shit has been going down. I'm going to write about two (technically three but I'll group the first two together for obvious reasons) of the worst incidents we've seen today.

BlackEnergy and CrashOverride

This piece of malware has been around since early 2000's, for the intention of creating DDoS attacks (which I wrote about here) from infected computers. It has since then branched out in its usage, particularly into targeting infrastructure environments. Most notable is the 2015 Ukrainian powergrid incident, which occured when the Russian hacking group known as "Sandworm", infected three Ukrainian energy companies, wiping out systems and causing a power outage for over 250 000 households during winter. The attack began with just one infected document being opened in the affected companies. When BlackEnergy infected their systems, it opened up a remote connection to the attackers, making them able to control the entire powergrid opreation from inside Russia, and thereby switching it off.

That was not enough though, as the attackers also implanted another piece of malicious software known as KillDisk, which wiped out many of the ciritical operation systems, as well as cutting off the connection to the UPS units, which are backup generators in case of system outage. To add a cherry on top, BlackEnergy did what it was originally intended to do - DDoS attacks - towards the energy companies call-centers, so that customers were not able to call and ask what was happening.

The Ukrainian powergrid is quite outdated, which made the attack easier, but it was also the saving grace, as they still had manual power-switches (as opposed to purely digital, which were under the attackers control), so power was eventually restored before they had to rebuild all of their digital systems. This is more concerning for countries with modern powergrids, as manual switches have all been replaced by only digital, meaning power restoration could take weeks or months in case of a similar attack.

Besides the energy companies, three other critical Ukrainian infrastructure organisations were hit by BlackEnergy, but did not result in any operational outages.

But it didn't stop there. Just one year later, in December 2016, a similar attack struck Kiev, successfully taking down one-fifth of the countrys electrical power. Like with the BlackEnergy incident, it was quite quickly restored, but there was a far more horrifying infection this time. Named CrashOverride, the malware was much more sophisticated than BlackEnergy, did more things automatically without the need of input from a remote attacker. It was also modular, meaning that functionalities could just be added to it like lego-pieces, adapting it to whatever kind of electrical grid it was entering. This meant that it wouldn't just be able to infect only Ukranian electrical grids, but just about any country's. Furthermore, evidence points to the 2016 CrashOverride infection only being a test-run.

Triton

Last but definitely not least - Triton, the first (known) malware designed to kill.

But before we talk about it, we need to look at what happened in Bhopal, India in 1984 when what has since been considered the worst industrial disaster of all time occured. At the Union Carbide India Limited pesticide plant in December 2nd, one of the gas tanks had a fatal malfunction, creating a massive gas leak of methyl isocyanate, which is extremely toxic. The leak spread to the surrounding city of Bhopal, resulting in almost 600 000 injured people, 40 000 temporary injuries, 4 000 permanent or severe injuries and over 8 000 people died within the first two weeks, with an estimated additional 8 000 deaths following due to injuries in the time after.

This was of course not caused by Triton, but it became the inspiration for the creation of the malware In 2017, a new piece of malware was discovered in Schneider Electrics industrial control system (called Triconex) at a Saudi Arabian petrochemical facility, which unravelled a horrible and complex secret. The infection chain for Triton contains many steps, so let's start with a brief overview of what the Triconex ICS and SIS is. ICS (Industrial Control System) are computers that handles all the industrial processes, computers that are programmed to do one thing and one specific thing only, unlike our regular PCs which you can play games or surf the internet and whatever. ICS will be computers who control valves, releases chemicals into vats, spins stuff around, or whatever automated processes may happen at an industrial facility.

SIS (Safety Instrumented System) are a kind of ICS that are responsible to check that everything is going alright and, if needed, will take over the process in case some ICS is failing and may result in damage, fire, injury or other disasters. So a SIS are monitoring failsafes, meant to prevent what happened in Bhopal.

Unless, of course, you program a malware intended to make the SIS malfunction.

What happened in the Saudi Arabian petrochemical facility started as follows:

The attackers successfully implanted a remote access trojan, which just like in the BlackEnergy case, makes the attackers able to control infected machines remotely. However, you can't infect a ICS or SIS this way, you need to enter a regular computer with internet access first, which is what they did. The initial machine was an engineering station, on which ICS and SIS computers are controlled. From there, the attackers wanted to plant their own software on the ICS and SIS machines, but there was a problem; the software can't be installed without someone turning a physical key on the Triconex devices, as a security measure. A second problem is that every time new software changes are made to a Triconex device, the old software will be deleted and replaced entirely by the new, which meant that the malware was at risk of being deleted if any engineer made any software changes.

So a second piece of Triton malware was made to overcome those hurdles. Instead of being save where the software should be saved in the Triconex devices, it saved itself where the firmware was installed (the piece of software that's made to have the Triconex work as opposed to where the software that tells the Triconex what to do), this not only gave Triton persistence even if new software was loaded, but also overrides the physical key as firmware always has administrator privileges. With all this in place, the attacker could execute any commands at the comfort of their home to both the ICS and SIS systems in the facility.

As luck would have it, before the attackers were able to cause any harm, the facility experienced a safety incident, prompting shutdown of the whole operation, and an investigation later uncovered the malware in the systems. Had Triton not been discovered in time, it would have been able to cause catastrophic failures similar to what happened in Bhopal. But just because it was thwarted this time, doesn't mean it's gone for good. There will always be some actor who is willing to try again.

Let me tell you about the most insane bank heist that is going to sound like I'm just leaking the script for the next American hacking movie. The goal? Steal one billion USD. And it all began with an email and a printer, which as we all know is where problems usually start. Another weapon in this heist was... Weekends and time zones.

As usual, no prior computer science education needed.

What happened?

On the morning of February 5th 2016, a printer had stopped working in the central bank of Bangladesh (Bangladesh Bank). But it wasn't just any printer, it was the printer responsible for printing all the records of the multimillion transfers going in and out of the bank. When the poor employees finally won the printer battle and had it resume normal operation, they saw a very concerning account transfer in the records that was coming out. The bank had an USD account in the USA, at Federal Reserve Bank, with approximately 1 billlion Dollars in it, and the Federal Reserve Bank had received instructions to drain almost the entire amount. In the records that came out in the printer, the American bank had attempted to urgently message the Bangladesh bank regarding this transfer, but couldn't get through to them. This was because the hack had actually started the day before, Thursday 4th, at around 20:00 Bangladesh time, when the bank was closed. However, USA had just started their day, giving the American bank plenty of time to follow through with the instructions from the Bangladesh bank to drain their entire account while they were closed. And that wasn't the end of it, as weekends are from Friday to Saturday in Bangladesh, meaning that the Bangladesh bank headquarters in Dhaka wouldn't discover this withdrawal until Sunday morning. That's when they immediately tried to reach the American bank, which of course didn't work as over there it was Saturday evening, and the American weekend is from Saturday to Sunday, meaning that they wouldn't be reachable until Monday.

You see what I mean by the hackers using time zones and weekends, finding the perfect time for the American bank to execute their orders while Bangladesh discovers the withdrawal several days too late, and again several days too late for Americans to be reachable. But it didn't stop there with their timehacking.

The money had to go somewhere from the American bank, and it would be stupid to send it directly to the hackers own account without laundering the money first. So they had set up four different bank accounts in the Philippines, using fake names and credentials. Why the Philippines? Because the Lunar new year was on Monday the 8th, which is a holiday and holiday means no bank activities in either Bangladesh or the Philippines, buying the hackers even more time. As a final act, they messed with the printer responsible for printing transaction records, adding another few hours to their schedule. Moon and stars really aligned perfectly for this plan.

But how did they do it?

It all began one year prior, in January 2015, with an email sent to several employees at the Bangladesh Bank. The email seemingly contained a job application from a person who didn't actually exist, but who was very polite in his request for a position at the bank, with a link to his CV and cover letter. Naturally this link led to a document with a little surprise gift - malware. Since the heist happened, at least one of the recipients must have clicked the link, and successfully deployed a RAT - Remote Access Trojan, malware that lets you control a computer from the comfort of your own home, as well as a toolkit with various malware to move from computer to computer, avoiding discovery, and covering their tracks.

From there, the hackers slowly made their way through the bank offices network, one step at a time to avoid setting off alarms, looking for any computer that had control of the banks SWIFT setup. SWIFT lets banks transfer large amounts of money between themselves and other banks connected to SWIFT. And as soon as they found one of those computers, they stopped. They didn't need to hack SWIFT in the traditional sense of the word - since they operated in a bank computer, the SWIFT-software assumed they naturally had to be bank employees. However, one of the parts of the malware used in the heist was for manipulating the SWIFT system, as the hackers weren't physically there to press anything. Additionally, since they were laying dormant for the time to strike, they needed to keep an eye out for SWIFT updates that could detect any tampering with the system, and adapt accordingly.

Then they waited many months for the stars to align on February 4th, 2016.

There were 35 transfers made by the hackers from the American bank account, totaling almost 1 billion USD, but there were two of these tiny little seemingly insignificant details that prevented this from becoming the worlds largest bank heist in history. The hackers biggest enemy became this concept known as “words”.

The Philippine bank accounts were all located in the same RCBC Bank office on Jupiter Street in Manila. And this would be the hackers downfall, as USA had sanctions put on an Iranian cargo ship called Jupiter. Since the transactions went to a recipient that contained the word “Jupiter”, it created a security alert in the Federal Reserve Bank that the employees needed to investigate. When they saw what was going on, they managed to stop all but five of the initial 35 transactions, thus “only” roughly 100 million USD made it to the Philippines. The Bangladesh bank requested to reverse the transactions, but since the money was in the Philippines, they would need bureaucracy in form of a court order to reclaim the money, and we all know that's not a 5 minute project. It was when Bangladesh filed the court order in late February that the case became public (since court orders are public documents) and the news broke to the country.

Once in the RCBC bank accounts, the money arrived on Friday the 5th and was immediately moved again. First the 100 million was converted to local currency, and some of it was withdrawn in cash, while the rest was sent off to other hacker-controlled locations. And this is where the second tiny little detail cut off even more of the hackers precious payday. 20 million USD had been sent to Shalika Foundation, a charity organisation in Sri Lanka. But,  once again the hackers worst enemy - words - decided to strike again. A typo was made in their transaction, sending the money to “Shalika Fundation”, and a bank employee who must have had their morning coffee spotted this typo and rejected the transfer and kept the funds frozen. This left the hackers with 80 million USD.

✨Now comes the money laundering!✨

There was a second reason for choosing the Philippines as deposit zone; gambling is legal and the casinos had no money laundering regulations imposed. The accomplices of the heist booked private rooms in two casinos located in Manila - Solaire and Midas - and proceeded to purchase tokens to gamble for with the stolen money. Since they played with a room consisting of their fellow accomplices, winning was not really much of a challenge. Then the tokens could be exchanged back to money that would now be clean. To avoid suspicion, they didn't gamble all of the money at once, but over the course of several weeks gambled away the dirty money to clean money.

Who was behind it?

It's normally difficult to pinpoint where the more sophisticated hacking groups come from. Oftentimes, they will leave false clues behind that points to another group so they will face more trouble instead of the group that did it. They may even place clues from several different groups, just to mess with the analysts. It's also quite common to simply “steal” a way of working from another group, or use a leaked/stolen tool from another group (criminals aren't safe from other criminals, especially not in this business) - there are new malware coming out all the time with code that is just a slight modification of a well-known malware actor that had their source code leaked or simply had hired the same programmer. Or they may leave no clues as to who was behind it. Attribution to the guilty part is usually the single most difficult mission in IT-security - often it's just pure guesswork with little to no solid evidence to back it up, if you're lucky there's circumstantial evidence.

This case was no different. The first clue came from the IP the bad guys used to connect to the Bangladesh bank from. It was located in Pyongyang, North Korea. But, as I mentioned, this is not a conclusive verdict, as the IP may simply be planted false evidence to throw the analysts off their track. After the heist, the hackers used a data-wiper to scrub as much of their malware off the bank systems, but they didn't succeed in deleting all of it, some of the tools were still present, including the wiper.

Due to the scale of this operation, it caught the attention of every single IT-security person and IT-security company worldwide, who all of course wanted to know who and how they did it. With the remaining malware, a joint effort was made, comparing malware code to other malware code for similarities. Some was found in Poland, after an analyst noted the similarities from another suspected North Korean hack. Some was found in another infamous North Korean hack targeting Sony Pictures. More and more signs pointed towards the same actor. Some were false leads, the hackers seemed to be wanting to implicate the Russians did it, but failed quite miserably at that, just sprinkling random Russian words into the malware and making it way too obvious it was a ruse.

You may not believe this, but the North Korean government has one of the most notorious hacking groups in the world, known as the Lazarus Group. Some of its more well-known adventures include an extremely data-destructive hack of Sony Pictures (as punishment for releasing “The Interview”), creation of the ransomware WannaCry which was used against many targets worldwide (including hospitals), and various attempts at gathering information from governments and government-affiliated corporations all over the world. And, of course, this heist.

Eventually, after months of collaboration all over the world, the final verdict fell on North Korea, and specifically one of their programmers. His name is Park Jin Hyok, and worked for Chosun Expo - a front company for the North Korean government, located in Dalian (China) who used the funds of the fake corporation gained from legitimate programming jobs from customers worldwide to create the malware and plan the heist with all of its expenses. Of course he wasn't the sole person involved in this project, but it's the only person we know was in it.

This particular heist had been meticulously planned for several years, and Park Jin Hyok had moved to Dalian, set up fake IDs and built a network of contacts there to avoid suspicion. However, he didn't manage to delete all of his online footprints, and became the number one suspect when his internet activities suddenly came from Pyongyang, North Korea.

Additionally, several Chinese business men - many associated with the casino industry in China's Macau territory - were also charged and arrested for assisting with setting up the gambling rooms and coordinating the money laundering process. One unknown Chinese business man managed to get away with 31 million USD of the 80 million that remained after the heist, and as you would expect, he was never to be seen again.

With the middlemen from China paid off, not much remained of the original 1 billion to North Korea. But the heist has fascinated the whole IT-security world nonetheless.

I remember when the news of this case dropped to the IT-security world, who all wanted to take part in the hunt. It was a very fun time, we were all sitting at the edge of our seats waiting for the next update. I hope it was at least somewhat exciting for you too to read about, and thank you for reading this long post! If you liked it, please consider reblogging as it motivates me to write more. You may also like malware stuff I've written about before, such as Stuxnet or just plain evil malware that is a threat to our daily lives.

Few of you have missed the whole AI/AI-art/ChatGPT-debate by now and even though few have the technical literacy to actually know what it is and its implementations, it hasn't stopped people from having opinions on it, and wow they sure are Opinions. It's mainly about how it's art-theft and will put already struggling artists out of business because now there's a chance that their dandelion found in a deviantart furry artwork they made using GIMP once will now be seen made sort of in the same style on a 250x250 pixel generated picture from a free online generator. And now I'm going to be snarky about it but also highlight a problem seen from the other end of this - the value of labour, and I'm not talking about the artists labour here.

But first let's look back a little bit for some well-needed perspective:

The logic for this is nothing we haven't seen before; you can't copy art and have it made available for just everyone to use like this! In the early 2000's it put musicians out of business and destroyed music forever with the introduction of napster. Pirate bay is why movies no longer are being made. It has destroyed art as we know it when people tauntingly right-clicked on a cryptobro's NFT and clicked "save as" (which I assume is also very problematic for the people who are vehemently against AI art? It's a literal 1-to-1 copy of your work). Media corporations are dying because intellectual properties are no longer protected under the copyright laws after 70 or so years. In the 90's there was even some video star who literally murdered a radio star. With the introduction of vinyl, it even killed live music forever.

So technology has been destroying just about all forms of art as we know it for a while now and each time it's the same doomsday predictions from the newly formed kind of art-christianity where some art has soul (Good, Skilled Laboured artists) and others hasn't (Evil, of course).

Now for the informative part of the post:

In the 1970's, computers as we know them today began forming, and with it, the value of a computer programmers skill and labour. Alongside with this, they saw a growing problem: Corporations owned everything they made, and corporations will also have the whole say about what will be present on a computer and the price of everything present on it.

This was not very appreciated by neither the programmers, and nor the customers (although few saw this growing problem coming). So in a weird twist of fate, programmers became one of the most left-wing labour-rights occupation you could find by forming Free Software Foundation, GNU, and essentially setting the stage for you to be able to use the free GIMP software instead of buying a staggering price for Adobe's Photoshop. It enabled you to download firefox instead of buying a copy of internet explorer. Because yes, before this kind of software activism formed, and the general environment of software development became to make it as freely available as possible - and having an outright despise for corporations like Novell and Microsoft for taking such huge amount of money to their own pockets instead of the developers, literally every piece of software cost money. A LOT of money.

This kind of 100% for free software usage we're used to has also led to us no longer being appreciative of the work and skill that goes behind keeping a software not only developed and updated continuously for decades, but also spending money on keeping it hosted and delivered to you for free. We even joke and scoff about the mere thought of having to pay 0.99 Euro for an app we'd use daily and a developer spent 2 years in the making. Meanwhile, when someone offers to pay someone merely 10 euro or so for a handmade blanket, there's an outrage about the value of labour and skill. And rightfully so! I support that, and so should you, even if it's labour that you weren't the one making.

And it doesn't end there either - we all know corporations has no trouble finding new ways to charge you money. Organisations like Free Software Foundation, various Linux projects and Mozilla have campaigned for a freer usage in general, leading to fair-use laws, campaigning for the right to repair your technology instead of having to buy new one all the time, as well as preventing corporations from banning every other piece of software on a computer that they don't want you to have (from a competitor or free alternative of their software).

I mentioned Adobe specifically, because in the wave of anti-AI-art outcry, artists are campaigning for a ban on making software that uses other peoples artistic similarities (not copies mind you, similarities, meaning making it a copyright infringement to have art that is similar to yours, since that's what AI-art algorithms create), and I'm sure right off the bat many of you can see the huge problem with that, but Adobe sure isn't. They're also gladly in on this, because that would mean that free alternatives of Photoshop like GIMP would also become a copyright infringement. So would a lot of our other free software we use daily and take for granted.

Create two new files in notepad or whatever, name them mouse.sys and mhgfs.sys and save them in the C:/system32/drivers/ folder.

Change your username or computer name to "honey" or "sandbox".

Change your system location to Russia.

Hello everyone and welcome to another episode of "an actual post".

Today I'll write about one of the most common type of methods malware use to strike your PC; Overflows. This is a very complicated subject but I will do my best to keep it simple and not use too many technical terms but rather terms you're most likely familiar with or will be. So as usual, no prior computer science education needed.

There are many different ways for malware (computer viruses) to enter your system, but how would it manage to slip by any antivirus detection? Say that you have a brand new kitchen robot cooking food for you, and it gets an infection with a malware that is telling it to stab you with a kitchen knife. Any security software in this robot could easily tell that some new random program just told the robot to do something obviously bad and successfully stop it.

So to circumvent detection, malware can use different kinds of stack/buffer overflows in subroutines of other programs.

What is a subroutine?

A subroutine is like a program inside a program, doing something that is commonly performed and can be called to do a specific job it is made for by the main program. To keep using our kitchen robot example, a subroutine of it could be to check if there are ingredients to cook a soup. This subroutine gets a list of things to check for; carrots, potatoes and onion, and at the end of this list there is an instruction to tell the main program the result of this investigation. This list is called a stack or buffer. Since it's basically just a stack of information. So our kitchen robot subroutine can look something like this:

Check for carrots

Check for potatoes

When done, return this information to: These ingredients exist. (0x01)

Point 3 in this todo-list is called the return instruction, which will send the result of the ingredient investigation back to the main program that is in charge of cooking the meal. This main program is located in the robots memory while running, at a certain address, just like your home has a certain address. Every program running will have their own specific location and let's say that the address of the main program is called 0x01.

How it's abused - Buffer overflow

Now you can use this subroutine checklist for malice by injecting evil instructions instead of ingredient checking. Each ingredient on the list is only allowed to be of a certain size, which means the number of characters available for each point is limited, to let's say 20 characters. So a common tactic for malware, to avoid being caught by antivirus software, is to not execute the code themselves, but tell the native and harmless ingredient subroutine to check for something at the point before the return instruction that exceeds 20 characters. This can be just random text. Once 20 characters have been written, the following characters will be forced into the final point of the list - the return instruction. So let's say a malware infection tells the subroutine to do this: Check for 1111111111Kill owner (0x01)

What happens in the todo-list of the subrotine? This:

Check for 1111111111 (The 20 characters limitation is reached)

When done, return this information to: Kill owner (0x01) (The following instruction will be overwritten by the remaining characters the malware sent to the subroutine)

So the characters following "Check for 1111111111" which is "Kill owner (0x01)" will overwrite the following return instruction with malicious input to the main program at 0x01 to do instead of cooking food. And since the main program is not considered malicious, antivirus software will not react to this.

Ways to combat this

These kind of exploits are notoriously difficult to prevent. But there are a few ways. The two most prevalent ones in Windows is called DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization). DEP simply forbids any code from being run in the location of the ingredient subroutine, it may only transmit data back to other programs but never instructions to execute actions. ASLR makes it so that when programs are run, they are not assigned the same address every time, meaning that the main program isn't always located at 0x01 but could be at 0x49 or wherever, so that the malware return instruction back to 0x01 isn't necessarily where the main program is located and as such nothing will be executed since the instruction was sent to an empty or otherwise wrong address. There are however...

Ways to combat the ways to combat this

Malware is pretty much always a step ahead so of course you can pass these security measures. The most sneaky one being to not use any own code, but abuse other already present and neccessary functionality of the robot. So to bypass the DEP protection, malware can construct a chain of other harmless actions and turn it into its own end goal.

So let's say our robot also has other functions for cooking you food that it needs to be able to do: Walking (like for walking around the kitchen and serving food) which is located at address 0x02, Grabbing things (like kitchen tools) which is located at address 0x03, and Attach (to blend ingredients into pots or otherwise combine food with each other) which is located at address 0x04. These are all vital to the functionality of the robot and will also not be stopped by the antivirus or other security measures.

So what malware can do to escape the prevention of its own code being executed, it can simply change the return instructions to point at a different program instead of the main program and keep doing so to create a chain of events. Instead of telling Main program at 0x01 to walk up to the owner and kill them, the return instructions will instead point to 0x02 - the walking program, with information to initiate its own subroutine to walk up to the owner instead of garbage ingredient check data and then overwrite the return instruction away from the main program at 0x01 to:

Locate owner

Walk to them

Perform next step111

When done, return this information to: Instructions for walking (0x02)

So the attacked ingredient check subroutine will instead of sending data back to the main cooking program simply send normal harmless instructions to the normal harmless Walking program at 0x02. That program will receive those instructions coupled with the next buffer overwriting of the return instruction address to point at 0x03: the Grabbing program. Which the malware instruct to grab the kitchen knife and then again overwrites the return address over to 0x04: the Attach program with instruction to attach the knife it now holds into the owner it has walked up to.

Individually these actions are harmless, but chained together it causes the robot to perform the otherwise illegal action of stabbing the owner without ever executing anything of its own code and as such bypasses the DEP protection.

In real life it will often be a chain that makes Windows use the command prompt to download and execute things from the internet that would otherwise be caught by security measures.

ASLR can also be bypassed in several ways, but that would have to be a whole separate post as this one is already getting quite long now.

Real life example: Equation Editor

One of the most popular native Windows programs to exploit today is the Equation Editor that Microsoft Office programs which allows you to write mathematical equations in a document. A subroutine in the Equation Editor that checks for and returns which font to use in the equation can be exploited by buffer overflows since it was written before DEP was implemented and is therefore vulnerable to executing malicious commands. The font information only supports 40 characters, so entering something longer than that can overwrite the return instructions to point at another location, such as the address of WinExec (which starts up programs), which will instead of a font name get instructions to execute Powershell and make it run a code snippet that downloads the complete malware. Since powershell ran that instruction, it has administrator rights and is whitelisted by security software due to it being a crucial Windows functionality.

All computers with Office programs older than 2018 are vulnerable to this exploit. It is not entirely known why Microsoft never patched this flaw in Equation Editor, but rumours has it that they have simply lost the original code and is therefore unable to rebuild it. Due to this major security flaw, Equation Editor was removed from Office programs by the end of 2017. But many computers around the world still uses Office programs from before 2018 and this attack vector is therefore still seen today.

jRAT (also known as Adwind) is, as the name suggest, a RAT. This is a type of computer malware that is probably the worst type to get infected by, as the acronym stands for Remote Access Trojan, meaning the attacker behind the infection will have complete control of your computer remotely. The attacker can, for example, log everything you type (including passwords), spy through the webcam, download and upload files from your computer, stop programs from running, and more.

In this post I will write specifically about how jRAT works, but the purpose of the malware is the same as any RAT - spying and stealing information. And don't worry, you won't need a computer science background of any kind to understand this post!

As with many other malware infections, they start by the user initiating the infection chain, thinking it is something else. This is where the "Trojan" part comes in, as in the Trojan Horse - You think you are opening one thing, for example an invoice or shipping confirmation in an email, but it is actually the malware you are starting up. It can arrive as an attachment asking for payment, a link in an email that seems to be from DHL with a package tracking number... The lures are many and sometimes very well made.

jRAT is depending on having Java installed, as the initial malicious file will run on Java, and its file will have an .jar-extension. It will start by establishing contact with a so-called "C&C" (Command and Control) server, which I have written more about in this post, but it is in short like a secret meeting place on the internet where malware go to fetch further instructions or files. one of the reasons for doing this is that it makes it harder for antivirus software to stop it. Once it has made contact with the C&C, it will immediately replace itself with the newest version and fetch three new files with different purposes. All of the will be located under the folder AppData/Local/Temp/, which is common for malware as it's kind of an all-purpose location, hiding in plain sight among other random files. The fetched files are:

1. A .class-file with a random name, for example _0.57339082331822999210753159459375475.class - this is the main malware "body" and is actually a .jar (Java) file, and it is responsible for all the control the attacker will have of your computer. It will also drop a copy of itself under the user folder, which is later used for persistence (I will go into this part later).

2. VBS-files (Visual Basic Script, a kind of scripting language made by Microsoft and is commonly used with Windows software) with random names, for example HOMgGlvQhbNYUpH8623951051131488128.vbs - these files will check the system for any antiviruses and other security products installed. Kind of like checking the perimeter for guards.

3. A .reg-file also under the same location and a random name such as cYlDEVVYAP4997887052104582959.reg - these will execute via reg.exe Windows process to create registry entries. The Windows registry is kind of a library for software, where settings and information software use is stored and referred to. Here jRAT will create entries of known antivirus, analysis and security products, for example Malwarebytes antivirus. The purpose of all these entries is so that whenever the system detects a new program started and it is in this registry list, it will immediately be stopped. So most of the tools available that could remove or analyse this infection will no longer start up or work.

Additionally, once the infection is complete and jRAT is landed safely in your system, it will create assistance files that provides the many spying functionalities of jRAT. They are all named “Windows” followed by 19 random digits, to appear like they are part of the system and avoid being deleted.

Now, returning to what I said about persistency: In malware terms, "persistency" means "how the malware will start up again whenever the computer is restarted, without user interaction or knowledge". There are many ways to achieve this, and here's how jRAT does it; since it is depending on Java to run, it will add Java to the Windows Auto Run registry collection. Windows looks into this part of the registry whenever your computer is started to see which programs it will run immediately on start-up, which is why you have programs like Spotify, Skype and Steam popping up in your face first thing in the morning. Additionally, in this auto run registry entry, it will also tell java that it should run the jRAT "body" file stored in the user folder under another randomly named folder. And as simple as that, jRAT will now run whenever you start up your computer

In this post we’re going to take a closer look on the malware TrickBot and its devious abilities. No prior computer science education is needed, I will try to keep this as easily understandable for everyone as possible, but if you have any questions - don’t hesitate to ask and I’ll do my best to answer. :)

The purpose of this post is to bring a basic understanding of how TrickBot works and operates. Hopefully it will bring an idea of how malware like this looks like and where it comes from, especially if you have no previous experience with it - this post is intended for you!

Introduction

TrickBot is a relatively new banking trojan that emerged in mid-2016. Its main purpose, like other banking trojans, is stealing money from your bank account or other financial institutions, as well as harvesting personal information to sell on the black market. All from your own computer. What really sets it apart from the others is its international scope: Banking trojans usually target one or a few countries and their banks. This is because it requires a lot of work to maintain a functional bank account robbing program that can operate on multiple banks, as we’ll see later in this post. TrickBot, however, is able to steal from over 25 countries across Europe, North America and Australia and is likely to expand even further with time.

It is likely to have originated from the previously successful but now defunct banking trojan Dyreza, as it shares a lot of similarities in the code. This indicates the authors behind it have a lot of experience as well as resources to keep up such an advanced piece of malware that is also so good at evading being caught by antivirus software. It is currently only able to infect Windows computers, so if you run GNU/Linux or Mac, you should be safe (at least for now!).

So let’s dissect TrickBot and see what makes it so nasty.

Delivery

Like most other malware, TrickBot employs a variety of methods to infect your computer, such as exploit kits and botnets. I have already written about those topics in previous posts, so I’ll link to them here to avoid repeating myself:

About exploits and vulnerabilities

About botnets

But the current main type of propagation is through infected Word and Excel documents delivered in emails. Typically, the emails are made to look like genuine messages from your bank or other corporations, with attached documents that are enticing to open, such as invoices, pay slips or something that calls to action. These documents contain a piece of code called a macro, which in itself isn’t malicious, but it contains instructions for the computer to go to specified addresses to download the actual TrickBot. This is one of the many strategies that prevents antivirus software from detecting TrickBot in an infected document.

To analyze a bit deeper, here’s the chain of events that occurs when the document is allowed to run the macro:

First, a randomly named .bat-file (for example vahjgkd.bat) is created in a folder for storing temporary files: AppData/Local/Temp. A .bat-file is a simple list of commands for the computers command interpreter, giving it instructions that doesn’t need human interaction, so you won’t notice what’s happening. These instructions tell the computer to go to a specific site and download a malicious file that is disguised as a harmless image file; logo.png. The .bat-file is randomly named to yet again avoid antivirus detection - it is more difficult to prevent something if you don’t know what it’s called.

The fake logo.png file is actually another randomly named file, this time an executable. Once downloaded and run, it will create new a new folder usually under AppData/Roaming/services or AppData/Roaming/winapp or similar, it varies a bit depending on the version of TrickBot. Additionally, it spawns a second randomly named .exe-file - This is the actual TrickBot - and saves it under the newly created folder. As a final task, the first .exe-file orders Windows to create a Scheduled Task of TrickBot. This will make Windows start up the TrickBot malware every time the computer is restarted or it’s somehow otherwise interrupted from running, making sure that it is always running no matter what you do. After all this work is done, the first .exe-file simply deletes itself.

Now it is time for the actual TrickBot to get to work! First, it will need to download its modules, which works kind of like Lego bricks. Each brick/module offers a different functionality, and can be built together to form a highly customizable and adaptable construct. These modules can be downloaded from addresses that are coded into TrickBot and are all saved in the newly created folder. I will write more in detail about these modules later on.

Now TrickBot has successfully infected the system! Let’s look at what it does from here:

The Trick

After infecting a system, TrickBot will hook itself to the browser(s) - Firefox, Chrome, Internet Explorer or Edge. Meaning, it will carefully monitor everything you do in your browser, while being disguised as a legitimate Windows process called svchost. It will not do anything else until you go to one of the sites TrickBot is looking out for - banks or other sensitive information services. Then it will trigger its browser injection and redirection attack:

Whenever you have typed in the address to your bank, TrickBot will immediately take you to another site operated by the criminals behind it. That fake bank site will look identical to the real deal, and to make it worse, TrickBot has another trick up its sleeve: While you are redirected to the fake site, TrickBot also maintains a connection to the real bank in the background. From there, it fetches the original address and displays it in the browser, so you can not see in the address bar that you are in the wrong place. To make it even worse, it also fetches the banks genuine digital certificate - which is used to identify and verify that the site does indeed belong to whoever claims to - and injects it along the fake bank site. It is more or less impossible to tell apart from the real deal.

This of course requires the authors behind TrickBot to be able to replicate each individual bank from all over the world, including correct language and graphics, as well as keeping it updated with changes. This is why I mentioned that it’s what makes TrickBot so special; the team behind it has the enormous resources required to do so.

Once on the fake site, you will as expected be prompted with your login information. This will be harvested and TrickBot will establish a connection to its Command and Control (C&C) server. This is a remote location where it receives further instructions from the criminals, as well as drop off the harvested data and other information.

This type of redirection attacks first surfaced in 2014 with TrickBots predecessor Dyreza.

Alternatively, depending on how the bank is set up, TrickBot may also use a similar type of injection attack that I have previously written about in this post.

Anatomy

Now let’s take a look at the structure of this particular malware. Here are its currently (as of November 2017) most important files and modules, all located in the folder created when TrickBot was delivered to the system:

- config.conf

This file contains the configurations for the communication with the C&C server, such as the information of where to go to download additional modules, dropping off collected data and settings for other modules.

- systeminfo

This is an system information gatherer. It will find out which usernames there are on the machine, which programs are installed, how much memory is available, which processor the computer has, and more.

- client_id and group_tag

Two other files that contains information. Client_id gathers which version of Windows you’re running, an unique identifying number for this particular infection as well as the name of your computer, while group_tag contains information regarding the version of TrickBot. Together, these two form a sort of ID of the computer that is used in the communications to and from the C&C server. A (somewhat simplified, for readability's sake) example of the content of these two files could be:

client_id: unichromescomputer_windows10.E4578F293

So first we have the name of the computer, an underscore followed by the operative system version, then a period followed by a random string of letters and numbers which are unique for each infection.

group_tag: tmt2

Just a single note regarding the internal information of TrickBot.

Let’s take a look at how a command sent by TrickBot to its C&C server can look like. Each command is represented by a number, for example number 5 means “Download this specified module to me please”, and is formatted like this:

[IP to C&C server]/[group_tag]/[client_id]/[command number]/[module requested]

So if TrickBot wants to download systeminfo to my computer, it would look like this:

https://193.9.28.24/tmt2/unichromescomputer_windows10.E4578F293/5/systeminfo

- importDll

This module is designed to steal information from your browser. Cookies, browser history, shared items, local storage, and more. Everything it can get its grabby hands on.

- injectDll

This one is responsible for the browser hijacking and the fraudulent bank sites I’ve talked about previously. To perform its duties, it employs the help of another configuration file, injectDll_configs, which in turn contains the following:

dinj: This is a list of all the banks and other sites that TrickBot targets, so it refers to this every time you go somewhere in your browser. If it’s on the dinj-list, you will be subjected to the second type of attack I wrote about earlier in the post.

sinj: Also a list of targets that works just like dinj, but instead of being subjected to the second type of attack, you will be redirected to the fake variant of the site.

dpost: Simply contains the IP address to where the stolen banking data is being exfiltrated to.

- outlookDll

This module is primarily targeted at corporate computers. It goes for the email credentials saved in Microsoft Outlook, such as emails, usernames, passwords, servers and ports. It finds this information stored in the computers registry, which is kind of like a library with settings and configurations for the system and programs. All the data gathered is sent off to an IP stored in the file mailsearcher_configs.

- shareDll and wormDll

Lastly, we have one of the more recent abilities of TrickBot, discovered in July 2017, but not fully functional until around September: Lateral movement. This means the ability to travel across a network and (without the interaction of any human) infect new computers. To achieve this, it uses the infamous exploit eternalblue, which was used in the reported ransomware epidemics of WannaCry and Petya/notPetya earlier this year. It lead to many corporations, organizations and other places such as hospitals or airports having all of their computers infected, just from a single computer on their network. It simply means that you can become infected without noticing it, just for being on the same network as a computer that opened a malicious document or encountered an exploit kit delivering TrickBot.