xorl %eax, %eax

Threat Intelligence: Phising kits anti-detection

leave a comment »

In my past posts I described a few common techniques used by phising kits authors to evade detection. This seems to be becoming more and more common among popular phising kits. Here I will present a few very common techniques that I came across lately.

The first one is the common anti-detection based on the client’s details such as originating IP address, user-agent string, domain name, etc. I have seen a few references of phising kit authors describing those with the slang term “antiboots” and “antibot”. You can see an example of such files below.

$hostname = gethostbyaddr($_SERVER['REMOTE_ADDR']);
$blocked_words = array("above","google","softlayer","amazonaws","cyveillance","phishtank","dreamhost","netpilot","calyxinstitute","tor-exit",);
foreach($blocked_words as $word) {
    if (substr_count($hostname, $word) > 0) {
		header("HTTP/1.0 404 Not Found");
        die("<h1>404 Not Found</h1>The page that you have requested could not be found.");

$bannedIP = array("^66.102.*.*", "^38.100.*.*", "^64.71.*.*", "^206.207.*.*", "^207.70.*.*", "^209.19.*.*", "^107.170.*.*", "^149.20.*.*", "^38.105.*.*", "^74.125.*.*",  "^66.150.14.*", "^54.176.*.*", "^38.100.*.*", "^184.173.*.*", "^66.249.*.*", "^128.242.*.*", "^72.14.192.*", "^208.65.144.*", "^74.125.*.*", "^209.85.128.*", "^216.239.32.*", "^74.125.*.*", "^207.126.144.*", "^173.194.*.*", "^64.233.160.*", "^72.14.192.*", "^66.102.*.*", "^64.18.*.*", "^194.52.68.*", "^194.72.238.*", "^62.116.207.*", "^212.50.193.*", "^69.65.*.*", "^50.7.*.*", "^131.212.*.*", "^46.116.*.* ", "^62.90.*.*", "^89.138.*.*", "^82.166.*.*", "^85.64.*.*", "^85.250.*.*", "^89.138.*.*", "^93.172.*.*", "^109.186.*.*", "^194.90.*.*", "^212.29.192.*", "^212.29.224.*", "^212.143.*.*", "^212.150.*.*", "^212.235.*.*", "^217.132.*.*", "^50.97.*.*", "^217.132.*.*", "^209.85.*.*", "^66.205.64.*", "^204.14.48.*", "^64.27.2.*", "^67.15.*.*", "^202.108.252.*", "^193.47.80.*", "^64.62.136.*", "^66.221.*.*", "^64.62.175.*", "^198.54.*.*", "^192.115.134.*", "^216.252.167.*", "^193.253.199.*", "^69.61.12.*", "^64.37.103.*", "^38.144.36.*", "^64.124.14.*", "^206.28.72.*", "^209.73.228.*", "^158.108.*.*", "^168.188.*.*", "^66.207.120.*", "^167.24.*.*", "^192.118.48.*", "^67.209.128.*", "^12.148.209.*", "^12.148.196.*", "^193.220.178.*", "", "^198.25.*.*", "^64.106.213.*");
if(in_array($_SERVER['REMOTE_ADDR'],$bannedIP)) {
     header('HTTP/1.0 404 Not Found');
} else {
     foreach($bannedIP as $ip) {
          if(preg_match('/' . $ip . '/',$_SERVER['REMOTE_ADDR'])){
               header('HTTP/1.0 404 Not Found');
               die("<h1>404 Not Found</h1>The page that you have requested could not be found.");

The above means that as an organization you need some “clean” networks, not associated to your organization from where you should be running your phising detection engines. But this is not the only one, another common technique employed by many phising kit authors is to embed static content of the target page in Base64 encoded format as shown below.

  <div class='dialog'>
  ... skipping ...

This means that if your detection engine was relying on callback images or static content, it is very likely that it will not be able to detect those phising pages. Additionally, I have identified numerous phising kits that do not target credentials only but they are after OAuth2 tokens too. This means that you have to tune your systems to support this attack scenario too. Finally, I have identified at least two separate phising kits which deliver the content AES encrypted along with a JavaScript implementation of AES to do the decryption during the client side execution.

ini_set('display_errors', '1');

/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  */
/*  AES implementation in PHP                                                                     */
/*    (c) Chris Veness 2005-2014 www.movable-type.co.uk/scripts                                   */
/*    Right of free use is granted for all commercial or non-commercial use under CC-BY licence.  */
/*    No warranty of any form is offered.                                                         */
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  */

Class Aes
     * AES Cipher function [§5.1]: encrypt 'input' with Rijndael algorithm
     * @param input message as byte-array (16 bytes)
     * @param w     key schedule as 2D byte-array (Nr+1 x Nb bytes) -
     *              generated from the cipher key by keyExpansion()
     * @return      ciphertext as byte-array (16 bytes)
    public static function cipher($input, $w)

Phising remains the top intrusion method for the past couple of years. Make sure that you adapt and combat this effectively. I hope that the above information were useful to some defenders.

Written by xorl

February 20, 2018 at 09:59

LKM loading kernel restrictions

with one comment

Loading arbitrary kernel modules dynamically has always been a gray area between usability oriented and security oriented Linux developers & users. In this post I will present what options are available today from the Linux kernel and the most popular kernel hardening patch, the grsecurity. Those will give you some ideas on how those projects deal with the threat of Linux kernel’s LKMs (Loadable Kernel Modules).

This can be split to two main categories, allowing dynamic LKM loading introduces the following two threats:

  • Malicious LKMs. That’s more or less rootkits or similar malware that an adversary can load for various operations, most commonly to hide specific activities from the user-space.
  • Vulnerable LKM loading. Imagine that you have a 0day exploit on a specific network driver but this is not loaded by default. If you can trigger a dynamic loading then you can use your code to exploit it and compromise the system. This is what this vector is about.

Linux kernel and KSPP
The KSPP (Kernel Self-Protection Project) of the Linux kernel tried to fix this issue with the introduction of the kernel modules access restriction. Below you can see the exact description that Linux kernel’s documentation has for this restriction.

Restricting access to kernel modules

The kernel should never allow an unprivileged user the ability to load specific
kernel modules, since that would provide a facility to unexpectedly extend the
available attack surface. (The on-demand loading of modules via their predefined
subsystems, e.g. MODULE_ALIAS_*, is considered “expected” here, though additional
consideration should be given even to these.) For example, loading a filesystem
module via an unprivileged socket API is nonsense: only the root or physically
local user should trigger filesystem module loading. (And even this can be up
for debate in some scenarios.)

To protect against even privileged users, systems may need to either disable
module loading entirely (e.g. monolithic kernel builds or modules_disabled
sysctl), or provide signed modules (e.g. CONFIG_MODULE_SIG_FORCE, or dm-crypt
with LoadPin), to keep from having root load arbitrary kernel code via the
module loader interface.

The most restrictive way is via modules_disabled sysctl variable which is available by default on the Linux kernel. This can either be set dynamically as you see here.

sysctl -w kernel.modules_disabled=1

Or permanently as part of the runtime kernel configuration as you can see here.

echo 'kernel.modules_disabled=1' >> /etc/sysctl.d/99-custom.conf

In both cases, the result is the same. Basically, the above change its default value from “0” to “1”. You can find the exact definition of this variable in kernel/sysctl.c.

        .procname    = "modules_disabled",
        .data        = &modules_disabled,
        .maxlen        = sizeof(int),
        .mode        = 0644,
        /* only handle a transition from default "0" to "1" */
        .proc_handler    = proc_dointvec_minmax,
        .extra1        = &one,
        .extra2        = &one,

If we look into kernel/module.c we will see that if modules_disabled has a non-zero value it is not allowing LKM loading (may_init_module()) or even unloading (delete_module() system call) of any LKM. Below you can see the module initialization code that requires both the SYS_MODULE POSIX capability, and modules_disabled to be zero.

static int may_init_module(void)
    if (!capable(CAP_SYS_MODULE) || modules_disabled)
        return -EPERM;

    return 0;

Similarly, the delete_module() system call has the exact same check as shown below. In both cases, failure of those will result in a Permission Denied (EPERM) error.

SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
        unsigned int, flags)
    struct module *mod;
    char name[MODULE_NAME_LEN];
    int ret, forced = 0;

    if (!capable(CAP_SYS_MODULE) || modules_disabled)
        return -EPERM;

Looking in kernel/kmod.c we can also see another check, before the kernel module loading request is passed to call_modprobe() to get loaded in the kernel, the __request_module() function verifies that modprobe_path is set, meaning the LKM is not loaded via an API or socket instead of /sbin/modprobe command.

int __request_module(bool wait, const char *fmt, ...)
    va_list args;
    char module_name[MODULE_NAME_LEN];
    int ret;

     * We don't allow synchronous module loading from async.  Module
     * init may invoke async_synchronize_full() which will end up
     * waiting for this task which already is waiting for the module
     * loading to complete, leading to a deadlock.
    WARN_ON_ONCE(wait && current_is_async());

    if (!modprobe_path[0])
        return 0;

The above were the features that Linux kernel had for years to protect against this threat. The downside though is that completely disabling loading and unloading of LKMs can break some legitimate operations such as system upgrades, reboots on systems that load modules after boot, automation configuring software RAID devices after boot, etc.

To deal with the above, on 22 May 2017 the KSPP team proposed a patch to __request_module() (still to be added to the kernel) which follows a different approach.

int __request_module(bool wait, int allow_cap, const char *fmt, ...)

    if (!modprobe_path[0])
        return 0;


    ret = security_kernel_module_request(module_name, allow_cap);
    if (ret)

What you see here is that in the very early stage of the kernel module loading security_kernel_module_request() is invoked with the module to be loaded as well as allow_cap variable which can be set to either “0” or “1”. If its value is positive, the security subsystem will trust the caller to load modules with specific predifned (hardcoded) aliases. This should allow auto-loading of specific aliases. This was done to close a design flaw of the Linux kernel where although all modules required the CAP_SYS_MODULE capability to load modules (which is already checked as shown earlier), the network modules required the CAP_NET_ADMIN capability which completely bypassed the previously described controls. Using this modified __request_module() it is ensured that only specific modules that are allowed by the security subsystem will be able to auto-load. However, it is also crucial to note that to this date, the only security subsystem that utilizes security_kernel_module_request() hook is the SELinux.

Before we move on with grsecurity, it is important to note that in 07 November 2010 Dan Rosenberg proposed a replacement of modules_disabled, the modules_restrict which was a copy of grsecurity’s logic. It had three values, 0 (disabled), 1 (only root can load/unload LKMs), 2 (no one can load/unload – same as modules_disabled). You can see the check that it was adding to __request_module() below.

	/* Can non-root users cause auto-loading of modules? */
	if (current_uid() && modules_restrict)
		return -EPERM;

However, this was never added to the upstream kernel so there is no need to dive more into the details behind it. Just as an overview, here is the proposed kernel configuration option documentation for modules_restrict.

A toggle value indicating if modules are allowed to be loaded
in an otherwise modular kernel.  This toggle defaults to off
(0), but can be set true (1).  Once true, modules can be
neither loaded nor unloaded, and the toggle cannot be set back
to false.
A value indicating if module loading is restricted in an 
otherwise modular kernel.  This value defaults to off (0), 
but can be set to (1) or (2).  If set to (1), modules cannot 
be auto-loaded by non-root users, for example by creating a 
socket using a packet family that is compiled as a module and 
not already loaded.  If set to (2), modules can neither be 
loaded nor unloaded, and the value can no longer be changed.

Unfortunately, grsecurity stable patches are no longer publicly available. For this reason, in this article I will be using the grsecurity patch for kernel releases 3.1 to 4.9.24. For the LKM loading hardening grsecurity offers a kernel configuration option known as MODHARDEN (Harden Module Auto-loading). If we go back to ___request_module() in kernel/kmod.c we will see how this feature works.

    ret = security_kernel_module_request(module_name);
    if (ret)
        return ret;

    if (uid_eq(current_uid(), GLOBAL_ROOT_UID)) {
        /* hack to workaround consolekit/udisks stupidity */
        if (!strcmp(current->comm, "mount") &&
            current->real_parent && !strncmp(current->real_parent->comm, "udisk", 5)) {
            printk(KERN_ALERT "grsec: denied attempt to auto-load fs module %.64s by udisks\n", module_name);
            return -EPERM;

The check in this case is relatively simple, it verifies that the caller’s UID is the same as the static global UID of root user. This ensure that only users with UID=0 can load kernel modules which completely eliminates the cases of unprivileged users exploiting flaws that are allowing them to request kernel module loading. To overcome the network kernel modules issue grsecurity followed a different approach which maintains the capability check (which is currently used by a very limited amount of security subsystems) but redirects all loading to the ___request_module() function to ensure that only root can load them.

void dev_load(struct net *net, const char *name)

    no_module = !dev;
    if (no_module && capable(CAP_NET_ADMIN))
        no_module = request_module("netdev-%s", name);
    if (no_module && capable(CAP_SYS_MODULE)) {
        ___request_module(true, "grsec_modharden_netdev", "%s", name);
        request_module("%s", name);

Furthermore, grsecurity identified that a similar security design flaw also exists in the filesystem modules loading (still to be identified and fixed in the upstream kernel), which was fixed in a similar manner. Below is the grsecurity version of fs/filesystems.c’s get_fs_type() function which is ensuring that filesystem modules are loaded only by root user.

    fs = __get_fs_type(name, len);
    if (!fs && (___request_module(true, "grsec_modharden_fs", "fs-%.*s", len, name) == 0))
    if (!fs && (request_module("fs-%.*s", len, name) == 0))
fs = __get_fs_type(name, len);

This Linux kernel design flaw allows loading of non-filesystem kernel modules via mount. How grsecurity detects those is quite clever and can be found in simplify_symbols() function of kernel/module.c. What it does is ensuring that the the arguments of the module are copied to the kernel side, and then checks the module’s loading information in the symbol table to ensure that the loaded module is trying to register a filesystem instead of any arbitrary kernel module.

    int is_fs_load = 0;
    int register_filesystem_found = 0;
    char *p;

    p = strstr(mod->args, "grsec_modharden_fs");
    if (p) {
        char *endptr = p + sizeof("grsec_modharden_fs") - 1;
        /* copy \0 as well */
        memmove(p, endptr, strlen(mod->args) - (unsigned int)(endptr - mod->args) + 1);
        is_fs_load = 1;

    for (i = 1; i < symsec->sh_size / sizeof(Elf_Sym); i++) {
        const char *name = info->strtab + sym[i].st_name;

        /* it's a real shame this will never get ripped and copied
           upstream! ;(
        if (is_fs_load && !strcmp(name, "register_filesystem"))
            register_filesystem_found = 1;

switch (sym[i].st_shndx) {

To help in detection of malicious users trying to exploit this Linux kernel design flaw, grsecurity has also an alerting mechanism in place which immediately logs any attempts to load Linux kernel modules that are not filesystems using this design flaw. Meaning loading a kernel module via “mount” without that being an actual filesystem module.

    if (is_fs_load && !register_filesystem_found) {
        printk(KERN_ALERT "grsec: Denied attempt to load non-fs module %.64s through mount\n", mod->name);
        ret = -EPERM;

    return ret;

Security wise grsecurity’s approach is by far the most complete but unfortunately, by default the Linux kernel doesn’t have anything even close to this.

Written by xorl

February 17, 2018 at 15:07

Posted in linux

Multi-stage C&C and Red Teams

leave a comment »

A few days ago I read this excellent analysis by TALOS team and apparently, the most interesting part from a technical perspective is the high-OPSEC multi-stage Command & Control infrastructure which is described by the following diagram from TALOS team’s post.

The idea is that only if the infected system is verified by the first stage C2, it will open a firewall hole on the real/second-stage C&C server to start the communication. On top of that, it using domain fronting to hide behind Cloudflare, a very popular technique.

So, why am I writing this post?
This post is for any red teamers reading this. Most mature red teams are using domain fronting to emulate advanced adversaries, and the notion of multi-stage C&C is not something new. See for example MITRE’s T1104 from the ATT&CK framework that explains a few known APT groups that use this method. However, how many times have you seen a red team actually employing this? I know it is a setup that increases complexity but if you are getting paid to simulate some advanced adversary, do it.

Please read TALOS team’s post and remember, if someone gives you money to simulate what a real APT would do, do it properly. :)

Written by xorl

February 11, 2018 at 17:04

Posted in security

OPSEC fail: China and the African Union center

leave a comment »

It is becoming more and more common seeing big players doing childish operational security mistakes and this is one of them. The entire failure can be summarized effectively by the following picture. But looks like some people have still a lot to learn…

The story is relatively simple and straightforward. Around 5 years ago China donated the headquarters building, including all the infrastructure and technical support, of the organization in Addis Ababa. African Union happily started using it as it was a generous diplomatic relationship act. But 5 years later, in January 2018 it was discovered that the servers of the building were backdoored.

Specifically, they noticed that every night at around 02:00 there was a lot of traffic originating from the African Union’s HQ with the destination being some unidentified servers in Shanghai, China. The story was brought to light by Le Monde on 26 January 2018.

So, the lesson here is simple. There is so such thing as free lunch. No matter who you are or what you do, no one will give you something for no reason. Especially when it comes to technology. If you are in a decision making position keep this in mind (if you didn’t already), trust no one.

Written by xorl

February 5, 2018 at 19:37

Posted in opsec

SSH Hijacking for lateral movement

leave a comment »

A few weeks ago I contributed the SSH Hijacking lateral movement technique to MITRE’s ATT&CK framework. In this post I’ll go through the different implementations of this attack that I have come across so far to provide more details around it. Note that by hijacking here we mean that someone abuses the existing sessions without having access to the authentication details. So, without using stolen credentials or private keys.

SSH’s ControlMaster is a feature which allows multiplexed connections. Performance wise this is great since you only have to authenticate to the target system on the first SSH session and then, depending on the SSH daemon configuration you can open multiple new SSH sessions through the already established connection. This can be tuned on the server side with the following two directives.

Specifies the maximum number of open sessions permitted per
network connection. The default is 10.

Specifies the maximum number of concurrent unauthenticated
connections to the SSH daemon. Additional connections will
be dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10. 

By setting MaxSessions to 1 you can disable ControlMaster/session multiplexing and each new session will require a complete new connection that includes the authentication step. However, if you don’t, then regardless of how strong authentication method you are employing for your users, an attacker only has to get code execution to one of your user’s endpoints and wait for that user to SSH somewhere. The attacker can look for the open connections by inspecting the directory specified by ControlPath directive on the client’s side or just using common tools like netstat. Then, if the attacker attempts to open an SSH session to a host that it is already in the ControlMaster, it will require no authentication or establishing a new connection as it is re-using the existing one. Note that ControlMaster is enabled by default.

Agent Authentication
To reduce friction and make the experience more smooth many organizations employ the use of SSH-agent which is a service that allows authentication via a local socket file. When you connect to a remote system you can choose if you want your ssh-agent to be available there too using the ForwardAgent directive. By forwarding the agent you can move around systems without having to copy keys everywhere or re-authenticating manually. However, this has a downside too. If an attacker has root access on any of the systems from which you have forwarded your agent, he can re-use that socket file to open new SSH sessions with your information. Here is a very brief overview of how this is done.

# Attacker finds the SSHd process of the victim
ps uax|grep sshd

# Attacker looks for the SSH_AUTH_SOCK on victim's environment variables
grep SSH_AUTH_SOCK /proc/<pid>/environ

# Attacker hijack's victim's ssh-agent socket
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXXXX/agent.XXXX ssh-add -l

# Attacker can login to remote systems as the victim
ssh remote_system -l vicitm

If you are using OpenSSH, you can mitigate this threat by using the AllowAgentForwarding directive to ensure that only the hosts that need it will have it, rather than the entire environment.

In both of those cases, the attacker never had direct access to the authentication details. However, by abusing SSH features an attacker is able to move laterally into the environment without causing a lot of noise. I already gave some native SSH directives that can be used to mitigate this threat but of course, depending on your requirements you might have to come up with something different.

Written by xorl

February 4, 2018 at 18:32

Posted in security

OPSEC fail: Triton ICS malware

leave a comment »

This was a pretty nasty OPSEC failure that happened about two months ago. And it all started with one of my favourite threat hunting platforms, VirusTotal. Basically, the failure is nothing more than this, someone uploaded this targeted malware on VirusTotal and this is how it got leaked. So, this post will not focus that much on the malware but on its OPSEC failure side.

The above photo includes some of the products of SIS (Safety Instrumented Systems). SIS’ ICS devices is the target of this, now public, malware which is known as Triton or Trisis. If you want to fully understand what this malware does I suggest you to study the following.

What is important for this post is the operational security side of things. Like many others, I personally use online sandbox services like VirusTotal for threat hunting but not only for new malware samples, but also for non-malicious documents that include sensitive information. This is a common technique but many professionals tend to forget it. So, what can you do about it?

A few easy steps that you can employ to protect your organization are the following.

  • During the interview process (or awareness training) assess the OPSEC understanding of your employees. For example, if someone describes an analysis using some online or cloud tool ask “what is the risk of using this tool for the analysis?”. Basically, make them think twice before submitting anything outside the organization’s network.
  • Use endpoint solutions and perimeter application level firewalls to allow access to sharing platforms only to employees that need it for their work. This will limit the potentially unintended leaks.
  • For the day-to-day detection operations, deploy scrapers that will be hunting for your IP (Intellectual Property) on online sharing platforms. Check for example Huginn.
  • To effectively respond to those incidents, watermark your high value information so that they can be traced back easily.

Triton/Trisis was a valuable piece of code that some organization lost due to bad OPSEC. Don’t make the same mistakes. :)

Written by xorl

February 4, 2018 at 11:58

Posted in opsec

Book: Threat Intelligence and Me: A Book for Children and Analysts

leave a comment »

This is one of the funniest and at the same time informative books around threat intelligence. It is written by Robert Lee and the illustrations were made by Jeff Haas.

I don’t have much to say about this book, I just love to get this book over to anyone that says “threat intelligence” in every other sentence without having a clue about what they are talking about. Definitely something worth having in your library and a great gift for any buzzword lovers you come across.

Written by xorl

January 23, 2018 at 08:10

Posted in books