1. Illustrations of Ingenuity
RUXCON 2017
ATTACKER ANTICS
Illustrations of Ingenuity
Presented by Bart Inglot & Byrne Ghavalas

2. Byrne Ghavalas Principal Consultant at Mandiant
Experience includes IR / Forensics, Security Research and Pen Testing
Enjoy climbing, sailing, walking and am partial to good wine and coffee

3. Today’s Tales Stealing Secrets from an air-gapped network
AV Server gone bad
Hidden comment that can haunt you
A backdoor that uses DNS for C2
Securing corporate is tricky
A little known persistence technique
Rewriting import table
Hiding in plain sight
Sandbox evasion
Recommendations
The aim of this presentation is simply to provide some examples of attacker TTPs seen in the wild. All of these examples are associated with a single group of threat actors and were seen during an engagement in the APJ region. First, I’ll talk about some malware we named SOUNDBITE and it’s use of DNS for C2. Next, I’ll talk about KOMPROGO and a simple but effective persistence technique that doesn’t appear to be commonly used or know. I’ll describe some camouflage techniques observed with SOUNDBITE and KOMPROGO and I’ll finish up with an attack seen against McAfee ePO.

4. Stealing secrets from Air gapped networks
DRIVEDETECT and MSSHELL

5. Background
The victim used an air-gapped network to keep their Intellectual Property secure
To move data between networks they used a specific brand of USB storage devices
Manufacturer provides software to create encrypted containers (proprietary format)
256-bit / 128-bit AES encryption
Many claims by the manufacturer to assure the buyers that the security is unbreakable
The attackers staged the attack in 3 phases:
Identify systems of interest by deploying reconnaissance utilities
Research the security measures in place
Deploy utilities to steal data from encrypted containers
Attribution by iSIGHT Intelligence suggests a cyber-espionage group known as TICK
For convenience, the employees move data between air-gapped and domain joined hosts on USB devices

6. Phase 1: Identify systems of interest
NirSoft USBDeview
Small GUI utility that lists USB devices currently connected and previously used too
Supports command-line arguments, e.g. export into a CSV file
USBDeview.exe /scomma output.txt
DETECTMON reconnaissance utility that monitors drive insertion and removal.
When the utility starts, it logs all connected drives
Logs when a removable drive is inserted or removed
The utility then runs the following:
cmd.exe /c dir <drive_root_path> /s >> <local_staging_path>\<year><month><day><hour>
The utility may continue to run the "dir" command every three minutes while the drive is inserted.
Sample MD5: <HASH>

7. NirSoft USBDeview

8. Phase 2: Research the encrypted containers
Strong crypto: 256-bit AES by default
Solution: capture the password
Container is split across number of files and the format is unknown
Solution: reverse-engineer the software / use APIs
When accessed with a valid password, no disk mapping is created – unlike e.g. TrueCrypt
Solution: dump the process / re-use the handle / use APIs
The encryption key could be potentially tied up to the device (unconfirmed)
Solution: monitor USB insertions and automatically steal predefined files
The "/s" flag performs a recursive directory listing.

9. Phase 3: Crack up the encrypted containers
MSSHELL stealer searches newly-attached fixed and removable drives
Hash each filename until a match is found
Searches for the mounting software
Then search for a file with a predefined file extension and above 4MB
Searches for the encrypted container
Then attempt to open the container with 4 versions of the mounting software that is embedded in the malware
Bonus: DRIVEDETECT steals unprotected files
The utility runs the following command:
xcopy <DRIVE>:\\*.* <local_staging_path>\<10 digits for a date>\ /E /I /Q /Y /EXCLUDE:<local_staging_path>\sys.txt
The exclude list included: encrypted containers, PE files, Adobe Reader, files specific to victim’s environment
xcopy:
/E Copies directories and subdirectories, including empty ones.
/I If destination does not exist and copying more than one file,
assumes that destination must be a directory.
/Q Does not display file names while copying.
/Y Suppresses prompting to confirm you want to overwrite an
existing destination file.
/EXCLUDE:file1[+file2][+file3]...
Specifies a list of files containing strings. Each string
should be in a separate line in the files. When any of the
strings match any part of the absolute path of the file to be
copied, that file will be excluded from being copied.

