[01:07.540 --> 01:13.660]  Hello everyone and thank you for switching to the Red Team channel. I'm going to present
[01:13.660 --> 01:21.600]  how to compromise critical bank systems with very old hacker techniques. But firstly, a disclaimer.
[01:23.560 --> 01:31.300]  This talk represents my opinion and doesn't represent any position of my current or past
[01:31.300 --> 01:38.220]  employer. The information that I'm going to present today is widely public, available on
[01:38.220 --> 01:45.920]  the internet. These vulnerabilities have been mitigated for the financial entity.
[01:46.300 --> 01:52.760]  The information related to the claims was never compromised and the systems have been tested
[01:52.760 --> 01:59.240]  only with restricted investigation purposes to find and mitigate critical vulnerabilities
[01:59.240 --> 02:09.180]  on the systems. So this is the agenda for today. We are going to review quickly
[02:09.540 --> 02:16.800]  what is speed, speed and spay, the previous attacks in those systems, critical steps
[02:17.960 --> 02:26.740]  of the attack that I performed and some mitigation and detection for those critical steps.
[02:28.220 --> 02:33.980]  But before that, a little info about me.
[02:36.480 --> 02:46.480]  Right now I'm working in one of the world's largest insurance companies. I love to learn new
[02:46.480 --> 02:54.540]  things and in my free time I participate in book bounties and CTFs with a pretty bad place in the
[02:54.540 --> 03:05.500]  world. Also, this is my second talk in DEFCON. The first one was called how to obtain 100
[03:05.500 --> 03:13.420]  Facebook accounts per day through internet searches. If you wanted to look at that talk,
[03:13.420 --> 03:19.840]  you can search the video in the DEFCON channel. So let's begin.
[03:20.640 --> 03:28.760]  What are SWIFT, speed and spay? Mainly there are systems used to transfer money between
[03:28.760 --> 03:37.600]  financial institutions with some difference. SWIFT was born to fulfill a need to establish
[03:38.580 --> 03:46.750]  a universal way to get money from one country to another and set standards for financial transactions.
[03:46.750 --> 03:55.240]  So the Society for Worldwide Interbank Financial Telecommunication was created.
[03:55.310 --> 04:02.370]  Now SWIFT also sells software and services to financial institutions,
[04:02.680 --> 04:13.290]  much of it for use on the SWIFTnet network as ISO 9362. Normally SWIFT use
[04:13.850 --> 04:20.430]  bank identifier codes, popularly known as SWIFT codes.
[04:24.400 --> 04:33.880]  Now, SWIFT is a domestic payment system for U.S. dollar transfers developed and operated by
[04:33.880 --> 04:43.160]  Banco Mexico. SWIFT sells same-day payments in U.S. dollars among health in Mexican banks
[04:43.160 --> 04:54.850]  in Mexican territory. And SPAY is a system to facilitate payments between financial institutions
[04:55.450 --> 05:07.030]  through their accounts and on behalf of their account holders in near real time, 24 hours a day,
[05:07.030 --> 05:14.150]  every day of the year, in Mexican territory also.
[05:17.130 --> 05:23.110]  Those systems have suffered many security breaches in the past because
[05:23.650 --> 05:28.150]  the interest in these systems is high.
[05:29.870 --> 05:36.070]  They manage all the transactions between financial entities and the rest of the world.
[05:36.070 --> 05:43.650]  As such, these systems could be an enormous risk because the goals of the
[05:43.650 --> 05:48.910]  threat actors are very profitable and easy to monetize.
[05:51.310 --> 06:00.270]  If we do a close-up in Mexico, a while ago there was a cybercrime group called Bandidos
[06:00.270 --> 06:07.850]  Revolution Team with headquarters in Mexico. They came to cybercrime through large-scale
[06:08.590 --> 06:16.830]  operations. They were charged with running one of the biggest cybersecurity breaches in Mexican
[06:17.390 --> 06:26.920]  financial history. Unluckily, they compromised the state systems in terms of banks in Mexico.
[06:28.440 --> 06:35.460]  The official report says that the Bandidos Revolution Team never compromised the central
[06:35.460 --> 06:46.360]  systems of the state. They only took advantage of the weak environment that runs those critical
[06:46.360 --> 06:56.920]  systems. The interesting part of this history is that they were not arrested by Mexican
[06:56.920 --> 07:04.340]  cybersecurity police or any other related cybersecurity authority. It was only possible
[07:04.340 --> 07:13.000]  after a private financial institution filled a complaint about electronic fraud that the
[07:13.000 --> 07:22.900]  investigation began. Later, a financial authority started digging around the case.
[07:23.180 --> 07:33.520]  They reviewed the activities for an individual that owned three football soccer teams and had
[07:33.520 --> 07:46.410]  intention of buying yet another team that they decided to step in. The attorney general's office
[07:46.410 --> 07:56.930]  in Mexico then ordered a search of 11 properties in Guanajuato state and they found everything
[07:57.730 --> 08:07.430]  from drugs, weapons, and cash, all the way to luxury vehicles like Ferrari,
[08:07.430 --> 08:15.730]  McLaren, Lamborghini, etc. Six men and two women were arrested that day.
[08:16.230 --> 08:25.750]  Sounds like the plot of a hacker movie, right? But do you really need to be an elite hacker to
[08:25.750 --> 08:44.130]  compromise those systems? We are going to check the critical steps of my attack and we can draw
[08:44.130 --> 08:55.890]  your own conclusions. Now, let's rewind a couple of years before that. A client asked me to perform
[08:55.890 --> 09:03.450]  an assessment and the scope was, as you might guess, some of the critical systems in their
[09:03.450 --> 09:13.030]  environment. Swift, Speed, and Spade systems. For the assessment, I need to emulate a cyber threat
[09:13.030 --> 09:21.710]  with access through the network and with the ability to gain local administrative access.
[09:25.890 --> 09:33.360]  Now, let me show you the steps that I followed to compromise Swift, Speed, and Spade.
[09:35.880 --> 09:45.660]  Using valid access through the network previously provided by the client, commonly called
[09:47.340 --> 09:56.560]  white card, I start for scanning to identify some common services stealthily.
[09:59.060 --> 10:09.600]  And techniques like not being scanned, specifying ports, and using a complete connection are very
[10:09.600 --> 10:23.390]  effective to perform that scans. With the information previously obtained, I found a very
[10:23.390 --> 10:32.130]  common port, SSH, and I tried to gain access to the systems performing a brute force attack
[10:32.130 --> 10:42.050]  with default credentials. I used a common dictionary from Kali and I tested the same username as password.
[10:43.630 --> 10:54.870]  I found a default valid database user. The next step was logging into the system and
[10:54.870 --> 11:07.850]  enumerated valid user stored in etc.passwd. Then, I created a custom dictionary with
[11:07.850 --> 11:17.330]  the users and then I tested users with the same password policy. Same password as username.
[11:22.850 --> 11:30.710]  Later, I found another maintenance account with more privileges and interactive shell.
[11:30.810 --> 11:40.950]  That user was in 80% of the host in my scope and it used the same bad password policy.
[11:40.950 --> 11:46.290]  So, I was capable to log in a lot of hosts but
[11:48.710 --> 11:50.910]  I had a problem.
[11:52.570 --> 12:00.390]  I realized that none of the conventional hacking tools were working well. They not only didn't
[12:00.390 --> 12:08.750]  support Solaris environments, but even worse, the client had an outdated version of Solaris.
[12:08.750 --> 12:16.610]  Also, most of the tools are designed to be used in Windows. There isn't even a native
[12:16.610 --> 12:25.310]  interpreter for that version of Solaris and Coal Strike doesn't have any auxiliary modes for that.
[12:27.730 --> 12:34.930]  I spent a lot of time in enumeration like some offensive circuit exam.
[12:34.930 --> 12:41.760]  And long after, I found that the system runs Java.
[12:46.150 --> 12:54.720]  I was so excited but in a moment of rush and without believing my TTPs before, I uploaded
[12:56.060 --> 13:02.950]  a Java interpreter. Then, obviously, since the interpreter is a well-known binary,
[13:02.950 --> 13:11.770]  it was deleted instantly by some endpoint protection. A common node error.
[13:16.620 --> 13:24.800]  I had to figure out a way to create an undetectable Java quickly since the time assignment for the
[13:24.800 --> 13:31.620]  execution was running out. And all the tools available to do this are designed for Windows
[13:31.620 --> 13:41.900]  such as Bail, Shelter Pro, etc. I found a very basic solution like all the techniques
[13:41.900 --> 13:48.580]  reviewed today. But powerful. In an entry from Nullbyte's blog called
[13:48.580 --> 13:59.100]  use MSF console to generate command to obfuscate payloads and evade antivirus detection.
[14:01.530 --> 14:10.090]  The entry in the Nullbyte's blog was current. Only one year before my engagement. So, I will be
[14:10.090 --> 14:34.930]  very reliable. And finally, I have an undetectable Java interpreter. And an interpreter's callback.
[14:37.740 --> 14:43.620]  At this point, I didn't have a root account yet.
[14:43.700 --> 14:49.280]  In my research to find how to obtain root privilege in those systems,
[14:49.280 --> 14:56.560]  I read some previous investigative works that indicated that the NSA hacking group,
[14:56.560 --> 15:09.820]  Equation Group, had compromised a lot of Swift systems. I found the leak made by the
[15:09.820 --> 15:21.220]  shadow brokers and it had documentation names of Swift systems compromised. And of course,
[15:21.220 --> 15:29.560]  exploits. Also, this is a very good tool for conspiracy theory.
[15:45.130 --> 15:51.330]  I found a tool in the shadow brokers dump used to elevate privilege
[15:51.950 --> 16:01.030]  in outdated Solaris systems called Extreme Parts. And finally, I was rooting the systems.
[16:05.280 --> 16:14.700]  After that, the client asked me to wrap things up and not touch any database information clients
[16:14.700 --> 16:20.220]  or systems because the assessment was running in an operational environment.
[16:20.780 --> 16:27.350]  Lastly, this is a request for my attack with 18 critical assets compromised.
[16:33.080 --> 16:44.690]  Yeah, these slides could be a success in the hall. Also, the hacksort part is exciting.
[16:46.730 --> 16:53.720]  It is important to talk about how to mitigate and detect these simple activities in a critical
[16:53.720 --> 17:03.520]  system such as DoF. So, let's begin. To mitigate port and vulnerability scans, you need to ensure
[17:05.100 --> 17:11.800]  that unnecessary ports and services are closed to prevent the use of discovery and
[17:11.800 --> 17:21.560]  potential exploitation. Also, the use of an IPS and proper network segmentation helps to protect
[17:21.560 --> 17:35.300]  to protect critical servers and devices. To detect it, you need to review the systems
[17:35.300 --> 17:41.580]  and network events. And with the help of a network intrusion detection system,
[17:41.880 --> 17:50.920]  you can identify scanning activity. It is a basic attack but very difficult to detect.
[17:50.920 --> 17:57.780]  So, the data and events should not be viewed in isolation.
[18:08.080 --> 18:15.960]  But rather as a part of chain of behaviors that could lead to another activity such as
[18:15.960 --> 18:22.380]  lateral movements based on the information obtained.
[18:24.900 --> 18:31.400]  To create a custom detection of this, I recommend creating a monitoring honeypot
[18:31.400 --> 18:43.240]  service in a common port that the technology doesn't use. For example, 22, 40, 43, 80, etc.
[18:49.800 --> 18:57.860]  To avoid successful brute force attacks, you need to use a robust password policy to prevent
[18:57.860 --> 19:06.080]  password from being guessed and the use of multi-factor authentications and solutions
[19:06.080 --> 19:14.840]  using passwordless logging, using SSH keychain, for example.
[19:15.240 --> 19:24.180]  For detection, you need to monitor authentication logs for system and application logging failures
[19:24.660 --> 19:33.760]  of valid accounts. If authentication failures are high, then there might be a brute force
[19:33.760 --> 19:40.560]  going on to access to the systems using legitimate credentials.
[19:41.700 --> 19:46.420]  Also, monitor failed authentication attempts across
[19:47.440 --> 19:53.520]  various accounts that may result from password spray attempts.
[19:53.720 --> 20:01.080]  I recommend creating honeypot accounts and monitoring failed attempts in the critical host
[20:01.080 --> 20:08.200]  and training users to not use the same password for multiple accounts and limit
[20:09.160 --> 20:14.320]  credential overlap across accounts and systems.
[20:17.220 --> 20:25.100]  Now, for the enumeration, this type of attacks cannot be easily mitigated with preventive control
[20:25.100 --> 20:35.020]  since it is based on the abuse of the system features. You can monitor process and command
[20:35.020 --> 20:44.020]  line arguments for actions that could be taken to gather system and network information.
[20:44.340 --> 20:54.960]  I suggest monitoring the access to etc.passwd and etc.shadow files and log failed access attempts.
[21:00.440 --> 21:06.620]  If the obfuscation itself is not possible,
[21:07.120 --> 21:13.980]  it might be possible to detect the malicious activity that caused the obfuscated file.
[21:13.980 --> 21:26.900]  For example, the method that was used to write, read, or modify the file on the system.
[21:27.620 --> 21:34.480]  The obfuscation tools can be used to detect these indicators in payloads. Obfuscation
[21:34.480 --> 21:42.620]  used in payloads for initial access can be detected at the network. Use network
[21:42.620 --> 21:52.480]  intrusion detection systems to identify compressive and encrypted attachments and scripts.
[21:52.900 --> 21:58.660]  This is a difficult one, but you can use next generation endpoint security tools
[21:58.660 --> 22:07.230]  and monitor the possible future actions. So, to summarize,
[22:10.090 --> 22:17.430]  those are the general recommendations. The main problems with those security gaps were
[22:17.990 --> 22:28.850]  using legacy systems, default and reuse users, and passwords with a bad password policy,
[22:28.850 --> 22:37.750]  no monitoring of privileged accounts, and the general recommendation to avoid those security
[22:37.750 --> 22:48.970]  gaps. Use a patch policy and its enforcement in critical assets. Isolate the legacy systems.
[22:48.970 --> 22:57.990]  Use a password and user policy that includes not the file usernames with password rotation.
[22:57.990 --> 23:06.870]  Add those and allow users to reuse passwords. Also, enforce activity monitoring in critical
[23:06.870 --> 23:20.270]  assets. With all this info, do you really need to be an elite hacker to compromise those systems?
[23:31.090 --> 23:38.990]  From my perspective, you don't need to be an elite hacker. Some critical systems have
[23:38.990 --> 23:46.290]  very basic vulnerabilities with a very bad security engine. Financial entities need to
[23:46.290 --> 23:59.770]  enforce their security controls because the risk is real. As I showed you in the previous slides.
[24:01.950 --> 24:12.290]  Well, thank you very much if you reached this point in my talk. If you want to share some gags
[24:12.890 --> 24:21.070]  with me, this is my Twitter. Also, I want to give a shout out to all the 19th floor team.
[24:21.070 --> 24:27.990]  And the Q&A will be on the Redteam Village Discord. And thank you for watching.