10. OPSEC MSSHELL uses modified MD5
Single byte change of a constant in Round 3
Pictures: “Fundamentals of Computer Security” by Pieprzyk, Josef (et al.)

11. Attribution
TICK is a cyber espionage team that targets public and private interests in the Asia-Pacific region
Active since at least 2009, maintained a low profile
Targeting of Chinese dissident organisations suggests Chinese origin
Targeted industries include: defense, heavy industry, aerospace, technology, banking, healthcare, automotive and media
Unconfirmed reporting by Symantec indicates targets in Australia, India, Singapore and USA
Custom Base64 alphabets / signed malware
Malware:
Fat Agent (aka IRONHALO and Gofarer)
PostBot (aka SNOWSHOE and Daserf)
Various downloaders, launchers, infectors, uploaders

12. AV Server gone bad Cobalt Strike, PowerShell & ePO
I have seen a attackers use a variety of methods, including logon scripts or infecting gold images. But what about your AV server?

13. AV Server Gone Bad – Background
Attackers used Cobalt Strike (along with SOUNDBITE and KOMPROGO)
Easily recognisable when recorded by Windows Event Logs
Random service name – also seen with Metasploit
Base64-encoded script, “%COMSPEC%” and “powershell.exe” suggest Cobalt Strike
Decoding the script revealed additional PowerShell script with base64-encoded GZIP stream that in turn contained a base64-encoded Cobalt Strike “Beacon” payload.
A service was installed in the system. Service Name: 0f65bea Service File Name: %COMSPEC% /b /c start /b /min powershell.exe -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkAT…
The attackers didn’t only rely on the backdoors we found; they made substantial use of Cobalt Strike. It’s a commercially available collection of threat emulation tools that works with Metasploit Framework, which is an exploitation framework.
In terms of artefacts, it was fairly trivial to identify attacker activity, provided of course it was logged in the Windows event logs and they hadn’t rolled. For example, as you can see from EVENT 7045 above, we can see the random service name, use of %COMSPEC% and powershell with the base64 encoded payload. On some systems, you may also get some snippets (or script blocks) from the PowerShell event log if you have PowerShell 5.0 deployed, as suspicious blocks are recorded.
When decoded, base64 script contained another powershell script that contained base64 encoded string, which was a GZIP compressed stream. Decoding and decompressing that yielded yet another powershell script with an base64 encoded payload. The payload was usually the BEACON payload from Cobalt Strike. The attackers were fond of using named-pipes rather than opening listening ports – this is a really powerful capability and enables the attackers to pviot and move laterally using SMB traffic, which usually doesn’t attract any suspicion.
With Cobalt Strike being so capable, operating in memory, easy pivoting and encrypted communications, pushing out the payload to multiple systems makes sense.
But how? The AV server is a pretty good candidate – but how easy it to repurpose an AV server?
Attackers used Cobalt Strike “Beacon” (mostly) with “named-pipe” to enable easy pivoting
Also made use of external C2 with custom URI
How to easily distribute the payload to systems?
The AV server will do nicely, thanks!

14. Attacking McAfee ePO
Jérôme Nokin gave a talk in 2013 titled “Turning your managed Anti-Virus into my botnet” and also created “ePolicy 0wner”
antivirus-into-my-botnet-owasp-benelux slides/
The “ePolicy 0wner” tool enables the ability to create rogue McAfee packages
Attackers may have “borrowed” ideas from the tool
Back in 2013 Jerome gave a talk…
ePO configurations can be fairly complex and involve multiple servers with repository caches distributed across the environment. Also, simply uploading your tool is not going to work as McAfee ensured that packages had to be appropriately signed.
Jerome’s reverse engineering efforts discovered that ePO used a hardcoded 3DES key and some XOR. His ePolicy 0Wner tool is available publicly and provides a range of capabilities, including executing commands across multiple systems or creating rogue packages that can be pushed out across the enterprise.
Comparing some of the artefacts identified through the investigation with the capabilities of the tool suggested that perhaps the attackers had “borrowed” some ideas from this tool.

15. ePolicy 0wner – Rogue Package Deployment
--cli-deploy
This mode hacks various files on the ePo server (such as catalog.z, PkgCatalog.z) and performs “Product Deployment” or “Command Execution” (with SYSTEM privs) on the managed stations. The ePo repository will be updated with your files, and also replicated on all Agent-Handlers (Multiple Agent-Handler are typically used in large network with remote branch offices to reduce network traffic between the managed stations and the master ePo repository).
--file </path/to/file>
The file you would like to upload/exec on the victim(s). The file will be added to a new McAfee product and then deployed on the managed stations. The new product will also embed a batch file called 'run.bat' which contains something similar to 'start <your file>'. [...]
The README is pretty comprehensive and there is a great video too. One of the modes available is “cli-deploy”. [Read and explain]. Tool handles the creation of the catalogue files with appropriate signing and compression.
The ”file” option allows one to specify the desired file to be uploaded and executed. It creates “run.bat” and uses “start” to execute the command.
Clearly, ”repurposing” of ePO is a worthwhile goal. What tipped us off?

16. That can’t be good! ePO Server traffic to multiple clients
Network monitoring identified communication between ePO servers and endpoints (on tcp/8081 – the port associated with the McAfee agent on the endpoint).
Here we see a PS1 file being posted to the endpoint. The script was similar to some Cobalt Strike PowerShell we had previously identified.
Note the URI.
Not good – time to take a look at the ePO server.
That can’t be good!

17. Found “KB ps1” on ePO
Found the file in multiple locations, including:
D:\Program Files (x86)\McAfee\ePolicy Orchestrator\DB\Software\Current\ DLP_Agent\Install\0409
Also found a RAR file:
D:\Program Files (x86)\McAfee\ePolicy Orchestrator\DB\repo.rar
The PowerShell file was found on the ePO server in multiple locations. Note the path matches what we saw in the URI.
We also found a RAR file…

18. What was in Repo.rar?
The RAR file contained the necessary elements required for rogue package distribution and execution.
Evidence found it was extracted on the ePO server.
The “run.bat” file seems familiar…
You will also notice that there is a RepoCache, this enabled distribution to the “Agent-Handlers” or other ePO servers in the environment.

19. And in “run.bat”?
start "" C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionPolicy bypass -noexit -file "%ALLUSERSPROFILE%\Application data\mcafee\common framework\current\DLP_Agent\Install\0409\KB ps1" && ping n 15 > nul
The use of “run.bat” that contains something similar to ‘start <your file>’…
This turned out to be a very effective mechanism for distribution of the Cobalt Strike payload to systems across the enterprise.
That brings me to the end of my tales. Of course, one always has to provide some recommendations.

20. HIDDEN COMMENT that can haunt you
Web Shell

21. Quiz
The attackers made a copy of “index.php” and then modified the original file
Pseudo-code of what was introduced:
now = datetime.now()
total_minutes = ticks(now).minutes()
value = total_minutes / 10
print("<!-- {ecd6899b-e8e6-44ea-8ff7-439" + value + "} -->")
Example:
<!-- {ecd6899b-e8e6-44ea-8ff } --!>
What could it be for?

22. Background Web Shells Common examples:
Common technique for attackers to get back to the environment
Passive in nature
Difficult to detect
Use legitimate web server functionality
Size and language can vary greatly
Obfuscated / encrypted
Minimal logging for POST requests over HTTPS
Business applications vulnerable too
Common examples:
China Chopper
c99 PHP Shell
WSO Shell

23. Example: China Chopper
Server-side script:
Client-side application:

24. Source: https://www. fireeye

25. Password Protected Web Shell
We discovered a “timestomped” web shell in the same directory
Pseudo-code:
#1 now = datetime.now()
#2 total_minutes = ticks(now).minutes()
#3 value = total_minutes / 10
#4 password = "ABC" + value + "XYZ" #5
#6 if (Cookies["Secret"] != password)
#7 {
#8 Redirect("
#9 }
#10 system($_GET["cmd"])

26. A backdoor that uses DNS for C2
SOUNDBITE
SONDBITE is a backdoor we identified during the engagement and utilised DNS for it’s command and control communications.

27. SOUNDBITE – Capabilities
Communicates with its command and control (C2) servers via DNS tunneling
Provides an attacker the ability to
create processes
upload and download files
execute shell commands
enumerate and manipulate files and directories
enumerate windows
manipulate the registry
gather system information
It’s a capable backdoor that successfully bypasses many network security policies. The malware did not need to communicate directly with the malicious name server and operated successfully through a normal recursive server. This makes tracking down the compromised hosts a lot more difficult.
During our network monitoring, an alert for the C2 communication would typically involve the recursive / caching name server and C2 but determining what downstream systems generated the requests tends to be difficult and, for many organisations, impossible as they have no logging of DNS requests / responses.

28. SOUNDBITE – Example of Supported Commands
Description
0x03
Start hidden window process <CommandArg0> with command line <CommandArg2>
0x04
Compress and upload file <CommandArg0>
0x05
1. Execute "C:\Windows\system32\cmd.exe /u /c <CommandArg0>"
2. Wait <CommandArg2> milliseconds for process to complete
3. Read response via created pipes, ZLIB-compress, and send
0x07
Write data specified in <CommandArg2> to file <CommandArg0>; if file <CommandArg0>’s parent directory does not exist, create it
0x0A
Enumerate windows
0x0F
Enumerate files in the <CommandArg0> directory
0x10
Move file specified in <CommandArg0> to <CommandArg2>
0x11
Delete file <CommandArg0>
0x12
Get logical drive letters
0x13
Create directory <CommandArg0>
0x14
Delete directory <CommandArg0>
It’s fairly simple but certainly capable. Notice that there is no ‘CommandArg1’ - it’s not clear why it is not used – perhaps it’s older functionality or something planned for a future variant.
Not shown and probably the initial command after the first beacon:
Set the system identifier, then get system information: computer name, username, OS version.
0x0B
1. Set HKCU\Software\INSUFFICIENT\INSUFFICIENT.INI\(Default) to binary data of length four specified in <CommandArg0>
2. Execute command 0x0C
0x0C
1. Get system information: computer name, username, OS version
2. If HKCU\Software\INSUFFICIENT\INSUFFICIENT.INI\BounceTime does not exist, write the current system time
3. Read HKCU\Software\INSUFFICIENT\INSUFFICIENT.INI\UsageCount
Set’s BounceTime value to an 8-bytes Little-Endian Hex value that would represent the time the system was compromised (i.e. backdoor operating and able to communicate with C2).
So, what does a Beacon look like?

29. SOUNDBITE – Beacon Example
280-byte DNS query
z.tonholding.com
z.nsquery.net
NULL RR (Resource Record)
0x0a is NULL RR
0x01 is Internet Class
First 6 bytes
Host identifier (stored in registry)
Last 3 bytes
Counter (GetTickCount)
Custom base64 dictionary
A 280-byte DNS query.
NULL RR defined in RFC 883 (completion queries) but obsoleted by RFC1035.
First 6 bytes are the base64 encoding of the 4-byte system identifier stored in the registry after the initial communication (Command 0x0B).
Last 3 bytes are from lowest 2 bytes of GetTickCount() and always change between requests.
Base64 is A-Z (Upper and Lower), 0-9 and _ -
A 32 character - 24-byte status message.
The 32 characters preceding the first “.” constitute the encoded status message.
Maximum is 47 characters preceding the domain name represent the encoded response data. Longer response uses 4-bit zero values between 46 byte sequences.
The bytes between the identifier and tick count are for status responses. In this case, the 2-byte sequence after the host identifier is NULL and this indicates a Beacon query.
0x01 = Delivering command data
0x02 = Command data delivery complete
For responses that need more than one message, the protocol provides a “Command results sequence number; begins with 0x01” recorded in this status message (at 0x0A). This means “Delivering data” would be set until the last item, which would then have “Command data delivery complete (0x02)” set.
What does a command from the C2 server look like?

30. SOUNDBITE – C2 Command Example
Offset
Length
Description
0x10 4
C2 command
0x14
Length of decompressed ZLIB data
0x18
Length of ZLIB-compressed data
0x1c
ZLIB-compressed data (header: 0x789c)
The C2 server embeds its command data in the RDATA portion of the DNS response’s RR.
Let’s take a look at the structure of a simple message prior to base64 encoding.
The command is specified at offset 0x10, followed by the length of decompressed ZLIB data, then the compressed length of the ZLIB data, the ZLIB header and finally the compressed data.
The bytes at offset 0x04 are used when dealing with messages spanning more than one request.
The ZLIB-compressed data beginning at offset 0x1C is optional for C2 commands that do not require arguments, like 0x0A (enumerate windows) or 0x12 (Get logical drives).
You might recall from the list of supported commands that 0x10 is the move file command. This is the compressed data, so what does this payload actually contain – what’s being moved?

31. SOUNDBITE – Decompressed Command Example
The 0x10 move file command requires the source and destination, CommandArg0 and CommandArg2.
The data structure is simply a length-value pair. Here you can see a length of 0x42 (or 66 in decimal).
If you count the number of characters in the path and filename you’ll see there are only 33 characters. However, you will also notice the values are the typical Windows UTF-16 encoding, hence a length of 66.
The 2nd argument is ignored and the 3rd argument is the destination.
In this case, the command is moving ‘oldfile’ to ‘newfile’.
You’ll recall that I explained that the malware will respond to command requests with a 24-byte status message. The protocol does become more complex when handling larger commands and results that span more than one message or are larger than 46 bytes. In that case, you can’t simply use ZLIB decompression – you need to account for the 4-bit zero separator between each 46 byte message. Those nuances aren’t relevant to our discussion though and I think it’s clear from what I have described that the backdoor is well structured and effective.
What about host-based indicators?
Commands are length-value pairs, with a 4-byte value
Commands are in Unicode
Example moves C:\Users\username\Desktop\oldfile to C:\Users\username\Desktop\newfile
Longer commands use more complex encoding and decoding technique with ZLIB

32. SOUNDBITE – Host Based Indicators
Value
Filename
xwizard.exe
SndVolSSO.exe
mscorsvw.exe
csc.exe
MD5
02b2d905a72c4bb2abfc278b8ca7f722
5394b09cf2a0b3d1caaecc46c0e502e3
e2d7d0021fd414349cbd95cd6a62f930
4f5a64c35d7b19a3143d2ca7b1c3264f
Persistence
WcsPluginService\xa0
Windows Color System\xa0
C:\Windows\xwizard.exe /k wcssvc
clr_optimization_v _86
Microsoft .NET Framework NGEN v _X86
c:\Windows\Microsoft.NET\Framework\v \mscorsvw.exe /s netsvcs
Registry
Software\INSUFFICIENT\INSUFFICIENT.INI
4-Byte value set by C2
Software\NL2\NL.INI
Signature
xwizard.exe (Unsigned)
SndVolSSO.exe (Self-signed – Microsoft)
mscorsvw.exe (Unsigned)
csc.exe (Self-signed – Microsoft)
Mutex
8633f77ce68d3a4ce13b d2daf_<USER>
843f0711e1a54ac ada311c06c_<USER>
PE Resource
RT_RCDATA for xwizard.exe contains ZLIB-compressed copy of SndVolSSO.exe
RT_HTML for mscorsvw.exe contains ZLIB-compressed copy of csc.exe
We identified two variants, both of which were uploaded to VirusTotal (and no, not by us). There are a few other HBIs, for example, when xwizard.exe doesn’t have admin rights to create a service, it will instead install to “%APPDATA%\Microsoft\Expression\” and use Microsoft\Windows\CurrentVersion\Run\ElbyCDIO” for persistence.
You recall from the beacon I described that there was a 4-byte value set with the 0x0B command? And then it is sent with every beacon / response? Well, it is stored in the registry. Rather handily, when you’re trying to map infected hosts to traffic, you can compare the identifier.
In this sample, xwizard.exe provides the persistence and is the dropper for the backdoor. This was the first variant we found and explains the name we gave the malware.
xwizard.exe is a valid executable name. SndVolSSO.exe doesn’t exist but SndVolSSO.dll is legitimate.
It is also worth highlighting that the attackers “signed” their malware. It’s a self-signed certificate, pretending to be from Microsoft. This was seen for both variants.
This second variant uses a slightly different registry key, but it still ends in .INI and operates in the same way as the other variant.
mscorsvw.exe provides the persistence and is the dropper for the backdoor – csc.exe
The service name file location here is very subtle – it’s almost spot on. The version number of is not valid – the legitimate version is Also, the service name of _86 is incorrect – it should be 32 or 64.
Speaking of persistence, let’s move on and take a look at a persistence technique used by another piece of malware we found.

33. Securing corporate email is tricky
Exchange Transport Agent

34. Background
The attackers wanted to read s across victim organisations
Most environments run Active Directory and Microsoft Exchange
Common attack angles:
Mailbox exporting
Inbox forwarding rules
Transport rules
Mailbox delegation
Less common techniques
ISAPI Filter
Used for stealing user credentials
Exchange Transport Agent
Extension of Exchange transport behavior
Available since at least Exchange Server 2010
Not listed are methods that are not directly related to compromise of AD or AD credentials, such as forwarding or accessing mail using anti-spam solutions, capturing SMTP network traffic in mail flow, compromising storage or backup systems, or hijacking mail flow through modification of DNS records.
Mailbox delegation:
- APT29 used single factor ActiveSync to steal 2FA backup codes

35. Extending Exchange Server
The attackers dropped 3 components on the Exchange server
Transport agent (“agent.dll”)
Load “miner.dll”
Capture sent messages by registering to a Routing Agent event
Extract metadata and the message content
Pass them to “miner.dll”
Mining component (“miner.dll”)
Load and decrypt the configuration file
Mine the s:
Encrypt and store on disk if criteria are met
Execute the command in the body and delete the if sent by the attacker
Uploader (“stealer.exe”)
Exfiltrate encrypted files and clean up

36. Create a Transport Agent
Template:
Relevant cmdlets:
Install-TransportAgent
Enable-TransportAgent
Get-TransportAgent

37. ✔ ✔ ✔ ✔ ✔ Achieved Objectives Secure Customisable Extensible Forgiving
Encryption: configuration file and mined s
Kill-switch: free space or current date
Customisable
Configuration file: monitored inbox list and ignore list
Extensible
Independent components
Remote code execution via s from the attackers
Forgiving
Logs errors to a file
Automated
No need for remote access ✔ ✔ ✔ ✔

38. A little known persistence technique
KOMPROGO
When I first identified the malware, it wasn’t immediately clear how it maintained persistence.

39. KOMPROGO – Description
Symantec: Backdoor.Komprogo
e/writeup.jsp?docid=
When researching the samples found during the engagement, I found that Symantec had identified a sample in December 2015 and it had many characteristics that matched what I found, including some of the HBIs and C2. Again, the backdoor is pretty capable and has the ability to manage files and processes, execute arbitrary commands and so on.

40. Komprogo KOMPROGO – Details Loads the KOMPROGO payload in to memory
Loader
Loads the KOMPROGO payload in to memory
Persistence Mechanism
Executes the loader if specific mutex is not found
Payload DLL
Copy of loader with modified PE header (makes a new DLL) and entry point is modified
Analysis of the samples we identified found that KOMPROGO actually consisted of 3 components:
Loader, Persistence Mechanism and Payload.
Initially, I thought the InprocServer32 was the means for persistence using COM object hijacking. That’s how I found the Symantec entry as I was looking up the CLSID.
The malware sets the value of this key – it uses a random executable that meets it’s requirements and this process is executed with an argument referencing the DLL payload.
So, how does the persistence work then?

41. KOMPROGO – Loader Creates payload DLL in “%TEMP%\..\” Creates mutex
Creates “Classes\CLSID\{53255E7F-D464-40FB-857D-A2F9F0E1E397}\InprocServer32\”
Random executable
PE file from %ProgramFiles% and %SystemRoot%\system32 or %SystemRoot%\SysWow64\ with resource directory
Target process used to load DLL payload as an argument
Executes target process with DLL argument then loads payload and unloads itself
Analysis of the samples we identified found that KOMPROGO actually consisted of 3 components:
Loader, Persistence Mechanism and Payload.
Initially, I thought the InprocServer32 was the means for persistence using COM object hijacking. That’s how I found the Symantec entry as I was looking up the CLSID.
The malware sets the value of this key – it uses a random executable that meets it’s requirements and this process is executed with an argument referencing the DLL payload.
So, how does the persistence work then?

42. KOMPROGO – Persistence
KOMPROGO uses “Services\WinSock2\Parameters\AutoDialDLL” for persistence
Mechanism is described by Hexacorn Ltd
When Winsock library (ws2_32.dll) is invoked, it will load the DLL specified in “AutoDialDLL”
The key usually points to a legitimate, signed version of “rasadhlp.dll”
DLL must export 3 functions
WSAttemptAutodialAddr
WSAttemptAutodialName
WSNoteSuccessfulHostentLookup
KOMPROGO variants observed installed 32-bit and 64-bit DLLs and configured the registry value as appropriate
One variant used “rasadhlp.dll” as the file name…
The backdoor uses AutoDialDLL. When I searched on this, I only found one reference related to malware persistence and that was on a blog from Hexacorn.
In my very limited testing, the Sysinternals Autoruns didn’t appear to identify this key.
It turns out that when the Winsock library is invoked, magic happens and in the end, the DLL specified by this key is loaded.
When the KOMPROGO persistence DLL is invoked, it will check if the malware is running, and if not, it will execute the launcher. We identified two variants of the backdoor in the environment. The attackers dropped both the 32-bit and 64-bit versions of the supporting DLL.
A little more investigation, and I found that the key exists by default and usually points to a legitimate and signed version of a file named “rasadhlp.dll”. One of the KOMPROGO variants used a file name “rasadhlp.dll” and that brings me on to ”Hiding in Plain Sight”

43. Hiding in plain sight Simple techniques used by SOUNDBITE and KOMPROGO
In this section of the talk, I am going to cover the simple techniques used by the backdoors to hide in plain sight.

44. Which one is Legitimate?
SOUNDBITE Example
Service Name
WcsPluginService
Display Name
Windows Color System
Image Path
<???>
Which one is Legitimate?
Service Name
WcsPluginService 
Display Name
Windows Color System 
Image Path
<???>
For those of you that were really observant, I gave away the answer when I showed you the HBIs for the first variant of SOUNDBITE – xwizard.exe and SndVolSSO.exe.
Which one of these is evil? And no, they’re not identical 

45. Which one is Legitimate?
SOUNDBITE Example
Service Name
WcsPluginService
Display Name
Windows Color System
Image Path
%SystemRoot%\system32\svchost.exe -k wcssvc
Which one is Legitimate?
Service Name
WcsPluginService 
Display Name
Windows Color System 
Image Path
C:\Windows\xwizard.exe /k wcssvc
Perhaps this will make it easier? Can you recognise the the good one versus the bad one now?
Why?
Would it be obvious if you couldn’t compare them with a 50/50 chance?

46. Which one is Legitimate?
SOUNDBITE Example
Service Name
WcsPluginService
Display Name
Windows Color System
Image Path
%SystemRoot%\system32\svchost.exe -k wcssvc
Which one is Legitimate?
Service Name
WcsPluginService 
Display Name
Windows Color System 
Image Path
C:\Windows\xwizard.exe /k wcssvc
So, the bottom one is bad and the top one is the legitimate version in this example. So, what couldn’t you see…

47. SOUNDBITE Example Service Name WcsPluginService Display Name
Windows Color System 
Image Path
C:\Windows\xwizard.exe /k wcssvc
Service Name
WcsPluginService\xa0
Display Name
Windows Color System\xa0
Image Path
C:\Windows\xwizard.exe /k wcssvc
‘NO-BREAK SPACE’ (NBSP)
Unicode – U+00a0
UTF8 – 0xc2 0xa0
Looks just like a regular space (0x20) in most tools and applications
Administrators are unlikely to notice the subtle difference when looking at a list of services
The attackers made use of a No Break Space – you may have seen this used in HTML encoding? It turns out that it is fairly easy to find this using automated tools but it’s unlikely that an admin or support engineer is going to spot that something is out of place.
What about KOMPROGO? I already provided a bit of a hint…

48. KOMPROGO Example
KOMPROGO uses “Services\WinSock2\Parameters\AutodialDLL” for persistence
The key usually points to a legitimate, signed version of “rasadhlp.dll”
How would you populate the key with something that looks like “rasadhlp.dll”?
NBSP is no good – it shows up as a space!
We know KOMPROGO uses the AutoDialDLL for persistence and it usually has a value of “rasadhlp.dll”. Assuming you know to look at this key, it would be pretty obvious when the value was changed from the default. As it turns out, the one variant we saw was configured with an unusual name. But the other variant was more cunning.
The challenge here is to create a file name and populate the registry so it looks “normal” to the casual observer. Any thoughts?
NBSP won’t work – it would show as a space.

49. rasadhlp.dll KOMPROGO Example
KOMPROGO uses “Services\WinSock2\Parameters\AutodialDLL” for persistence
The key usually points to a legitimate, signed version of “rasadhlp.dll”
How would you populate the key with something that looks like “rasadhlp.dll”?
NBSP is no good – it shows up as a space!
rasadhlp.dll
‘OPERATING SYSTEM COMMAND’
Unicode – U+009d
UTF8 – 0xc2 0x9d
Control character is not displayed in most applications – looks like “rasadhlp.dll”
No visual clues that something is amiss
The attackers picked the option of using a non-printing character that tends not to be displayed in many applications.
I always find it interesting to see how attackers try to camouflage their malware.
It’s also interesting to learn how they go about deploying it.

50. Recommendations
What can you do?

51. Recommendations Application whitelisting
Enhanced logging for PowerShell
Regular review of critical systems such as centralised AV, logon scripts, or other centralised distribution mechanisms
These are commonly targeted by attackers
It is important to know what assets, scripts and packages are configured
Change control and regular reviews can help identify rogue assets, scripts and packages
Nothing really new here and it’s certainly not a comprehensive list.
For PowerShell logging, upgrading to the latest version of PowerShell and ensuring the appropriate hotfixes are deployed will certainly be helpful in generating additional evidence for forensic analysis.
Thank you for your time. Any questions?

52. Thank You